15:00:57 <portdirect> #startmeeting openstack-helm
15:00:58 <openstack> Meeting started Tue Jul 30 15:00:57 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:59 <portdirect> o/
15:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:02 <openstack> The meeting name has been set to 'openstack_helm'
15:01:05 <dwalt> o/
15:01:06 <megheisler> \o
15:01:08 <portdirect> lets give it a few mins for people to arrive
15:01:18 <portdirect> agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-07-30
15:01:21 <lamt> o/
15:01:22 <georgk> hi
15:01:32 <rihabb2> o/
15:01:42 <srwilkers> o/
15:01:51 <gagehugo> o/
15:02:11 <howell> o/
15:03:34 <evrardjp> o/
15:04:16 <portdirect> ok - lets go
15:04:53 <portdirect> #topic release management method mechanics
15:05:32 <portdirect> we have a ps up here: https://review.opendev.org/#/c/673022/ which is an effort to begin the formalisation of our agreed upon stance to release management
15:06:07 <portdirect> ttx had suggested `independant` as the path to follow here
15:06:26 <portdirect> but based on evrardjp's feedback would `none` be more appropriate for now?
15:07:03 <srwilkers> i think none makes sense here
15:07:20 <evrardjp> well
15:07:47 <evrardjp> I don't think so -- I think you can drop that patch, and just make a patch in the releases repo, saying you're independent
15:07:58 <evrardjp> I can walk you through that if you like
15:08:40 <evrardjp> you would need a file in here: https://github.com/openstack/releases/tree/master/deliverables/_independent
15:08:41 <lamt> What is the impact if we put release management: none - would that not accomplish the same thing?
15:09:31 <portdirect> evrardjp: already done: https://review.opendev.org/#/c/673024/
15:09:40 <evrardjp> none in governance was meant for something else. So I will double check with the TC and releases if we want to have this instead.
15:09:40 <portdirect> i just need to add storyboard
15:10:13 <gagehugo> It looks like other projects that don't follow a release strictly also use none, so that seems fine
15:10:21 <evrardjp> yeah. You can even add more things portdirect :)
15:10:36 <srwilkers> evrardjp: okay.  based on your feedback on that change, i would have assumed that was the case and you wouldnt need to double check
15:10:55 <portdirect> though Sean McGinnis says that the releases repo ps is not required
15:11:12 <portdirect> so i think it would help if you could align with the tc evrardjp
15:11:24 <srwilkers> i agree here
15:11:28 <portdirect> as im getting conflicting advice from three angles
15:11:32 <evrardjp> srwilkers: let me rephrase. independent shouldn't be governance, IMO
15:11:47 <srwilkers> it would be nice to formalize this, as this seems to be a recurring discussion each cycle
15:12:08 <portdirect> to be clear: we are not yet ready for a release, and dont intend to follow the openstack release cycle when we are.
15:12:16 <evrardjp> marking it as none in governance is something we can do. But I would encourage to say that we have some release management instead
15:12:25 <evrardjp> and that release management we have is independant of openstack
15:12:30 <evrardjp> branches
15:12:42 <evrardjp> so for me the only thing that apply is a patch in releases
15:12:53 <evrardjp> (with the model being independent)
15:12:57 <portdirect> ok - so please sync with sean, and ttx
15:12:59 <lamt> would none be the correct thing to add if independent is not correct - but I agree with portdirect , it would be good to have agreement with TC.
15:13:35 <evrardjp> I will make sure this is discussed on the next tc office hours or in the review
15:13:43 <portdirect> great - thanks dude
15:13:48 <evrardjp> sorry for the mess there, you shouldn't have to worry about that :)
15:13:55 <portdirect> np
15:14:16 <portdirect> ok - lets move on
15:14:20 <portdirect> #topic Broken image building
15:14:29 <portdirect> evrardjp: you're up :D
15:15:47 <evrardjp> oh yeah
15:16:02 <evrardjp> so don't bother doing patches into loci images right now, things are broken
15:16:18 <evrardjp> it's due to a package we are building, who has disappeared from pypi
15:16:48 <evrardjp> we have a temp fix to not build it, which only impacts zaqar afaik
15:17:16 <evrardjp> I am discussing the long term fix as we speak
15:17:47 <evrardjp> nothing else to say.
15:19:22 <portdirect> ok - thanks dude
15:19:35 <cheng1> So the openstack-helm-image CI fails recently?
15:19:56 <cheng1> I didn't pay attention
15:21:21 <evrardjp> yeah
15:21:37 <evrardjp> on just the loci built images
15:21:40 <evrardjp> it's recent
15:21:49 <cheng1> Ok, evrardjp . got it
15:21:54 <cheng1> thanks
15:23:48 <evrardjp> yw
15:24:19 * srwilkers slaps portdirect around with a rather large trout
15:24:38 * evrardjp smiles as he sees the red face of portdirect
15:25:11 <srwilkers> alright - i think portdirect got pulled into something else.  aside from the reviews listed, is there anything else we wanted to discuss for round table?
15:27:07 <srwilkers> alright.  not sure i can change the topic, so here's the list of items on the review list
15:27:17 <srwilkers> https://review.opendev.org/#/c/671696/
15:27:18 <srwilkers> https://review.opendev.org/#/c/643284/
15:27:18 <srwilkers> https://review.opendev.org/#/c/671030/ - update Nagios Core to 4.4.3
15:27:18 <srwilkers> https://review.opendev.org/#/c/668202/ - propose adding PVC support for singleton Nagios pod deployment
15:27:18 <srwilkers> https://review.opendev.org/#/c/672578/ - update elasticsearch register snapshot repository job to include verification of repositories added
15:28:14 <srwilkers> one for adding the jq package to the neutron image, one for extending the neutron chart to support ovs with dpdk
15:28:27 <srwilkers> and the other three there are mine, so shameless plug
15:28:54 <srwilkers> just general updating for the nagios image, then quality-of-life improvements for the nagios and elasticsearch charts
15:29:03 <evrardjp> no reason to be ashamed in the first place :)
15:29:24 <lamt> Also - https://review.opendev.org/#/c/673372 - someone added that just now
15:29:31 <evrardjp> on the first one, do we want consistency?
15:29:36 <srwilkers> yep, just saw
15:29:42 <evrardjp> across the neutron images?
15:30:01 <evrardjp> I am fine with being smarter at inclusion of packages
15:30:17 <evrardjp> it's always the lightweight vs featureful topic
15:31:19 <cheng1> Yeah, to parse json file. I would like to include the new package jq evrardjp
15:31:44 <georgk> evrardjp: in order to support per-host overrides, we need local config files. And we need jq for parsing those in a human-comprehensible  manner
15:31:48 <cheng1> which is just tens of KB
15:32:06 <georgk> happy to explain the details... :-)
15:32:29 <evrardjp> I am fine with the addition of jq :)
15:32:44 <srwilkers> same here
15:32:54 <evrardjp> I am just wondering if it won't be a problem for future me if neutron sriov images needs jq later, and I thought we had done it
15:32:57 <srwilkers> i do love me some jq
15:33:16 <evrardjp> we can still see later, it's fine :)
15:33:26 <evrardjp> sorry for that convo then :p
15:33:59 <srwilkers> might be worth discussing whether it's something we should add to the images most likely to be part of a host level overrides scenario
15:34:21 <srwilkers> just food for thought
15:34:22 * srwilkers shrugs
15:35:29 <srwilkers> looks like we've got two more items added
15:35:35 <evrardjp> srwilkers: thanks for translating that into english
15:35:42 <evrardjp> That's exactly what I meant
15:35:48 <srwilkers> evrardjp: np :)
15:35:54 <srwilkers> oh, i like this change: https://review.opendev.org/#/c/672738/5
15:35:59 <srwilkers> i know we discussed that last week
15:36:12 <lamt> that's me - added re: DB backup from last week.
15:36:19 <evrardjp> that's cool indeed
15:36:41 <lamt> posting on behalf of Cliff who is not here
15:39:02 <srwilkers> id like to see corresponding changes to take advantage of https://review.opendev.org/#/c/672738/5 quickly.  im wondering if instead of having conditional checks, it instead makes sense to take advantage of the built in sprig default function for when those things arent supplied
15:39:37 <srwilkers> and just makimg those defaults the standard kubernetes job defaults (ie: backofflimit = 6, etc)
15:41:56 <srwilkers> that's all i've got
15:42:16 <evrardjp> oh I see
15:42:36 <evrardjp> srwilkers: but wouldn't that mean we would have to maintain those k8s defaults in tree?
15:42:55 <evrardjp> or is there some cleverness possible?
15:43:31 <evrardjp> (sorry for the late answer there)
15:43:45 <evrardjp> (that's all I got too)
15:43:47 <srwilkers> it would unfortunately, but i'd argue the tradeoff here is sacrificing readability/simplicity
15:44:13 <evrardjp> I don't know how much they change, and if that wouldn't set wrong expectations
15:45:46 * srwilkers pokes portdirect
15:46:30 <evrardjp> srwilkers: after more than hour anyone can stop a meeting
15:46:33 <evrardjp> just saying
15:46:45 <evrardjp> :)
15:47:04 <portdirect> hey - sorry - been pulled into fun
15:47:16 <portdirect> #endmeeting