14:59:28 <mattmceuen> #startmeeting OpenStack-Helm
14:59:29 <openstack> Meeting started Tue Jun 11 14:59:28 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:32 <openstack> The meeting name has been set to 'openstack_helm'
14:59:36 <mattmceuen> #topic Rollcall
15:00:25 <mattmceuen> Hi everybody -- here's our agenda today, please add anything to discuss:  https://etherpad.openstack.org/p/openstack-helm-meeting-2019-06-11
15:00:45 <srwilkers> o/
15:00:48 <itxaka> \o
15:00:56 <mattmceuen> since folks are still joining and may have missed it:  agenda :)  https://etherpad.openstack.org/p/openstack-helm-meeting-2019-06-11
15:01:20 <georgk> hi there
15:01:22 <mattmceuen> portdirect is incapacitated by work today
15:01:38 <mattmceuen> decimated, even
15:01:41 <mattmceuen> o/ georgk!
15:02:17 <mattmceuen> We have a -very- light agenda today so far, only requests for code review
15:02:51 <mattmceuen> I will post them here, and let's see if any discussion is needed for them while we have the eyeballs
15:02:58 <gagehugo> o/
15:03:01 <mattmceuen> https://review.opendev.org/#/c/660572/ --> Rafactoring volume mount variables in db sync job
15:03:01 <mattmceuen> https://review.opendev.org/#/c/659993/ --> Add volumes mount variables in the nova-cell-setup job
15:03:02 <mattmceuen> https://review.opendev.org/#/c/660544/ --> rabbitmq: set hostPath for rabbitmq-data
15:03:02 <mattmceuen> https://review.opendev.org/#/c/662426/ --> Creating directory from ${APACHE_RUN_DIR} variable
15:03:02 <mattmceuen> https://review.opendev.org/#/c/662603/ --> Enable hugepage support in HTK resources snippet
15:03:02 <mattmceuen> https://review.opendev.org/#/c/662992/ --> htk: provide default domain env and secrets
15:03:02 <mattmceuen> https://review.opendev.org/#/c/662993/ --> keystone: default domain fix
15:03:03 <mattmceuen> https://review.opendev.org/#/c/663130/ --> Add SUSE image for Selenium to be used in helm tests
15:03:07 <mattmceuen> o/ gagehugo
15:03:08 <howell> o/
15:04:04 <itxaka> whats the output of the friday discussion with portdirect regarding the poll to be sent for the meeting times mattmceuen?
15:04:15 <georgk> awesome, I patch is already in the list :-)
15:04:20 <georgk> i == my
15:04:42 <mattmceuen> itxaka the output was that I hoped noone would remember that this week as portdirect and I failed to sort that out
15:04:48 <itxaka> lmao
15:05:02 <mattmceuen> I will redouble my efforts this week, apologize
15:05:53 <evrardjp> o/
15:06:02 <mattmceuen> o/ evrardjp howell
15:06:21 <mattmceuen> #topic Roundtable
15:06:31 <mattmceuen> Any questions / thoughts on the patchsets above?
15:07:05 <evrardjp> none
15:07:30 <georgk> one question
15:07:34 <mattmceuen> Any other topics that everyone would like to discuss today?
15:07:39 <georgk> a generic one
15:07:43 <mattmceuen> go for it
15:07:46 <mattmceuen> #topic generic one
15:07:51 <georgk> thanks!
15:08:15 <georgk> the OVS image in openstack-helm-images is a source build of OVS 2.8.1
15:08:31 <georgk> the LOCI images of the openstack components use the distro provided OVS 2.5.4
15:08:50 <georgk> does anybody happen to know why this is the case?
15:09:16 <georgk> like is there a historical technical reason for adding a 2.8 source build which is not 100% compabile with 2.5.4
15:09:25 <georgk> just curious
15:09:39 <mattmceuen> I'm looking now - I'm not aware of any reason
15:10:54 <mattmceuen> looks like an attempt was made to bump it to 2.10.1, which was reverted
15:11:11 <georgk> yeah, this was me and evrardjp...
15:11:54 <georgk> we, the little group around the OVS-DPDK people, try to find the best way out of the following:
15:11:57 <mattmceuen> have the incompatibilities between 2.8 and 2.5 manifested themselves in any issues?
15:12:28 <georgk> yes, there is at least one problem related to querying mtu sizes
15:12:30 <itxaka> the opensuse image is using 2.11.0
15:12:34 <evrardjp> georgk: I would prefer to not having source builds if it's possible to rely on packages
15:13:00 <evrardjp> it means less maintenance burden
15:13:01 <itxaka> we should probably sync both :(
15:13:23 <evrardjp> itxaka: not really. Syncing versions between OSes is a nightmare
15:13:34 <georgk> so, we cannot get 2.5.4 in neutron-ovs-agent to work with OVS 2.10
15:13:46 <georgk> I expect similar problems with 2.11...
15:13:48 <mattmceuen> ahh
15:13:48 <evrardjp> I believe we should use the native OS version as much as we can, because this is properly tested by the packagers/distros
15:14:16 <georgk> does it work for you with opensuse?
15:14:39 <evrardjp> georgk: we are consistent in versions
15:14:47 <evrardjp> we are using OS provided versions
15:14:52 <evrardjp> for all the charts
15:15:02 <georgk> ah, right, sure, you are not using the debian images for the OVS-agent :-)
15:15:03 <evrardjp> which is why I think it's easier if you have a ppa/mirror
15:15:06 <georgk> stupid me
15:15:08 <evrardjp> georgk: correct
15:15:58 <georgk> or go back to a 2.5.4 image of OVS itself -> coming back to my original question of why tehre is a 2.8.1 source build
15:17:19 <mattmceuen> I am not sure, and the git history only goes back to late last year.  evrardjp, do you know where that one lived prior to openstack-helm-images?
15:19:05 <evrardjp> mattmceuen: it's still in osh-infra afaik
15:19:08 <evrardjp> we didn't remove it yet
15:19:26 <evrardjp> I was waiting for the gates to move to use osh-images first
15:20:14 <evrardjp> https://github.com/openstack/openstack-helm/tree/master/tools/images/openvswitch
15:20:19 <evrardjp> I was wrong it was osh
15:20:28 <mattmceuen> ahh there it is
15:20:53 <georgk> ah, yes
15:20:57 <georgk> lightweight image
15:20:58 <evrardjp> I asked in the past the reason for versions, but without deep details answered. I can maybe find that in the logs.
15:21:14 <evrardjp> Long story short, not a real explanation anywhere, because it wasn't written in the commit messages
15:21:23 <mattmceuen> So the original commit from portdirect says "This PS moves to use a lightweight build of OvS 2.8.1 using the
15:21:23 <mattmceuen> offical k8s network base image." -- I think we'll need to ask him if there's a reason
15:21:24 <evrardjp> just "bump image" or things like that
15:21:35 <georgk> seems so
15:22:09 <mattmceuen> #action mattmceuen to sync w/ portdirect on OvS 2.8.1
15:22:21 <evrardjp> not sure what's the action point there though
15:22:27 <georgk> mattmceuen: awesome, thank you
15:22:35 <evrardjp> you want to figure out why we are using this version, or why can't we bump?
15:22:53 <mattmceuen> Yes :)
15:23:00 <mattmceuen> the answer to the first one impacts the second one
15:23:11 <georgk> evrardjp: I am hesitent to bump using a ppa, to be honest
15:23:11 <evrardjp> I understood with Yes :)
15:23:25 <evrardjp> georgk: why? It would be consistent across neutron and ovs image
15:23:46 <evrardjp> else you have to carry this kind of code everywhere.
15:24:06 <evrardjp> (Except if you plan to extract said data from a docker container to another, which sounds even messier)
15:24:11 <georgk> true, but we would have to carry the code to build a ppa package, too
15:24:29 <georgk> and even worse: maintain a ppa which other people might want to use, too
15:24:45 <evrardjp> against collaboration on said ppa? :p
15:25:50 <georgk> well, collaboration is highly welcome
15:25:57 <evrardjp> I think it would be easy to have a container that builds said package, and use that container for installing the package on the different images, at worst, but that sounds very tedious
15:27:01 <evrardjp> if we were to use bionic default ovs, you would have 2.9.2, which is already better than 2.8.1 btw
15:27:05 <georgk> how does that differ from having a source build in the debian images?
15:27:21 <georgk> true
15:27:34 <evrardjp> I mean maintaining a source build is expensive
15:27:35 <georgk> the Loci images are still Xenial, right?
15:27:45 <georgk> or did I miss bionic builds?
15:27:50 <evrardjp> it's what we decide it to be
15:28:16 <evrardjp> right now, we are building xenial, but we could work on bionic
15:29:10 <mattmceuen> georgk, for the ovs dpdk work you want to achieve, is 2.9.2 sufficient for that?  Or need 2.10?
15:29:49 <georgk> mattmceuen: 2.9.2 should be fine. The problem is rather in the version difference between the OpenStack component images and the OVS image itself
15:30:35 <georgk> so, we either try to make it work on 2.5.4 as community maintained version using the Xenial image or move to Bionic loci images
15:30:36 <evrardjp> which is why a package is winning in this case, because reusing
15:30:45 <mattmceuen> yep gotcha
15:30:56 <evrardjp> but I guess it's not up to me :)
15:31:20 <evrardjp> I am not fighting this, I just think it will become quite messy when it's about building the neutron images :p
15:31:25 <mattmceuen> I think switching to bionic will require some input from our PTL, but it sounds good to me :)
15:31:44 <georgk> ok, ok
15:31:55 <georgk> I assume switching to bionic has a larger impact
15:32:04 <evrardjp> mattmceuen: I think it makes sense to have a message for those who want the latest and greatest --- that they can have a different base os
15:32:14 <evrardjp> so produce more images basically
15:32:27 <evrardjp> because that enters the realm of the multi-os spec
15:32:29 <georgk> so, we need to look into 2.5.4 first (which is quite old) and if that doesn't cut it, we need to bump to bionic...
15:33:01 <mattmceuen> +1 to both evrardjp and georgk
15:33:22 <evrardjp> georgk: maybe also having a look at UCA would be useful
15:33:36 <georgk> UCA?
15:33:42 <evrardjp> ubuntu cloud archive
15:33:49 * portdirect shudders
15:33:50 <georgk> ah, ok
15:33:55 <georgk> :-)
15:34:06 <georgk> or not, portdirect?
15:34:52 <portdirect> UCA is not exactly 'reliable'
15:35:30 <evrardjp> it is, assuming you are consistent with its use.
15:35:43 <evrardjp> do not mix uca and non uca for example :p
15:35:55 <evrardjp> we've been using UCA in OSA for years without issue.
15:36:02 <evrardjp> it's not epel
15:36:14 <portdirect> and there we differ - i like epel ;D
15:36:31 <portdirect> but I'd fully support a move to bionic - its high time we did
15:36:56 * mattmceuen cheers
15:38:31 <mattmceuen> evrardjp do you have any idea how much bigger than a breadbox moving to bionic would be?  any hidden gotchas or concerns?
15:38:51 <evrardjp> I don't know I haven't tried.
15:39:01 <evrardjp> but the work for suse was straightforward
15:39:04 <portdirect> it would be very simple
15:39:11 <evrardjp> so I don't expect big issues
15:39:15 <mattmceuen> great
15:39:20 <portdirect> just change the source image refs
15:39:23 <evrardjp> we are also building neutron with 1804
15:39:28 <evrardjp> right now
15:39:28 <portdirect> and also the gate/test host
15:39:29 <evrardjp> and it works
15:39:31 <portdirect> yup
15:39:39 <georgk> great, I'll take it
15:39:41 <evrardjp> so I suppose it wouldn't be that hard to build the 1804 images for everyone
15:39:42 <georgk> :-)
15:39:52 <itxaka> famous last words
15:39:59 <evrardjp> hahah
15:40:00 <mattmceuen> thanks georgk
15:40:03 <mattmceuen> ha!
15:40:19 <evrardjp> this still supposes the fact to run on the same host, I expect bumping host to bionic needs to happen too, and might require more work
15:40:21 <georgk> wait, I'll take the resulting images
15:40:36 <evrardjp> georgk: that's not what I understood :p
15:40:42 <itxaka> too late georgk
15:40:43 <mattmceuen> too late georgk
15:40:46 <itxaka> lmao
15:40:46 <georgk> I know!
15:40:48 <evrardjp> hahah
15:40:52 <evrardjp> that's a sign
15:40:58 <evrardjp> we all understood it that way :p
15:41:24 <georgk> yes, yea, the entire community...
15:41:30 <evrardjp> hahaha
15:41:43 <georgk> I am happy to help
15:42:30 <georgk> I might need some pointers
15:43:08 <mattmceuen> evrardjp would you be able to collaborate with georgk on that?  Hopefully it "just works"
15:43:12 <evrardjp> sure, don't hesitate to ask :)
15:43:40 <evrardjp> yeah I am fine with helping.
15:43:47 <mattmceuen> tytyty
15:43:48 <evrardjp> but everyone can help :p
15:43:55 <mattmceuen> for sure
15:44:44 <georgk> thanks
15:44:57 <mattmceuen> alright - I think we've discussed this one pretty well.  Other topics?
15:45:41 <mattmceuen> ok - in that case we can call it a day!
15:45:48 <mattmceuen> thanks everyone for joining
15:45:51 <georgk> ok, thank you all!
15:45:59 <mattmceuen> appreciate your time & your brainpower
15:46:06 <mattmceuen> #endmeeting