<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 11:28 AM, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/16/2013 01:52 PM, Aaron Rosen wrote:<br>
> @Henry - One thing to add to what Mike was saying. If we pull port<br>
> creation out of nova-compute then the port could be exposed to the<br>
> scheduler and thus do what your are thinking.<br>
<br>
</div>This makes sense to me. Eventually, scheduling might take network<br>
connectivity and possibly proximity into account, along with QoS. The<br>
scheduler should be able to fail the instance launch if the requested<br>
connectivity cannot be provided on any available compute node.<br>
<div class="im"><br>
><br>
> @Mike - I think we'd still want to leave nova-compute to create the tap<br>
> interfaces and sticking external-ids on them though.<br>
<br>
</div>It also seems nova-compute should call port-update to set<br>
binding:host_id and then use the returned binding:vif_type, since the<br>
vif_type might vary depending on the host, at least with ml2. The Arista<br>
top-of-rack switch hardware driver functionality also depends on the<br>
binding:host_id being set.<br>
<br></blockquote><div>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) . <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Bob<br>
<div class="im"><br>
><br>
><br>
> On Thu, May 16, 2013 at 10:05 AM, Mike Wilson <<a href="mailto:geekinutah@gmail.com">geekinutah@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:geekinutah@gmail.com">geekinutah@gmail.com</a>>> wrote:<br>
><br>
> Henry,<br>
><br>
> It seems like this kind of discussion is similar to what I was<br>
> hearing at the summit around unified scheduling. Ie. where a service<br>
> has dependencies on locality ,capabilities and possible more<br>
> abstract things, like other services' quotas. What Aaron and I were<br>
> discussing over IRC yesterday is that port creation is none of<br>
> nova-compute's business, or the api for that matter. The current<br>
> bugs are legit, but it's because we never quite tore all the network<br>
> abstraction out of nova. Port-creation is one example of this<br>
> behavior. There's others, such as nova-compute creating tap devices<br>
> and sticking external-ids on the tap. IMO, this is none of<br>
> nova-compute's business. We could "fix" the bug, but better to move<br>
> the software in the direction that it should be going. Which is<br>
> getting out the networking business and letting quantum handle that.<br>
><br>
> -Mike<br>
><br>
><br>
> On Thu, May 16, 2013 at 8:49 AM, Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>>> wrote:<br>
><br>
> I was envisioning a future with something along the lines of:<br>
><br>
> QoS has been implemented in quantum.<br>
> The provider has set up some service levels with guaranteed<br>
> 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>
><br>
> If quantum manages bandwidth and nova-compute knows nothing<br>
> about it, then nova could try to send the instance to a compute<br>
> node where there is not 250 Mbit/s of guaranteed bandwidth<br>
> available and quantum would fail it. This is what we'd like to<br>
> avoid, right?<br>
><br>
> Maybe this is a generic problem for nova? Maybe nova should<br>
> maintain a complete list/dict of quota items, like cores,<br>
> memory, disk, ports, bandwidth, etc. Some of them nova would set<br>
> up itself, others would be created/populated/updated by other<br>
> components via some registration mechanism. I know nothing about<br>
> how nova works so I am probably not making sense.<br>
><br>
><br>
> On Thu, May 16, at 9:55 am Aaron Rosen (<a href="mailto:arosen@nicira.com">arosen@nicira.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>>) wrote:<br>
>> This more has to do with failing before the instance makes it<br>
>> to a compute node and having all the port information details<br>
>> before it's sent to the compute node. Quota restraints like<br>
>> bandwidth would be an attribute of a port (which quantum would<br>
>> manage) and nova-compute should not know anything about.<br>
>><br>
>><br>
>><br>
>> On Thu, May 16, 2013 at 6:28 AM, Henry Gessau<br>
</div><div class="im">>> <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a> <mailto:<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>>> wrote:<br>
>><br>
>> On Wed, May 15, at 3:53 pm, Aaron Rosen wrote:<br>
>><br>
>> > I created the following blueprint and wanted to hear<br>
>> what the community<br>
>> > though before starting on it.<br>
>> ><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>
>> You address specifically the issue with the "number of<br>
>> ports" quota.<br>
>><br>
>> Although we are not ready for it yet, you may want to take<br>
>> into account that<br>
>> one day there could be additional quota restraints (like<br>
>> bandwidth). I.e. just<br>
>> try to ensure that it will not be too hard to add those<br>
>> when the time comes.<br>
>><br>
>> -- Henry<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>> <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>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
</div>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">>> <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>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="im">> <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>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<div class="HOEnZb"><div class="h5">> <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>
><br>
><br>
><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>
<br>
<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>
</div></div></blockquote></div><br></div></div>