Mailing List Archive

In some ways, at least to me, the main end-goal is having OpenStack be a
standard and reference implementation, which allows for others to extend
and build upon. The web succeeded because the standard (HTTP) was agreed
upon by all, and a free and open reference implementation, which was
developed and governed by a neutral community, (Apache httpd) was available.


On Thu, Oct 31, 2013 at 5:06 AM, Thierry Carrez <thierry@openstack.org>wrote:

> Mark McLoughlin posted a very interesting view at:
>
> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/
>
> I agree with him. "Core" is not a goal, it's just a means to an end. A
> "market of interoperable OpenStack clouds" is the goal. By focusing on
> the means rather than the end goal, we face the risk of missing the target.
>
> If you focus on the end goal, you realize there is a choice between two
> approaches: the common denominator approach (aim for a small set to make
> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
> the prescriptive approach (define what would make a "complete" OpenStack
> cloud, and use the power of the trademark to encourage everyone to
> converge towards that). There is no way around that choice and we should
> have the courage to tackle it early rather than late.
>
> I like Rob's approach to the problem because it tries to be neutral and
> technical, however I'm concerned that it defers the hard (and political)
> choice between those approaches, concentrates on the mechanics and hopes
> that those will somehow tell us where the finish line is.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>

A reference implementation is good but, as I have explained to Rob, there is a need to allow a cloud which has chosen to implement an alternative to still be defined as 'OpenStack API compliant'.

A typical example would be if ceph was chosen as an object store rather than swift. From the outside, they'd look the same but it is an implementation choice.

Tim

From: Jim Jagielski [mailto:jimjag@gmail.com]
Sent: 31 October 2013 15:12
To: Thierry Carrez
Cc: foundation@lists.openstack.org
Subject: Re: [OpenStack Foundation] OpenStack core and interoperability

In some ways, at least to me, the main end-goal is having OpenStack be a standard and reference implementation, which allows for others to extend and build upon. The web succeeded because the standard (HTTP) was agreed upon by all, and a free and open reference implementation, which was developed and governed by a neutral community, (Apache httpd) was available.

On Thu, Oct 31, 2013 at 5:06 AM, Thierry Carrez <thierry@openstack.org<mailto:thierry@openstack.org>> wrote:
Mark McLoughlin posted a very interesting view at:
http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/

I agree with him. "Core" is not a goal, it's just a means to an end. A
"market of interoperable OpenStack clouds" is the goal. By focusing on
the means rather than the end goal, we face the risk of missing the target.

If you focus on the end goal, you realize there is a choice between two
approaches: the common denominator approach (aim for a small set to make
sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
the prescriptive approach (define what would make a "complete" OpenStack
cloud, and use the power of the trademark to encourage everyone to
converge towards that). There is no way around that choice and we should
have the courage to tackle it early rather than late.

I like Rob's approach to the problem because it tries to be neutral and
technical, however I'm concerned that it defers the hard (and political)
choice between those approaches, concentrates on the mechanics and hopes
that those will somehow tell us where the finish line is.

--
Thierry Carrez (ttx)

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org<mailto:Foundation@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, Oct 31, 2013 at 10:29 AM, Tim Bell <Tim.Bell@cern.ch> wrote:

> ** **
>
> A reference implementation is good but, as I have explained to Rob, there
> is a need to allow a cloud which has chosen to implement an alternative to
> still be defined as ‘OpenStack API compliant’.
>

Of course. A reference implementation doesn't preclude other compliant
implementations at all.


> ****
>
> ** **
>
> A typical example would be if ceph was chosen as an object store rather
> than swift. From the outside, they’d look the same but it is an
> implementation choice.****
>
> ** **
>
> Tim****
>
> ** **
>
> *From:* Jim Jagielski [mailto:jimjag@gmail.com]
> *Sent:* 31 October 2013 15:12
> *To:* Thierry Carrez
> *Cc:* foundation@lists.openstack.org
> *Subject:* Re: [OpenStack Foundation] OpenStack core and interoperability*
> ***
>
> ** **
>
> In some ways, at least to me, the main end-goal is having OpenStack be a
> standard and reference implementation, which allows for others to extend
> and build upon. The web succeeded because the standard (HTTP) was agreed
> upon by all, and a free and open reference implementation, which was
> developed and governed by a neutral community, (Apache httpd) was available.
> ****
>
> ** **
>
> On Thu, Oct 31, 2013 at 5:06 AM, Thierry Carrez <thierry@openstack.org>
> wrote:****
>
> Mark McLoughlin posted a very interesting view at:
>
> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/
>
> I agree with him. "Core" is not a goal, it's just a means to an end. A
> "market of interoperable OpenStack clouds" is the goal. By focusing on
> the means rather than the end goal, we face the risk of missing the target.
>
> If you focus on the end goal, you realize there is a choice between two
> approaches: the common denominator approach (aim for a small set to make
> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
> the prescriptive approach (define what would make a "complete" OpenStack
> cloud, and use the power of the trademark to encourage everyone to
> converge towards that). There is no way around that choice and we should
> have the courage to tackle it early rather than late.
>
> I like Rob's approach to the problem because it tries to be neutral and
> technical, however I'm concerned that it defers the hard (and political)
> choice between those approaches, concentrates on the mechanics and hopes
> that those will somehow tell us where the finish line is.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation****
>
> ** **
>

Hi,

On 10/31/2013 10:06 AM, Thierry Carrez wrote:
> Mark McLoughlin posted a very interesting view at:
> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/

Awesome summary & more or less exactly what I think.

> I agree with him. "Core" is not a goal, it's just a means to an end. A
> "market of interoperable OpenStack clouds" is the goal. By focusing on
> the means rather than the end goal, we face the risk of missing the target.

The goal is: allow someone using one OpenStack cloud to move *his* stuff
to another OpenStack cloud easily. Also allow someone to burst from a
private OpenStack cloud to a public OpenStack cloud easily on demand.
That could be achieved by interoperability, but the definition of
interoperability could also be too narrow to allow that.

> If you focus on the end goal, you realize there is a choice between two
> approaches: the common denominator approach (aim for a small set to make
> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
> the prescriptive approach (define what would make a "complete" OpenStack
> cloud, and use the power of the trademark to encourage everyone to
> converge towards that). There is no way around that choice and we should
> have the courage to tackle it early rather than late.

Third option: standardise on interfaces and behaviour, and ignore
implementation.

Cheers,
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Before I answer some specific points, I'd like to say that I agree with
Thierry's assesssment of the goal.

I'd also like to say that I am in favor of defining what I think a cloud
should be and using the power of the brand to encourage people to
converge towards that.

I believe that even in the short time OpenStack has been here, we've
seen that every time OpenStack doesn't have a stated opinion, everyone
rushes to diverge as quickly as humanly possible, but as soon as there
is an opinion, even a vague one, convergence starts to happen. I'd like
to continue that trend, because I think it's in the best interests of
our users.

On 10/31/2013 07:29 AM, Tim Bell wrote:
>
>
> A reference implementation is good but, as I have explained to Rob,
> there is a need to allow a cloud which has chosen to implement an
> alternative to still be defined as ‘OpenStack API compliant’.

I think "API compliant" is a fine thing, as long as there is a
difference between saying "this IS OpenStack" and "this is compatible
with OpenStack"

>
> A typical example would be if ceph was chosen as an object store rather
> than swift. From the outside, they’d look the same but it is an
> implementation choice.
>
>
>
> Tim
>
>
>
> *From:*Jim Jagielski [mailto:jimjag@gmail.com]
> *Sent:* 31 October 2013 15:12
> *To:* Thierry Carrez
> *Cc:* foundation@lists.openstack.org
> *Subject:* Re: [OpenStack Foundation] OpenStack core and interoperability
>
>
>
> In some ways, at least to me, the main end-goal is having OpenStack be a
> standard and reference implementation, which allows for others to extend
> and build upon. The web succeeded because the standard (HTTP) was agreed
> upon by all, and a free and open reference implementation, which was
> developed and governed by a neutral community, (Apache httpd) was available.

I believe we've always been quite strongly against having a defined
standard and then implementing it.

> On Thu, Oct 31, 2013 at 5:06 AM, Thierry Carrez <thierry@openstack.org
> <mailto:thierry@openstack.org>> wrote:
>
> Mark McLoughlin posted a very interesting view at:
> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/
>
> I agree with him. "Core" is not a goal, it's just a means to an end. A
> "market of interoperable OpenStack clouds" is the goal. By focusing on
> the means rather than the end goal, we face the risk of missing the
> target.
>
> If you focus on the end goal, you realize there is a choice between two
> approaches: the common denominator approach (aim for a small set to make
> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
> the prescriptive approach (define what would make a "complete" OpenStack
> cloud, and use the power of the trademark to encourage everyone to
> converge towards that). There is no way around that choice and we should
> have the courage to tackle it early rather than late.
>
> I like Rob's approach to the problem because it tries to be neutral and
> technical, however I'm concerned that it defers the hard (and political)
> choice between those approaches, concentrates on the mechanics and hopes
> that those will somehow tell us where the finish line is.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org <mailto:Foundation@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>
>
>
>
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On 10/31/2013 07:36 AM, Dave Neary wrote:
> Hi,
>
> On 10/31/2013 10:06 AM, Thierry Carrez wrote:
>> Mark McLoughlin posted a very interesting view at:
>> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/
>
> Awesome summary & more or less exactly what I think.
>
>> I agree with him. "Core" is not a goal, it's just a means to an end. A
>> "market of interoperable OpenStack clouds" is the goal. By focusing on
>> the means rather than the end goal, we face the risk of missing the target.
>
> The goal is: allow someone using one OpenStack cloud to move *his* stuff
> to another OpenStack cloud easily. Also allow someone to burst from a
> private OpenStack cloud to a public OpenStack cloud easily on demand.
> That could be achieved by interoperability, but the definition of
> interoperability could also be too narrow to allow that.
>
>> If you focus on the end goal, you realize there is a choice between two
>> approaches: the common denominator approach (aim for a small set to make
>> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
>> the prescriptive approach (define what would make a "complete" OpenStack
>> cloud, and use the power of the trademark to encourage everyone to
>> converge towards that). There is no way around that choice and we should
>> have the courage to tackle it early rather than late.
>
> Third option: standardise on interfaces and behaviour, and ignore
> implementation.

There is a VERY specific and strong reason why this is not the approach,
and that's because it disincentivies people from working on OpenStack
itself. We already have the problem with Neutron where not enough
companies are working on the core of neutron because they're all only
working on their vendor plugins. If OpenStack all of a sudden became a
set of interfaces, then the goal of an Open cloud would, I'm pretty
certain, become lost.

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

+1

> On Oct 31, 2013, at 9:41 AM, Monty Taylor <mordred@inaugust.com> wrote:
>
>
>
>> On 10/31/2013 07:36 AM, Dave Neary wrote:
>> Hi,
>>
>>> On 10/31/2013 10:06 AM, Thierry Carrez wrote:
>>> Mark McLoughlin posted a very interesting view at:
>>> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/
>>
>> Awesome summary & more or less exactly what I think.
>>
>>> I agree with him. "Core" is not a goal, it's just a means to an end. A
>>> "market of interoperable OpenStack clouds" is the goal. By focusing on
>>> the means rather than the end goal, we face the risk of missing the target.
>>
>> The goal is: allow someone using one OpenStack cloud to move *his* stuff
>> to another OpenStack cloud easily. Also allow someone to burst from a
>> private OpenStack cloud to a public OpenStack cloud easily on demand.
>> That could be achieved by interoperability, but the definition of
>> interoperability could also be too narrow to allow that.
>>
>>> If you focus on the end goal, you realize there is a choice between two
>>> approaches: the common denominator approach (aim for a small set to make
>>> sure most current "OpenStack clouds" will stay "OpenStack clouds"), and
>>> the prescriptive approach (define what would make a "complete" OpenStack
>>> cloud, and use the power of the trademark to encourage everyone to
>>> converge towards that). There is no way around that choice and we should
>>> have the courage to tackle it early rather than late.
>>
>> Third option: standardise on interfaces and behaviour, and ignore
>> implementation.
>
> There is a VERY specific and strong reason why this is not the approach,
> and that's because it disincentivies people from working on OpenStack
> itself. We already have the problem with Neutron where not enough
> companies are working on the core of neutron because they're all only
> working on their vendor plugins. If OpenStack all of a sudden became a
> set of interfaces, then the goal of an Open cloud would, I'm pretty
> certain, become lost.
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:
> There is a VERY specific and strong reason why this is not the approach,
> and that's because it disincentivies people from working on OpenStack
> itself. We already have the problem with Neutron where not enough
> companies are working on the core of neutron because they're all only
> working on their vendor plugins. If OpenStack all of a sudden became a
> set of interfaces, then the goal of an Open cloud would, I'm pretty
> certain, become lost.

Rob talks about using having three tools - our culture, our velocity and
our trademark. The first two could be as effective at having people
choose to use OpenStack itself rather than a compatible implementation
of its interfaces.

I could see us having two trademark programs "OpenStack Cloud" - where
you know that the provider is running a "faithful implementation" of
OpenStack code - and "OpenStack Compatible Cloud" - where you just know
the provider is compatible with the interfaces.

I'd see having "OpenStack Compatible Cloud" as the first priority.

If we can figure out how to build a sane "OpenStack Cloud" program in
short order, then awesome. But it shouldn't hold back the first program.

Mark.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, 2013-10-31 at 14:52 +0000, Mark McLoughlin wrote:
> On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:
> > There is a VERY specific and strong reason why this is not the approach,
> > and that's because it disincentivies people from working on OpenStack
> > itself. We already have the problem with Neutron where not enough
> > companies are working on the core of neutron because they're all only
> > working on their vendor plugins. If OpenStack all of a sudden became a
> > set of interfaces, then the goal of an Open cloud would, I'm pretty
> > certain, become lost.
>
> Rob talks about using having three tools - our culture, our velocity and
> our trademark. The first two could be as effective at having people
> choose to use OpenStack itself rather than a compatible implementation
> of its interfaces.
>
> I could see us having two trademark programs "OpenStack Cloud" - where
> you know that the provider is running a "faithful implementation" of
> OpenStack code - and "OpenStack Compatible Cloud" - where you just know
> the provider is compatible with the interfaces.
>
> I'd see having "OpenStack Compatible Cloud" as the first priority.
>
> If we can figure out how to build a sane "OpenStack Cloud" program in
> short order, then awesome. But it shouldn't hold back the first program.

Oh, and to be clear - if it did happen this way, I'd quite happily
deprecate the "OpenStack Compatible Cloud" program once we have the
"OpenStack Cloud" program in place.

Or maybe there's only one program and the "use OpenStack code"
requirement gets added in the future.

So, I agree that it is not a long-term goal for OpenStack to be a
standards organization encouraging multiple alternate implementations of
its APIs.

But we do need to get moving on encouraging interoperability between
public clouds, even if that means making a short term tactical decision
that we don't need to require they use OpenStack code for everything.

Mark.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, Oct 31, 2013 at 10:41 AM, Monty Taylor <mordred@inaugust.com> wrote:

> If OpenStack all of a sudden became a
> set of interfaces, then the goal of an Open cloud would, I'm pretty
> certain, become lost.


It really depends on the strength of the community around those
"interfaces"...

I use the term interface, in this context at least, very loosely. Think of
it more as the set or protocols and standards. In this meaning, having a
default, FOSS implementation, managed by a neutral entity with a real
strong community behind it is *crucial*.

Not to reference Apache httpd again, but the concerns and issues regarding
an "Open Cloud" is not so much different than the "old" days of an "Open
Web". During those times, there was *significant* incentive for externals
to drive the web, to create their own "version" of the web. AOL tried it,
and it was the availability of Apache, as well as the huge amount of
community around Apache and its status as a reference implementation that
allowed us back then to stop AOL's efforts in their tracks. You can find
similar parallels in other areas as well.

Let's not think that OpenStack is sooooo unique that it has nothing that
can be learned by others who came before. Isn't that what true Open Source
is about?

On Thu, Oct 31, 2013 at 9:58 AM, Mark McLoughlin <markmc@redhat.com> wrote:

> Or maybe there's only one program and the "use OpenStack code"
> requirement gets added in the future.
>
[...]

> But we do need to get moving on encouraging interoperability between
> public clouds, even if that means making a short term tactical decision
> that we don't need to require they use OpenStack code for everything.


That is a one-way gate. I would be surprised to see a deployment revert
from using Ceph rather than Swift in order to meet that, after all there
was a valid-to-the-deployer reason to not use Swift in the first place. An
upstream requirements change doesn't change that.

That said, I do agree that the OpenStack API compatibility is important now
and shouldn't wait for the long-term ideal. But I have no expectation that
adding things like the code requirements down the road will change the
existing deployments.

dt

--

Dean Troyer
dtroyer@gmail.com

On 10/31/2013 07:52 AM, Mark McLoughlin wrote:
> I could see us having two trademark programs "OpenStack Cloud" - where
> you know that the provider is running a "faithful implementation" of
> OpenStack code - and "OpenStack Compatible Cloud" - where you just know
> the provider is compatible with the interfaces.

Highlighting a risk with putting 'compatible cloud' first: I have the
feeling that the worst case scenario would be that this would accelerate
centrifugal push out of OpenStack code base and into 'improved' code
bases, but 'compatible at API level'. We may end up with having less
attractivity for the central pieces of OpenStack.

Not necessarily bad per se, just something to be aware of and manage.

/stef

--
Ask and answer questions on https://ask.openstack.org

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

I don't see compatible as being any easier for us to put in place than OpenStack. Both require us to make the same high level decision about which services need to be either run or implemented. The difference is in enforcement or assertion. I think we can do both.

As OpenStack, I do not think we need to go out of our way to enable people to not collaborate. We can stop it, and I think it's everyone's right to choose NIH and to do whatever, but it's not my job to help them or give them kudos when they do.

Ceph, BTW, I think is a great counter example. They existed first, but went and added integration. That's an example of a positive and helpful alternate impl... But honestly, it's such an exception I think we can all directly make the actual judgement call when we see it.

Stefano Maffulli <stefano@openstack.org> wrote:

>On 10/31/2013 07:52 AM, Mark McLoughlin wrote:
>> I could see us having two trademark programs "OpenStack Cloud" - where
>> you know that the provider is running a "faithful implementation" of
>> OpenStack code - and "OpenStack Compatible Cloud" - where you just know
>> the provider is compatible with the interfaces.
>
>Highlighting a risk with putting 'compatible cloud' first: I have the
>feeling that the worst case scenario would be that this would accelerate
>centrifugal push out of OpenStack code base and into 'improved' code
>bases, but 'compatible at API level'. We may end up with having less
>attractivity for the central pieces of OpenStack.
>
>Not necessarily bad per se, just something to be aware of and manage.
>
>/stef
>
>--
>Ask and answer questions on https://ask.openstack.org
>
>_______________________________________________
>Foundation mailing list
>Foundation@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Yes, learning from the past. And yes open web. However, note that the numbers of players and scale of early stage business attention is quite different.

Also, this is the second time you've suggested that you think OpenStack thinks it's too special and could learn more from its predecessors. I think that you're potentially missing the fact that OpenStack is largely descended from Ubuntu and MySQL in it's structure and approach and has taken many lessons to heart. But it's also important to forge the ground in front of us now, and not get blinded by the battles of 20 years ago, both good and bad.

New times call for new choices sometimes. Apache created a new license back when, ignoring the existing ones. We're using it, learning. But, we're also forging ahead where it makes sense.

So far, I think we're doing pretty well.

Jim Jagielski <jimjag@gmail.com> wrote:

>
>
>
>
>On Thu, Oct 31, 2013 at 10:41 AM, Monty Taylor <mordred@inaugust.com> wrote:
>
>If OpenStack all of a sudden became a
>
>set of interfaces, then the goal of an Open cloud would, I'm pretty
>certain, become lost.
>
>
>It really depends on the strength of the community around those "interfaces"...
>
>
>I use the term interface, in this context at least, very loosely. Think of it more as the set or protocols and standards. In this meaning, having a default, FOSS implementation, managed by a neutral entity with a real strong community behind it is *crucial*.
>
>
>Not to reference Apache httpd again, but the concerns and issues regarding an "Open Cloud" is not so much different than the "old" days of an "Open Web". During those times, there was *significant* incentive for externals to drive the web, to create their own "version" of the web. AOL tried it, and it was the availability of Apache, as well as the huge amount of community around Apache and its status as a reference implementation that allowed us back then to stop AOL's efforts in their tracks. You can find similar parallels in other areas as well.
>
>
>Let's not think that OpenStack is sooooo unique that it has nothing that can be learned by others who came before. Isn't that what true Open Source is about?
>

I think there are more examples than ceph. From my memory, HP adapted their message queue implementation to be compatible with Marconi.

It would seem that where people do use the code (maybe they were out first), they should be rewarded for being compatible with the API.

BTW, it's going to be a squeeze on Monday at the board to get this into 1h30

Tim

On 31 Oct 2013, at 17:57, Monty Taylor <mordred@inaugust.com>
wrote:

> I don't see compatible as being any easier for us to put in place than OpenStack. Both require us to make the same high level decision about which services need to be either run or implemented. The difference is in enforcement or assertion. I think we can do both.
>
> As OpenStack, I do not think we need to go out of our way to enable people to not collaborate. We can stop it, and I think it's everyone's right to choose NIH and to do whatever, but it's not my job to help them or give them kudos when they do.
>
> Ceph, BTW, I think is a great counter example. They existed first, but went and added integration. That's an example of a positive and helpful alternate impl... But honestly, it's such an exception I think we can all directly make the actual judgement call when we see it.
>
> Stefano Maffulli <stefano@openstack.org> wrote:
>
>> On 10/31/2013 07:52 AM, Mark McLoughlin wrote:
>>> I could see us having two trademark programs "OpenStack Cloud" - where
>>> you know that the provider is running a "faithful implementation" of
>>> OpenStack code - and "OpenStack Compatible Cloud" - where you just know
>>> the provider is compatible with the interfaces.
>>
>> Highlighting a risk with putting 'compatible cloud' first: I have the
>> feeling that the worst case scenario would be that this would accelerate
>> centrifugal push out of OpenStack code base and into 'improved' code
>> bases, but 'compatible at API level'. We may end up with having less
>> attractivity for the central pieces of OpenStack.
>>
>> Not necessarily bad per se, just something to be aware of and manage.
>>
>> /stef
>>
>> --
>> Ask and answer questions on https://ask.openstack.org
>>
>> _______________________________________________
>> Foundation mailing list
>> Foundation@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, Oct 31, 2013 at 1:09 PM, Monty Taylor <mordred@inaugust.com> wrote:

> Yes, learning from the past. And yes open web. However, note that the
> numbers of players and scale of early stage business attention is quite
> different.
>

The numbers are yes, but the situation is not. And even the number are not
all that different, if one looks at the relative scale instead of absolute
numbers.

>
> Also, this is the second time you've suggested that you think OpenStack
> thinks it's too special and could learn more from its predecessors. I think
> that you're potentially missing the fact that OpenStack is largely
> descended from Ubuntu and MySQL in it's structure and approach and has
> taken many lessons to heart. But it's also important to forge the ground in
> front of us now, and not get blinded by the battles of 20 years ago, both
> good and bad.
>

Hubris is the enemy of progress. No one is suggesting being "blinded" by
battles, but rather instead *learning* from them.


>
> New times call for new choices sometimes. Apache created a new license
> back when, ignoring the existing ones. We're using it, learning. But, we're
> also forging ahead where it makes sense.
>

Ignoring? Hardly.

But that's just it... the times are "kinda" new, not completely new. Maybe
if you had been around back then you'd realize that. That's the value of
experience.


> So far, I think we're doing pretty well.


You are. I was just proposing that possibly listening to others might help
do better. The whole idea of collaboration is listening and learning from
people.

>
>
> Jim Jagielski <jimjag@gmail.com> wrote:
>
>
>
>
> On Thu, Oct 31, 2013 at 10:41 AM, Monty Taylor <mordred@inaugust.com>wrote:
>
>> If OpenStack all of a sudden became a
>> set of interfaces, then the goal of an Open cloud would, I'm pretty
>> certain, become lost.
>
>
> It really depends on the strength of the community around those
> "interfaces"...
>
> I use the term interface, in this context at least, very loosely. Think of
> it more as the set or protocols and standards. In this meaning, having a
> default, FOSS implementation, managed by a neutral entity with a real
> strong community behind it is *crucial*.
>
> Not to reference Apache httpd again, but the concerns and issues regarding
> an "Open Cloud" is not so much different than the "old" days of an "Open
> Web". During those times, there was *significant* incentive for externals
> to drive the web, to create their own "version" of the web. AOL tried it,
> and it was the availability of Apache, as well as the huge amount of
> community around Apache and its status as a reference implementation that
> allowed us back then to stop AOL's efforts in their tracks. You can find
> similar parallels in other areas as well.
>
> Let's not think that OpenStack is sooooo unique that it has nothing that
> can be learned by others who came before. Isn't that what true Open Source
> is about?
>

The OpenStack Mission is to:

To produce the ubiquitous OpenSource Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable.

IMHO the operative (action) word is "produce." This is why I agree with
Monty that it is critical that if we start somewhere, it should be with a
program based on people running the code, who have a vested interest in the
code's continual evolution and survival. If we take our eye of of that it
could invite fragmentation and dilution of any meaning for "what is
openstack".

That said, it seems to me that technically speaking, we might only need 1
set of tests that could feed the two distinct programs being described
("openstack cloud" and "compatible"). So there might be to two
(marketing/business/logo) *programs* with unique requirements other than
testing, but with one test suite.

Therefore, IMHO, the best place to start is with the development of the
test itself while continuing to discuss the ways in which the results might
be applied to two distinct (logo) *prorgrams*. Now I understand that you
cant develop a test in the absence of requirements such as which projects
to include, but we could probably come up with a sensible starting point
and add additional coverage over time (increasing test coverage not
necessarily implying that each must pass to qualify for a specific program).







On Thu, Oct 31, 2013 at 9:58 AM, Mark McLoughlin <markmc@redhat.com> wrote:

> On Thu, 2013-10-31 at 14:52 +0000, Mark McLoughlin wrote:
> > On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:
> > > There is a VERY specific and strong reason why this is not the
> approach,
> > > and that's because it disincentivies people from working on OpenStack
> > > itself. We already have the problem with Neutron where not enough
> > > companies are working on the core of neutron because they're all only
> > > working on their vendor plugins. If OpenStack all of a sudden became a
> > > set of interfaces, then the goal of an Open cloud would, I'm pretty
> > > certain, become lost.
> >
> > Rob talks about using having three tools - our culture, our velocity and
> > our trademark. The first two could be as effective at having people
> > choose to use OpenStack itself rather than a compatible implementation
> > of its interfaces.
> >
> > I could see us having two trademark programs "OpenStack Cloud" - where
> > you know that the provider is running a "faithful implementation" of
> > OpenStack code - and "OpenStack Compatible Cloud" - where you just know
> > the provider is compatible with the interfaces.
> >
> > I'd see having "OpenStack Compatible Cloud" as the first priority.
> >
> > If we can figure out how to build a sane "OpenStack Cloud" program in
> > short order, then awesome. But it shouldn't hold back the first program.
>
> Oh, and to be clear - if it did happen this way, I'd quite happily
> deprecate the "OpenStack Compatible Cloud" program once we have the
> "OpenStack Cloud" program in place.
>
> Or maybe there's only one program and the "use OpenStack code"
> requirement gets added in the future.
>
> So, I agree that it is not a long-term goal for OpenStack to be a
> standards organization encouraging multiple alternate implementations of
> its APIs.
>
> But we do need to get moving on encouraging interoperability between
> public clouds, even if that means making a short term tactical decision
> that we don't need to require they use OpenStack code for everything.
>
> Mark.
>
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>

On Thu, 2013-10-31 at 13:55 -0500, Mark Collier wrote:
> The OpenStack Mission is to:
>
> To produce the ubiquitous OpenSource Cloud Computing platform that
> will meet the needs of public and private clouds regardless of size,
> by being simple to implement and massively scalable.
>
> IMHO the operative (action) word is "produce." This is why I agree
> with Monty that it is critical that if we start somewhere, it should
> be with a program based on people running the code, who have a vested
> interest in the code's continual evolution and survival. If we take
> our eye of of that it could invite fragmentation and dilution of any
> meaning for "what is openstack".
>
>
> That said, it seems to me that technically speaking, we might only
> need 1 set of tests that could feed the two distinct programs being
> described ("openstack cloud" and "compatible"). So there might be to
> two (marketing/business/logo) *programs* with unique requirements
> other than testing, but with one test suite.
>
>
> Therefore, IMHO, the best place to start is with the development of
> the test itself while continuing to discuss the ways in which the
> results might be applied to two distinct (logo) *prorgrams*. Now I
> understand that you cant develop a test in the absence of requirements
> such as which projects to include, but we could probably come up with
> a sensible starting point and add additional coverage over time
> (increasing test coverage not necessarily implying that each must pass
> to qualify for a specific program).

Ok, I'd be totally cool with all that ... if I had any idea how we were
going to go about creating "a program based on people running the code".
I see a near bottomless pit of issues we'd need to work through before
putting that into place and I don't want to block making
interoperability progress on these issues.

Am I missing something? What's (roughly) your take on how such a program
would work?

To be clear, I mean - assuming we know what code should be required to
run - how do we express those requirements precisely and certify that
providers are meeting them?

Thanks,
Mark.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, 2013-10-31 at 10:57 -0600, Monty Taylor wrote:
> I don't see compatible as being any easier for us to put in place than
> OpenStack. Both require us to make the same high level decision about
> which services need to be either run or implemented. The difference is
> in enforcement or assertion. I think we can do both.

How would we express which code is required and how would providers
(self-)certify that they are running that code?

Do we require zero modifications to the required code? If modifications
are allowed, how do we express what level of modifications? Or do we
just make it a good faith "we haven't made any fundamental changes"
assertion?

Are providers required to just run the required code, or actually route
all user requests through that code? Are they allowed they put other
code between the user and the required code?

Or do we require providers to submit a report of what upstream code
they're running and we (a human, on behalf of the Foundation) makes a
judgement call based on guidelines as to whether this is a faithful
implementation? If we go this route - i.e. making it a question of a
judgement call - how do we make those judgement calls totally fair and
transparent? We certainly don't want accusations of us rejecting a
provider because we don't like them.

The "OpenStack compatible" thing *is* either - the self-certification
process is "run these tests, you must pass them all". Totally
unambiguous.

Mark.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

This is how it works now. You're required to run the code.

Thing is, this is about legal contracts. So enforcement is hazy. Essentially, if hp signs a trademark usage thing that says we have to run it, our own lawyers won't let us do different. I think the first step is to say "OpenStack requires you run the code" ... Then as violations are brought to our attention, we look in to it.

On a parallel tack, compatible is testable. I think it's also useful. An OpenStack could not be compatible based on config. You could be compatible with being an OpenStack.



Mark McLoughlin <markmc@redhat.com> wrote:

>On Thu, 2013-10-31 at 13:55 -0500, Mark Collier wrote:
>> The OpenStack Mission is to:
>>
>> To produce the ubiquitous OpenSource Cloud Computing platform that
>> will meet the needs of public and private clouds regardless of size,
>> by being simple to implement and massively scalable.
>>
>> IMHO the operative (action) word is "produce." This is why I agree
>> with Monty that it is critical that if we start somewhere, it should
>> be with a program based on people running the code, who have a vested
>> interest in the code's continual evolution and survival. If we take
>> our eye of of that it could invite fragmentation and dilution of any
>> meaning for "what is openstack".
>>
>>
>> That said, it seems to me that technically speaking, we might only
>> need 1 set of tests that could feed the two distinct programs being
>> described ("openstack cloud" and "compatible"). So there might be to
>> two (marketing/business/logo) *programs* with unique requirements
>> other than testing, but with one test suite.
>>
>>
>> Therefore, IMHO, the best place to start is with the development of
>> the test itself while continuing to discuss the ways in which the
>> results might be applied to two distinct (logo) *prorgrams*. Now I
>> understand that you cant develop a test in the absence of requirements
>> such as which projects to include, but we could probably come up with
>> a sensible starting point and add additional coverage over time
>> (increasing test coverage not necessarily implying that each must pass
>> to qualify for a specific program).
>
>Ok, I'd be totally cool with all that ... if I had any idea how we were
>going to go about creating "a program based on people running the code".
>I see a near bottomless pit of issues we'd need to work through before
>putting that into place and I don't want to block making
>interoperability progress on these issues.
>
>Am I missing something? What's (roughly) your take on how such a program
>would work?
>
>To be clear, I mean - assuming we know what code should be required to
>run - how do we express those requirements precisely and certify that
>providers are meeting them?
>
>Thanks,
>Mark.
>
>
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, 2013-10-31 at 17:24 -0400, Monty Taylor wrote:
> This is how it works now. You're required to run the code.
>
> Thing is, this is about legal contracts. So enforcement is hazy.
> Essentially, if hp signs a trademark usage thing that says we have to
> run it, our own lawyers won't let us do different. I think the first
> step is to say "OpenStack requires you run the code" ... Then as
> violations are brought to our attention, we look in to it.

You mean this?

https://www.openstack.org/brand/openstack-cloud/

We could just add "must pass API compatibility tests" to those technical
requirements.

We might also list some other projects which "must be included in their
entirety in the product".

Would you see any further refinement of the requirements?

If we thought we could go ahead with those requirements and open the
program to non-Platinum/Gold members, then great.

That allows us to get down to the real business of deciding which APIs
are required and considering changing the list of required projects.

Mark.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On 10/31/2013 05:22 PM, Mark McLoughlin wrote:
> On Thu, 2013-10-31 at 10:57 -0600, Monty Taylor wrote:
>> I don't see compatible as being any easier for us to put in place than
>> OpenStack. Both require us to make the same high level decision about
>> which services need to be either run or implemented. The difference is
>> in enforcement or assertion. I think we can do both.
>
> How would we express which code is required and how would providers
> (self-)certify that they are running that code?
>
> Do we require zero modifications to the required code? If modifications
> are allowed, how do we express what level of modifications? Or do we
> just make it a good faith "we haven't made any fundamental changes"
> assertion?
>
> Are providers required to just run the required code, or actually route
> all user requests through that code? Are they allowed they put other
> code between the user and the required code?
>
> Or do we require providers to submit a report of what upstream code
> they're running and we (a human, on behalf of the Foundation) makes a
> judgement call based on guidelines as to whether this is a faithful
> implementation? If we go this route - i.e. making it a question of a
> judgement call - how do we make those judgement calls totally fair and
> transparent? We certainly don't want accusations of us rejecting a
> provider because we don't like them.
>
> The "OpenStack compatible" thing *is* either - the self-certification
> process is "run these tests, you must pass them all". Totally
> unambiguous.

Legal agreements are ambiguous. It drives us tech folks BATTY. But
that's one of the reasons we have lawyers, because legal agreements are
ambiguous and require human judgement.

I think we start with what you mentioned earlier, a good faith statement
of "you have to run the code" - and not try to spell out specifics.
Smell tests are often fine here. Is Rackspace running keystone? No. We
all know that. Are Rackspace and HP running Cinder? Different story -
AIUI, they are running Cinder with custom plugins. Are they running
Nova? Yes. Absolutely. Do they carry local patches? Probably.

I don't think think this is the type of criteria that a gating test can
be developed for, or even a check list. I think it's simply a legal
agreement, that the company in question agrees that, in order to use the
mark "An OpenStack Cloud" or whatever, that they will actually run
OpenStack itself.

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On 10/31/2013 05:22 PM, Mark McLoughlin wrote:
> On Thu, 2013-10-31 at 10:57 -0600, Monty Taylor wrote:
>> I don't see compatible as being any easier for us to put in place than
>> OpenStack. Both require us to make the same high level decision about
>> which services need to be either run or implemented. The difference is
>> in enforcement or assertion. I think we can do both.
>
> How would we express which code is required and how would providers
> (self-)certify that they are running that code?
>
> Do we require zero modifications to the required code? If modifications
> are allowed, how do we express what level of modifications? Or do we
> just make it a good faith "we haven't made any fundamental changes"
> assertion?
>
> Are providers required to just run the required code, or actually route
> all user requests through that code? Are they allowed they put other
> code between the user and the required code?
>
> Or do we require providers to submit a report of what upstream code
> they're running and we (a human, on behalf of the Foundation) makes a
> judgement call based on guidelines as to whether this is a faithful
> implementation? If we go this route - i.e. making it a question of a
> judgement call - how do we make those judgement calls totally fair and
> transparent? We certainly don't want accusations of us rejecting a
> provider because we don't like them.
>
> The "OpenStack compatible" thing *is* either - the self-certification
> process is "run these tests, you must pass them all". Totally
> unambiguous.

As an example approach on self-certification, this is how OSDL/Linux
Foundation handled/handles Carrier Grade Linux. CGL was basically a
checklist, and you had to self register how you provided the features in
question. Those documents were then posted publicly -
http://www.linuxfoundation.org/collaborate/workgroups/cgl/registered-distributions

The theory being that what this really did was ensure disclosure, and
give enough information that customers could make their own decisions
about how required features were provided.

There was no judgement call made by the committee about whether the way
a group implemented a feature was "good enough" or not, but just an
assumption that disclosure at that level of detail would be enough sun
light to help convergence on it's own.

Doing something like this in OpenStack would be different, for sure. CGL
was really about piecing together functionality from the kernel, and
user space tooling, to ensure some common base characteristics. OSDL
didn't create this code. But it's at least a pretty concrete example of
what self-certification could look like, warts and all.

-Sean

--
Sean Dague
http://dague.net

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Yes that is the existing program with requirements regarding running code.
A couple of things to note:

1) It includes by reference the "Restricted Use Logo Guidelines" (see: *
http://www.openstack.org/brand/openstack-cloud/* ) which includes a
requirement that clouds pass a FITS test approved by the TC. So this is
already in the existing agreements. All that is needed is for the tests to
be written and TC approved. No new legal language is required AFAIK.

"As of January 1st, 2012, your product must pass any Faithful
Implementation Test Suite (FITS) defined by the Technical Committee that
will be made available on http://www.openstack.org/FITS , to verify that
you are implementing a sufficiently current and complete version of the
software (and exposing associated APIs) to ensure compatibility and
interoperability. Your product will be required to pass the current FITS
test on an annual basis, which will generally require you to be running
either of the latest two software releases."

2) Eligibility for the the current program requires companies to be either
a Start Up sponsor, an established company Sponsor, Gold Member, or
Platinum Member. (The sponsor categories were omitted from your list).
This requirement could certainly be debated, but it does help when
approaching the problem via legal agreements (as opposed to software tests)
if there is a relationship with the companies in question. It also helps
fund the defense of the trademark which the company is looking to leverage
in their commercial offering.

So I would say that we actually have the framework we need. As Monty
pointed out, the "using code" is not something we necessarily need to
devise technical tests for. It is a term in an agreement which, while not
perfect, is a reasonable path for achieviing this particular goal IMHO.
That it exists in the current agreements is even better.

Mark





On Thu, Oct 31, 2013 at 4:53 PM, Mark McLoughlin <markmc@redhat.com> wrote:

> On Thu, 2013-10-31 at 17:24 -0400, Monty Taylor wrote:
> > This is how it works now. You're required to run the code.
> >
> > Thing is, this is about legal contracts. So enforcement is hazy.
> > Essentially, if hp signs a trademark usage thing that says we have to
> > run it, our own lawyers won't let us do different. I think the first
> > step is to say "OpenStack requires you run the code" ... Then as
> > violations are brought to our attention, we look in to it.
>
> You mean this?
>
> https://www.openstack.org/brand/openstack-cloud/
>
> We could just add "must pass API compatibility tests" to those technical
> requirements.
>
> We might also list some other projects which "must be included in their
> entirety in the product".
>
> Would you see any further refinement of the requirements?
>
> If we thought we could go ahead with those requirements and open the
> program to non-Platinum/Gold members, then great.
>
> That allows us to get down to the real business of deciding which APIs
> are required and considering changing the list of required projects.
>
> Mark.
>
>