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