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.

I don't follow the optional-but-not-necessary argument here, or
where you're applying the cut-off for the graph not turning into
a gigantic picture.

There were a bunch of relationships in the original graph that
are not strictly necessary for nova to fulfill it's primary goal,
but are desired and existing functional dependencies in any case.

So, are we trying to capture all dependencies here, or to apply
some value-judgement and selectively capture just the good
dependencies, for some definition of good?

> 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).

In addition to consuming notifications from nova, ceilometer also
calls out to the public nova, keystone, glance, neutron, and swift
APIs.

Hence: ceilometer CANUSE [nova, keystone, glance, neutron, swift].

In addition, the ceilometer API is invoked by heat and horizon.

I've submitted a pull request with these relationships, neglecting
the consumes-notifications-from relationship for now.

Cheers,
Eoghan

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