Open Stack

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?").

> 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.