Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-06 Thread Eoghan Glynn

  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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-04 Thread Chris Dent

On Fri, 3 Oct 2014, Devananda van der Veen wrote:


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]


So while I agree with the usefulness of being able to describe these
technical dependencies for minimal satisfaction and agree that it is a
useful tool for creating boundaries and compartments for testing, the
reason I started the subthread is because I think this form of statement

   I'm describing [...] for [...] of a given _project_.

is prejudicing a certain set of priorities and perspectives which over
the long term are damaging to the health of the larger ecosystem (the
big tent or whatever it is), especially in terms of satisfying people
other than us haute dev types.

It's pretty clear everyone's intentions are pretty much in the right and
similar place, but there's some friction over language and details. The
tribalism associated with project appears to contribute:

* to getting people off track a bit
* keeping us in technical solutions when what we need are both technical
  solutions and organizational/social solutions

Presumably (I wasn't there to see it) the program/project distinction
was an effort to overcome this, but it hasn't worked. Of course not,
you don't gain much if you have people in a room with name A and all
you do is put a new name on the room and don't change the people or
the room.

We need to do more this time around than change some names.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Joe Gordon
On Fri, Oct 3, 2014 at 9:51 AM, Chris Dent chd...@redhat.com wrote:

 On Fri, 3 Oct 2014, Joe Gordon wrote:

  * services that nothing depends on
 * services that don't depend on other services

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


 I'm hesitant to open this can but it's just lying there waiting,
 wiggling like good bait, so:

 How are you defining dependency in that picture?


data is coming from here:
https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
and the key is here: https://github.com/jogo/graphing-openstack

Note ceilometer has no relationships because I wasn't sure what exactly
they were (which were required and which are optional etc.), not because
there are none. It turns out its not easy to find this information in an
easily digestible format.


 For example:

 Many of those services expect[1] to be able to send notifications (or
 be polled by) ceilometer[2]. We've got an ongoing thread about the need
 to contractualize notifications. Are those contracts (or the desire
 for them) a form of dependency? Should they be?


So in the case of notifications, I think that is a Ceilometer CAN-USE Nova
THROUGH notifications




 [1] It's not that it is a strict requirement but lots of people involved
 with the other projects contribute code to ceilometer or make
 changes in their own[3] project specifically to send info to
 ceilometer.

 [2] I'm not trying to defend ceilometer from slings here, just point out
 a good example, since it has _no_ arrows.

 [3] their own, that's hateful, let's have less of that.

 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Chris Dent

On Fri, 3 Oct 2014, Joe Gordon wrote:


data is coming from here:
https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
and the key is here: https://github.com/jogo/graphing-openstack


Cool, thanks.


Many of those services expect[1] to be able to send notifications (or
be polled by) ceilometer[2]. We've got an ongoing thread about the need
to contractualize notifications. Are those contracts (or the desire
for them) a form of dependency? Should they be?



So in the case of notifications, I think that is a Ceilometer CAN-USE Nova
THROUGH notifications


Your statement here is part of the reason I asked. I think it is
possible to argue that the dependency has the opposite order: Nova might
like to use Ceilometer to keep metrics via notifications or perhaps:
Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling.

This is perhaps not the strict technological representation of the
dependency, but it represents the sort of pseudo-social
relationships between projects: Nova desires for Ceilometer (or at
least something doing telemetry) to exist.

Ceilometer itself is^wshould be agnostic about what sort of metrics are
coming its way. It should accept them, potentially transform them, store
them, and make them available for later use (including immediately). It
doesn't^wshouldn't really care if Nova exists or not.

There are probably lots of other relationships of this form between
other services, thus the question: Is a use-of-notifications
something worth tracking? I would say yes.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Chris Friesen

On 10/03/2014 11:38 AM, Chris Dent wrote:

On Fri, 3 Oct 2014, Joe Gordon wrote:



Many of those services expect[1] to be able to send notifications (or
be polled by) ceilometer[2]. We've got an ongoing thread about the need
to contractualize notifications. Are those contracts (or the desire
for them) a form of dependency? Should they be?



So in the case of notifications, I think that is a Ceilometer CAN-USE
Nova
THROUGH notifications


Your statement here is part of the reason I asked. I think it is
possible to argue that the dependency has the opposite order: Nova might
like to use Ceilometer to keep metrics via notifications or perhaps:
Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling.

This is perhaps not the strict technological representation of the
dependency, but it represents the sort of pseudo-social
relationships between projects: Nova desires for Ceilometer (or at
least something doing telemetry) to exist.


This may be quibbling, but I would suggest that it is the end-user that 
may want something doing telemetry to exist.


Nova proper doesn't really care about telemetry.  Nova exports telemetry 
because end-users want the information to be available for use by other 
services.  Nova itself doesn't actually make use of it or call out to 
services that make use of it.


Now something like Heat really depends on telemetry.  It wants to know 
if an instance didn't kick the watchdog timer, or if the webserver keeps 
crashing, or other information provided by telemetry.



Ceilometer itself is^wshould be agnostic about what sort of metrics are
coming its way. It should accept them, potentially transform them, store
them, and make them available for later use (including immediately). It
doesn't^wshouldn't really care if Nova exists or not.

There are probably lots of other relationships of this form between
other services, thus the question: Is a use-of-notifications
something worth tracking? I would say yes.


Sure, because those notifications are a form of API and those should be 
versioned and tracked appropriately. Nova can't arbitrarily change the 
format of the notifications it sends out because that would break anyone 
that cares about the contents of those notifications.


Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Devananda van der Veen
On Fri, Oct 3, 2014 at 11:18 AM, Chris Friesen
chris.frie...@windriver.com wrote:
 On 10/03/2014 11:38 AM, Chris Dent wrote:

 On Fri, 3 Oct 2014, Joe Gordon wrote:


 Many of those services expect[1] to be able to send notifications (or
 be polled by) ceilometer[2]. We've got an ongoing thread about the need
 to contractualize notifications. Are those contracts (or the desire
 for them) a form of dependency? Should they be?


 So in the case of notifications, I think that is a Ceilometer CAN-USE
 Nova
 THROUGH notifications


 Your statement here is part of the reason I asked. I think it is
 possible to argue that the dependency has the opposite order: Nova might
 like to use Ceilometer to keep metrics via notifications or perhaps:
 Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling.

 This is perhaps not the strict technological representation of the
 dependency, but it represents the sort of pseudo-social
 relationships between projects: Nova desires for Ceilometer (or at
 least something doing telemetry) to exist.


 This may be quibbling, but I would suggest that it is the end-user that may
 want something doing telemetry to exist.

 Nova proper doesn't really care about telemetry.  Nova exports telemetry
 because end-users want the information to be available for use by other
 services.  Nova itself doesn't actually make use of it or call out to
 services that make use of it.

Yup.

 Now something like Heat really depends on telemetry.  It wants to know if an
 instance didn't kick the watchdog timer, or if the webserver keeps crashing,
 or other information provided by telemetry.


Now that is a really good point. /me tosses up a pull request for that change.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Devananda van der Veen
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.

Even saying nova CAN-USE ceilometer is incorrect, though, since Nova
isn't actually using Ceilometer to accomplish any functional task
within it's domain. More correct would be to say Ceilometer
CAN-ACCEPT notifications FROM Nova. Incidentally, this is very
similar to the description of Heat and Horizon, except that, instead
of consuming a public API, Ceilometer is consuming something else
(internal notifications).

-Deva

On Fri, Oct 3, 2014 at 10:38 AM, Chris Dent chd...@redhat.com wrote:
 On Fri, 3 Oct 2014, Joe Gordon wrote:

 data is coming from here:
 https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
 and the key is here: https://github.com/jogo/graphing-openstack


 Cool, thanks.

 Many of those services expect[1] to be able to send notifications (or
 be polled by) ceilometer[2]. We've got an ongoing thread about the need
 to contractualize notifications. Are those contracts (or the desire
 for them) a form of dependency? Should they be?


 So in the case of notifications, I think that is a Ceilometer CAN-USE Nova
 THROUGH notifications


 Your statement here is part of the reason I asked. I think it is
 possible to argue that the dependency has the opposite order: Nova might
 like to use Ceilometer to keep metrics via notifications or perhaps:
 Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling.

 This is perhaps not the strict technological representation of the
 dependency, but it represents the sort of pseudo-social
 relationships between projects: Nova desires for Ceilometer (or at
 least something doing telemetry) to exist.

 Ceilometer itself is^wshould be agnostic about what sort of metrics are
 coming its way. It should accept them, potentially transform them, store
 them, and make them available for later use (including immediately). It
 doesn't^wshouldn't really care if Nova exists or not.

 There are probably lots of other relationships of this form between
 other services, thus the question: Is a use-of-notifications
 something worth tracking? I would say yes.


 --
 Chris Dent tw:@anticdent freenode:cdent
 https://tank.peermore.com/tanks/cdent

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Eoghan Glynn


 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?

 Even saying nova CAN-USE ceilometer is incorrect, though, since Nova
 isn't actually using Ceilometer to accomplish any functional task
 within it's domain. More correct would be to say Ceilometer
 CAN-ACCEPT notifications FROM Nova. Incidentally, this is very
 similar to the description of Heat and Horizon, except that, instead
 of consuming a public API, Ceilometer is consuming something else
 (internal notifications).

In addition to consuming notifications from nova, ceilometer also
calls out to the public nova, keystone, glance, neutron, and swift
APIs.

Hence: ceilometer CANUSE [nova, keystone, glance, neutron, swift].

In addition, the ceilometer API is invoked by heat and horizon.

I've submitted a pull request with these relationships, neglecting
the consumes-notifications-from relationship for now.

Cheers,
Eoghan

 -Deva
 
 On Fri, Oct 3, 2014 at 10:38 AM, Chris Dent chd...@redhat.com wrote:
  On Fri, 3 Oct 2014, Joe Gordon wrote:
 
  data is coming from here:
  https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
  and the key is here: https://github.com/jogo/graphing-openstack
 
 
  Cool, thanks.
 
  Many of those services expect[1] to be able to send notifications (or
  be polled by) ceilometer[2]. We've got an ongoing thread about the need
  to contractualize notifications. Are those contracts (or the desire
  for them) a form of dependency? Should they be?
 
 
  So in the case of notifications, I think that is a Ceilometer CAN-USE Nova
  THROUGH notifications
 
 
  Your statement here is part of the reason I asked. I think it is
  possible to argue that the dependency has the opposite order: Nova might
  like to use Ceilometer to keep metrics via notifications or perhaps:
  Nova CAN-USE Ceilometer FOR telemetry THROUGH notifications and polling.
 
  This is perhaps not the strict technological representation of the
  dependency, but it represents the sort of pseudo-social
  relationships between projects: Nova desires for Ceilometer (or at
  least something doing telemetry) to exist.
 
  Ceilometer itself is^wshould be agnostic about what sort of metrics are
  coming its way. It should accept them, potentially transform them, store
  them, and make them available for later use (including immediately). It
  doesn't^wshouldn't really care if Nova exists or not.
 
  There are probably lots of other relationships of this form between
  other services, thus the question: Is a use-of-notifications
  something worth tracking? I would say yes.
 
 
  --
  Chris Dent tw:@anticdent freenode:cdent
  https://tank.peermore.com/tanks/cdent
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Chris Friesen

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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Devananda van der Veen
On Fri, Oct 3, 2014 at 1:33 PM, Eoghan Glynn egl...@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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Devananda van der Veen
On Fri, Oct 3, 2014 at 2:13 PM, Chris Friesen
chris.frie...@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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev