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 <dewr...@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 <n...@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 <mtorlue...@apache.org> > > wrote: > > > > > On Sun, Jan 29, 2017 at 2:02 PM, Nir Sopher <n...@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" <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/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 <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> > > > > > > > > > > > > > > >
