[cyborg][neutron][nova] Networking support in Cyborg

Lajos Katona katonalala at gmail.com
Mon Jun 15 12:05:03 UTC 2020


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-provider-traits-detail#list-resource-provider-traits

regards
Lajos Katona (lajoskatona)


Wang, Xin-ran <xin-ran.wang at 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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200615/7dfe079d/attachment.html>


More information about the openstack-discuss mailing list