Open Stack

On 07/11/2013 01:10 PM, Joshua McKenty wrote:
> And now we get to the meat of the matter. The original definition of
> FITS was as a joint effort by the TC and the board - since it's as
> inappropriate for the TC to define "interoperability" outside of board
> involvement, as it is for the board to determine the architecture
> required to be considered a "plugin".
> 
> The only mechanism that the foundation (being the TC, the Board, and the
> User Committee, as well as the larger member body) has to enforce
> interoperability, is the trademark policy. But the decisions of which
> features, components, etc. *must* or *may* be supported in a given
> product or service in order to wear a particular mark, are primarily a
> business decision - despite the technical details.
> 
> As a final caveat, while the TC approves a single integrated release, I
> suspect the board will continue to authorize a set of marks to be
> applied to services and products - although I imagine the current
> "OpenStack Storage", "OpenStack Compute", "Powered By" and "Built For"
> will likely expand and evolve.

Yup. I agree with all of the above. I think the real trick around
requirements is not unique to here. We've all dealt with product
managers who try to dictate implementation too much - I regularly work
with theatre directors who give me notes like "I really want some red
light in this scene" when what they _should_ be telling me is "the main
character is having a climactic crisis at this moment that I'd really
like to drive home" The second let's me do my job as a lighting
designer, and amusingly enough is actually closer to the way the
director is thinking about the problem in the first place

So, the TC needs from the board the requirements, the definitions of the
problem, the REAL thing we're trying to do. Does the board care about
plugins or API extensions? No. The board wants to ensure that vendors
can deliver products related to openstack in a particular manner. And
actually, the discussion around what we want that to look like, outside
of technical implementation of how we achieve it, is super interesting.

Do we, for instance, want vendors to be able to deploy a cloud, call it
OpenStack, and present a different interface to the user? An API
extension is an implementation of a way to allow people to run openstack
clouds with divergent interfaces. Another way is via discoverable
capabilities. Alternately, the board could decide, NOPE, 4 clouds with 4
different interfaces do not help the business goals of OpenStack, we do
not want that. If the board made that decision, the TC would need to
figure out what that means for the kvm/xen divergence and things like
metadata vs. configdrive vs injections - which are all different
end-user interfaces.

The board and the TC each have super important roles here, and I
definitely agree we need to work together on them.


> --
> 
> Joshua McKenty
> Chief Technology Officer
> Piston Cloud Computing, Inc.
> +1 (650) 242-5683
> +1 (650) 283-6846
> http://www.pistoncloud.com
> 
> "Oh, Westley, we'll never survive!"
> "Nonsense. You're only saying that because no one ever has."
> 
> On Jul 11, 2013, at 9:56 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
> 
>>
>>
>> On 07/11/2013 12:39 PM, Thierry Carrez wrote:
>>> Russell Bryant wrote:
>>>> On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com
>>>> <mailto:Rob_Hirschfeld at Dell.com> wrote:
>>>>> Background info:
>>>>> https://etherpad.openstack.org/Board-2013-SpiderDiscussion
>>>>
>>>> This is the first time I've seen this.  I must admit that my initial
>>>> reaction is that I'm not comfortable with the direction this seems to be
>>>> taking.
>>>>
>>>> I understand the need to have a solid definition of what "core" means.
>>>> I also assume that the goal here is to eventually arrive at some set of
>>>> definitions and policies.
>>>>
>>>> However, some of the specific items discussed on this etherpad are
>>>> things that are in my opinion, in TC (or even project specific
>>>> governance) territory, and should be considered out of scope for any
>>>> policy coming from the board.
>>>
>>> This is new to me too, but AFAICT it's an effort to define the list of
>>> criteria the board intends to apply for granting the "core" label on a
>>> given project.
>>>
>>> We ruled that the TC was free to produce the stuff it wanted, and that
>>> the board was free to apply a "core" label to a subset of that. they are
>>> also free to define what they mean by "core" (or any other label they
>>> may want to create).
>>>
>>> As an example:
>>>
>>>> * In the introduction, the secondary issue identified is whether
>>>> projects should be pluggable.  I believe this is TC territory.
>>>
>>> If they want to grant the "core" label only to pluggable projects, I'm
>>> not sure that would be in our territory ?
>>
>> No, I believe Russell is correct, and I'm sorry I did not catch/raise
>> this earlier. The reason we have a board/tc split is separation of
>> specialty. It is not expected that people on the board have the
>> technical background to make technical decisions, it is conversely not
>> expected that members of the TC have the business/legal background to
>> make decisions on issues around brand or trademark. That some of us on
>> the board have technical backgrounds is a thing I think we must be
>> vigilant about and not forget the role we have been asked to play on
>> that body. In that regard, I believe I have failed at the moment.
>>
>> The split between integrated and core is similarly intended to let the
>> technical body decide about implementation issues and let the board make
>> decisions on the *what*, as Russel says. While the language may
>> theoretically allow the board to apply whatever criteria it wants to to
>> grant the core label, I think it's very important we don't create a
>> shadow TC of folks making additional technical judgment calls and using
>> trademark to enforce them. It's not an us vs. them thing - it's quite
>> simply a scope-of-body-of-people thing. If both bodies have 'final' say
>> on a technical matter but with a different label, no one anywhere is
>> going to be able to figure out what the heck OpenStack is.
>>
>> Back to the matter at hand, I think Doug's suggestions move in the
>> direction of where the language should go.
>>
>> "The cloud must pass the automated test suite designated by the TC as
>> defining interoperability"
>>
>> both states an outcome the board wants to see, and lets the TC decide.
>> I'd even remove the word 'automated' - although I'm _certain_ that the
>> TC would want it to be automated and not manual. That sentence above is
>> actually quite similar to one that's in our current trademark policy, btw.
>>
>>
>> _______________________________________________
>> Foundation-board mailing list
>> Foundation-board at lists.openstack.org
>> <mailto:Foundation-board at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board
>