Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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

Re: Preventing routing to individual caches

[Dave Neuman <ne...@apache.org>]

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 column on the profile table.

On Thu, Aug 24, 2017 at 8:40 AM, Gelinas, Derek <De...@comcast.com>
wrote:

> 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 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.
> 4) Column in the “type” table. Like option 1, this would apply at the
> server level.
> 5) Column in the “profile” table.  Like option 2, this would apply at the
> profile level.
>
>
> > On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <
> rawlin_peters@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" <De...@comcast.com> wrote:
> >> Iâ?Td 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) <
> efriedri@cisco.com> wrote:
> >>>
> >>> What about a modification of option 1- adding a new state per server.
> >>>
> >>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
> the difference
> >>>
> >>> â?"Eric
> >>>
> >>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
> Derek_Gelinas@comcast.com> wrote:
> >>>>
> >>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment -
> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
> something more permanent.
> >>>>
> >>>> DG
> >>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
> efriedri@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_Gelinas@comcast.com> wrote:
> >>>>>>
> >>>>>> Weâ?Tve 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â?Ts
> info in the crconfig file.
> >>>>>>
> >>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do
> this, and Iâ?Td 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â?Td 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â?Tt thought of or
> listed here.
> >>>>>>
> >>>>>> Derek
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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 24, 2017, at 12:34 PM, Eric Friedrich (efriedri) <ef...@cisco.com> wrote:
> 
> 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 <mt...@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.
> 
> On Thu, Aug 24, 2017 at 8:52 AM, Gelinas, Derek <De...@comcast.com>
> wrote:
> 
>> 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 <De...@comcast.com>
>> wrote:
>>> 
>>> 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 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.
>>> 4) Column in the “type” table. Like option 1, this would apply at the
>> server level.
>>> 5) Column in the “profile” table.  Like option 2, this would apply at
>> the profile level.
>>> 
>>> 
>>>> On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <
>> rawlin_peters@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" <De...@comcast.com>
>> wrote:
>>>>> Iâ?Td 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) <
>> efriedri@cisco.com> wrote:
>>>>>> 
>>>>>> What about a modification of option 1- adding a new state per server.
>>>>>> 
>>>>>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
>> the difference
>>>>>> 
>>>>>> â?"Eric
>>>>>> 
>>>>>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
>> Derek_Gelinas@comcast.com> wrote:
>>>>>>> 
>>>>>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment -
>> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
>> something more permanent.
>>>>>>> 
>>>>>>> DG
>>>>>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
>> efriedri@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_Gelinas@comcast.com> wrote:
>>>>>>>>> 
>>>>>>>>> Weâ?Tve 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â?Ts
>> info in the crconfig file.
>>>>>>>>> 
>>>>>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do
>> this, and Iâ?Td 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â?Td 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â?Tt thought of or
>> listed here.
>>>>>>>>> 
>>>>>>>>> Derek
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: Preventing routing to individual caches

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

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 <mt...@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.

On Thu, Aug 24, 2017 at 8:52 AM, Gelinas, Derek <De...@comcast.com>
wrote:

> 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 <De...@comcast.com>
> wrote:
> >
> > 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 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.
> > 4) Column in the “type” table. Like option 1, this would apply at the
> server level.
> > 5) Column in the “profile” table.  Like option 2, this would apply at
> the profile level.
> >
> >
> >> On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <
> rawlin_peters@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" <De...@comcast.com>
> wrote:
> >>> Iâ?Td 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) <
> efriedri@cisco.com> wrote:
> >>>>
> >>>> What about a modification of option 1- adding a new state per server.
> >>>>
> >>>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
> the difference
> >>>>
> >>>> â?"Eric
> >>>>
> >>>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
> Derek_Gelinas@comcast.com> wrote:
> >>>>>
> >>>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment -
> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
> something more permanent.
> >>>>>
> >>>>> DG
> >>>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
> efriedri@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_Gelinas@comcast.com> wrote:
> >>>>>>>
> >>>>>>> Weâ?Tve 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â?Ts
> info in the crconfig file.
> >>>>>>>
> >>>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do
> this, and Iâ?Td 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â?Td 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â?Tt thought of or
> listed here.
> >>>>>>>
> >>>>>>> Derek
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Re: Preventing routing to individual caches

[Mark Torluemke <mt...@apache.org>]

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 <De...@comcast.com>
wrote:

> 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 <De...@comcast.com>
> wrote:
> >
> > 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 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.
> > 4) Column in the “type” table. Like option 1, this would apply at the
> server level.
> > 5) Column in the “profile” table.  Like option 2, this would apply at
> the profile level.
> >
> >
> >> On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <
> rawlin_peters@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" <De...@comcast.com>
> wrote:
> >>> Iâ?Td 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) <
> efriedri@cisco.com> wrote:
> >>>>
> >>>> What about a modification of option 1- adding a new state per server.
> >>>>
> >>>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ?  to indicate
> the difference
> >>>>
> >>>> â?"Eric
> >>>>
> >>>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <
> Derek_Gelinas@comcast.com> wrote:
> >>>>>
> >>>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment -
> setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want
> something more permanent.
> >>>>>
> >>>>> DG
> >>>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <
> efriedri@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_Gelinas@comcast.com> wrote:
> >>>>>>>
> >>>>>>> Weâ?Tve 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â?Ts
> info in the crconfig file.
> >>>>>>>
> >>>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do
> this, and Iâ?Td 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â?Td 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â?Tt thought of or
> listed here.
> >>>>>>>
> >>>>>>> Derek
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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 <De...@comcast.com> wrote:
> 
> 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 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.
> 4) Column in the “type” table. Like option 1, this would apply at the server level.
> 5) Column in the “profile” table.  Like option 2, this would apply at the profile level.
> 
> 
>> On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <ra...@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" <De...@comcast.com> wrote: 
>>> Iâ?Td 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) <ef...@cisco.com> wrote:
>>>> 
>>>> What about a modification of option 1- adding a new state per server. 
>>>> 
>>>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ? to indicate the difference
>>>> 
>>>> â?"Eric
>>>> 
>>>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <De...@comcast.com> wrote:
>>>>> 
>>>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment - setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want something more permanent.
>>>>> 
>>>>> DG
>>>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <ef...@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 <De...@comcast.com> wrote:
>>>>>>> 
>>>>>>> Weâ?Tve 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â?Ts info in the crconfig file.
>>>>>>> 
>>>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do this, and Iâ?Td 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â?Td 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â?Tt thought of or listed here.
>>>>>>> 
>>>>>>> Derek
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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 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.
4) Column in the “type” table. Like option 1, this would apply at the server level.
5) Column in the “profile” table.  Like option 2, this would apply at the profile level.


> On Aug 23, 2017, at 5:53 PM, rawlin.peters@gmail.com <ra...@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" <De...@comcast.com> wrote: 
>> Iâ?Td 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) <ef...@cisco.com> wrote:
>>> 
>>> What about a modification of option 1- adding a new state per server. 
>>> 
>>> Instead of ADMIN_DOWN, it could be â?oREPORTED_DRAINâ? to indicate the difference
>>> 
>>> â?"Eric
>>> 
>>>> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <De...@comcast.com> wrote:
>>>> 
>>>> Thatâ?Ts actually the workaround weâ?Tre using at the moment - setting them to admin_down.  Thatâ?Ts a temporary measure, though - we want something more permanent.
>>>> 
>>>> DG
>>>>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) <ef...@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 <De...@comcast.com> wrote:
>>>>>> 
>>>>>> Weâ?Tve 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â?Ts info in the crconfig file.
>>>>>> 
>>>>>> Thereâ?Ts been a bit of internal debate about the best ways to do this, and Iâ?Td 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â?Td 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â?Tt thought of or listed here.
>>>>>> 
>>>>>> Derek
>>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: Preventing routing to individual caches

[Jeff Elsloo <el...@apache.org>]

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.peters@gmail.com
<ra...@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" <De...@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) <ef...@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 <De...@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) <ef...@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 <De...@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
>> >>>
>> >>
>> >
>>
>>

Re: Preventing routing to individual caches

["rawlin.peters@gmail.com" <ra...@comcast.com>]

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" <De...@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) <ef...@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 <De...@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) <ef...@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 <De...@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
> >>> 
> >> 
> > 
> 
> 

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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
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.
4) Column in the “type” table. Like option 1, this would apply at the server level.
5) Column in the “profile” table.  Like option 2, this would apply at the profile level.

So it’s a question of which level is preferred, I suppose - delivery service, server, or profile?  Any of the three will resolve the issue, but the DS level fix, while being the most complex to code and add to the UI, will create the most flexibility.  The question is do we need that flexibility and do we want the added complexity which accompanies it?

DG


On Aug 22, 2017, at 6:22 PM, Gelinas, Derek <De...@comcast.com>> wrote:

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 <ni...@qwilt.com>> wrote:

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 Service assignments".

However, as you describe options #1,#2 as valid options, it seems that the
problem you are dealing with completely resides in the "servers" domain -
as the server should have the same behavior for all delivery-services.
Therefore, option #1 might be more suitable.

Nir

On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <De...@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) <
efriedri@cisco.com<ma...@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 <De...@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) <
efriedri@cisco.com<ma...@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_Gelinas@comcast.com<ma...@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

Re: Preventing routing to individual caches

[Nir Sopher <ni...@qwilt.com>]

Hi,

From the conversation so far it feels like a new "server type" is needed,
and *maybe *some way to mark delivery services to be deployed on this kind
of servers as well.
If the "marking" is required, it can also be done in the (to be discussed)
"deployed DS versions" table.

Either way, please take into consideration self-service and tenancy  - the
variables of a DS in the DS table should be managed by the DS owner. As I
see it, adding "CDN deployment related parameters" to the DS itself, brings
the DS owner control over something he should not have.

Nir

On Wed, Aug 23, 2017 at 10:45 AM, Gelinas, Derek <De...@comcast.com>
wrote:

> I suppose it could be a new type.  How are you thinking we'd implement in
> that case? Off the cuff I'm thinking we could have a type filter ds
> parameter which would list the various server types we want routed.  In
> that way we could differentiate between the default edge type and something
> else.  Doing it that way would require a bit of retooling the query used to
> generate the delivery service list, but that's about it.  Though in that
> case it really wouldn't need to be a different delivery service type, so I
> suspect you've something else in mind.
>
> On Aug 23, 2017, at 12:14 AM, Eric Friedrich (efriedri) <
> efriedri@cisco.com<ma...@cisco.com>> wrote:
>
> Could this be a new DS type or does it apply to a whole server?
> ________________________________________
> From: Gelinas, Derek [Derek_Gelinas@comcast.com<mailto:
> Derek_Gelinas@comcast.com>]
> Sent: Tuesday, 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 as potential
> destinations by traffic router.
>
> DG
>
> On Aug 22, 2017, at 3:19 PM, Nir Sopher <nirs@qwilt.com<mailto:nirs@
> qwilt.com><ma...@qwilt.com>> wrote:
>
> 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 Service assignments".
>
> However, as you describe options #1,#2 as valid options, it seems that the
> problem you are dealing with completely resides in the "servers" domain -
> as the server should have the same behavior for all delivery-services.
> Therefore, option #1 might be more suitable.
>
> Nir
>
> On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <Derek_Gelinas@comcast.com
> <ma...@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) <
> efriedri@cisco.com<ma...@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_Gelinas@comcast.com<
> mailto:Derek_Gelinas@comcast.com><ma...@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) <
> efriedri@cisco.com<ma...@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_Gelinas@comcast.com<ma...@comcast.com><mailto:
> Derek_Gelinas@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
>
>
>
>
>
>
>

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

I suppose it could be a new type.  How are you thinking we'd implement in that case? Off the cuff I'm thinking we could have a type filter ds parameter which would list the various server types we want routed.  In that way we could differentiate between the default edge type and something else.  Doing it that way would require a bit of retooling the query used to generate the delivery service list, but that's about it.  Though in that case it really wouldn't need to be a different delivery service type, so I suspect you've something else in mind.

On Aug 23, 2017, at 12:14 AM, Eric Friedrich (efriedri) <ef...@cisco.com>> wrote:

Could this be a new DS type or does it apply to a whole server?
________________________________________
From: Gelinas, Derek [Derek_Gelinas@comcast.com<ma...@comcast.com>]
Sent: Tuesday, August 22, 2017 6:22 PM
To: dev@trafficcontrol.incubator.apache.org<ma...@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 as potential destinations by traffic router.

DG

On Aug 22, 2017, at 3:19 PM, Nir Sopher <ni...@qwilt.com>> wrote:

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 Service assignments".

However, as you describe options #1,#2 as valid options, it seems that the
problem you are dealing with completely resides in the "servers" domain -
as the server should have the same behavior for all delivery-services.
Therefore, option #1 might be more suitable.

Nir

On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <De...@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) <
efriedri@cisco.com<ma...@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 <De...@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) <
efriedri@cisco.com<ma...@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_Gelinas@comcast.com<ma...@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

RE: Preventing routing to individual caches

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

Could this be a new DS type or does it apply to a whole server?
________________________________________
From: Gelinas, Derek [Derek_Gelinas@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 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 <ni...@qwilt.com>> wrote:

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 Service assignments".

However, as you describe options #1,#2 as valid options, it seems that the
problem you are dealing with completely resides in the "servers" domain -
as the server should have the same behavior for all delivery-services.
Therefore, option #1 might be more suitable.

Nir

On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <De...@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) <
efriedri@cisco.com<ma...@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 <De...@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) <
efriedri@cisco.com<ma...@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_Gelinas@comcast.com<ma...@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

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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 <ni...@qwilt.com>> wrote:

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 Service assignments".

However, as you describe options #1,#2 as valid options, it seems that the
problem you are dealing with completely resides in the "servers" domain -
as the server should have the same behavior for all delivery-services.
Therefore, option #1 might be more suitable.

Nir

On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <De...@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) <
efriedri@cisco.com<ma...@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 <De...@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) <
efriedri@cisco.com<ma...@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_Gelinas@comcast.com<ma...@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

Re: Preventing routing to individual caches

[Nir Sopher <ni...@qwilt.com>]

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 Service assignments".

However, as you describe options #1,#2 as valid options, it seems that the
problem you are dealing with completely resides in the "servers" domain -
as the server should have the same behavior for all delivery-services.
Therefore, option #1 might be more suitable.

Nir

On Tue, Aug 22, 2017 at 8:45 PM, Gelinas, Derek <De...@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) <
> efriedri@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 <De...@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) <
> efriedri@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_Gelinas@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
> >>>
> >>
> >
>
>

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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) <ef...@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 <De...@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) <ef...@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 <De...@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
>>> 
>> 
> 

Re: Preventing routing to individual caches

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

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 <De...@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) <ef...@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 <De...@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
>> 
> 

Re: Preventing routing to individual caches

["Gelinas, Derek" <De...@comcast.com>]

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) <ef...@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 <De...@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
> 

Re: Preventing routing to individual caches

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

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 <De...@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