Hi, You don't need neutron to get resource provider information, you can fetch everything from placement. If you list RPs all that is created by neutron will be under a compute (as root provider) and will be named something like this for neutron agents: *<host name>:Open vSwitch agent* or *<host name>:NIC Switch agent*. If the agent has configured bandwidth, than it has a leaf like this : *<host name>:Open vSwitch agent:<bridge name> *or *<host name>:NIC Switch agent:<nic> *as it is configured in the relevant neutron config on the given host. Neutron can't give you up-to-date information of the RPs (like generation) as it is placement who has all these. The same is true for traits, to get the traits for RPs placement is your service: https://docs.openstack.org/api-ref/placement/?expanded=list-resource-provide... regards Lajos Katona (lajoskatona) Wang, Xin-ran <xin-ran.wang@intel.com> ezt írta (időpont: 2020. jún. 12., P, 12:31):
Hi all,
I prefer that physnet related stuff still managed by neutron, because it is a notion of neutron. If we let Cyborg update this traits to Placement, what will we do if Neutron enabled bandwidth feature and how we know whether this feature is enabled or not.
Can we just let Neutron always report physnet traits. I am not very familiar with neutron, is there any gap?
Otherwise, if Cyborg do need report this to placement, my proposal is:
Neutron will provide an interface which allow Cyborg to get physnet trait/RP, if this feature is not configured, it will return 404, then Cyborg will know that neutron did not configured bandwidth feature, and Cyborg can report all by itself. If Neutron returns something meaningful, Cyborg should use the same RP and update other traits on this RP.
In this way, Cyborg and Neutron will use the same RP and keep the consistency.
Thanks, Xin-Ran
-----Original Message----- From: Sean Mooney <smooney@redhat.com> Sent: Thursday, June 11, 2020 9:44 PM To: Nadathur, Sundar <sundar.nadathur@intel.com>; openstack-discuss < openstack-discuss@lists.openstack.org> Subject: Re: [cyborg][neutron][nova] Networking support in Cyborg
Hi Sean,
From: Sean Mooney <smooney@redhat.com> Sent: Thursday, June 11, 2020 4:31 AM
On Thu, 2020-06-11 at 11:04 +0000, Nadathur, Sundar wrote:
[...] * Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. For that, the device profile must have a single resource group that includes the resource, traits and Cyborg
properties for both the accelerator and NIC. The device profile for a Neutron port will presumably have only one request group. So, the device profile would look something like this:
{ "name": "my-smartnic-dp", "groups": [{ "resources:FPGA": "1", "resources:CUSTOM_NIC_X": "1", "trait:CUSTOM_FPGA_REGION_ID_FOO": "required", "trait:CUSTOM_NIC_TRAIT_BAR": "required", "trait:CUSTOM_PHYSNET_VLAN3": "required", "accel:bitstream_id": "3AFE" }] }
having "trait:CUSTOM_PHYSNET_VLAN3": "required", in the device profile means you have to create a seperate device profile with the same details for each physnet and the user then need to fine the profile that matches there neutron network's physnet which is also problematic if they use the multiprovidernet extention. so we shoud keep the physnet seperate and have nova or neutorn append that when we make the placment query.
True, we did discuss this at the PTG, and I agree. The physnet can be passed in from the command line during port creation.
On Thu, 2020-06-11 at 12:24 +0000, Nadathur, Sundar wrote: that is not how that works.
when you create a neutron network with segmenation type vlan or flat it is automatically assigned a segmeantion_id and phsynet. As an admin you can chose both but as a tenant this is managed by neutron
ignoring the multiprovidernet for a second all vlan and flat network have 1 phyesnet and the port get a phsynet form the network it is created on.
the multiprovidernet extension allow a singlel neutron provider network to have multiple physnets but nova does not support that today.
so nova can get the physnet from the port/network/segment and incorporate that in the placment request but we cant pass it in during port creation.
in general tenants are not aware of physnets.
[...] * We discussed the physnet trait at the PTG. My suggestion is to keep Cyborg out of this, and out of networking in general, if
possible.
well this feature is more or less the opisite of that intent but i get that you dont want cyborg to have to confiure the networking
atribute of the interface.
The admin could apply the trait to the right RP. Or, the OpenStack installer could automate this. That's similar in spirit to having the admin configure the physnet in PCI whitelist. yes they could its not a partially good user experience as it quite tedious to do but yes it a viable option and likely sufficnet for the initial work. installer could automate it but having to do it manually would not be ideal.
Regards, Sundar