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 <[email protected]> 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, [email protected] < > [email protected]> 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" <[email protected]> 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) < > [email protected]> 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 < > [email protected]> 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) < > [email protected]> 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 < > [email protected]> 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 > >>>>> > >>>> > >>> > >> > >> > > > >
