14:01:19 <dmellado> #startmeeting kuryr
14:01:20 <openstack> Meeting started Mon Mar 19 14:01:19 2018 UTC and is due to finish in 60 minutes.  The chair is dmellado. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:24 <openstack> The meeting name has been set to 'kuryr'
14:01:32 <dmellado> Hi fellow kuryrs, who's here today for the meeting?
14:02:08 <dulek> o/
14:02:13 <yboaron_> o/
14:02:17 <ltomasbo> o/
14:02:55 <irenab> hi
14:03:14 <dmellado> #chair dulek yboaron_ ltomasbo irenab
14:03:15 <openstack> Current chairs: dmellado dulek irenab ltomasbo yboaron_
14:03:32 <kaliya> o/
14:03:45 <dmellado> Hi kaliya
14:03:48 <dmellado> so, let's start
14:03:57 <dmellado> #topic kuryr-kubernetes
14:04:18 <dmellado> I wanted to share with you that after a few days of CI crisis we should be fine for the time being
14:04:50 <dmellado> I'll be trying to decouple a few dependencies
14:05:09 <dmellado> so if you've any patch that failed recently, and specially with post_failure, please do recheck it
14:05:14 <dmellado> it might not be your fault
14:05:35 <dmellado> I'll be also adding some multinode gates during the upcoming days, now with proper services split
14:05:42 <dmellado> 2 and 4 nodes, probably
14:05:55 <dmellado> so, besides that, who has something that would love to share? :P
14:07:18 <irenab> dmellado, is there any news regarding sr-iov/dpdk patches?
14:08:01 <dmellado> irenab, not really, maybe kaliya can update us on that
14:08:29 <dmellado> I asked the intel foiks to update the blueprint with their contributions/info
14:08:34 <kaliya> not much. I know danil is working on rebasing the sr-iov part. For the nested part, I saw somewhere some binary file including some Intel patch
14:09:05 <dmellado> https://blueprints.launchpad.net/kuryr-kubernetes/+spec/nested-dpdk-support
14:09:36 <dmellado> kaliya: yeah, they sent us a diff file but I asked them to put a proper review so we could take a look and review
14:09:51 <dmellado> tbh I was hoping that Gary was on the call today to ask him about that
14:09:58 <dmellado> irenab: Will send him an email ad cc you
14:10:11 <irenab> dmellado, thanks
14:10:14 <dmellado> kaliya: thanks on the sriov side, btw
14:10:18 <kaliya> yes, that diff has some syntax issues, thank you dmellado
14:10:36 <yboaron_> Question: Do we plan to merge the multi vif/dpdk/sr-iov patches in current approach, or to wait/sync with what vikasc presented
14:10:44 <dmellado> also tbh I would bet on that diff needing a rebase as well
14:11:13 <dmellado> yboaron_: they have been there for a while, so I'd get there on their current state once they're good to go
14:11:29 <kaliya> what's vikasc "presentation" ?
14:11:35 <dmellado> and add vikasc approach on a follow-up patch
14:11:40 <irenab> dmellado, +1
14:11:42 <dmellado> kaliya: he did send an email to the ML but should be recorded
14:11:54 <kaliya> I missed that
14:12:22 <dmellado> kaliya: I'll ask him for the record link and send an email, no worries
14:12:27 <kaliya> thanks!
14:13:09 <dmellado> yw!
14:13:14 <irenab> kaliya, the slides https://docs.google.com/presentation/d/1_Yu88NA--afhal5uBipQymGqbNKagi-p2kr9acyH8CM/edit#slide=id.g3525172c70_0_0
14:13:59 <kaliya> ahh this one, yes thanks irenab
14:15:13 <dmellado> all right, any another topic or patches that would require attention?
14:15:20 <dmellado> ltomasbo: yboaron_ dulek ?
14:15:34 <dulek> dmellado: Not much from my side regarding kuryr-kubernetes.
14:16:13 <ltomasbo> not much either, perhaps just take a look at the patch:
14:16:25 <ltomasbo> https://review.openstack.org/#/c/548673
14:16:42 <yboaron_> dmellado, neither from my side
14:16:59 <ltomasbo> it will be interesting to agree on going for network ids or subnet ids for the pools
14:17:05 <ltomasbo> with their respective pros and cons
14:17:06 <dmellado> ltomasbo: will do, tbh though this was already merged
14:17:14 <dmellado> will take a look
14:17:30 <ltomasbo> thanks
14:17:40 <dmellado> #topic kuryr-libnetwork
14:17:47 <irenab> ltomasbo, what is the argument?
14:18:10 <ltomasbo> irenab, the current patch assumes there is only one subnet per network
14:18:55 <irenab> ltomasbo, so to make it generic case, need to take subnet_id and not network_id into account?
14:18:57 <ltomasbo> irenab, if we use subnet ids instead, we will support multiple subnets per network, but it will have some performance impact, as we need to call neutron to get subnets ids from network ids
14:19:05 <ltomasbo> which is the information at the vif object
14:19:28 <ltomasbo> well, I'm not sure we need multiple subnets per network
14:19:47 <ltomasbo> and celebdor said that their support in neutron is so-so too
14:20:03 <dmellado> ltomasbo: maybe dual stack, but I'll have to think about it
14:20:32 <ltomasbo> that is the only case, and it seems it is not that realistic/useful either
14:20:33 <irenab> we need to see the use case
14:20:47 <ltomasbo> for a generic use case, network_id is enough
14:20:58 <irenab> as long as there is no specific use case, may go with net_id
14:21:04 <ltomasbo> there may be some corner cases were subnet id may be needed I guess
14:21:15 <dmellado> yeah, I don't really think that it might be worth the performance hit
14:21:15 <ltomasbo> *where
14:21:30 <dmellado> ltomasbo: you're more than welcome to add tests regarding the corner cases
14:21:30 <irenab> and the framwork should be flexible enough to add multi subnets in the future is needed
14:21:45 <celebdor> ltomasbo: can you remind me why there is a perf impact on using subnet id?
14:21:59 <ltomasbo> yes, it is switching one key by the other andthe way to obtain it
14:22:13 <ltomasbo> celebdor, vif obj has already the network id
14:22:13 <celebdor> where do we obtain the netid from?
14:22:20 <celebdor> that's what I thought
14:22:29 <celebdor> but I thought that vif also has subnets
14:22:34 <ltomasbo> but if we want to use the subnet_id we need to retrieve it from the network id + subnet range
14:22:51 <celebdor> in fact I thought we even get the IP address from subnets
14:23:03 <celebdor> (of the vif object)
14:23:06 <ltomasbo> celebdor, we do get the subnet cidr
14:23:13 <ltomasbo> but not the uuid
14:23:45 <yboaron_> ltomasbo, I Assume that caching will help with performance, how many network to we intend to support ?
14:23:58 <yboaron_> networks
14:24:00 <ltomasbo> I thought about that too
14:24:04 <ltomasbo> but it may have some problems
14:24:10 <irenab> the performance impact can be itigatred if kuryr will fetch subnets on start-up
14:24:12 <celebdor> ltomasbo: ah... Another instance of crappy (for our purposes) os-vif information structure
14:24:14 <ltomasbo> we need to base it on the network ui and the subnet range
14:24:33 <ltomasbo> and then you can actually remove the subnet and create another one, with same range (and different uuid)
14:25:36 <ltomasbo> so, caching could be tricky, and assuming the subnets are already there could not cover all the use cases, for instance creating new subnets for each namespace
14:26:00 <dmellado> yeah, if we cache and create new subnets then we're screwed again
14:26:20 <yboaron_> ltomasbo, yes, that's a good point
14:26:34 <ltomasbo> another option could be to use network_id + subnet cidr
14:26:41 <ltomasbo> that should be unique
14:26:52 <ltomasbo> but perhaps a bit ugly...
14:26:55 <irenab> do we capture per namespace subnet discussion somewhere?
14:27:19 <irenab> not pool specific parts only?
14:27:20 <ltomasbo> not yet, I'm working on a PoC, and will write a devref soon
14:28:05 <celebdor> dulek: I sort of feel that with KuryrPort CRDs we would not have that much of a problem
14:28:08 <irenab> maybe worth to discuss the the full picture
14:28:28 <dmellado> irenab: +1
14:28:29 <yboaron_> +1
14:28:39 <dulek> celebdor: Well, K8s API is much more reliable than Neutorn.
14:28:49 <dulek> celebdor: But we still get synchronization issues, right?
14:28:57 <ltomasbo> irenab, yes, but adding the network id to the pools is related but not only targeting the subnet per namespace
14:29:15 <dmellado> ltomasbo: let's add in any case some docs to your patch
14:29:20 <dmellado> I'll fetch you tomorrow at the office
14:29:23 <ltomasbo> as if you have pools enabled, and change the subnet_id at kuryr.conf and restart the controller, it will lead you to error
14:29:31 <ltomasbo> not to error, to the pods in a different subnet
14:29:43 <celebdor> dulek: like?
14:29:56 <irenab> ltomasbo, agree, but some scenarious you consider seems to be driven by multi-subnet network
14:30:46 <ltomasbo> irenab, could be, but the initial though was on making kuryr namespace aware, more than the multi-subnet driver
14:30:49 <celebdor> With KuryrPort you'd just get the subnet_id from the driver, create the KuryrPort objects in the K8s API
14:31:05 <celebdor> that are assigned to specific Host
14:31:08 <dulek> celebdor: Like when creating and changing subnets? Don't know yet TBH.
14:31:34 <dulek> celebdor: Mhm.
14:31:37 <irenab> celebdor, how driver will fetch the subnet_id?
14:31:54 <celebdor> irenab: that's driver specific
14:32:02 <celebdor> one can be configuration
14:32:05 <ltomasbo> celebdor, for the subnet per namespace object we could also add subnet id to the CRDs, and use them for the pools
14:32:06 <irenab> call neutron?
14:32:25 <celebdor> ltomasbo: yes, I thought about KuryrSubnet
14:32:26 <ltomasbo> but that will solve only that case
14:32:34 <celebdor> and have the namespace annotated to point to it
14:32:44 <ltomasbo> celebdor, I already have a kuryrNet in my Pod :)
14:32:47 <ltomasbo> PoC
14:32:54 <celebdor> irenab: "call neutron" That usually only makes things worse :P
14:33:04 <celebdor> ltomasbo: that's good
14:34:24 <celebdor> so... I feel like this needs a videochat discussion :P
14:34:30 <ltomasbo> xD
14:34:38 <yboaron_> Yeppppppp
14:35:20 <ltomasbo> I agree, but why if we start with 1 subnet per network, and if we find out a use case for more than a subnet per network, then move to subnet_ids
14:35:44 <ltomasbo> it will be much simple and if there is no such use case, it will not pay off
14:35:57 <irenab> +1
14:36:09 <ltomasbo> (and perhaps the best solution is to include the subnet id at the os-vif object actually)
14:36:13 <celebdor> ltomasbo: okay, okay
14:36:39 <ltomasbo> that will bring consistency across drivers/pools
14:36:50 <celebdor> ltomasbo: you have my +2
14:37:01 <celebdor> but if we get to the end of the cycle in this state I'll get grumpy
14:37:09 <dmellado> celebdor: like always
14:37:11 <celebdor> I really want to move state to CRDs
14:37:12 <dmellado> xD
14:37:14 <yboaron_> ltomasbo, you have my +1 for ... video chat :-)
14:37:15 <celebdor> dmellado: but a bit more
14:37:27 <ltomasbo> xD
14:37:41 <dmellado> in any case yah, let's do a bluejeans call on the topic
14:38:03 <celebdor> ltomasbo: since you prolly have more meetings, send the invite :P
14:38:25 <ltomasbo> celebdor, what do you want to move to CRDs? for all the pools? or the cni pool ones?
14:38:58 <celebdor> ltomasbo: I want the Pools to be de facto backed by KuryrPort objects in the API
14:39:09 <ltomasbo> or you mean to move pools to CRD regardless of the driver
14:39:12 <celebdor> so that reloading is not a Neutron search operation, but a GET on K8s
14:39:42 <celebdor> like what kuryr CNI side pools PoC by dulek is doing
14:39:56 <ltomasbo> well, reloading is cheap enough now
14:40:09 <celebdor> ltomasbo: I don't mean it just because of this
14:40:22 <celebdor> I'm just trying to consolidate state on the K8s side
14:40:35 <celebdor> having much in both sides makes me uneasy
14:40:55 <ltomasbo> ok, anyway, I'll send an invite for a call
14:41:30 <dulek> Are w talking kuryr-libnetwork now?
14:41:36 <ltomasbo> go!
14:41:52 <dulek> There's this fix I've wrote for Neutron extensions getting deprecated: https://review.openstack.org/#/c/553756
14:41:58 <dulek> s/deprecated/removed
14:42:10 <dulek> Neutron patch is depending on this one, so it'll be great to get it reviewed.
14:42:26 <celebdor> dulek: alrighty
14:42:28 <dulek> I've already tested it here: https://review.openstack.org/#/c/553763, looks like things are working.
14:42:34 <dmellado> dulek: saw it, will review
14:43:28 <dulek> Thanks!
14:43:31 <irenab> dulek, will +2 once zuul is happy
14:43:37 <dmellado> yep
14:44:08 <dmellado> # open discussion
14:44:14 <dmellado> #topic open discussion
14:44:19 <celebdor> dulek: looks good to me
14:44:55 <celebdor> irenab: dmellado: are you both going to the summit?
14:45:13 <celebdor> Cause I got some requests to confirm my attendance due to the accepted talks
14:45:21 <celebdor> and as you know I won't be able to make it this time
14:45:29 <irenab> celebdor, I am not sure yet, will update
14:45:35 <dmellado> celebdor: I am, I'll need still ack fron irena, yep
14:46:19 <yboaron_> the Israeli summit ? :=)
14:46:27 <dmellado> yboaron_: the Vancouver one
14:46:33 <dmellado> :P
14:46:40 <celebdor> yboaron_: that one I'm counting with you and irenab for
14:46:41 <yboaron_> dmellado, kidding
14:46:52 <celebdor> I'd love to go though
14:47:06 <celebdor> and the weather is nicer than in Vancouver
14:47:22 <dmellado> celebdor: in any case throw the session to me and I'll see how can I manage
14:47:27 <irenab> celebdor, not sure about the weather
14:47:47 <yboaron_> I'm sure about the weather!
14:47:52 <dmellado> it can't be worse than Dublin
14:47:54 <irenab> its about +33 here today
14:48:15 <ltomasbo> dmellado, are you also taking the other one (SF one?)
14:48:18 <dmellado> +33? how much humidity?
14:48:27 <celebdor> dmellado: I already did
14:48:30 <dmellado> ltomasbo: yeah, those are lightning talks so I could handle
14:48:39 <dmellado> but I'll see if I can get cospeakers
14:48:42 <ltomasbo> ok
14:48:50 <celebdor> dmellado: the humidity depends on how much you sweat
14:48:51 <celebdor> xD
14:48:55 <irenab> ltomasbo, are you planning to attend the summit?
14:49:00 <dmellado> ltomasbo: you're always welcome to come along, though
14:49:15 <dmellado> irenab: we split the SF project and the Summit and ltomasbo will travel closer xD
14:49:23 <ltomasbo> irenab, I don't think so, going all the way to Vancouver for just 10 minutes talk...
14:49:41 <dmellado> ltomasbo: you can also come along for some another session xD
14:49:45 <ltomasbo> dmellado, closer but more boring...
14:49:49 <irenab> I think it has potential to become 40 mins
14:49:54 <dmellado> so far I've got 2 lightning talks
14:49:57 <dmellado> + one full talk
14:50:00 <dmellado> + project updates
14:50:04 <dmellado> + project oboarding
14:50:07 <dmellado> man, so much for me xD
14:50:10 <ltomasbo> xD
14:50:46 <irenab> dmellado, sounds like you will miss the Dublin summit ...
14:50:49 <dmellado> and the worst thing is that my girlfriend expects me to go to the wedding from her friend the next day after I'm back xD
14:51:15 <kaliya> you can bring a nice present:)
14:51:18 <dmellado> irenab: you go and grab someone from toga if you can't make it in the end xD
14:51:30 <irenab> :-)
14:52:00 <dmellado> anyways, it's being a looong meeting day and I still didn't get to have lunch
14:52:05 <dmellado> so thanks for attending
14:52:12 <dmellado> and bon apetit! xD
14:52:13 <kaliya> bye
14:52:14 <dmellado> xD
14:52:18 <celebdor> thank you all!
14:52:19 <irenab> bye
14:52:20 <yboaron_> bbye
14:52:27 <dmellado> #endmeeting kuryr