Open Stack

On Nov 6, 2012, at 11:18 AM, Gary Kotton <gkotton at redhat.com> wrote:
> On 11/06/2012 06:50 PM, Kyle Mestery (kmestery) wrote:
>> On Nov 6, 2012, at 6:09 AM, Gary Kotton<gkotton at redhat.com>  wrote:
>> 
>>> Hi,
>>> In order to move forward with the blueprint vif-plugging-improvements (https://blueprints.launchpad.net/quantum/+spec/vif-plugging-improvements). A description of the problem can be seen at https://docs.google.com/presentation/d/1vD2bc2WyqQzOLODjFrfLgg661WU0nteY7NEaVS4pv5g/edit.
>>> 
>>> A precursor to the blueprint is the following patches (which improve the way in which libvirt manages the linux bridge plugin - improved security and performance) [it would be nice if they could both land at the same time :)]:
>>>     Nova - https://review.openstack.org/#/c/14830/
>>>     Quantum - https://review.openstack.org/#/c/14961/
>>> 
>>> The goals of the blueprint are:
>>>     - remove configuration variables from the nova.conf for the specific quantum plugin and have nova learn the networking "implementation" from quantum
>>>     - simplify the hypervisor drivers (when using quantum)
>>>     - more robust interface for the VIF plugins
>>> 
>>> I would first like to tackle the first two items. Prior to doing this I would like to get input regarding the interfaces. The goal here is to have minimal changes in Nova and to have Quantum provide the necessary support and infrastructure.
>>> 
>>> The third item has been very nicely described by Ian (aka ijw) - http://wiki.openstack.org/VifPlugging. This can be addressed once we have the building blocks and ready.
>>> 
>>> I would like to get some input regarding the Quantum API. In order for Quantum to be able provide the necessary network "implementation" the proposal will be to have the following API:
>>> GET /network-implementation-details/<net-id>. The plugin will be responsible for filling in the relevant details. These details will be used by Nova compute to create/manage/configure the vNic (depending on the underlying technology). This will initially be done as part of a generic Quantum VIF plugin. In the future this can have extensions to indicate if a host is on a specific network (in the event that Quantum can support more than one plugin or networking technology for a logical network)
>>> 
>>> Open issues:
>>> - permissions - can any user access this information or should it be an admin user? Will Nova need some privileged access to get this information?
>>> - will this need to be extended to ports? For example if the hypervisor enables the guest to access a paravirtualized network adapter. If so then the API
>>> GET /port-implementation-details/<port-id>  can be added. Is this relevant?
>>> 
>> I think it may be necessary to plan on having the port-implementation API. I think in the case of a paravirtualized network adapter, as well as in the case of PCI passthrough, it makes sense.
> 
> Thanks. Another option would be to have a sub resource on the port command to provide the details. This could be a cleaner solution. That is
> GET /port/<id>/details
> 
> We can do away with the network command.
> 
That works too.

> My concerns are still the permissions

My opinion on the permissions would be to require admin privileges. This type of information likely relates directly to host hardware resources, so exposing it only to users with admin privileges seems appropriate.

Thanks,
Kyle

>> 
>>> Thanks
>>> Gary
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>