Unfortunately it's not so far fetched that I don't need it to implement
required support in a plugin, and not so far fetched I haven't had to do it at
least twice in the core already.
To avoid going in circles and to summarize my 2c, I've to say I agree with
James that the whole proposal and the problem description looks rather
unconvincing and extraneous at best. Be so it may, extending this capability to
plugins seems even more far-fetched.
- Sudheer
> On Nov 22, 2016, at
In order to enable ops to experiment/test/verify the new configuration options
before upgrading to the next major version, without breaking other people.
Note also this isn't a *replace*, it's an augmentation. The whole point is to
enable existing configuration to continue to work exactly as it d
But, practically, on purpose, why'd you ever want to replace an existing config
setting with another new config setting in a minor release (I'm not referring
to implementation bugs)? That sort of change should belong to a major release.
The argument that it makes it easier to inherit new major r
Sudheer;
"Now, let's assume the default has been changed to "thread" pool sharing in
5.3".
No, let's not. That's the opposite of what I'm talking about. The entire point
of all of this is to *NOT* change the default behavior. In fact, the goal is to
not change behavior at all unless the administ
I have to say this is an odd argument.
Anyone that does real world code in enterprise environments knows that you have
to migrate between versions. Config value that are renamed have to allow for
time migrate to a new value. Hard switches will upset customers very quickly.
They need time to be w
> On Nov 22, 2016, at 6:25 AM, Alan Carroll
> wrote:
>
> "If `proxy.config.james` supersedes the old configuration, I should not have
> to explicitly specify it in records.config for that to work"
> Correct. And if the administrator specifies no configuration variable, that's
> what happens.
The conflict is in the solution being proposed -
AFAICT, merely not specifying a config setting explicitly in records.config
does NOT mean, the resultant (default) behavior can be changed in a minor
release update.
For example, take the case of server session sharing that was the origin of the
I don't see the conflict with the policy you quoted. Use of the config
variable source mechanism means that new configuration options can be added to
minor versions because it can be done without an incompatible change, exactly
in line with "MINOR version when you add functionality in a
backwa
Here's what curl says about its upgrade policy -
https://curl.haxx.se/libcurl/abi.html
"In the vast majority of all cases, a typical libcurl upgrade does not
break the ABI at all. Your application can remain using libcurl just as before,
only with less bugs and possibly with added new features.
"If `proxy.config.james` supersedes the old configuration, I should not have to
explicitly specify it in records.config for that to work"
Correct. And if the administrator specifies no configuration variable, that's
what happens. If the administrator does specify it, then it works. The case of
i
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
ow
>> 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!
>>
>>
>> Fr
>
>
> 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
>
> To: "dev@trafficserver.apache.org"
> Sent: Monday, Nove
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:
> 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
>
'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
To: "dev@trafficserver.apache.org"
Sent: Monday, Nove
.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 f
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
30 matches
Mail list logo
