Open Stack

On Thu, May 16, 2013 at 9:46 PM, Russell Bryant <rbryant at redhat.com> wrote:

> On 05/16/2013 08:18 PM, Andrew Laski wrote:
> > 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.
>
> Agreed, though all things essential to Nova are also likely to be
> popular.  :-)
>
> > And I think consistency can be enforced by refstack and trademark
> > guidelines, and doesn't necessarily need to be enforced by Nova.
>
> I definitely do not want to punt this problem to the board of directors.
>  I think setting some baseline of consistency is a technical issue and
> should be exclusively handled by the technical community.
>
> > 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.
>
> +1, definitely important to have this well defined before v3 is finalized.
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

FWIW this is exactly the question that I brought up a couple weeks back and
I have some very strong opinions on.  I honestly believe that there should
be *core* (for lack of a better term) API for each project and it should be
expected that the functionality/calls in that API should just work
(regardless of how they're implemented and whether it's efficient or not).

The stance I've taken in the Cinder project is that there's a core set of
functionality [1], each driver submitted to Cinder needs to be able to
provide this level of functionality.  There may be exceptions, grace
periods for folks to catch up etc, but really it seems like  a horrible
end-user experience to make an API call and get things like "Not
Implemented" one time and then not the next just by luck of the draw from
the scheduler and which back-end driver happened to be selected.  This sort
of defeats the purpose in my opinion.

Anyway, I agree with Russell, this is most definitely a Technical Community
issue and I would hope that we can reach an agreement on this without too
much difficulty.  I know that on the Cinder side I think we've finally all
agreed that this is a good thing and we're all more or less willing to
implement it and keep it updated.  We're at least trying it for another
cycle and I hope that it stands.

[1] https://wiki.openstack.org/wiki/Cinder#Minimum_Driver_Features

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/c67d8dc9/attachment.html>