Open Stack

On 10/03/2014 02:33 PM, Eoghan Glynn 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.
>
> 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?

I would suggest that we look at things from the point of view of what 
the component needs in order to accomplish its goals.

As an example, for nova to do anything useful it needs 
neutron/keystone/glance.

If the end-user wants persistent block storage, then nova needs cinder.

If the end-user wants object storage, then nova needs swift.

For heat to be really useful it needs both ceilometer and nova.


On the other hand, nova doesn't *need* 
ceilometer/heat/trove/ironic/zaqar) for anything.


In terms of integration testing, this means that a change within 
ceilometer/heat/trove/ironic/zaqar/etc. that breaks them should not 
block submissions to nova.  On the other hand a change within neutron 
that breaks it probably will block submissions to nova.

On the flip side, it may be beneficial for 
ceilometer/heat/trove/ironic/zaqar/etc. to develop against a stable 
snapshot of nova/neutron/keystone/glance so that they're isolated 
against changes that break them.  (Though they may want to run 
integration tests against the most recent versions to catch API breakage 
early.)

Chris