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