Open Stack

On Thu, Jul 11, 2013 at 1:02 PM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> 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.
>

+10 Very well said.


>
> 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
> >>
> >
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130711/cba9be35/attachment-0001.html>