Open Stack

On Thu, Apr 25, 2013 at 11:21 AM, Doug Hellmann <doug.hellmann at dreamhost.com
> wrote:

>
>
>
> On Thu, Apr 25, 2013 at 12:58 PM, John Griffith <
> john.griffith at solidfire.com> wrote:
>
>>
>>
>>
>> On Thu, Apr 25, 2013 at 10:07 AM, Doug Hellmann <
>> doug.hellmann at dreamhost.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Apr 25, 2013 at 11:24 AM, Monty Taylor <mordred at inaugust.com>wrote:
>>>
>>>>
>>>>
>>>> On 04/25/2013 11:15 AM, John Griffith 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.
>>>>
>>>> I agree with you 100% on this.
>>>>
>>>> >  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.
>>>>
>>>> Actually, the important response here is that it's on the TC to define
>>>> the technical characteristics. I believe your questions above are well
>>>> within scope.
>>>>
>>>> I'll say this - the current stated value proposition for OpenStack is
>>>> that multiple inter-operable clouds that run OpenStack provide value for
>>>> the user by preventing vendor lock in.
>>>>
>>>> We have several programs running right now to work on doing
>>>> interoperability definitions and testing.
>>>>
>>>> I think that it's safe to say that the emerging view point is that the
>>>> user experience of using an OpenStack cloud should not be altered based
>>>> on implementation choices. To that end, I believe you've been making the
>>>> right call, and we need to continue pushing viewpoints such as that.
>>>>
>>>
>>> I agree with the goal, but we also have to be careful not to define the
>>> pre and post conditions of the API endpoints based on assumptions derived
>>> from the capabilities of a single backend/driver (whether from a vendor or
>>> an open source project) in a way that restricts the feature set of
>>> OpenStack as a whole. For example, if we assume that snapshots always have
>>> a parent volume because some part of OpenStack core (not a driver) wants to
>>> do something with that volume, that's one thing. But if we assume that the
>>> parent volume is always there because a particular driver requires it not
>>> be deleted, maybe that's not something we need to bake into the API
>>> definition. (Disclaimer: I'm not a block storage expert, so take that as an
>>> example rather than an argument for/against this specific decision.)
>>>
>>
>> Fair point, and I'm not saying we limit anybody in what they can provide,
>> but I am saying it seems wrong to allow everybody to have their own
>> definition and implementation.  I think there's a clear difference between
>> core API/Functionality and extras as you mention.
>>
>
> We seem to be agreeing. :-) My main point was that "extensions" or
> legitimate differences in behavior will not always mean new API calls, and
> that in a lot of cases that may be OK as long as those differences aren't
> changes to the fundamental expectations of the user.
>

Ahh... yes, I think we do agree here, thanks for clarifying.

>
>
>>
>>> Another way to handle interoperability for "optional" features/behaviors
>>> is to provide an API for the client to learn what is supported by a given
>>> implementation. That way at least the app calling the API can decide what
>>> to allow before trying something and getting an error.
>>>
>>
>> Sure, but in the case of Cinder or multiple back-ends you have no
>> expectation on what the behaviors or characteristics are.  This seems
>> contradictory to me to say "API for the client to learn what's supported"
>> and to use the term interoperability.  That means interoperability if you
>> implement OpenStack exactly the same way with the same options and back-end
>> devices.
>>
>
> True, the definitions of "features" would have to be taken on a
> case-by-case basis. I'm not saying we let every driver and deployment do
> whatever they want, but for cases where it doesn't matter to the core of
> OpenStack, we can afford some flexibility.
>

Yep, 100%, my companies driver is an example of this.  It offers additional
features but doesn't change/break any behaviors in the core api or behave
differently if you're not using said features.


>
> Doug
>
> PS - Thierry mentioned moving this to the dev list. I don't mind if
> someone wants to move the thread with the next reply, or if John wants to
> just start a new thread over there.
>
>
>>
>>> Doug
>>>
>>>
>>>>
>>>> > 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..
>>>>
>>>> I'd be in favor of making a more formal technical statement around what
>>>> we think interoperability and API policy should look like here. You're
>>>> WELL within your rights as PTL to just be making that call right now -
>>>> but writing something down and being clear about it so that it doesn't
>>>> keep coming up might be friendly to people.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130425/e47fb570/attachment.html>