Excerpts from Day, Phil's message of 2014-04-08 03:03:41 -0700: > > -----Original Message----- > > From: Robert Collins [mailto:robe...@robertcollins.net] > > Sent: 07 April 2014 21:01 > > To: OpenStack Development Mailing List > > Subject: [openstack-dev] [TripleO] config options, defaults, oh my! > > > > So one interesting thing from the influx of new reviews is lots of patches > > exposing all the various plumbing bits of OpenStack. This is good in some > > ways (yay, we can configure more stuff), but in some ways its kindof odd - > > like - its not clear when https://review.openstack.org/#/c/83122/ is needed. > > > > I'm keen to expose things that are really needed, but i'm not sure that > > /all/ > > options are needed - what do folk think? > > I'm very wary of trying to make the decision in TripleO of what should > and shouldn't be configurable in some other project. For sure the > number of config options in Nova is a problem, and one that's been > discussed many times at summits. However I think you could also make > the case/assumption for any service that the debate about having a config > option has already been held within that service as part of the review > that merged that option in the code - re-running the debate about whether > something should be configurable via TripleO feels like some sort of > policing function on configurability above and beyond what the experts in > that service have already considered, and that doesn't feel right to me. > > Right now TripleO has a very limited view of what can be configured, > based as I understand on primarily what's needed for its CI job. > As more folks who have real deployments start to look at using TripleO > its inevitable that they are going to want to enable the settings that > are important to them to be configured. I can't imagine that anyone is > going to add a configuration value for the sake of it, so can't we start > with the perspective that we are slowly exposing the set of values that > do need to be configured ? >
<snip> > > > > So my proposal here - what I'd like to do as we add all these config > > options to > > TripleO is to take the care to identify which of A/B/C/D they are and code > > them appropriately, and if the option is one of 1b) or 2b) make sure there > > is a > > bug in the relevant project about the fact that we're having to override a > > default. If the option is really a case of 1a) I'm not sure we want it > > configurable at all. > > > > I'm not convinced that anyone is in a position to judge that there is a > single right answer - I know the values that are right for my deployments, > but I'm not arrogant enough to say that they universally applicable. > You only have to see the wide range of Openstack Deployments presented > at every summit to know that that there a lot of different use cases out > there. My worry is that if we try to have that debate in the context of > a TripleO review, then we'll just spin between opinions rather than make > the rapid progress towards getting the needed degree of configurability. > So I would rule out 1a and 1b as options. Again it feels like any > debate about this really belongs back in the projects that TripleO is > deploying rather than TripleO itself. > To me, TripleO isn't just OpenStack CI on a large scale. And TripleO isn't "here's a generic set of tools, go build a cloud." At least, not yet, likely some day. To me, TripleO is first _a_ deployment of OpenStack. Meaning, we can consider our first milestone reached when we have produced a consumable, high scale deployment of OpenStack using OpenStack to operate it. Contributions that do not push us toward that milestone have an impact on it. At the very least they distract our reviewers, and at most, they actively delay that milestone by adding complexity resulting in slower velocity toward it. I don't mean to say that they're not welcome, as I think they add an incredible amount of value; we end up with a virtuous circle as we gather users and contribution that is not directly related to our immediate goals. However, what I'm suggesting is that generic universal configurability of all of the services isn't the immediate goal. Many of these configuration knobs, while eventually necessary to widen the usability of TripleO in a similar fashion to the rest of the OpenStack, will delay even the most narrow initial usability of TripleO. > I'm also not a great fan of considering a change in the default value > (in either TripleO or the original project) as an alternative -whether > the original default was a good choice or not there is a high chance > that someone is relying on it - so any change in a default needs to go > through a deprication period so that folks have a chance to explicitly > configure to keep the setting if they need to. That patterns reasonably > well established in most of the projects, and as folks are now starting > to use TripleO I think it needs to have the same discipline. It's a > pain for sure, but it's the only way to keep stable systems for people > consuming from trunk. > Seeing as TripleO has not reached its initial milestone (described above) I don't think we're at the point of configuration rigor just yet. That is certainly a topic for the summit though, as if we decide to go down that road, I think we need to join the integrated release. > If the root cause of the problem is that every change to exploit a > configurable feature of a deployed service needs an explicit matching > change in TripleO, maybe that's a degree of tight coupling that needs > to be addressed by having a more generic mechanism ? > I think Dan Prince laid out a nice path for how this could be done to give users consuming TripleO directly a generic mechanism. That certainly would be something that near term would be useful and doesn't seem like it would add too much complexity. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
