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.
> >
> 
> For nova to do anything useful at all, it very simply needs an
> identity service (keystone), an image registry service (glance), and a
> network service (neutron (ignoring the fact that nova-network is still
> there because we actually want it to go away)). Without these, Nova is
> utterly useless.
> 
> So, from a minimalist compute-centric perspective, THAT'S IT.

Sure, I get that idea of isolating the minimal set of dependencies
for the compute use-case.

I was questioning the fact the dependency graph referenced on the
thread earlier:

  http://i.imgur.com/y8zmNIM.png

selectively included *some* dependencies that lay outside this narrow
use-case for nova, but not others.

> > 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?
> 
> Nope. I am not making any value judgement whatsoever. I'm describing
> dependencies for minimally satisfying the intended purpose of a given
> project. For example, Nova's primary goal is not "emit telemetry", it
> is "scalable, on demand, self service access to compute resources" [1]
> 
> There are a lot of other super-awesome additional capabilities for
> which Nova depends on other services. And folks want to add more cool
> things on top of, next to, and underneath this "ring compute". And
> make new non-compute-centric groups of projects. That's all wonderful.
> 
> I happen to also fall in that camp - I think Ironic is a useful
> service, but I'm happy for it to not be in that inner ring of
> codependency. The nova.virt.ironic driver is optional from Nova's POV
> (Nova works fine without it), and Nova is optional from Ironic's POV
> (it's a bit awkward, but Ironic can deploy without Nova, though we're
> not testing it like that today).
> 
> On the other hand, from a minimalist telemetry-centric perspective,
> what other projects do I need to run Ceilometer? Correct me if I'm
> wrong, but I think the answer is "None".

At the very least, ceilometer would need keystone to function.

> Or rather, which ever ones I
> want. If I'm running Nova and not running Swift, Ceilometer works with
> Nova. If I'm running Swift but not Nova, Ceilometer works with Swift.
> There's no functional dependency on either Nova or Swift here - it's
> just consumption of an API. None of which is bad - but this informs
> how we gate test these projects, and how we allocate certain resources
> (like debugging gate-breaking bugs) across projects.

OK, so if project A doesn't *need* project B to function minimally,
but will use if it's available, and it's likely to be so in most
realistic deployments, then we still need to ensure somehow that
changes in project B don't break project A.

i.e. even if the dependency isn't a strict necessity, it may still
very likely be an actual reality in practice.

Cheers,
Eoghan