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
