As I understand Zhilin’s changes, they are a superset of changing the routing name.
Whereas today we must have “tr.ds.cdn.company.com<http://tr.ds.cdn.company.com>” or “edge.”, with Zhilin’s changes you can set a completely custom DS FQDN. As he puts it in his original email, "And “my-subdomain.topdomain.com<http://my-subdomain.topdomain.com>” in pattern 2) will be used as the RFQDN instead of “tr.my-subdomain.cdndomain.com<http://tr.my-subdomain.cdndomain.com>” or “edge.my-subdomain.cdndomain.com<http://edge.my-subdomain.cdndomain.com>”. This way, user can fully customize the whole domain for a delivery service.” This should (I hope!) extend to being able to set “customroutingname.ds.cdn.company.com<http://customroutingname.ds.cdn.company.com>” on a per-DS basis (or really any other custom Delivery Service FQDN someone could want). The motivation behind his proposal is to better support wholesale customers who want to bring their own domain without needing to CNAME over to the CDN (and play the corresponding games with HTTPS certs) —Eric On Aug 4, 2017, at 12:37 PM, Peters, Rawlin <[email protected]<mailto:[email protected]>> wrote: @Dave @Eric I have my current code pushed to my fork, and it can be compared against apache/master here [1]. I did see Zhilin’s original proposal on the mailing list, and I also thought it seemed similar but not the same thing as what I’d been working on. In his example, there is a reference to “tr.test.ipcdn.mycompany.com<http://tr.test.ipcdn.mycompany.com>.”, which means the routing names are not being completely replaced, and custom DS domain support would be added alongside the current functionality of using routing names like “tr” and “edge”. - Rawlin [1] https://github.com/apache/incubator-trafficcontrol/compare/master...rawlinp:per-cdn-routing-names_2 On 8/4/17, 9:39 AM, "Dave Neuman" <[email protected]<mailto:[email protected]>> wrote: @Eric It looks like Zhilin's proposal is for custom delivery service domains (eg instead of "tr.foo.domain.com<http://tr.foo.domain.com>" you can have "tr.foo.otherdomain.com<http://tr.foo.otherdomain.com>") while Rawlins is for custom routing names (eg instead of "tr.foo.domain.com<http://tr.foo.domain.com>" you can have "bar.foo.domain.com<http://bar.foo.domain.com>"). I think the two features are similar but different. Would you agree or am I misunderstanding? @Rawlin and @Zhilin if you have WIP code maybe you could open a WIP PR and we can take a look to see if there will be conflicts? --Dave On Fri, Aug 4, 2017 at 8:59 AM, Durfey, Ryan <[email protected]<mailto:[email protected]>> wrote: Yeah, I just rethought that. I was envisioning http://servicename.customername.cdn_domain/ where we could get a cert for “*.customername.cdn_domain/” for multiple customer services. However, we currently have to use the format http://servicename- cusotmername.cdn_domain/ where a wildcard cert would not be applicable. Apologies for the confusion. Ryan Durfey M | 303-524-5099 CDN Support (24x7): 866-405-2993 or [email protected]<mailto:[email protected]><mailto: [email protected]<mailto:[email protected]>> From: David Neuman <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" < [email protected]<mailto:[email protected]>> Date: Friday, August 4, 2017 at 8:40 AM To: "[email protected]<mailto:[email protected]>" < [email protected]<mailto:[email protected]>> Subject: Re: Adding support for per-DeliveryService routing names @Ryan: “edge.” Limits our ability to use wildcard ssl certs for DNS routed services for similar customer services which can save a lot of time, cost, and hassle. Can you explain more? I don't see the need for wildcard certs when Traffic Router returns only one FQDN for a DNS routed Deliveryservice? If you are talking about a "future feature" then we should worry about that then. On Fri, Aug 4, 2017 at 8:09 AM, Durfey, Ryan <[email protected]<mailto:[email protected]>< mailto:[email protected]>> wrote: Random thought on this… “edge.” Limits our ability to use wildcard ssl certs for DNS routed services for similar customer services which can save a lot of time, cost, and hassle. “tr.” Makes sense for HTTP 302 routed services because you can use wildcard certs for the server hostname that replaces the “tr.” in the domain. Is it worth considering “tr.” for http routed and nothing for DNS routed ie. “xml-id.cdn_domain”? Ryan Durfey M | 303-524-5099 CDN Support (24x7): 866-405-2993 or [email protected]<mailto:[email protected]><mailto: [email protected]<mailto:[email protected]>><mailto: [email protected]<mailto:[email protected]><mailto:[email protected]>> From: Jan van Doorn <[email protected]<mailto:[email protected]><mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]><mailto:dev@ trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" < [email protected]<mailto:[email protected]><mailto:dev@ trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>> Date: Friday, August 4, 2017 at 8:04 AM To: "[email protected]<mailto:[email protected]><mailto:dev@ trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" < [email protected]<mailto:[email protected]><mailto:dev@ trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>> Subject: Re: Adding support for per-DeliveryService routing names 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) < [email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected] <mailto:[email protected]%3e>> 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/51d7ed1ae65a3697c39edd00236e6f 3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E<mailto: 3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E> < https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f 3897da37ef5b24ac452a17cabb@ <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 <[email protected]< mailto:[email protected]>< mailto:[email protected]> <mailto:[email protected]><mailto:[email protected] %3e><mailto:[email protected]%3e%3cmailto:Rawlin_Peters@ comcast.com%3e%3e>> 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]<mailto: [email protected]><mailto: [email protected]<mailto:[email protected]>><mailto: [email protected]<mailto:[email protected]><mailto: [email protected]>><mailto:[email protected]%3e%3e>> 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
