15:01:33 <srwilkers> #startmeeting openstack-helm
15:01:34 <openstack> Meeting started Tue Jul 11 15:01:33 2017 UTC and is due to finish in 60 minutes.  The chair is srwilkers. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:37 <openstack> The meeting name has been set to 'openstack_helm'
15:01:38 <srwilkers> morning
15:01:59 <jayahn> morning
15:02:13 <portdirect> evening jayahn :)
15:02:15 <jayahn> and evening
15:02:17 <jayahn> :)
15:03:17 <srwilkers> hope everyone had a good holiday last week
15:03:27 <srwilkers> if you celebrated, that is
15:03:37 <srwilkers> heres the etherpad for today's agenda -- its noticeably sparse
15:03:49 <srwilkers> https://etherpad.openstack.org/p/openstack-helm-meeting-2017-07-11
15:04:30 <srwilkers> feel free to place anything you'd like to discuss today, as i imagine it'll mostly be an open discussion as we add to the list
15:07:01 <srwilkers> #topic Specs for OSH
15:07:30 <srwilkers> since this has a few items on the agenda, i wanted to bring this up and get opinions on the approach forward
15:08:04 <portdirect> I think specs makes sense for some things, eg logging, networking backends
15:08:13 <srwilkers> agreed
15:08:28 <portdirect> long as we keep it approprately scoped - and dont go into the world of process for processes sake
15:08:36 <srwilkers> ++
15:09:30 <lrensing> items that introduce a new paradigm should have a spec to discuss and gain community backing
15:09:34 <srwilkers> im really fond of the feedback mechanism it provides versus just seeking feedback in patchsets for things that make sense
15:09:39 <lrensing> that's my thought atleast
15:09:48 <v1k0d3n> ++ on that srwilkers
15:09:52 <jayahn> ++
15:09:57 <srwilkers> its easy to miss a patchset
15:10:05 <portdirect> though a spec would be in the form of a ps?
15:10:11 <portdirect> unless I'm missing something
15:10:19 <srwilkers> during drafting, sure
15:10:22 <mattmceuen> What types of scope would not be kicked off via a spec?
15:10:26 <srwilkers> but it still lives and persists in the repo
15:10:38 <srwilkers> something to point back to
15:10:55 <portdirect> roger - though by the time its merged its not a fb mechanism - but a mandate
15:11:05 <srwilkers> whatever you want to call it
15:11:16 <portdirect> an important distinction to note
15:11:22 <lrensing> with regards to the deliverable of a spec, should it just land in the repo as a doc?
15:11:34 <portdirect> lrensing: thats the normal approach
15:11:38 <srwilkers> yeah, we'll get a spec directory in teh repo
15:11:46 <srwilkers> and direct them there
15:11:51 <v1k0d3n> ++
15:12:39 <srwilkers> any other feedback here?
15:13:23 <mattmceuen> Question - what scope (other than bug fixes) would not be kicked off via a spec
15:13:27 <portdirect> mattmceuen: the types of things that would not require a spec - new services
15:13:38 <portdirect> though they may well be driven by the spec
15:13:49 <portdirect> eg you would not need a spec to add a fluentd chart
15:14:05 <portdirect> but for it to have value it should be writtent to follow a logging spec
15:15:08 <mattmceuen> ok
15:16:05 <srwilkers> #topic chart values format
15:16:15 <srwilkers> its a pretty good tie in to the next item
15:16:29 <srwilkers> floors yours lrensing
15:16:51 <v1k0d3n> is alanmeadows around by chance
15:18:04 <lrensing> so as the agenda says, there was a request for our charts to have a consistent values format across every service
15:18:07 <alanmeadows> I am here
15:18:24 <portdirect> we are 90% of the way there
15:18:37 <portdirect> though the keys are not in any standardised order
15:18:41 <lrensing> it's something we have always looked to keep consistent, and we've done a good job of doing misc refactors to make it consistent
15:19:29 <lrensing> but it would be great to define a preset values tree skeleton for all charts moving forward so that developers andn operators have a consistent experience between services
15:19:41 <portdirect> +1
15:19:45 <v1k0d3n> just as a thought here.
15:20:17 <v1k0d3n> wouldn't docs explain the consistent approach...meaning, does it really _have_ to be alphabetical?
15:20:22 <v1k0d3n> so my thoughts...
15:20:32 <alanmeadows> I thought one of the original goals was a document providing "a tutorial on a day in the life of constructing a chart"
15:21:06 <portdirect> ++
15:21:09 <alanmeadows> essentially a walk through on creating a fictitious chart from the ground up - "This chart relies on the blah service, so I am going to add these fields in values to ensure that its up before my application launches"
15:21:16 <alanmeadows> so on and so forth down the line
15:21:20 <v1k0d3n> some values are more commonly changed than others...like images, replica counts, etc. configs can ultimately be very large in custom installs, and it's nice having that towards the bottom.
15:21:47 <portdirect> v1k0d3n: if you could provide fb on my ps here it would be great: https://review.openstack.org/#/c/481964/
15:22:29 <portdirect> the devault values is just a reference - i dont think many people will be modifying them (though I may be wrong)
15:22:49 <v1k0d3n> i am going to, but wanted to discuss since the topic is open
15:22:53 <portdirect> hence why I felt that removing any subjectiveness was the best approach
15:23:21 <v1k0d3n> yeah, i see your point.
15:23:47 <v1k0d3n> i'm not wildly opposed to it...just that the docs reflect positioning already.
15:24:30 <portdirect> i dont think they do?
15:24:44 <v1k0d3n> so it's going to be a lot of work and PS for little value in the end other than aesthetics. it seems to put aesthetics over function.
15:25:03 <portdirect> they ref the sections - but now how they are potitioned relative to each other in the default values.yaml
15:25:45 <v1k0d3n> the sections where sort of in like to positioning at one point...may not be as much now. but that's not my main point anyway.
15:26:19 <portdirect> just takes 5 seconds to sort a yaml tree - though it takes a lot longer to manually earch for a section (say network) when they are in a diff place for each service
15:26:56 <portdirect> so whatever method we settle on - i really think there should be a uniform standard across all charts
15:28:37 <mattmceuen> agree.  both approaches make sense.  So I guess it's a little bit of an open question how frequently people will actually modify the values yaml.  How frequently do you think folks will refer to it?  Would a logical (aesthetically pleasing) order be handy for that?
15:29:41 <srwilkers> i think having a uniform standard is the goal, regardless of how it's all ordered.  maybe there'd be value in getting someone whos working on getting up to speed with our charts to take this on and identify what makes it easier from their perspective. maybe alraddarla?
15:29:56 <v1k0d3n> a standard would be really great.
15:30:00 <lrensing> i agree portdirect, this was an item that has been tossed around amongst the group for a long time and at the time of it's original inception, the values files didn't have much of a structure or consistency amongst them.  a lot of the work you've done with adding functions to helm toolkit has forced some structure across charts which is a good first step
15:30:36 <portdirect> yeah - we now have the same keys in each values.yaml - and I've kulled the dead ones
15:30:58 <portdirect> the only think left is putting those keys into some sort of order
15:31:15 <v1k0d3n> this is a good approach.
15:31:49 <v1k0d3n> i just like the sections to be in relation to some form of frequency or function over  alphabetical for aesthetics
15:32:09 <v1k0d3n> because aesthetics don't really matter honestly when we can make them whatever we want anyway :)
15:32:10 <portdirect> alphabetical is def not asthecticly pleasing
15:32:18 <v1k0d3n> :) true that.
15:32:50 <portdirect> i dont think i can express my logic any clearer than the commit message https://review.openstack.org/#/c/481964/
15:33:02 <v1k0d3n> i really, really like having replicaas and images towards the top...it's an instant eyeball snapshot of what the deployment looks like.
15:33:30 <v1k0d3n> you did. all good there man. i said my part so i'm good.
15:34:07 <srwilkers> the key takeaway is that theres consensus we'd like a standard -- thats a great start for me.  i think we can hammer down the specifics of what that looks like as we go
15:34:20 <srwilkers> but we should definitely leave feedback on portdirect's patchset
15:34:27 <v1k0d3n> ++
15:34:28 <srwilkers> and transition that to a spec at some point
15:34:35 <alraddarla> o/
15:34:39 <alraddarla> sorry im late
15:34:50 <portdirect> yeah - and larry has volunteered to write a spec :)
15:35:16 <v1k0d3n> sounds good. all comments on the ps/spec
15:35:26 <lrensing> and after today i expect a lot of discussion on it :)
15:36:00 <srwilkers> awesome.
15:36:06 <srwilkers> think we can move on then?
15:36:35 <srwilkers> #topic helm chart orchestrators
15:36:46 <srwilkers> all you portdirect
15:37:22 <portdirect> so we have a ps in flight: https://review.openstack.org/#/c/481234/
15:37:48 <portdirect> that should add an armada spec for a simple os-h deployment
15:38:32 <portdirect> once Tim and the crew have finished it - I'd like us to drop the two node gate and replace it it with another three node - but running armada
15:38:59 <v1k0d3n> huge  fan of this
15:39:27 <v1k0d3n> great to see it starting to be discussed.
15:40:13 <portdirect> yeah - After this meeting I'm gonna give them a hand trying to work thorugh some issues they have had
15:40:30 <jayahn> skt is currently using landscape to deploy full ha openstack. we promised to put our landscape setting to upstream repo, then we are having "re-visit to issue" discussion. (you can read etherpad for more detail)
15:41:01 <jayahn> landscaper.. not landscape..
15:41:02 <jayahn> anyway
15:41:11 <portdirect> yeah - would be great to get your experiences
15:41:30 <portdirect> theres aslo a few other tools I've heard noises about on the horizon
15:41:49 <srwilkers> yeah, thatd be great.  if there's long-term support there for it, id like to see that included as well.
15:42:00 <jayahn> yeah, i will do. long story short, when landscaper start influencing how developer test each individual chart, we really started discussing around its value.
15:42:29 <jayahn> and shortfalls
15:42:35 * portdirect sad face
15:43:10 <jayahn> probably my "upcoming" feedback will include how this deployment tool will affect "development" process, how it is influencing each other..
15:43:24 <jayahn> and love to get feedback on this issue from you guys as well
15:44:12 <srwilkers> of course.  we'd be happy to provide whatever we can
15:44:17 <portdirect> yeah - one of the reasons I've been pushing so hard for this recently is so we can ensure that armada works perfectly with os-h, while not limiting any other deployment method.
15:44:47 <portdirect> I'd really like to see support for gerrit PSes for one :D
15:45:22 <v1k0d3n> it would be nice to see something like armada end up in kubernetes incubator too.
15:45:55 <v1k0d3n> i know this isn't exactly the place for this topic, but it's something that was discussed a while back. although...to that point...several options were discussed including putting it in OS.
15:46:45 <v1k0d3n> i think though, to your point portdirect putting it over the fence to kubernetes may be a nice way to show the projects working together (OSH in OS, and a tool that can deploy it in kube-incubation).
15:46:59 <srwilkers> yeah, would be nice to see it land somewhere.  at least showing what it's capable of in a three node gate would be a solid first step to that end i think
15:47:25 <v1k0d3n> good point. agreed.
15:47:31 <v1k0d3n> nice way to test the stack
15:47:36 <srwilkers> #topic logging/monitoring
15:47:38 <portdirect> srwilkers: ++
15:48:04 <srwilkers> i threw this up.  similar to the chart values format, i plan on getting a spec in flight today for the logging and monitoring approach for OSH
15:48:18 <srwilkers> have been working on it over a week or so, and would be nice to get it up for some proper feedback/discussions
15:48:36 <portdirect> srwilkers: the sooner the better :D
15:48:50 <srwilkers> portdirect: yep
15:49:18 <portdirect> would really help when it comes to working out what we need to do
15:49:41 <portdirect> from both an output sense, but also what we can do with that output
15:50:05 <portdirect> once we have a spec in draft I would be great to get input from as many sources as possible
15:50:37 <portdirect> jayahn, v1k0d3n  and our ondercloud team should really get pulled in as much as poss
15:50:43 <portdirect> *undercloud
15:50:48 <alanmeadows> The aspect that is currently missing is tieing it all together--putting on an operations hat and saying yes, what happens out of the box has what I need in terms of visibility
15:51:00 <portdirect> ++
15:51:07 <alanmeadows> The building blocks are coming together
15:51:27 <srwilkers> alanmeadows: i agree.  the operations hat is one i dont have much experience with thus far
15:51:50 <alanmeadows> What we can do is dedicated a part of the spec to some use cases
15:52:08 <alanmeadows> and extract these from our own operations folks, i.e. what is it they are trying to see, and manually fetch today
15:52:37 <alanmeadows> and make sure that our out-of-the-box views account for these
15:53:10 <jayahn> alanmeadows: ++
15:54:00 <srwilkers> yep, works for me
15:54:07 <alanmeadows> same thing for alarming, we can assemble what we're currently monitoring today, that can drive what prometheus alarms can potentially do again out of the box
15:54:11 <alanmeadows> at least as a starting place
15:54:47 <jayahn> that would be really good value we can collect together.
15:55:12 <v1k0d3n> agreed
15:55:37 <alanmeadows> We may want to split it up into two specs, one would be more platform/foundational (where I think you are thinking Steve) - another would be what default behavior we inject into this Logging-Monitoring-Alerting platform to provide value to real operators?
15:56:18 <v1k0d3n> starting to gather requirements for our ops team and would like to share thoughts once i get more settled in. these past coupleof weeks have been crazy.
15:57:05 <srwilkers> alanmeadows: i think that would make more sense the more i think about it
15:57:35 <alanmeadows> they obviously play together, as the platform needs to support the injection of said operator needs
15:57:53 <alanmeadows> in either case just throwing that idea out there
15:58:58 <alraddarla> +1 alanmeadows
15:59:06 <srwilkers> works for me.  ill get them started today and call attention to them once they're in
15:59:50 <srwilkers> ill go ahead and wrap up since we're hitting time
16:00:00 <srwilkers> we can carry anything else over to openstack-helm
16:00:06 <srwilkers> #endmeeting