On Sat, Feb 6, 2016 at 2:14 AM, Cody A.W. Somerville < cody.somervi...@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
__________________________________________________________________________ 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
