Open Stack

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.
>> 
>>  https://etherpad.openstack.org/p/DefCoreLighthouse.F2F
>> 
>>  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
>>  sections.
>> 
>>  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
>> anyway.
> 
> In the case of Swift, the strawman from the Board (or DefCore) might be:
> 
>  The following capabilities should be required of OpenStack clouds:
> 
>    objectstore-container
>    objectstore-container-quota
>    objectstore-container-acl
>    objectstore-acct-services
>    objectstore-container-staticweb
> 
>  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 
>  pluggable.
> 
> 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.

Vish

> 
>> 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.
> 
> Mark.
> 
> 
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140630/f1751595/attachment.pgp>