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 <derek_geli...@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 <derek_geli...@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.pet...@gmail.com <
> rawlin_pet...@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" <derek_geli...@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) <
> efrie...@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_geli...@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) <
> 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â?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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
