Open Stack

Hi,

Port-resource-request (see:
https://docs.openstack.org/api-ref/network/v2/index.html#port-resource-request
)
is a read-only (and admin-only) field of ports, which is filled
based on the agent heartbeats. So now there is now polling of agents or
similar. Adding extra "overload" to this mechanism, like polling cyborg or
similar
looks something out of the original design for me, not to speak about the
performance issues to add

   - API requests towards cyborg (or anything else) to every port GET
   operation
   - store cyborg related information in neutron db which was fetched from
   cyborg (periodically I suppose) to make neutron able to fill
   port-resource-request.

Regards
Lajos

Sean Mooney <smooney at redhat.com> ezt írta (időpont: 2020. máj. 28., Cs,
16:13):

> On Thu, 2020-05-28 at 20:50 +0800, yumeng bao wrote:
> > 
> > Hi all,
> >
> >
> > In cyborg pre-PTG meeting conducted last week[0],shaohe from Intel
> introduced SmartNIC support integrations,and we've
> > reached some initial agreements:
> >
> > The workflow for a user to create a server with network
> acceleartor(accelerator is managed by Cyborg) is:
> >
> >   1. create a port with accelerator request specified into
> binding_profile field
> >  NOTE: Putting the accelerator request(device_profile) into
> binding_profile is one possible solution implemented in
> > our POC.
> the binding profile field is not really intended for this.
>
>
> https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py#L31-L34
> its intended to pass info from nova to neutron but not the other way
> around.
> it was orgininally introduced so that nova could pass info to the neutron
> plug in
> specificly the sriov pci address. it was not intended for two way
> comunicaiton to present infom form neutron
> to nova.
>
> we kindo of broke that with the trusted vf feature but since that was
> intended to be admin only as its a security risk
> in a mulit tenant cloud its a slightl different case.
> i think we should avoid using the binding profile for passing info form
> neutron to nova and keep it for its orginal
> use of passing info from the virt dirver to the network backend.
>
>
> >        Another possible solution,adding a new attribute to port object
> for cyborg specific use instead of using
> > binding_profile, is discussed in shanghai Summit[1].
> > This needs check with neutron team, which neutron team would suggest?
> from a nova persepctive i would prefer if this was  a new extention.
> the binding profile is admin only by default so its not realy a good way
> to request features be enabled.
> you can use neutron rbac policies to alther that i belive but in genral i
> dont think we shoudl advocate for non admins
> to be able to modify the binding profile as they can break nova. e.g. by
> modifying the pci addres.
> if we want to supprot cyborg/smartnic integration we should add a new
> device-profile extention that intoduces the ablity
> for a non admin user to specify a cyborg device profile name as a new
> attibute on the port.
>
> the neutron server could then either retirve the request groups form
> cyborg and pass them as part of the port resouce
> request using the mechanium added for minium bandwidth or it can leave
> that to nova to manage.
>
> i would kind of prefer neutron to do this but both could work.
> >
> >   2.create a server with the port created
> >
> > Cyborg-nova-neutron integration workflow can be found on page 3 of the
> slide[2] presented in pre-PTG.
> >
> > And we also record the introduction! Please find the pre-PTG meeting
> vedio record in [3] and [4], they are the same,
> > just for different region access.
> >
> >
> > [0]
> http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014987.html
> > [1]https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj
> > [2]pre-PTG slides:https://docs.qq.com/slide/DVm5Jakx5ZlJXY3lw
> > [3]pre-PTG vedio records in Youtube:
> https://www.youtube.com/watch?v=IN4haOK7sQg&feature=youtu.be
> > [4]pre-PTG vedio records in Youku:
> >
> http://v.youku.com/v_show/id_XNDY5MDA4NjM2NA==.html?x&sharefrom=iphone&sharekey=51459cbd599407990dd09940061b374d4
> >
> > Regards，
> > Yumeng
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200529/7fe35629/attachment.html>