[OpenStack-DefCore] [OpenStack Foundation] Understanding DefCore
markmc at redhat.com
Sun Jun 29 14:19:49 UTC 2014
On Sun, 2014-06-29 at 14:34 +0100, Mark McLoughlin wrote:
> On Wed, 2014-06-25 at 13:57 -0500, Mark Collier wrote:
> > The question that is raised when we consider going below 100% of a
> > particular project, is do you eventually consider 0%, as long as the
> > APIs are implemented? Let’s say, hypothetically, your product or
> > cloud service exposes the Swift API but uses an alternative back end,
> > say Ceph for example. Is that still “OpenStack”? Let’s face it,
> > that’s the question on a lot of people’s minds. The Defcore committee
> > has approached these questions holistically by starting with
> > documenting criteria for making such weighty decisions.
> I think the criteria for deciding which API capabilities are required
> has been well documented and looks to be giving a very reasonable
> outcome. However, the process for deciding "designated sections" looks
> increasingly backwards to me.
A fair question would be "what do you think is a not-backwards process
for answering the question of what code should be required under the
OpenStack Powered trademark license?"
Given that the board is the deciding body for that question, but they/we
are looking for the widest possible consultation on it, how about:
* The Board comes up with a very rough strawman set of "required
code" based on its very rough understanding of the technical
architecture and the current commercial ecosystem. It could be the
Defcore committee delegated to draft this strawman and the
"required code" could still be called "designated sections"
* The wider community (including the TC and PTLs) is asked to give its
input in the form of questions - i.e. "what are we missing?"
* The Board openly answers those questions (perhaps DefCore triages
and answers the straightforward ones) and those answers effectively
determine the final "required code" policy.
> In the case of Swift, the conclusion so far seems to be that certain
> Swift APIs could be considered required capabilities, but *only if* the
> TC decides that 0% of Swift's code is designated.
> Picking designated sections for Swift > we are in a position to choose
> 0 or 100 without any intermdiate.
> DefCore agrees that the TC is the deciding body for designated
> Official position, DefCore asks TC to resolve Swift D.S. question.
> ACTION > Rob to take to TC that if Swift has any designated sections
> then the DefCore committee will likely recommending omitting the
> "object-*" capabilities from core.
> i.e. that DefCore sees that it is impossible for the "OpenStack Powered"
> trademark license to require the use of any Swift code, and that if the
> TC thinks any code should be required then DefCore will recommend that
> no APIs are required, effectively resulting in no code being required
In the case of Swift, the strawman from the Board (or DefCore) might be:
The following capabilities should be required of OpenStack clouds:
However, there are several commercial OpenStack products which
provide a faithful implementation of these capabilities without using
any of Swift's code. Given the way Swift is designed, we do not think
these products could be required to use a subset of Swift's code
without forcing them to choose between using all of Swift's code or
losing their license to use the "OpenStack Powered" trademark. We
feel many of these products are high-quality, valued parts of the
OpenStack ecosystem and deserve to be able to describe themselves as
"OpenStack Powered". For that reason, we feel that the trademark
license agreement should not require the use of any Swift code but we
will review this situation each release as Swift evolves to be more
The wider community would be invited to ask whether certain technical
details had been considered (e.g. "have you considered requiring xyz
part of Swift's API layer, since it's possible to plug any other object
storage system behind that?").
> The starting assumption that "the TC is the deciding body for designated
> sections" just seems (and has always seemed) wrong to me, particularly
> if it results in the Board removing capabilities from the "required
> capabilities" list because the Board disagrees with the TC's opinion
> that the code for those APIs should be required.
What I'm suggesting above as a process more accurately reflects the TC
and PTLs involvement here. There is a default position (e.g. no Swift
code can be required) based on an (incomplete?) technical understanding
and a (hopefully) pretty complete understanding of the commercial
ecosystem. The TC and PTLs are effectively being asked to provide some
technical oversight to make sure important technical details aren't
being missed. It's important that the wider community is invited to
participate in that technical oversight, since the TC and PTLs may not
even be the most motivated to provide thoughtful assistance on this.
More information about the Defcore-committee