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 Monitor and Traffic Router aware of the new
status. Something like MONITOR_ONLY might make sense. If we did this
in Traffic Ops, we could use the new status to control whether DS
assignments occur in the Traffic Ops APIs (legacy CRConfig and
monitoring/routing config APIs). Making the change in Traffic Ops is
likely to be less work and will be less disruptive to production
traffic (no deployment of TR required).
The specific reason why this is tricky is that we want to poll astats
to collect metrics off these caches using Traffic Monitor, assign
delivery services to them, but not route traffic to them. That implies
that the caches must be in the CRConfig in order for Traffic Monitor
to see them, but due to the DS assignments, Traffic Router will route
traffic to them. The caches in question already have a unique type,
"EDGE_FOO" for example, while our regular edges are simply "EDGE."
A while back, I worked on a change to allow us to monitor any server
type that begins with EDGE or MID, which gets them into the CRConfig.
This worked fine until we had a need to map DSs to the edge type in
question. With the golang version of Traffic Monitor we moved toward
monitoring.json, but we still rely on CRConfig. Long term we should
complete that move, and update Traffic Router to consume the routing
config so that the two configs of the components aren't so tightly
coupled. That would allow us to accomplish this sort of thing much
more easily and clearly.
--
Thanks,
Jeff
On Wed, Aug 23, 2017 at 3:53 PM, rawlin.pet...@gmail.com
<rawlin_pet...@comcast.com> wrote:
> 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" <derek_geli...@comcast.com> wrote:
>> 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)
>> > <efrie...@cisco.com> wrote:
>> >
>> > 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 <derek_geli...@comcast.com>
>> >> wrote:
>> >>
>> >> 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)
>> >>> <efrie...@cisco.com> wrote:
>> >>>
>> >>> 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 <derek_geli...@comcast.com>
>> >>>> wrote:
>> >>>>
>> >>>> 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 crconfig file.
>> >>>>
>> >>>> There’s been a bit of internal debate about the best ways to do this,
>> >>>> and I’d like to collect some opinions on the matter.
>> >>>>
>> >>>> 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 could be easily filtered on. Minor UI change only.
>> >>>> 2) Profile parameter - when marked, nothing is routed to any host with
>> >>>> this profile. Heavy handed, and would require additional profile
>> >>>> parameter lookups when generating the crconfig, so it’d slow it down.
>> >>>> No UI change.
>> >>>> 3) deliveryservice_servers table flag - an additional column that is
>> >>>> true by default. When desired, the user could pull up a sub-window
>> >>>> within the delivery service configuration that would present a list of
>> >>>> the hosts which have been assigned to the delivery service (and are not
>> >>>> of org type). The user could deselect the desired hosts, setting the
>> >>>> DSS routing value to false. This server would then be ignored when
>> >>>> generating the crconfig data for that specific delivery service. This
>> >>>> would be the most configurable option, and should be as quick as option
>> >>>> 1, but would require the most extensive code changes.
>> >>>>
>> >>>> Personally, I like option 3, but would very much like to hear opinions,
>> >>>> arguments, and other options that I haven’t thought of or listed here.
>> >>>>
>> >>>> Derek
>> >>>
>> >>
>> >
>>
>>
