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