15:00:44 <mattmceuen> #startmeeting openstack-helm
15:00:45 <openstack> Meeting started Tue Dec 19 15:00:44 2017 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:48 <mattmceuen> #topic rollcall
15:00:48 <openstack> The meeting name has been set to 'openstack_helm'
15:01:02 <mattmceuen> GM/GE all!
15:01:06 <raymaika> o/
15:01:06 <portdirect> o/
15:01:08 <daveKormann> hihi!
15:01:24 <v1k0d3n> here.
15:01:32 <mattmceuen> all your awesome agenda topics go here -> https://etherpad.openstack.org/p/openstack-helm-meeting-2017-12-19
15:01:45 <gmmaha> o/
15:01:49 <srwilkers> o/
15:02:35 <alanmeadows> o/
15:03:30 <mattmceuen> Not bad for the week before christmas :)
15:03:42 <daveKormann> it's next week that'll be the real litmus test.
15:04:09 <icolwell> o/
15:04:27 <mattmceuen> #topic holistic etcd approach
15:04:44 <mattmceuen> This was a holdover from last week, and I just wanted to make sure we rounded out the conversation and didn't leave any points hanging
15:05:15 <mattmceuen> To refresh our memory:
15:05:15 <mattmceuen> Various charts trying to use etcd, can we (and should we) unify an approach, or let etcds sprinkle the cloud?
15:05:15 <mattmceuen> e.g. https://review.openstack.org/#/c/525752/
15:05:15 <mattmceuen> Rabbit would likely follow in approach at some point
15:05:15 <mattmceuen> Calico ....
15:05:16 <mattmceuen> ...
15:05:43 <mattmceuen> (there were general good feelings around this notion last week)
15:06:20 <portdirect> we need a real etcd chart
15:06:31 <portdirect> the one we have today is useful - but essentially a toy
15:06:52 <daveKormann> dumb question: ceph doesn't currently make any use of etcd; would it make any sense for things like pool and topology things to go there?
15:06:52 <v1k0d3n> ++
15:07:08 <portdirect> daveKormann: I dont think there is a need for that
15:07:11 <daveKormann> kk
15:07:18 <tlam_> o/
15:07:22 <srwilkers> a real etcd chart would be nice for things like mistral, where etcd can be used as a backend.  would be nice to have a standard approach for using etcd instead of just random disjoint etcds everywhere
15:07:31 <portdirect> we should be able to model that via values, and get the info we need from the lma stack
15:07:50 <daveKormann> yah, was mostly thinking about the stuff that might change post-deployment
15:07:57 <daveKormann> ie, pools.
15:08:06 <portdirect> that should be a chart update really
15:08:15 <daveKormann> but yeah, probably unnecessary and fair point about chart updates.
15:08:45 <portdirect> we should also revisit the etcd operator
15:08:52 <v1k0d3n> ++ :)
15:09:04 <portdirect> before embarking on 'building from sratch'
15:09:09 <mattmceuen> we probably need a good spec to gather ideas for said etcd, to ensure it's general enough to fit the bill for all interested consumers.
15:09:17 <v1k0d3n> etcd operator is actually pretty solid.
15:09:22 <portdirect> i think it would make sense to do a spec here - were we can weigh the pros and cons?
15:09:30 <mattmceuen> +1
15:09:32 <v1k0d3n> +1
15:10:12 <mattmceuen> and make sure we add the folks we know in the etcd chart consumer/creator world as reviewers
15:10:42 <mattmceuen> volunteer for the spec effort?
15:11:26 <portdirect> I could strawman, but would not have time before mid jan to work on it in depth.
15:11:51 <mattmceuen> #action team to create a spec for a general-purpose etcd chart, portdirect to put out a strawman to facilitate conversation
15:12:22 <mattmceuen> that would be awesome portdirect.  I think just having it out there is a good first step and we can build from there.  Maybe referencing out to prior etc art so folks can find it.
15:13:07 <mattmceuen> Any other points on the etcd front before we move on?
15:13:30 <mattmceuen> #topic RBAC rework (lamt)
15:13:38 <mattmceuen> Go for it tlam_ !
15:13:51 <mattmceuen> https://review.openstack.org/#/c/526464/
15:14:00 <portdirect> is tlam_ here?
15:14:24 <mattmceuen> he o/ 'd us
15:14:35 <v1k0d3n> i see lamt
15:14:38 <tlam_> I am here
15:14:46 <v1k0d3n> lol
15:14:47 <tlam_> on a smurf
15:15:16 <portdirect> can you give us a rundown of your rbac work?
15:15:21 <tlam_> I would like some eyes on that patch set that does a few things
15:15:28 <tlam_> portdirect,  sure
15:16:22 <tlam_> 1. it addresses the issue where some injected SA and its associated resources from lingering when the chart is deleted
15:17:16 <tlam_> 2. it now dynamically (don't like that word, but..) generate the role and binding in the proper namespaces
15:17:39 <tlam_> as well as provide read only access to the resources it needs
15:17:49 <tlam_> to enforce the concept of least-priv
15:18:46 <tlam_> 3. the PS also starts to move things from clusterrole -> role as part of the effort to remove naming collision
15:19:03 <portdirect> thats awesome tin
15:19:11 <portdirect> really moves us forward there
15:19:37 <tlam_> portdirect, thx, would really like feedback on that PS
15:19:43 <v1k0d3n> yeah, great job.
15:19:43 <mattmceuen> yeah that's fantastic - thanks for doing that work Tin, will take a look
15:19:52 <portdirect> removing the hack to mount a service account and then graning an amdin readonly role is a bit win :D
15:19:55 <portdirect> *granting
15:20:04 <portdirect> tlam_: dont worry - I'm hammering it right now ;)
15:20:10 <v1k0d3n> tin, are you getting much feedback from sean and the team in CSO where you're at?
15:20:23 <v1k0d3n> i'm looking forward to seeing their feedback on PS like this.
15:20:42 <v1k0d3n> i'm discussing with Dan Solero too...just to make sure there are eyes there to help out.
15:20:55 <tlam_> most of them are on vacation :)  I will send a note out though
15:21:02 <tlam_> for all sec-related PS so they are aware
15:21:04 <v1k0d3n> lol sounds like the team i know.
15:21:10 <v1k0d3n> that would be great. let me know if i can help?
15:21:18 <v1k0d3n> i know the desire is there for sure.
15:21:48 <tlam_> least priv is one of those things they like, so I am sure they'd like it
15:22:04 <portdirect> they are also involved in the design ;)
15:22:45 <mattmceuen> Sounds excellent - let's get some solid feedback on that PS guys
15:22:52 <mattmceuen> Thanks tlam_ !
15:23:02 <mattmceuen> #topic Ceph pod-per-OSD/device support
15:23:02 <v1k0d3n> +!
15:23:13 <daveKormann> all right then.
15:23:34 <daveKormann> so, gmmaha and i have been working on this.
15:24:02 <daveKormann> we had a previous patchset to support a ceph OSD device and pod-per-osd model
15:24:15 <daveKormann> but after feedback from portdirect we've rebooted.
15:24:37 <daveKormann> the patchset i put in the etherpad is the replacement:
15:24:41 <daveKormann> https://review.openstack.org/#/c/527505/
15:24:57 <portdirect> daveKormann: can we align this with rootfs
15:25:06 <portdirect> and the rest of the ceph-helm folks
15:25:25 <portdirect> so that we can move to deprecate our ceph chart asap
15:25:27 <daveKormann> yeah, definitely.  i went and looked at what ceph-helm had and when i looked it seemed to be approximately what the previous OSH patch had
15:25:49 <daveKormann> we're still very close to that in model, but i've reworked the scripts.  i'll pursue unifying the two
15:25:58 <portdirect> that would be awesome
15:26:01 <daveKormann> most of the work, though, is in the gate test stuff
15:26:06 <daveKormann> which now has its own playbook
15:26:11 <portdirect> I'm about to make a ps over there t remove helm-toolkit
15:26:21 <portdirect> and simplify the chart, removing all openstack specific things
15:26:25 <daveKormann> kewl
15:26:35 <gmmaha> portdirect: that is awesome
15:27:04 <daveKormann> i don't think we're QUITE ready for reviews on our new ps until we work to unify it with the ceph-helm side
15:27:21 <daveKormann> but it wouldn't hurt to have input particularly on the test design
15:27:21 <mattmceuen> daveKorman - also, just to make sure you're looped in on the convo we had last week which also touched on the ceph long-term plan -- logs from last week http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-12-15.00.log.html  (search for ceph :)  )
15:27:32 <gmmaha> portdirect: daveKormann: are we merging the two beforfe the patch or post?
15:27:35 <portdirect> also - do you peeps want a hand with getting a gate env up and running?
15:27:39 <gmmaha> or we just align the patch so that it is easy to merge
15:27:49 <portdirect> I think that depends on the ci/cd we can get in place
15:28:35 <gmmaha> portdirect: i see. alright
15:28:38 <mattmceuen> @gmmaha -
15:28:39 <mattmceuen> 15:44:15 <portdirect> 1) Split Keystone endpoint creation out of the ceph chart and into its own thing (that would live in OSH)
15:28:39 <mattmceuen> 15:44:15 <portdirect> 2) Merge the healthchecks from OSH into Ceph-Helm
15:28:39 <mattmceuen> 15:44:15 <portdirect> 3) Merge the luminous support from Ceph-Helm into OSH
15:28:39 <mattmceuen> 15:44:15 <portdirect> 4) Update the loopback device creation scripts from bash to ansible
15:28:39 <mattmceuen> 15:44:16 <portdirect> 5) Combine the disc targetting efforts from both OSH and Ceph-Helm into a single effort that brings the reliability of RH's approach with the OSD by bus-id from OSH
15:28:39 <mattmceuen> 15:44:16 <portdirect> 6) The Ceph-Helm chart will then be moved/mirrored to k8s/charts
15:28:40 <mattmceuen> 15:44:17 <portdirect> 7) At this point, add an OSH gates to experimentally use the Ceph-Helm chart
15:28:40 <mattmceuen> 15:44:17 <portdirect> 8) Once stabilised and we have confidence, depreciate the OSH ceph chart
15:28:41 <mattmceuen> 15:44:45 <portdirect> the order is obviously somewhat flexible - but as a general outline how does this seem?
15:28:44 <mattmceuen> (from last week ^)
15:28:53 <daveKormann> yeah, it would probably make sense for us to have a gate env.  most of the ridiculously high rev number on that patch is me wrestling with the differences between my ansible and the osh one
15:29:12 <portdirect> cool - I'll prioritise that
15:29:15 <daveKormann> 4 i think is the bulk of what we've done here.
15:29:19 <gmmaha> mattmceuen: thanks.. (kicking myself for not reading it properly)
15:29:33 <portdirect> so we have some devices that survive a reboot in a vm :)
15:29:38 <mattmceuen> no worries gmmaha :)
15:29:53 <daveKormann> we've definitely got that now, and i've rewritten the zap: support so it can be used again
15:30:34 <daveKormann> previously, enabling "zap" broke pod/node restart.  now it does all kinds of sanity checking to only zap a foreign disk
15:30:49 <daveKormann> sounds like that's one of those things we need to work on merging with ceph-helm
15:31:01 <daveKormann> is rootfs the best contact for that?
15:31:57 <portdirect> daveKormann: I'd say so
15:32:04 <daveKormann> great.  i'll hit him up.
15:32:19 <gmmaha> the current state of the PS will fail dev-deploy unless we add new flags for the ceph-osd to use a directory based backend. I am trying to hack the daemonset-osd to fllback to the current default directory based osd but my helm hackery is not that great (just yet). Wanted to get the pulse of the community here. We ok with adding new flags or would we prefer to stick to ceph-osd=enabled and have it all work under that
15:33:19 <gmmaha> that is the one place i am sorta stuck at and trying to figure it out
15:34:33 <daveKormann> that's likely another place we should coordinate with ceph-helm, since presumably they also want a unified model for directories/device-backed OSDs
15:35:43 <gmmaha> definitely..
15:36:15 <gmmaha> i will take the general silence as we are alright eitheways as long as ceph-helm folks & us are unified ont hat
15:36:16 <gmmaha> :)
15:36:53 <mattmceuen> +1 on that :)
15:37:01 <portdirect> silence is tantamount to agreement on irc :D
15:37:21 <gmmaha> :D
15:37:26 <mattmceuen> Next topic:
15:37:35 <mattmceuen> #topic roadmap to v 1.0 OSH
15:37:45 <mattmceuen> v1k0d3n it's all yours
15:38:09 <v1k0d3n> hey all. from outside looking in, so many good things/improvements are being added.
15:38:18 <portdirect> you are a cor you know ;)
15:38:20 <portdirect> *core
15:38:36 <v1k0d3n> haven't forgotten.
15:38:43 <v1k0d3n> but that's a sidenote? lol
15:39:23 <v1k0d3n> wondering for community eyes on the project where we're defining completion for a v1.0.0 roadmap?
15:39:33 <v1k0d3n> version information targets, etc.
15:39:56 <mattmceuen> One convo from a couple months back had some criteria along those lines:  http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-10-31-15.00.log.html
15:40:04 <mattmceuen> (search for newton)
15:40:19 <mattmceuen> 15:14:36 <portdirect> 1) support node/cluster reboot fully
15:40:19 <mattmceuen> 15:14:56 <portdirect> 2) get the charts in correct repos
15:40:19 <mattmceuen> 15:15:18 <portdirect> 3) get voting gates
15:40:22 <srwilkers> yeah, i feel like we've revisited this topic more than a few times
15:40:33 <v1k0d3n> we have.
15:41:04 <v1k0d3n> so should i give my leadership this link to evesdrop?
15:41:22 <srwilkers> are you asking for a firm declaration of a date?
15:41:30 <v1k0d3n> not at all.
15:41:43 <portdirect> I dont think the critieria have changed
15:41:47 <srwilkers> because those three points above are still the requirements and have been discussed openly.  they represent the majority of the work that's been done lately
15:42:02 <v1k0d3n> what version of kubernetes, etcd, etc?
15:42:06 <portdirect> and we are moving full steam ahead to try and achive that
15:42:12 <v1k0d3n> is this not a good idea to document in the repo somewhere?
15:42:16 <portdirect> thats same as it always has been
15:42:35 <portdirect> the current release of k8s etc at the time of release
15:42:36 <mattmceuen> v1k0d3n I agree it's a good thing to document outside of the etherpad
15:42:40 <portdirect> so 1.9.0 here
15:42:42 <v1k0d3n> nobody thinks it's a bit unclear for new-comers to the project?
15:42:43 <portdirect> at the moment
15:42:51 <portdirect> unless it takes us three months to get there
15:42:54 <srwilkers> in a previous meeting, the versions we actively support for openstack-helm will be what's gated against
15:42:55 <mattmceuen> Is this a good thing for a spec, or is this more a wiki type animal?
15:42:57 <portdirect> in which case 1.10 ;)
15:43:11 <srwilkers> sorry, we agreed in a previous meeting that the version we support will be what we gate against
15:43:12 <portdirect> a wiki - as its flexible
15:43:19 <srwilkers> ^
15:43:24 <portdirect> i think referenced in the docs is where to go
15:43:32 <portdirect> and that should also be fully gated
15:43:40 <portdirect> just as we have done with the aio guide
15:43:40 <mattmceuen> yeah, I think to v1k0d3n's point, this is less about making decisions, and more about communicating them
15:43:41 <v1k0d3n> target? or current? there's a difference.
15:43:45 <portdirect> we need to gate all the docs
15:43:53 <v1k0d3n> yes, communicating target for v1.
15:44:13 <portdirect> the target is the current release at the point of our release.
15:44:22 <v1k0d3n> not worried about current. since we don't have a branch/tagged release yet...giving users a guide is helpful. it also is a call to action.
15:44:28 <portdirect> for all upstream components, etcd, k8s etc
15:45:47 <srwilkers> i dont see how listing a target of release versions equates to a call to action
15:46:00 <v1k0d3n> what i'm referring to isn't uncommon at all. especially for a core to bring it up.
15:46:13 <v1k0d3n> targets give the community eyes on patterns of intent.
15:46:31 <v1k0d3n> if there's no work done, but it's listed as a target...then they can help pick up that work.
15:46:38 <v1k0d3n> https://github.com/kubernetes/kubernetes/milestones/
15:46:54 <v1k0d3n> ^^ great example of what other projects do, and what i'm referring to.
15:47:21 <srwilkers> after we cut a 1.0 release, that would be more feasible
15:47:36 <srwilkers> i dont think setting arbitrary milestones before then is very helpful to getting us there
15:47:53 <mattmceuen> I'm good with specifying the target versions of key dependencies, as long as they're malleable until the actual release, to reflect reality
15:49:01 <mattmceuen> Yeah, we tried the milestone approach early in OSH history, and I don't think it bought us all that much
15:49:33 <alanmeadows> I think we're getting bogged down in targets, the main takeaway I get from this is we've been missing a LP or whatever equivalent of https://github.com/kubernetes/kubernetes/milestones/
15:50:03 <alanmeadows> a "clear" march towards a cut, or whatever the next target may be
15:50:09 <portdirect> mattmceuen: could you create a blueprint for the road to 1.0.0 ?
15:50:17 <portdirect> would that align with the above?
15:50:24 <mattmceuen> portdirect was already going to volunteer :)
15:50:28 <v1k0d3n> milestones help other companies/users buy in. that's a powerful tool to get more users.
15:50:41 <srwilkers> if it puts this issue to bed, i think that'd a good idea
15:51:07 <v1k0d3n> just trying to help. i don't want to put a thorn in anyone's side.
15:51:13 <mattmceuen> We're all aligned on the need to document a 1.0, and I think there's still more thought to be had into how granular to make targets post 1.0
15:52:02 <mattmceuen> #action mattmceuen to take a stab at leadership- and community-communicable targets for the initial stable OSH release
15:52:27 <mattmceuen> Thanks for bringing it up v1k0d3n, I think it's a good thing to get down in a concise way.
15:52:50 <mattmceuen> You keep the floor!
15:52:53 <v1k0d3n> let me know if i can help. i can rally folks around it with targets.
15:52:55 <mattmceuen> #topic blueprints in OSH
15:53:01 <v1k0d3n> sorry...not targets. milestones?
15:53:02 <mattmceuen> thanks v1k0d3n will do :)
15:55:25 <v1k0d3n> just reminder really to submit blueprints really.
15:55:53 <v1k0d3n> we submitted a blueprint for some work we hired ericsson to work on, but were told someone else had a lot of work towards the same chart.
15:56:12 <srwilkers> id like to point out that blueprint was filed friday during kubecon
15:56:15 <v1k0d3n> with blueprints, it can really save overlap on work, etc.
15:56:29 <srwilkers> only after i had chatted about working on ODL in my spare time
15:56:34 <v1k0d3n> right. giving enough time for anyone to submit their work.
15:56:45 <srwilkers> and it was just happenstance that we both had been working on said chart with no blueprint filed for it
15:56:54 <v1k0d3n> right.
15:57:06 <v1k0d3n> so we submitted a blueprint so anyone could pick it up.
15:57:21 <mattmceuen> v1k0d3n I don't think we've had a practice to submit blueprints, just specs, right?
15:57:33 <srwilkers> there's an assignee with a marked approver, and that blueprint was approved when i looked last
15:57:40 <srwilkers> that indicates someone had already been targeted for doing that work
15:57:51 <srwilkers> but the person who submitted the WIP wasnt the assignee
15:57:52 <mattmceuen> Re specs, from http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-05-15.00.log.html
15:57:52 <mattmceuen> 15:05:49 <mattmceuen> 1. when a change impacts multiple charts
15:57:52 <mattmceuen> 15:06:09 <mattmceuen> 2. when a change needs design feedback from the larger team prior to implementation
15:57:52 <mattmceuen> 15:06:24 <mattmceuen> 3. when a change does something substantially new that'll be modeled in other charts later
15:57:52 <mattmceuen> 15:07:06 <mattmceuen> The gist being:  write specs as a means to drive common understanding (think: useful documentation) and common direction (think: everyone's aligned)
15:57:54 <srwilkers> so this confuses me a bit
15:58:23 <v1k0d3n> sorry, what confuses you srwilkers?
15:59:00 <mattmceuen> executive decision
15:59:04 <mattmceuen> tabling this please.
15:59:12 <srwilkers> you claim you submitted a blueprint so anyone can pick up the work, but blueprint assignees  are expected to be the ones performing the work
15:59:32 <mattmceuen> this is good conversation, but for another venue.
15:59:59 <v1k0d3n> this is getting sideways. i thought there was an ask to submit blueprints.
16:00:07 <v1k0d3n> we didn't really want the overlap in work at all.
16:00:44 <portdirect> sounds like v1k0d3n's point is spot on
16:00:57 <portdirect> and before commencing on work a bp should be sumbitted
16:00:58 <mattmceuen> Yup I get it v1k0d3n, not saying blueprints are a bad topic
16:01:04 <mattmceuen> just a sore topic
16:01:04 <portdirect> the before is important..
16:01:21 <portdirect> but this should not be a hard req
16:01:23 <v1k0d3n> in this case it could've save a lot of money. i would've much rather had srwilkers work quite honestly.
16:01:34 <v1k0d3n> no. totally agree portdirect not a hard requirement.
16:01:42 <v1k0d3n> i don't want process to be heavy at all
16:02:10 <srwilkers> meetings over, let's clear this out and take whatevers left to OSH
16:02:10 <mattmceuen> we will reconvene this topic
16:02:57 <mattmceuen> Only one last topic
16:03:08 <mattmceuen> oops we're over time :)
16:03:12 <mattmceuen> #endmeeting