Open Stack

On Fri, Oct 3, 2014 at 1:33 PM, Eoghan Glynn <eglynn at redhat.com> wrote:
>
>
>> 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.

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


-Devananda

[1] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n6