Open Stack

On Fri, Oct 3, 2014 at 2:13 PM, Chris Friesen
<chris.friesen at windriver.com> wrote:
> 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.
>

Yep, exactly.

And conversely, if a change in Nova *did* break
ceilometer/heat/trove/ironic/zaqar/etc, well, *shit*, someone screwed
up. Either we just broke an API contract in Nova and we should
immediately revert that, or someone was depending on an unstable API
that they shouldn't have been, or they were depending on undocumented
behavior which they really shouldn't have been. But in every case, we,
the developers, did something bad, and should fix it.

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

++

What I'm proposing moves us towards this, but I don't think we're
ready for it today.


Cheers,
Devananda