15:00:34 <portdirect> #startmeeting openstack-helm
15:00:34 <openstack> Meeting started Tue Sep 24 15:00:34 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <openstack> The meeting name has been set to 'openstack_helm'
15:00:46 <portdirect> hey folks, lets give it a few mins for people to arrive
15:00:56 <itxaka> \o
15:00:58 <itxaka> o/
15:00:58 <portdirect> the agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-09-24
15:00:58 <lamt> o/
15:01:01 <itxaka> \o/
15:01:15 <portdirect> itxaka: good to have you back :D
15:01:32 <stevthedev> o/
15:01:37 <jsuchome> o/
15:02:03 <srwilkers> o/
15:03:07 <megheisler> \o
15:04:05 <howell> o/
15:04:20 <portdirect> ok - lets get going
15:04:21 <roman_g> o/
15:05:00 <portdirect> #topic Make probe configs its own key in values?
15:05:07 <portdirect> itxaka: floor is yours
15:05:11 <itxaka> yay!
15:05:50 <itxaka> mainly what it says, currently the config for the probe options is mixed together with the pod policies, which in some cases makes it difficult to find them and to see what the values are
15:06:29 <itxaka> not only that but we use an ugly way of printing them to the values which if I could I would burn because they are totally unreadable
15:06:53 <itxaka> I value readability over commodity and tbh, htk is full of terrible unreadable things
15:07:22 <itxaka> so seeing that the probe function was recently introduced, I would propose a different approach to the probes that you can see on https://review.opendev.org/#/c/683220/
15:07:34 <itxaka> just a simple key for them and a toyaml in the templates
15:08:03 <itxaka> no more 300 chars functions that you need to look up and decipher from htk to understand what they do
15:08:20 <portdirect> theres a lot to unpack here
15:08:40 <portdirect> and i certainly am no fan of the sprawl of gotpl we have in htk
15:09:10 <portdirect> but we also need to consider some of the other aspects as to why we got here
15:09:35 <portdirect> we maintain a huge number of charts in this project
15:10:00 <portdirect> and key to our success is constency in configuration input to them
15:10:26 <portdirect> and also the ability to make improvements across the project simply
15:10:52 <portdirect> the htk funcations as they are today enable this, and also allow us to improve uniformly as well
15:11:14 <itxaka> mmmh...
15:11:42 <itxaka> I do agree that for some parts of common functions htk is a godsend, because we can fix or improve something i one place and it gets propagated
15:11:51 <itxaka> but for probes?
15:12:11 <jsuchome> is there a compromise possible? function in htk but not the crazy one as it is currently but something more like itxaka's proposal?
15:12:23 <itxaka> is there something expected to change in the probe configuration that would warrant having a function (which actually just does toYaml) for this?
15:13:38 <portdirect> itxaka: that case is accommodated for: https://github.com/openstack/openstack-helm-infra/blob/master/helm-toolkit/templates/snippets/_kubernetes_probes.tpl#L55
15:13:38 <itxaka> I do understand this on endpoints or dns or something that its complex
15:14:11 <itxaka> but this is pretty straigthforward and it hurts my heart to see that complexity for no good reason
15:14:16 <portdirect> a good example is neutron and nova, where in production environments we many need to change the probe to refelct operating condidtions
15:14:41 <portdirect> also with a simple toyaml - how would you disable the probe if desired?
15:15:43 <itxaka> if you disable the probe then you have bigger problems than complexity :p
15:16:09 <portdirect> welcome to the real world :D
15:16:10 <itxaka> thats actually a good point, I did not think of probe disabling as I would not expect anyone to actually disable a probe lmao
15:17:06 <itxaka> ok, point taken, that kind of makes sense if you are crazy and disable probes
15:17:47 <portdirect> itxaka: sometimes you need to as the world is full of crazy things
15:18:11 <portdirect> eg recently we had a case where a site was using the fluent logger, which is blocking
15:18:11 <itxaka> ok then its settled and I would die a little bit everytime that I use that function
15:18:17 <portdirect> fluentd was down
15:18:23 <jsuchome> that change (introducing this _kubernetes_probes.tpl) is quite new, if it is that needed, how did people disable probes before?
15:18:30 <portdirect> we needed to disable the probes to stop the rot spreading
15:18:38 <portdirect> now this is a bad edge case
15:19:01 <itxaka> so the probe helper came from there? lmao
15:19:03 <portdirect> but the sort of stuff that we can cope with through having a common well developed function
15:19:12 <itxaka> still a good thing to have stuff that comes from real issues
15:19:29 <portdirect> no - just an example of why having every chart differnt means we loose the benefit of having a common function
15:19:42 <itxaka> +1 for me to move on from this issue as I consider it settled
15:19:49 <itxaka> unless jsuchome has something to say about it?
15:20:16 <portdirect> jsuchome: re your q - kubectl edit :screams:
15:20:18 <jsuchome> I had hopes to see a code that even I can understand
15:20:44 <jsuchome> ah
15:21:17 <portdirect> i think this convo raises a really good point though
15:21:25 <itxaka> I thought you could not disable probes via kubectl edit :o
15:21:42 <portdirect> itxaka: you can do anything with a big enough hammer
15:22:05 <portdirect> you can though for all but statefulsets
15:22:09 <portdirect> `no more 300 chars functions that you need to look up and decipher from htk to understand what they do`
15:22:17 <portdirect> ^ this is so true
15:22:21 <itxaka> yeah tpl is terribleeeee
15:22:30 <portdirect> and somthing we need to solve for
15:22:59 <portdirect> I'll put it on the agenda for next week - and lets see if we can think of better ways in the mean time?
15:23:09 <itxaka> +1
15:23:49 <jsuchome> I would just think that if disabling is the main issue, there might be a chance to make it possible with simpler method ... but I do not have specific idea now, so let's move on
15:24:16 <portdirect> #topic Time to make zuul RELEASE-OS jobs voting?
15:24:23 <portdirect> itxaka: your up :D
15:24:44 <itxaka> me again?
15:24:52 <itxaka> yeah what it says, not much to expand
15:25:05 <portdirect> i think its time
15:25:05 <itxaka> should we already move those into voting? Its been a long time with no progress there
15:25:14 <itxaka> some may be broken and we are just ignoring them
15:25:23 <itxaka> and we are already running them, what a waste of good resources!
15:25:42 <portdirect> yeah - i think we should get a ps in today to flip them, unless anyone objects
15:26:23 <itxaka> yay |o/
15:26:27 <portdirect> ok - lets do it itxaka and jsuchome :D
15:26:39 <itxaka> yay yay \o/
15:26:46 <itxaka> whos sending the ps?
15:26:48 <portdirect> im excited - finally get suse voting, and a less historic openstack release
15:27:15 <portdirect> itxaka: you ok with pusing it?
15:27:21 <itxaka> yup!
15:27:23 <portdirect> or jsuchome - then we can both get it in
15:27:45 <itxaka> suse, ubuntu or all of them? Or several separated patches?
15:28:24 <jsuchome> sorry I wasn't following, I could (so itxaka can use his +2), but I'll leave the honors of creating PS to him
15:28:41 <portdirect> roger - thanks
15:28:45 <portdirect> ok - lets move on
15:28:56 <portdirect> #topic Was there a plan to unite various (bash) deployment scripts?
15:28:58 <jsuchome> (I think if they are stable anough, let's do them all in one patch)
15:29:04 <portdirect> jsuchome: agreed
15:29:24 <portdirect> also i think this is you?
15:29:33 <jsuchome> yes: so, I remember that some time ago we voluntered to work on those deployment scripts
15:29:45 * itxaka runs
15:29:50 <jsuchome> but then I think someone had an AI to lay out some plans first
15:30:25 <jsuchome> so I was wondering, if there's a specific plan, or if I could just start digging and propose something...
15:30:49 <portdirect> jsuchome: i put a few thoughts in the etherpad
15:30:56 <jsuchome> yeah, and also evrardjp said he used to have some ideas about this some time ago, I'm not sure if it went in the same direction
15:31:13 <portdirect> but i think its high time we pruned a lot of the old scripts that are gathering dust
15:31:27 <evrardjp> yeah let's clean everything !
15:31:40 <itxaka> +1
15:31:46 <portdirect> jsuchome: it went in a very similar direction to what evrardjp was proposing, just in bash rather than ansible
15:31:46 <jsuchome> so basically the plan is to take developer + multinode scripts and combine them with component ones?
15:31:53 <portdirect> though he can keep me honest there
15:31:54 <jsuchome> and he's alive! (evrardjp)
15:32:04 <evrardjp> (in another meeting)
15:32:11 <evrardjp> (sorry)
15:32:17 <portdirect> jsuchome: that would seem like the best place to start
15:32:36 <jsuchome> ok then, I'll try to start there
15:32:46 <itxaka> everything merged *and* in ansible? Is this a dream?
15:32:58 <portdirect> w00t - that would be great jsuchome
15:33:07 <portdirect> itxaka: steady now
15:33:15 <jsuchome> I did not promise ansible itxaka!
15:33:25 <itxaka> :(
15:33:38 <itxaka> I read ansible somewhere and got excited
15:33:43 * jsuchome whispers there's not enough chef in this ecosystem...
15:33:59 <portdirect> i think we should be looking to add over-rides to allow the `component` scripts to forfil the same functions as the developer and multinode ones do today
15:34:15 * portdirect would like some puppet
15:34:22 <itxaka> omg stop it
15:35:24 <itxaka> portdirect: like with the features I guess?
15:35:35 <itxaka> so multinode would be a feature?
15:35:55 <itxaka> "feature" in the sense of feature gates and overrides of course
15:36:04 <portdirect> itxaka: i think so
15:36:09 <itxaka> +1
15:36:33 <portdirect> unless we want multinode to be the default, and 'singlenode' to be the (anti) feature?
15:37:09 <itxaka> do we expect other that POCs and Developers to deploy single node deployments?
15:37:17 <itxaka> IMO should test the most common scenario
15:37:39 <portdirect> i think to be honest - single node is the most common senario
15:37:59 <itxaka> then single node as the default should be
15:38:02 <portdirect> so perhaps leave it that way to simplify people starting out?
15:38:25 <jsuchome> hm, most common senario for playing around, but production?
15:39:12 <portdirect> oh my - so production is hard - in that we (putting work hat on) typically run >20 replicas of apis etc
15:39:47 <portdirect> and other config params that would rule out anything other than large(ish) deployments
15:39:51 <jsuchome> you mean you don't even use those scripts?
15:40:01 <itxaka> well mostly the difference between 2 and 20 replicas is not much rigth?
15:40:02 <portdirect> not for production no
15:40:15 <itxaka> is most about the single pod vs multipod (no matter the number) deployments
15:40:25 <portdirect> for that id reccomend a datacenter lifecycle tool like (wait for it)
15:40:26 <portdirect> ...
15:40:27 <portdirect> airship
15:40:30 <itxaka> nooooo
15:40:45 <jsuchome> and here we are
15:41:14 <jsuchome> ok, so it's settled, multinode is the feature that needs to be turned on
15:41:20 <portdirect> sounds good
15:42:07 <portdirect> #topic Release notes? Abandoned? Enforced? Ignored?
15:42:31 <itxaka> ah I just moved that below because I dont want us to run out of time for roman_g topic
15:42:52 <portdirect> ah - ok, lets come back to this
15:42:53 <portdirect> 2 sec
15:43:07 <portdirect> #topic Zuul Promote jobs are failed, logs are hidden
15:43:12 <portdirect> roman_g: floor is yours
15:44:02 <roman_g> Just wanted to say that jobs failed
15:44:18 <roman_g> AFAIK we don't have notification for post merge jobs
15:45:10 <roman_g> I'm guessing if this is normal, or is it being taken care of already, or I can request logs and investigate
15:45:18 <roman_g> ?
15:45:32 <roman_g> Promote jobs
15:45:33 <roman_g> https://review.opendev.org/#/c/672678/
15:46:16 <portdirect> evrardjp: is our resident sme in this area
15:46:37 <itxaka> you it would be nice to be able to see those logs while filtering any secrets in there otherwise its a black box
15:46:43 <roman_g> That's hist patch, btw :)
15:46:46 <roman_g> *his
15:47:02 <itxaka> evrardjp is currently on a meeting so he wont be available unfortunately :/
15:47:24 <portdirect> when hes escaped, you we ok to discuss this in #openstack-helm?
15:48:24 <itxaka> +1
15:49:04 <portdirect> ok - thanks for bringing this up roman_g and also digging into it
15:49:12 <portdirect> lets take it to the channel when evrardjp is around
15:49:30 <portdirect> #topic Release notes? Abandoned? Enforced? Ignored?
15:49:43 <roman_g> itxaka: I would be gone home in 20 min. or so. Couldn't participate, but highlight me if needed, I will read tomorrow.
15:50:19 <itxaka> As it says, we dont have much movement in release notes so I wonder what should we do. Do we want to start -1 ps with no release notes for important stuff or we just go ahead and fully ignore them?
15:50:24 <itxaka> roman_g will do, thanks!
15:51:45 <lamt> I was thinking about reno the other day as there is a lot of network policies work inflight - but since we don't have any "releases" per se, it feels like additional administrative work.
15:51:49 <jsuchome> that seems like a good idea, but what is "important stuff" ?
15:52:10 <roman_g> what product manager decides to be important
15:52:20 <portdirect> i'm inclined to agree with lamt
15:52:39 <portdirect> in that at the moment it generates admin overhead, that im not sure pays off
15:52:58 <portdirect> untill we can at least solve the problem of `what is "important stuff"`
15:53:15 <itxaka> agreed
15:53:26 <portdirect> so im inclined to say ignore for now?
15:53:55 <lamt> ++
15:54:20 <itxaka> +1
15:55:04 <portdirect> #topic the long lost, and partly forgotten openstack-objects chart
15:55:13 <itxaka> yay
15:55:23 <itxaka> so there may be some work coming for that
15:55:31 <itxaka> as there has been some recent interest on it
15:55:32 <portdirect> awesome!
15:55:42 <itxaka> so its not fully forgotten but pretty down in the backlog
15:55:50 <portdirect> yes - it would tie in nicely to the gate pruning as well
15:55:57 <itxaka> that point was just a informative note
15:56:07 <portdirect> ok - thanks dude
15:56:16 <portdirect> #topic Helm3 plans
15:56:23 <itxaka> me again
15:56:31 <portdirect> we wont have time for all of this today
15:56:43 <portdirect> but in summary - we dont have any direct plans at this time
15:56:56 <portdirect> as the charts will all work with helm3
15:56:58 <jsuchome> have you seen that video? Is it worth watching?
15:57:00 <itxaka> indeed we dont, some guy just filled up the topic etherpad
15:57:14 <portdirect> itxaka: and thats why we love you
15:57:29 <itxaka> what about the library charts? any plan to move htk into that?
15:57:36 <itxaka> mostly interested in that
15:57:56 <portdirect> itxaka: we should, as htk was very much one of the drivers behind that feature ;D
15:58:02 <itxaka> oooh
15:58:16 <evrardjp> library charts I guess
15:58:37 <portdirect> it would also be a good time to address if possible some of the concerns raised at the start of the meeting
15:58:41 <evrardjp> (catching up)
15:58:54 <portdirect> in that when we move to a library chart, we should also clean up htk
15:59:02 <itxaka> moving to lua?
15:59:02 <portdirect> rather than take it all with us
15:59:12 <portdirect> thats a possible outcome
15:59:30 <portdirect> i think it would be good to have howell involved in these convos to
15:59:30 <evrardjp> portdirect: that sounds fair, but how will you make sure you don't break customers, as you don't have stable versioning yet ?
15:59:41 <itxaka> ٩( ๑╹ ꇴ╹)۶
15:59:52 <portdirect> evrardjp: with great care ;D
15:59:59 <evrardjp> and a lot of shas!
16:00:00 <evrardjp> :)
16:00:02 <portdirect> lol
16:00:15 <portdirect> we should def start next week on this topic
16:00:29 <portdirect> thats all the time we have today folks - thanks so much for coming
16:00:33 <portdirect> #endmeeting