Open Stack

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> 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) 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> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/b7f5309d/attachment.html>