You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Nir Sopher <ni...@qwilt.com> on 2017/01/26 10:51:05 UTC
Server's sarameters - adding some logic
Hi,
Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>, allowing
variables to be evaluated as part of a traffic-server parameter, made me
realize that the simple solution of variable substitution is might not be
strong enough.
As an example, lets take traffic server ip bind configuration.
Setting :
LOCAL proxy.local.incoming_ip_to_bind
to be:
STRING __CACHE_IPv4__ [__CACHE_IPv6__]
If the server's IPv6 address is set, it will work nicely.
But if the IPv6 is not set, we will end up with an invalid configuration.
As far as I know, a single profile cannot support both use-cases.
Separating into 2 profile is not scalable. Splitting a profile for this
purpose may result with many profiles, with small differences between them,
which are hard to follow and identify.
I would like to suggest an improvement that
- Allow a parameter to be optional.
- Allow some logic in the evaluation of the parameter's value.
This can be achieved by using expressions to be evaluated in the
parameter's value.
The syntax of course, needs to be discussed, but lets say for example that:
__COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
One may set a value to be:
STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ? [__CACHE_IPv6__] :
""__COND_END__
Having the IPv6 part in the result only if set.
Furthermore, a special evaluation result string (e.g. __NA__) may identify
parameters that should be omitted from the server's configuration.
I would appreciate your view on the issue.
Thanks,
Nir
Re: Server's sarameters - adding some logic
Posted by Nir Sopher <ni...@qwilt.com>.
Indeed, under these circumstances, further investing in this area seems not
to be very productive.
Thank you Dewayne, both for your answer and further discussing the issue,
Nir
On Tue, Jan 31, 2017 at 11:43 PM, Dewayne Richardson <de...@gmail.com>
wrote:
> Hi Nir,
>
> The server hardware tab we plan on removing eventually. It was a feature
> that was added long before Traffic Ops existed back then we called it
> Twelve Monkeys. Once we move toward TC 3.0, we plan on building "bare
> essential" Traffic Ops where we will (initially) leave behind several
> features that can be managed by other ThirdParty software.
>
> The TO Hardware UI and database tables will be one of those candidates.
> So, I wouldn't invest a lot of time populating that area of the application
> (unless you have a valid use case).
>
> > I am basically looking for a way to decouple unrelated configurations
> one from
> the other - avoiding the need to add more profiles due to relatively small
> differences.
>
> We have had design discussions in relation to this question, but Traffic
> Ops doesn't currently support your ask. So, TO doesn't support multiple
> profiles per server.
>
>
> Thanks,
>
>
> Dewayne
>
> On Mon, Jan 30, 2017 at 3:11 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
> > Thanks Mark,
> > Can you please provide an example to explain how "parameters to
> > cache-group" assignment is used?
> >
> > I assumed the "parameter to cache-group" assignment gives an additional
> > dimension to the profiles table - allowing a server to have more than one
> > profile.
> > I now understand this is not the case.
> >
> > I am basically looking for a way to decouple unrelated configurations one
> > from the other - avoiding the need to add more profiles due to relatively
> > small differences.
> >
> > As I see it, server's configuration parameters are derived from a few
> > aspects:
> >
> > 1. The server's main functionality: edge vs mid
> > 2. The server's HW "vendor".
> > For example: block devices naming conventions is different for KVM
> > (/dev/vd?) and VmWare (/dev/sd?) .
> > 3. The server's HW variant strength/capacity.
> > For example: storage capacity and throughput - per storage tier;
> > interface speed; possible CPU related bounds.
> > Note that these differences can derive from different platform
> > specifications, but also form the HW generation: Dell R730 platforms
> are
> > able to contain more disks than the previous generation R720
> platforms.
> > 4. The server software supported capabilities or settings.
> > For example: Live, SSL, debug, etc.
> > Note that these capabilities can also derive from the cache software
> and
> > version - for example, ATS version supported plugins.
> >
> > IIUC, currently each server is attached with a single profile, and
> > theoretically, each of the above aspects multiply the amount of profiles.
> > I believe that in real life, within a single ISP, the matrix is sparsed
> and
> > the number of profiles is limited and controlled.
> >
> > Still, I believe that an ability to attach multiple profiles to a single
> > server, each focused on a different aspect, would be beneficial. It ill
> > allow:
> >
> > 1. The decoupling of server's hardware and software, as already
> > suggested as a future feature in traffic-control documentation.
> > 2. Better view of capability related parameters, allowing a better
> > understanding of which parameter value is derived from which
> capability.
> >
> > Can you please share your view on the subject?
> > What is the status of the hardware and software profiles decoupling?
> >
> > Thanks,
> > Nir
> >
> > On Mon, Jan 30, 2017 at 12:40 AM, Mark Torluemke <mt...@apache.org>
> > wrote:
> >
> > > On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <ni...@qwilt.com> wrote:
> > >
> > > > Thanks Robert.
> > > >
> > > > Indeed. The parameters-profile mechanism practically solves the
> > > scalability
> > > > issue.
> > > > BTW, I noticed there is an ability to assign a variable to a cache
> > group.
> > > > Can someone please elaborate on it? I tried it, setting a variable in
> > > > records.config and examining the result file, but it did not work
> they
> > > way
> > > > I expected.
> > > >
> > >
> > > These parameters are on the cache group itself, not on the caches that
> > are
> > > in the cache group.
> > >
> > >
> > > >
> > > > Nir
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: "Robert Butts" <ro...@gmail.com>
> > > > Date: Jan 26, 2017 5:58 PM
> > > > Subject: Re: Server's sarameters - adding some logic
> > > > To: <de...@trafficcontrol.incubator.apache.org>
> > > > Cc:
> > > >
> > > > > I think that we should not attempt to invent a scripting language
> for
> > > > this
> > > > purpose.
> > > > >
> > > > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > > > candidate
> > > > for the job.
> > > >
> > > > +1 on both counts.
> > > >
> > > > Though I'm not convinced we need a scripting language in parameters
> > yet.
> > > >
> > > > > Separating into 2 profile is not scalable.
> > > >
> > > > Creating or embedding a scripting language is a pretty big feature.
> You
> > > can
> > > > assign the same parameters to multiple profiles. So all the
> parameters
> > > > which are the same can be assigned to both profiles, so no parameters
> > are
> > > > duplicated. Arguably, this scenario is exactly why we have the
> > > > Parameters–Profiles system.
> > > >
> > > > On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com>
> wrote:
> > > >
> > > > > I think that we should not attempt to invent a scripting language
> for
> > > > this
> > > > > purpose.
> > > > >
> > > > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > > > candidate
> > > > > for the job.
> > > > > "Lua is a powerful, efficient, lightweight, embeddable scripting
> > > > language".
> > > > > It can be embedded in all popular languages, specifically in perl
> > > > > <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inlin
> e/Lua.pm
> > > >and
> > > > > (More relevant, I think) in go
> > > > > <https://www.google.co.il/webhp?sourceid=chrome-instant&
> > > > > rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+
> > lua+from+go>
> > > > > .
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com>
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121
> >,
> > > > > allowing
> > > > > > variables to be evaluated as part of a traffic-server parameter,
> > made
> > > > me
> > > > > > realize that the simple solution of variable substitution is
> might
> > > not
> > > > be
> > > > > > strong enough.
> > > > > >
> > > > > > As an example, lets take traffic server ip bind configuration.
> > > > > > Setting :
> > > > > > LOCAL proxy.local.incoming_ip_to_bind
> > > > > > to be:
> > > > > > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> > > > > >
> > > > > > If the server's IPv6 address is set, it will work nicely.
> > > > > > But if the IPv6 is not set, we will end up with an invalid
> > > > configuration.
> > > > > >
> > > > > > As far as I know, a single profile cannot support both use-cases.
> > > > > > Separating into 2 profile is not scalable. Splitting a profile
> for
> > > this
> > > > > > purpose may result with many profiles, with small differences
> > between
> > > > > them,
> > > > > > which are hard to follow and identify.
> > > > > >
> > > > > > I would like to suggest an improvement that
> > > > > >
> > > > > > - Allow a parameter to be optional.
> > > > > > - Allow some logic in the evaluation of the parameter's value.
> > > > > >
> > > > > > This can be achieved by using expressions to be evaluated in the
> > > > > > parameter's value.
> > > > > > The syntax of course, needs to be discussed, but lets say for
> > example
> > > > > that:
> > > > > > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > > > > > One may set a value to be:
> > > > > > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> > > > > [__CACHE_IPv6__]
> > > > > > :
> > > > > > ""__COND_END__
> > > > > > Having the IPv6 part in the result only if set.
> > > > > >
> > > > > > Furthermore, a special evaluation result string (e.g. __NA__) may
> > > > > identify
> > > > > > parameters that should be omitted from the server's
> configuration.
> > > > > >
> > > > > >
> > > > > > I would appreciate your view on the issue.
> > > > > >
> > > > > > Thanks,
> > > > > > Nir
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > *Oren Shemesh*
> > > > > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 |
> > > orens@qwilt.com
> > > > > <yo...@qwilt.com>
> > > > >
> > > >
> > >
> >
>
Re: Server's sarameters - adding some logic
Posted by Dewayne Richardson <de...@gmail.com>.
Hi Nir,
The server hardware tab we plan on removing eventually. It was a feature
that was added long before Traffic Ops existed back then we called it
Twelve Monkeys. Once we move toward TC 3.0, we plan on building "bare
essential" Traffic Ops where we will (initially) leave behind several
features that can be managed by other ThirdParty software.
The TO Hardware UI and database tables will be one of those candidates.
So, I wouldn't invest a lot of time populating that area of the application
(unless you have a valid use case).
> I am basically looking for a way to decouple unrelated configurations one from
the other - avoiding the need to add more profiles due to relatively small
differences.
We have had design discussions in relation to this question, but Traffic
Ops doesn't currently support your ask. So, TO doesn't support multiple
profiles per server.
Thanks,
Dewayne
On Mon, Jan 30, 2017 at 3:11 PM, Nir Sopher <ni...@qwilt.com> wrote:
> Thanks Mark,
> Can you please provide an example to explain how "parameters to
> cache-group" assignment is used?
>
> I assumed the "parameter to cache-group" assignment gives an additional
> dimension to the profiles table - allowing a server to have more than one
> profile.
> I now understand this is not the case.
>
> I am basically looking for a way to decouple unrelated configurations one
> from the other - avoiding the need to add more profiles due to relatively
> small differences.
>
> As I see it, server's configuration parameters are derived from a few
> aspects:
>
> 1. The server's main functionality: edge vs mid
> 2. The server's HW "vendor".
> For example: block devices naming conventions is different for KVM
> (/dev/vd?) and VmWare (/dev/sd?) .
> 3. The server's HW variant strength/capacity.
> For example: storage capacity and throughput - per storage tier;
> interface speed; possible CPU related bounds.
> Note that these differences can derive from different platform
> specifications, but also form the HW generation: Dell R730 platforms are
> able to contain more disks than the previous generation R720 platforms.
> 4. The server software supported capabilities or settings.
> For example: Live, SSL, debug, etc.
> Note that these capabilities can also derive from the cache software and
> version - for example, ATS version supported plugins.
>
> IIUC, currently each server is attached with a single profile, and
> theoretically, each of the above aspects multiply the amount of profiles.
> I believe that in real life, within a single ISP, the matrix is sparsed and
> the number of profiles is limited and controlled.
>
> Still, I believe that an ability to attach multiple profiles to a single
> server, each focused on a different aspect, would be beneficial. It ill
> allow:
>
> 1. The decoupling of server's hardware and software, as already
> suggested as a future feature in traffic-control documentation.
> 2. Better view of capability related parameters, allowing a better
> understanding of which parameter value is derived from which capability.
>
> Can you please share your view on the subject?
> What is the status of the hardware and software profiles decoupling?
>
> Thanks,
> Nir
>
> On Mon, Jan 30, 2017 at 12:40 AM, Mark Torluemke <mt...@apache.org>
> wrote:
>
> > On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <ni...@qwilt.com> wrote:
> >
> > > Thanks Robert.
> > >
> > > Indeed. The parameters-profile mechanism practically solves the
> > scalability
> > > issue.
> > > BTW, I noticed there is an ability to assign a variable to a cache
> group.
> > > Can someone please elaborate on it? I tried it, setting a variable in
> > > records.config and examining the result file, but it did not work they
> > way
> > > I expected.
> > >
> >
> > These parameters are on the cache group itself, not on the caches that
> are
> > in the cache group.
> >
> >
> > >
> > > Nir
> > >
> > > ---------- Forwarded message ----------
> > > From: "Robert Butts" <ro...@gmail.com>
> > > Date: Jan 26, 2017 5:58 PM
> > > Subject: Re: Server's sarameters - adding some logic
> > > To: <de...@trafficcontrol.incubator.apache.org>
> > > Cc:
> > >
> > > > I think that we should not attempt to invent a scripting language for
> > > this
> > > purpose.
> > > >
> > > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > > candidate
> > > for the job.
> > >
> > > +1 on both counts.
> > >
> > > Though I'm not convinced we need a scripting language in parameters
> yet.
> > >
> > > > Separating into 2 profile is not scalable.
> > >
> > > Creating or embedding a scripting language is a pretty big feature. You
> > can
> > > assign the same parameters to multiple profiles. So all the parameters
> > > which are the same can be assigned to both profiles, so no parameters
> are
> > > duplicated. Arguably, this scenario is exactly why we have the
> > > Parameters–Profiles system.
> > >
> > > On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com> wrote:
> > >
> > > > I think that we should not attempt to invent a scripting language for
> > > this
> > > > purpose.
> > > >
> > > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > > candidate
> > > > for the job.
> > > > "Lua is a powerful, efficient, lightweight, embeddable scripting
> > > language".
> > > > It can be embedded in all popular languages, specifically in perl
> > > > <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm
> > >and
> > > > (More relevant, I think) in go
> > > > <https://www.google.co.il/webhp?sourceid=chrome-instant&
> > > > rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+
> lua+from+go>
> > > > .
> > > >
> > > >
> > > >
> > > > On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>,
> > > > allowing
> > > > > variables to be evaluated as part of a traffic-server parameter,
> made
> > > me
> > > > > realize that the simple solution of variable substitution is might
> > not
> > > be
> > > > > strong enough.
> > > > >
> > > > > As an example, lets take traffic server ip bind configuration.
> > > > > Setting :
> > > > > LOCAL proxy.local.incoming_ip_to_bind
> > > > > to be:
> > > > > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> > > > >
> > > > > If the server's IPv6 address is set, it will work nicely.
> > > > > But if the IPv6 is not set, we will end up with an invalid
> > > configuration.
> > > > >
> > > > > As far as I know, a single profile cannot support both use-cases.
> > > > > Separating into 2 profile is not scalable. Splitting a profile for
> > this
> > > > > purpose may result with many profiles, with small differences
> between
> > > > them,
> > > > > which are hard to follow and identify.
> > > > >
> > > > > I would like to suggest an improvement that
> > > > >
> > > > > - Allow a parameter to be optional.
> > > > > - Allow some logic in the evaluation of the parameter's value.
> > > > >
> > > > > This can be achieved by using expressions to be evaluated in the
> > > > > parameter's value.
> > > > > The syntax of course, needs to be discussed, but lets say for
> example
> > > > that:
> > > > > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > > > > One may set a value to be:
> > > > > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> > > > [__CACHE_IPv6__]
> > > > > :
> > > > > ""__COND_END__
> > > > > Having the IPv6 part in the result only if set.
> > > > >
> > > > > Furthermore, a special evaluation result string (e.g. __NA__) may
> > > > identify
> > > > > parameters that should be omitted from the server's configuration.
> > > > >
> > > > >
> > > > > I would appreciate your view on the issue.
> > > > >
> > > > > Thanks,
> > > > > Nir
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Oren Shemesh*
> > > > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 |
> > orens@qwilt.com
> > > > <yo...@qwilt.com>
> > > >
> > >
> >
>
Re: Server's sarameters - adding some logic
Posted by Nir Sopher <ni...@qwilt.com>.
Thanks Mark,
Can you please provide an example to explain how "parameters to
cache-group" assignment is used?
I assumed the "parameter to cache-group" assignment gives an additional
dimension to the profiles table - allowing a server to have more than one
profile.
I now understand this is not the case.
I am basically looking for a way to decouple unrelated configurations one
from the other - avoiding the need to add more profiles due to relatively
small differences.
As I see it, server's configuration parameters are derived from a few
aspects:
1. The server's main functionality: edge vs mid
2. The server's HW "vendor".
For example: block devices naming conventions is different for KVM
(/dev/vd?) and VmWare (/dev/sd?) .
3. The server's HW variant strength/capacity.
For example: storage capacity and throughput - per storage tier;
interface speed; possible CPU related bounds.
Note that these differences can derive from different platform
specifications, but also form the HW generation: Dell R730 platforms are
able to contain more disks than the previous generation R720 platforms.
4. The server software supported capabilities or settings.
For example: Live, SSL, debug, etc.
Note that these capabilities can also derive from the cache software and
version - for example, ATS version supported plugins.
IIUC, currently each server is attached with a single profile, and
theoretically, each of the above aspects multiply the amount of profiles.
I believe that in real life, within a single ISP, the matrix is sparsed and
the number of profiles is limited and controlled.
Still, I believe that an ability to attach multiple profiles to a single
server, each focused on a different aspect, would be beneficial. It ill
allow:
1. The decoupling of server's hardware and software, as already
suggested as a future feature in traffic-control documentation.
2. Better view of capability related parameters, allowing a better
understanding of which parameter value is derived from which capability.
Can you please share your view on the subject?
What is the status of the hardware and software profiles decoupling?
Thanks,
Nir
On Mon, Jan 30, 2017 at 12:40 AM, Mark Torluemke <mt...@apache.org>
wrote:
> On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
> > Thanks Robert.
> >
> > Indeed. The parameters-profile mechanism practically solves the
> scalability
> > issue.
> > BTW, I noticed there is an ability to assign a variable to a cache group.
> > Can someone please elaborate on it? I tried it, setting a variable in
> > records.config and examining the result file, but it did not work they
> way
> > I expected.
> >
>
> These parameters are on the cache group itself, not on the caches that are
> in the cache group.
>
>
> >
> > Nir
> >
> > ---------- Forwarded message ----------
> > From: "Robert Butts" <ro...@gmail.com>
> > Date: Jan 26, 2017 5:58 PM
> > Subject: Re: Server's sarameters - adding some logic
> > To: <de...@trafficcontrol.incubator.apache.org>
> > Cc:
> >
> > > I think that we should not attempt to invent a scripting language for
> > this
> > purpose.
> > >
> > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > candidate
> > for the job.
> >
> > +1 on both counts.
> >
> > Though I'm not convinced we need a scripting language in parameters yet.
> >
> > > Separating into 2 profile is not scalable.
> >
> > Creating or embedding a scripting language is a pretty big feature. You
> can
> > assign the same parameters to multiple profiles. So all the parameters
> > which are the same can be assigned to both profiles, so no parameters are
> > duplicated. Arguably, this scenario is exactly why we have the
> > Parameters–Profiles system.
> >
> > On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com> wrote:
> >
> > > I think that we should not attempt to invent a scripting language for
> > this
> > > purpose.
> > >
> > > My guess is that Lua <https://www.lua.org/about.html> is a good
> > candidate
> > > for the job.
> > > "Lua is a powerful, efficient, lightweight, embeddable scripting
> > language".
> > > It can be embedded in all popular languages, specifically in perl
> > > <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm
> >and
> > > (More relevant, I think) in go
> > > <https://www.google.co.il/webhp?sourceid=chrome-instant&
> > > rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
> > > .
> > >
> > >
> > >
> > > On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>,
> > > allowing
> > > > variables to be evaluated as part of a traffic-server parameter, made
> > me
> > > > realize that the simple solution of variable substitution is might
> not
> > be
> > > > strong enough.
> > > >
> > > > As an example, lets take traffic server ip bind configuration.
> > > > Setting :
> > > > LOCAL proxy.local.incoming_ip_to_bind
> > > > to be:
> > > > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> > > >
> > > > If the server's IPv6 address is set, it will work nicely.
> > > > But if the IPv6 is not set, we will end up with an invalid
> > configuration.
> > > >
> > > > As far as I know, a single profile cannot support both use-cases.
> > > > Separating into 2 profile is not scalable. Splitting a profile for
> this
> > > > purpose may result with many profiles, with small differences between
> > > them,
> > > > which are hard to follow and identify.
> > > >
> > > > I would like to suggest an improvement that
> > > >
> > > > - Allow a parameter to be optional.
> > > > - Allow some logic in the evaluation of the parameter's value.
> > > >
> > > > This can be achieved by using expressions to be evaluated in the
> > > > parameter's value.
> > > > The syntax of course, needs to be discussed, but lets say for example
> > > that:
> > > > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > > > One may set a value to be:
> > > > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> > > [__CACHE_IPv6__]
> > > > :
> > > > ""__COND_END__
> > > > Having the IPv6 part in the result only if set.
> > > >
> > > > Furthermore, a special evaluation result string (e.g. __NA__) may
> > > identify
> > > > parameters that should be omitted from the server's configuration.
> > > >
> > > >
> > > > I would appreciate your view on the issue.
> > > >
> > > > Thanks,
> > > > Nir
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Oren Shemesh*
> > > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 |
> orens@qwilt.com
> > > <yo...@qwilt.com>
> > >
> >
>
Re: Server's sarameters - adding some logic
Posted by Mark Torluemke <mt...@apache.org>.
On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <ni...@qwilt.com> wrote:
> Thanks Robert.
>
> Indeed. The parameters-profile mechanism practically solves the scalability
> issue.
> BTW, I noticed there is an ability to assign a variable to a cache group.
> Can someone please elaborate on it? I tried it, setting a variable in
> records.config and examining the result file, but it did not work they way
> I expected.
>
These parameters are on the cache group itself, not on the caches that are
in the cache group.
>
> Nir
>
> ---------- Forwarded message ----------
> From: "Robert Butts" <ro...@gmail.com>
> Date: Jan 26, 2017 5:58 PM
> Subject: Re: Server's sarameters - adding some logic
> To: <de...@trafficcontrol.incubator.apache.org>
> Cc:
>
> > I think that we should not attempt to invent a scripting language for
> this
> purpose.
> >
> > My guess is that Lua <https://www.lua.org/about.html> is a good
> candidate
> for the job.
>
> +1 on both counts.
>
> Though I'm not convinced we need a scripting language in parameters yet.
>
> > Separating into 2 profile is not scalable.
>
> Creating or embedding a scripting language is a pretty big feature. You can
> assign the same parameters to multiple profiles. So all the parameters
> which are the same can be assigned to both profiles, so no parameters are
> duplicated. Arguably, this scenario is exactly why we have the
> Parameters–Profiles system.
>
> On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com> wrote:
>
> > I think that we should not attempt to invent a scripting language for
> this
> > purpose.
> >
> > My guess is that Lua <https://www.lua.org/about.html> is a good
> candidate
> > for the job.
> > "Lua is a powerful, efficient, lightweight, embeddable scripting
> language".
> > It can be embedded in all popular languages, specifically in perl
> > <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm>and
> > (More relevant, I think) in go
> > <https://www.google.co.il/webhp?sourceid=chrome-instant&
> > rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
> > .
> >
> >
> >
> > On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
> >
> > > Hi,
> > >
> > > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>,
> > allowing
> > > variables to be evaluated as part of a traffic-server parameter, made
> me
> > > realize that the simple solution of variable substitution is might not
> be
> > > strong enough.
> > >
> > > As an example, lets take traffic server ip bind configuration.
> > > Setting :
> > > LOCAL proxy.local.incoming_ip_to_bind
> > > to be:
> > > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> > >
> > > If the server's IPv6 address is set, it will work nicely.
> > > But if the IPv6 is not set, we will end up with an invalid
> configuration.
> > >
> > > As far as I know, a single profile cannot support both use-cases.
> > > Separating into 2 profile is not scalable. Splitting a profile for this
> > > purpose may result with many profiles, with small differences between
> > them,
> > > which are hard to follow and identify.
> > >
> > > I would like to suggest an improvement that
> > >
> > > - Allow a parameter to be optional.
> > > - Allow some logic in the evaluation of the parameter's value.
> > >
> > > This can be achieved by using expressions to be evaluated in the
> > > parameter's value.
> > > The syntax of course, needs to be discussed, but lets say for example
> > that:
> > > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > > One may set a value to be:
> > > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> > [__CACHE_IPv6__]
> > > :
> > > ""__COND_END__
> > > Having the IPv6 part in the result only if set.
> > >
> > > Furthermore, a special evaluation result string (e.g. __NA__) may
> > identify
> > > parameters that should be omitted from the server's configuration.
> > >
> > >
> > > I would appreciate your view on the issue.
> > >
> > > Thanks,
> > > Nir
> > >
> >
> >
> >
> > --
> >
> > *Oren Shemesh*
> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | orens@qwilt.com
> > <yo...@qwilt.com>
> >
>
Re: Server's sarameters - adding some logic
Posted by Nir Sopher <ni...@qwilt.com>.
Thanks Robert.
Indeed. The parameters-profile mechanism practically solves the scalability
issue.
BTW, I noticed there is an ability to assign a variable to a cache group.
Can someone please elaborate on it? I tried it, setting a variable in
records.config and examining the result file, but it did not work they way
I expected.
Nir
---------- Forwarded message ----------
From: "Robert Butts" <ro...@gmail.com>
Date: Jan 26, 2017 5:58 PM
Subject: Re: Server's sarameters - adding some logic
To: <de...@trafficcontrol.incubator.apache.org>
Cc:
> I think that we should not attempt to invent a scripting language for this
purpose.
>
> My guess is that Lua <https://www.lua.org/about.html> is a good candidate
for the job.
+1 on both counts.
Though I'm not convinced we need a scripting language in parameters yet.
> Separating into 2 profile is not scalable.
Creating or embedding a scripting language is a pretty big feature. You can
assign the same parameters to multiple profiles. So all the parameters
which are the same can be assigned to both profiles, so no parameters are
duplicated. Arguably, this scenario is exactly why we have the
Parameters–Profiles system.
On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com> wrote:
> I think that we should not attempt to invent a scripting language for this
> purpose.
>
> My guess is that Lua <https://www.lua.org/about.html> is a good candidate
> for the job.
> "Lua is a powerful, efficient, lightweight, embeddable scripting
language".
> It can be embedded in all popular languages, specifically in perl
> <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm>and
> (More relevant, I think) in go
> <https://www.google.co.il/webhp?sourceid=chrome-instant&
> rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
> .
>
>
>
> On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
> > Hi,
> >
> > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>,
> allowing
> > variables to be evaluated as part of a traffic-server parameter, made me
> > realize that the simple solution of variable substitution is might not
be
> > strong enough.
> >
> > As an example, lets take traffic server ip bind configuration.
> > Setting :
> > LOCAL proxy.local.incoming_ip_to_bind
> > to be:
> > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> >
> > If the server's IPv6 address is set, it will work nicely.
> > But if the IPv6 is not set, we will end up with an invalid
configuration.
> >
> > As far as I know, a single profile cannot support both use-cases.
> > Separating into 2 profile is not scalable. Splitting a profile for this
> > purpose may result with many profiles, with small differences between
> them,
> > which are hard to follow and identify.
> >
> > I would like to suggest an improvement that
> >
> > - Allow a parameter to be optional.
> > - Allow some logic in the evaluation of the parameter's value.
> >
> > This can be achieved by using expressions to be evaluated in the
> > parameter's value.
> > The syntax of course, needs to be discussed, but lets say for example
> that:
> > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > One may set a value to be:
> > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> [__CACHE_IPv6__]
> > :
> > ""__COND_END__
> > Having the IPv6 part in the result only if set.
> >
> > Furthermore, a special evaluation result string (e.g. __NA__) may
> identify
> > parameters that should be omitted from the server's configuration.
> >
> >
> > I would appreciate your view on the issue.
> >
> > Thanks,
> > Nir
> >
>
>
>
> --
>
> *Oren Shemesh*
> Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | orens@qwilt.com
> <yo...@qwilt.com>
>
Re: Server's sarameters - adding some logic
Posted by Robert Butts <ro...@gmail.com>.
> I think that we should not attempt to invent a scripting language for this
purpose.
>
> My guess is that Lua <https://www.lua.org/about.html> is a good candidate
for the job.
+1 on both counts.
Though I'm not convinced we need a scripting language in parameters yet.
> Separating into 2 profile is not scalable.
Creating or embedding a scripting language is a pretty big feature. You can
assign the same parameters to multiple profiles. So all the parameters
which are the same can be assigned to both profiles, so no parameters are
duplicated. Arguably, this scenario is exactly why we have the
Parameters–Profiles system.
On Thu, Jan 26, 2017 at 5:10 AM, Oren Shemesh <or...@qwilt.com> wrote:
> I think that we should not attempt to invent a scripting language for this
> purpose.
>
> My guess is that Lua <https://www.lua.org/about.html> is a good candidate
> for the job.
> "Lua is a powerful, efficient, lightweight, embeddable scripting language".
> It can be embedded in all popular languages, specifically in perl
> <http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm>and
> (More relevant, I think) in go
> <https://www.google.co.il/webhp?sourceid=chrome-instant&
> rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
> .
>
>
>
> On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
> > Hi,
> >
> > Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>,
> allowing
> > variables to be evaluated as part of a traffic-server parameter, made me
> > realize that the simple solution of variable substitution is might not be
> > strong enough.
> >
> > As an example, lets take traffic server ip bind configuration.
> > Setting :
> > LOCAL proxy.local.incoming_ip_to_bind
> > to be:
> > STRING __CACHE_IPv4__ [__CACHE_IPv6__]
> >
> > If the server's IPv6 address is set, it will work nicely.
> > But if the IPv6 is not set, we will end up with an invalid configuration.
> >
> > As far as I know, a single profile cannot support both use-cases.
> > Separating into 2 profile is not scalable. Splitting a profile for this
> > purpose may result with many profiles, with small differences between
> them,
> > which are hard to follow and identify.
> >
> > I would like to suggest an improvement that
> >
> > - Allow a parameter to be optional.
> > - Allow some logic in the evaluation of the parameter's value.
> >
> > This can be achieved by using expressions to be evaluated in the
> > parameter's value.
> > The syntax of course, needs to be discussed, but lets say for example
> that:
> > __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> > One may set a value to be:
> > STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ?
> [__CACHE_IPv6__]
> > :
> > ""__COND_END__
> > Having the IPv6 part in the result only if set.
> >
> > Furthermore, a special evaluation result string (e.g. __NA__) may
> identify
> > parameters that should be omitted from the server's configuration.
> >
> >
> > I would appreciate your view on the issue.
> >
> > Thanks,
> > Nir
> >
>
>
>
> --
>
> *Oren Shemesh*
> Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | orens@qwilt.com
> <yo...@qwilt.com>
>
Re: Server's sarameters - adding some logic
Posted by Oren Shemesh <or...@qwilt.com>.
I think that we should not attempt to invent a scripting language for this
purpose.
My guess is that Lua <https://www.lua.org/about.html> is a good candidate
for the job.
"Lua is a powerful, efficient, lightweight, embeddable scripting language".
It can be embedded in all popular languages, specifically in perl
<http://search.cpan.org/~vparseval/Inline-Lua-0.03/lib/Inline/Lua.pm>and
(More relevant, I think) in go
<https://www.google.co.il/webhp?sourceid=chrome-instant&rlz=1C1LENP_enIL506IL506&ion=1&espv=2&ie=UTF-8#q=calling+lua+from+go>
.
On Thu, Jan 26, 2017 at 12:51 PM, Nir Sopher <ni...@qwilt.com> wrote:
> Hi,
>
> Working on TC-121 <https://issues.apache.org/jira/browse/TC-121>, allowing
> variables to be evaluated as part of a traffic-server parameter, made me
> realize that the simple solution of variable substitution is might not be
> strong enough.
>
> As an example, lets take traffic server ip bind configuration.
> Setting :
> LOCAL proxy.local.incoming_ip_to_bind
> to be:
> STRING __CACHE_IPv4__ [__CACHE_IPv6__]
>
> If the server's IPv6 address is set, it will work nicely.
> But if the IPv6 is not set, we will end up with an invalid configuration.
>
> As far as I know, a single profile cannot support both use-cases.
> Separating into 2 profile is not scalable. Splitting a profile for this
> purpose may result with many profiles, with small differences between them,
> which are hard to follow and identify.
>
> I would like to suggest an improvement that
>
> - Allow a parameter to be optional.
> - Allow some logic in the evaluation of the parameter's value.
>
> This can be achieved by using expressions to be evaluated in the
> parameter's value.
> The syntax of course, needs to be discussed, but lets say for example that:
> __COND_BEGIN__/__COND_END__ delimits a condition to be evaluated:
> One may set a value to be:
> STRING __CACHE_IPv4__ __COND_BEGIN__ __CACHE_IPv6__!="" ? [__CACHE_IPv6__]
> :
> ""__COND_END__
> Having the IPv6 part in the result only if set.
>
> Furthermore, a special evaluation result string (e.g. __NA__) may identify
> parameters that should be omitted from the server's configuration.
>
>
> I would appreciate your view on the issue.
>
> Thanks,
> Nir
>
--
*Oren Shemesh*
Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | orens@qwilt.com
<yo...@qwilt.com>