Open Stack

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) 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
> 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/c51888a5/attachment.html>