On Fri, Oct 3, 2014 at 6:47 AM, Sean Dague <s...@dague.net> wrote:
> 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
> unit.


"Integration" in this sense (being part of that co-dependent group) is
actually a burden both on projects and on developers. Want to upgrade
Nova? Crap. I have to upgrade these other things too. Want to upgrade
Swift? Sure, that's easy.... just upgrade that one thing.

> 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
> --
> Sean Dague
> http://dague.net
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to