Open Stack

@Henry  - One thing to add to what Mike was saying. If we pull port
creation out of nova-compute then the port could be exposed to the
scheduler and thus do what your are thinking.

@Mike - I think we'd still want to leave nova-compute to create the tap
interfaces and sticking  external-ids on them though.


On Thu, May 16, 2013 at 10:05 AM, Mike Wilson <geekinutah at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/61f05651/attachment.html>