Open Stack

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

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160219/65736dd2/attachment.html>