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