I don’t believe that we want to have this as just a parameter - this is not a
minor setting, and it’s not something we want lost in the noise.
Unless anyone has any objections, I’m going to set this up as a new profile
column with a checkbox in the profile settings of the UI.
Derek
> On Aug 24, 2017, at 12:34 PM, Eric Friedrich (efriedri) <efrie...@cisco.com>
> wrote:
>
> This is more of a general question, not related to this specific feature:
>
> What determines when something can be a new column in the profile table
> versus a parameter? (this also goes back to our DB normalization discussion)
>
> --Eric
>
> ________________________________________
> From: Mark Torluemke <mtorlue...@apache.org>
> Sent: Thursday, August 24, 2017 12:11 PM
> To: dev@trafficcontrol.incubator.apache.org
> Subject: Re: Preventing routing to individual caches
>
> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
