Rawlin- I’m all good with your proposal, but I think some background might be helpful.
What’s the use case behind this feature? And how is the DS xml_id tied to the delivery service’s FQDN? —Eric > On Aug 7, 2017, at 2:13 AM, Zhilin Huang (zhilhuan) <[email protected]> > wrote: > > Sorry for missing this topic. > > Yes, I think this feature is different with the customized domain feature. If > you are interested, my work is in my fork: > https://github.com/apache/incubator-trafficcontrol/compare/master...zhilhuan:custom-ds-domain?expand=1 > > Thanks, > Zhilin > > > On 8/5/17, 3:51 AM, "Eric Friedrich (efriedri)" <[email protected]> wrote: > > >> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <[email protected]> wrote: >> >> Ok, it makes sense that if it can support fully customized DS domain names, >> there would be >> nothing stopping the user from entering a HOST_REGEXP >> “foo.ds.cdn.company.com” to >> essentially pick “foo” as the custom routing name. However, I think that >> misses the point >> of custom routing names. If the xml_id or CDN domain name changes, that >> HOST_REGEXP >> would no longer work and would need updated to keep the DS running, right? > EF> Ok I understand now! The purpose is not to be able to use something > instead of “edge” or “tr” but to keep the HOST_REGEXP static when xml_id or > domain_name change. > >> >> Custom routing names would be for users who continue to use the default >> “.*\.ds\..*” >> HOST_REGEXP in their delivery service rather than a fully-customized domain. >> That way >> they can change their DS more freely without the HOST_REGEXP requiring >> constant updating. >> >> --Rawlin >> >> On 8/4/17, 10:50 AM, "Eric Friedrich (efriedri)" <[email protected]> wrote: >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> >> > > >
