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