[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore
vishvananda at gmail.com
Mon Jun 30 16:53:34 UTC 2014
On Jun 29, 2014, at 7:19 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 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?”).
+1 to this. This seems to be a much clearer position. Thank you for pointing
out the elephant and addressing it directly.
>> 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.
> Foundation mailing list
> Foundation at lists.openstack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Foundation