15:00:14 <portdirect> #startmeeting openstack-helm
15:00:15 <openstack> Meeting started Tue Aug 27 15:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'openstack_helm'
15:00:19 <portdirect> o/
15:00:29 <portdirect> lets give it a few mins for people to arrive
15:00:43 <portdirect> agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-08-27
15:00:48 <portdirect> #topic rollcall
15:01:13 <srwilkers> o/
15:01:17 <georgk> \o
15:01:41 <howell> o/
15:01:48 <itxaka> \o/
15:01:51 <gagehugo> o/
15:01:59 <Steven-280x> o7
15:02:31 <itxaka> \o/
15:02:31 <itxaka> |
15:02:31 <itxaka> \
15:02:35 <itxaka> buu
15:02:41 <lamt> o/
15:02:44 <itxaka> didnt work, I forgot to escape it
15:03:02 <portdirect> itxaka: that looks painful, i hope you are ok
15:03:22 <mbuil> o/
15:03:59 <portdirect> ok - lets go
15:04:11 <portdirect> #topic - time
15:04:41 <portdirect> hey, just thought i should communicate this - partly as im so excited about it
15:04:48 <mattmceuen> o/
15:05:08 <portdirect> ive recently changed roles within my employer
15:05:20 <evrardjp> oh?
15:05:24 <itxaka> :o
15:05:27 <evrardjp> that's for open discussion?
15:05:31 <itxaka> lmao
15:05:44 <portdirect> and so should now be able to devote an approprite amount of time moving forward
15:06:04 <mattmceuen> portdirect unleashed and unshackled!!
15:06:13 <itxaka> ok, so topi is worng, I read it as "minus time"
15:06:16 <portdirect> i really need to thank both mattmceuen and srwilkers so much for helping cover my absence over the last few weeks
15:06:17 <evrardjp> mattmceuen: haha
15:06:20 <itxaka> like less time
15:06:25 <evrardjp> weren't you already full time portdirect?
15:06:44 <portdirect> yes - but the flux capactitor was broken
15:06:51 <srwilkers> no problem :)
15:07:03 <srwilkers> he's now able to hit 88 miles per hour
15:07:09 <itxaka> great scott!
15:07:14 <Steven-280x> wear a helmet
15:07:15 <evrardjp> srwilkers: itxaka hahaha
15:07:35 <evrardjp> portdirect: I see
15:07:42 <portdirect> anyway - lets move on
15:07:50 <evrardjp> good news, congrats I guess? :)
15:07:56 <portdirect> #topic value overrides for gates
15:08:10 <portdirect> georgk: i think this is you (and also a great topic)
15:08:19 <georgk> thanks
15:08:48 <georgk> primarily just a questions as i ran into this as part of a review on my dpdk patches
15:09:16 <georgk> when checking the gate scripts, they don't use the values_overrides functionality yet
15:09:28 <georgk> I didn't find a good example at least
15:09:46 <georgk> so, shall we extract the gate-specific overrides?
15:10:03 <georgk> and if so, how to model this
15:10:25 <portdirect> its hard, wile we are transitioning for sure
15:10:47 <portdirect> i think neutron and keystone between them offer some good examples here
15:11:44 <itxaka> yeah keystone uses a feature_gate for ldap I think
15:11:51 <portdirect> in particular the keystone ldap job, where we make use of the 'feature gate' functionaility: https://github.com/openstack/openstack-helm/blob/master/zuul.d/jobs-openstack-helm.yaml#L55-L74
15:11:55 <georgk> yes, I saw that
15:12:05 <portdirect> and neutron, where we have release specific over-rides
15:12:08 <georgk> but I wasn't feeling good about modeling a gate configuration as a feature
15:12:15 <itxaka> and I sent one patch today for testing the resource which also uses that: https://review.opendev.org/#/c/678578/
15:12:19 <georgk> like, running non-ha in a gate
15:12:26 <georgk> is that a feature gate?
15:12:35 <portdirect> i think it should be
15:12:45 <itxaka> either a feature or a bug, your choice :p
15:12:51 <georgk> :-)
15:13:11 <portdirect> yeah - 'feature' doesn't always mean good :)
15:13:48 <georgk> so, looking at this https://review.opendev.org/#/c/643284/33/neutron/values_overrides/dpdk-rocky-ubuntu_bionic.yaml
15:14:04 <georgk> I could split this into a gate.yaml and a dpdk.yaml as corresponding overrides
15:14:06 <portdirect> i think this is a good ref for where the term comes from: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
15:14:16 <portdirect> georgk: that would be great!
15:15:03 <georgk> ok, if there is agreement, fine with me
15:15:22 <itxaka> +1
15:15:31 <georgk> I can give it a try, but I'll go on vacation soon, so rihabb will probably take over (just FYI)
15:15:56 <portdirect> georgk: would you mind if I take a poke at the ps sometime this week?
15:16:47 <georgk> please poke it
15:16:57 <georgk> carefully...
15:16:59 <georgk> ;-)
15:17:05 <portdirect> will do :D
15:17:37 * portdirect looks at:
15:17:37 * portdirect https://www.amazon.com/M-Z-Livestock-Electric-Cattle-Batteries/dp/B07GRKK6GP/ref=asc_df_B07GRKK6GP/?tag=hyprod-20&linkCode=df0&hvadid=343257889873&hvpos=1o1&hvnetw=g&hvrand=8404574012282221268&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022859&hvtargid=aud-801381245258:pla-750808049640&psc=1&tag=&ref=&adgrpid=68270154919&hvpone=&hvptwo=&hvadid=343257889873&hvpos=1o1&hvnetw=g&hvr
15:17:37 * portdirect and=8404574012282221268&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9022859&hvtargid=aud-801381245258:pla-750808049640
15:17:55 <evrardjp> oh geez thanks
15:18:05 <georgk> 100% SATISFACTION GUARANTEED
15:18:06 <evrardjp> I totally needed that in my amazon history
15:18:16 <srwilkers> oh, i think i can get that into the office
15:18:22 <evrardjp> EASY TO CARRY -> 31"
15:18:28 <srwilkers> gives me a way to get portdirect's attention when i need to
15:18:40 * portdirect regrets link
15:18:43 <evrardjp> srwilkers: I see
15:18:57 <evrardjp> srwilkers: I thought it was more: https://www.amazon.com/Agrilabs-VetGun-Delivery-System/dp/B00L2G5RSG/ref=pd_sbs_328_1/144-3730140-0510016?_encoding=UTF8&pd_rd_i=B00L2G5RSG&pd_rd_r=dcdad721-2509-453a-858b-7223d52539ca&pd_rd_w=5ou42&pd_rd_wg=5Ed1M&pf_rd_p=43281256-7633-49c8-b909-7ffd7d8cb21e&pf_rd_r=P5SMGN01WZG0D51RG82N&psc=1&refRID=P5SMGN01WZG0D51RG82N
15:19:14 <srwilkers> that's also acceptable
15:19:15 <evrardjp> Only 7 left in stock, get yours soon!
15:19:45 <portdirect> ok - sorry georgk
15:20:20 <portdirect> untill we got distracted with office equipment, was this helpful?
15:20:32 <georgk> :-)
15:20:44 <georgk> yes, I got all the infos I was looking for
15:20:49 <georgk> maybe too much actually...
15:21:11 <portdirect> awesome, thanks dude
15:21:24 <portdirect> #topic mariadb helm chart: Be closer to mariadb upstream helm chart?
15:21:30 <portdirect> evrardjp: i think this is you?
15:22:07 <itxaka> oh my, why did you link those...
15:22:16 <itxaka> now Im on a spiral of reading the comments in there
15:22:34 <itxaka> and yeah, that has to be evrardjp!
15:23:11 <itxaka> "does it work for cats and dogs?"  oh my
15:23:21 <evrardjp> haha
15:23:30 <evrardjp> yeah it's me
15:24:08 <evrardjp> Today a coworker just noticed that our maria helm chart could deserve some love to be image agnostic (due to presence of hardcoded paths)
15:24:39 <evrardjp> As an action item, we'll make that more flexible with the current mechanism we have but...
15:25:07 <evrardjp> The said image is very close to the upstream image on dockerhub, with the same kind of entrypoint etc.
15:25:17 <evrardjp> so my question is the following:
15:25:35 <evrardjp> Should we try again to be closer to upstream mariadb, so that we don't have to maintain it?
15:25:56 <evrardjp> That could be either using the mariadb official helm chart (under beta!) or the mariadb operator
15:26:01 <evrardjp> (under beta!)
15:26:20 <portdirect> so the image is actually based on the upstream image, just with the python k8s client added: https://github.com/openstack/openstack-helm-images/blob/master/mariadb/Dockerfile.ubuntu_xenial#L12-L15
15:26:23 <evrardjp> is there someone evaluating those now that they have gained maturity?
15:26:30 <portdirect> we'd need to review again
15:26:38 <evrardjp> ok
15:26:59 <portdirect> but last time we looked the chart in 'helm/charts' had a couple of differences
15:27:28 <portdirect> its active/passive ratehr than active/active
15:27:39 <evrardjp> here I say there are two sources to look for, but indeed the one in helm/charts is the most visible one
15:27:46 <portdirect> which would make it more useful in some circumstances, and less in others
15:27:47 <srwilkers> it's still set up that way portdirect
15:27:51 <srwilkers> i just took a look
15:28:18 <portdirect> it also had some resulanccy issues in that recovering from a 'hard' outage was very tricky
15:28:33 <portdirect> *resiliency
15:28:43 <portdirect> but this may well have changed?
15:28:47 <itxaka> cant we send our changes to the upstream one? or are they reluctant to be accepted?
15:28:56 <evrardjp> not sure, but was wondering if it was evaluated
15:29:08 <itxaka> upstream = official chart
15:29:10 <evrardjp> itxaka: I like this approach
15:29:21 <evrardjp> I prefer not having to maintain stuff. :D
15:29:33 <itxaka> exactly :D
15:29:33 <portdirect> its cretainly worth a shot - shelling out tech debt is one of the goals we have
15:30:03 <srwilkers> i think it's important to note though
15:30:40 <portdirect> i also remember some security issues, and we'd need to evaluate the alignment of the values layouts
15:30:53 <portdirect> s/values/config
15:30:57 <srwilkers> that while we have a mariadb chart in openstack-helm-infra, i dont think it's the only option for an openstack-helm deployment
15:31:26 <srwilkers> it's just the option we've provided for those looking for a solution that aligns closely with the chart design patterns we've followed
15:31:35 <portdirect> this is very true
15:33:04 <portdirect> its also woth noting the chart in helm/charts relies on logic built into the bitnami images
15:33:10 <srwilkers> so while im not opposed to exploring the deltas, i think at this point it's important to keep in mind the tradeoffs from differing points of view
15:33:22 <evrardjp> srwilkers: what's the alternative? Because I think the design patterns are not broad, so it might require some hard work. But I agree on the fact it's free for the user, which is what I like :)
15:33:46 <evrardjp> srwilkers: it would be nice to list and document those
15:34:04 <evrardjp> I mean things are done for a reason, yet it's not explicit, because it's not documented
15:34:28 <evrardjp> then it is in the memory of a few, which might or might not be active in the project anymore
15:35:12 <evrardjp> anyway, I have my answer, thanks for the info!
15:38:20 <portdirect> ok - i think thats it for the agenda this week
15:38:40 <portdirect> any other topics we should be aware of before moving into reviews?
15:40:06 <portdirect> #topic reviews
15:40:30 <portdirect> one of the services we have been sorely lacking is designate
15:40:39 <portdirect> so its great to see a chart come in for it:
15:40:46 <portdirect> https://review.opendev.org/469981 (Designate chart)
15:41:10 <portdirect> one of the chalenges with this service has been gettign a backend that works well in k8s
15:41:37 <portdirect> in a past life, i had to do this (not fun), and ended up with the same conclusion as the author has here
15:42:00 <portdirect> in that powerdns seems to make the most sense as an initial backend to leverage: https://review.opendev.org/676142 (PowerDNS chart)
15:42:08 <portdirect> (in turn using mysql)
15:42:29 <alanmeadows> the layers run deepeth
15:42:33 <portdirect> would be great to see these merged, and then neutron updated to be able to take advantage of them
15:44:27 <portdirect> also georgk's and cheng1 's ovs dpdk work is in the final straight - lets get it home
15:45:11 <srwilkers> sounds good to me
15:45:12 <georgk> +1 :)
15:47:36 <portdirect> ok - if thats it lets give everyone 10 mins back
15:47:48 <portdirect> thanks everyone, see you in #openstack-helm
15:47:53 <portdirect> #endmeeting