Open Stack

I would really like to see this as well. Let nova do virtualization really reliably and well. Let quantum do networking really reliably and well (and so on).

Someday I hope :-)

-Josh

From: Mike Wilson <geekinutah at gmail.com<mailto:geekinutah at gmail.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 16, 2013 10:05 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova][Quantum] Move quantum port creation to nova-api

Henry,

It seems like this kind of discussion is similar to what I was hearing at the summit around unified scheduling. Ie. where a service has dependencies on locality ,capabilities and possible more abstract things, like other services' quotas. What Aaron and I were discussing over IRC yesterday is that port creation is none of nova-compute's business, or the api for that matter. The current bugs are legit, but it's because we never quite tore all the network abstraction out of nova. Port-creation is one example of this behavior. There's others, such as nova-compute creating tap devices and sticking external-ids on the tap. IMO, this is none of nova-compute's business. We could "fix" the bug, but better to move the software in the direction that it should be going. Which is getting out the networking business and letting quantum handle that.

-Mike


On Thu, May 16, 2013 at 8:49 AM, Henry Gessau <gessau at cisco.com<mailto:gessau at cisco.com>> wrote:
I was envisioning a future with something along the lines of:
QoS has been implemented in quantum.
The provider has set up some service levels with guaranteed bandwidth,
  e.g. Bronze = 10 Mbit/s, Silver = 50 Mbit/s, Gold = 250 Mbit/s
A tenant wants to deploy an instance with one Gold port.
If quantum manages bandwidth and nova-compute knows nothing about it, then nova could try to send the instance to a compute node where there is not 250 Mbit/s of guaranteed bandwidth available and quantum would fail it. This is what we'd like to avoid, right?

Maybe this is a generic problem for nova? Maybe nova should maintain a complete list/dict of quota items, like cores, memory, disk, ports, bandwidth, etc. Some of them nova would set up itself, others would be created/populated/updated by other components via some registration mechanism. I know nothing about how nova works so I am probably not making sense.


On Thu, May 16, at 9:55 am Aaron Rosen (arosen at nicira.com<mailto:arosen at nicira.com>) wrote:
This more has to do with failing before the instance makes it to a compute node and having all the port information details before it's sent to the compute node. Quota restraints like bandwidth would be an attribute of a port (which quantum would manage) and nova-compute should not know anything about.



On Thu, May 16, 2013 at 6:28 AM, Henry Gessau <gessau at cisco.com<mailto:gessau at cisco.com>> wrote:
On Wed, May 15, at 3:53 pm, Aaron Rosen wrote:

> I created the following blueprint and wanted to hear what the community
> though before starting on it.
>
> https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port

You address specifically the issue with the "number of ports" quota.

Although we are not ready for it yet, you may want to take into account that
one day there could be additional quota restraints (like bandwidth). I.e. just
try to ensure that it will not be too hard to add those when the time comes.

-- Henry

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




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


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/309b248c/attachment.html>