Open Stack

To me, the most important thing is being able to accurately understand what capabilities are supported (or not) by an API whether core or extension.

Personally I think the right answer is that a "core" API must be 100% implemented. If it's not 100% necessary than why is it core?

That said, "core" should not represent the capabilities of the default implementation, instead it should represent the features that the service defines as being truly required regardless of any implementation.

So to this question: deleting the parent volume while there are still dependent snapshots sounds like it is not essential to being "core", and should be exposed as an additional non-core capability which is discoverable at /extensions. That way consumers of the API can know that by default this is not supported, but if the capability is reported as being enabled as an extension then you can go ahead and make that call with the expectation of success.

    - Gabriel

> -----Original Message-----
> From: Mark McClain [mailto:mark.mcclain at dreamhost.com]
> Sent: Thursday, April 25, 2013 11:31 AM
> To: openstack-tc at lists.openstack.org
> Subject: Re: [openstack-tc] [OpenStack-TC] Agenda item proposal
> 
> We face a similar problem in Networking.  For sometime, we've had the hard
> requirement that the core API must be supported for a plugin to be
> submitted.  The vendors have been ok with this because our core API is
> relatively small.  The small API has created another item we've been
> discussing: How do extensions become part of the core and what happens to
> existing plugins that do not support those extensions?  Currently, we've
> sidestepped the issue and do plan to migrate any widely adopted extensions
> into core during Havana.
> 
> mark
> 
> 
> On Apr 25, 2013, at 11:15 AM, John Griffith <john.griffith at solidfire.com>
> wrote:
> 
> > Hey Folks,
> >
> > With the growth of vendor activity in the form of driver submissions in
> Cinder there's some concerns and challenges that I have and I'd like to get
> some thoughts from the TC as I move forward.
> >
> > The short version here is:
> >     "What is our goal with OpenStack WRT API behavior and
> implementation?"
> >
> >
> >
> > The longer detailed version:
> >
> > With the increased activity from Vendors in Cinder adding their drivers
> there's some conflicts regarding  what should be required for acceptance.
> My position on this has been pretty simple (albeit unpopular) that if it's
> supported by the reference implementation (LVM Driver) and it's a core API
> call then those are your requirements.
> >
> > In addition I feel that behaviors of the API should be standard regardless of
> what driver is being used.  For example; a number of folks have proposed
> that they should be able to do things like "delete a parent volume of a
> snapshot" if the driver supports it, if the driver doesn't then just return an
> error.
> >
> > My response to this has been NO WAY, because the result is different
> behaviors and expectations based on what driver is currently in use.  This is
> very bad IMO because the whole point of Cinder from my perspective is to
> abstract those differences and details out.  Adding functionality and features
> on top of the reference implementation (via extensions, types etc) is one
> thing, but deviating from the behavior is a very bad idea IMO.  It would be
> one thing if there was no way to achieve what the vendor would like to
> accomplish but the fact is in almost every one of these cases that comes up
> there's a way to do what they would like, it just doesn't use the vocabulary or
> semantics that they would like.
> >
> > Anyway, I know we pushed the "what is OpenStack" back to the board at
> one point and I don't recall ever seeing a clear response on that.  What I'd like
> to do as a TC function is to actually define some sort of goal or mission
> statement of what we are hoping to provide.  This doesn't have to be a huge
> debate or a 1000 page manifesto, just a clear mission statement on what an
> end user or provider should expect when they install OpenStack projects and
> use the API.
> >
> > I can continue to make my own calls on this which is fine with me, but I
> suspect that other projects either are dealing with, or will be dealing with this
> same sort of issue.  It might be worth discussing and putting some sort of
> concept around what our goal is here.
> >
> > Thanks,
> > John
> >
> >
> >
> > _______________________________________________
> > OpenStack-TC mailing list
> > OpenStack-TC at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
> 
> 
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc