Open Stack

We also need to define the process for change of the tests


-        What is the lead time before an additional set of tests become the standard ?

-        For how long will a branded cloud be allowed to continue to be branded while failing the tests ?

There could be two different styles of tests which could have different parameters:


-        Those that increase the quality of testing (such as testing an additional use case)

-        Those that increase the scope of testing (such as a new component)

Tim

From: Mark Collier [mailto:mark at openstack.org]
Sent: 05 February 2014 18:23
To: Troy Toman
Cc: foundation at lists.openstack.org
Subject: Re: [OpenStack Foundation] The two types of interoperability


I think "the branding issue" is inseparable from interop (unless I misunderstand what you mean by that).



I think the initial phases of defcore make sense, in so much as the focus is on defining what is expected to be in commercial products and services to be called "openstack", and in starting with a modest definition and a reasonable set of tests (largely based on what already exists) so that progress can be made quickly.  To me these things are the critical next steps on the road to interop.



At the moment, there are zero tests being used as a gate for the use of the mark commercially*, so as long as X is >0 it's an infinite improvement IMHO, and one that can't come soon enough. Note that the tests are not the sum total of the requirements today for the commercial use of the mark, nor should they be in the future, but as an additive step they are most welcome and helpful.



Mark



*To be clear, the use of the mark DOES currently require, contractually, that products/services pass tests... the tests just need to exist.  This is why I will throw a party when we can implement the first tests, however modest









On Wednesday, February 5, 2014 10:44am, "Troy Toman" <troy.toman at rackspace.com<mailto:troy.toman at rackspace.com>> said:

>
>
> > On Feb 5, 2014, at 6:05 AM, "Thierry Carrez" <thierry at openstack.org<mailto:thierry at openstack.org>>
> wrote:
> >
> > Mark McLoughlin wrote:
> >> To put the question another way - which helps users more? The ability to
> >> write interoperable code which uses a large number of OpenStack APIs,
> >> but which is only actually interoperable between a small number of
> >> OpenStack clouds? Or interoperability whereby you have a smaller set of
> >> interoperable APIs, but code that uses only those APIs would be
> >> interoperable with a much larger number of OpenStack clouds?
> >
> > I like your way of framing the question.
> >
> > Personally I think going for loose interoperability is short-sighted.
> > Yes you'll have a lot of providers but you'll forever have a bad
> > experience moving workloads around.
>
> +1
>
> >
> > With total interoperability, you may have less providers at start, but
> > at least they provide a great experience moving workloads around. And as
> > more join them, it only gets better. Total interoperability is basically
> > the only way to potentially reach one day the nirvana of "lots of
> > providers + great end user experience".
> >
> > The trick is to bootstrap it. If you have 0 or 1 "true openstack" cloud
> > available at first, it's hard to get any benefit from that hypothetical
> > federation. Total interop requires a bit of a leap of faith.
> >
> > So yet another way to frame that discussion (at board level) is: are you
> > more interested in convergence and federation (and beating Amazon all
> > together), or are you more interested in competing (and be a set of
> > individual loosely-coupled small competitors to Amazon).
>
> I think this is the right conversation to have around the goal of
> interoperability. I think it is important to note that it was decided to NOT focus
> on interoperability in the initial phases of DefCore but to just try and solve the
> branding issue. Based on the feedback, it feels like the most pressing issue
> really is around interop and we should wade into that sooner rather than later
> even if it is (or maybe because it is) messy. As I said earlier, I also don't
> think it is helpful to try and solve both with one label or brand.
>
> Given all that, I am very supportive of taking simpler first steps and "learning"
> our way into this. I think it is more likely to not only yield progress sooner but
> get us to the proper endpoint faster too. Making tangible progress on making
> federation/convergence is critical for OpenStack in 2014 IMHO. Or, if we can't
> line up on that goal, then let's be explicit and stop setting that expectation. I
> really hope we can do the former. I'm not sure what a loosely-coupled set of
> clouds does to change the landscape.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > _______________________________________________
> > Foundation mailing list
> > Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140205/b79b0670/attachment-0001.html>