@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
>
>
>
>
