Open Stack

Sorry guys, initially I had not understood the separation of nova-api and
nova-compute. Thanks for setting me straight. It all makes sense now.

-- Henry

On Thu, May 16, at 2:28 pm, Robert Kukura <rkukura at redhat.com> wrote:

> On 05/16/2013 01:52 PM, Aaron Rosen wrote:
>> @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.
> 
> This makes sense to me. Eventually, scheduling might take network
> connectivity and possibly proximity into account, along with QoS. The
> scheduler should be able to fail the instance launch if the requested
> connectivity cannot be provided on any available compute node.
> 
>> 
>> @Mike - I think we'd still want to leave nova-compute to create the tap
>> interfaces and sticking  external-ids on them though.
> 
> It also seems nova-compute should call port-update to set
> binding:host_id and then use the returned binding:vif_type, since the
> vif_type might vary depending on the host, at least with ml2. The Arista
> top-of-rack switch hardware driver functionality also depends on the
> binding:host_id being set.
> 
> -Bob
> 
>> 
>> 
>> On Thu, May 16, 2013 at 10:05 AM, Mike Wilson <geekinutah at gmail.com
>> <mailto: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
>>     <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
>> 
>> 
>> 
>>     _______________________________________________
>>     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
>> 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
>