Open Stack

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 at redhat.com> 
Sent: Thursday, June 11, 2020 9:44 PM
To: Nadathur, Sundar <sundar.nadathur at intel.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [cyborg][neutron][nova] Networking support in Cyborg

On Thu, 2020-06-11 at 12:24 +0000, Nadathur, Sundar wrote:
> Hi Sean,
> 
> > From: Sean Mooney <smooney at 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.
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