Inline On Thu, Aug 3, 2017 at 1:57 PM, Peters, Rawlin <[email protected]> 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" <[email protected]> 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. > > [DN] +1 from me > > 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. > > [DN] I don't really mind either way, but I lean towards adding a column to the DS table. Just because we already have a lot of columns isn't a good reason to not add another one. I assume that in most of the places that we are setting the routing name we already have the DS "object" in memory so it would probably avoid an extra call to the database to get a parameter. > > 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’. > [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. > > 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 > > >
