14:01:02 <slaweq> #startmeeting neutron_drivers 14:01:03 <openstack> Meeting started Fri Dec 4 14:01:02 2020 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:06 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:10 <mlavalle> o/ 14:01:21 <rubasov> o/ 14:01:26 <slaweq> hi 14:01:42 <yonglihe> hi,. 14:01:46 <ralonsoh> hi 14:02:25 <rafaelweingartne> \o 14:02:26 <slaweq> lets wait few more minutes for haleyb, njohnston, amotoki and yamamoto :) 14:02:31 <lajoskatona> o/ 14:02:36 <njohnston> o/ 14:06:30 <slaweq> it's 6 minutes after we started meeting 14:06:38 <slaweq> and we have quorum already 14:06:43 <slaweq> so lets start 14:06:54 <slaweq> #topic RFEs 14:07:02 <slaweq> agenda for the meeting is at https://wiki.openstack.org/wiki/Meetings/NeutronDrivers 14:07:11 <slaweq> we have 2 RFEs for today 14:07:15 <slaweq> https://bugs.launchpad.net/neutron/+bug/1905115 14:07:16 <openstack> Launchpad bug 1905115 in neutron "[RFE] Extend neutron-metadata-agent to support to proxy multiple external services" [Wishlist,New] 14:07:21 <slaweq> that's first one 14:08:23 <yonglihe> I would like a new one, https://bugs.launchpad.net/neutron/+bug/1906602, sorry. 14:08:25 <openstack> Launchpad bug 1906602 in neutron "[RFE] add new extension "device-profile" for port" [Undecided,New] 14:09:04 <slaweq> yonglihe: that is added by ralonsoh to the on demand section 14:09:12 <yonglihe> thanks. 14:09:12 <slaweq> I hope we will have time to discuss it today too 14:10:14 <haleyb> hi, sorry i'm late 14:10:39 <slaweq> haleyb: hi 14:10:40 <yonglihe> I suppose the REF deal with Neutron side detail, and this won't block nova's overall design spec, right? 14:11:03 <slaweq> haleyb: we started from 14:11:05 <slaweq> https://bugs.launchpad.net/neutron/+bug/1905115 14:11:06 <openstack> Launchpad bug 1905115 in neutron "[RFE] Extend neutron-metadata-agent to support to proxy multiple external services" [Wishlist,New] 14:11:06 <yonglihe> s/REF/RFE 14:12:16 <haleyb> i did read this the other day, and my immediate thought was Octavia (load balancer) 14:12:40 <slaweq> haleyb: loadbalancer? 14:12:56 <haleyb> it mentions haproxy, L4/L7 14:13:07 <slaweq> my understanding is that this is to allow instances to reach some services which are outside of the openstack cloud 14:13:18 <slaweq> so it would be something opposite to octavia IIUC 14:14:02 <haleyb> for example, in #2 (shared license pool), is the VM asking for a license on startup? 14:14:54 <haleyb> maybe i didn't read it enough 14:14:54 <rubasov> though I never used that, previously I thought nova's vendordata plugin can be used to do that part of the RFE 14:15:30 <slaweq> haleyb: that is my understanding of this rfe 14:16:00 <njohnston> My main question is: is the list of external services set in code, or is it operator-configured, or is it tenant-configured? I can certainly imagine that for Windows instances a connection to SCCM would be essential, but that is the camel's nose, so to speak. 14:16:12 <haleyb> why does neutron need to proxy for a license, shouldn't that be some other service? 14:16:25 <haleyb> s/be the proxy 14:16:41 <njohnston> For an otherwise-isolated tenant network 14:17:01 <slaweq> njohnston++ yes, that's my understanding of it too 14:18:22 <slaweq> njohnston: I don't know the answer for how list of those services would be set 14:18:41 <slaweq> but IMHO the best/easiest would be to do it in config file for metadata agent 14:19:00 <mlavalle> While reading it, I assumed it would be configurable. Inly an assumption, though 14:19:22 <rubasov> the rfe says "neutron congfiguration file" so I assumed operator-configured 14:19:23 <mlavalle> Probably would need to be spelled out in a spec 14:19:53 <slaweq> rubasov: thx, I was almost sure I saw it somewhere :) 14:21:43 <rubasov> which btw is a bit weird for me because that would mean you can't bake standard images for these services, since the access url could be different in every deployment 14:22:28 <slaweq> rubasov: I believe that for "standard" deployment it would be disabled 14:22:43 <slaweq> and it's targeting some specific use case with specific images 14:24:48 <mlavalle> haleyb you reaised an interesting question. Maybe because Neutron is a central point that would allow proxying to many different kinds of services, not only licenses? 14:25:51 <haleyb> so i guess getting back to my original question - if this wasn't an isolated network, the user could just configure a well-known IP to have their license server on, right? 14:26:07 <slaweq> haleyb: yes 14:26:25 <mlavalle> yeah, but then again, licenses is only one of the use cases envisioned here, IIUC 14:26:45 <slaweq> that's my understanding too 14:26:51 <haleyb> that's why without that specific requirement i thought of octavia, but it could just be another VM in the cloud 14:26:54 <slaweq> they also say something about some monitoring 14:27:12 <mlavalle> yeap, monitoring is another use case mentioned 14:27:51 <mlavalle> it's really an attempt to create a "swiss knife" with the metadata agent to proxy "whatever" 14:28:48 <njohnston> The first question I had when reading this is: why not just use security groups? I think that this is really a way to get around not having a default security group where an admin could centrally configure "all new instances get connections to SCCM, inventory-api, etc. no matter what" 14:29:17 <slaweq> njohnston: but how SG would help in the isolated network? 14:29:21 <njohnston> (which would require not using isolated tenant networks of course) 14:29:28 <slaweq> :) 14:30:03 <njohnston> If a customer is using isolated networks for some kind of compliance reason though I worry very much about poking holes in that, especially if it could be satisfied another way 14:34:36 <njohnston> I have deployed windows servers that have to communicate with SCCM on startup, so I see the value in this, but I can't imagine saying yes to this and then no to any number of other things corporations like to do, at which point the security model had just become another kind of security group 14:35:26 <njohnston> well, startup, but especially they need to communicate with SCCM when they get imaged initially 14:36:42 <slaweq> it can be also done with one additional vm which would be connected to external network and which would do such proxy 14:36:50 <slaweq> and then neutron don't need to do anything 14:37:12 <slaweq> on such vm they would be able to control everything as they want :) 14:37:16 <njohnston> right! Addressing it in architecture is better than modifying the service to handle the request 14:37:22 <haleyb> slaweq: right, there are other ways 14:38:44 <slaweq> ok, so lets ask them if that would solve their problem 14:38:49 <njohnston> +1 14:39:00 <haleyb> i'm just also thinking when we (maybe) do a server-less metadata in some OVN future feature and we break this 14:39:03 <slaweq> if not - maybe they will provide more data for further discussion 14:39:11 <haleyb> so +1 to ask them 14:39:17 <mlavalle> +1 14:39:30 <slaweq> ralonsoh: any thoughts? 14:39:43 <ralonsoh> ok to ask them 14:39:46 <slaweq> k 14:39:48 <slaweq> thx 14:39:52 <slaweq> so this one is done 14:40:39 <slaweq> lets now discuss https://bugs.launchpad.net/neutron/+bug/1906602 which was added by ralonsoh to the on demand section 14:40:40 <openstack> Launchpad bug 1906602 in neutron "[RFE] add new extension "device-profile" for port" [Undecided,New] 14:40:46 <ralonsoh> slaweq, thanks 14:40:49 <slaweq> but as we have yonglihe here 14:40:54 <ralonsoh> long story short: https://review.opendev.org/c/openstack/nova-specs/+/742785/14/specs/wallaby/approved/support-sriov-smartnic.rst#129 14:40:57 <slaweq> we can talk now 14:41:12 <slaweq> and btw. thx rubasov for allowing discuss of that before his rfe :) 14:41:12 <yonglihe> First question, need a spec for neutron? 14:41:26 <yonglihe> thanks, rubasov 14:41:33 <rubasov> sure, np 14:41:53 <ralonsoh> let's first propose what should be done 14:42:05 <ralonsoh> Neutron needs to extend the port API 14:42:11 <ralonsoh> to provide to Nova a string parameter 14:42:18 <ralonsoh> "device_profile" 14:42:30 <ralonsoh> this parameter will be passed to Nova and then to Cyborg 14:42:47 <ralonsoh> this parameter is given during the port creation (read-only) 14:43:22 <ralonsoh> and replying to the RFE question, IMO I think we don't need a spec for this 14:43:26 <ralonsoh> having the Nova one 14:43:29 <lajoskatona> So the user needs to know the good value here at port-create time? 14:43:34 <yonglihe> dolpher, and xinran also here. ralonsoh, yeah. and a new nit type is also required by nova. 14:43:35 <ralonsoh> yes 14:43:42 <yonglihe> s/nit/nic 14:43:52 <lajoskatona> ralonsoh: ok 14:44:18 <ralonsoh> lajoskatona, of course that can't be modified if the port is bound 14:44:31 <ralonsoh> if the port is not bound, can be deleted and created again 14:44:46 <lajoskatona> ralonsoh, yonglihe: when the validation happens, when the value is passed from nova to cyborg? 14:45:10 <lajoskatona> so no need to check in neutron create time? 14:45:12 <ralonsoh> well, not validation but request 14:45:24 <ralonsoh> according to the spec, no 14:45:36 <ralonsoh> this parameter is a generic string 14:45:39 <gibi> we touched upon the validation during the PTG but validating the device_profile name from neutron perspective would require a cyborg client to be added 14:45:59 <gibi> as far as I remember we agreed not to do this at the first step 14:46:01 <ralonsoh> something like a trait? 14:46:40 <slaweq> gibi: yes, I also remember something like that 14:47:09 <gibi> so the server create will fail not the port create if the port has an invalid device_profile value set 14:48:56 <lajoskatona> gibi, salweq: ok 14:50:06 <slaweq> this device_profile field will accept only string? or will it be some dict with various values? 14:50:26 <ralonsoh> this is supposed to be like a os trait 14:50:55 <ralonsoh> a string that will define a profile stored in Cyborg 14:51:06 <yonglihe> it should be only string, like a 'flavor' name, which defined in Cyborg 14:51:21 <slaweq> ok, thx 14:51:51 <slaweq> do You have any other questions regarding that? or do You want to vote on approving it or not? 14:52:14 <slaweq> I'm personally ok to approve that rfe on our side, especially that we discussed that during the ptg already 14:52:27 <mlavalle> +1 14:52:42 <njohnston_> does neutron have any responsibility for validating that the named policy exists in Cyborg before proceeding? 14:52:52 <ralonsoh> not now, as commented 14:53:03 <ralonsoh> for now we are not adding the Cyborg client 14:53:13 <njohnston_> I am +1 14:53:35 <lajoskatona> +1 14:53:38 <njohnston_> ok, apologies my connection tion dropped, I must have missed that 14:54:17 <slaweq> haleyb: any thoughts? 14:54:26 <slaweq> I guess that ralonsoh is "+1" on this also :) 14:54:33 <ralonsoh> (I added this item to the agenda, I should not vote) 14:54:40 * haleyb got distracted so won't vote 14:55:36 <slaweq> hmm, that's hard - we have 3x +1, 2x "hold" and missing 2 people 14:55:48 <slaweq> I have such thing first time here :/ 14:56:06 <ralonsoh> no rush, I'll ask next week for more votes 14:56:15 <haleyb> i can read s/b 14:56:23 <slaweq> haleyb: would be great :) 14:56:24 <ralonsoh> (I'll add it again to the agenda, just for voting) 14:56:53 <yonglihe> thanks. 14:56:54 <slaweq> haleyb: so please read it this week, and we will get back to it as first item on next meeting 14:57:06 <haleyb> +1 it seems simple enough for neutron 14:57:14 <slaweq> ok, thx haleyb :) 14:57:23 <slaweq> so I will mark this rfe as approved 14:57:23 <ralonsoh> thank you all 14:57:27 <slaweq> thx 14:57:38 <slaweq> have a great weekend and see You next week! 14:57:40 <slaweq> o/ 14:57:50 <mlavalle> o/ 14:57:53 <rubasov> o/ 14:57:54 <slaweq> rubasov: Your rfe will be first one next week 14:58:00 <slaweq> #endmeeting