Open Stack

On 05/16/13 at 10:27am, Russell Bryant wrote:
>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'm actually not against this.  But if there's a forced API I think it 
should be somewhat minimal.  And promotion to core might occur because 
some functionality is deemed fairly essential to Nova, not necessarily 
because it's popular.

And I think consistency can be enforced by refstack and trademark 
guidelines, and doesn't necessarily need to be enforced by Nova.

More than anything I just want to have the conversation about what core 
means, which is always a heated topic in this community.  I have my own 
opinion on it but really I would like to see us all to be on the same 
page when making decisions about what should or should not be core, 
whatever page that is.

>
>> 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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev