15:02:56 <srwilkers> #startmeeting OpenStack-Helm
15:02:57 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:00 <openstack> The meeting name has been set to 'openstack_helm'
15:03:07 <srwilkers> hey good morning everyone
15:03:11 <srwilkers> thanks for joining
15:03:14 <v1k0d3n> o/
15:03:18 <alraddarla> o/
15:03:28 <serverascode> o/
15:03:30 <gardlt> o/
15:03:59 <dulek> o/
15:04:15 <lrensing> o/
15:04:26 <srwilkers> 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 <lamt> o/
15:04:58 <alanmeadows> \o
15:05:23 <v1k0d3n> alanmeadows: just have to be different with that right-handed wave.
15:05:36 <srwilkers> look at alanmeadows, leading change
15:05:51 <srwilkers> first thing i wanted to chat about was our list of bugs on launchpad: https://bugs.launchpad.net/openstack-helm
15:06:28 <srwilkers> 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 <v1k0d3n> 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 <srwilkers> haha
15:07:36 <alanmeadows> im virtually ambidextrous
15:07:43 <v1k0d3n> leakypipes would  appreciate that one.
15:08:13 <alanmeadows> srwilkers: I think the list is a good start, I think at the moment it is unrepresentative of the known issues
15:08:23 <srwilkers> alanmeadows, agreed
15:08:46 <v1k0d3n> +1
15:09:04 <alanmeadows> 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 <srwilkers> the call to action is for anyone reporting behavior they expect is a bug should file a bug in launchpad
15:09:55 <alanmeadows> 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 <srwilkers> the drivers team should then triage it and verify it's an issue and prioritize it
15:10:32 <alanmeadows> I will admit I haven't gone through the process yet to see what information launchpad asks for
15:10:37 <alanmeadows> for this project
15:10:41 <lrensing> i don't think we do alanmeadows
15:10:43 <v1k0d3n> docs need this alanmeadows
15:10:45 <srwilkers> alanmeadows, i believe there's openstack documentation for filing bugs or issues, let me check
15:11:02 <v1k0d3n> 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 <srwilkers> https://wiki.openstack.org/wiki/Bugs#Reporting is a good spot to start, albeit the links are for the core projects
15:11:48 <srwilkers> but we can also provide a tl;dr for filing bugs
15:12:56 <alanmeadows> sure, but likely we want details such as kubernetes versions, kubelet versions
15:13:13 <alanmeadows> perhaps offering and suggesting something similar to the gate "dump it all" scripts
15:13:27 <portdirect> ++
15:13:34 <srwilkers> that sounds reasonable to me
15:14:21 <portdirect> 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 <alanmeadows> 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 <srwilkers> yeah, that helps reduce the overhead associated with triaging and trying to pin down exactly where the issues may have started.
15:15:19 <lrensing> ++
15:17:06 <alanmeadows> 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 <portdirect> 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 <portdirect> where they attach the payload is anther question though :D
15:17:54 <srwilkers> portdirect, alanmeadows yep. i think it's reasonable to get that done fairly quickly
15:18:02 <srwilkers> portdirect, ill let you take it from here for a bit
15:18:40 <srwilkers> im off to another meeting
15:18:53 * portdirect glares around room
15:19:14 <portdirect> suppose we should also discuss blueprints?
15:19:49 <portdirect> 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 <portdirect> i know srwilkers has also been taking to infra about getting the link between launchpad and gerrit running smooth
15:21:10 <lrensing> yeah we need to be more diligent about referencing blueprints in our patchsets
15:21:40 <portdirect> I think perhaps we should come to some agreement about what needs a bp
15:21:43 <alanmeadows> to be clear, part of the problem is not only linking
15:21:48 <alanmeadows> the bp to link to is missing as well
15:21:54 <lrensing> most definitely alanmeadows
15:21:58 <portdirect> :)
15:22:18 <portdirect> so, if its a new feature it needs a bp (i think we can all agree here)
15:22:21 <lrensing> but to pete's point, how do we determine the scope required for a bp
15:22:26 <lrensing> yes
15:23:07 <portdirect> 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 <portdirect> which may touch on sveral charts/areas
15:23:51 <dulek> I guess any new feature needs a blueprint that will explain the motivation.
15:24:04 <dulek> Fixes and minor refactors won't need blueprints.
15:24:10 <portdirect> agreed
15:24:15 <dulek> I think that's the simplest classification you can get.
15:24:22 <dulek> And in doubt - ask the core team. :)
15:24:33 <lrensing> right - to that i'd like to say that project-wide refactors should be given more attention (maybe a bp?)
15:24:44 <dulek> lrensing: Totally. :)
15:25:02 <portdirect> yeah - as they would need to be justified
15:25:02 <alanmeadows> 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 <portdirect> ++
15:25:26 <lrensing> yes
15:25:33 <portdirect> well that seemed easy :)
15:25:54 <lrensing> what about documentation and blueprints
15:25:57 <portdirect> so shall we try and enforce, no merge unless we have met this criteria?
15:26:32 <portdirect> i think when approving the pb, it should require that it includes docs/tests as part of the scope as required
15:26:43 <alanmeadows> 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 <alanmeadows> accepted, assigned, so on
15:26:49 <portdirect> so its not marked as compete until thats done
15:26:58 <alanmeadows> not only must a bp exist, but it should be accepted to merge commits from
15:27:06 <alanmeadows> if a traditional workflow is being followed
15:27:19 <portdirect> good point, at the moment most people seem to be creating and self approving
15:27:26 <lrensing> yeah alanmeadows we're getting ahead of ourselves slightly :)
15:27:46 <alanmeadows> there needs to be a bp grooming process
15:27:50 <alanmeadows> its basically roadmap enforcement
15:27:52 <alanmeadows> at the bp level
15:28:06 <alanmeadows> and so sorry for mentioning the word grooming
15:28:16 <portdirect> right - so should we make this part of the meeting  - a section for bp reviews
15:29:07 <lrensing> i am fine with that
15:29:36 <lrensing> if it becomes too much of a timesink we can address it then
15:30:31 <portdirect> ok - so this week - can we go over all the existing bp's and get them in shape?
15:31:00 <portdirect> theres 24 currently so not too much of a task for a quick vetting: https://blueprints.launchpad.net/openstack-helm
15:31:39 <portdirect> 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 <alanmeadows> you are the root of many issues
15:32:40 <lrensing> let's dive into it then
15:34:14 <portdirect> nice - dulek would be great to get your input on the ones out there as well
15:35:35 <dulek> portdirect: Sure thing, although I don't think I'll be opposed to any of the BP.
15:35:49 <portdirect> we done on this topic for now?
15:37:05 <portdirect> ok - so I've got one more thing I want to mention
15:37:35 <portdirect> I'm hoping that we should have a ceph based deploy running in the three node check by eod
15:37:44 <portdirect> ^^ I'll even make a bp for it :D
15:38:04 <lrensing> i'll hold you to it portdirect
15:38:15 <dulek> \o/
15:38:23 <alraddarla> lolz
15:38:31 <portdirect> and would really like to get the linter moving to a voting gate - as its been very stable
15:39:16 <portdirect> so - with that I've run out of steam :)
15:39:20 <alanmeadows> https://cdn.meme.am/instances/400x/55368412.jpg
15:39:26 <portdirect> any other things people would like to bring up
15:39:42 <portdirect> you knows it alanmeadows  :)
15:39:58 <serverascode> I was wondering if there is anything obvious for a newb to work on
15:41:42 <portdirect> 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 <portdirect> but do you have any areas that interest you or you've worked on before?
15:42:40 <serverascode> no not particularly, but I can poke around at docs and see if there is anything I can contribute there
15:42:55 <portdirect> 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 <serverascode> ok, I can take a look into that as well
15:44:37 <alanmeadows> what is the mandate for things exercised in these rally launched tests
15:44:42 <alanmeadows> What is a test that is "too long"
15:44:46 <alanmeadows> or "overkill"
15:45:03 <alanmeadows> how are the ones there chosen
15:45:05 <portdirect> there is a default timeout of 300s in helm for the enire test to run
15:45:24 <alanmeadows> and how would someone else examine a list to do their own choosing
15:45:35 <alanmeadows> of candidates for inclusion
15:46:12 <portdirect> the ones chosen (to date) have been those that exercise only that service and any immediate dependencies
15:46:37 <portdirect> as we should have a sperate rally chart that does comprehestive testing
15:46:49 <portdirect> jayahn has a pb for tempest based tests
15:47:52 <portdirect> 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 <alanmeadows> 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 <alanmeadows> the framework is clear, the process foe electing tests to go into the rally yaml, not so clear
15:48:47 <portdirect> ah - i see your point
15:49:05 <portdirect> 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 <alanmeadows> that was where I was going
15:49:53 <portdirect> 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 <portdirect> would not be approprate as it rely on novanetwork being used
15:51:09 <portdirect> 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 <portdirect> ^^ and theres a terminology oxymoron :)
15:51:44 <alanmeadows> I sense a need for the test framework to have some documentation including these details
15:52:16 <alanmeadows> otherwise contributions on this front will be challenging, and we need contributions here
15:53:03 <portdirect> right - I'll put together a doc asap
15:53:26 * portdirect mumbles about being caught by his own edicts
15:53:50 <alanmeadows> :)
15:54:24 <lrensing> anything else to discuss? i think we covered the big points
15:54:44 <portdirect> I'm good
15:54:45 <lrensing> otherwise i think we can wrap this up
15:55:07 <alraddarla> \o
15:56:25 <portdirect> cool - so we good to close up?
15:57:05 <srwilkers> #endmeeting OpenStack-Helm