15:00:21 <mattmceuen> #startmeeting openstack-helm
15:00:26 <openstack> Meeting started Tue Jun 18 15:00:21 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'openstack_helm'
15:00:32 <evrardjp> o/
15:00:35 <howell> o/
15:00:38 <georgk> hi
15:00:38 <mattmceuen> #topic Rollcall
15:00:41 <mattmceuen> https://etherpad.openstack.org/p/osh-meeting-2019-06-18
15:00:48 <mattmceuen> Hey everybody - here is our agenda ^
15:00:49 <rha> hi
15:00:50 <itxaka> o/
15:00:52 <rihbb> hi
15:01:02 <mattmceuen> we'll give it a minute before getting started
15:01:13 <mattmceuen> Please add anything you'd like to discuss today to the agenda
15:02:03 <cheng1> o/
15:03:28 <mattmceuen> Alright -- let's get started
15:03:37 <mattmceuen> #topic Meeting Time Voting
15:03:50 <mattmceuen> I sent out an email on this just a bit ago
15:03:57 <mattmceuen> Slightly overdue, thanks for your patience :)
15:04:23 <mattmceuen> portdirect and I sent out an etherpad with options and instructions
15:04:45 <mattmceuen> instructions are in the etherpad and the email, so need to dig up the email: https://etherpad.openstack.org/p/osh-meeting-vote-2019
15:05:29 <mattmceuen> I'm asking anyone (who cares) to please vote thusly:
15:05:59 <mattmceuen> Pick your top five preferred Meeting Time + Meeting Approach combinations, and fill in one of the templates
15:06:14 <mattmceuen> I think it's self-explanatory, but please let me know if there are any questions
15:06:32 <mattmceuen> We'll run this voting till EOD next Tuesday, so we get one more shot at reminding folks next team meeting
15:06:35 <mattmceuen> Any questions?
15:07:11 * portdirect slides in through the back door, trips over a chair, looks around then slides awkwardly into a seat.
15:07:50 <mattmceuen> o/ portdirect :D
15:07:58 <mattmceuen> alright - moving on!
15:08:03 * evrardjp notices portdirect has dropped the archeological vase everyone was watching at the center of the room
15:08:21 * portdirect slides lower in his chair
15:08:30 <mattmceuen> #topic openstack-helm-images release tagging/naming/tracking?
15:08:39 <itxaka> thats me
15:08:54 * mattmceuen is glad portdirect got released briefly from the mines!
15:09:05 <mattmceuen> take it away itxaka
15:09:14 <itxaka> wondering how we should track releases under the openstack-helm-images repo as we do on the openstack-helm repo
15:09:25 <itxaka> we been having some issues with this lately, openvswitch for example
15:09:39 <itxaka> tempest is also not synced with any release and its hardcoded
15:09:40 <evrardjp> what do you mean by "having issues" ?
15:09:56 <evrardjp> tempest need some love
15:10:14 <itxaka> someone was complaining on irc about having an X version of openvswitch which was not compatible with something
15:10:26 <evrardjp> Is freezing images with a date good enough?
15:10:34 <itxaka> doesnt seem like we have the capability to have distinct images pinned to versions
15:10:39 <evrardjp> itxaka: yes, we discussed this last week I think
15:10:46 <itxaka> ahh did I miss it?
15:10:51 <itxaka> yes, I miss it then
15:10:58 <evrardjp> but yeah, we don't "release"
15:11:08 <evrardjp> we are currently doing just master
15:11:41 <itxaka> yeah, tempest is terrible in this example becuase using master for it can backfire big time
15:11:43 <evrardjp> I am not sure what's the proposal here
15:11:48 <evrardjp> to understand*
15:12:09 <itxaka> no proposal yet, just a heads up that its something that we migth want to tackle sooner than later
15:12:18 <itxaka> especially with the upgrade gates incoming
15:12:49 <itxaka> we might start hitting issues with versions out of sync and no way of using a newer/older version from osh-images
15:13:10 <itxaka> I did not have had time to investigate deeply enough to propose anything
15:13:11 <mattmceuen> yeah, we discussed the openvswitch example specifically last week, but we should validate that our general approach fits what we need as well
15:13:18 <evrardjp> so for me that raises two questions.
15:13:21 <mbuil> itxaka: you mean the OS version or the openstack version? or both?
15:13:40 <evrardjp> 1) should we branch the whole repo with openstack branches? Does that make sense?
15:13:42 <itxaka> both should be including when discussing this IMO
15:13:51 <evrardjp> Or do we branch with our OSH "releases"
15:14:04 <itxaka> thats a great question
15:14:21 <evrardjp> 2) If we do not branch, how do you intend to do this?
15:14:37 <portdirect> we (I) need to formalize the response to this - as we have discussed at many ptgs
15:14:58 <portdirect> we ideally do not want to branch - but this needs written up
15:15:19 <evrardjp> yup I think we need to improve documentation there indeed.
15:15:20 <itxaka> do we need to keep a matrix of openstack versions -> image versions then?
15:15:28 <evrardjp> do we need to?
15:15:42 <itxaka> as I missed any convo about this Im just hitting in the dark here on how its supposed to work
15:15:48 <portdirect> itxaka - we should be able to get that from the tag/image-overrides?
15:15:50 <evrardjp> because we have rolling "openstack" images, and the rest sounds fine to just roll forward
15:16:43 <georgk> itxaka: honestly, rihbb and I wanted to bring up that exact question today again
15:16:46 <itxaka> portdirect, how is someone supposed to know that deploying ubuntu-queens from osh needs the osh.image openvsiwthc 20180524 image?
15:16:49 <evrardjp> ok so I think the action items are to clear that up then?
15:16:53 <georgk> as part of the bionic image introduction
15:17:07 <evrardjp> itxaka: I see what you mean
15:17:28 <itxaka> there is no links between osh and osh-images versions written anywhere so it gets a bit confusing
15:17:34 <georgk> +1
15:17:43 <mattmceuen> itxaka: the ubuntu-queens reference overrides would list out the recommended overrides, right?
15:17:51 <mattmceuen> recommended *image overrides
15:18:08 <itxaka> but for some images we only build "latest" no?
15:18:30 <evrardjp> but at every point the "latest" should work, as long as its consistent
15:19:16 <itxaka> will it? doesnt the openvswitch issue last week told us that it doesnt? or was that a different issue?
15:19:20 <mattmceuen> latest of "everything" should probably work together, but to your point evrardjp, if we tag images w/ date (or something) that should be what we use in the reference overrides for particular override sets I would think
15:20:02 <evrardjp> mattmceuen: I think frozen images should be used for "stable" like branches, or for ensuring upgrades. This is why I said we should link that to OSH and start releasing OSH.
15:20:15 <evrardjp> it's not an easy topic :)
15:20:25 <itxaka> tbh, from my point of view, if we dont sync with openstack release names it gets unmaintainable pretty soon, even with date-freezed images
15:20:45 <evrardjp> I didn't say we need to branch per openstack branch in that last comment. But having a "stable" branch
15:20:46 <portdirect> i agree with evrardjp, on the need for frozen images
15:21:27 <mattmceuen> So portdirect I think you were speaking to the famous "sugarcube spec" - should we include image freezing in that spec as a related point of discussion?
15:21:28 <evrardjp> the tooling itself doesn't need to be branched though.
15:21:39 <portdirect> i think i see the need for us to tie these things together using the example over-rides, eg: https://github.com/openstack/openstack-helm/blob/master/neutron/values_overrides/rocky-opensuse_15.yaml
15:21:47 <portdirect> we should also do this for things like ovs
15:21:55 <itxaka> agreed
15:22:05 <portdirect> using the same name format - so that we can tie things simplty together
15:22:22 <portdirect> which i suppose is the matrix itxaka proposed, just presented slightly differently?
15:22:23 <itxaka> the operators know that they are using the correct stuff, and that it should work with other RELEASE_BRANCH components
15:22:35 <portdirect> yup
15:23:44 <itxaka> well, the matrix I was talking assumed that we would only have date-freezed images, which would be a nightmare to maintain
15:23:56 <itxaka> if we had named frozen images, then its easy peasy
15:24:05 <mattmceuen> is RELEASE_BRANCH in this context openstack, osh release, OS, or some combo?
15:24:18 <itxaka> same as osh I think
15:24:19 <evrardjp> itxaka: I think we should not talk generally in here
15:24:27 <mattmceuen> I thought we were trying to avoid branching for openstack release and OS release, and only branch for osh major versions
15:24:42 <evrardjp> the only problem I see is inconsistent for ovs for the bare ovs image and what's provided in neutron, correct?
15:25:09 <georgk> evrardjp: yes, due to source build OVS image
15:25:09 <evrardjp> in that case, can't we just have consistent images by making multiple ovs images (per openstack branch)
15:25:31 <portdirect> ^
15:25:40 <evrardjp> georgk: I think there are multiple solutions to this problem
15:25:46 <itxaka> and tempest
15:25:58 <evrardjp> I would rather tackle those separately
15:26:31 <evrardjp> the tempest issue is different right?
15:26:49 <evrardjp> Because if you would branch you would not gain anything with tempest, because tempest is supposed to be following master anyway
15:26:52 <evrardjp> isn't it?
15:26:53 <itxaka> so one thing is the problem that we have currently, but this is something that can hit us later with all the other osh-images .... images
15:27:44 <evrardjp> can we do a summary of what is decided?
15:27:54 <evrardjp> I am confused now :p
15:28:17 <evrardjp> should that be a spec?
15:28:19 <mattmceuen> ++
15:28:21 <evrardjp> docs?
15:28:39 <portdirect> i think a spec would be great here
15:28:44 <evrardjp> I propose we document what we do, why we do, and the limitations, and if necessary, a spec for changes?
15:28:50 <itxaka> agreed
15:28:56 <evrardjp> ok
15:28:56 <itxaka> sounds like a better way
15:29:13 <mattmceuen> We need a spec to outline when OSH is branched, how OSH deals with multiple openstack releases and operating systems, and how image building / tagging / branching dovetails into that
15:29:16 <itxaka> of discussing this and also getting some backstory on it for those of us that do not have it
15:29:35 <portdirect> could we start that in a spec - I think that that would be the best way to fully articulate it
15:29:47 <itxaka> agreed
15:29:55 <portdirect> I could take that on - as its been on my action item list for far to long
15:30:19 <itxaka> +1
15:30:23 <mattmceuen> that would be awesome portdirect, ty
15:30:26 <evrardjp> portdirect: I am still waiting for the CI and/or the versioning/releasing of helm charts, don't you want me to draft something?
15:30:53 <portdirect> I have get a stab at it evrardjp
15:31:07 <evrardjp> ok I will let that to you then :)
15:31:09 <portdirect> though once its up - i think it would be gret to get multiple people on the ps
15:31:10 <portdirect> :)
15:31:32 <evrardjp> fine for me. I just don't want to you burn out due to the amount fo work :)
15:31:53 <evrardjp> long story short: you have our support, dear leader!
15:32:00 <mattmceuen> +1
15:32:17 <mattmceuen> If you need any help dusting off ancient PTG discussions you know where to find me portdirect :D
15:32:42 <mattmceuen> I'd even buy you new sugarcubes
15:32:48 <portdirect> lol - I'll take the dear part - though the only leader thing about me is in the title PTL - I'm an admin bod
15:33:17 <portdirect> mattmceuen: :D
15:33:32 <evrardjp> mattmceuen: hahah
15:33:43 <mattmceuen> Alright, anything else to discuss on this before we defer the conversation to the spec?
15:34:02 <mattmceuen> In that case, moving on:
15:34:02 <portdirect> evrardjp: for context, the 1st versioning conversation re osh used many sugarcubes in dublin to work though
15:34:30 <mattmceuen> The spec needs sugarcube ascii art or I won't approve it
15:34:32 <evrardjp> I heard about that, but I wasn't there. It just regularily comes back, it's a nice running joke :)
15:35:02 <mattmceuen> #topic Idee of a new SIG interesting for OSH members
15:35:03 <evrardjp> "Today we'll learn about releasing with the _latest_ sugarcubes. Amazing!"
15:35:07 <mattmceuen> https://etherpad.openstack.org/p/containers-sig
15:35:18 <mattmceuen> evrardjp want to walk us through this?  I haven't had a chance to take a look
15:35:20 <evrardjp> yeah. That might interest you.
15:35:29 <evrardjp> oh you expect more text?
15:35:33 <evrardjp> I am eating a waffle!
15:35:50 <itxaka> lmao
15:36:04 <mattmceuen> well I wanted a description, but now I really just want a waffle
15:36:10 <evrardjp> haha
15:36:12 <evrardjp> I understand
15:36:15 <evrardjp> so
15:36:18 <mattmceuen> no the text in the etherpad looks good :)
15:36:47 <evrardjp> well, there were discussions in the past about how to work with different container image building projects. Let's say we didn't document the failures or the agreements.
15:37:04 <evrardjp> I think in the past there has been a need and a willingness to work together.
15:37:15 <evrardjp> I am just adding a scope here, and trying to group ppl together
15:37:38 <evrardjp> osh is technically independant of images, but it still builds some, and consumes some
15:37:41 <portdirect> I think this is a great initiative to get moving
15:38:05 <evrardjp> have a look at the etherpad, and add your name if you want to participate, actively or passively
15:38:15 <evrardjp> that would be nice to have some kind of support.
15:38:27 <portdirect> I'd really like us to not be in the image building process (or at least have as small a surface area as possible) and this looks like a great step in that direction.
15:38:51 <mattmceuen> thanks for getting traction on this evrardjp
15:39:10 <portdirect> and having a common set of guidlines that Kolla/OSH/TrippleO(/OSA?) can use woudl really help
15:39:37 <portdirect> along with projects guiding the packaging requirements they have
15:39:41 <evrardjp> OSA is not really part of the scope, as they are using machine containers, but the first action item of collaboration benefits them too
15:40:01 <evrardjp> so yeah it touches things broadly
15:40:22 <portdirect> yeah - and the healthchecks!
15:40:30 <mattmceuen> hooray for healthchecks
15:40:44 <portdirect> adam did some great work in that space - it would be good to see it 'taken home'
15:40:46 <evrardjp> that would be a collaboration with self-healing I guess
15:40:52 <evrardjp> yeah
15:40:52 <portdirect> yeah
15:41:39 <mattmceuen> evrardjp will you send out next steps on the ML, or ?
15:42:11 <evrardjp> mattmceuen: correct. One will the mailing lists, two will be the patchset for governance-sigs which I already have opened.
15:42:18 <evrardjp> I am continuing on that lever
15:42:20 <evrardjp> level*
15:42:26 <mattmceuen> excellent
15:42:52 <mattmceuen> Any other questions / thoughts on the SIG, team?
15:44:07 <mattmceuen> Thanks evrardjp -- moving on:
15:44:14 <mattmceuen> #topic Roundtable
15:44:38 <mattmceuen> We have some patchsets needing review - and a handful at the top have been waiting for a while:
15:44:46 <mattmceuen> https://review.opendev.org/#/c/660572/ --> Rafactoring volume mount variables in db sync job
15:44:46 <mattmceuen> https://review.opendev.org/#/c/662992/ --> htk: provide default domain env and secrets
15:44:46 <mattmceuen> https://review.opendev.org/#/c/662993/ --> keystone: default domain fix
15:44:46 <mattmceuen> https://review.opendev.org/#/c/665102/ --> Add bionic based build jobs to Zuul build configuraton
15:44:47 <mattmceuen> https://review.opendev.org/#/c/665310/ --> ubuntu bionic based ovs image
15:45:18 <mattmceuen> Would be great to get some eyes on all of them
15:45:48 <mattmceuen> Any other patches we'd like to request extra review on?  Or other Roundtable topics?
15:46:02 <georgk> for the bionic images, we'd like to get input in terms of which OpenStack version we should go for
15:46:26 <georgk> it ties into the discusion we just had
15:46:39 <georgk> so, comments are welcome
15:46:46 <georgk> on the patchset
15:47:13 <portdirect> georgk: why move away from source build here?
15:47:46 <portdirect> i get move from debian, though it does make it very hard to target a particular version of ovs
15:47:50 <georgk> we'd like to move away from building OVS from source
15:48:04 <portdirect> why?
15:48:06 <georgk> ah, ok
15:48:31 <evrardjp> portdirect: but it makes things very consistent to use packages in ovs and neutron image for example
15:48:31 <georgk> mainly because of incosistencies between the OVS version in the nova and neutron images and the OVS image itself
15:48:51 <evrardjp> as long as its from the same source, they should work together well :)
15:49:04 <georgk> currently, nova and neutron ship with the xenial version of 2.5 which is older than the 2.8 source build
15:49:10 <evrardjp> also, why maintaining things where someone does it for you? :D
15:49:51 <georgk> we were wondering last week: was there a technical reason to go  for a 2.8 source build?
15:50:06 <evrardjp> (disclaimer: I work for a distro, but that's not only because that reasoning pays my bills that I have it, it makes genuinely sense to me)
15:50:20 <portdirect> there were some bugs in 2.5 that effected operation
15:50:33 <portdirect> i dont have the details to hand, but can dig them out
15:50:41 <evrardjp> that's valuable input
15:50:45 <georgk> ok, we noticed however that 2.5 in neutron-ovs-agent does not work with 2.8 and DPDK
15:51:01 <georgk> so, we wanted to move to a common consistent version
15:51:11 <georgk> hence the upgrade to bionic to get off of 2.5
15:51:11 <portdirect> ok - lets look to fix that
15:51:27 <portdirect> are you using the clients to perform operations, or native?
15:51:52 <georgk> well, we havent really touched any config on that part
15:52:16 <georgk> the default I'd say :)
15:55:57 <portdirect> georgk: I'd look into ovsdb_interface, and check that its set to 'native'
15:56:26 <portdirect> if so then much of the versioning issues should come down to the python lib used to talk to the ovsdb
15:56:57 <georgk> ok, I'll check that and come back to you
15:57:26 <mattmceuen> 3min left - any additional topics today?
15:57:29 <georgk> still, it would be great to use a newer version of OVS with DODK support
15:57:41 <portdirect> agreed!
15:59:06 <mattmceuen> Alright folks, that's a wrap - thanks for joining today & have a great week
15:59:14 <mattmceuen> #endmeeting