Re: Preventing routing to individual caches

is also goes back to our DB normalization discussion) > > --Eric > > > From: Mark Torluemke <mtorlue...@apache.org> > Sent: Thursday, August 24, 2017 12:11 PM > To: dev@trafficcontrol.incubator.apache.org > Subject: Re: Preventing rou

Re: Preventing routing to individual caches

<mtorlue...@apache.org> Sent: Thursday, August 24, 2017 12:11 PM To: dev@trafficcontrol.incubator.apache.org Subject: 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.

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

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

Re: Preventing routing to individual caches

ply to a whole server? > > From: Gelinas, Derek [derek_geli...@comcast.com derek_geli...@comcast.com>] > Sent: Tuesday, August 22, 2017 6:22 PM > To: dev@trafficcontrol.incubator.apache.org<mailto:dev@ > trafficcontrol.incubator.apache.org> &g

Re: Preventing routing to individual caches

gust 22, 2017 6:22 PM To: dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org> Subject: Re: Preventing routing to individual caches The use case is fairly specific. Suffice it to say we have reverse proxies that need configuration without being treated a

RE: Preventing routing to individual caches

Could this be a new DS type or does it apply to a whole server? From: Gelinas, Derek [derek_geli...@comcast.com] Sent: Tuesday, August 22, 2017 6:22 PM To: dev@trafficcontrol.incubator.apache.org Subject: Re: Preventing routing to individual caches The use

Re: Preventing routing to individual caches

I should add that there are two further options which have been pointed out to me: 1) Server table flag - when marked, nothing is routed to the host at all. Not as configurable as option 3, but more so than option 2. Faster than option 2 as it would be returned with existing search results and

Re: Preventing routing to individual caches

The use case is fairly specific. Suffice it to say we have reverse proxies that need configuration without being treated as potential destinations by traffic router. DG On Aug 22, 2017, at 3:19 PM, Nir Sopher > wrote: Hi Derek, Could you please shade

Re: Preventing routing to individual caches

I’d agree with you if this was designed to drain, but this is intended as a permanent state for a pretty good long list of caches. DG > On Aug 22, 2017, at 1:28 PM, Eric Friedrich (efriedri) > wrote: > > What about a modification of option 1- adding a new state per

Re: Preventing routing to individual caches

What about a modification of option 1- adding a new state per server. Instead of ADMIN_DOWN, it could be “REPORTED_DRAIN” to indicate the difference —Eric > On Aug 22, 2017, at 1:14 PM, Gelinas, Derek wrote: > > That’s actually the workaround we’re using at the

Re: Preventing routing to individual caches

That’s actually the workaround we’re using at the moment - setting them to admin_down. That’s a temporary measure, though - we want something more permanent. DG > On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) > wrote: > > How does your use case differ from

Re: Preventing routing to individual caches

How does your use case differ from marking a server as offline in Traffic Ops and snapshotting? Thats the easiest way I can think of to get a server in this state —Eric > On Aug 22, 2017, at 1:00 PM, Gelinas, Derek wrote: > > We’ve run across a situation in which