On 10/03/2014 09:25 AM, Anne Gentle wrote:
> On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann <d...@doughellmann.com
> <mailto:d...@doughellmann.com>> wrote:
>     On Oct 3, 2014, at 12:46 AM, Joe Gordon <joe.gord...@gmail.com
>     <mailto:joe.gord...@gmail.com>> wrote:
>>     On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen
>>     <devananda....@gmail.com <mailto:devananda....@gmail.com>> wrote:
>>         On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann
>>         <d...@doughellmann.com <mailto:d...@doughellmann.com>> wrote:
>>         > As promised at this week’s TC meeting, I have applied the various 
>> blog posts and mailing list threads related to changing our governance model 
>> to a series of patches against the openstack/governance repository [1].
>>         >
>>         > I have tried to include all of the inputs, as well as my own 
>> opinions, and look at how each proposal needs to be reflected in our current 
>> policies so we do not drop commitments we want to retain along with the 
>> processes we are shedding [2].
>>         >
>>         > I am sure we need more discussion, so I have staged the changes as 
>> a series rather than one big patch. Please consider the patches together 
>> when commenting. There are many related changes, and some incremental steps 
>> won’t make sense without the changes that come after (hey, just like code!).
>>         >
>>         > Doug
>>         >
>>         > [1] 
>> https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z
>>         > [2] https://etherpad.openstack.org/p/big-tent-notes
>>         I've summed up a lot of my current thinking on this etherpad
>>         as well
>>         (I should really blog, but hey ...)
>>         https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy
>>     After seeing Jay's idea of making a yaml file modeling things and
>>     talking to devananda about this I went ahead and tried to graph
>>     the relationships out.
>>     repo: https://github.com/jogo/graphing-openstack
>>     preliminary YAML
>>     file: 
>> https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
>>     sample graph: http://i.imgur.com/LwlkE73.png
>>     It turns out its really hard to figure out what the relationships
>>     are without digging deep into the code for each project, so I am
>>     sure I got a few things wrong (along with missing a lot of projects).
>     The relationships are very important for setting up an optimal gate
>     structure. I’m less convinced they are important for setting up the
>     governance structure, and I do not think we want a specific gate
>     configuration embedded in the governance structure at all. That’s
>     why I’ve tried to describe general relationships (“optional
>     inter-project dependences” vs. “strict co-dependent project groups”
>     [1]) up until the very last patch in the series [2], which redefines
>     the integrated release in terms of those other relationships and a
>     base set of projects.
> I'm reading and reading and reading and my thoughts keep returning to,
> "we're optimizing only for dev." :)
> I need to either get over that or decide what parts need tweaking for
> docs and support optimization. I'll get going on reviews -- thanks a
> bunch for all this compilation and for the good blog writing. Much
> appreciated.

The relationships are also quite important for deployment units, because
we're talking about what minimal set of things we're going to say work
together. And we're going to be dictating the minimum lock step upgrade

Any project that fully stands on it's own (like Swift or Ironic, given
that keystone is optional) can be stood up on their own. Ok, they go in
one bucket and you call tell people, you want this function, just
install this project, it's a vertical on it's own. Heat works quite well
against a compute stack you don't run yourself (teams doing this in HP
all the time). I expect Zaqar to be like Swift, and be a thing you can
just have.

That's not the case for the compute stack, for better or worse. And,
based on the User Surveys, the compute stack is what most people are
trying to get out of OpenStack right now. So we should unconfuse that,
create a smaller basic building block (that people can understand), and
provide guidance on how you could expand your function with our vast
array of great expansion sets.

OpenStack is enough parts that you can mix and match as much as you
want, but much like the 600 config options in Nova, we really can't
document every combination of things.


Sean Dague

OpenStack-dev mailing list

Reply via email to