Open Stack

On Thu, May 16, 2013 at 11:28 AM, 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.
>
> Yup I agree. It will have to do that anyways at some point to update the
port to include the device_id (which maps to the nova instance id) .


> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/0866b267/attachment.html>