So a bit of background here. This began from thinking about functional dependencies, and pondering whether a map of the dependency graph of our projects could inform our gating structure, specifically to encourage (or dare I say, actually force) all of us (the project teams) to become more cognizant of the API contracts we are making with each other, and the pain it causes when we break those contracts.
Let's not extend this exercise to a gigantic everything-needs-everything-to-do-everything picture, which is where it's heading now. Sure, telemetry is important for operators, and in no way am I saying anything else when I say: for Nova to fulfill its primary goal, telemetry is not necessary. It is optional. Desired, but optional. Even saying "nova CAN-USE ceilometer" is incorrect, though, since Nova isn't actually using Ceilometer to accomplish any functional task within it's domain. More correct would be to say "Ceilometer CAN-ACCEPT notifications FROM Nova". Incidentally, this is very similar to the description of Heat and Horizon, except that, instead of consuming a public API, Ceilometer is consuming something else (internal notifications). -Deva On Fri, Oct 3, 2014 at 10:38 AM, Chris Dent <chd...@redhat.com> wrote: > On Fri, 3 Oct 2014, Joe Gordon wrote: > >> data is coming from here: >> https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml >> and the key is here: https://github.com/jogo/graphing-openstack > > > Cool, thanks. > >>> Many of those services expect[1] to be able to send notifications (or >>> be polled by) ceilometer[2]. We've got an ongoing thread about the need >>> to contractualize notifications. Are those contracts (or the desire >>> for them) a form of dependency? Should they be? >>> >> >> So in the case of notifications, I think that is a Ceilometer CAN-USE Nova >> THROUGH notifications > > > Your statement here is part of the reason I asked. I think it is > possible to argue that the dependency has the opposite order: Nova might > like to use Ceilometer to keep metrics via notifications or perhaps: > Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling. > > This is perhaps not the strict technological representation of the > dependency, but it represents the sort of pseudo-social > relationships between projects: Nova desires for Ceilometer (or at > least something doing telemetry) to exist. > > Ceilometer itself is^wshould be agnostic about what sort of metrics are > coming its way. It should accept them, potentially transform them, store > them, and make them available for later use (including immediately). It > doesn't^wshouldn't really care if Nova exists or not. > > There are probably lots of other relationships of this form between > other services, thus the question: Is a use-of-notifications > something worth tracking? I would say yes. > > > -- > Chris Dent tw:@anticdent freenode:cdent > https://tank.peermore.com/tanks/cdent > > _______________________________________________ > 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
