14:03:31 <dmellado> #startmeeting kuryr 14:03:32 <openstack> Meeting started Mon Nov 27 14:03:31 2017 UTC and is due to finish in 60 minutes. The chair is dmellado. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:35 <openstack> The meeting name has been set to 'kuryr' 14:03:40 <dmellado> Hi kuryrs ;) 14:03:45 <dmellado> who's here today for the meeting 14:03:47 <dmellado> ? 14:04:00 <irenab> hi 14:04:07 <leyal> hi 14:04:20 <dmellado> #chair irenab 14:04:21 <openstack> Current chairs: dmellado irenab 14:04:40 <dmellado> #chair dulek ltomasbo 14:04:41 <openstack> Current chairs: dmellado dulek irenab ltomasbo 14:04:48 <ltomasbo> o/ 14:04:50 <dulek> o/ 14:05:00 <dmellado> #topic kuryr-kubernetes 14:05:21 <yboaron> 0/ 14:05:27 <dmellado> Hi folks, do you have anything about this topic today? ;) 14:05:40 <dmellado> also, ltomasbo irenab dulek I'll be having you chair this if you don't mind 14:05:47 <dmellado> as I'm in another meeting at the same time xD 14:06:03 <irenab> dmellado: sure 14:06:14 <ltomasbo> dmellado, I'm also at 2 meetings at the same time :) 14:06:21 <irenab> lets have an update on current activities? 14:06:22 <dmellado> ltomasbo: you too?X D 14:06:46 <irenab> dmellado: you should have days without meetings 14:06:49 <dmellado> sure, who wants to start 14:06:54 <dmellado> irenab: I would toally love that 14:07:07 <ltomasbo> Fridays are more or less like that usually 14:07:18 <dulek> Okay, I can start. 14:07:35 <dulek> I'm looking into daemon side VIF choice idea. 14:07:52 <dulek> Here's more info: https://blueprints.launchpad.net/kuryr-kubernetes/+spec/daemon-pool-port-choice 14:08:05 <irenab> dulek: the reason is to have less/no work on the controller side? 14:08:05 <dulek> irenab raised concerns on how this will work with network policies. 14:08:30 <dulek> irenab: Yes, it's to distribute the work. 14:09:01 <irenab> dulek: still keeping worker nodes without the need to access neutron API, right? 14:09:20 <dulek> irenab: That is the plan - all Neutron calls will be done in controller. 14:09:48 <dulek> And controller->CNI daemon "communication" will happen through KuryrPort objects that are CRDs. 14:09:49 <irenab> dulek: so the approuch is strongly built on pre created port pools? 14:10:08 <dulek> 100% based on pools. Is that an issue? 14:10:34 <irenab> I am still concerned about the policies stuff, since not sure how it plays with the pools 14:10:41 <irenab> leyal: any idea on this? 14:10:56 <dulek> I'm having those concerns as well. 14:11:22 <dulek> And that's why it's taking me so long time to even come up with consistent design - it's a lot of moving parts to take care of. 14:11:48 <leyal> I am not sure that i understand exactly what this change means .. 14:12:10 <irenab> dulek: can you please elaborate a bit 14:12:11 <irenab> ? 14:12:26 <dulek> leyal: You're aware how port pools work currently? 14:12:51 <leyal> dulek , yes 14:13:23 <dulek> Okay. So now as we have CNI daemon, which is standalone service that run on every node, we can try to shift some work controller is doing to the CNI daemon. 14:13:53 <dulek> The idea is to leave pool management to controller (shrinking and expanding pools as pods get created or deleted). 14:14:16 <dulek> And move the choice of VIF from the pool to kuryr-daemon. 14:14:40 <dulek> So each kuryr-daemon is aware what ports are assigned to its pool by the controller. 14:14:55 <dulek> And can just choose VIF from the pool in there. 14:15:25 <irenab> while pool is key-ed by node-project-sg, right? 14:15:26 <dulek> Oh and annotate them! 14:15:45 <leyal> so from network-policy prespective - it's mean that the cni should be aware to the SG of POD .. 14:16:31 <dulek> Hm, not sure here really. 14:16:40 <leyal> as it's need to know from which pool it's need to take the interface .. 14:16:59 <dulek> Current pools design doesn't cope too well with updating a SG of the port. 14:17:18 <ltomasbo> yep, updating sg rules are ok 14:17:19 <leyal> currently the SG is part of pool-key .. 14:17:28 <ltomasbo> creating a new one, means a new pool 14:18:03 <irenab> ltomasbo: but policy can be assigned to existing pod 14:18:08 <dulek> Mhm. I'm not sure how network policies are supposed to be modeled - by updating the SG of the port or by creating SG (SGs) for each Network Policy that got created? 14:18:25 <ltomasbo> irenab, but would that mean, changing the sg assigned to it, right? 14:18:27 <leyal> yes , but pod can be attached to many SG's as it's can be assigned to many policies .. 14:18:44 <dulek> irenab: Ah. So there's an issue regardless of my previous question. 14:18:46 <irenab> dulek: please see the proposal: https://review.openstack.org/#/c/519239/ 14:19:07 <irenab> ltomasbo: ^^ 14:19:32 <ltomasbo> an option could be to not delete the ports whose sgs had changed, but putting then back into a new pool 14:20:00 <irenab> which will require coordination between controller and node 14:20:24 <ltomasbo> right now it will not matter if you change the sg of a port, the thing is that when you delete that port, the sg will be reapplied, the initial one 14:20:28 <yboaron> ltomasbo, I didn't understand ,we"ll have pool per SG ? 14:20:29 <irenab> dulek: what details will KuryrPort CRD hold? 14:20:36 <ltomasbo> my mind concern is what to do with the ports on the pool 14:20:49 <ltomasbo> *main 14:21:07 <yboaron> but we should support ports that should be attached to multiple SGs 14:21:10 <ltomasbo> should we leave them, and create new pools? move the ports from a pool to another 14:21:16 <dulek> irenab: Currently I thought of VIF and nodeName it's assigned to, but this is still being thought out. 14:21:25 <ltomasbo> the latter will end up in a chunk of calls to neutron, which will kill the performance 14:21:50 <ltomasbo> yboaron, yes, the key include all the sgs 14:22:16 <dulek> I think the fundamental issue we need to solve first is to connect current implementation of port-pools and network policies. 14:22:30 <irenab> dulek: +1 14:22:32 <dulek> As it sounds to me that designs are not compatible as-is. 14:22:36 <ltomasbo> so, if a port is in 2 sgs (sg_1 and sg_2 )will be in a different pool than another port with just have sg_1 or sg_2 14:22:40 <dulek> Even without the bp I'm working on. 14:22:52 <yboaron> but if for example we should bind SG1,SG2, and SG3 to specific port , from which pool it should be allocated ? 14:23:03 <ltomasbo> dulek +1 14:23:09 <irenab> dulek: but preferably before the one you work on 14:23:28 <dulek> irenab: Totally, I don't want to break everything! 14:23:32 <leyal> dulek , i think that's ok , as the port-pool use group of SG's as key , and we can still can use it in the network-policy .. 14:23:39 <ltomasbo> yboaron, there should be a pool with ports that already have sg1, sg2 and sg3 14:23:43 <irenab> another issue is that now , with policies we will have SGs that can be changed dynamically 14:24:28 <ltomasbo> yes, but we need to consider the performance (regardless of using the pools or not) 14:24:52 <ltomasbo> we definitelly don't want to change the ports at the pool everytime a network-policy change 14:25:01 <irenab> I think we may need a dedicated discussion on pool/policies concern 14:25:05 <ltomasbo> perhaps it is about time to implement the TTL that ivc proposed for the port pools 14:25:08 <dulek> ltomasbo: I'd expect change of network policy to be rather rare. 14:25:17 <ltomasbo> so that when a network policy is created, a new pool is created for it 14:25:33 <ltomasbo> and if the previous one is not use, it will progressively delete the unused ports 14:25:36 <leyal> irenab, do you think that in real-case it's will change Frequently ? 14:25:57 <ltomasbo> also, what type of changes? 14:26:06 <irenab> leyal: no, I think it expresses the application connectivity map, so should be quite stable and predefined 14:26:06 <ltomasbo> if it is adding rules to a sg, there is no problem with that 14:26:23 <ltomasbo> and if there are just changes to running pods, that is also independent of pools 14:26:24 <irenab> but still can be changed 14:26:37 <leyal> ltomasbo , it's not pool per policy as pod can be attached to many policies .. 14:26:43 <dulek> ltomasbo: Change to pod = change to port, isn't it? 14:26:53 <ltomasbo> yes, but not to pool 14:27:07 <ltomasbo> keep in mind that ports that belong to the pools, are the one that are not in use! 14:27:16 <dulek> ltomasbo: But if SG of a port changes, we need to move it to another pool, aren't we? 14:27:25 <dulek> ltomasbo: Oh. Nice. 14:27:34 <ltomasbo> yes, but it will be pretty easy to create a new pool on deletion 14:27:50 <ltomasbo> right now the policy is that if the sg was changed while attached to the port 14:27:56 <ltomasbo> we re-apply SG 14:28:04 <dulek> Okay, I guess me and ltomasbo need to re-review the network policy spec from perspective of pools. 14:28:08 <ltomasbo> but we can do differently and put it back into a new pool 14:28:26 <dulek> ltomasbo: Makes sense. 14:28:50 <leyal> ltomasbo, you mean where pod is deleted ? 14:28:52 <irenab> leyal: lets add a chapter in the policy spec on how it is supposed to work with the pools 14:29:14 <ltomasbo> irenab, leyal: yes, when pod is deleted 14:29:38 <leyal> ltomasbo, +1 14:29:39 <ltomasbo> irenab, leyal: but do the network policy affect anything if there is no pods? 14:29:42 <irenab> even if policy is already deleted? 14:29:53 <ltomasbo> I mean, when you create a new network policy, you just create an SG, right? 14:30:12 <irenab> ltomasbo: correct 14:30:13 <leyal> ltomasbo, yes 14:30:23 <dulek> ltomasbo: Potentially SGs. 14:30:31 <leyal> irenab, will do 14:30:34 <ltomasbo> well, 1-M sgs, 14:30:44 <ltomasbo> but then, you will create a new pod with the new policy 14:30:53 <ltomasbo> which means that it will need the new SG(s) 14:31:00 <leyal> dulek, it's a real SG (maybe not attached to any port ) 14:31:09 <ltomasbo> and the pool will not exist, so kuryr will create 5 (or X) portsto popluate that pool 14:32:10 <ltomasbo> so, that should work, but we'll need a few extra polishing patch set to not leave a lot of leftovers 14:32:20 <ltomasbo> like populated pools that we will no longer use 14:32:49 <ltomasbo> and put back the modified ports on the new pools instead of the previous one 14:32:55 <irenab> ltomasbo: it will create one pool or x num of nodes? 14:33:19 <ltomasbo> no, it just create a pool for a given node/vm 14:33:46 <ltomasbo> right now you do not populate ports in all the nodes, only in the ones with existing pods 14:33:51 <ltomasbo> unless you pre-create them 14:34:13 <irenab> ok 14:35:34 <leyal> ltomasbo, agree for the polishing-patch , and return the port to the new pools .. 14:36:21 <ltomasbo> cool, I'll sync with dulek about the impact of that on the cni side 14:36:45 <dulek> ltomasbo: Okay! 14:37:01 <irenab> ok, lets follow up on the relevant patches and irc channel 14:37:11 <yboaron> leyal, according to your design , every pod ration should end up with adding pod's port to specific SG , right ? 14:37:17 <dulek> I guess I've used enough meeting time. Thanks for all the ideas! 14:37:26 <yboaron> creation 14:37:32 <ltomasbo> xD 14:37:43 <leyal> yboaron, yes (at least to the default .. ) 14:38:26 <yboaron> that means that we still need to access neutron even if we'll have pre-created port m with the right SG's 14:39:12 <irenab> yboaron: unless there are already pool with Policies SGs 14:39:32 <leyal> yboaron, the por on the pool will be attched to the SG .. 14:39:48 <leyal> ports* 14:40:16 <yboaron> leyal, irenab OK got it 14:40:48 <irenab> shall we move to other updates/topics? 14:41:04 <dulek> Yup! 14:41:12 <irenab> dmellado: anything on testing? 14:41:28 <dmellado> irenab: basically testing the multinode gates 14:41:32 <dmellado> before pushing patches 14:41:41 <dmellado> I'm having some issues due to hardware limitations 14:41:45 <dmellado> but WIP 14:42:02 <dmellado> will be deploying mroe gates as soon as I get to properly test them as well as patches for the devstack configs 14:42:13 <dmellado> what I would require, though 14:42:21 <dmellado> is for volunteers to add more scenario tests 14:42:26 <dmellado> anyone up for that? :P 14:43:03 <irenab> dmellado: maybe worth to have some page/etherpad to list future tests, so anyone having free cycle can try to pick one 14:43:20 <dmellado> those are marked on the blueprint 14:43:22 <dmellado> hold on 14:43:42 <dmellado> https://blueprints.launchpad.net/kuryr-kubernetes/+spec/functional-testing-catch-up 14:44:05 <dmellado> I'll be spending some time with gena to cover some of those but will add a whiteboard with the split to be assigned tests 14:44:09 <dmellado> + etherpad to comment 14:44:25 <irenab> dmellado: great, thanks 14:44:28 <dmellado> #TODO (dmellado): create etherpad for scenario tests 14:45:01 <irenab> dmellado: ltomasbo : regarding the matrox of different backends with kuryr 14:45:06 <irenab> matrix 14:45:25 <dmellado> irenab: did you identify something that we were missing? 14:45:40 <dmellado> #link https://blueprints.launchpad.net/kuryr-kubernetes/+spec/enhance-upstream-gates 14:46:11 <irenab> dmellado: I will check 14:46:29 <dmellado> irenab: thanks! 14:47:01 <irenab> #action irenab to check is something is missing at https://blueprints.launchpad.net/kuryr-kubernetes/+spec/enhance-upstream-gates 14:47:15 <irenab> dmellado: thank you for the update 14:47:32 <irenab> any other updates/topics? 14:49:26 <irenab> #topic open discussions 14:49:47 <irenab> any non kuryr-kubernetes related topic to discuss? 14:51:04 <irenab> I just wanted to mention that there is going to be PTG event during the last week of February. as a team we should decide if participate 14:51:56 <irenab> I guess apuimedo will proceed with this dicussionduring the coming meetings 14:52:37 <irenab> well, any other topic or shall we close a meeting a bit earlier? 14:53:47 <irenab> I will count silence as ‘yes ‘to close earlier :-) 14:54:02 <irenab> thank you all for participation 14:54:06 <irenab> #endmeeting