Open Stack

On 07/11/2013 01:15 PM, Mark Collier wrote:
> +1 to your last sentence... pointing out that the current policy /
> license agreements specifically mandate a product must pass a
> TC-approved interop test (a.k.a.. FITS).
> 
>  
> 
> On a practical level, I see the development of the test (leveraging
> Tempest?) and decisions about what are "must pass" vs. "nice to pass" as
> the critical next steps.
> 
>  
> 
> I'm not sure if it makes things simpler or more complex to equate "must
> pass" with "core" and "nice to pass" with "non-core integrated"...

As a quick data point - both the conversations at the board that Rob,
Josh and I had and the tech ones we had at the last summit started with
getting a scoreboard done at all. There are several related tasks around
getting this done which Josh and I have both been calling refstack, but
which I am coming to believe are actually two completely separate projects.

The thing we discussed at the last summit was, as a next step, being
able to run tempest against a cloud with a standard tempest config (not
customized per cloud) This would then produce some number of failures
and some number of passes, and that's expected. Analyzing and reporting
on those passes and failures in some understandable manner so that board
people can look at the status of a given feature or concept and start to
make decisions. That's the part that the openstack project has slated to
work on, and is pretty nicely tied to other infra work anyway.

The other effort, which is what Josh has been calling refstack, is about
having a system for registering endpoints, requesting to be tested and
presenting a dashboard of results. This isn't a thing that the OpenStack
project itself is really involved with, and may or may not even be a
thing that the foundation officially runs - but I believe if it runs
whatever the output of the first half of this is, then it can be a
useful service. I think, for what it's worth, that Josh's thing is most
likely the thing to retain the refstack name, and the other thing is
going to be named something else. Like Larry. I dunno. not important
right now.

I mention this because there are efforts going in parallel to this
discussion so that we'll be in a position to actually report on and
respond to whatever the outcome here are.

> "core" and "must pass" are both, to me, about doing whatever we can to
> create, in the real world marketplace, lots of clouds calling themselves
> "openstack" that have a set of functionality and behavior that can be
> relied upon by end users (app developers etc).
> 
>  
> 
> Discoverability via API of what's inside a particular cloud is certainly
> a desirable direction to account for the fact that deployments in the
> real world are quite diverse.

I think that certainly is a strong word, and I think that there is a
world view in which it's a terrible idea. I think it's a worthwhile
discussion to have. "to account for the fact that deployments in the
real world are quite diverse" is the current situation we are in because
we started off very focused on the needs of the service provider. It can
certainly be argued that allowing that divergence comes at a cost. In
fact, as someone who runs a massive cloud application across two public
OpenStack clouds, I can tell you that the user experience is that in the
places where they do not diverge, multiple openstack clouds is AMAZING
and I am able to produce AMAZING applications. In the places where they
do diverge, I want to kill people, because it makes those features
completely and totally useless to me as a consumer.

I'll call out Swift CDN as an example. CDN is an extension at both
Rackspace and HP because swift core does not do cdn. That means that I
cannot do cdn things with python-swiftclient, which means that I cannot
consistently use the two swifts I have access to - which means I use
neither. I'm sad about that, because swift is great technology. Instead,
I have a nova vm connected to a very large cinder volume, and I run an
apache server on it.

So one can argue that it's important to let providers make their own
choices and do things differently, and that's great if the value
proposition that we were trying to get at here was to make Rackspace
Cloud or HP Cloud the best cloud in the world.  But we're not. The value
proposition that I'm working on is making OpenStack the best meta-cloud.
Every way in which Rackspace and HP's public clouds diverge is a nail in
our coffin, and one more step we're taking down the path of Open Group,
posix and the death of the traditional unixes. Every way in which the
constituent clouds that are part of the global OpenStack meta-cloud is a
step towards us winning. AND growing the market. AND making tons of
money for both Rackspace and HP's clouds.

But we have GOT to continue fighting the urge to think of each cloud as
a beautiful unique snowflake.

> 
> I believe the spirit of the "must enable plug-ins to be considered for
> core" (and having at least one open source reference that's useable) is
> philosophically about ensuring the real world of "openstack clouds" are
> flexible enough to accommodate multiple technologies to solve a
> particular domain's problems, while guarding against a trojan vendor
> lock in scenario.
> 
>  
> 
>  
> 
>  
> 
> On Thursday, July 11, 2013 11:56am, "Monty Taylor"
> <mordred at inaugust.com> said:
> 
>>
>>
>> On 07/11/2013 12:39 PM, Thierry Carrez wrote:
>> > Russell Bryant wrote:
>> >> On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com wrote:
>> >>> 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.
>> >>
>> >> 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.
>> >
>> > This is new to me too, but AFAICT it's an effort to define the list of
>> > criteria the board intends to apply for granting the "core" label on a
>> > given project.
>> >
>> > We ruled that the TC was free to produce the stuff it wanted, and that
>> > the board was free to apply a "core" label to a subset of that. they are
>> > also free to define what they mean by "core" (or any other label they
>> > may want to create).
>> >
>> > As an example:
>> >
>> >> * In the introduction, the secondary issue identified is whether
>> >> projects should be pluggable. I believe this is TC territory.
>> >
>> > If they want to grant the "core" label only to pluggable projects, I'm
>> > not sure that would be in our territory ?
>>
>> No, I believe Russell is correct, and I'm sorry I did not catch/raise
>> this earlier. The reason we have a board/tc split is separation of
>> specialty. It is not expected that people on the board have the
>> technical background to make technical decisions, it is conversely not
>> expected that members of the TC have the business/legal background to
>> make decisions on issues around brand or trademark. That some of us on
>> the board have technical backgrounds is a thing I think we must be
>> vigilant about and not forget the role we have been asked to play on
>> that body. In that regard, I believe I have failed at the moment.
>>
>> The split between integrated and core is similarly intended to let the
>> technical body decide about implementation issues and let the board make
>> decisions on the *what*, as Russel says. While the language may
>> theoretically allow the board to apply whatever criteria it wants to to
>> grant the core label, I think it's very important we don't create a
>> shadow TC of folks making additional technical judgment calls and using
>> trademark to enforce them. It's not an us vs. them thing - it's quite
>> simply a scope-of-body-of-people thing. If both bodies have 'final' say
>> on a technical matter but with a different label, no one anywhere is
>> going to be able to figure out what the heck OpenStack is.
>>
>> Back to the matter at hand, I think Doug's suggestions move in the
>> direction of where the language should go.
>>
>> "The cloud must pass the automated test suite designated by the TC as
>> defining interoperability"
>>
>> both states an outcome the board wants to see, and lets the TC decide.
>> I'd even remove the word 'automated' - although I'm _certain_ that the
>> TC would want it to be automated and not manual. That sentence above is
>> actually quite similar to one that's in our current trademark policy, btw.
>>
>>
>> _______________________________________________
>> Foundation-board mailing list
>> Foundation-board at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
>>
>