Hey all,

I’ve dug through this a bit more, and defaulting a new 
DeliveryService.routing_name
column to ‘tr’ for HTTP delivery services presents an upgrade issue if a CDN has
chosen to use a custom “http.routing.name” parameter for the Traffic Routers
in that CDN (by editing the http.properties files of the Traffic Routers).

For instance, if “http.routing.name” has been set to “ccr”, the new routing name
“tr” will break all of the clients using the old “ccr” delivery service URL.

Basically we need to provide a one-time upgrade step to allow CDNs using a 
custom 
“http.routing.name” to default the new routing_name column to that value for
existing HTTP delivery services. What would be the best way to do this? Some 
options
might be:
1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade, read that
    parameter and use it to update the routing_name for existing HTTP delivery 
services.
    After upgrade, you can safely remove the profile parameter.
2. Let the upgrade automatically default the routing_name to ‘tr’ or ‘edge’. 
After 
    upgrading, manually update each HTTP delivery service to use the current 
    “http.routing.name” in use (we could provide an API endpoint to “bulk 
update” the 
    routing names for all HTTP delivery services in a CDN).

Note this is not an exhaustive list, this is a just a couple options that have 
come up in
discussion so far. Feel free to add any more ideas to this list.

After the upgrade has been completed, the “http.routing.name” parameter in the
Traffic Router’s “http.properties” file will be ignored (same with the 
“dns.routing.name”
parameter in “dns.properties” which I’m not sure can even be changed safely 
today).

Thoughts?

--Rawlin

On 8/4/17, 10:19 AM, "Peters, Rawlin" <rawlin_pet...@comcast.com> wrote:

    @Dave @JvD
    
    Thanks for the feedback. I think I can get on board with defaulting the DS 
columns to ‘edge’ and ‘tr’. I was thinking the CDN columns might be useful if 
the user just wants to set it CDN-wide and not individually on each DS, but I 
guess if we default it as part of the upgrade migration, we should also provide 
an API endpoint to set the routing names on all DSes in a CDN to a single 
value, thus still providing a “per-CDN” option. Would a “bulk” update also be 
useful, in case a user wants to update a handful of DSes to the same routing 
names at once?
    
    @JvD Re: TR_PROFILE vs. DS_PROFILE
    The default would come from a TR_PROFILE linked to the CDN, and the 
override would come from a DS_PROFILE linked to that specific DS. I looked into 
those options to cover all my bases, but I think adding columns to at least the 
DS table and not touching profiles at all is the better option.
    
    -Rawlin
    
    On 8/4/17, 8:04 AM, "Jan van Doorn" <j...@knutsel.com> wrote:
    
        Agree with Dave on
        
        [*DN] we should default the database column to "edge" for DNS and "tr" 
for*
        *http.  Then we don't have to do the null check.*
        
        If we do that, we can make the columns mandatory, and it makes sense
        they're not in the DS_PROFILE. Also makes it so we don't have to have a 
CDN
        wide setting. (and Rawlin, I think you mean to say DS_PROFILE rather 
than
        TR_PROFILE type to add the param to if we chose to do that?? Or was it 
the
        default that goes into TR_PROFILE and the override into DS_PROFILE?).
        In any case - if we make the columns NOT NULL and default them to "tr" 
and
        "edge", I'm +1 on columns in the deliveryservice table.
    
    
        
        Cheers,
        JvD
        
        On Fri, Aug 4, 2017 at 7:12 AM Eric Friedrich (efriedri) 
<efrie...@cisco.com>
        wrote:
        
        > Hey Rawlin-
        >   Zhilin has also been working on a very similar feature which was
        > proposed on this mailer last month:
        > 
https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
        > <
        > 
https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
        > <dev.trafficcontrol.apache.org>>
        >
        > Can you please work him to ensure we don’t duplicate work and that if 
both
        > solutions are needed they will work together?
        >
        > On Aug 3, 2017, at 3:57 PM, Peters, Rawlin <rawlin_pet...@comcast.com
        > <mailto:rawlin_pet...@comcast.com>> wrote:
        >
        > Sorry, Outlook converted my numbered list poorly. I’ve corrected the
        > numbering (items 1-3) below.
        >
        > On 8/3/17, 1:52 PM, "Peters, Rawlin" 
<rawlin_pet...@comcast.com<mailto:
        > rawlin_pet...@comcast.com>> wrote:
        >
        >    Hello All,
        >
        >    I’ve been working on adding support for configurable per-CDN and
        > per-DeliveryService routing names [1] (what are currently
        > hardcoded/defaulted to ‘edge’ and ‘tr’ for DNS and HTTP Delivery 
Services,
        > respectively), and I have a few things to propose.
        >
        >
        >      1.  Add a column to the CDN table for the DNS and HTTP routing 
names.
        >
        >
        >
        >    I’ve currently been working off the assumption that per-CDN routing
        > names would be configurable by adding ‘http.routing.name’ and ‘
        > dns.routing.name’ parameters to a profile of type TR_PROFILE using the
        > ‘CRConfig.json’ config file. To me this seems like bad UX because the 
user
        > has to click through multiple steps and fill in multiple fields in 
the UI
        > just to change the CDN’s routing names. It also requires joining a few
        > different tables in the DB just to find the parameters per-CDN. For 
that
        > reason, I think it would be better if ‘dns_routing_name’ and
        > ‘http_routing_name’ were added as columns of the ‘cdn’ table, and 
changing
        > them via the UI would follow the same process as choosing the CDN’s 
domain
        > name. Because the routing names would be the CDN-wide defaults, the 
‘Edit
        > CDN’ window feels like the most natural place to put it.
        >
        >
        >      2.  Values for per-DeliveryService routing names could live in 
one of
        > a couple different areas:
        >         *   New columns in the delivery_service table
        >         *   Parameters in a DS Profile
        >
        >    As the developer, my vote would be for Option A because it seems 
like
        > it would lead to cleaner code in Traffic Ops because the routing names
        > would be readily-available when handling a DeliveryService. You 
wouldn’t
        > have to also fetch its profile then dig through it to find the routing
        > names. A downside could be that adding columns to an 
already-overcrowded
        > table isn’t ideal.
        >
        >    Option B is less appealing to me but might have some advantages 
such as
        > keeping the number of columns down in the DeliveryService table. 
However,
        > DS Profiles currently seem to be geared more towards the Multi-site 
Origin
        > feature in generating specific ATS configuration (parent.config) and 
less
        > towards a “junk drawer for optional config”. As the routing names 
would
        > affect the entire DS and multiple config files, it doesn’t seem right 
to
        > have it as a profile parameter using ‘CRConfig.json’ as the config 
file. I
        > wasn’t around when DS Profiles were introduced, so if you are more 
familiar
        > with their purpose/origin and think this is a good fit for them, I’d 
like
        > to hear your advice.
        >
        >
        >      3.  If per-DeliveryService routing names are not set explicitly 
for a
        > DS (i.e. the column is null), then the DS will use the per-CDN routing
        > names as a default. If the per-CDN routing names are unset, they will
        > default to the current values of ‘edge’ and ‘tr’. So the lookup 
hierarchy
        > would be DS.routing_names -> CDN.routing_names -> default ‘edge/tr’.
        >
        >    I’d like to know what you think of these proposals, and any
        > advice/feedback is welcome.
        >
        >    Best regards,
        >    Rawlin
        >
        >    [1] https://issues.apache.org/jira/browse/TC-287
        >
        >
        >
        >
        
    
    

Reply via email to