15:02:56 #startmeeting OpenStack-Helm 15:02:57 Meeting started Tue Jun 13 15:02:56 2017 UTC and is due to finish in 60 minutes. The chair is srwilkers. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:00 The meeting name has been set to 'openstack_helm' 15:03:07 hey good morning everyone 15:03:11 thanks for joining 15:03:14 o/ 15:03:18 o/ 15:03:28 o/ 15:03:30 o/ 15:03:59 o/ 15:04:15 o/ 15:04:26 i don't think we have a lot on the agenda for this meeting, so there are a few items i wanted to touch one, then we can open up the floor and discuss any topics you'd like to raise 15:04:52 o/ 15:04:58 \o 15:05:23 alanmeadows: just have to be different with that right-handed wave. 15:05:36 look at alanmeadows, leading change 15:05:51 first thing i wanted to chat about was our list of bugs on launchpad: https://bugs.launchpad.net/openstack-helm 15:06:28 ive seen a few questions pop up on IRC over the last week about some weird behavior, and i'd like to see those end up in either confirming a bug's existence thats listed or filing a new one if appropriate 15:06:39 it's because his brain is abnorally large on the left side (engineering/science) that he can't raise his left arm. 15:06:43 haha 15:07:36 im virtually ambidextrous 15:07:43 leakypipes would appreciate that one. 15:08:13 srwilkers: I think the list is a good start, I think at the moment it is unrepresentative of the known issues 15:08:23 alanmeadows, agreed 15:08:46 +1 15:09:04 srwilkers: is the call to action to encourage those reporting them in IRC to go create bugs, or a call to action for regulars to fill those out for them? 15:09:44 the call to action is for anyone reporting behavior they expect is a bug should file a bug in launchpad 15:09:55 I'm wondering, do we have a creating a bug report documentation page, where we educate potentially new users the information we're after -- similar to the old github templates asking for versions of this that and others 15:10:00 the drivers team should then triage it and verify it's an issue and prioritize it 15:10:32 I will admit I haven't gone through the process yet to see what information launchpad asks for 15:10:37 for this project 15:10:41 i don't think we do alanmeadows 15:10:43 docs need this alanmeadows 15:10:45 alanmeadows, i believe there's openstack documentation for filing bugs or issues, let me check 15:11:02 docs need love in general, but this would be a good first step 15:11:23 * portdirect enters room huffing and puffing, sorry I'm late peeps 15:11:34 https://wiki.openstack.org/wiki/Bugs#Reporting is a good spot to start, albeit the links are for the core projects 15:11:48 but we can also provide a tl;dr for filing bugs 15:12:56 sure, but likely we want details such as kubernetes versions, kubelet versions 15:13:13 perhaps offering and suggesting something similar to the gate "dump it all" scripts 15:13:27 ++ 15:13:34 that sounds reasonable to me 15:14:21 that would be great - for the gate env we have pretty much everything clocked down, bar docker that i can think of - but a summary report would really help there 15:14:23 so when someone creates a bug report that says mariadb fails to come up, but from the dump its clear their PVC backend is hosed, we know what we're dealing with 15:15:10 yeah, that helps reduce the overhead associated with triaging and trying to pin down exactly where the issues may have started. 15:15:19 ++ 15:17:06 so the take away would be a document describing the details we need, directing them to a net-new script (some modified version of gate dump) where they can attach a debug payload 15:17:12 ok - all we need is a quick doc that tells you to set/export LOGS_DIR before running the log dump script 15:17:42 where they attach the payload is anther question though :D 15:17:54 portdirect, alanmeadows yep. i think it's reasonable to get that done fairly quickly 15:18:02 portdirect, ill let you take it from here for a bit 15:18:40 im off to another meeting 15:18:53 * portdirect glares around room 15:19:14 suppose we should also discuss blueprints? 15:19:49 ideally we should try and link the work we are doing against them (and I know I'm prob the worst at doing that...) 15:20:21 i know srwilkers has also been taking to infra about getting the link between launchpad and gerrit running smooth 15:21:10 yeah we need to be more diligent about referencing blueprints in our patchsets 15:21:40 I think perhaps we should come to some agreement about what needs a bp 15:21:43 to be clear, part of the problem is not only linking 15:21:48 the bp to link to is missing as well 15:21:54 most definitely alanmeadows 15:21:58 :) 15:22:18 so, if its a new feature it needs a bp (i think we can all agree here) 15:22:21 but to pete's point, how do we determine the scope required for a bp 15:22:26 yes 15:23:07 if its a change that is requires as k8s/helm etc change, we should prob make a blueprint in the form of say (bp: support helm 2.4) 15:23:23 which may touch on sveral charts/areas 15:23:51 I guess any new feature needs a blueprint that will explain the motivation. 15:24:04 Fixes and minor refactors won't need blueprints. 15:24:10 agreed 15:24:15 I think that's the simplest classification you can get. 15:24:22 And in doubt - ask the core team. :) 15:24:33 right - to that i'd like to say that project-wide refactors should be given more attention (maybe a bp?) 15:24:44 lrensing: Totally. :) 15:25:02 yeah - as they would need to be justified 15:25:02 so the list of what doesn't need a bp is "cleanup" refactors focused on a specific chart, and bugs (which are a separate thing) 15:25:16 ++ 15:25:26 yes 15:25:33 well that seemed easy :) 15:25:54 what about documentation and blueprints 15:25:57 so shall we try and enforce, no merge unless we have met this criteria? 15:26:32 i think when approving the pb, it should require that it includes docs/tests as part of the scope as required 15:26:43 that is talking about the bottom layer, we haven't discussed the workflow operations of blueprints themselves which at this moment do not appear to be exercised 15:26:47 accepted, assigned, so on 15:26:49 so its not marked as compete until thats done 15:26:58 not only must a bp exist, but it should be accepted to merge commits from 15:27:06 if a traditional workflow is being followed 15:27:19 good point, at the moment most people seem to be creating and self approving 15:27:26 yeah alanmeadows we're getting ahead of ourselves slightly :) 15:27:46 there needs to be a bp grooming process 15:27:50 its basically roadmap enforcement 15:27:52 at the bp level 15:28:06 and so sorry for mentioning the word grooming 15:28:16 right - so should we make this part of the meeting - a section for bp reviews 15:29:07 i am fine with that 15:29:36 if it becomes too much of a timesink we can address it then 15:30:31 ok - so this week - can we go over all the existing bp's and get them in shape? 15:31:00 theres 24 currently so not too much of a task for a quick vetting: https://blueprints.launchpad.net/openstack-helm 15:31:39 and then we should create pb's for all the appropriate ps's we have in flight (probably mostly looking at myself here...) 15:32:07 you are the root of many issues 15:32:40 let's dive into it then 15:34:14 nice - dulek would be great to get your input on the ones out there as well 15:35:35 portdirect: Sure thing, although I don't think I'll be opposed to any of the BP. 15:35:49 we done on this topic for now? 15:37:05 ok - so I've got one more thing I want to mention 15:37:35 I'm hoping that we should have a ceph based deploy running in the three node check by eod 15:37:44 ^^ I'll even make a bp for it :D 15:38:04 i'll hold you to it portdirect 15:38:15 \o/ 15:38:23 lolz 15:38:31 and would really like to get the linter moving to a voting gate - as its been very stable 15:39:16 so - with that I've run out of steam :) 15:39:20 https://cdn.meme.am/instances/400x/55368412.jpg 15:39:26 any other things people would like to bring up 15:39:42 you knows it alanmeadows :) 15:39:58 I was wondering if there is anything obvious for a newb to work on 15:41:42 serverascode: theres a lot of potential areas :) and it would be awesome to get more hands on the deck. docs are an obvious 1st place (as most of us are too deep int the woods to offer a proper outside perspective) 15:42:04 but do you have any areas that interest you or you've worked on before? 15:42:40 no not particularly, but I can poke around at docs and see if there is anything I can contribute there 15:42:55 off the top of my head, getting assiatnce expanding the 'helm test' stuff from glance and keystone to other charts would be super valuble 15:43:23 ok, I can take a look into that as well 15:44:37 what is the mandate for things exercised in these rally launched tests 15:44:42 What is a test that is "too long" 15:44:46 or "overkill" 15:45:03 how are the ones there chosen 15:45:05 there is a default timeout of 300s in helm for the enire test to run 15:45:24 and how would someone else examine a list to do their own choosing 15:45:35 of candidates for inclusion 15:46:12 the ones chosen (to date) have been those that exercise only that service and any immediate dependencies 15:46:37 as we should have a sperate rally chart that does comprehestive testing 15:46:49 jayahn has a pb for tempest based tests 15:47:52 personally I'd like to see: rally (driving tempest) where possible, falling back to tempest when not, and finally basic functioal tests via the cli when even thats not avalible for a service 15:48:06 yes but to the point serverascode is asking, how would a new entrant build such a list for another chart, say nova 15:48:29 the framework is clear, the process foe electing tests to go into the rally yaml, not so clear 15:48:47 ah - i see your point 15:49:05 a good set of tests can be obtained from here for a service: https://github.com/openstack/rally/tree/0.8.1/samples/tasks/scenarios/nova 15:49:17 that was where I was going 15:49:53 and some judgement will be needed, as for example this: https://github.com/openstack/rally/blob/0.8.1/samples/tasks/scenarios/nova/create-and-delete-network.yaml 15:50:10 would not be approprate as it rely on novanetwork being used 15:51:09 also I've been setting the runner and sla to just exercise the service, not make it sweat: https://github.com/openstack/openstack-helm/blob/master/keystone/templates/etc/_rally_tests.yaml.tpl#L7-L13 15:51:34 ^^ and theres a terminology oxymoron :) 15:51:44 I sense a need for the test framework to have some documentation including these details 15:52:16 otherwise contributions on this front will be challenging, and we need contributions here 15:53:03 right - I'll put together a doc asap 15:53:26 * portdirect mumbles about being caught by his own edicts 15:53:50 :) 15:54:24 anything else to discuss? i think we covered the big points 15:54:44 I'm good 15:54:45 otherwise i think we can wrap this up 15:55:07 \o 15:56:25 cool - so we good to close up? 15:57:05 #endmeeting OpenStack-Helm