14:03:20 <dmellado> #startmeeting kuryr
14:03:21 <openstack> Meeting started Mon Sep 17 14:03:20 2018 UTC and is due to finish in 60 minutes.  The chair is dmellado. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:25 <openstack> The meeting name has been set to 'kuryr'
14:03:33 <dmellado> #chair celebdor
14:03:34 <openstack> Current chairs: celebdor dmellado
14:03:38 <dmellado> #chair ltomasbo
14:03:39 <openstack> Current chairs: celebdor dmellado ltomasbo
14:03:46 <ltomasbo> o/
14:03:57 <dmellado> Hi folks, who's here today for the kuryr meeting
14:04:21 <dmellado> I'm feeling kinda feverish today, so I'll be relying on celebdor to run the meeting
14:04:29 <dmellado> (or ltomasbo, if celebdor doesn't show up) xD
14:05:31 <celebdor> yes, yes
14:05:33 <celebdor> I'm here
14:05:35 <dmellado> so, round call
14:05:38 <celebdor> Welcome everybody!
14:05:42 <celebdor> who's here
14:05:43 <celebdor> ?
14:05:44 <dmellado> if we're all
14:05:54 <celebdor> and being in fever delirium doesn't count
14:05:59 <dmellado> I was thinking about us just switching to ofice hours tbh
14:06:00 <celebdor> dmellado: off to bed with you
14:06:06 <dmellado> I'll send an email
14:06:15 <celebdor> up to you
14:06:23 <celebdor> irenab: you here?
14:07:02 <celebdor> aperevalov: is here
14:07:07 <aperevalov> hi
14:07:35 <celebdor> ltomasbo: you had quite some discussion with aperevalov or danil about the initial patches last week, right?
14:07:53 <ltomasbo> yep, I was trying to fully understand the SRIOV patch
14:08:14 <ltomasbo> now I get it and besides some rewording I think it is good shape
14:08:20 <ltomasbo> but I don't have hard to test it
14:08:23 <ltomasbo> hardware
14:08:44 <dulek> o/, sorry for being late, something kicked me out of this channel.
14:08:50 <ltomasbo> talking about this: https://review.openstack.org/#/c/512280/
14:09:43 <celebdor> ltomasbo: so what is https://review.openstack.org/#/c/512280/ missing for your +1 ?
14:10:08 <aperevalov> celebdor: as I understood  verification,
14:10:23 <ltomasbo> I see danil updated the patch, so, nothing from my sided
14:10:26 <ltomasbo> side
14:11:00 <celebdor> right
14:11:14 <ltomasbo> celebdor, but I didn't test it myself...
14:11:33 <ltomasbo> I'll try to take a look to the following one tomorrow morning
14:11:41 <celebdor> ltomasbo: thanks for that
14:11:44 <aperevalov> do you think to test it in devstack and in tempest plugin, target host should have SRIOV device?
14:11:48 <celebdor> I'll see if we can get some hw to test
14:12:15 <celebdor> aperevalov: is there some fake sriov virtio that can be used?
14:13:02 <aperevalov> celebdor: I don't know mock for that
14:13:26 <dulek> aperevalov: Any chance to get Intel's SR-IOV voting on Kuryr? (Sorry if that was asked, eavesdrop.openstack.org doesn't have logs yet.)
14:15:18 <aperevalov> dulek: I was late today too ;)
14:15:48 <celebdor> I think they wanted to add support for dpdk in they infra
14:15:52 <celebdor> not sure about sr-iov
14:16:25 <dulek> And personally I don't really have an issue with merging SR-IOV without testing it myself as long as this is a well separated change from rest of the code.
14:16:41 <dulek> And if we get a promise that someone with hardware dedicates to support it.
14:16:48 <ltomasbo> +1
14:17:23 <dulek> Otherwise it's quite hard to say that we support it. Unfortunately this one is hard to be just write, get merged, forget.
14:17:26 <ltomasbo> it is a different driver, different object, so it should be separated enough
14:18:07 <aperevalov> our colegues in Suwon have SRIOV equipment ;) tomorrow we can ask to verify our patches.
14:18:27 <dulek> ltomasbo: That's what I expected. Even if that code's dead it isn't affecting us. But to say it's supported we probably need CI or someone who's testing it regularly.
14:18:40 <dulek> aperevalov: Great!
14:19:00 <ltomasbo> dulek, sure! fully agree
14:20:56 <celebdor> alright
14:21:04 <celebdor> Do we have any other topic?
14:21:23 <celebdor> Maybe ltomasbo having to bring SG ownership to the Octavia weekly meeting
14:22:01 <dulek> celebdor, ltomasbo: And pinging us so we could show up?
14:22:06 <aperevalov> if you agree with technical proposal in my vhostuser spec, so you can check my first 2 patches.
14:22:38 <celebdor> aperevalov: very well
14:22:51 <ltomasbo> yep, I was trying to get a simple fix on octavia to permit SG modification by the tenant creating the loadbalancer, and thus enabling service isolation on kuryr with namespaces
14:23:06 <dulek> Yeah, I didn't wanted to do unfocused reviews doing PTG, but now I should be able to sit at this.
14:26:10 <dulek> Okay, maybe my topic then?
14:26:27 <ltomasbo> go ahead!
14:26:37 <celebdor> sure
14:26:39 <dulek> Octavia has UDP support starting from Rocky (yeah!) so we should start supporting it.
14:26:52 <dulek> yboaron_ volunteered to work on that - thanks!
14:27:02 <dulek> The only question is how to correctly implement it.
14:27:34 <dulek> I think that we should query Octavia API version and based on that ignore or handle UDP LB creation.
14:28:19 <celebdor> dulek: are they bumping the API version?
14:28:25 <celebdor> cause that would really surprise me
14:28:32 <dulek> yboaron_ had a different idea - if I haven't misunderstood, we'll just assume that Rocky's Kuryr works with Rocky's Octavia.
14:28:53 <dulek> celebdor: Not the major version from what I was told. Let me try to find the API in question…
14:29:29 <celebdor> ok
14:29:30 <yboaron_> dulek, yes we can go with your approach, that means that kuryr  should stores features to Octavia features to versions mapping
14:29:57 <yboaron_> dulek, Ooops I mean Octavia features to version numbers mapping,
14:30:33 <dulek> yboaron_: Maybe that's even done in Octavia client, not sure here.
14:30:53 <dulek> And I cannot find this version discovery on their API reference, I'll try asking about it.
14:31:25 <celebdor> dulek: alright. If it is there, I don't mind
14:31:26 <yboaron_> I asked nmagnezi this morning, and he said that currently it isn't supported in Octavia client
14:31:39 <celebdor> I'd be surprised if it is there though
14:31:57 <celebdor> #action dulek to find out about the API versioning / feature negotiation
14:31:59 <yboaron_> this the pointer he sent me https://github.com/openstack/octavia-tempest-plugin/commit/dfd818a421886cc65ff54531df42f11c0cc294c0
14:32:22 <celebdor> #link https://github.com/openstack/octavia-tempest-plugin/commit/dfd818a421886cc65ff54531df42f11c0cc294c0
14:32:50 <dulek> yboaron_, celebdor: Okay, seems like this is it: https://github.com/openstack/octavia/blob/master/octavia/api/root_controller.py#L73
14:33:17 <celebdor> #link https://github.com/openstack/octavia/blob/master/octavia/api/root_controller.py#L73
14:33:43 <dulek> So… looks like v2.2 is with UDP?
14:33:53 <yboaron_> I guess so..
14:34:18 <celebdor> I so much prefer when you can just query for features
14:34:20 <dulek> Yeah, that would be correct.
14:34:22 <celebdor> instead of dealing with versions
14:34:23 <yboaron_> OK, we can go with this approach, celebdor what do u think ?
14:34:24 <celebdor> :/
14:34:31 <dulek> celebdor: Yeah, I agree with that.
14:35:28 <celebdor> dulek: yboaron_: I don't suppose they have anything like that
14:35:30 <celebdor> do they?
14:36:01 <dulek> celebdor: You mean current features list? No, it doesn't look like it. Only the 2.2 version means there's UDP.
14:36:04 <yboaron_> They dont according to nmagnezi it's in their roadmap
14:36:22 <celebdor> alright, alright
14:36:28 <celebdor> so let's use the damn versions
14:36:38 <celebdor> but I want that hidden in the client object
14:36:48 <celebdor> like if lbaas_client.supports_udp
14:36:58 <celebdor> don't let it leak out
14:37:06 <celebdor> or it will come back to bite us
14:37:25 <yboaron_> something similar to what u did with cascade deletion
14:37:49 <yboaron_> sounds good to me
14:38:04 <celebdor> yes
14:38:09 <celebdor> that's what I propose
14:38:44 <dulek> Okay, so I guess we're fine with this?
14:38:51 <celebdor> I am
14:38:58 <ltomasbo> sounds good
14:39:00 <yboaron_> me2
14:39:47 <celebdor> anything else?
14:42:36 <celebdor> alright then
14:42:41 <celebdor> thank you all for joining!
14:42:43 <celebdor> #endmeeting