<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 3, 2014 at 9:42 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
----- Original Message -----<br>
><br>
><br>
> On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann < <a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
> On Oct 3, 2014, at 12:46 AM, Joe Gordon < <a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen <<br>
> <a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a> > wrote:<br>
><br>
><br>
> On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann < <a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a> ><br>
> wrote:<br>
> > As promised at this week’s TC meeting, I have applied the various blog<br>
> > posts and mailing list threads related to changing our governance model to<br>
> > a series of patches against the openstack/governance repository [1].<br>
> ><br>
> > I have tried to include all of the inputs, as well as my own opinions, and<br>
> > look at how each proposal needs to be reflected in our current policies so<br>
> > we do not drop commitments we want to retain along with the processes we<br>
> > are shedding [2].<br>
> ><br>
> > I am sure we need more discussion, so I have staged the changes as a series<br>
> > rather than one big patch. Please consider the patches together when<br>
> > commenting. There are many related changes, and some incremental steps<br>
> > won’t make sense without the changes that come after (hey, just like<br>
> > code!).<br>
> ><br>
> > Doug<br>
> ><br>
> > [1]<br>
> > <a href="https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z</a><br>
> > [2] <a href="https://etherpad.openstack.org/p/big-tent-notes" target="_blank">https://etherpad.openstack.org/p/big-tent-notes</a><br>
><br>
> I've summed up a lot of my current thinking on this etherpad as well<br>
> (I should really blog, but hey ...)<br>
><br>
> <a href="https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy" target="_blank">https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy</a><br>
><br>
><br>
> After seeing Jay's idea of making a yaml file modeling things and talking to<br>
> devananda about this I went ahead and tried to graph the relationships out.<br>
><br>
> repo: <a href="https://github.com/jogo/graphing-openstack" target="_blank">https://github.com/jogo/graphing-openstack</a><br>
> preliminary YAML file:<br>
> <a href="https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml" target="_blank">https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml</a><br>
> sample graph: <a href="http://i.imgur.com/LwlkE73.png" target="_blank">http://i.imgur.com/LwlkE73.png</a><br>
> It turns out its really hard to figure out what the relationships are without<br>
> digging deep into the code for each project, so I am sure I got a few things<br>
> wrong (along with missing a lot of projects).<br>
><br>
> The relationships are very important for setting up an optimal gate<br>
> structure. I’m less convinced they are important for setting up the<br>
> governance structure, and I do not think we want a specific gate<br>
> configuration embedded in the governance structure at all. That’s why I’ve<br>
> tried to describe general relationships (“optional inter-project<br>
> dependences” vs. “strict co-dependent project groups” [1]) up until the very<br>
> last patch in the series [2], which redefines the integrated release in<br>
> terms of those other relationships and a base set of projects.<br>
><br>
><br>
> I agree the relationships are very important for gate structure and less so<br>
> for governance. I thought it would be nice to codify the relationships in a<br>
> machine readable format so we can do things with it, like try making<br>
> different rules and see how they would work. For example we can already make<br>
> two groups of things that may be useful for testing:<br>
><br>
> * services that nothing depends on<br>
> * services that don't depend on other services<br>
><br>
> Latest graph: <a href="http://i.imgur.com/y8zmNIM.png" target="_blank">http://i.imgur.com/y8zmNIM.png</a><br>
<br>
</div></div>This diagram is missing any relationships for ceilometer.<br></blockquote><div><br></div><div>It sure is, the graph is very much a work in progress. Here is the yaml that generates it <a href="https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml">https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml</a> want to update that to includes ceilometer's relationships?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Ceilometer calls APIs provided by:<br>
<br>
* keystone<br>
* nova<br>
* glance<br>
* neutron<br>
* swift<br>
<br>
Ceilometer consumes notifications from:<br>
<br>
* keystone<br>
* nova<br>
* glance<br>
* neutron<br>
* cinder<br>
* ironic<br>
* heat<br>
* sahara<br>
<br>
Ceilometer serves incoming API calls from:<br>
<br>
* heat<br>
* horizon<br>
<br>
Cheers,<br>
Eoghan<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>