Open Stack

On 05/16/2013 10:11 AM, Andrew Laski wrote:
> On 05/14/13 at 09:18am, Christopher Yeoh wrote:
>> <snip>
>> In a closely related issue there is also a blueprint covering promoting
>> APIs to core and vice-versa and we'll need to get a consensus around
>> this as well, so if anyone has any suggestions, please make them.
> 
> I'm assuming that core means on by default, and guaranteed to be on
> because there's some enforcement of it being loaded.  If this is not the
> case then disregard the rest of this post, but if it is I would like to
> propose an alternative.
> 
> Since everything will essentially be an extension in v3 what if core was
> just the default configuration value for extensions that should be
> loaded.  And there would be nothing preventing them from being turned
> off through configuration.

I really think we should force a base API to be present.  We can do our
users a huge favor by setting a core API that is *always* present, and
that will always work in a consistent manner, assuming a reasonably
capable compute driver is in use.  This is how we ensure a base level of
consistency among all OpenStack clouds.

> I bring this up mainly because not all hypervisors support the same
> features.  Currently this is mainly addressing the proposed promotion of
> console_output into core, which according to
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix would only be
> supported by half of the virt drivers in Nova.  With the other
> discussion happening around advertising capabilities in the API it seems
> like we shouldn't force capabilities to be advertised if they're not
> supported.

I don't think we should use what's supported by *every* hypervisor in
Nova as the bar.  Some of these drivers just aren't as capable, and we
shouldn't have to set an unreasonably low bar for the API because of them.

It's a good idea to take these things into account, but we're going to
have to choose some "first class citizens" to use for setting the bar.
The vast majority of deployments are using Xen or KVM, so if one of
those can't support something, it probably shouldn't be in the core API.

> I suppose another way I could phrase the argument would be that I think
> core, as I think it's currently defined, should not contain anything
> that can't be supported by any Nova deployment.  Which I think pares it
> down to a bare minimum of functionality that would be guaranteed to be
> loaded.
> 
> Anyways, just wanted to throw this out here and see what others think.


-- 
Russell Bryant