15:00:10 <portdirect> #startmeeting openstack-helm
15:00:11 <openstack> Meeting started Tue Jun 25 15:00:10 2019 UTC and is due to finish in 60 minutes.  The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:14 <openstack> The meeting name has been set to 'openstack_helm'
15:00:23 <portdirect> lets give it a few mins for people to arrive
15:00:28 <portdirect> agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-06-25
15:00:32 <portdirect> #topic rollcall
15:00:33 <evrardjp> o/
15:00:47 <srwilkers> o/
15:00:50 <dwalt> o/
15:00:55 <georgk> hi
15:02:06 <howell> o/
15:03:44 <mattmceuen> o/
15:03:52 <gagehugo> o/
15:04:36 <portdirect> ok lets begin :D
15:05:18 <portdirect> 1st its great to be back, the last couple of weeks have been hectic - so I'd really like to thank srwilkers and mattmceuen for holding the fort while i was away
15:05:25 <portdirect> #topic Release docs progress
15:05:38 <portdirect> I really owe you all an update on this
15:05:54 <jayahn> o/
15:06:05 <portdirect> I've been working through it at a technical level, based on the conversations and notes we have taken at the various ptgs
15:06:39 <portdirect> of which one of the primary points i have been looking for is where osh 'breaks'
15:07:10 <portdirect> in that we need to make a change beyond overrides to support a particular version of openstack
15:07:34 <portdirect> i suspect this may be it: https://review.opendev.org/#/c/666150/
15:08:20 <portdirect> though once we have a definative, it will be much easier to articulate the points around our proposed high level semver like versioning
15:08:47 <portdirect> and how a site would flow through both versions of osh, and versions of openstack releases
15:09:23 <evrardjp> not really sure to understand this
15:10:25 <portdirect> which aspect evrardjp ?
15:10:59 <evrardjp> I understand all the words separately, not together :)
15:11:24 <evrardjp> Do you mean you will not come up with a release versionning plan until 66150 is resolved?
15:11:41 <portdirect> ah - no
15:11:48 <evrardjp> Or do you mean that the helm charts not branched per release is problematic?
15:12:02 <evrardjp> Because this patch doesn't introduce extra conditionals
15:12:04 <portdirect> i think it provides a great example of the sort of thing our release versioning needs to solve for
15:12:09 <itxaka> o/
15:13:28 <evrardjp> portdirect: I would say "yes, I agree, that's our project' scope to deal with upgrades of helm charts to deal with new openstack changes"
15:13:32 <portdirect> eg - to avoid a rats nest of confditionals - we may want to say, when openstack uses this version of oslo middleware (as an example) - we want to increment the Y version of osh, deprecating support for old versions of openstack etc
15:14:03 <portdirect> evrardjp: i think the spec will make it clearer when articulated
15:14:10 <evrardjp> ok
15:14:31 <evrardjp> don't forget it's not only about versions of dependencies :)
15:14:33 <portdirect> the point you raise is exactly what we need to cover with the stament `how a site would flow through both versions of osh, and versions of openstack releases`
15:15:03 <evrardjp> yes, documentations and/or specs are missing in that regard
15:15:10 <cheng1> +1 for spec
15:15:53 <portdirect> will be up soo for sure
15:15:56 <portdirect> soon
15:16:05 <evrardjp> k
15:16:25 <evrardjp> the earlier it is up, the more time we have to discuss about ironing the details all together
15:16:39 <portdirect> another thing thats also been done to support this effort, is validation of openstack releases between ocata and rocky
15:16:43 <evrardjp> and I am told that devil is in the details
15:16:44 <evrardjp> :p
15:16:58 <portdirect> pike came in here: https://review.opendev.org/#/c/666936/
15:17:29 <portdirect> and queens just needs a few things to tidy it up: https://review.opendev.org/#/c/667205/
15:18:33 <portdirect> i hope to add rocky, and stein today
15:18:43 <evrardjp> to clarify state, will the current jobs be renamed to ocata?
15:18:52 <portdirect> yes
15:18:58 <evrardjp> good
15:19:27 <evrardjp> portdirect: we don't build stein images yet
15:19:32 <evrardjp> afaik
15:19:38 <evrardjp> but we could very easily
15:19:45 <portdirect> ++
15:19:47 <portdirect> if we ok to move on, i think this brings us neatly into the reworked values overrides for the gates/local dev?
15:20:01 <evrardjp> k
15:20:10 <evrardjp> sounds a logical next convo
15:20:17 <portdirect> #topic Simpler overrides
15:20:19 <itxaka> very cool, great to see it moving fast now portdirect!
15:20:28 <evrardjp> I still have some questions on the etherpad, might be worth explaining there
15:20:49 <portdirect> so the gate over-rides functionality we had was a great leap forward for us
15:21:13 <portdirect> in that it opened the door to testing multiple variations of config over-rides in the gates
15:21:25 <portdirect> though suffered from a few issues
15:21:47 <evrardjp> overlaps?
15:22:26 <portdirect> mainly that 1) it applied the over-rides ubiquitously to all charts (eg neurton over-rides applied to mariadb, or more worryingly nova), 2) was very hard to use locally for development
15:22:59 <evrardjp> agreed. That was done in a rush because you had something to rework the gates
15:23:04 <evrardjp> :p
15:23:24 <portdirect> so we worked on a bash script to allow the values args to be generated inline for chart deployment/upgrade
15:23:34 <portdirect> https://review.opendev.org/#/c/666958/
15:24:28 <portdirect> which is more easily portable, and provides clearer feedback as to what is being applied to charts, and how people can extend that
15:24:31 <portdirect> eg: http://logs.openstack.org/58/666958/25/check/openstack-helm-compute-kit-rocky-opensuse_15/b23ee1e/ara-report/result/1c47ceaa-6f27-4a36-b6e5-d1f1cc67c7c9/
15:25:21 <portdirect> the hardest thing here was making it work for both BSD and GNU utils ;D
15:25:33 <evrardjp> I welcome the change generally, but I know this will break some of our toolings
15:26:20 <portdirect> i validated against all our gates, i hope nothing breaks - what did i miss?
15:26:26 <evrardjp> I would have preferred to know that shell arguments would have changed
15:26:41 <evrardjp> but it's fine, we never claimed it was a stable interface
15:27:20 <evrardjp> it's just a surprise for me, I am just back from holidays :)
15:27:44 <evrardjp> anyway, positive change overall, thanks for the work! :)
15:28:22 <portdirect> one q i have, is that i wonder if we should remove the default values for images from the charts?
15:28:41 <portdirect> my logic here is thus:
15:29:15 <portdirect> currently we have no way of validating/enforging that a particular version of openstack, or any partiuclar distro is used for deployment
15:29:24 <portdirect> and this would allow us to be sure of that
15:29:42 <portdirect> but comes with a massive downside, in that it would mean that our charts would not work 'out of the box'
15:29:56 <portdirect> but would need at least one set of over-rides applied to it
15:30:12 <portdirect> just a thought, but a conversation i think thats worth having
15:30:23 <evrardjp> I am not fond of that approach, because it will cause so many questions
15:31:24 <evrardjp> and also because the conversation above with releasing versions.
15:31:30 <portdirect> im not either :( the other thought that occured was for us to 'strip' these keys/branches out in our gates which would achive a similar effect
15:31:55 <evrardjp> I am not really sure to understand the problem
15:32:09 <evrardjp> you're afraid that some of the overrides wouldn't be applied?
15:32:19 <portdirect> more - what if we miss one
15:32:34 <portdirect> eg, forget to put an opensuse image in for say the keystone db sync job
15:33:26 <evrardjp> it kinda links me to my next steps question :)
15:33:48 <evrardjp> I thought it would be nice to remove all overrides from the shell scripts to bring them into each charts
15:34:08 <portdirect> currently we can only validate this by doing things like looking at the outpur here: http://logs.openstack.org/93/666193/2/check/openstack-helm-glance-rocky-opensuse_15/6e08fe3/primary/system/docker-images.txt
15:34:44 <evrardjp> if we do so, we can have multiple files applied, and the first one could be a "gate wiper" to ensure all images are pointing to null. But that's most likely a burden to maintain
15:35:13 <portdirect> if its just `images: null` would be simple :D
15:35:18 <jayahn> i totally recognize probelm pete is saying
15:35:26 <evrardjp> portdirect: not really
15:35:39 <evrardjp> because when a new image is added or removed, you have to think about those overrides
15:35:53 <portdirect> yes! we would need to - and currently we dont
15:35:58 <portdirect> thats the exact point
15:36:15 <portdirect> the same is true of passwords etc
15:36:32 <portdirect> but lets stick to images for now
15:36:58 <evrardjp> portdirect: I think all of this can be solved by the right documentation
15:37:31 <evrardjp> and good CI-ing
15:37:34 <portdirect> it certainly helps - but it doesnt ensure we are validating the right stuff
15:37:49 <jayahn> can we have this discussion over mailing list as well?
15:37:58 <portdirect> jayahn: i think that would be great
15:38:22 <evrardjp> I think it's best approach to discuss it over ML
15:38:30 <itxaka> +1 for those of as slow as heck today which are not understanding the issue well enough :)
15:38:34 <jayahn> we have very similar problem internally with a bit different use cases.
15:38:38 <evrardjp> it impacts how OSH is consumed
15:38:44 <jayahn> i really want to bring this discussion to my team
15:38:48 <portdirect> jayahn: i suspect you are not the only ones ;)
15:38:55 <evrardjp> portdirect: correct ;)
15:39:45 <portdirect> one of the pain points that ATT has consuming OSH internally is that 'default' images leak through
15:39:49 <jayahn> we had to make "diff function" to automatically find out if there is new images, or if we are missing any "necessary" override.
15:39:51 <evrardjp> but I think you are pointing to multiple problems, and I think we would all benefit from splitting that into smaller chunks
15:40:00 <portdirect> they get through development, and then fail ci
15:40:05 <portdirect> (obviously)
15:40:24 <evrardjp> it seems we all had that then
15:40:48 <portdirect> nice - lets take this to the ml to continue
15:41:24 <portdirect> one other thing i added in support of the above was getting the helm release values saved in ci: https://review.opendev.org/#/c/667178/
15:42:16 <portdirect> so we can clearly see 'helms' view of the world: http://logs.openstack.org/78/667178/2/check/openstack-helm-infra-openstack-support/da1cdba/primary/helm/values/
15:43:14 <evrardjp> this is nice
15:43:16 <evrardjp> very nice
15:43:26 <jayahn> +1 on this!
15:44:08 <portdirect> ok to move on?
15:44:19 <evrardjp> I will just drop this here...
15:44:29 <evrardjp> Maybe everything would be simpler if we used helmfile.
15:44:49 * evrardjp hides
15:45:12 <portdirect> or armada...
15:45:21 <portdirect> anyway
15:45:41 <portdirect> #topic meeting-time
15:45:48 <mattmceuen> ah this is me
15:45:48 <portdirect> mattmceuen: floor is yours
15:46:24 <mattmceuen> https://etherpad.openstack.org/p/osh-meeting-vote-2019
15:46:36 <mattmceuen> Just a reminder that we have an open vote for the time for this meeting
15:46:54 <mattmceuen> We're planning to close voting EOD today - if you have an opinion, please follow the instructions in the etherpad!
15:46:58 <jayahn> can we extend this vote for 1~2 days? I wrote reason in etherpad
15:47:57 <evrardjp> mattmceuen: I don't see many core reviewers opinion there.
15:48:08 <mattmceuen> Agree, need more opinions :)
15:48:13 <evrardjp> Not a great message :p
15:48:30 <mattmceuen> I think the message is that the core team is open to anything that facilitates the community!
15:48:30 <jayahn> i was confused with airship voting since mail sent out to mailing list got a wrong etherpad link. :)
15:48:36 * mattmceuen core team: prove me wrong
15:48:51 <evrardjp> mattmceuen: wow that's awesome.
15:48:53 <portdirect> I've intentinally not voted - as I'll move my life around whatever the community decides
15:49:03 <mattmceuen> jayahn: sorry I have lost the etherpad, sigh
15:49:08 <mattmceuen> can you paste the reason in here
15:49:13 <evrardjp> portdirect: this is a recipe for burnout :)
15:49:16 <mattmceuen> and I'll defer to portdirect on the timing decision
15:49:21 <evrardjp> :(
15:49:40 <evrardjp> one touch wrong and completely changed the meaning of my sentence!
15:49:40 <jayahn> there were two mails asking for vote; one for airship, one for osh
15:49:45 <portdirect> evrardjp: i never sleep
15:50:04 <jayahn> osh voting mail has etherpad link pointing to airship voting etherpad
15:50:14 <mattmceuen> oh dear
15:50:14 <jayahn> that got me confused, i thought i did vote
15:50:18 <mattmceuen> sorry about that
15:50:50 <mattmceuen> since we need to make sure we get everyone's vote anyway, you ok with extending a couple days portdirect?
15:50:56 <jayahn> and.. that was also my not-carefully-read mail problem
15:51:16 <portdirect> works for me mattmceuen
15:51:17 <evrardjp> jayahn: pay attention, this channel is logged :)
15:51:25 <jayahn> ah.. yeap
15:51:39 <jayahn> ;)...
15:51:51 <portdirect> #action extend vote one week for meeting times
15:52:11 * jayahn now totally understand why my company sweep out my email every month.
15:52:11 <mattmceuen> well that means I have six and a half days to vote!
15:52:14 <portdirect> jayahn: please get your team to vote as well
15:52:22 <jayahn> I will
15:52:34 <jayahn> and samsung guys as well
15:52:43 <portdirect> nice - thx
15:53:18 <mattmceuen> that's all from me portdirect
15:53:48 <portdirect> #topic auto_bridge_add bond port support
15:53:53 <portdirect> cheng1: floor is yours
15:54:03 <cheng1> in neutron chart, we can add nic to ovs bridge according to auto_bridge_add. but we don't support adding bond to ovs bridge yet.
15:54:16 <cheng1> I would like to add bond support
15:54:23 <cheng1> https://storyboard.openstack.org/#!/story/2005946
15:54:37 <portdirect> sounds good to me :D
15:55:28 <portdirect> i think a ps, implementing that would be awesome
15:55:50 <cheng1> portdirect, thanks. I will create patch for this
15:55:58 <portdirect> nice - ok to move on?
15:56:04 <cheng1> another thing about ovs
15:56:16 <cheng1> the ovs image patch  https://review.opendev.org/#/c/665310/
15:56:35 <cheng1> several ovs-dpdk feature patches depends on this patch
15:56:56 <cheng1> as they need the dpdk-enabled ovs image.
15:57:16 <cheng1> Would like to get more reviews from the cores.
15:57:19 <portdirect> ok - so there was a q for georgk about supportability of distro packages, but if hes good with it - then lgtm
15:57:57 <georgk> rihabb is trying to build bionic based images at the moment
15:58:35 <georgk> let's see how that works out
15:58:53 <portdirect> evrardjp: you ok with waiting untill next week, or want to take your two topics to the channel?
15:59:10 <georgk> the bionic upgrade is "just" a side track of the OVS activity
15:59:21 <georgk> :-)
15:59:27 <portdirect> georgk: sounds good, look forward to seeing how this works out
15:59:56 <portdirect> ok - we are out of time, I'll put your items at the top of the etherpad for next week evrardjp
15:59:57 <evrardjp> portdirect: it's feedback
16:00:03 <evrardjp> let's move to channel
16:00:03 <portdirect> thanks everyone!
16:00:05 <evrardjp> thanks!
16:00:10 <georgk> thanks
16:00:11 <portdirect> #endmeeting openstack-helm