<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 11, 2013 at 1:02 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 07/11/2013 01:15 PM, Mark Collier wrote:<br>
> +1 to your last sentence... pointing out that the current policy /<br>
> license agreements specifically mandate a product must pass a<br>
> TC-approved interop test (a.k.a.. FITS).<br>
><br>
><br>
><br>
> On a practical level, I see the development of the test (leveraging<br>
> Tempest?) and decisions about what are "must pass" vs. "nice to pass" as<br>
> the critical next steps.<br>
><br>
><br>
><br>
> I'm not sure if it makes things simpler or more complex to equate "must<br>
> pass" with "core" and "nice to pass" with "non-core integrated"...<br>
<br>
As a quick data point - both the conversations at the board that Rob,<br>
Josh and I had and the tech ones we had at the last summit started with<br>
getting a scoreboard done at all. There are several related tasks around<br>
getting this done which Josh and I have both been calling refstack, but<br>
which I am coming to believe are actually two completely separate projects.<br>
<br>
The thing we discussed at the last summit was, as a next step, being<br>
able to run tempest against a cloud with a standard tempest config (not<br>
customized per cloud) This would then produce some number of failures<br>
and some number of passes, and that's expected. Analyzing and reporting<br>
on those passes and failures in some understandable manner so that board<br>
people can look at the status of a given feature or concept and start to<br>
make decisions. That's the part that the openstack project has slated to<br>
work on, and is pretty nicely tied to other infra work anyway.<br>
<br>
The other effort, which is what Josh has been calling refstack, is about<br>
having a system for registering endpoints, requesting to be tested and<br>
presenting a dashboard of results. This isn't a thing that the OpenStack<br>
project itself is really involved with, and may or may not even be a<br>
thing that the foundation officially runs - but I believe if it runs<br>
whatever the output of the first half of this is, then it can be a<br>
useful service. I think, for what it's worth, that Josh's thing is most<br>
likely the thing to retain the refstack name, and the other thing is<br>
going to be named something else. Like Larry. I dunno. not important<br>
right now.<br>
<br>
I mention this because there are efforts going in parallel to this<br>
discussion so that we'll be in a position to actually report on and<br>
respond to whatever the outcome here are.<br>
<br>
> "core" and "must pass" are both, to me, about doing whatever we can to<br>
> create, in the real world marketplace, lots of clouds calling themselves<br>
> "openstack" that have a set of functionality and behavior that can be<br>
> relied upon by end users (app developers etc).<br>
><br>
><br>
><br>
> Discoverability via API of what's inside a particular cloud is certainly<br>
> a desirable direction to account for the fact that deployments in the<br>
> real world are quite diverse.<br>
<br>
I think that certainly is a strong word, and I think that there is a<br>
world view in which it's a terrible idea. I think it's a worthwhile<br>
discussion to have. "to account for the fact that deployments in the<br>
real world are quite diverse" is the current situation we are in because<br>
we started off very focused on the needs of the service provider. It can<br>
certainly be argued that allowing that divergence comes at a cost. In<br>
fact, as someone who runs a massive cloud application across two public<br>
OpenStack clouds, I can tell you that the user experience is that in the<br>
places where they do not diverge, multiple openstack clouds is AMAZING<br>
and I am able to produce AMAZING applications. In the places where they<br>
do diverge, I want to kill people, because it makes those features<br>
completely and totally useless to me as a consumer.<br>
<br>
I'll call out Swift CDN as an example. CDN is an extension at both<br>
Rackspace and HP because swift core does not do cdn. That means that I<br>
cannot do cdn things with python-swiftclient, which means that I cannot<br>
consistently use the two swifts I have access to - which means I use<br>
neither. I'm sad about that, because swift is great technology. Instead,<br>
I have a nova vm connected to a very large cinder volume, and I run an<br>
apache server on it.<br>
<br>
So one can argue that it's important to let providers make their own<br>
choices and do things differently, and that's great if the value<br>
proposition that we were trying to get at here was to make Rackspace<br>
Cloud or HP Cloud the best cloud in the world.  But we're not. The value<br>
proposition that I'm working on is making OpenStack the best meta-cloud.<br>
Every way in which Rackspace and HP's public clouds diverge is a nail in<br>
our coffin, and one more step we're taking down the path of Open Group,<br>
posix and the death of the traditional unixes. Every way in which the<br>
constituent clouds that are part of the global OpenStack meta-cloud is a<br>
step towards us winning. AND growing the market. AND making tons of<br>
money for both Rackspace and HP's clouds.<br></blockquote><div><br></div><div style>+10 Very well said.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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