Open Stack

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
>