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. >
Yes "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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
