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