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
