Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Fox, Kevin M]

Yeah, I think the really gray issue here is the dependency thing...

I think we would mostly agree that depending on a non free component for the 
actual
implementation is bad. So, the dependency through Cassandra on the Oracle JVM is
a problem.

But if you allow the argument that the plugins being semiclosed is ok because 
there just isnt
a fully open implementation yet for the plugins, you could make the same 
argument for
the database. Why not allow Cassandra now, since there isn't a non free 
implementation
of Cassandra yet?

It is a sticky problem. You could start putting in very carefully worded 
exceptions to allow the
one case but not the other, but would be ripe for abuse.

The other way to wrangle it would be continuing the discussion on what it would 
take to
make an acceptable enough open solution. Swift is close I think, but like you 
said, it doesn't have
geoip which may be needed to consider it a CDN. What features must a CDN have 
before its
considered a viable CDN?

Designate+Swift might be enough? What other gaps are there?

Thanks,
Kevin



From: Thierry Carrez [thie...@openstack.org]
Sent: Monday, February 22, 2016 9:08 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Back to the original thread: what does "no open core" mean in OpenStack
2016 ? I think working on that could help sway the Poppy decision one
way or another: my original clarification proposal ("It should have a
fully-functional, production-grade open source implementation") would
mean we would have to exclude Poppy, or make an exception that we can
back up.

Poppy really touches a grey area. Their intent is not malicious and they
mostly behave like an OpenStack project. There are a number of potential
issues like the Cassandra dependency (which depends on Oracle JDK), or
the lack of integration with Designate, but those could be fixed before
the final acceptance.

The central question is therefore, should Poppy not be included in the
"official OpenStack projects" list because it is only functional when
coupled with external, non-OpenStack proprietary services. I hear the
arguments of both sides and they are all valid. Yet we have to make a
decision.

Kevin suggested Poppy could support Swift as its open source backend. It
would just put things in a Swift container. That would make a poor CDN,
since AIUI Swift would only spread the data on globally distributed
clusters, not serve it from closest location. That means we would have
to drop the "fully-functional, production-grade" part of the "no open
core" clarification.

The "no open core" 2016 interpretation could also be moved to "It should
support a fully-functional, production-grade open source implementation
if one is available".

In both cases, the new wording would certainly open the door for real
"open core" services in OpenStack: things that *only* live in OpenStack
as an entry point for proprietary software or hardware. So I'm not sure
we want either of them.

Any other suggestion ?

Or maybe we should not try to clarify what "no open core" means in 2016,
and rely on TC members common sense to judge that ?

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Mon, Feb 22, 2016 at 11:08 AM, Thierry Carrez 
wrote:

> Back to the original thread: what does "no open core" mean in OpenStack
> 2016 ? I think working on that could help sway the Poppy decision one way
> or another: my original clarification proposal ("It should have a
> fully-functional, production-grade open source implementation") would mean
> we would have to exclude Poppy, or make an exception that we can back up.
>

I think "open core" still means basically what it did 5 years ago, in that
it is generally a single entity that is 'holding back' part of a
project/product from the "community release" for product purposes.

OpenStack's "no open core" rule was set with that in mind IIRC.  While
Poppy doesn't meet the above definition, and therefore I wouldn't call it
open core, it does share certain characteristics with open core projects in
that it is not production-ready without a commercial/proprietary service.

We as a community often take a strong stand that the tools we use to
produce OpenStack are Open Source whenever possible.  Sometimes, when that
is not possible, we simply do without rather than compromise that
philosophy.  See our lack of a video-conference capability (aside from the
arguable usefulness of it).  There simply is not a usable/scalable option
that fits our values.  Would we suddenly find one acceptable if we had an
open source API abstraction layer to multiple non-free services?

I think with that stance on the tools we use it seems a bit disingenuous to
declare that one of our deliverables is a project to enable just that sort
of service.  This does not strike me as consistent with the OpenStack
mission.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ian Cordasco]

-Original Message-
From: Mike Perez <thin...@gmail.com>
Reply: Mike Perez <thin...@gmail.com>
Date: February 22, 2016 at 11:51:39
To: Ian Cordasco <sigmaviru...@gmail.com>, OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

> On 02/22/2016 07:19 AM, Ian Cordasco wrote:
> > -Original Message-
> > From: Mike Perez  
> > Reply: OpenStack Development Mailing List (not for usage questions)  
> > Date: February 19, 2016 at 19:21:13
> > To: openstack-dev@lists.openstack.org  
> > Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
> >
> >> On 02/18/2016 09:05 PM, Cody A.W. Somerville wrote:
> >>> There is no implicit (or explicit) requirement for the tests to be a
> >>> full integration/end-to-end test. Mocks and/or unit tests would be
> >>> sufficient to satisfy "test-driven gate".
> >>
> >> While I do agree there is no requirement, I would not be satisfied with
> >> us giving up on having functional or integration tests from a project
> >> because of the available implementations. It's reasons like this that
> >> highlight Poppy being different from the rest of OpenStack.
> >
> > Would third-party integration CI not be satisfactory?
>  
> That would be fine, but are these commercial CDN solutions going to be
> interested in hosting them?

I don't know that for certain and I don't know if the Poppy team has gotten so 
far as asking them. I'd also be unsurprised if this resulted in a catch 22 of 
sorts where CDNs will only work on those if Poppy is OpenStack and we'd only be 
happy accepting Poppy if it had those third-party CI services.

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 02/22/2016 07:19 AM, Ian Cordasco wrote:

-Original Message-
From: Mike Perez <thin...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: February 19, 2016 at 19:21:13
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016


On 02/18/2016 09:05 PM, Cody A.W. Somerville wrote:

There is no implicit (or explicit) requirement for the tests to be a
full integration/end-to-end test. Mocks and/or unit tests would be
sufficient to satisfy "test-driven gate".


While I do agree there is no requirement, I would not be satisfied with
us giving up on having functional or integration tests from a project
because of the available implementations. It's reasons like this that
highlight Poppy being different from the rest of OpenStack.


Would third-party integration CI not be satisfactory?


That would be fine, but are these commercial CDN solutions going to be 
interested in hosting them?


--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thierry Carrez]

Back to the original thread: what does "no open core" mean in OpenStack 
2016 ? I think working on that could help sway the Poppy decision one 
way or another: my original clarification proposal ("It should have a 
fully-functional, production-grade open source implementation") would 
mean we would have to exclude Poppy, or make an exception that we can 
back up.


Poppy really touches a grey area. Their intent is not malicious and they 
mostly behave like an OpenStack project. There are a number of potential 
issues like the Cassandra dependency (which depends on Oracle JDK), or 
the lack of integration with Designate, but those could be fixed before 
the final acceptance.


The central question is therefore, should Poppy not be included in the 
"official OpenStack projects" list because it is only functional when 
coupled with external, non-OpenStack proprietary services. I hear the 
arguments of both sides and they are all valid. Yet we have to make a 
decision.


Kevin suggested Poppy could support Swift as its open source backend. It 
would just put things in a Swift container. That would make a poor CDN, 
since AIUI Swift would only spread the data on globally distributed 
clusters, not serve it from closest location. That means we would have 
to drop the "fully-functional, production-grade" part of the "no open 
core" clarification.


The "no open core" 2016 interpretation could also be moved to "It should 
support a fully-functional, production-grade open source implementation 
if one is available".


In both cases, the new wording would certainly open the door for real 
"open core" services in OpenStack: things that *only* live in OpenStack 
as an entry point for proprietary software or hardware. So I'm not sure 
we want either of them.


Any other suggestion ?

Or maybe we should not try to clarify what "no open core" means in 2016, 
and rely on TC members common sense to judge that ?


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ian Cordasco]

-Original Message-
From: Mike Perez <thin...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: February 19, 2016 at 19:21:13
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

> On 02/18/2016 09:05 PM, Cody A.W. Somerville wrote:
> > There is no implicit (or explicit) requirement for the tests to be a
> > full integration/end-to-end test. Mocks and/or unit tests would be
> > sufficient to satisfy "test-driven gate".
>  
> While I do agree there is no requirement, I would not be satisfied with
> us giving up on having functional or integration tests from a project
> because of the available implementations. It's reasons like this that
> highlight Poppy being different from the rest of OpenStack.

Would third-party integration CI not be satisfactory?

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 02/18/2016 09:05 PM, Cody A.W. Somerville wrote:

There is no implicit (or explicit) requirement for the tests to be a
full integration/end-to-end test. Mocks and/or unit tests would be
sufficient to satisfy "test-driven gate".


While I do agree there is no requirement, I would not be satisfied with 
us giving up on having functional or integration tests from a project 
because of the available implementations. It's reasons like this that 
highlight Poppy being different from the rest of OpenStack.


--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 02/17/2016 06:30 AM, Doug Hellmann wrote:

Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:

On 02/16/2016 11:30 AM, Doug Hellmann wrote:

So I think the project team is doing everything we've asked.  We
changed our policies around new projects to emphasize the social
aspects of projects, and community interactions. Telling a bunch
of folks that they "are not OpenStack" even though they follow those
policies is rather distressing.  I think we should be looking for
ways to say "yes" to new projects, rather than "no."


My disagreements with accepting Poppy has been around testing, so let me
reiterate what I've already said in this thread.

The governance currently states that under Open Development "The project
has core reviewers and adopts a test-driven gate in the OpenStack
infrastructure for changes" [1].

If we don't have a solution like OpenCDN, Poppy has to adopt a reference
implementation that is a commercial entity, and infra has to also be
dependent on it. I get Infra is already dependent on public cloud
donations, but if we start opening the door to allow projects to bring
in those commercial dependencies, that's not good.


Only Poppy's test suite would rely on that, though, right? And other
projects can choose whether to co-gate with Poppy or not. So I don't see
how this limitation has an effect on anyone other than the Poppy team.


I maybe reading the words to closely, so someone please correct me, but 
"adopts a test-driven gate in the OpenStack infrastructure for changes" 
seems to imply that it would be *in the OpenStack infrastructure*, which 
is exactly the problem I'm outlining here.


Read my earlier quote above about commercial dependencies in our 
infrastructure and that being bad.



--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Cody A.W. Somerville]

On Sat, Feb 6, 2016 at 2:14 AM, Cody A.W. Somerville <
cody.somervi...@gmail.com> wrote:
 

>
> I'd like to suggest we tightly scope this discussion and subsequent
> decision to Poppy exclusively. The reason for this is two fold. The first
> is so that a timely resolution and answer can be provided to the Poppy
> team. The second is that I think once we've answered the specific
> questions and concerns about Poppy (some of which I believe are novel in
> nature) we'll be in a better position to then inductively reason about the
> problem and derive the more generalized rule or principle that I think
> Thierry was hoping to establish.
>
> In that vein, I'll try to summarize the questions or concerns I've seen
> raised here and in the TC meeting[3] - apologies if I've missed any:
>
> Poppy is an OpenStack project designed to make CDN services easier to
> consume with a generic vendor-neutral API[4]. The concern is that it only
> has support for commercial CDN service providers. It does not have support
> for a CDN service that is Open Source.
>
>  1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]?
>

I do not believe that Poppy meets the definition of "Open Core". By most
accounts, "Open Core" is a business or licensing model where there are
proprietary editions of a product built on top of a core open source
technology or project and/or project uses copyright assignment in order to
be able to dual license under non-open source licenses. Neither seem
applicable here.


>  2. Do we have a requirement that the primary component/backend (or at
> least one of the components/backends) driven/abstracted/orchestrated by a
> project (directly or via driver/plugin/et al) be considered Open Source? If
> yes, is there room for an exception when one simply doesn't exist? Is
> there special consideration for "services" (ie. think GPL vs. AGPL)?
>

There is clearly the preference, if not the requirement when such an
opportunity exists, but no one has expressed that this is a hard
requirement otherwise.


>  3. Does a project that only enables the use of commercial
> services/projects belong in OpenStack?
>

I think providing a standard abstraction for provisioning and managing
content distribution furthers our goal of being the ubiquitous open cloud
platform. I predict that content distribution will become an important and
very standard capability desired in large cloud deployments, particularly
in enterprise environments that span the globe, and so we'll likely see
such a service developed and probably be powered by swift. Due to the
nature of CDN, augmenting your content distribution capabilities with a
third-party CDN provider will be common and natural.


>  4. Does Poppy violate existing requirements around testing/CI[7][8]?
>

I do not believe that it does. Using mocks and/or unit tests would be
sufficient to meet "test-driven gate" requirement.


>  5. Does dependency on Casandra make Poppy non-free?
>

TBD.


>  6. Does a project that only enables the use of non-OpenStack
> services/projects belong in OpenStack?
>

The big tent model seems to explicitly encourage the idea that projects in
the OpenStack ecosystem are welcome to consider themselves OpenStack
projects. Poppy itself isn't just a consumer but is intended to be a
first-class cloud service.

Some additional facts that have been pointed out include:
>
>  - It currently only supports Akamai - which makes sense to be the first
> provider, Akamai is the CDN provider for Rackspace[9] and the project is
> mostly developed by Rackspace[10] - but implementation is underway for
> Fastly, Amazon CloudFront, and MaxCDN[11].
>  - It currently only supports Rackspace DNS but support for Designate is
> planned[11] (only a stub exists in tree currently).
>

I'm surprised these two points - particularly the latter, the fact that
Poppy currently only supports Rackspace DNS where Designate does exist and
could be integrated with - has not been raised by anyone else.

Cody
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Cody A.W. Somerville]

On Wed, Feb 17, 2016 at 1:20 PM, Jay Pipes  wrote:

> On 02/17/2016 09:30 AM, Doug Hellmann wrote:
>
>> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
>>
>>> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
>>>
 So I think the project team is doing everything we've asked.  We
 changed our policies around new projects to emphasize the social
 aspects of projects, and community interactions. Telling a bunch
 of folks that they "are not OpenStack" even though they follow those
 policies is rather distressing.  I think we should be looking for
 ways to say "yes" to new projects, rather than "no."

>>>
>>> My disagreements with accepting Poppy has been around testing, so let me
>>> reiterate what I've already said in this thread.
>>>
>>> The governance currently states that under Open Development "The project
>>> has core reviewers and adopts a test-driven gate in the OpenStack
>>> infrastructure for changes" [1].
>>>
>>> If we don't have a solution like OpenCDN, Poppy has to adopt a reference
>>> implementation that is a commercial entity, and infra has to also be
>>> dependent on it. I get Infra is already dependent on public cloud
>>> donations, but if we start opening the door to allow projects to bring
>>> in those commercial dependencies, that's not good.
>>>
>>
>> Only Poppy's test suite would rely on that, though, right? And other
>> projects can choose whether to co-gate with Poppy or not. So I don't see
>> how this limitation has an effect on anyone other than the Poppy team.
>>
>
> But what would really be tested in Poppy without any commercial CDN
> vendor? Nothing functional, right? I believe the fact that Poppy cannot be
> functionally tested in the OpenStack CI gate basically disqualifies it from
> being "in OpenStack".
>

There is no implicit (or explicit) requirement for the tests to be a full
integration/end-to-end test. Mocks and/or unit tests would be sufficient to
satisfy "test-driven gate".
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Fox, Kevin M]

It might be good to consider the scale that's needed too. For us, some of our 
clouds are on an internal network and its highly non desirable for an external 
cdn to be used. But to have the api work internally and scale out to at least 
the organization, so the same app templates can be used internally and 
externally. that would be very cool. So backing it by swift or something would 
be an interesting way to do it. It might not be very hard to implement that 
way, and would be useful to those that have private only clouds (probably a lot 
of folks). It wouldn't be a true CDN in the regular sense since it wouldn't be 
geographic. But, good enough. Would that be possible?

Thanks,
Kevin

From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Thursday, February 18, 2016 4:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 2016-02-18 17:20:35 -0600 (-0600), Ian Cordasco wrote:
[...]
> Presently, I think we need a F/OSS CDN but it isn't going to
> happen until the infrastructure for a CDN is something any
> OpenStack consumer would want to manage.
[...]

Probably an unusual use case and stretching the definition of CDN:
the Infra team has rolled their own by putting Apache on virtual
machines serving content from AFS for the purpose of hosting a
variety of content mirrors in each of the myriad OpenStack
providers/regions where it runs CI jobs. It may be that the
infrastructure for a CDN is in fact something that a lot of
multi-region/cross-provider applications would like to manage but
that their needs are sufficiently different so as to make a targeted
solution for one useless for another.

Ignorance on my part I'm sure, but I'd like to see a definition of
"content delivery network" that people can agree on before figuring
out what Poppy even is. I've browsed its documentation and it
doesn't seem to actually define this, so I get the impression that
its entire existence is defined and informed solely by other
proprietary application designs.
--
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jeremy Stanley]

On 2016-02-18 17:20:35 -0600 (-0600), Ian Cordasco wrote:
[...]
> Presently, I think we need a F/OSS CDN but it isn't going to
> happen until the infrastructure for a CDN is something any
> OpenStack consumer would want to manage.
[...]

Probably an unusual use case and stretching the definition of CDN:
the Infra team has rolled their own by putting Apache on virtual
machines serving content from AFS for the purpose of hosting a
variety of content mirrors in each of the myriad OpenStack
providers/regions where it runs CI jobs. It may be that the
infrastructure for a CDN is in fact something that a lot of
multi-region/cross-provider applications would like to manage but
that their needs are sufficiently different so as to make a targeted
solution for one useless for another.

Ignorance on my part I'm sure, but I'd like to see a definition of
"content delivery network" that people can agree on before figuring
out what Poppy even is. I've browsed its documentation and it
doesn't seem to actually define this, so I get the impression that
its entire existence is defined and informed solely by other
proprietary application designs.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ian Cordasco]

-Original Message-
From: Flavio Percoco <fla...@redhat.com>
Reply: Flavio Percoco <fla...@redhat.com>, OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>
Date: February 18, 2016 at 10:10:18
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

> On 16/02/16 19:17 +, Sean M. Collins wrote:
> >That is certainly a problem. However I think I would lean on Sean
> >Dague's argument about how Neutron had an open source solution that
> >needed a lot of TLC. The point being that at least they had 1 option.
> >Not zero options.
> >
> >And Dean's point about gce and aws API translation into OpenStack
> >Compute is also very relevant. We have precedence for doing API
> >translation layers that take some foreign API and translate it into
> >"openstackanese"
> >
> >I think Poppy would have a lot easier time getting into OpenStack were
> >it to take the steps to build a back-end that would do the required
> >operations to create a CDN - using a multi-region OpenStack cloud. Or
> >even adopting an open source CDN. Something! Anything really!
> >
> >Yes, it's a lot of work, but without that, as I think others have
> >stated - where's the OpenStack part?
>  
> That's not Poppy's business, fwiw. We can't ask a provisioning project to also
> be in the business of providing a data API. As others have mentioned, it's 
> just
> unfortunate that there's no open source solution for CDNs. TBH, I'd rather 
> have
> Poppy not running functional tests (because this is basically what this
> discussion is coming down to) than having the team working on a
> half-implemented, kinda CDN hack just to make the CI happy.
>  
> If someone wants to work on a CDN service, fine. That sounds awesome but let's
> not push the Poppy team down that road. They have a clear goal and mission.
> OpenStack's requirements are a bit too narrow for them.
>  
> That said, as Monty mentioned in the TC meeting, deploying CDN's is not
> necessary something a cloud wants to do. Providing a service that provisions
> CDN's is more likely to be used by a cloud provider.

I've been sitting on the fence for a while now in this discussion but I'd have 
to say that this point of view has swayed me towards being in favor of 
including Poppy in OpenStack.

I understand the arguments against this, but I think in spite of the weak 
similarities being drawn with other projects (e.g., Cinder having F/OSS 
drivers) I think we have to also recognize a difference in the problem domains. 
Presently, I think we need a F/OSS CDN but it isn't going to happen until the 
infrastructure for a CDN is something any OpenStack consumer would want to 
manage.

If anything, a consumer of OpenStack would probably like the freedom that poppy 
will provide in being able to swap out existing CDN providers while consuming 
the same API.

But that's just my two cents as a non-TC community member.
--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 16/02/16 19:17 +, Sean M. Collins wrote:

Doug Hellmann wrote:

Is there? I thought the point was OpenCDN isn't actually usable. Maybe
someone from the Poppy team can provide more details about that.


That is certainly a problem. However I think I would lean on Sean
Dague's argument about how Neutron had an open source solution that
needed a lot of TLC. The point being that at least they had 1 option.
Not zero options.

And Dean's point about gce and aws API translation into OpenStack
Compute is also very relevant. We have precedence for doing API
translation layers that take some foreign API and translate it into
"openstackanese"

I think Poppy would have a lot easier time getting into OpenStack were
it to take the steps to build a back-end that would do the required
operations to create a CDN - using a multi-region OpenStack cloud. Or
even adopting an open source CDN. Something! Anything really!

Yes, it's a lot of work, but without that, as I think others have
stated - where's the OpenStack part?



That's not Poppy's business, fwiw. We can't ask a provisioning project to also
be in the business of providing a data API. As others have mentioned, it's just
unfortunate that there's no open source solution for CDNs. TBH, I'd rather have
Poppy not running functional tests (because this is basically what this
discussion is coming down to) than having the team working on a
half-implemented, kinda CDN hack just to make the CI happy.

If someone wants to work on a CDN service, fine. That sounds awesome but let's
not push the Poppy team down that road. They have a clear goal and mission.
OpenStack's requirements are a bit too narrow for them.

That said, as Monty mentioned in the TC meeting, deploying CDN's is not
necessary something a cloud wants to do. Providing a service that provisions
CDN's is more likely to be used by a cloud provider.

Cheers,
Flavio



Like that Wendy's commercial from way back: "Where's the beef?"

--
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Fox, Kevin M]

You should be able to test that the functionality of using the api, and seeing 
an appropriate plugin call gets called without a proprietary back end. Then its 
up to each plugin to test for their own compliance to the reference.

Another approach for testing, maybe you could create the "dead simple cdn" that 
basically just uploads stuff to the local swift? Its not much of a cdn, but you 
may not need more then that. For my cloud, that amount of "cdn" would be enough 
in a lot of cases.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, February 17, 2016 10:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 09:30 AM, Doug Hellmann wrote:
> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
>> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
>>> So I think the project team is doing everything we've asked.  We
>>> changed our policies around new projects to emphasize the social
>>> aspects of projects, and community interactions. Telling a bunch
>>> of folks that they "are not OpenStack" even though they follow those
>>> policies is rather distressing.  I think we should be looking for
>>> ways to say "yes" to new projects, rather than "no."
>>
>> My disagreements with accepting Poppy has been around testing, so let me
>> reiterate what I've already said in this thread.
>>
>> The governance currently states that under Open Development "The project
>> has core reviewers and adopts a test-driven gate in the OpenStack
>> infrastructure for changes" [1].
>>
>> If we don't have a solution like OpenCDN, Poppy has to adopt a reference
>> implementation that is a commercial entity, and infra has to also be
>> dependent on it. I get Infra is already dependent on public cloud
>> donations, but if we start opening the door to allow projects to bring
>> in those commercial dependencies, that's not good.
>
> Only Poppy's test suite would rely on that, though, right? And other
> projects can choose whether to co-gate with Poppy or not. So I don't see
> how this limitation has an effect on anyone other than the Poppy team.

But what would really be tested in Poppy without any commercial CDN
vendor? Nothing functional, right? I believe the fact that Poppy cannot
be functionally tested in the OpenStack CI gate basically disqualifies
it from being "in OpenStack".

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Anne Gentle's message of 2016-02-17 12:28:42 -0600:
> On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes  wrote:
> 
> > On 02/17/2016 09:30 AM, Doug Hellmann wrote:
> >
> >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
> >>
> >>> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
> >>>
>  So I think the project team is doing everything we've asked.  We
>  changed our policies around new projects to emphasize the social
>  aspects of projects, and community interactions. Telling a bunch
>  of folks that they "are not OpenStack" even though they follow those
>  policies is rather distressing.  I think we should be looking for
>  ways to say "yes" to new projects, rather than "no."
> 
> >>>
> >>> My disagreements with accepting Poppy has been around testing, so let me
> >>> reiterate what I've already said in this thread.
> >>>
> >>> The governance currently states that under Open Development "The project
> >>> has core reviewers and adopts a test-driven gate in the OpenStack
> >>> infrastructure for changes" [1].
> >>>
> >>> If we don't have a solution like OpenCDN, Poppy has to adopt a reference
> >>> implementation that is a commercial entity, and infra has to also be
> >>> dependent on it. I get Infra is already dependent on public cloud
> >>> donations, but if we start opening the door to allow projects to bring
> >>> in those commercial dependencies, that's not good.
> >>>
> >>
> >> Only Poppy's test suite would rely on that, though, right? And other
> >> projects can choose whether to co-gate with Poppy or not. So I don't see
> >> how this limitation has an effect on anyone other than the Poppy team.
> >>
> >
> > But what would really be tested in Poppy without any commercial CDN
> > vendor? Nothing functional, right? I believe the fact that Poppy cannot be
> > functionally tested in the OpenStack CI gate basically disqualifies it from
> > being "in OpenStack".
> >
> 
> I do want end-users to have CDN, I do. And I'm a pragmatist as well so the
> "open core" arguments aren't as important to me.
> 
> That said, for me, since poppy itself doesn't offer/run/maintain the
> service but instead simply offers an API on top of CDN provider's APIs, I
> don't think it's necessary to govern it in OpenStack.

Most of our successful services do the same thing. They abstract
another service, but don't replicate it's features in their code
base. Nova isn't a hypervisor. Cinder isn't a block device. Trove
isn't a database.  Neutron isn't an SDN.

The *only* difference is that because of the nature of a CDN, running
one yourself isn't practical and so there's no significant (or
viable) open source implementation.

Doug

> 
> Thanks,
> Anne
> 
> >
> > Best,
> > -jay
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Anne Gentle]

On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes  wrote:

> On 02/17/2016 09:30 AM, Doug Hellmann wrote:
>
>> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
>>
>>> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
>>>
 So I think the project team is doing everything we've asked.  We
 changed our policies around new projects to emphasize the social
 aspects of projects, and community interactions. Telling a bunch
 of folks that they "are not OpenStack" even though they follow those
 policies is rather distressing.  I think we should be looking for
 ways to say "yes" to new projects, rather than "no."

>>>
>>> My disagreements with accepting Poppy has been around testing, so let me
>>> reiterate what I've already said in this thread.
>>>
>>> The governance currently states that under Open Development "The project
>>> has core reviewers and adopts a test-driven gate in the OpenStack
>>> infrastructure for changes" [1].
>>>
>>> If we don't have a solution like OpenCDN, Poppy has to adopt a reference
>>> implementation that is a commercial entity, and infra has to also be
>>> dependent on it. I get Infra is already dependent on public cloud
>>> donations, but if we start opening the door to allow projects to bring
>>> in those commercial dependencies, that's not good.
>>>
>>
>> Only Poppy's test suite would rely on that, though, right? And other
>> projects can choose whether to co-gate with Poppy or not. So I don't see
>> how this limitation has an effect on anyone other than the Poppy team.
>>
>
> But what would really be tested in Poppy without any commercial CDN
> vendor? Nothing functional, right? I believe the fact that Poppy cannot be
> functionally tested in the OpenStack CI gate basically disqualifies it from
> being "in OpenStack".
>

I do want end-users to have CDN, I do. And I'm a pragmatist as well so the
"open core" arguments aren't as important to me.

That said, for me, since poppy itself doesn't offer/run/maintain the
service but instead simply offers an API on top of CDN provider's APIs, I
don't think it's necessary to govern it in OpenStack.

Thanks,
Anne


>
> Best,
> -jay
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jay Pipes]

On 02/17/2016 09:30 AM, Doug Hellmann wrote:

Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:

On 02/16/2016 11:30 AM, Doug Hellmann wrote:

So I think the project team is doing everything we've asked.  We
changed our policies around new projects to emphasize the social
aspects of projects, and community interactions. Telling a bunch
of folks that they "are not OpenStack" even though they follow those
policies is rather distressing.  I think we should be looking for
ways to say "yes" to new projects, rather than "no."


My disagreements with accepting Poppy has been around testing, so let me
reiterate what I've already said in this thread.

The governance currently states that under Open Development "The project
has core reviewers and adopts a test-driven gate in the OpenStack
infrastructure for changes" [1].

If we don't have a solution like OpenCDN, Poppy has to adopt a reference
implementation that is a commercial entity, and infra has to also be
dependent on it. I get Infra is already dependent on public cloud
donations, but if we start opening the door to allow projects to bring
in those commercial dependencies, that's not good.


Only Poppy's test suite would rely on that, though, right? And other
projects can choose whether to co-gate with Poppy or not. So I don't see
how this limitation has an effect on anyone other than the Poppy team.


But what would really be tested in Poppy without any commercial CDN 
vendor? Nothing functional, right? I believe the fact that Poppy cannot 
be functionally tested in the OpenStack CI gate basically disqualifies 
it from being "in OpenStack".


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/17/2016 03:10 AM, Sean M. Collins wrote:
> Thomas Goirand wrote:
>> s/I dislike/is not free software/ [*]
>>
>> It's not a mater of taste. Having Poppy requiring a non-free component,
>> even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it
>> non-free.
> 
> Your definition of non-free versus free, if I am not mistaken, is
> based on GPLv3. OpenStack is not GPL licensed

This has nothing to do with the GPL license.
Where did you get this from?
IMO, you really are, mistaking.

> I understand and respect the point of view of the Debian project on
> this, however OpenStack is an Apache licensed project. So, this is
> entirely your bikeshed.
> 
>> Ensuring we really only accept free software is not a bikeshed color
>> discussion, it is really important. And that's the same topic as using
>> non-free CDN solution (see below).
> 
> It is a bikeshed, because you are injecting a debate over the freedoms of
> Apache license vs. GPLv3 into this discussion.

I have no idea where this comes from.

> Which you do, on many
> occasions. I respect this, but at some point it does hijack the original
> intent of the thread. Which is now happening.

I have *never* discussed Apache vs GPLv3, neither in this list or
elsewhere. So I really don't understand why you're writing this.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800:
> On 02/16/2016 11:30 AM, Doug Hellmann wrote:
> > So I think the project team is doing everything we've asked.  We
> > changed our policies around new projects to emphasize the social
> > aspects of projects, and community interactions. Telling a bunch
> > of folks that they "are not OpenStack" even though they follow those
> > policies is rather distressing.  I think we should be looking for
> > ways to say "yes" to new projects, rather than "no."
> 
> My disagreements with accepting Poppy has been around testing, so let me
> reiterate what I've already said in this thread.
> 
> The governance currently states that under Open Development "The project 
> has core reviewers and adopts a test-driven gate in the OpenStack 
> infrastructure for changes" [1].
> 
> If we don't have a solution like OpenCDN, Poppy has to adopt a reference
> implementation that is a commercial entity, and infra has to also be 
> dependent on it. I get Infra is already dependent on public cloud 
> donations, but if we start opening the door to allow projects to bring 
> in those commercial dependencies, that's not good.

Only Poppy's test suite would rely on that, though, right? And other
projects can choose whether to co-gate with Poppy or not. So I don't see
how this limitation has an effect on anyone other than the Poppy team.

Doug

> 
> [1] - 
> http://governance.openstack.org/reference/new-projects-requirements.html
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Stefano Maffulli]

On 02/05/2016 07:17 PM, Doug Hellmann wrote:
> So, is Poppy "open core"?

I think it's a simple answer: no, Poppy is not open core.

Poppy is not open core... Is Linux Open Core because you have to buy a
processor and ram to run it?

Or is Firefox open core because I have to buy service from a bank before
I can use an online banking system?

A better question to ask is whether it fits in OpenStack given that
Poppy's open source code can only be tested by the community if the
community buys some/all those CDNs.

/stef

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 02/16/2016 11:30 AM, Doug Hellmann wrote:

So I think the project team is doing everything we've asked.  We
changed our policies around new projects to emphasize the social
aspects of projects, and community interactions. Telling a bunch
of folks that they "are not OpenStack" even though they follow those
policies is rather distressing.  I think we should be looking for
ways to say "yes" to new projects, rather than "no."


My disagreements with accepting Poppy has been around testing, so let me
reiterate what I've already said in this thread.

The governance currently states that under Open Development "The project 
has core reviewers and adopts a test-driven gate in the OpenStack 
infrastructure for changes" [1].


If we don't have a solution like OpenCDN, Poppy has to adopt a reference
implementation that is a commercial entity, and infra has to also be 
dependent on it. I get Infra is already dependent on public cloud 
donations, but if we start opening the door to allow projects to bring 
in those commercial dependencies, that's not good.


[1] - 
http://governance.openstack.org/reference/new-projects-requirements.html


--
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Edward Leafe's message of 2016-02-16 13:46:50 -0600:
> On Feb 16, 2016, at 1:30 PM, Doug Hellmann  wrote:
> 
> > So I think the project team is doing everything we've asked.  We
> > changed our policies around new projects to emphasize the social
> > aspects of projects, and community interactions. Telling a bunch
> > of folks that they "are not OpenStack" even though they follow those
> > policies is rather distressing.  I think we should be looking for
> > ways to say "yes" to new projects, rather than "no."
> 
> So if some group creates a 100% open project, and follows all of the Opens, 
> at what point do we consider relevance to OpenStack itself? How about a 100% 
> open text editor? Can we add that, since after all OpenStack code is written 
> with text editors.

We do have a relevance clause. Whether or not Poppy is relevant wasn't
part of the discussion, up to this point.

> 
> CDNs are not part of OpenStack, even if some parts of some projects may use 
> one from time to time. A common interface to CDNs seems to address a problem 
> that is not really part of what OpenStack does.

Can you explain why? Because I see cloud deployments with CDN APIs,
and I think that makes it relevant to clouds. I also see it as
relevant to deployers of OpenStack who want to support interoperable
APIs while still retaining a choice about what backend they implement,
which is exactly what the other OpenStack services do with their
drivers.

> 
> It's great to want to include people, but I think that there is more to it 
> than just whether their practices mirror ours.

OK. Are we changing what the argument related to Poppy is about, though,
to find a different reason to exclude them?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Edward Leafe]

On Feb 16, 2016, at 1:30 PM, Doug Hellmann  wrote:

> So I think the project team is doing everything we've asked.  We
> changed our policies around new projects to emphasize the social
> aspects of projects, and community interactions. Telling a bunch
> of folks that they "are not OpenStack" even though they follow those
> policies is rather distressing.  I think we should be looking for
> ways to say "yes" to new projects, rather than "no."

So if some group creates a 100% open project, and follows all of the Opens, at 
what point do we consider relevance to OpenStack itself? How about a 100% open 
text editor? Can we add that, since after all OpenStack code is written with 
text editors.

CDNs are not part of OpenStack, even if some parts of some projects may use one 
from time to time. A common interface to CDNs seems to address a problem that 
is not really part of what OpenStack does.

It's great to want to include people, but I think that there is more to it than 
just whether their practices mirror ours.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Fox, Kevin M]

Most of the "open core" issues we've run into time and time again were because 
one company had control of both an open and a closed edition and used their 
sole control to prevent features from entering the open edition because they 
wanted to make money off of it in the closed edition.

This most certainly does not apply to Poppy. They have both things that make an 
open source project truly open. an open license, and open governance. Its the 
latter thing that prevents vendor lockin. The irony is, Poppy wants to join 
OpenStack to cement that governance to prevent vendor control which which is 
being used to try and exclude it.

The nice thing about standardizing on Poppy would be it might lower the bar for 
a truly open CDN to be created because there might finally be visible enough 
demand for it. "My users want the api, and there isn't an open backend.. let me 
go write one"

The OpenSource world steps up with an implementation of something when it 
finally decides to scratch the itch. an open CDN has not been a significant 
enough itch to scratch so far.

An open api for CDN's on the other hand does seem like a useful thing to me, 
separate from an open CDN to back it. I'd greatly prefer to write apps against 
such a system instead of targeting the proprietary api's directly. It makes the 
open source code I write more open.

Yes, this is a sucky position to be in, but I think in this one case, its the 
lessor of two evils.

Thanks,
Kevin

From: Dean Troyer [dtro...@gmail.com]
Sent: Tuesday, February 16, 2016 10:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Tue, Feb 16, 2016 at 11:51 AM, Amit Gandhi 
<amit.gan...@rackspace.com<mailto:amit.gan...@rackspace.com>> wrote:
Poppy intends to be an abstraction API over the various CDNs available.  We do 
not want to be in the business of building a CDN itself.

Specific to the Poppy discussion, I think this is another point that makes 
Poppy not part of OpenStack: none of the services it wants to abstract are part 
of OpenStack.  I came up with another example of a project that takes the 
Compute API and translates it to gce or aws calls but we actually have this 
situation with the ESX hypervisor driver and multiple Cinder backends to 
commercial products.  But in those cases, the project is otherwise useful to an 
OpenStack deployment that does not include those products.

Now for the actual thread topic of open core and non-free backends.  We seem to 
be haggling over the declaration of one or more specific projects as 'open 
core-like', where the real discussion is in defining the general terms.  I have 
always thought of 'open core' in the Eucalyptus sense like what partially 
spurred the creation of Nova in the first place.  The same entity controlled 
both an 'open source' project and a commercial product based on it, where 
certain features/capabilities were only available in the non-free version.

What I think is important here is 'the same entity'.  This is where we need to 
be concerned, specifically with organizations that attempt to extract value 
from OpenStack yet hinder our advancement in return by holding back 
contributions.  And this may be the one place where the 'viral' nature of the 
GPL would have been useful to us in a business relationship. [[NO I do not 
intend to open that can'o'worms, only to illustrate our lack of that built-in 
mechanism to lessen the impact of open core]]

dt


--

Dean Troyer
dtro...@gmail.com<mailto:dtro...@gmail.com>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-02-16 12:57:58 -0600:
> On Tue, Feb 16, 2016 at 11:51 AM, Amit Gandhi 
> wrote:
> 
> > Poppy intends to be an abstraction API over the various CDNs available.
> > We do not want to be in the business of building a CDN itself.
> >
> 
> Specific to the Poppy discussion, I think this is another point that makes
> Poppy not part of OpenStack: none of the services it wants to abstract are
> part of OpenStack.  I came up with another example of a project that takes
> the Compute API and translates it to gce or aws calls but we actually have
> this situation with the ESX hypervisor driver and multiple Cinder backends
> to commercial products.  But in those cases, the project is otherwise
> useful to an OpenStack deployment that does not include those products.

I'm not sure why it should be abstracting anything that's already part
of OpenStack. That only makes sense for some types of projects, and
while "CDN-as-a-service" might be interesting that's not what the Poppy
team is building.

> Now for the actual thread topic of open core and non-free backends.  We
> seem to be haggling over the declaration of one or more specific projects
> as 'open core-like', where the real discussion is in defining the general
> terms.  I have always thought of 'open core' in the Eucalyptus sense like
> what partially spurred the creation of Nova in the first place.  The same
> entity controlled both an 'open source' project and a commercial product
> based on it, where certain features/capabilities were only available in the
> non-free version.

I brought up Poppy to illustrate the point that definitions that
seem clear in the abstract can be less clear in the concrete. All
of the Poppy code itself is open. There is no more advanced or more
complete version available elsewhere. Yes, it requires some other
service to run.  None of the service providers control the project,
which as you point out below is the source of concern with "open
core".

So I think the project team is doing everything we've asked.  We
changed our policies around new projects to emphasize the social
aspects of projects, and community interactions. Telling a bunch
of folks that they "are not OpenStack" even though they follow those
policies is rather distressing.  I think we should be looking for
ways to say "yes" to new projects, rather than "no."

Doug

> What I think is important here is 'the same entity'.  This is where we need
> to be concerned, specifically with organizations that attempt to extract
> value from OpenStack yet hinder our advancement in return by holding back
> contributions.  And this may be the one place where the 'viral' nature of
> the GPL would have been useful to us in a business relationship. [[NO I do
> not intend to open that can'o'worms, only to illustrate our lack of that
> built-in mechanism to lessen the impact of open core]]
> 
> dt
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean M. Collins]

Doug Hellmann wrote:
> Is there? I thought the point was OpenCDN isn't actually usable. Maybe
> someone from the Poppy team can provide more details about that.

That is certainly a problem. However I think I would lean on Sean
Dague's argument about how Neutron had an open source solution that
needed a lot of TLC. The point being that at least they had 1 option.
Not zero options.

And Dean's point about gce and aws API translation into OpenStack
Compute is also very relevant. We have precedence for doing API
translation layers that take some foreign API and translate it into
"openstackanese" 

I think Poppy would have a lot easier time getting into OpenStack were
it to take the steps to build a back-end that would do the required
operations to create a CDN - using a multi-region OpenStack cloud. Or
even adopting an open source CDN. Something! Anything really!

Yes, it's a lot of work, but without that, as I think others have
stated - where's the OpenStack part?

Like that Wendy's commercial from way back: "Where's the beef?"

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean M. Collins]

Thomas Goirand wrote:
> s/I dislike/is not free software/ [*]
> 
> It's not a mater of taste. Having Poppy requiring a non-free component,
> even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it
> non-free.

Your definition of non-free versus free, if I am not mistaken, is
based on GPLv3. OpenStack is not GPL licensed

I understand and respect the point of view of the Debian project on
this, however OpenStack is an Apache licensed project. So, this is
entirely your bikeshed.

> Ensuring we really only accept free software is not a bikeshed color
> discussion, it is really important. And that's the same topic as using
> non-free CDN solution (see below).

It is a bikeshed, because you are injecting a debate over the freedoms of
Apache license vs. GPLv3 into this discussion. Which you do, on many
occasions. I respect this, but at some point it does hijack the original
intent of the thread. Which is now happening.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Tue, Feb 16, 2016 at 11:51 AM, Amit Gandhi 
wrote:

> Poppy intends to be an abstraction API over the various CDNs available.
> We do not want to be in the business of building a CDN itself.
>

Specific to the Poppy discussion, I think this is another point that makes
Poppy not part of OpenStack: none of the services it wants to abstract are
part of OpenStack.  I came up with another example of a project that takes
the Compute API and translates it to gce or aws calls but we actually have
this situation with the ESX hypervisor driver and multiple Cinder backends
to commercial products.  But in those cases, the project is otherwise
useful to an OpenStack deployment that does not include those products.

Now for the actual thread topic of open core and non-free backends.  We
seem to be haggling over the declaration of one or more specific projects
as 'open core-like', where the real discussion is in defining the general
terms.  I have always thought of 'open core' in the Eucalyptus sense like
what partially spurred the creation of Nova in the first place.  The same
entity controlled both an 'open source' project and a commercial product
based on it, where certain features/capabilities were only available in the
non-free version.

What I think is important here is 'the same entity'.  This is where we need
to be concerned, specifically with organizations that attempt to extract
value from OpenStack yet hinder our advancement in return by holding back
contributions.  And this may be the one place where the 'viral' nature of
the GPL would have been useful to us in a business relationship. [[NO I do
not intend to open that can'o'worms, only to illustrate our lack of that
built-in mechanism to lessen the impact of open core]]

dt


-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Amit Gandhi]

OpenCDN is an abandoned project, although there have been a few attempts at 
creating one called “OpenCDN”.

As far as the we can tell (Poppy Team), there is currently no viable Open 
source CDN’s available.  If there is we would be happy to add it as a supported 
driver.

Also, even if the CDN software itself was open, the true value of a CDN comes 
from the distributed global network of servers it offers and its performance to 
serve requests.  Not just the features/API offered.

Poppy intends to be an abstraction API over the various CDNs available.  We do 
not want to be in the business of building a CDN itself.


Amit.



On Feb 16, 2016, at 12:22 PM, Doug Hellmann 
> wrote:

Excerpts from Sean M. Collins's message of 2016-02-16 07:15:34 +:
Thomas Goirand wrote:
Oh, that, and ... not using CassandraDB. And yes, this thread is a good
place to have this topic. I'm not sure who replied to me this thread
wasn't the place to discuss it: I respectfully disagree, since it's
another major blocker, IMO as important, if not more, as using a free
software CDN solution.

Let's handle the policy implications discussed in this thread before we
dive into the "don't use this component that I dislike" bikeshed.
Reading the thread, it appears that we've made good progress on building
consensus towards having Poppy consider an open source CDN as the
"reference implementation" (to use some Neutron parlance).

Then we can bikeshed about how good/bad the components used in the
reference implementation are. Later. The point being, there is an open
source solution that will be used to flesh out a true vendor-neutral API
(as I understand Mike Perez's position, and agree with!).

Is there? I thought the point was OpenCDN isn't actually usable. Maybe
someone from the Poppy team can provide more details about that.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/16/2016 03:15 PM, Sean M. Collins wrote:
> Thomas Goirand wrote:
>> Oh, that, and ... not using CassandraDB. And yes, this thread is a good
>> place to have this topic. I'm not sure who replied to me this thread
>> wasn't the place to discuss it: I respectfully disagree, since it's
>> another major blocker, IMO as important, if not more, as using a free
>> software CDN solution.
> 
> Let's handle the policy implications discussed in this thread before we
> dive into the "don't use this component that I dislike" bikeshed.

s/I dislike/is not free software/ [*]

It's not a mater of taste. Having Poppy requiring a non-free component,
even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it
non-free.

Ensuring we really only accept free software is not a bikeshed color
discussion, it is really important. And that's the same topic as using
non-free CDN solution (see below).

On 02/11/2016 08:03 PM, Flavio Percoco wrote:
> On 11/02/16 17:31 +0800, Thomas Goirand wrote:
>> I'm not sure who replied to me this thread
>> wasn't the place to discuss it: I respectfully disagree
>
> This thread is to talk about the *open core* issue.

Yeah, correct: open core. So we're discussing the freeness of software
we can accept. That's right on topic to me. Its dependencies, being
remote (ie: commercial CDNs) *OR* local (CassandraDB, and therefore the
Oracle JVM) are both non-free. And in fact, local dependencies which
someone would actually need to install on his computer, are even more
important than the remote ones.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Sean M. Collins's message of 2016-02-16 07:15:34 +:
> Thomas Goirand wrote:
> > Oh, that, and ... not using CassandraDB. And yes, this thread is a good
> > place to have this topic. I'm not sure who replied to me this thread
> > wasn't the place to discuss it: I respectfully disagree, since it's
> > another major blocker, IMO as important, if not more, as using a free
> > software CDN solution.
> 
> Let's handle the policy implications discussed in this thread before we
> dive into the "don't use this component that I dislike" bikeshed.
> Reading the thread, it appears that we've made good progress on building
> consensus towards having Poppy consider an open source CDN as the
> "reference implementation" (to use some Neutron parlance).
> 
> Then we can bikeshed about how good/bad the components used in the
> reference implementation are. Later. The point being, there is an open
> source solution that will be used to flesh out a true vendor-neutral API
> (as I understand Mike Perez's position, and agree with!).

Is there? I thought the point was OpenCDN isn't actually usable. Maybe
someone from the Poppy team can provide more details about that.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean M. Collins]

Thomas Goirand wrote:
> Oh, that, and ... not using CassandraDB. And yes, this thread is a good
> place to have this topic. I'm not sure who replied to me this thread
> wasn't the place to discuss it: I respectfully disagree, since it's
> another major blocker, IMO as important, if not more, as using a free
> software CDN solution.

Let's handle the policy implications discussed in this thread before we
dive into the "don't use this component that I dislike" bikeshed.
Reading the thread, it appears that we've made good progress on building
consensus towards having Poppy consider an open source CDN as the
"reference implementation" (to use some Neutron parlance).

Then we can bikeshed about how good/bad the components used in the
reference implementation are. Later. The point being, there is an open
source solution that will be used to flesh out a true vendor-neutral API
(as I understand Mike Perez's position, and agree with!).

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/08/2016 09:54 PM, Flavio Percoco wrote:
> Would our votes change if Poppy had support for OpenCDN (imagine it's being
> maintained) even if that solution is terrible?

Let's say it was doing that, and spawning instances containing OpenCDN
running on a multi-datacenter OpenStack deployment, then IMO it would be
a good candidate.

Oh, that, and ... not using CassandraDB. And yes, this thread is a good
place to have this topic. I'm not sure who replied to me this thread
wasn't the place to discuss it: I respectfully disagree, since it's
another major blocker, IMO as important, if not more, as using a free
software CDN solution.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 11/02/16 17:31 +0800, Thomas Goirand wrote:

On 02/08/2016 09:54 PM, Flavio Percoco wrote:

Would our votes change if Poppy had support for OpenCDN (imagine it's being
maintained) even if that solution is terrible?


Let's say it was doing that, and spawning instances containing OpenCDN
running on a multi-datacenter OpenStack deployment, then IMO it would be
a good candidate.



This might be an overkill for cloud admins and there'll be close to no clouds
running their own CDN.


Oh, that, and ... not using CassandraDB. And yes, this thread is a good
place to have this topic. I'm not sure who replied to me this thread
wasn't the place to discuss it: I respectfully disagree, since it's
another major blocker, IMO as important, if not more, as using a free
software CDN solution.


It was me and I disagree. This thread is to talk about the *open core* issue. In
fact, the first email didn't even call out Poppy to begin with. For all the
remaining issues there's a spec in the governance repo that can be used. Also,
this topic was discussed in the latest TC meeting.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2016-02-10 08:35:19 -0800:
> Chris Dent wrote:
> > [...]
> > Observing this thread and "the trouble with names"[1] one I get
> > concerned that we're trending in the direction of expecting
> > projects/servers/APIs to be done and perfect before they will ever
> > be OpenStack. This, of course, runs entirely contrary to the spirit
> > of open source where people release a solution to their itch and
> > people join with them to make it better.
> >
> > If we start thinking of projects as needing to have "production-grade"
> > implementations and APIs as needing to be stable and correct from
> > the start we're backing ourselves into corners that are very difficult
> > to get out of, distracting ourselves from the questions we ought to be
> > asking, and putting barriers in the way of doing new but necessary
> > stuff and evolving.
> 
> I certainly didn't intend to mean that projects need to have a final API 
> or perfect implementation before they can join the tent. I meant that 
> projects need to have a reference implementation using open source tools 
> that has a chance of being used in production one day. Imagine a project 
> which uses sqlite in testing but requires Oracle DB to achieve full 
> functionality or scaling beyond one user: the sqlite backend would be a 
> token open backend for testing purposes but real usage would need you to 
> buy into proprietary options. That would certainly be considered "open 
> core": a project that pretends to be open but requires proprietary 
> technology to be "really used".
> 
> Now it's not that clear cut and a lot of things fall in the grey area: 
> on one side you have proprietary backends that may offer better 
> performance -- at which point should we consider that "better 
> performance" means nobody would seriously use the open source backend ? 
> On the other side you have corner cases like Poppy where the 
> "proprietary service" it plugs into is difficult to replicate since it's 
> as much physical infrastructure than software.
> 

What you say above resonates with me Thierry, I think this is a gray area,
and I think we have a TC to provide well informed value judgments for
this gray area while we seek to bring the dark and light sides closer
together so there are fewer shades of gray to judge.

For what it's worth, I think Poppy is perhaps soundly in the very middle
of the gray area. There's nothing about it that smells like a poorly
behaved free rider grab for free development resources, nor does it feel
like a lock-in attempt. It legitimately feels like something that
enables OpenStack users to consume services that sit outside of OpenStack.

So, for me, the users are served by this project developing closely with
OpenStack, even if there's no viable free way to consume it. I think
Neutron tap danced through this gray area early on, and now has reached
a point where it is clearly in the light side of things, with _multiple_
free drivers that are completely viable. So, let's let Poppy tap dance,
and let's keep making sure our TC is well informed and makes thought
out decisions like this one, even if they are hard.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thierry Carrez]

Chris Dent wrote:

[...]
Observing this thread and "the trouble with names"[1] one I get
concerned that we're trending in the direction of expecting
projects/servers/APIs to be done and perfect before they will ever
be OpenStack. This, of course, runs entirely contrary to the spirit
of open source where people release a solution to their itch and
people join with them to make it better.

If we start thinking of projects as needing to have "production-grade"
implementations and APIs as needing to be stable and correct from
the start we're backing ourselves into corners that are very difficult
to get out of, distracting ourselves from the questions we ought to be
asking, and putting barriers in the way of doing new but necessary
stuff and evolving.


I certainly didn't intend to mean that projects need to have a final API 
or perfect implementation before they can join the tent. I meant that 
projects need to have a reference implementation using open source tools 
that has a chance of being used in production one day. Imagine a project 
which uses sqlite in testing but requires Oracle DB to achieve full 
functionality or scaling beyond one user: the sqlite backend would be a 
token open backend for testing purposes but real usage would need you to 
buy into proprietary options. That would certainly be considered "open 
core": a project that pretends to be open but requires proprietary 
technology to be "really used".


Now it's not that clear cut and a lot of things fall in the grey area: 
on one side you have proprietary backends that may offer better 
performance -- at which point should we consider that "better 
performance" means nobody would seriously use the open source backend ? 
On the other side you have corner cases like Poppy where the 
"proprietary service" it plugs into is difficult to replicate since it's 
as much physical infrastructure than software.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[gordon chung]

On 10/02/2016 11:35 AM, Thierry Carrez wrote:
> Chris Dent wrote:
>> [...]
>> Observing this thread and "the trouble with names"[1] one I get
>> concerned that we're trending in the direction of expecting
>> projects/servers/APIs to be done and perfect before they will ever
>> be OpenStack. This, of course, runs entirely contrary to the spirit
>> of open source where people release a solution to their itch and
>> people join with them to make it better.
>>
>> If we start thinking of projects as needing to have "production-grade"
>> implementations and APIs as needing to be stable and correct from
>> the start we're backing ourselves into corners that are very difficult
>> to get out of, distracting ourselves from the questions we ought to be
>> asking, and putting barriers in the way of doing new but necessary
>> stuff and evolving.
>
> I certainly didn't intend to mean that projects need to have a final API
> or perfect implementation before they can join the tent. I meant that
> projects need to have a reference implementation using open source tools
> that has a chance of being used in production one day. Imagine a project
> which uses sqlite in testing but requires Oracle DB to achieve full
> functionality or scaling beyond one user: the sqlite backend would be a
> token open backend for testing purposes but real usage would need you to
> buy into proprietary options. That would certainly be considered "open
> core": a project that pretends to be open but requires proprietary
> technology to be "really used".

apologies if this was asked somewhere else in thread, but should we try 
to define "production" scale or can we even? based on the last survey, 
the vast majority of deployments are under 100nodes[1]. that said, a few 
years ago, one company was dreaming 100,000 nodes.

i'd imagine the 50 node solution won't satisfy the 1000 node solution 
let alone the 10k node. similarly, the opposite direction will probably 
give an overkill solution. it seems somewhat difficult to define 
something against 'production' term unless we scope it somehow (e.g # of 
node ranges)?

[1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Tim Bell]

On 10/02/16 21:53, "gordon chung"  wrote:

>
>
>On 10/02/2016 11:35 AM, Thierry Carrez wrote:
>> Chris Dent wrote:
>>> [...]
>>> Observing this thread and "the trouble with names"[1] one I get
>>> concerned that we're trending in the direction of expecting
>>> projects/servers/APIs to be done and perfect before they will ever
>>> be OpenStack. This, of course, runs entirely contrary to the spirit
>>> of open source where people release a solution to their itch and
>>> people join with them to make it better.
>>>
>>> If we start thinking of projects as needing to have "production-grade"
>>> implementations and APIs as needing to be stable and correct from
>>> the start we're backing ourselves into corners that are very difficult
>>> to get out of, distracting ourselves from the questions we ought to be
>>> asking, and putting barriers in the way of doing new but necessary
>>> stuff and evolving.
>>
>> I certainly didn't intend to mean that projects need to have a final API
>> or perfect implementation before they can join the tent. I meant that
>> projects need to have a reference implementation using open source tools
>> that has a chance of being used in production one day. Imagine a project
>> which uses sqlite in testing but requires Oracle DB to achieve full
>> functionality or scaling beyond one user: the sqlite backend would be a
>> token open backend for testing purposes but real usage would need you to
>> buy into proprietary options. That would certainly be considered "open
>> core": a project that pretends to be open but requires proprietary
>> technology to be "really used".
>
>apologies if this was asked somewhere else in thread, but should we try 
>to define "production" scale or can we even? based on the last survey, 
>the vast majority of deployments are under 100nodes[1]. that said, a few 
>years ago, one company was dreaming 100,000 nodes.
>
>i'd imagine the 50 node solution won't satisfy the 1000 node solution 
>let alone the 10k node. similarly, the opposite direction will probably 
>give an overkill solution. it seems somewhat difficult to define 
>something against 'production' term unless we scope it somehow (e.g # of 
>node ranges)?
>
>[1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf


As always, scale is relative. However, projects have shown major difficulties 
to scale to 10% of the larger deployments. Scaling beyond that, even with 
commercial solutions, has required major investments in custom configurations 
by the deployers.

There are two risks I see

A. Use sqlite and then change to proprietary solution X for scale
B. Works at a small scale but scalability has not been considered as a design 
criteria or demonstrated

I think it is important that the community is informed on these constraints 
before feeling that a particular project is the solution for them and that the 
TC factors these questions into their approval criteria.

Tim


>
>-- 
>gord
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/05/2016 01:16 PM, Sean Dague wrote:

> Whether or not it is, I'm not sure how it is part of a Ubiquitous
> Open Source Cloud Platform. Because it only enables the use of
> commerical services.
> 
> It's fine that it's open source software. I just don't think it's
> OpenStack.

Agreed. I don't think that everything that may be useful to consumers
of OpenStack has to be part of OpenStack, either.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWu5jUAAoJEKMgtcocwZqLtqoP/3INidXySMluomwiJv6fZe9g
x4ycIuaVK5zJeNErE7zPHjUTr4xX+KRHdnjBNUf5Ufeig4A2GqXPikj32hR4MaYA
x2Hro60xgmq0vGRTbFNRg9BObuHnrpg+JQKuIBEk8K7TaXJBuINBFv92863IaBjQ
NdeG87b7/sv6E6onB1V4LML7WwRjNEwz90dbwoBqPGkPtbB7h4WR/XyWw+13gU5/
Dw74MguubvP7et4dGBA14SPnk6j6CJ4WAZQ87Ud2eqlgkaFMlXml1RbJc+Q+H4lI
kzOJycLQJJdb2kvCypFlGxYqyr8kAZyxVy9UUDom3TkEE3SVr5Hz5tUw9edh3FXy
OKWglQ2x9rJUQpKeUznmbtIWZTt0C5ANUu6mpvnAZKmd1qF2njRO9yCvHPWlJT7T
dlq3MzeTWVLvMhABevuyPxtha3LIRitoMvQEpIpYsbMqLAREBMT/KODW9WJ9beQE
5LAPNK1RmLFL/gqxYod8XKWYwjUAKt6cOyUjHAASsqlgunMNn+l4DOAvPd3HaOph
g+skabkbDuYBfLw9v8gmjfpK/QTKPapHiGVTVKu6lnN87srMm8ep2scobx+YTAII
am6OFcUebEgEmD7Bhl9y37TUO/AIBqU4IRplI3pGp5ABnV1/uTcwFIJgLGoBAh+d
3X1gbt9GpKvdqUn0V3DN
=G5RR
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/05/2016 01:27 PM, Mike Perez wrote:

>>> So while Poppy may not fully qualify for the open core label,
>>> it still fails some of the tests that we want to see, such as a
>>> usable open source implementation.

>> From a QA perspective in gate, if we have to rely on a commercial
>> solution
> (even if donated) to test it, then that's bad.

Wasn't that the exact argument regarding needing to be able to boot a
Linux image? We can't reasonably test it without getting into
payment/licensing issues.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWu5hWAAoJEKMgtcocwZqLofIQAK7aofIjWwcqQGvA9yz9lFsI
5T53e4CjDZOVoTQaTdH085DVlMpL6kOARAzPTohoL6dRo/h0fusp0lSqWtPaDQwk
VNnNKR0GvcyP8nGi6YYa6rVqJLiZPtovbsdnmgDnfI9WRJ76cXy+HlLmtCVZsAej
boE/8b9h+cUwGQH/S6hH3Pi63GzThNH4k0goNWSvzXqrqQ6ypKDM5As1SUnTUgkk
Bioe8TRS5Bdt8bpxUOVwiuGBskO0vdX4DUYtsO7uLvD1x/ZIxX9iPQKKK9/E1tjg
HpqiVjrOahsLzcAFhCzfqNYyYTG0W45w00DLdQstG25IaVSIQ7GnbsW2HSAwLBUP
AU9/gAtkARj0PK+MafjrRmGtllCfh60KJCNWUOHmrjChDhE/TyigCqSa/Xq1abLi
KykKx4vjLUuTAVCIBIfeUB0ZEPdqiamGRigKGocLjSV+HUR28A2mpQCMkBiw5w7s
UPtlWnm4SP5ox5dpUx537OmPbaeoEF701k7tftiPOe30g5kq9GB5qAxCg2kbjRnc
Jn7rwt7otxH39hZ8rLRO8DgA5AHj3GrH5QX6Zehpx2lJakq8E/wqPtvzyDA8Y2j0
hoLWXCL5cTmtGXK4BuJLs2JzzM/Pvabq7lf8JYEQthENHXhAXk+E1F1rq3Ld6A28
VMUrfCiH8tCNVyn/HOZc
=/gSw
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Fox, Kevin M]

There's two main types of services in openstack. Those that are a multitenant 
aware implementation of some kind of data plane protocol with an "openstack" 
api. Swift/radosgw, Zaqar, MagnetoDB, etc. I think we can ignore these in this 
discussion.

Then there's what I consider the more "Operating System" style OpenStack 
services. They are like the Linux Kernel Subsystems. They provide a standard 
API, and provide plugins to actually implement the guts of the requests. 
Abstracting out the request from how to get it done.

(A few services do both, Neutron for example is a pure pluggable api, but also 
provides a reference implementation driver that does an sdn.)

So, the question I think is really for those "Operating System" style services, 
is it alright to have a standard, opensource api with no current backing system 
that's free?

While not a pure direct comparison,lets look to the leading opensource 
operating system for guidance. So, are there any examples of a OS subsystem 
that has drivers that there are no purely open solutions to implementing the 
api. Just off the top of my head, I'd say the Infiniband subsystem. You can't 
use the api unless you buy hardware from someone and use the appropriate driver 
and proprietary firmware.

So there is precedent for it in the open source world. While being completely 
open is a great goal, I think there are rare cases where it makes sense to 
allow the abstraction and plugable drivers without a current open backend.

Poppy is a very interesting edge case. CDN's are useful to users mostly because 
they are about having the vast network of machines spread across the world that 
you can push content to. Its not the software users care about but the whole 
worldwide system made up of hardware, sysadmins, software, etc. You can almost 
think of it as a single piece of hardware provided by a vendor in this 
instance. I'm guessing at present, its unlikely that any reference 
implementation of an opensource piece of software would ever be that widely 
deployed. But as an optional API, it would be great if there was a single 
standard opensource api that was vendor neutral can be provided so that it 
doesn't just break down to each vendor providing their own proprietary api. The 
open/standard api is a much better thing for everyone. Most OS's accept this 
level of tradeoff.

Just my 2 cents.

Thanks,
Kevin

From: Ed Leafe [e...@leafe.com]
Sent: Wednesday, February 10, 2016 12:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/05/2016 01:16 PM, Sean Dague wrote:

> Whether or not it is, I'm not sure how it is part of a Ubiquitous
> Open Source Cloud Platform. Because it only enables the use of
> commerical services.
>
> It's fine that it's open source software. I just don't think it's
> OpenStack.

Agreed. I don't think that everything that may be useful to consumers
of OpenStack has to be part of OpenStack, either.

- --

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWu5jUAAoJEKMgtcocwZqLtqoP/3INidXySMluomwiJv6fZe9g
x4ycIuaVK5zJeNErE7zPHjUTr4xX+KRHdnjBNUf5Ufeig4A2GqXPikj32hR4MaYA
x2Hro60xgmq0vGRTbFNRg9BObuHnrpg+JQKuIBEk8K7TaXJBuINBFv92863IaBjQ
NdeG87b7/sv6E6onB1V4LML7WwRjNEwz90dbwoBqPGkPtbB7h4WR/XyWw+13gU5/
Dw74MguubvP7et4dGBA14SPnk6j6CJ4WAZQ87Ud2eqlgkaFMlXml1RbJc+Q+H4lI
kzOJycLQJJdb2kvCypFlGxYqyr8kAZyxVy9UUDom3TkEE3SVr5Hz5tUw9edh3FXy
OKWglQ2x9rJUQpKeUznmbtIWZTt0C5ANUu6mpvnAZKmd1qF2njRO9yCvHPWlJT7T
dlq3MzeTWVLvMhABevuyPxtha3LIRitoMvQEpIpYsbMqLAREBMT/KODW9WJ9beQE
5LAPNK1RmLFL/gqxYod8XKWYwjUAKt6cOyUjHAASsqlgunMNn+l4DOAvPd3HaOph
g+skabkbDuYBfLw9v8gmjfpK/QTKPapHiGVTVKu6lnN87srMm8ep2scobx+YTAII
am6OFcUebEgEmD7Bhl9y37TUO/AIBqU4IRplI3pGp5ABnV1/uTcwFIJgLGoBAh+d
3X1gbt9GpKvdqUn0V3DN
=G5RR
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Tim Bell]

On 11/02/16 00:33, "gordon chung"  wrote:

>
>
>On 10/02/2016 4:28 PM, Tim Bell wrote:
>>
>> On 10/02/16 21:53, "gordon chung"  wrote:
>>
>>> apologies if this was asked somewhere else in thread, but should we try
>>> to define "production" scale or can we even? based on the last survey,
>>> the vast majority of deployments are under 100nodes[1]. that said, a few
>>> years ago, one company was dreaming 100,000 nodes.
>>>
>>> i'd imagine the 50 node solution won't satisfy the 1000 node solution
>>> let alone the 10k node. similarly, the opposite direction will probably
>>> give an overkill solution. it seems somewhat difficult to define
>>> something against 'production' term unless we scope it somehow (e.g # of
>>> node ranges)?
>>>
>>> [1] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf
>>
>>
>> As always, scale is relative. However, projects have shown major 
>> difficulties to scale to 10% of the larger deployments. Scaling beyond that, 
>> even with commercial solutions, has required major investments in custom 
>> configurations by the deployers.
>>
>> There are two risks I see
>>
>> A. Use sqlite and then change to proprietary solution X for scale
>> B. Works at a small scale but scalability has not been considered as a 
>> design criteria or demonstrated
>>
>> I think it is important that the community is informed on these constraints 
>> before feeling that a particular project is the solution for them and that 
>> the TC factors these questions into their approval criteria.
>>
>
>is there a source for this? a place where people list their reference 
>architectures and deployment scales?
>
>i'm not a deployer but as an outsider, i've found that there isn't a lot 
>of transparency in regards to how projects have been made to scale. 
>maybe this is a side effect of OpenStack being hard as hell to use, but 
>it seems configurations are the secret sauce people use to sell so we 
>have a lot of failure stories (bottom-end constraints) in the community 
>rather than successes (upper-end constraints).
>
>are there a collection of fully transparent deployers out there to be 
>our 'production' baseline? to help vet scalability? just CERN?

The large deployment team 
(https://wiki.openstack.org/wiki/Large_Deployment_Team) meets regularly and 
presents architectures at the summits and ops mid cycle meetup ‘show’ 
sessions. I can remember presentations from Walmart, Paypal/eBay, Rackspace and 
Yahoo! recently. The LDT etherpads also contain a lot of information. This is 
then regularly put into the ops manual 
(http://docs.openstack.org/openstack-ops/content/architecture.html).

>
>-- 
>gord
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Chris Dent]

On Fri, 5 Feb 2016, Jim Meyer wrote:

On Feb 5, 2016, at 9:54 AM, Tim Bell  wrote:
The scale could be defined on the basis of the survey data. The
reference implementation should be able to address at least X% of
deployments. I can think of at least one project which was not
suitable for use at a reasonable size configuration and not being
able to demonstrate this would have saved a lot of grief in the ops
community as well as ensuring the project addressed the issue early.


+1 and I can think of more than one. =\


Observing this thread and "the trouble with names"[1] one I get
concerned that we're trending in the direction of expecting
projects/servers/APIs to be done and perfect before they will ever
be OpenStack. This, of course, runs entirely contrary to the spirit
of open source where people release a solution to their itch and
people join with them to make it better.

If we start thinking of projects as needing to have "production-grade"
implementations and APIs as needing to be stable and correct from
the start we're backing ourselves into corners that are very difficult
to get out of, distracting ourselves from the questions we ought to be
asking, and putting barriers in the way of doing new but necessary
stuff and evolving.

In the case of Poppy I think we should be asking questions which
can't be answered with heuristics. We have to use humans.

1 Does it satisfy a need that needs to be satisfied?
2 Is the team involved of good intent? Are they capable of building
  something good, even if they haven't yet.
3 Is the tool (or intended tool) usable and useful without buying
  something you'd have to buy anyway (we all have to buy computers
  and networks) or putting the buyer in an untenable license violation?
4 Is the tool something that belongs in OpenStack?

Number 3 is the real topic of this thread. I'd argue that software
that uses a _service_ that is non-free does not make the software
non-free. Gating is certainly an issue but I think that is addressed
by my next point, about number 4.

While the big tent is nice in that it allows lots of people to use
the excellent OpenStack infrastructure it's diffusing the meaning of
what OpenStack is. We should be asking ourselves if something like
Poppy needs to be in OpenStack in order for it to be useful (and for
OpenStack to be better). Would Poppy be more useful to
more people if it were something that happens to work with OpenStack
but doesn't need OpenStack?

OpenStack is a type of meat and Poppy is perhaps a type of sauce.
OpenStack tastes good with Poppy on it, but it also taste good with
other types of sauce. Other types of meat may also taste good with
Poppy on it.

We shouldn't make Poppy "OpenStack" if it can be good sauce for lots of
meats. And we shouldn't make Poppy "OpenStack" because we need to make
more sure that the meat we've already got tastes good and doesn't
cause "hate" in user survey reactions.

By opening the flaps of the big tent wide we're opening ourselves up to
a lot of questions and debates that we don't necessarily have to have if
we keep ourselves focused more keenly on a limited vision of OpenStack.
And we're helping to keep the wide open source ecosystem healthy (where
the stuff under the tent works well with the rest of the world by virtue
of being a part of it rather than a separate something that is growing
to consume everything it needs). The tent doesn't have to cover
everything.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html
--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 08/02/16 10:52 -0800, Mike Perez wrote:

On 13:56 Feb 08, Flavio Percoco wrote:

On 08/02/16 09:24 -0500, Sean Dague wrote:
>On 02/08/2016 08:54 AM, Flavio Percoco wrote:
>
>>Would our votes change if Poppy had support for OpenCDN (imagine it's being
>>maintained) even if that solution is terrible?
>>
>>I guess my question is: When do we start considering a project to be
>>safe from
>>an open source perspective? Because, having support for 1 opensource
>>technology
>>doesn't mean it provides enough (or good) open source ways to deploy the
>>software. If the only supported open solution is *terrible* then
>>deployers would
>>be left with only commercial solutions to choose from.
>
>There is a lot of difference between 1 and 0 options, even if 1 isn't a
>great option. It also means the design has been informed by open
>backends, and not just commercial products.
>

If I'm not misinterpreting the above, you're saying that design adviced by open
source backends give better results. While I'm a huge fan of basing designs on
open source solutions, I don't think the above is necessarily true. I don't
think a solution that comes out of common features taken from commercial
products is bad.

Just to be clear, I do prefer designs based on open solutions but I don't think
those, like Poppy, that provision commercial solutions are bad.

Sorry if I misunderstood you here.


Nobody said providing commercial solutions is bad. Only providing commercial
solutions and having infra provide something in gate that's *dependent* on
a commercial entity is bad.


This is not my interpretation of what was written in the email I was replying to
but I take I might have misread it (as I actually mentioned).



>I think one could also consider Neutron originally started in such a
>state. openvswitch was definitely not mature technology when this effort
>started. You pretty much could only use commercial backends and have
>anything work. The use in OpenStack exposed issues, people contributed
>to proper upstream, things got much much better. We now have a ton of
>open backends in Neutron. That would never have happened if the projects
>started with 0.
>

++

This is exactly where I wanted to get to. So, arguably, the Poppy team could
"simply" take OpenCDN (assuming the license allow for) put it on GH, get a gate
on it and come back to the TC requesting inclusion with the difference this time
it'll have support for 1, very old, open source, CDN software.

This wouldn't be seen as a "nice thing" from a community perspective but,
technically, it'd suffice all the requirements. Right?

I don't think *anyone* will actually contribute to OpenCDN ater that happens and
it'll still require the TC to say: "That solution is not well maintained still,
we need to make sure it's production ready before it can be considered a valid
open source backend for Poppy"


If Poppy was to be picked as OpenCDN as their reference implementation:

* Everything in the API should work with the reference implementation so it can
 be tested.

* If only a commercial solution can do something exposed in the API, that's
 bad. Your API is now dictated by some implementations.

You better believe there's going to be some investment in making OpenCDN work
if gate jobs are depending on it passing. If you want to introduce some shiny
new checkbox feature from a CDN, there's going to also be investment in making
it work with the reference implementation.


Sure, still valid though. The Poppy team could even have its own reference
implementation, TBH. That's why I asked what I asked in the email Sean replied
to:


>>I guess my question is: When do we start considering a project to be
>>safe from
>>an open source perspective? Because, having support for 1 opensource
>>technology
>>doesn't mean it provides enough (or good) open source ways to deploy the
>>software. If the only supported open solution is *terrible* then
>>deployers would
>>be left with only commercial solutions to choose from.


Cheers,
Flavio

P.S: I'm playing the devils advocate here. I want to make sure we discuss some
of these things through and there's enough feedback from the community.

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jim Meyer]

> On Feb 5, 2016, at 9:54 AM, Tim Bell  wrote:
> 
> ...
> 
>> On "production-grade":
>> 
>> I'd be (strongly) in favor of defining a target deployment configuration and 
>> size which we find representative of the minimum bar for "production-grade." 
>> Anything less concrete and specific becomes more nuisance than help. I'd 
>> hope that specs might look like the following:
>> 
>> - tests must be run against an OpenStack-certified cloud containing at 
>> minimum 20 compute nodes, 1 TB block storage, 1 TB object storage
>> - tests must demonstrate service responsiveness, stability, and reliability 
>> while VMs, compute volumes, object store objects, and networks are 
>> created/destroyed at a rate of 50/second in any combination while 
>> maintaining 99.9%+ service availability, <1% error rate, and response 
>> latency of <100ms  
>> - tests must demonstrate service resiliency when faced with common component 
>> failures such as: compute node failure, storage failure, network failure, 
>> etc.
> 
> 
> The scale could be defined on the basis of the survey data. The reference 
> implementation should be able to address at least X% of deployments. I can 
> think of at least one project which was not suitable for use at a reasonable 
> size configuration and not being able to demonstrate this would have saved a 
> lot of grief in the ops community as well as ensuring the project addressed 
> the issue early.

+1 and I can think of more than one. =\

—j

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Julien Danjou]

On Fri, Feb 05 2016, Jay Pipes wrote:

> However, even though it's not the Poppy team's fault, I think the fact that 
> the
> Poppy project user's only choice when using Poppy is to use a non-free backend
> disqualifies Poppy from being an OpenStack project. The fact that the Poppy
> team follows the four Opens and genuinely wants to align with the OpenStack
> development methodology and processes is admirable and we should certainly
> encourage that behaviour, including welcoming Poppy into our CI platform for 
> as
> much as we can (given the obvious limitations around functional testing of
> Poppy). However, at the end of the day, I agree with Sean that this non-free
> restriction inherent in Poppy means it should not be included in the
> openstack/governance projects.yaml file as an "official" OpenStack project.

This is the kind of situation that makes Debian created a 'contrib'
section in its repository, a middle-ground between 'main' (free software)
and 'non-free' (non-free software):

  "The contrib archive area contains supplemental packages intended to
  work with the Debian distribution, but which require software outside
  of the distribution to either build or function.

  Every package in contrib must comply with the DFSG."

People writing software that goes into 'contrib' did not write non-free
software, but their software depends on non-free software, which makes
them useless to run an complete free system.

It seems OpenStack is finding itself in the same situation here. It
maybe too soon – or even unwanted – to have an equivalent "contrib"
section, but the familiarity of the situation strikes me.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 06/02/16 12:12 +0800, Thomas Goirand wrote:

On 02/05/2016 06:57 PM, Thierry Carrez wrote:

Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were
created to define how we would operate as a community. The first open,
"Open Source", added the following precision: "We do not produce 'open
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with
the other open source cloud platform (Eucalyptus) which was following an
Open Core strategy with a crippled community edition and an "enterprise
version". OpenStack was then the property of a single entity
(Rackspace), so giving strong signals that we would never follow such a
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit
independent Foundation, which could not even do an "enterprise edition"
if it wanted to. However, member companies build "enterprise products"
on top of the Apache-licensed upstream project. And we have drivers that
expose functionality in proprietary components. So what does it mean to
"not do open core" in 2016 ? What is acceptable and what's not ? It is
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what
is acceptable as an official project in the upstream OpenStack open
source effort. It should have a fully-functional, production-grade open
source implementation. If you need proprietary software or a commercial
entity to fully use the functionality of a project or getting serious
about it, then it should not be accepted in OpenStack as an official
project. It can still live as a non-official project and even be hosted
under OpenStack infrastructure, but it should not be part of
"OpenStack". That is how I would interpret "no open core" in OpenStack
2016.

Of course, the devil is in the details, especially around what I mean by
"fully-functional" and "production-grade". Is it just an API/stability
thing, or does performance/scalability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.

Comments ?


As I understand, Poppy a kind of middleware that does network access (an
"wrapper API"), right? This is comparable to let's say Pidgin, which
accesses proprietary services like Google talk, Yahoo messenger and
such. I have no problem with such a software, which I consider
completely free, even if they access a non-opened reverse engineered
network protocol.

The problem, to me, is different. It is more related to what kind of
value Poppy brings to OpenStack as a whole. And to me, that's where the
problem is. It's very low value, because its area is very far from what
we do: bring a fully open cloud. And Poppy only publishes to external
(commercial) service providers, it doesn't publish things within let's
say a multi-datacenter OpenStack deployment through a VM image it would use.


Providing a driver that sits on top of an open source solution (which apparently
doesn't exist in this case) doesn't mean everyone will deploy it on top of it.
People could choose non-open technologies and that doesn't - certainly,
shouldn't - change the way Poppy works. The same applies for every other
services that does *provisioning*, which is exactly what Poppy does.

I fail to see how Poppy doesn't provide a provisioning API to CDN
technologies/services that can be multi-tenant/multi-datacenter. If it doesn't,
then I believe the issue is in Poppy's API and not caused by the lack of open
source CDN solutions


Moreover, its requirement of Cassandra DB is a no-go (this has already
been discussed in another thread: Cassandra doesn't work well on OpenJDK
at all, which makes it non-free as it requires a Java interpreter which
is non-free itself). If I had to upload Poppy to Debian, it would be
uploaded to contrib (which is the area where free software requiring
non-free software to run or be built are uploaded). Contrib isn't
officially part of Debian.



So, this, I believe, is certainly an issue but one we shouldn't be discussing in
this email thread.

[snip]

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean Dague]

On 02/08/2016 08:54 AM, Flavio Percoco wrote:

> Would our votes change if Poppy had support for OpenCDN (imagine it's being
> maintained) even if that solution is terrible?
> 
> I guess my question is: When do we start considering a project to be
> safe from
> an open source perspective? Because, having support for 1 opensource
> technology
> doesn't mean it provides enough (or good) open source ways to deploy the
> software. If the only supported open solution is *terrible* then
> deployers would
> be left with only commercial solutions to choose from.

There is a lot of difference between 1 and 0 options, even if 1 isn't a
great option. It also means the design has been informed by open
backends, and not just commercial products.

I think one could also consider Neutron originally started in such a
state. openvswitch was definitely not mature technology when this effort
started. You pretty much could only use commercial backends and have
anything work. The use in OpenStack exposed issues, people contributed
to proper upstream, things got much much better. We now have a ton of
open backends in Neutron. That would never have happened if the projects
started with 0.

The flip side is  that CDN is a problem space that no consumers or ops
are interested in open backends. That's ok, however, if that's the case,
it doesn't feel OpenStack to me. Just being overlays for commercial
services seems a different thing that the rest of what's in OpenStack
today.

I think this is a place where there are lots of reasonable and different
points of view. And if it was clear cut there wouldn't be the need for
discussion.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 05/02/16 21:41 -0500, Jay Pipes wrote:

On 02/05/2016 02:16 PM, Sean Dague wrote:

On 02/05/2016 01:17 PM, Doug Hellmann wrote:

So, is Poppy "open core"?


Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
Source Cloud Platform. Because it only enables the use of commerical
services.

It's fine that it's open source software. I just don't think it's OpenStack.


So, I've read through this ML thread a couple times now. I see 
arguments on both sides of the coin here.


ditto

I'm no fan of open core. Never have been. So it irks me that Poppy 
can't work with any non-proprietary backend. But, as others have said, 
that isn't the Poppy team's fault.


However, even though it's not the Poppy team's fault, I think the fact 
that the Poppy project user's only choice when using Poppy is to use a 
non-free backend disqualifies Poppy from being an OpenStack project. 
The fact that the Poppy team follows the four Opens and genuinely 
wants to align with the OpenStack development methodology and 
processes is admirable and we should certainly encourage that 
behaviour, including welcoming Poppy into our CI platform for as much 
as we can (given the obvious limitations around functional testing of 
Poppy). However, at the end of the day, I agree with Sean that this 
non-free restriction inherent in Poppy means it should not be included 
in the openstack/governance projects.yaml file as an "official" 
OpenStack project.


After having put enough (I hope) thoughts on this over the weekend, I think I
agree with the above. They way I put it is:

What would be my solution, as a cloud provider, if I'd like to have a cloud
that relies only on open source technologies?

If you will, we could also add: What would distributions of OpenStack recommend
as a default driver?

This being said, I'd like to throw another question in the mix (just for the
sake of discussion and because I like to contradict myself).

Would our votes change if Poppy had support for OpenCDN (imagine it's being
maintained) even if that solution is terrible?

I guess my question is: When do we start considering a project to be safe from
an open source perspective? Because, having support for 1 opensource technology
doesn't mean it provides enough (or good) open source ways to deploy the
software. If the only supported open solution is *terrible* then deployers would
be left with only commercial solutions to choose from.

I'll comment back on the review but I wanted to get feedback from other folks in
this thread.

Cheers,
Flavio


I've left this comment on the review accordingly.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 13:56 Feb 08, Flavio Percoco wrote:
> On 08/02/16 09:24 -0500, Sean Dague wrote:
> >On 02/08/2016 08:54 AM, Flavio Percoco wrote:
> >
> >>Would our votes change if Poppy had support for OpenCDN (imagine it's being
> >>maintained) even if that solution is terrible?
> >>
> >>I guess my question is: When do we start considering a project to be
> >>safe from
> >>an open source perspective? Because, having support for 1 opensource
> >>technology
> >>doesn't mean it provides enough (or good) open source ways to deploy the
> >>software. If the only supported open solution is *terrible* then
> >>deployers would
> >>be left with only commercial solutions to choose from.
> >
> >There is a lot of difference between 1 and 0 options, even if 1 isn't a
> >great option. It also means the design has been informed by open
> >backends, and not just commercial products.
> >
> 
> If I'm not misinterpreting the above, you're saying that design adviced by 
> open
> source backends give better results. While I'm a huge fan of basing designs on
> open source solutions, I don't think the above is necessarily true. I don't
> think a solution that comes out of common features taken from commercial
> products is bad.
> 
> Just to be clear, I do prefer designs based on open solutions but I don't 
> think
> those, like Poppy, that provision commercial solutions are bad.
> 
> Sorry if I misunderstood you here.

Nobody said providing commercial solutions is bad. Only providing commercial
solutions and having infra provide something in gate that's *dependent* on
a commercial entity is bad.

> 
> >I think one could also consider Neutron originally started in such a
> >state. openvswitch was definitely not mature technology when this effort
> >started. You pretty much could only use commercial backends and have
> >anything work. The use in OpenStack exposed issues, people contributed
> >to proper upstream, things got much much better. We now have a ton of
> >open backends in Neutron. That would never have happened if the projects
> >started with 0.
> >
> 
> ++
> 
> This is exactly where I wanted to get to. So, arguably, the Poppy team could
> "simply" take OpenCDN (assuming the license allow for) put it on GH, get a 
> gate
> on it and come back to the TC requesting inclusion with the difference this 
> time
> it'll have support for 1, very old, open source, CDN software.
> 
> This wouldn't be seen as a "nice thing" from a community perspective but,
> technically, it'd suffice all the requirements. Right?
> 
> I don't think *anyone* will actually contribute to OpenCDN ater that happens 
> and
> it'll still require the TC to say: "That solution is not well maintained 
> still,
> we need to make sure it's production ready before it can be considered a valid
> open source backend for Poppy"

If Poppy was to be picked as OpenCDN as their reference implementation:

* Everything in the API should work with the reference implementation so it can
  be tested.

* If only a commercial solution can do something exposed in the API, that's
  bad. Your API is now dictated by some implementations.

You better believe there's going to be some investment in making OpenCDN work
if gate jobs are depending on it passing. If you want to introduce some shiny
new checkbox feature from a CDN, there's going to also be investment in making
it work with the reference implementation.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Flavio Percoco]

On 08/02/16 09:24 -0500, Sean Dague wrote:

On 02/08/2016 08:54 AM, Flavio Percoco wrote:


Would our votes change if Poppy had support for OpenCDN (imagine it's being
maintained) even if that solution is terrible?

I guess my question is: When do we start considering a project to be
safe from
an open source perspective? Because, having support for 1 opensource
technology
doesn't mean it provides enough (or good) open source ways to deploy the
software. If the only supported open solution is *terrible* then
deployers would
be left with only commercial solutions to choose from.


There is a lot of difference between 1 and 0 options, even if 1 isn't a
great option. It also means the design has been informed by open
backends, and not just commercial products.



If I'm not misinterpreting the above, you're saying that design adviced by open
source backends give better results. While I'm a huge fan of basing designs on
open source solutions, I don't think the above is necessarily true. I don't
think a solution that comes out of common features taken from commercial
products is bad.

Just to be clear, I do prefer designs based on open solutions but I don't think
those, like Poppy, that provision commercial solutions are bad.

Sorry if I misunderstood you here.


I think one could also consider Neutron originally started in such a
state. openvswitch was definitely not mature technology when this effort
started. You pretty much could only use commercial backends and have
anything work. The use in OpenStack exposed issues, people contributed
to proper upstream, things got much much better. We now have a ton of
open backends in Neutron. That would never have happened if the projects
started with 0.



++

This is exactly where I wanted to get to. So, arguably, the Poppy team could
"simply" take OpenCDN (assuming the license allow for) put it on GH, get a gate
on it and come back to the TC requesting inclusion with the difference this time
it'll have support for 1, very old, open source, CDN software.

This wouldn't be seen as a "nice thing" from a community perspective but,
technically, it'd suffice all the requirements. Right?

I don't think *anyone* will actually contribute to OpenCDN ater that happens and
it'll still require the TC to say: "That solution is not well maintained still,
we need to make sure it's production ready before it can be considered a valid
open source backend for Poppy"


The flip side is  that CDN is a problem space that no consumers or ops
are interested in open backends. That's ok, however, if that's the case,
it doesn't feel OpenStack to me. Just being overlays for commercial
services seems a different thing that the rest of what's in OpenStack
today.


Agreed that there's no much interest in having open backends for CDNs but there
*is* interest in CDNs, which are an important part of nowaday's cloud
applications. I personally want my cloud to suggest me something that *works*
and give me a seamless way to integrate with it the same way I integrate with
the DNS solution, messaging solution, etc.

In other words, I want my cloud to provide this and to do so, I agree it doesn't
need to be an "official" project for clouds to deploy it but I do think it's a
valid solution to have in the cloud tools-belt.



I think this is a place where there are lots of reasonable and different
points of view. And if it was clear cut there wouldn't be the need for
discussion.


++

Before we get to make any call, I want to make sure we've enough arguments that
we can base our opinions on. In fact, this very email currently has two
different opinions in favor and against including Poppy, although I believe I've
formed my opinion already.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jay Pipes]

On 02/05/2016 11:20 PM, Thomas Goirand wrote:

IMO, a middleware to access proprietary SaaS may be fully open. But it's
not OpenStack, as Sean Dague wrote.


That's what I wrote in the paragraph following the one you quoted. :)

-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Anita Kuno]

On 02/05/2016 02:41 PM, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
>> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
>> wrote:
>>
>>> So, is Poppy "open core"?
>>>
>>
>> It doesn't follow the 'spirit' of open core, but it does have some of the
>> characteristics, in that the open code is not all that useful, or maybe
>> even testable, without the commercial component(s) (at this time).
>>
>> So while Poppy may not fully qualify for the open core label, it still
>> fails some of the tests that we want to see, such as a usable open source
>> implementation.
>>
>> dt
>>
> 
> Testability is certainly an issue. There are ways to deal with the
> limitations, though. Is it any different from the other third-party
> CI we support for hardware drivers? Maybe it means no project wants
> to rely on Poppy because there's no way to set up integration tests.
> That's OK. We have other projects that don't have dependencies.
> 
> I'm not comfortable separating the intent aspect of the definition
> of "open core" from the effect. We set rules for the community to
> codify the culture and to discourage bad behavior. Nothing the Poppy
> team has done qualifies as bad behavior. What is the point of
> penalizing them with a strict interpretation of a rule meant to
> address a different problem?
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
I think we create problems for ourselves if we start equating the use of
the word no with punishment or penalty.

Sometimes no is a response that is chosen by one party for reasons
having nothing to do with punishment or penalty.

I think the two are separate.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Cody A.W. Somerville]

There are a lot of good questions and points being raised in this thread
but I think it might be appropriate to say we've opened a can of worms. As
mentioned by Doug there is a rather specific case[1] being considered that
I think provides some important context and framing.

It is clear that there are some that feel Poppy[2] should not be an
official OpenStack project. Deciding what is and what isn't an OpenStack
project is important for a number of reasons including protection of the
brand/identity of the project and the community; being faithful to our
principles; and logistical/resource constraints. It is a complicated and
nuanced topic with many considerations as evidenced by the many
conversations and opinions raised as part of the transition to the "big
tent model". I'll agree with Anita that it is a remarkable point of
strength that we've been able to communicate and find the consensus that we
have on these subjects when it is clear from even this short thread that
there is such a rich diversity of concerns, motivations, and agendas.

I'd like to suggest we tightly scope this discussion and subsequent
decision to Poppy exclusively. The reason for this is two fold. The first
is so that a timely resolution and answer can be provided to the Poppy
team. The second is that I think once we've answered the specific questions
and concerns about Poppy (some of which I believe are novel in nature)
we'll be in a better position to then inductively reason about the problem
and derive the more generalized rule or principle that I think Thierry was
hoping to establish.

In that vein, I'll try to summarize the questions or concerns I've seen
raised here and in the TC meeting[3] - apologies if I've missed any:

Poppy is an OpenStack project designed to make CDN services easier to
consume with a generic vendor-neutral API[4]. The concern is that it only
has support for commercial CDN service providers. It does not have support
for a CDN service that is Open Source.

 1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]?
 2. Do we have a requirement that the primary component/backend (or at
least one of the components/backends) driven/abstracted/orchestrated by a
project (directly or via driver/plugin/et al) be considered Open Source? If
yes, is there room for an exception when one simply doesn't exist? Is there
special consideration for "services" (ie. think GPL vs. AGPL)?
 3. Does a project that only enables the use of commercial
services/projects belong in OpenStack?
 4. Does Poppy violate existing requirements around testing/CI[7][8]?
 5. Does dependency on Casandra make Poppy non-free?
 6. Does a project that only enables the use of non-OpenStack
services/projects belong in OpenStack?

Some additional facts that have been pointed out include:

 - It currently only supports Akamai - which makes sense to be the first
provider, Akamai is the CDN provider for Rackspace[9] and the project is
mostly developed by Rackspace[10] - but implementation is underway for
Fastly, Amazon CloudFront, and MaxCDN[11].
 - It currently only supports Rackspace DNS but support for Designate is
planned[11] (only a stub exists in tree currently).

I'm going to ponder the above and I'll respond with my thoughts.

As for the following, they are all important and deserve deliberation but
I'd respectfully suggest we table them for another day - or at least
separately - so they get the attention and consideration they deserve:

 a) definitions for production-grade or scalable;
 b) new sets of requirements or standards for official projects, such as
the former;
 c) new requirements or conventions around feature parity or priority
between plugins/drivers/et al for Open Source vs. proprietary components;
 d) changing conventions around hosting of non-official projects;
 e) changing requirements around testing/CI;
 f) deciding anything already part of OpenStack isn't open enough or
unsuitable to be an OpenStack project; or
 g) material change or extension to the shared or common understanding of
"Open Core" in relation to deciding if Poppy is or is not open core.

[1] https://review.openstack.org/#/c/273756/
[2] http://www.poppycdn.org/
[3] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.html
[4] https://wiki.openstack.org/wiki/Poppy
[5] https://en.wikipedia.org/wiki/Open_core
[6] https://wiki.openstack.org/wiki/Open OR
https://governance.openstack.org/reference/opens.html
[7]
https://governance.openstack.org/reference/project-testing-interface.html
[8] Additional requirements exist such as must not install non-free
software in our hosted CI.
[9] https://www.rackspace.com/cloud/cdn-content-delivery-network
[10]
http://stackalytics.com/?project_type=all=all=poppy=commits
[11] https://github.com/openstack/poppy#features


Best regards,

Cody

-- 
Cody A.W. Somerville
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Russell Bryant]

On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> Even before OpenStack had a name, our "Four Opens" principles were
> created to define how we would operate as a community. The first open,
> "Open Source", added the following precision: "We do not produce 'open
> core' software". What does this mean in 2016 ?
> 
> Back in 2010 when OpenStack was started, this was a key difference with
> the other open source cloud platform (Eucalyptus) which was following an
> Open Core strategy with a crippled community edition and an "enterprise
> version". OpenStack was then the property of a single entity
> (Rackspace), so giving strong signals that we would never follow such a
> strategy was essential to form a real community.
> 
> Fast-forward today, the open source project is driven by a non-profit
> independent Foundation, which could not even do an "enterprise edition"
> if it wanted to. However, member companies build "enterprise products"
> on top of the Apache-licensed upstream project. And we have drivers that
> expose functionality in proprietary components. So what does it mean to
> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> time for us to refresh this.

Nice summary.  I agree that some clarification would be helpful given to
match our current reality.

> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open
> source effort. It should have a fully-functional, production-grade open
> source implementation. If you need proprietary software or a commercial
> entity to fully use the functionality of a project or getting serious
> about it, then it should not be accepted in OpenStack as an official
> project. It can still live as a non-official project and even be hosted
> under OpenStack infrastructure, but it should not be part of
> "OpenStack". That is how I would interpret "no open core" in OpenStack
> 2016.
> 
> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
> 
> Comments ?
> 

I agree with your take.  I'm not too worried about coming up with a
strict definition for what a reasonable open source backend is.  We can
throw in some desirable traits like you have done, and then leave it to
the TC to evaluate.  I think that's a reasonable part of the TC's job.

-- 
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thierry Carrez]

Dean Troyer wrote:

On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez > wrote:


My personal take on that is that we can draw a line in the sand for
what is acceptable as an official project in the upstream OpenStack
open source effort. It should have a fully-functional,
production-grade open source implementation. If you need proprietary
software or a commercial entity to fully use the functionality of a
project or getting serious about it, then it should not be accepted
in OpenStack as an official project. It can still live as a
non-official project and even be hosted under OpenStack
infrastructure, but it should not be part of "OpenStack". That is
how I would interpret "no open core" in OpenStack 2016.


Should we host projects that have no hope of becoming official projects
due to this sort of criteria?  Would we host GPL-only projects under
openstack/?


The answer to that lives at:
http://governance.openstack.org/reference/licensing.html

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Gareth]

I think that will become a clear definition but not a strict one :) In
Huawei, each release of product will be evaluated by availability,
security, usability, maintainability and something else. Those design
ideas looks difficult but could drive projects stronger.

On Sat, Feb 6, 2016 at 12:49 AM, Russell Bryant  wrote:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Even before OpenStack had a name, our "Four Opens" principles were
>> created to define how we would operate as a community. The first open,
>> "Open Source", added the following precision: "We do not produce 'open
>> core' software". What does this mean in 2016 ?
>>
>> Back in 2010 when OpenStack was started, this was a key difference with
>> the other open source cloud platform (Eucalyptus) which was following an
>> Open Core strategy with a crippled community edition and an "enterprise
>> version". OpenStack was then the property of a single entity
>> (Rackspace), so giving strong signals that we would never follow such a
>> strategy was essential to form a real community.
>>
>> Fast-forward today, the open source project is driven by a non-profit
>> independent Foundation, which could not even do an "enterprise edition"
>> if it wanted to. However, member companies build "enterprise products"
>> on top of the Apache-licensed upstream project. And we have drivers that
>> expose functionality in proprietary components. So what does it mean to
>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>> time for us to refresh this.
>
> Nice summary.  I agree that some clarification would be helpful given to
> match our current reality.
>
>> My personal take on that is that we can draw a line in the sand for what
>> is acceptable as an official project in the upstream OpenStack open
>> source effort. It should have a fully-functional, production-grade open
>> source implementation. If you need proprietary software or a commercial
>> entity to fully use the functionality of a project or getting serious
>> about it, then it should not be accepted in OpenStack as an official
>> project. It can still live as a non-official project and even be hosted
>> under OpenStack infrastructure, but it should not be part of
>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>> 2016.
>>
>> Of course, the devil is in the details, especially around what I mean by
>> "fully-functional" and "production-grade". Is it just an API/stability
>> thing, or does performance/scalability come into account ? There will
>> always be some subjectivity there, but I think it's a good place to start.
>>
>> Comments ?
>>
>
> I agree with your take.  I'm not too worried about coming up with a
> strict definition for what a reasonable open source backend is.  We can
> throw in some desirable traits like you have done, and then leave it to
> the TC to evaluate.  I think that's a reasonable part of the TC's job.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Gareth (Kun Huang)

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > Even before OpenStack had a name, our "Four Opens" principles were
> > created to define how we would operate as a community. The first open,
> > "Open Source", added the following precision: "We do not produce 'open
> > core' software". What does this mean in 2016 ?
> >
> > Back in 2010 when OpenStack was started, this was a key difference with
> > the other open source cloud platform (Eucalyptus) which was following an
> > Open Core strategy with a crippled community edition and an "enterprise
> > version". OpenStack was then the property of a single entity
> > (Rackspace), so giving strong signals that we would never follow such a
> > strategy was essential to form a real community.
> >
> > Fast-forward today, the open source project is driven by a non-profit
> > independent Foundation, which could not even do an "enterprise edition"
> > if it wanted to. However, member companies build "enterprise products"
> > on top of the Apache-licensed upstream project. And we have drivers that
> > expose functionality in proprietary components. So what does it mean to
> > "not do open core" in 2016 ? What is acceptable and what's not ? It is
> > time for us to refresh this.
> >
> > My personal take on that is that we can draw a line in the sand for what
> > is acceptable as an official project in the upstream OpenStack open
> > source effort. It should have a fully-functional, production-grade open
> > source implementation. If you need proprietary software or a commercial
> > entity to fully use the functionality of a project or getting serious
> > about it, then it should not be accepted in OpenStack as an official
> > project. It can still live as a non-official project and even be hosted
> > under OpenStack infrastructure, but it should not be part of
> > "OpenStack". That is how I would interpret "no open core" in OpenStack
> > 2016.
> >
> > Of course, the devil is in the details, especially around what I mean by
> > "fully-functional" and "production-grade". Is it just an API/stability
> > thing, or does performance/scalability come into account ? There will
> > always be some subjectivity there, but I think it's a good place to start.
> >
> > Comments ?
> 
> If a project isn't fully functional* then why would we accept it at all? 
> Imagine this scenario:
> 
> 1) Heat didn't exist
> 2) A project exactly like heat applies for OpenStack, that lets you use 
> templates to create resources to a specification
> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
> templates longer than 200 characters.

There's a more concrete case being considered right now that is less
clear to some [1].

The Poppy project provides an open source service to wrap content
delivery network APIs. They follow all of our other best-practices,
but there is apparently no practical open source CDN solution.
OpenCDN was mentioned, but it seems dead.

In the absence of any open source solution, the Poppy service is
only useful when connected to commercial services. The Poppy team
has provided drivers for several of these (I see akamai, cloudfront,
fastly, and maxcdn in their "providers" package). Stackalytics shows
the contributors on the team are mostly from Rackspace[2].  I'm not
aware of Rackspace owning any of those services, though I'm sure
they have relationships with one more more.

My understanding of the "no open core" requirement is about the
intent of the contributor.  We don't want separate community and
"enterprise" editions of components (services or drivers).  The
Poppy situation doesn't seem to be a case of open washing anything,
or holding back features in order to sell a more advanced version.
It happens that for Poppy to be useful, you have to buy another
service for it to talk to (and to serve your data), but all of the
Poppy code is actually open and there are several services to choose
from.  There is no "better" version of Poppy available for sale,
if you buy a PoppyCDN subscription.

So, is Poppy "open core"?

Doug

[1] https://review.openstack.org/#/c/273756/
[2] 
http://stackalytics.com/?project_type=all=all=poppy=commits

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jim Meyer]

On "production-grade":

> On Feb 5, 2016, at 6:23 AM, Tim Bell <tim.b...@cern.ch> wrote:
> 
> From: Dean Troyer
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Friday 5 February 2016 at 14:57
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
>> [...]
>> Of course, the devil is in the details, especially around what I mean by 
>> "fully-functional" and "production-grade". Is it just an API/stability 
>> thing, or does performance/scalability come into account ? There will always 
>> be some subjectivity there, but I think it's a good place to start.
> 
> I think defining 'fully-functional' is easy enough until you allow 'vendor 
> extensions' into the API.  But there is still an amount of objective criteria 
> to look at to make it something that a group of, say 13 judges, might arrive 
> at a reasonable answer.
> 
> 'Production-grade' is more subjective, especially with the size of deployment 
> differences in 'production' for a bunch of other things.  But again, it is 
> one of those things that reasonably technical people will generally arrive at 
> a useful conclusion .  Existing components (DB, message queues, etc) can 
> point at known production deployments as evidence; new components have a 
> harder sell.

I'm in complete support of requiring any device in OpenStack to have a 
"production-grade" free-software-based configuration; I'd also say that this 
should be the default configuration for "pure upstream" OpenStack. I don't see 
this as conflicting at all with vendor distros or deployments, which may change 
underlying components and configuration freely as long as the result meets the 
standards for "production-grade."

I'd be (strongly) in favor of defining a target deployment configuration and 
size which we find representative of the minimum bar for "production-grade." 
Anything less concrete and specific becomes more nuisance than help. I'd hope 
that specs might look like the following:

- tests must be run against an OpenStack-certified cloud containing at minimum 
20 compute nodes, 1 TB block storage, 1 TB object storage
- tests must demonstrate service responsiveness, stability, and reliability 
while VMs, compute volumes, object store objects, and networks are 
created/destroyed at a rate of 50/second in any combination while maintaining 
99.9%+ service availability, <1% error rate, and response latency of <100ms  
- tests must demonstrate service resiliency when faced with common component 
failures such as: compute node failure, storage failure, network failure, etc.

(all numbers here are to show the level of specificity needed, are completely 
made up, and should be chosen more appropriately than that)

I also think these are things that we should be regularly testing for core 
OpenStack services, and that I'd be happy to see as part of DefCore someday.

--j

> 
> For a time many projects used SQLite as a reference implementation for 
> testing DB functionality, and have moved away from that (completely? I'm not 
> sure) as we all agree it really is not a production-grade implementation.  
> That is an easy example, but as a community we have crossed this bridge 
> multiple times already and will be able to do it again.
> 
> This could also be covered by needing scaleable as well as fully-functional 
> and production grade. Again, it would be subjective but it would avoid 
> reference implementations that only work at devstack scale.
> 
> Tim
> 
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtro...@gmail.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 14:23 Feb 05, Tim Bell wrote:
> I think defining 'fully-functional' is easy enough until you allow 'vendor
> extensions' into the API.  But there is still an amount of objective criteria
> to look at to make it something that a group of, say 13 judges, might arrive
> at a reasonable answer.

I think those extensions shouldn't exist to begin with. That's another
discussion though, and a direction I think some projects are making already.

If a vendor wants to introduce anything into a project's API, there should be
some equivalent open source thing to back it up that people can try it out on.

I think more importantly the reference implementation a project chooses should
be able to use said feature, which is going to be an open source solution.

Projects like Cinder suffer from this today, and our only way of knowing if the
feature works is vendor third party CI's that use the optional tempest tests
for having the feature available in their driver.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
wrote:

> So, is Poppy "open core"?
>

It doesn't follow the 'spirit' of open core, but it does have some of the
characteristics, in that the open code is not all that useful, or maybe
even testable, without the commercial component(s) (at this time).

So while Poppy may not fully qualify for the open core label, it still
fails some of the tests that we want to see, such as a usable open source
implementation.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ryan Brown]

On 02/05/2016 05:57 AM, Thierry Carrez wrote:

Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were
created to define how we would operate as a community. The first open,
"Open Source", added the following precision: "We do not produce 'open
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with
the other open source cloud platform (Eucalyptus) which was following an
Open Core strategy with a crippled community edition and an "enterprise
version". OpenStack was then the property of a single entity
(Rackspace), so giving strong signals that we would never follow such a
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit
independent Foundation, which could not even do an "enterprise edition"
if it wanted to. However, member companies build "enterprise products"
on top of the Apache-licensed upstream project. And we have drivers that
expose functionality in proprietary components. So what does it mean to
"not do open core" in 2016 ? What is acceptable and what's not ? It is
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what
is acceptable as an official project in the upstream OpenStack open
source effort. It should have a fully-functional, production-grade open
source implementation. If you need proprietary software or a commercial
entity to fully use the functionality of a project or getting serious
about it, then it should not be accepted in OpenStack as an official
project. It can still live as a non-official project and even be hosted
under OpenStack infrastructure, but it should not be part of
"OpenStack". That is how I would interpret "no open core" in OpenStack
2016.

Of course, the devil is in the details, especially around what I mean by
"fully-functional" and "production-grade". Is it just an API/stability
thing, or does performance/scalability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.

Comments ?


If a project isn't fully functional* then why would we accept it at all? 
Imagine this scenario:


1) Heat didn't exist
2) A project exactly like heat applies for OpenStack, that lets you use 
templates to create resources to a specification
3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
templates longer than 200 characters.


Would *any* TC count that as a project that could join under our current 
system? I don't think so. The TC (and community) would say something 
along the lines of "WTF are you thinking? Go read the 4 opens and try again"


I don't think adding "no open core" would change a decision the 
future-community and future-tc might make, because they will be elected 
by aforementioned community. Adding buzz-requirements like "must be 
fully-functional, production grade, webscale open-cloud softwidgets" 
isn't going to help future-us.


Footnotes:

* in my view, an openstack product that requires you to pay a vendor is 
as functional as an openstack product chock-full of syntax errors


** Shed Cat Enterprise Leopard is strictly fictional, and not based on 
any company that currently or ever has existed.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ryan Brown]

On 02/05/2016 01:17 PM, Doug Hellmann wrote:

Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:

On 02/05/2016 05:57 AM, Thierry Carrez wrote:

Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were
created to define how we would operate as a community. The first open,
"Open Source", added the following precision: "We do not produce 'open
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with
the other open source cloud platform (Eucalyptus) which was following an
Open Core strategy with a crippled community edition and an "enterprise
version". OpenStack was then the property of a single entity
(Rackspace), so giving strong signals that we would never follow such a
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit
independent Foundation, which could not even do an "enterprise edition"
if it wanted to. However, member companies build "enterprise products"
on top of the Apache-licensed upstream project. And we have drivers that
expose functionality in proprietary components. So what does it mean to
"not do open core" in 2016 ? What is acceptable and what's not ? It is
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what
is acceptable as an official project in the upstream OpenStack open
source effort. It should have a fully-functional, production-grade open
source implementation. If you need proprietary software or a commercial
entity to fully use the functionality of a project or getting serious
about it, then it should not be accepted in OpenStack as an official
project. It can still live as a non-official project and even be hosted
under OpenStack infrastructure, but it should not be part of
"OpenStack". That is how I would interpret "no open core" in OpenStack
2016.

Of course, the devil is in the details, especially around what I mean by
"fully-functional" and "production-grade". Is it just an API/stability
thing, or does performance/scalability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.

Comments ?


If a project isn't fully functional* then why would we accept it at all?
Imagine this scenario:

1) Heat didn't exist
2) A project exactly like heat applies for OpenStack, that lets you use
templates to create resources to a specification
3) BUT, if you don't buy Proprietary Enterprise Template Parsing
Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse
templates longer than 200 characters.


There's a more concrete case being considered right now that is less
clear to some [1].

>

The Poppy project provides an open source service to wrap content
delivery network APIs. They follow all of our other best-practices,
but there is apparently no practical open source CDN solution.
OpenCDN was mentioned, but it seems dead.


This doesn't surprise me, since most of the "value-add" from a CDN is in 
the "we have points of presence and peering agreements" and less about 
"we use software XYZ". Take, for instance, a typical CDN pricing 
structure. You pay tiered on some combination bandwidth used and the 
number of points-of-presence you want your content served from.


Open source projects aren't usually set up around making big capital 
expenditures and buying lots of bandwidth, so the lack of a FOSS CDN 
isn't exactly Poppy's fault.



In the absence of any open source solution, the Poppy service is
only useful when connected to commercial services. The Poppy team
has provided drivers for several of these (I see akamai, cloudfront,
fastly, and maxcdn in their "providers" package). Stackalytics shows
the contributors on the team are mostly from Rackspace[2].  I'm not
aware of Rackspace owning any of those services, though I'm sure
they have relationships with one more more.


Even in the absence of an open source CDN, I struggle to call poppy 
"open core" in the spirit of "you must buy our enterprise plan" because 
it still doesn't require paying any single vendor. I can still choose 
the commodity (bandwidth, datacenter locations, etc) provider.


This actually proves my point about the community/TC being intelligent 
and being able to make decisions about this sort of thing. A written 
rule about open core might mean we couldn't allow Poppy into the tent, 
but because we have the broader 4-Opens we can look at it and say "yeah, 
it requires you pay for a service, but it's clearly enabling many 
vendors and making it EASIER to switch, which is great."



My understanding of the "no open core" requirement is about the
intent of the contributor.  We don't want separate community and
"enterprise" editions of components (services or drivers).  The
Poppy situation doesn't seem to be a case of open washing anything,
or holding back features in order to sell a more advanced version.
It happens that for Poppy to be 

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 07:57 Feb 05, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez 
> wrote:
> 
> > My personal take on that is that we can draw a line in the sand for what
> > is acceptable as an official project in the upstream OpenStack open source
> > effort. It should have a fully-functional, production-grade open source
> > implementation. If you need proprietary software or a commercial entity to
> > fully use the functionality of a project or getting serious about it, then
> > it should not be accepted in OpenStack as an official project. It can still
> > live as a non-official project and even be hosted under OpenStack
> > infrastructure, but it should not be part of "OpenStack". That is how I
> > would interpret "no open core" in OpenStack 2016.
> >
> 
> Should we host projects that have no hope of becoming official projects due
> to this sort of criteria?  Would we host GPL-only projects under openstack/?

With previous threads complaining about low on infra resources to help with
stable releases, I'd actually say no we shouldn't host them. We're already low
with the sunsetting of a big public cloud.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Neil Jerram]

On 05/02/16 10:59, Thierry Carrez wrote:
> Hi everyone,
>
> Even before OpenStack had a name, our "Four Opens" principles were 
> created to define how we would operate as a community. The first open, 
> "Open Source", added the following precision: "We do not produce 'open 
> core' software". What does this mean in 2016 ?
>
> Back in 2010 when OpenStack was started, this was a key difference with 
> the other open source cloud platform (Eucalyptus) which was following an 
> Open Core strategy with a crippled community edition and an "enterprise 
> version". OpenStack was then the property of a single entity 
> (Rackspace), so giving strong signals that we would never follow such a 
> strategy was essential to form a real community.
>
> Fast-forward today, the open source project is driven by a non-profit 
> independent Foundation, which could not even do an "enterprise edition" 
> if it wanted to. However, member companies build "enterprise products" 
> on top of the Apache-licensed upstream project. And we have drivers that 
> expose functionality in proprietary components. So what does it mean to 
> "not do open core" in 2016 ? What is acceptable and what's not ? It is 
> time for us to refresh this.
>
> My personal take on that is that we can draw a line in the sand for what 
> is acceptable as an official project in the upstream OpenStack open 
> source effort. It should have a fully-functional, production-grade open 
> source implementation. If you need proprietary software or a commercial 
> entity to fully use the functionality of a project or getting serious 
> about it, then it should not be accepted in OpenStack as an official 
> project. It can still live as a non-official project and even be hosted 
> under OpenStack infrastructure, but it should not be part of 
> "OpenStack". That is how I would interpret "no open core" in OpenStack 2016.
>
> Of course, the devil is in the details, especially around what I mean by 
> "fully-functional" and "production-grade". Is it just an API/stability 
> thing, or does performance/scalability come into account ? There will 
> always be some subjectivity there, but I think it's a good place to start.
>
> Comments ?
>

This sounds right to me.

It looks like there may soon be a group of projects wanting to move from
Neutron stadium governance to OpenStack big tent governance, and I
presume this criterion should apply to those too.

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> wrote:
> 
> > So, is Poppy "open core"?
> >
> 
> It doesn't follow the 'spirit' of open core, but it does have some of the
> characteristics, in that the open code is not all that useful, or maybe
> even testable, without the commercial component(s) (at this time).
> 
> So while Poppy may not fully qualify for the open core label, it still
> fails some of the tests that we want to see, such as a usable open source
> implementation.
> 
> dt
> 

Testability is certainly an issue. There are ways to deal with the
limitations, though. Is it any different from the other third-party
CI we support for hardware drivers? Maybe it means no project wants
to rely on Poppy because there's no way to set up integration tests.
That's OK. We have other projects that don't have dependencies.

I'm not comfortable separating the intent aspect of the definition
of "open core" from the effect. We set rules for the community to
codify the culture and to discourage bad behavior. Nothing the Poppy
team has done qualifies as bad behavior. What is the point of
penalizing them with a strict interpretation of a rule meant to
address a different problem?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jeremy Stanley]

On 2016-02-05 13:17:40 -0500 (-0500), Doug Hellmann wrote:
[...]
> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
[...]

Considering the openness of software based on the openness of its
prerequisites is complex and fraught with snakepits. There is
unfortunately almost always some level of non-freeness:

To run it, do you need to purchase a computer or similar
infrastructure? Electricity? Cooling?

Will it run on a system which is not littered with non-free
microcode, either uploaded as blobs by the operating system or
perpetually resident as system firmware in (((e)e)p)rom?

Are there systems with board schematics and full parts manifests
published under an open license on which you can run it?

This discussion comes up a lot in other free software communities,
and if we push back on completely freely-licensed and
openly-developed client software which people can use with a
proprietary service and for which there is no alternative open
equivalent service on the market (yet), we need to be prepared to
answer these other questions about where we draw the line on "open
enough."
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Anita Kuno]

On 02/05/2016 12:14 PM, Ryan Brown wrote:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Even before OpenStack had a name, our "Four Opens" principles were
>> created to define how we would operate as a community. The first open,
>> "Open Source", added the following precision: "We do not produce 'open
>> core' software". What does this mean in 2016 ?
>>
>> Back in 2010 when OpenStack was started, this was a key difference with
>> the other open source cloud platform (Eucalyptus) which was following an
>> Open Core strategy with a crippled community edition and an "enterprise
>> version". OpenStack was then the property of a single entity
>> (Rackspace), so giving strong signals that we would never follow such a
>> strategy was essential to form a real community.
>>
>> Fast-forward today, the open source project is driven by a non-profit
>> independent Foundation, which could not even do an "enterprise edition"
>> if it wanted to. However, member companies build "enterprise products"
>> on top of the Apache-licensed upstream project. And we have drivers that
>> expose functionality in proprietary components. So what does it mean to
>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>> time for us to refresh this.
>>
>> My personal take on that is that we can draw a line in the sand for what
>> is acceptable as an official project in the upstream OpenStack open
>> source effort. It should have a fully-functional, production-grade open
>> source implementation. If you need proprietary software or a commercial
>> entity to fully use the functionality of a project or getting serious
>> about it, then it should not be accepted in OpenStack as an official
>> project. It can still live as a non-official project and even be hosted
>> under OpenStack infrastructure, but it should not be part of
>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>> 2016.
>>
>> Of course, the devil is in the details, especially around what I mean by
>> "fully-functional" and "production-grade". Is it just an API/stability
>> thing, or does performance/scalability come into account ? There will
>> always be some subjectivity there, but I think it's a good place to
>> start.
>>
>> Comments ?
> 
> If a project isn't fully functional* then why would we accept it at all?
> Imagine this scenario:
> 
> 1) Heat didn't exist
> 2) A project exactly like heat applies for OpenStack, that lets you use
> templates to create resources to a specification
> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing
> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse
> templates longer than 200 characters.
> 
> Would *any* TC count that as a project that could join under our current
> system? I don't think so. The TC (and community) would say something
> along the lines of "WTF are you thinking? Go read the 4 opens and try
> again"

I think it is a point of strength that so many in our community
including the TC both individually and collectively are able to
communicate perspectives and decisions without referencing profanity.

So I happen to disagree with your current characterization as worded.

Thank you,
Anita.

> 
> I don't think adding "no open core" would change a decision the
> future-community and future-tc might make, because they will be elected
> by aforementioned community. Adding buzz-requirements like "must be
> fully-functional, production grade, webscale open-cloud softwidgets"
> isn't going to help future-us.
> 
> Footnotes:
> 
> * in my view, an openstack product that requires you to pay a vendor is
> as functional as an openstack product chock-full of syntax errors
> 
> ** Shed Cat Enterprise Leopard is strictly fictional, and not based on
> any company that currently or ever has existed.
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean Dague]

On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
>> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> Even before OpenStack had a name, our "Four Opens" principles were
>>> created to define how we would operate as a community. The first open,
>>> "Open Source", added the following precision: "We do not produce 'open
>>> core' software". What does this mean in 2016 ?
>>>
>>> Back in 2010 when OpenStack was started, this was a key difference with
>>> the other open source cloud platform (Eucalyptus) which was following an
>>> Open Core strategy with a crippled community edition and an "enterprise
>>> version". OpenStack was then the property of a single entity
>>> (Rackspace), so giving strong signals that we would never follow such a
>>> strategy was essential to form a real community.
>>>
>>> Fast-forward today, the open source project is driven by a non-profit
>>> independent Foundation, which could not even do an "enterprise edition"
>>> if it wanted to. However, member companies build "enterprise products"
>>> on top of the Apache-licensed upstream project. And we have drivers that
>>> expose functionality in proprietary components. So what does it mean to
>>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>>> time for us to refresh this.
>>>
>>> My personal take on that is that we can draw a line in the sand for what
>>> is acceptable as an official project in the upstream OpenStack open
>>> source effort. It should have a fully-functional, production-grade open
>>> source implementation. If you need proprietary software or a commercial
>>> entity to fully use the functionality of a project or getting serious
>>> about it, then it should not be accepted in OpenStack as an official
>>> project. It can still live as a non-official project and even be hosted
>>> under OpenStack infrastructure, but it should not be part of
>>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>>> 2016.
>>>
>>> Of course, the devil is in the details, especially around what I mean by
>>> "fully-functional" and "production-grade". Is it just an API/stability
>>> thing, or does performance/scalability come into account ? There will
>>> always be some subjectivity there, but I think it's a good place to start.
>>>
>>> Comments ?
>>
>> If a project isn't fully functional* then why would we accept it at all? 
>> Imagine this scenario:
>>
>> 1) Heat didn't exist
>> 2) A project exactly like heat applies for OpenStack, that lets you use 
>> templates to create resources to a specification
>> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
>> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
>> templates longer than 200 characters.
> 
> There's a more concrete case being considered right now that is less
> clear to some [1].
> 
> The Poppy project provides an open source service to wrap content
> delivery network APIs. They follow all of our other best-practices,
> but there is apparently no practical open source CDN solution.
> OpenCDN was mentioned, but it seems dead.
> 
> In the absence of any open source solution, the Poppy service is
> only useful when connected to commercial services. The Poppy team
> has provided drivers for several of these (I see akamai, cloudfront,
> fastly, and maxcdn in their "providers" package). Stackalytics shows
> the contributors on the team are mostly from Rackspace[2].  I'm not
> aware of Rackspace owning any of those services, though I'm sure
> they have relationships with one more more.
> 
> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
> 
> So, is Poppy "open core"?

Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
Source Cloud Platform. Because it only enables the use of commerical
services.

It's fine that it's open source software. I just don't think it's OpenStack.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 12:27 Feb 05, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> wrote:
> 
> > So, is Poppy "open core"?
> >
> 
> It doesn't follow the 'spirit' of open core, but it does have some of the
> characteristics, in that the open code is not all that useful, or maybe
> even testable, without the commercial component(s) (at this time).
> 
> So while Poppy may not fully qualify for the open core label, it still
> fails some of the tests that we want to see, such as a usable open source
> implementation.

>From a QA perspective in gate, if we have to rely on a commercial solution
(even if donated) to test it, then that's bad.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-02-05 14:16:12 -0500:
> On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> > Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
> >> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> >>> Hi everyone,
> >>>
> >>> Even before OpenStack had a name, our "Four Opens" principles were
> >>> created to define how we would operate as a community. The first open,
> >>> "Open Source", added the following precision: "We do not produce 'open
> >>> core' software". What does this mean in 2016 ?
> >>>
> >>> Back in 2010 when OpenStack was started, this was a key difference with
> >>> the other open source cloud platform (Eucalyptus) which was following an
> >>> Open Core strategy with a crippled community edition and an "enterprise
> >>> version". OpenStack was then the property of a single entity
> >>> (Rackspace), so giving strong signals that we would never follow such a
> >>> strategy was essential to form a real community.
> >>>
> >>> Fast-forward today, the open source project is driven by a non-profit
> >>> independent Foundation, which could not even do an "enterprise edition"
> >>> if it wanted to. However, member companies build "enterprise products"
> >>> on top of the Apache-licensed upstream project. And we have drivers that
> >>> expose functionality in proprietary components. So what does it mean to
> >>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> >>> time for us to refresh this.
> >>>
> >>> My personal take on that is that we can draw a line in the sand for what
> >>> is acceptable as an official project in the upstream OpenStack open
> >>> source effort. It should have a fully-functional, production-grade open
> >>> source implementation. If you need proprietary software or a commercial
> >>> entity to fully use the functionality of a project or getting serious
> >>> about it, then it should not be accepted in OpenStack as an official
> >>> project. It can still live as a non-official project and even be hosted
> >>> under OpenStack infrastructure, but it should not be part of
> >>> "OpenStack". That is how I would interpret "no open core" in OpenStack
> >>> 2016.
> >>>
> >>> Of course, the devil is in the details, especially around what I mean by
> >>> "fully-functional" and "production-grade". Is it just an API/stability
> >>> thing, or does performance/scalability come into account ? There will
> >>> always be some subjectivity there, but I think it's a good place to start.
> >>>
> >>> Comments ?
> >>
> >> If a project isn't fully functional* then why would we accept it at all? 
> >> Imagine this scenario:
> >>
> >> 1) Heat didn't exist
> >> 2) A project exactly like heat applies for OpenStack, that lets you use 
> >> templates to create resources to a specification
> >> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
> >> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
> >> templates longer than 200 characters.
> > 
> > There's a more concrete case being considered right now that is less
> > clear to some [1].
> > 
> > The Poppy project provides an open source service to wrap content
> > delivery network APIs. They follow all of our other best-practices,
> > but there is apparently no practical open source CDN solution.
> > OpenCDN was mentioned, but it seems dead.
> > 
> > In the absence of any open source solution, the Poppy service is
> > only useful when connected to commercial services. The Poppy team
> > has provided drivers for several of these (I see akamai, cloudfront,
> > fastly, and maxcdn in their "providers" package). Stackalytics shows
> > the contributors on the team are mostly from Rackspace[2].  I'm not
> > aware of Rackspace owning any of those services, though I'm sure
> > they have relationships with one more more.
> > 
> > My understanding of the "no open core" requirement is about the
> > intent of the contributor.  We don't want separate community and
> > "enterprise" editions of components (services or drivers).  The
> > Poppy situation doesn't seem to be a case of open washing anything,
> > or holding back features in order to sell a more advanced version.
> > It happens that for Poppy to be useful, you have to buy another
> > service for it to talk to (and to serve your data), but all of the
> > Poppy code is actually open and there are several services to choose
> > from.  There is no "better" version of Poppy available for sale,
> > if you buy a PoppyCDN subscription.
> > 
> > So, is Poppy "open core"?
> 
> Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
> Source Cloud Platform. Because it only enables the use of commerical
> services.
> 
> It's fine that it's open source software. I just don't think it's OpenStack.
> 
> -Sean

I don't understand the connection you're making.

Doug

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 14:41 Feb 05, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
> > On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> > wrote:
> > 
> > > So, is Poppy "open core"?
> > >
> > 
> > It doesn't follow the 'spirit' of open core, but it does have some of the
> > characteristics, in that the open code is not all that useful, or maybe
> > even testable, without the commercial component(s) (at this time).
> > 
> > So while Poppy may not fully qualify for the open core label, it still
> > fails some of the tests that we want to see, such as a usable open source
> > implementation.
> > 
> > dt
> > 
> 
> Testability is certainly an issue. There are ways to deal with the
> limitations, though. Is it any different from the other third-party
> CI we support for hardware drivers? Maybe it means no project wants
> to rely on Poppy because there's no way to set up integration tests.
> That's OK. We have other projects that don't have dependencies.

Yes it is different. Because the other examples like Cinder is there is an open
source solution that is available that could potentionally do the feature
proposed by a commercial solution, and therefore can be tested by anyone who
wants to install the free solution, in addition to see the results by third
party ci logs. (I say it this way because we haven't been good about making
sure certain features are available by ceph. Some are just impossible in the
reference implementation LVM)

> I'm not comfortable separating the intent aspect of the definition
> of "open core" from the effect. We set rules for the community to
> codify the culture and to discourage bad behavior. Nothing the Poppy
> team has done qualifies as bad behavior. What is the point of
> penalizing them with a strict interpretation of a rule meant to
> address a different problem?

As I've mentioned in previous replies of this thread it's about how the
community can test a project. If we have to depend on a commercial entity to do
tests on the main features of a project, I see that as a problem.

I'm with Sean where I see this as not fitting with what the community is trying
to bring in based on what the TC has set in the governance, and what has
already been raised in this discussion.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez 
wrote:

> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open source
> effort. It should have a fully-functional, production-grade open source
> implementation. If you need proprietary software or a commercial entity to
> fully use the functionality of a project or getting serious about it, then
> it should not be accepted in OpenStack as an official project. It can still
> live as a non-official project and even be hosted under OpenStack
> infrastructure, but it should not be part of "OpenStack". That is how I
> would interpret "no open core" in OpenStack 2016.
>

Should we host projects that have no hope of becoming official projects due
to this sort of criteria?  Would we host GPL-only projects under openstack/?


> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
>

I think defining 'fully-functional' is easy enough until you allow 'vendor
extensions' into the API.  But there is still an amount of objective
criteria to look at to make it something that a group of, say 13 judges,
might arrive at a reasonable answer.

'Production-grade' is more subjective, especially with the size of
deployment differences in 'production' for a bunch of other things.  But
again, it is one of those things that reasonably technical people will
generally arrive at a useful conclusion .  Existing components (DB, message
queues, etc) can point at known production deployments as evidence; new
components have a harder sell.

For a time many projects used SQLite as a reference implementation for
testing DB functionality, and have moved away from that (completely? I'm
not sure) as we all agree it really is not a production-grade
implementation.  That is an easy example, but as a community we have
crossed this bridge multiple times already and will be able to do it again.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Tim Bell]

From:  Dean Troyer
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
Date:  Friday 5 February 2016 at 14:57
To:  "OpenStack Development Mailing List (not for usage questions)"
Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez <thie...@openstack.org> wrote:
My personal take on that is that we can draw a line in the sand for what is 
acceptable as an official project in the upstream OpenStack open source effort. 
It should have a fully-functional, production-grade open source implementation. 
If you need proprietary software or a commercial entity to fully use the 
functionality of a project or getting serious about it, then it should not be 
accepted in OpenStack as an official project. It can still live as a 
non-official project and even be hosted under OpenStack infrastructure, but it 
should not be part of "OpenStack". That is how I would interpret "no open core" 
in OpenStack 2016.

Should we host projects that have no hope of becoming official projects due to 
this sort of criteria?  Would we host GPL-only projects under openstack/?
 
Of course, the devil is in the details, especially around what I mean by 
"fully-functional" and "production-grade". Is it just an API/stability thing, 
or does performance/scalability come into account ? There will always be some 
subjectivity there, but I think it's a good place to start.

I think defining 'fully-functional' is easy enough until you allow 'vendor 
extensions' into the API.  But there is still an amount of objective criteria 
to look at to make it something that a group of, say 13 judges, might arrive at 
a reasonable answer.

'Production-grade' is more subjective, especially with the size of deployment 
differences in 'production' for a bunch of other things.  But again, it is one 
of those things that reasonably technical people will generally arrive at a 
useful conclusion .  Existing components (DB, message queues, etc) can point at 
known production deployments as evidence; new components have a harder sell.

For a time many projects used SQLite as a reference implementation for testing 
DB functionality, and have moved away from that (completely? I'm not sure) as 
we all agree it really is not a production-grade implementation.  That is an 
easy example, but as a community we have crossed this bridge multiple times 
already and will be able to do it again.

This could also be covered by needing scaleable as well as fully-functional and 
production grade. Again, it would be subjective but it would avoid reference 
implementations that only work at devstack scale.

Tim


dt

-- 

Dean Troyer
dtro...@gmail.com



smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jay Pipes]

On 02/05/2016 02:16 PM, Sean Dague wrote:

On 02/05/2016 01:17 PM, Doug Hellmann wrote:

So, is Poppy "open core"?


Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
Source Cloud Platform. Because it only enables the use of commerical
services.

It's fine that it's open source software. I just don't think it's OpenStack.


So, I've read through this ML thread a couple times now. I see arguments 
on both sides of the coin here.


I'm no fan of open core. Never have been. So it irks me that Poppy can't 
work with any non-proprietary backend. But, as others have said, that 
isn't the Poppy team's fault.


However, even though it's not the Poppy team's fault, I think the fact 
that the Poppy project user's only choice when using Poppy is to use a 
non-free backend disqualifies Poppy from being an OpenStack project. The 
fact that the Poppy team follows the four Opens and genuinely wants to 
align with the OpenStack development methodology and processes is 
admirable and we should certainly encourage that behaviour, including 
welcoming Poppy into our CI platform for as much as we can (given the 
obvious limitations around functional testing of Poppy). However, at the 
end of the day, I agree with Sean that this non-free restriction 
inherent in Poppy means it should not be included in the 
openstack/governance projects.yaml file as an "official" OpenStack project.


I've left this comment on the review accordingly.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/05/2016 06:57 PM, Thierry Carrez wrote:
> Hi everyone,
> 
> Even before OpenStack had a name, our "Four Opens" principles were
> created to define how we would operate as a community. The first open,
> "Open Source", added the following precision: "We do not produce 'open
> core' software". What does this mean in 2016 ?
> 
> Back in 2010 when OpenStack was started, this was a key difference with
> the other open source cloud platform (Eucalyptus) which was following an
> Open Core strategy with a crippled community edition and an "enterprise
> version". OpenStack was then the property of a single entity
> (Rackspace), so giving strong signals that we would never follow such a
> strategy was essential to form a real community.
> 
> Fast-forward today, the open source project is driven by a non-profit
> independent Foundation, which could not even do an "enterprise edition"
> if it wanted to. However, member companies build "enterprise products"
> on top of the Apache-licensed upstream project. And we have drivers that
> expose functionality in proprietary components. So what does it mean to
> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> time for us to refresh this.
> 
> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open
> source effort. It should have a fully-functional, production-grade open
> source implementation. If you need proprietary software or a commercial
> entity to fully use the functionality of a project or getting serious
> about it, then it should not be accepted in OpenStack as an official
> project. It can still live as a non-official project and even be hosted
> under OpenStack infrastructure, but it should not be part of
> "OpenStack". That is how I would interpret "no open core" in OpenStack
> 2016.
> 
> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
> 
> Comments ?

As I understand, Poppy a kind of middleware that does network access (an
"wrapper API"), right? This is comparable to let's say Pidgin, which
accesses proprietary services like Google talk, Yahoo messenger and
such. I have no problem with such a software, which I consider
completely free, even if they access a non-opened reverse engineered
network protocol.

The problem, to me, is different. It is more related to what kind of
value Poppy brings to OpenStack as a whole. And to me, that's where the
problem is. It's very low value, because its area is very far from what
we do: bring a fully open cloud. And Poppy only publishes to external
(commercial) service providers, it doesn't publish things within let's
say a multi-datacenter OpenStack deployment through a VM image it would use.

Moreover, its requirement of Cassandra DB is a no-go (this has already
been discussed in another thread: Cassandra doesn't work well on OpenJDK
at all, which makes it non-free as it requires a Java interpreter which
is non-free itself). If I had to upload Poppy to Debian, it would be
uploaded to contrib (which is the area where free software requiring
non-free software to run or be built are uploaded). Contrib isn't
officially part of Debian.

So, to accept Poppy, IMHO, it would have to:
1/ Get away from Cassandra and use a db driver which is truly free. The
"Your own DB provider here" in the README.rst is not satisfying enough,
and another db provider *must* be promoted to 1st class citizen.
2/ Puppy *must* permit to use OpenStack deployments only across multiple
datacenters (multiple regions?) and be completely useful without the
need of external resources.

Until these 2 issues aren't solved, I see no point in accepting Poppy
under the big tent, even if I consider Poppy itself fully free-software
(and not open-core as Thierry wrote).

The above points 1 and 2 are blockers, but something can be done to lift
to block, so it's not entirely negative.

I hope this helps,
Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/05/2016 06:57 PM, Thierry Carrez wrote:
> Hi everyone,
> 
> Even before OpenStack had a name, our "Four Opens" principles were
> created to define how we would operate as a community. The first open,
> "Open Source", added the following precision: "We do not produce 'open
> core' software". What does this mean in 2016 ?
> 
> Back in 2010 when OpenStack was started, this was a key difference with
> the other open source cloud platform (Eucalyptus) which was following an
> Open Core strategy with a crippled community edition and an "enterprise
> version". OpenStack was then the property of a single entity
> (Rackspace), so giving strong signals that we would never follow such a
> strategy was essential to form a real community.
> 
> Fast-forward today, the open source project is driven by a non-profit
> independent Foundation, which could not even do an "enterprise edition"
> if it wanted to. However, member companies build "enterprise products"
> on top of the Apache-licensed upstream project. And we have drivers that
> expose functionality in proprietary components. So what does it mean to
> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> time for us to refresh this.
> 
> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open
> source effort. It should have a fully-functional, production-grade open
> source implementation. If you need proprietary software or a commercial
> entity to fully use the functionality of a project or getting serious
> about it, then it should not be accepted in OpenStack as an official
> project. It can still live as a non-official project and even be hosted
> under OpenStack infrastructure, but it should not be part of
> "OpenStack". That is how I would interpret "no open core" in OpenStack
> 2016.
> 
> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
> 
> Comments ?

As I understand, Poppy a kind of middleware that does network access (an
"wrapper API"), right? This is comparable to let's say Pidgin, which
accesses proprietary services like Google talk, Yahoo messenger and
such. I have no problem with such a software, which I consider
completely free, even if they access a non-opened reverse engineered
network protocol.

The problem, to me, is different. It is more related to what kind of
value Poppy brings to OpenStack as a whole. And to me, that's where the
problem is. It's very low value, because its area is very far from what
we do: bring a fully open cloud. And Poppy only publishes to external
(commercial) service providers, it doesn't publish things within let's
say a multi-datacenter OpenStack deployment through a VM image it would use.

Moreover, its requirement of Cassandra DB is a no-go (this has already
been discussed in another thread: Cassandra doesn't work well on OpenJDK
at all, which makes it non-free as it requires a Java interpreter which
is non-free itself). If I had to upload Poppy to Debian, it would be
uploaded to contrib (which is the area where free software requiring
non-free software to run or be built are uploaded). Contrib isn't
officially part of Debian.

So, to accept Poppy, IMHO, it would have to:
1/ Get away from Cassandra and use a db driver which is truly free. The
"Your own DB provider here" in the README.rst is not satisfying enough,
and another db provider *must* be promoted to 1st class citizen.
2/ Puppy *must* permit to use OpenStack deployments only across multiple
datacenters (multiple regions?) and be completely useful without the
need of external resources.

Until these 2 issues aren't solved, I see no point in accepting Poppy
under the big tent, even if I consider Poppy itself fully free-software
(and not open-core as Thierry wrote).

The above points 1 and 2 are solvable, and maybe the authors will want
to do something about it.

I hope this helps,
Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thomas Goirand]

On 02/06/2016 10:41 AM, Jay Pipes wrote:
> I'm no fan of open core. Never have been. So it irks me that Poppy can't
> work with any non-proprietary backend. But, as others have said, that
> isn't the Poppy team's fault.

I don't agree. Poppy could leverage a multi-datacneter OpenStack
deployment, and deploy a CDN using that. If Poppy's team didn't
implement it, who's fault is it?

There's *many* reverse proxies available. There's ways to account for
used bandwidth in OpenStack. There's even manila to share the published
content on multiple VMs and scale horizontally. We just need a bit of
glue around all of this, which Poppy could leverage to deploy a CDN on
top of OpenStack. But that's not the current implementation.

IMO, a middleware to access proprietary SaaS may be fully open. But it's
not OpenStack, as Sean Dague wrote.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev