> On Nov 21, 2016, at 2:36 PM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > Sudheer - this was originally put in (TS-3650) precisely so we could add / > change configuration values on point releases, so that in particular LTS > releases could be tweaked to accept next major version configurations without > breaking current major release configurations. This is quite handy if you're > trying out the next major version vs. running on the LTS. The only real > change I'm proposing here is making this already existing facility usable > from plugins. > James; > "If `proxy.config.james` is set then the value causes blah blah blah > behavior. If not set the deprecated configuration `proxy.config.peach` is > used. If that is not set either, the default value "Sudheer" is used.”.
If `proxy.config.james` supersedes the old configuration, I should not have to explicitly specify it in records.config for that to work. Why shouldn’t I be able to depend on the documented defaults like I can with every other configuration? What happens if they are both specified in records.config? What happens if `proxy.config.james` wasn’t specified in records.config and then it is after a reload? I’m still unconvinced :) > On Monday, November 21, 2016 4:25 PM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> wrote: > > > I see - so, IIUC, the problem you are trying to solve really is the > *replacement* of an existing config setting with an altogether new config > setting? > > In that case, I suppose, the proposed additional info may be used *if* we are > required to ensure backward compatibility, although, I'm not sure if that is > a mandatory requirement across major release updates (unless, of course, we > encounter a need to make this sort of change across a minor release update?). > > > >> On Nov 21, 2016, at 2:18 PM, Alan Carroll <solidwallofc...@yahoo-inc.com> >> wrote: >> >> Sorry, A, B, and C are config variables, such as >> "proxy.config.quick_filter.mask", "proxy.config.quick_filter.mask_in", >> "proxy.config.quick_filter.mask_out". >> >> >> On Monday, November 21, 2016 4:15 PM, Sudheer Vinukonda >> <sudheervinuko...@yahoo.com.INVALID> wrote: >> >> >> Huh, I'm totally confused..Are "A", "B", "C" different config *settings* or >> different *values* for a *given* setting? Your original reply seemed to >> indicate (at least, the initial part of the reply) that they were *values* >> for a given setting, but, the latest seems to indicate the opposite :-/ >> "The use case is providing backwards compatibility. Suppose a plugin uses >> config value A. A newer version, in order to support additional features, >> uses values B and C. It would be nice to be able to detect that neither B >> nor C were explicitly set by the administrator in records.config and >> therefore the plugin should fall back and use A. It is also required to >> *not* fall back to A if the administrator explicitly set B or C to the >> default value. Therefore checking the retrieved value against the default >> value is insufficient. One might use a bogus default value then, but now >> there's a problem if none of A,B, or C was set." >> >> >> PS: I am only trying to understand the use case or need/benefits of having >> this additional new info being proposed - not opposing the need for it! >> >> >> From: Alan Carroll <solidwallofc...@yahoo-inc.com.INVALID> >> >> To: "dev@trafficserver.apache.org" <dev@trafficserver.apache.org> >> Sent: Monday, November 21, 2016 1:55 PM >> Subject: Re: Config variable source values >> >> Let's say the default for B is "Sudheer". There are two cases I want to >> treat differently. >> 1) No mention of B is in records.config. Fall back to A.2) In >> records.config, the value for B is set to "Sudheer" by the administrator. >> Use this value, do not look at A. >> >> >> On Monday, November 21, 2016 3:32 PM, Sudheer Vinukonda >> <sudheervinuko...@yahoo.com.INVALID> wrote: >> >> >> Hmm..what do you mean by "the administrator explicitly set B or C to the >> default value"? >> >> >> >> >> >> >
