<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 6, 2016 at 2:14 AM, Cody A.W. Somerville <span dir="ltr"><<a href="mailto:cody.somerville@gmail.com" target="_blank">cody.somerville@gmail.com</a>></span> wrote:<br><div><span style="font-family:monospace,monospace"> <snip></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br><font face="monospace,monospace"><font face="monospace,monospace">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 </font><font face="monospace,monospace">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.<br><br></font>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:<br><br>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.<br></font><br></div><div><font face="monospace,monospace"> 1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]?<br></font></div></div></div></blockquote><div><br></div><div><font face="monospace,monospace">I do not believe that Poppy meets the definition of "Open Core". By most accounts, "Open Core" is a business or </font><font face="monospace,monospace"><font face="monospace,monospace">licensing </font>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.</font><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"></font></div><div><font face="monospace,monospace"> 2. Do we have a requirement that the primary component/backend (or at least one of the components/backends) </font><font face="monospace,monospace">driven/abstracted/orchestrated by a project (directly or via driver/plugin/et al) be considered Open Source? </font><font face="monospace,monospace"><font face="monospace,monospace">If yes, is there room for an exception when one simply doesn't exist? </font>Is there special consideration for "services" (ie. think  GPL vs. AGPL)?<br></font></div></div></div></blockquote><div><br></div><div><font face="monospace,monospace">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.</font><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"></font></div><div><font face="monospace,monospace"> 3. D</font><font face="monospace,monospace"><font face="monospace,monospace">oes a project that only enables the use of commercial services/projects belong in OpenStack?<br></font></font></div></div></div></blockquote><div><br><font face="monospace,monospace"></font><div><font face="monospace,monospace">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.</font></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"><font face="monospace,monospace"> 4.</font></font><font face="monospace,monospace"><font face="monospace,monospace"> Does Poppy violate existing requirements around testing/CI[7][8]?</font></font></div></div></div></blockquote><div><br></div><div><span style="font-family:monospace,monospace">I do not believe that it does. Using mocks and/or unit tests would be sufficient to meet "test-driven gate" requirement.<br></span></div><div><span style="font-family:monospace,monospace"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"><font face="monospace,monospace"> 5. Does dependency on Casandra make Poppy non-free?<br></font></font></div></div></div></blockquote><div><br></div><div><span style="font-family:monospace,monospace">TBD.</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"><font face="monospace,monospace"></font></font></div><div><font face="monospace,monospace"><font face="monospace,monospace"> 6. Does a project that only enables the use of non-OpenStack services/projects belong in OpenStack?<br></font></font></div></div></div></blockquote><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">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.</span><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><font face="monospace,monospace"><font face="monospace,monospace"></font></font></div><div><font face="monospace,monospace"></font></div><div><font face="monospace,monospace">Some additional facts that have been pointed out include:<br><br></font></div><div><font face="monospace,monospace"></font></div><div><font face="monospace,monospace"> - </font><font face="monospace,monospace"> 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].<br></font></div><div><font face="monospace,monospace"> - It currently only supports Rackspace DNS but support for Designate is planned[11] (only a stub exists in tree currently).</font><br></div></div></div></blockquote><div><br></div><div><span style="font-family:monospace,monospace">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.<br><br></span></div><div><span style="font-family:monospace,monospace">Cody</span><br></div></div></div></div>