Re: Global parameters and seeds.sql

Jeremy, I observed the same thing when I upgraded my instance of Traffic Ops. It had duplicated "tm.toolname" as a key. +1 on the proposal. Steve On Thu, Aug 24, 2017 at 12:04 PM, Jeremy Mitchell wrote: > IMO there seems to be an inherent flaw with global parameters

Re: Preventing routing to individual caches

I don’t believe that we want to have this as just a parameter - this is not a minor setting, and it’s not something we want lost in the noise. Unless anyone has any objections, I’m going to set this up as a new profile column with a checkbox in the profile settings of the UI. Derek > On Aug

Re: Preventing routing to individual caches

This is more of a general question, not related to this specific feature: What determines when something can be a new column in the profile table versus a parameter? (this also goes back to our DB normalization discussion) --Eric From: Mark Torluemke

Re: Preventing routing to individual caches

I'm good with a new column on the profile table. Also, I don't share the concern on this slowing down any queries significantly. On Thu, Aug 24, 2017 at 8:52 AM, Gelinas, Derek wrote: > I think profile is right out - that means a profile lookup for each server > that

Global parameters and seeds.sql

IMO there seems to be an inherent flaw with global parameters and that flaw is exposed in via seeds.sql. Let's use an example. There is a global parameter called tm.toolname with a seeded value of 'Traffic Ops' (

Re: Preventing routing to individual caches

I think profile is right out - that means a profile lookup for each server that we process, and that’s going to make an already slow subroutine a lot slower. DG > On Aug 24, 2017, at 10:40 AM, Gelinas, Derek > wrote: > > I’m not sure it would work, but I’ll look

Re: Preventing routing to individual caches

CCR_IGNORE won't work, and a quick grep in the code base makes me think CCR_IGNORE won't even work as it did previously (drop hosts from the CRConfig). That said, it's a good idea and I think we might be able to use the same concept to accomplish this, as long as we make Traffic Ops, or Traffic

Re: Preventing routing to individual caches

I believe using CCR_IGNORE would mean the caches aren't monitored by Traffic Monitor, and we don't want that. I don't really like any of the options but I don't have time or desire to think of something better. So, if I had to choose one of the options presented, I would choose 5 -- putting a

Re: Preventing routing to individual caches

I’m not sure it would work, but I’ll look into it. Assuming it does not, does anyone have any strong feelings about any of the choices? My personal preference is to use option 3 or option 1, or to use ccr_ignore. 1) Server table flag - when marked, nothing is routed to the host at all. Not