On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <[email protected]> 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" <[email protected]> > Date: Jan 26, 2017 5:58 PM > Subject: Re: Server's sarameters - adding some logic > To: <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 | [email protected] > > <[email protected]> > > >
