Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model
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
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
[openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model
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? 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? [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
Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model
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
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
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
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
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
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
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
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
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
