----- Original Message ----- > > > On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann < [email protected] > > wrote: > > > > > On Oct 3, 2014, at 12:46 AM, Joe Gordon < [email protected] > wrote: > > > > > > On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen < > [email protected] > wrote: > > > On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann < [email protected] > > 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 agree the relationships are very important for gate structure and less so > for governance. I thought it would be nice to codify the relationships in a > machine readable format so we can do things with it, like try making > different rules and see how they would work. For example we can already make > two groups of things that may be useful for testing: > > * services that nothing depends on > * services that don't depend on other services > > Latest graph: http://i.imgur.com/y8zmNIM.png
This diagram is missing any relationships for ceilometer. Ceilometer calls APIs provided by: * keystone * nova * glance * neutron * swift Ceilometer consumes notifications from: * keystone * nova * glance * neutron * cinder * ironic * heat * sahara Ceilometer serves incoming API calls from: * heat * horizon Cheers, Eoghan _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
