09:02:37 <flwang1> #startmeeting magnum 09:02:37 <openstack> Meeting started Wed May 6 09:02:37 2020 UTC and is due to finish in 60 minutes. The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:02:41 <openstack> The meeting name has been set to 'magnum' 09:02:54 <flwang1> strigazi: i just approved the labels spec 09:03:08 <flwang1> ttsiouts can start the work now 09:03:17 <strigazi> #topic labels override 09:03:36 <ttsiouts> o/ 09:03:50 <flwang1> strigazi: i kind of agree with you that we shouldn't use the config option to 'break' the api 09:04:00 <strigazi> I left a comment about the name, I did some deep reseach on wording 09:04:03 <flwang1> so i'm ok leave it as False 09:04:23 <flwang1> strigazi: yep, i saw that. and I appreciate your work 09:05:11 <strigazi> It turns out merge is more to the point... I think I initially proposed override :( 09:05:16 <openstackgerrit> Merged openstack/magnum-specs master: Magnum Labels Override https://review.opendev.org/716571 09:05:24 <strigazi> Based on method overriding 09:05:28 <ttsiouts> so should we go with 'merge' instead? 09:06:03 <ttsiouts> if so, I need to change the spec also 09:06:32 <strigazi> I think since we are just on the name discussion and for the "real" issues we have agreement, we can start polishing the implementation 09:06:40 <flwang1> strigazi: are you saying that you're voting 'merge'? 09:06:40 <strigazi> the name will be just a sed 09:06:54 <flwang1> strigazi: +1 09:07:00 <flwang1> ttsiouts: pls focus on the code part 09:07:13 <ttsiouts> flwang1: sure 09:07:15 <flwang1> we can continue the name discussion there and update the spec later 09:07:45 <ttsiouts> since we are discussing about this now, could we we decide on the name now also? 09:08:08 <ttsiouts> I think we all need this to get merged asap 09:08:15 <strigazi> naming is "hard" but it's a detail. Without brtknr we will go back to drawing when he joins 09:08:49 <flwang1> ttsiouts: i have approved the spec already 09:09:18 <strigazi> So it is megred too \o/ 09:09:31 <ttsiouts> \o/ 09:09:36 <flwang1> yep, i think strigazi and I agree to use 'merge', but we'd like to get a 'yes' from brtknr anyway :) 09:09:52 <ttsiouts> great! 09:10:21 <strigazi> so for you it's a go :) 09:10:58 <ttsiouts> flwang1, strigazi: great! thanks a lot for your effort 09:11:09 <flwang1> ttsiouts: thank you! 09:11:15 <flwang1> strigazi: move on? 09:11:30 <strigazi> yes 09:12:29 <strigazi> For nodes list 09:12:36 <flwang1> yes 09:12:40 <strigazi> flwang1: we go with ng node list 09:12:44 <strigazi> and then we see? 09:13:01 <flwang1> i have got new comments from Thomas and i'm happy with it 09:13:04 <flwang1> did you see it? 09:14:18 <flwang1> strigazi: IIUC, currently, we just need the nodes list based on a given NG 09:14:35 <strigazi> flwang1: exactly what I was typing 09:14:58 <flwang1> and i think we have no choice, we need to build it in memory but query heat and nova 09:15:28 <strigazi> flwang1: for an nodegroup, you can get the nodes with one heat call 09:15:32 <flwang1> the tricky part maybe the pagination, but i prefer to leave the pagination later, are you ok with that? 09:15:55 <flwang1> strigazi: yep, i know, i should say 'may be need call nova (or not)' 09:16:36 <flwang1> because Thomas mentioned he need the status and reason of the instance, so i'm not 100% sure if heat can provide that info or not 09:16:38 <strigazi> flwang1: we don't need calls to nova at this point. 1. heat does many calls to nova already. 2. We cut through the stack 09:16:51 <flwang1> that's details 09:16:53 <flwang1> i will figure out 09:17:14 <flwang1> are you ok do the pagination later? 09:17:14 <strigazi> flwang1: We can get status from heat too. 09:17:17 <strigazi> yes 09:17:22 <flwang1> wonderful 09:17:40 <strigazi> assuming we support up to 1000 nodes? 09:18:02 <strigazi> or there is no max? 09:19:03 <strigazi> flwang1: ^^ we just return all the info we have 09:19:32 <flwang1> what's the max size cluster in cern? 09:19:41 <flwang1> k8s can support 5k i think 09:19:54 <flwang1> but i don't think it's a common case in prod 09:20:22 <flwang1> especially given it's a one NG, not the whole cluster 09:20:41 <strigazi> I don't think we go over 500 atm 09:20:56 <strigazi> only for testing. Anyway, pagination lter 09:21:08 <strigazi> I'll leave a comment on gerrit 09:21:11 <flwang1> cool 09:21:16 <flwang1> thanks, man 09:22:01 <strigazi> One more from me: Support Helm v3 https://review.opendev.org/#/c/720234/ 09:22:16 <strigazi> Do you agree since we refactor to do a metachart? 09:22:24 <strigazi> I have all info about it in gerrit 09:23:42 <flwang1> i haven't gone through all the comments there, but as long as we don't break v2, i'm ok with that 09:25:04 <flwang1> do you have any concern? 09:25:25 <strigazi> it is fully compatible with v2 09:26:05 <strigazi> the charts we use are simple. Users/Operators could pick v3 or v3 09:26:15 <strigazi> the charts we use are simple. Users/Operators could pick v3 or v2 09:26:21 <flwang1> then i'm happy 09:28:37 <strigazi> Next, this can be merged 09:28:39 <strigazi> https://review.opendev.org/#/c/725391/ 09:29:11 <strigazi> some eventlet nonsense but needed 09:29:20 <flwang1> done 09:29:56 <strigazi> I think that's it 09:30:40 <strigazi> I'll finish the storyboard clean up now, and we are fully on with reviews and tasks. 09:32:35 <flwang1> strigazi: if you have time, it would be nice if you can take a look https://review.opendev.org/#/c/714347/ 09:34:01 <strigazi> This is a mapping? 09:34:31 <flwang1> what do you mean 'mapping'? 09:34:49 <strigazi> [az1, az2, foo] master-0 -> master-1 -> az2 master-2 -> foo 09:34:54 <flwang1> yes 09:35:29 <flwang1> master0-> az1, master 1> az2, master2 -> foo 09:37:07 <strigazi> There is no other way? server group spread on AZs? 09:37:34 <flwang1> can server group spread on AZs automatically? 09:37:47 <flwang1> i don't know,i need to do some research 09:38:24 <flwang1> i have another question about multi masters 09:38:44 <strigazi> I checked, not 09:38:48 <strigazi> I checked, no 09:38:55 <flwang1> IIRC, you mentioned that there is no LB (eg. octavia ) in CERN 09:39:08 <strigazi> This changed two weeks afo 09:39:10 <strigazi> This changed two weeks ago 09:39:14 <flwang1> so how do you use multi masters? 09:39:27 <strigazi> Today we are opening multimaster to all users. 09:40:00 <flwang1> so user can use ip0, ip1 and ip2 to access the k8s api? 09:40:22 <strigazi> one virtual ip 09:40:22 <flwang1> e.g. a 3 master nodes 09:40:57 <flwang1> can magnum support the virtual IP without lb? 09:41:03 <flwang1> i even don't know that 09:41:33 <strigazi> there is no LB (eg. octavia ) in CERN -> This changed two weeks ago 09:41:48 <flwang1> ok 09:41:55 <flwang1> i mean before that 09:41:56 <strigazi> or 4 weeks? ttsiouts when we opened LB 09:42:06 <strigazi> before that single master only 09:42:15 <flwang1> aaaaaaaaahhh 09:42:25 <flwang1> fair enough 09:42:40 <flwang1> i'd like to introduce a new field for cluster creation 09:42:55 <strigazi> master-lb-enabled ? 09:43:06 <flwang1> clever boy 09:43:06 <strigazi> excellent 09:43:29 <strigazi> +2 09:43:29 <flwang1> do you want to understand more background? 09:43:58 <flwang1> in CC, we're providing 2 templates for each version 09:43:59 <strigazi> not differnt CTs for single VS multi-master 09:44:01 <flwang1> dev and prod 09:44:19 <flwang1> one of the main difference is the lb 09:44:27 <strigazi> yeap, got it 09:44:28 <flwang1> we'd like to merge it to one 09:44:33 <strigazi> same here 09:45:01 <flwang1> and along with the labels merging, it would make our life much easier 09:45:15 <strigazi> sounds good to me 09:45:16 <flwang1> fantastic 09:46:06 <strigazi> I think ttsiouts implement the two features with the biggest influence to remove user pain 09:46:18 <strigazi> * implemented 09:46:25 <strigazi> labels are coming fast 09:46:34 <flwang1> which 2? 09:46:42 <flwang1> labels and ? 09:46:44 <strigazi> nodegroups and labels 09:46:49 <flwang1> right 09:46:50 <flwang1> yes 09:47:01 <flwang1> nodegroup is a very good one 09:47:14 <strigazi> different flavors with ngs, no hacks for labels 09:47:14 <flwang1> i really appreciate the contribution from CERN 09:47:42 <strigazi> ttsiouts++ 09:47:55 <flwang1> kudos on ttsiouts 09:48:28 <ttsiouts> strigazi, flwang1: thank you guys for all the reviews and ideas! 09:48:50 <flwang1> strigazi: can i book you for another 12 mins? 09:48:52 <strigazi> ttsiouts: :) flwang1: Anything else? I mean to discuss not for ttsiouts 09:49:00 <strigazi> tell me 09:49:20 <flwang1> i proposed a patch about the security group hardening 09:49:49 <strigazi> right, you restored it 09:49:57 <flwang1> but my original one was too strict, i'd like to improve it to set the security group rules based on the FIP and LB setting 09:50:43 <flwang1> or maybe a new label from user to set the security rules dynamically 09:51:03 <flwang1> in short, by default, it will be same as now 09:51:30 <flwang1> but it can be hardened if user prefer to 09:52:14 <flwang1> i know it may be not sounds very charming for CERN or StackHPC, but i believe mnaser will like it 09:52:21 <flwang1> strigazi: ^ 09:52:32 <flwang1> and CityNetworks 09:52:53 <strigazi> +1, I think we can have some reasonably secure default sec-groups. What do you want to pass on cluster creation? 09:54:00 <strigazi> extra rules? 09:54:13 <flwang1> for example, if lb enabled, then master nodes shouldn't open port to 0.0.0.0/0, but only the fixed network range of the cluster 09:54:16 <strigazi> or in th CT 09:54:33 <flwang1> i'm still in the design 09:54:42 <flwang1> in CC, we just hardcode the rules now 09:54:50 <flwang1> but it doesn't fit for upstream 09:55:08 <flwang1> but before i put more effort to dig, i'd like to get a general approval from you guys 09:55:28 <flwang1> to make sure community like the improvement direction 09:55:30 <strigazi> does this help? https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#check-required-ports 09:56:27 <flwang1> yes, and actually we know all the port clearly so far. and we verified with sonobuoy 09:56:45 <flwang1> i just need a new design to update the security group rules on the air 09:57:36 <flwang1> and it would be a bit hard, i can imagine 09:57:36 <strigazi> If we follow what this link says plus a way to pass a security group per nodegroup you don't need anything else, no? 09:58:06 <flwang1> let me give you an example, if user is using flannel, should we allow calico port? 09:58:21 <strigazi> no 09:58:38 <flwang1> or it's ok if it's only allowed within the network scope? 09:58:44 <flwang1> is it ok 09:59:17 <strigazi> as mentioned here, no: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#worker-node-s 09:59:33 <strigazi> the bgp ports are closed. 10:00:03 <strigazi> So they need to open within the cluster network only if calico is used 10:00:17 <flwang1> right, that's easy 10:00:22 <flwang1> ok 10:00:39 <flwang1> i will refactor the patch and invite you guys to review it 10:00:48 <flwang1> thank you all your valuable input 10:01:13 <strigazi> sure thing 10:01:25 <flwang1> have a nice day, ttyl 10:01:32 <strigazi> bye 10:01:39 <flwang1> o/ 10:01:43 <strigazi> don't forget to end the meeting 10:01:50 <strigazi> flwang1: ^^ 10:02:16 <strigazi> #endmeeting 10:02:29 <strigazi> I don't think I can do it 10:31:02 <openstackgerrit> Merged openstack/magnum master: Monkey patch original current_thread _active https://review.opendev.org/725391 10:31:15 <frickler> #endmeeting