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