Open Stack

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 <chdent at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev