malization discussion)
>
> --Eric
>
>
> From: Mark Torluemke
> 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
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.
On Thu, Aug 24, 2017
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 we process, and that’s going
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 into it.
>
> Assuming it does
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 Mon
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 colu
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 as
What about the server status CCR_IGNORE ("Server is ignored by traffic
router.") that already exists? It doesn't appear to be checked when generating
CRConfig right now, but maybe it should be?
--Rawlin
On 2017-08-22 11:45, "Gelinas, Derek" wrote:
> Iâd agree with you if this was designed t
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>
>
day, August 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
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
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
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 mailto:n...@qwilt.com>>
wrote:
Hi Derek,
Could you please shade more light on the
Hi Derek,
Could you please shade more light on the problem you are trying to solve?
As I see it, option #3 is indeed more flexible - as it can work in a DS
granularity.
It is even more powerful when you combine it with other extensions for this
table suggested in the "Drop Server -> Delivery Serv
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 server.
>
> Instead of AD
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 moment - setting them to
> adm
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 marking a server as offlin
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 we need certain caches to
>
We’ve run across a situation in which we need certain caches to simultaneously
have map rules for a delivery service, but not actually have those caches
routed to when requests are made via traffic router. Essentially, this means
removing the delivery service from the cache’s info in the crconf
19 matches
Mail list logo
