<div dir="ltr">Henry,<div><br></div><div>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.</div>
<div><br></div><div style>-Mike</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 8:49 AM, Henry Gessau <span dir="ltr"><<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
I was envisioning a future with something along the lines of:<br>
<blockquote>QoS has been implemented in quantum.<br>
The provider has set up some service levels with guaranteed
bandwidth,<br>
e.g. Bronze = 10 Mbit/s, Silver = 50 Mbit/s, Gold = 250 Mbit/s<br>
A tenant wants to deploy an instance with one Gold port.<br>
</blockquote>
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?<br>
<br>
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.<div><div class="h5"><br>
<br>
<div>On Thu, May 16, at 9:55 am Aaron Rosen
(<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.com</a>) wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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. <br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 16, 2013 at 6:28 AM, Henry
Gessau <span dir="ltr"><<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On Wed, May 15, at 3:53 pm, Aaron Rosen
wrote:<br>
<br>
> I created the following blueprint and wanted to
hear what the community<br>
> though before starting on it.<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port" target="_blank">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a><br>
<br>
</div>
</div>
You address specifically the issue with the "number of
ports" quota.<br>
<br>
Although we are not ready for it yet, you may want to take
into account that<br>
one day there could be additional quota restraints (like
bandwidth). I.e. just<br>
try to ensure that it will not be too hard to add those when
the time comes.<br>
<span><font color="#888888"><br>
-- Henry<br>
</font></span>
<div>
<div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>