Open Stack

On Thu, Jul 11, 2013 at 10:23 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

>
> On Thu, Jul 11, 2013 at 9:01 AM, Russell Bryant <rbryant at redhat.com>wrote:
>
>> On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com wrote:
>> > Board & TC Members,
>> >
>> >
>> >
>> > Alan and I have planned another 2 hour discussion session around the
>> > spider chart / what is core action plan.  The goal for this meeting is
>> > to refine the 6 positions that we’ve articulated and identify additional
>> > ones needed (my gut says, 4+ more).
>> >
>> >
>> >
>> > If you have not been part of this meeting, we’ll explain what’s going on
>> > in the 1^st 15 minutes (and there’s information in the etherpad too).
>> > I’m working on a post about it too, but you’ll have to wait for that.
>>
>> > Background info:
>> https://etherpad.openstack.org/Board-2013-SpiderDiscussion
>>
>> This is the first time I've seen this.  I must admit that my initial
>> reaction is that I'm not comfortable with the direction this seems to be
>> taking.
>>
>
> Same here, and I agree.
>
>
>>
>> I understand the need to have a solid definition of what "core" means.
>> I also assume that the goal here is to eventually arrive at some set of
>> definitions and policies.
>>
>> However, some of the specific items discussed on this etherpad are
>> things that are in my opinion, in TC (or even project specific
>> governance) territory, and should be considered out of scope for any
>> policy coming from the board.
>>
>> Some specific areas of concern to me:
>>
>> * In the introduction, the secondary issue identified is whether
>> projects should be pluggable.  I believe this is TC territory.
>>
>> * Position statement 1, "plug-in model expected for projects".  I
>> believe this is completely TC territory.
>>
>
> +1; not only TC territory, but it's a bogus assertion. Not everything has
> a use case for pluggability... hence the statement made in the etherpad
> "certain projects highly pluggable [...] while others have an opinion."
>

Perhaps this is an attempt to say "The implementation should not be tied to
a single vendor or open source backend."

There is also a certain amount of vagueness in the terms "plugin" and
"extension." There's probably some well-understood history on the part of
the people involved in the conversation now, but we need to have those
terms defined more precisely if we're going to use them as the basis of
certifying interoperability.


>
>
>>
>> * Position statement 2, "API extension model expected for plugin-ins".
>> Again, I believe this is completely TC territory.
>>
>
> +1 for TC.
>

There's also an argument to be made that APIs should *not* support
extensions, because that hurts interoperability -- an API with extensions
is different than one without.


>
>
>>
>> * Position statement 3, "Tempest used as basis for OpenStack mark".  I
>> think this is the wrong approach to take.  I think any position should
>> assume a specific test suite.  It should identify *what* exactly should
>> be covered in tests.  Using tempest is an implementation detail that
>> comes after deciding *what*.  Do you want to verify just against core
>> APIs?  All API extensions?  Whatever happens to be tested by tempest
>> today doesn't seem like a good definition.
>>
>
> +1; start by considering the goals of tempest, not tempest itself.
>

This feels like another overly specific statement with the right goal.
Rephrasing as "The cloud must pass the automated test suite designated by
the TC as defining interoperability" keeps the goal, but leaves the
specifics for later.


>
>
>>
>> * In the "questions to ask" section, I disagree with many of things even
>> being questions asked in this forum.  I won't go through all of them
>> individually.
>>
>> I don't have answers here, but I wanted to raise my discomfort and see
>> if anyone else felt similarly.
>>
>
> Thank you.
>

+1

Doug


>
>
>>
>> Thanks,
>>
>> --
>> Russell Bryant
>>
>> _______________________________________________
>> OpenStack-TC mailing list
>> OpenStack-TC at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>>
>
>
>
> --
>
> -Dolph
>
> _______________________________________________
> 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/20130711/178ff078/attachment-0001.html>