> On Nov 21, 2016, at 2:36 PM, Alan Carroll
> 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
> bre
Hmm..OK - Al though, I'm wondering this seems more of a band-aid approach to
something that shouldn't happen (at least, not typically) and something that
probably should be discouraged in principle? I fear It could get rather
confusing and probably unpredictable if this sort of config setting ch
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
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
> On Nov 21, 2016, at 2:04 PM, Alan Carroll
> wrote:
>
> But this is precisely the scenario in mind when the original RecSourceT code
> was put in for core. Otherwise, it's not possible to support the use of an
> old configuration with the new code. The default values of B and C will take
>
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
wrote:
Huh, I'm totally confused..Are "A", "B", "C" different config *
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 :-/
"
But this is precisely the scenario in mind when the original RecSourceT code
was put in for core. Otherwise, it's not possible to support the use of an old
configuration with the new code. The default values of B and C will take
precedence over value set for A in records.config even if neither B
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
> On Nov 21, 2016, at 1:22 PM, Alan Carroll
> wrote:
>
> 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 we
Hmm..what do you mean by "the administrator explicitly set B or C to the
default value"?
I'm not sure how the administrator can "play" around with default values? Or
Did you mean, if a new version (release?) of trafficserver changed the default
value for a setting?
If it is the latter (changin
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 theref
I'm curious to know the use case, if any, in where one'd care if a "default"
value for a setting came from the source code or from records.config.
Consequently, I wonder if it is sufficient to know that a given setting has a
"default" value or a non-default value.
It might also be helpful if y
No, they behave very differently. If you have a config variable in
RecordsConfig.cc and it's not mentioned in records.config you get
REC_SOURCE_DEFAULT. If you have a plugin created config variable that is not in
records.config you get REC_SOURCE_EXPLICIT. In both cases if the value is in
recor
> On Nov 21, 2016, at 11:50 AM, Alan Carroll
> wrote:
>
> No, the source is REC_SOURCE_EXPLICIT even if the variable is not mentioned
> in records.config. How else can a plugin tell if a config variable it creates
> has a value in records.config?
I think I’m confused about what you are propo
No, the source is REC_SOURCE_EXPLICIT even if the variable is not mentioned in
records.config. How else can a plugin tell if a config variable it creates has
a value in records.config?
On Monday, November 21, 2016 12:21 PM, James Peach
wrote:
> On Nov 21, 2016, at 9:14 AM, Alan Carro
> On Nov 21, 2016, at 9:14 AM, Alan Carroll
> wrote:
>
> REC_SOURCE_EXPLICIT - see TSMgmtStringCreate in InkAPI.cc (around line 8896).
> That is the same value as setting the value in a configuration file.
That sounds correct to me. The value was set in a configuration file and is
being cons
REC_SOURCE_EXPLICIT - see TSMgmtStringCreate in InkAPI.cc (around line 8896).
That is the same value as setting the value in a configuration file.
On Monday, November 21, 2016 10:29 AM, James Peach
wrote:
> On Nov 21, 2016, at 7:20 AM, Alan Carroll
> wrote:
>
> The config variable
> On Nov 21, 2016, at 7:20 AM, Alan Carroll
> wrote:
>
> The config variable sourcing data was originally put in to be able to detect
> that a variable was set even if that setting was the same as the default
> (otherwise this is impossible to reliably determine). I am working with a
> plugi
The config variable sourcing data was originally put in to be able to detect
that a variable was set even if that setting was the same as the default
(otherwise this is impossible to reliably determine). I am working with a
plugin that defines its own config records but as far as I can tell (1)
20 matches
Mail list logo
