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 <[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 >>>>>> >>>>> >>>> >>> >>> >> >
