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" <robert.o.bu...@gmail.com> Date: Jan 26, 2017 5:58 PM Subject: Re: Server's sarameters - adding some logic To: <dev@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 <n...@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 | or...@qwilt.com > <y...@qwilt.com> >
