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_geli...@comcast.com> wrote: > I’d agree with you if this was designed to drain, but this is intended as > a permanent state for a pretty good long list of caches. > > DG > > > On Aug 22, 2017, at 1:28 PM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > > > > What about a modification of option 1- adding a new state per server. > > > > Instead of ADMIN_DOWN, it could be “REPORTED_DRAIN” to indicate the > difference > > > > —Eric > > > >> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek <derek_geli...@comcast.com> > wrote: > >> > >> That’s actually the workaround we’re using at the moment - setting them > to admin_down. That’s a temporary measure, though - we want something more > permanent. > >> > >> DG > >>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > >>> > >>> How does your use case differ from marking a server as offline in > Traffic Ops and snapshotting? > >>> > >>> Thats the easiest way I can think of to get a server in this state > >>> > >>> —Eric > >>> > >>>> On Aug 22, 2017, at 1:00 PM, Gelinas, Derek < > derek_geli...@comcast.com> wrote: > >>>> > >>>> We’ve run across a situation in which we need certain caches to > simultaneously have map rules for a delivery service, but not actually have > those caches routed to when requests are made via traffic router. > Essentially, this means removing the delivery service from the cache’s info > in the crconfig file. > >>>> > >>>> There’s been a bit of internal debate about the best ways to do this, > and I’d like to collect some opinions on the matter. > >>>> > >>>> 1) Server table flag - when marked, nothing is routed to the host at > all. Not as configurable as option 3, but more so than option 2. Faster > than option 2 as it would be returned with existing search results and > could be easily filtered on. Minor UI change only. > >>>> 2) Profile parameter - when marked, nothing is routed to any host > with this profile. Heavy handed, and would require additional profile > parameter lookups when generating the crconfig, so it’d slow it down. No UI > change. > >>>> 3) deliveryservice_servers table flag - an additional column that is > true by default. When desired, the user could pull up a sub-window within > the delivery service configuration that would present a list of the hosts > which have been assigned to the delivery service (and are not of org > type). The user could deselect the desired hosts, setting the DSS routing > value to false. This server would then be ignored when generating the > crconfig data for that specific delivery service. This would be the most > configurable option, and should be as quick as option 1, but would require > the most extensive code changes. > >>>> > >>>> Personally, I like option 3, but would very much like to hear > opinions, arguments, and other options that I haven’t thought of or listed > here. > >>>> > >>>> Derek > >>> > >> > > > >
