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