09:00:12 <flwang1> #startmeeting magnum
09:00:13 <openstack> Meeting started Wed Feb 26 09:00:12 2020 UTC and is due to finish in 60 minutes.  The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:17 <openstack> The meeting name has been set to 'magnum'
09:00:42 <flwang1> #topic 0 worker cluster
09:00:46 <flwang1> brtknr: ^
09:01:21 <brtknr> yes, so i have the patch up, it works, just need to fix the tempest test so that functional-api passes
09:01:38 <brtknr> it allows existing clusters to remove the default-worker too
09:01:53 <flwang1> brtknr: did you try to add node group to the 0 worker cluster?
09:02:21 <strigazi> this needs at least a microversion?
09:02:35 <flwang1> strigazi: +1
09:02:52 <brtknr> i microversioned Nodegroups up
09:03:05 <flwang1> it's an important api change, so a microversion would be good
09:03:28 <brtknr> what else do i need to microversion?
09:04:06 <brtknr> see https://review.opendev.org/#/c/709721/2/magnum/objects/nodegroup.py
09:04:24 <strigazi> brtknr: this is an object version :)
09:04:27 <brtknr> yes i added nodegroup to the zero worker cluter
09:04:53 <flwang1> brtknr: we need api microversion
09:04:58 <strigazi> https://review.opendev.org/#/c/709721/2/magnum/api/controllers/v1/cluster.py@531
09:05:02 <brtknr> nice thing is, a nodegroup with zero workers can linger in the cluster until needed
09:05:07 <brtknr> which i think is quite nice
09:06:12 <brtknr> ok i will take a look at that
09:06:22 <brtknr> but in principal, you both are happy to take it?
09:06:41 <flwang1> brtknr: https://github.com/openstack/magnum/blob/master/magnum/api/controllers/v1/cluster_actions.py#L84
09:06:55 <flwang1> brtknr: i'm happy to get it in
09:07:23 <strigazi> brtknr: https://github.com/openstack/magnum/blob/master/magnum/api/controllers/versions.py#L48
09:07:33 <strigazi> these are api versions ^^
09:07:45 <brtknr> ok cool thank for the links :)
09:07:52 <flwang1> next topic?
09:07:55 <brtknr> will post another PS later today
09:08:23 <flwang1> #topic labels merging
09:08:24 <brtknr> sure lets move on
09:08:46 <flwang1> strigazi: do you know what's the process about the labels merging ?
09:08:59 <brtknr> I'd like to revive this in some way as I expected "merge" to be the default behaviour but looks like all labels from cluster template get discarded which is a bit silly... defeats the point of having a cluster template in the first place. I'd like to see a merge behaviour by default going forward and with an option to replace. Also like the suggestion of a "-" suffix to delete exisiting labels
09:09:01 <brtknr> from the cluster template.
09:09:08 <brtknr> copy paste from https://review.opendev.org/#/c/621611
09:09:36 <strigazi> flwang1: we had a discussion internally. in Decemeber but we never managed to push
09:09:50 <strigazi> something cleaner than the -- and ++
09:09:56 <flwang1> strigazi: do you have a private patch for this?
09:09:57 <strigazi> I can try to dig it up again
09:10:04 <strigazi> we don't have patch
09:10:16 <strigazi> flwang1: fyi our code has always been public
09:10:20 <flwang1> strigazi: it would be much appreciated if you can follow this
09:10:52 <flwang1> personally, i'd like to see we can get this fixed in this cycle
09:10:59 <strigazi> flwang1: the team member pushing this is leaving, we need to regroup
09:11:20 <brtknr> i quite like the label_policy metalabel
09:11:27 <flwang1> strigazi: ok, i see. and please let me know if there is anything i can help
09:11:45 <flwang1> brtknr: good to know you like the idea :)
09:12:06 <brtknr> we kind of need this soon so happy to update Richardo's patch if no objections
09:12:48 <strigazi> label_policy metalabel ? omg
09:12:53 <strigazi> what is this?
09:13:02 <flwang1> strigazi: do you want to lead this or you're happy to let brtknr to take?
09:13:25 <strigazi> can you give me two days to discuss with Ricardo?
09:13:33 <strigazi> if we can't push. Do as you want
09:13:35 <flwang1> strigazi: we don't have to dig into the details at this meeting
09:13:43 <flwang1> strigazi: sounds great
09:13:46 <flwang1> brtknr: happy?
09:13:57 <brtknr> Thanks Feilong. Also not too happy, the code gets weird with this.
09:13:59 <brtknr> There seem to be a few cases when passing labels on cluster create:
09:14:01 <brtknr> 1. we want to replace all cluster template labels with this new set
09:14:03 <brtknr> 2. we want to override some labels, and keep the cluster template values for others
09:14:05 <brtknr> 3. we want to drop some labels from the cluster template set
09:14:07 <brtknr> Would this work?
09:14:09 <brtknr> cluster-template labels: labelx=valuex,labely=valuey
09:14:11 <brtknr> 1. --labels label_policy=replace,label1=value1,label2=value2 -> label1=value1,label2=value2
09:14:13 <brtknr> 2. --labels label_policy=merge,labelx=valuexyz,label1=value1 -> labelx=valuexyz,labely=valuey,label1=value1
09:14:15 <brtknr> 3. --labels label_policy,labelx= -> labelx=,labely=valuey
09:14:17 <brtknr> There's a corner case between not providing a label at all, and providing an empty value - wsme seems to have the Unset type for this case. If we want to follow this, we could add a '-' as a suffix to the label name to explicitly say the label should be dropped from the list. kubectl label works like this.
09:14:19 <brtknr> The 'label_policy' works and i think i'm ok with it, though it's not perfect.
09:14:21 <brtknr> sorry more copy paste
09:14:33 <brtknr> see the 8th comment https://review.opendev.org/#/c/621611/3
09:15:00 <flwang1> brtknr: can we let strigazi discuss this with their team members and he will get back to us
09:15:18 <flwang1> (22:13:24) strigazi: can you give me two days to discuss with Ricardo?
09:15:18 <flwang1> (22:13:33) strigazi: if we can't push. Do as you want
09:15:40 <brtknr> ah sorry didnt see that
09:15:44 <brtknr> yeah sure
09:16:00 <flwang1> thanks, strigazi
09:16:03 <flwang1> let's move on
09:16:29 <flwang1> #topic re tag heat-container-agent
09:16:32 <flwang1> brtknr: ^
09:17:41 <brtknr> thoughts on retagging current ussuri-dev hca as stable-train?
09:17:53 <flwang1> brtknr: why?
09:18:14 <brtknr> for the logs mainly
09:18:38 <strigazi> I can do it now with train-2
09:18:46 <strigazi> never retag
09:18:48 <brtknr> ok sounds good
09:18:48 <strigazi> ever
09:18:59 <brtknr> train-2 is fine
09:19:26 <cosmicsound> this replacement for ussuri-dev?
09:19:35 <flwang1> can we use stable-train.2    ?
09:19:52 <strigazi> https://hub.docker.com/layers/openstackmagnum/heat-container-agent/train-stable-1/images/sha256-c8af38b06b38921e5328291acfe92f63a97ad85c806e54531c70aaf58863b64f?context=explore
09:19:56 <strigazi> train-stable-2
09:20:01 <flwang1> fine
09:20:10 <brtknr> cool thanks
09:20:11 <strigazi> we have train-stable-1 aleady
09:20:43 <flwang1> strigazi: all good
09:20:48 <flwang1> i'm ok with that
09:21:34 <strigazi> done
09:21:42 <brtknr> thanks :)
09:21:51 <flwang1> move on?
09:22:00 <brtknr> yep
09:22:18 <flwang1> #topic ansile os_coe_cluster
09:23:05 <brtknr> i found a bug in os_coe_cluster where it tries to access uuid which doesnt exist, not sure how this passed through the next, must be a change in openstacksdk code
09:24:20 <flwang1> i will take a look later
09:24:28 <flwang1> no idea what happened now :)
09:24:30 <brtknr> ok thanks
09:25:23 <flwang1> #topic another train release?
09:25:45 <flwang1> i prefer to use 9.3.0, i'm not a fan of x.y.1
09:26:15 <brtknr> as you prefer
09:26:24 <flwang1> and it's long list which deserves a bigger release version
09:26:31 <flwang1> strigazi: ^
09:26:41 <flwang1> brtknr: i will review the list tomorrow
09:26:56 <strigazi> I +2 all of them
09:26:58 <brtknr> cool, i am pretty sure i have missed off some of the patches
09:27:06 <brtknr> from the master
09:27:13 <strigazi> do 9.3, no prob
09:28:03 <brtknr> ok thanks
09:28:34 <brtknr> next topic
09:28:45 <flwang1> #topic Post install manifest https://review.opendev.org/676832
09:28:56 <flwang1> strigazi: ^ are you still OK with this idea?
09:30:36 <strigazi> sure, opt-in right?
09:30:48 <flwang1> strigazi: sure, it's opt-in
09:31:26 <flwang1> brtknr suggested to add a label   along with the config
09:31:59 <strigazi> and let users do whatever they want?
09:33:02 <flwang1> technically, user can install something when creating the cluster with the label
09:33:06 <strigazi> brtknr: can you defend the label option?
09:33:21 <flwang1> but it's not on my initial plan
09:33:22 <strigazi> have both?
09:33:30 <brtknr> i prefer the label option tbh
09:33:30 <strigazi> I don't get it
09:34:10 <flwang1> the original requirement for this is, as a public cloud, we'd like to pre-install the storage class
09:34:13 <brtknr> i mean, i dont think we'd ever use the config option, just the label option
09:35:10 <strigazi> the label option for the user is not compatible with the storageclass use case
09:35:25 <strigazi> In the sense, the user will forget
09:35:30 <brtknr> but i can see that label option presents the risk that a user creating the cluster can install anything they want as root
09:35:35 <strigazi> will have typos in the SC and so on
09:36:02 <flwang1> and then break the cluster bootstrap
09:36:20 <flwang1> can we hold the label a bit until we really need it
09:36:21 <flwang1> ?
09:36:35 <brtknr> yes we can hold the label
09:36:45 <strigazi> we can do the config as opt-in first and then we see
09:36:53 <brtknr> happy to take config option for now
09:37:10 <flwang1> cool, thanks, i will post a new patch set
09:37:25 <flwang1> a very productive meeting when we have strigazi
09:37:45 <brtknr> lol yeah the last one got cancelled because you werent here
09:38:00 <strigazi> this was a good one :) I was sick last week, sorry
09:38:19 <flwang1> strigazi: i'm sorry to hear that, i hope you're well now
09:38:34 <brtknr> coronavirus?
09:38:36 <strigazi> all good now, stand by for coronavirus :)
09:38:38 <flwang1> strigazi: btw, will you go to Vancouver ?
09:38:49 <strigazi> brtknr: no just a mild flu
09:38:55 <strigazi> flwang1:  I don't think so
09:39:12 <strigazi> kubecon AMS if it wonnt cancelled
09:39:16 <flwang1> strigazi: ok, then i probably won't go as well if i don't have you and brtknr
09:39:30 <flwang1> kubecon at Boston?
09:39:55 <strigazi> the next US is boston? I don't know about US.
09:40:01 <strigazi> next month is Amsterdam
09:40:07 <flwang1> ah, i see.
09:40:20 <flwang1> i probably go to the Boston one
09:40:23 <flwang1> will see
09:40:32 <strigazi> oh team, I think I found a cli bug yesterday
09:40:51 <flwang1> strigazi: what's that? do you have a patch?
09:41:20 <strigazi> openstack coe cluster resize --nodes-to-remove=0,3 doesn't work. openstack coe cluster resize --nodes-to-remove=0 --nodes-to-remove=3  works
09:41:26 <strigazi> need to double check
09:41:53 <strigazi> with index or uuid should be the same.
09:42:01 <strigazi> keep it in mind. I will test
09:42:07 <flwang1> cool
09:42:16 <flwang1> guys, anything else?
09:42:42 <strigazi> I'm good
09:42:57 <flwang1> cool, thank you for joining
09:43:06 <strigazi> cheers
09:43:08 <flwang1> i need to go to bed :)
09:43:14 <flwang1> #endmeeting