Open Stack

----- Original Message -----
> 
> 
> On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann < doug at doughellmann.com >
> wrote:
> 
> 
> 
> 
> On Oct 3, 2014, at 12:46 AM, Joe Gordon < joe.gordon0 at gmail.com > wrote:
> 
> 
> 
> 
> 
> On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen <
> devananda.vdv at gmail.com > wrote:
> 
> 
> On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann < doug at 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 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