> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <rawlin_pet...@comcast.com> 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)" <efrie...@cisco.com> 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 > <rawlin_pet...@comcast.com<mailto:rawlin_pet...@comcast.com>> 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" > <neu...@apache.org<mailto:neu...@apache.org>> 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 > <ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com>> > 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 > cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com><mailto: > cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>> > > > From: David Neuman > <david.neuma...@gmail.com<mailto:david.neuma...@gmail.com>> > Reply-To: > "dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org>" > < > > dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org>> > Date: Friday, August 4, 2017 at 8:40 AM > To: > "dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org>" > < > > dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org>> > 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 > <ryan_dur...@comcast.com<mailto:ryan_dur...@comcast.com>< > mailto:ryan_dur...@comcast.com>> > 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 > cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com><mailto: > cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>><mailto: > > cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com><mailto:cdn_supp...@comcast.com>> > > > From: Jan van Doorn > <j...@knutsel.com<mailto:j...@knutsel.com><mailto:j...@knutsel.com>> > Reply-To: > "dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org><mailto:dev@ > > trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" > < > > dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org><mailto:dev@ > > trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>> > Date: Friday, August 4, 2017 at 8:04 AM > To: > "dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org><mailto:dev@ > > trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" > < > > dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org><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) < > > efrie...@cisco.com<mailto:efrie...@cisco.com><mailto:efrie...@cisco.com><mailto:efrie...@cisco.com > <mailto:efrie...@cisco.com%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 <rawlin_pet...@comcast.com< > mailto:rawlin_pet...@comcast.com>< > mailto:rawlin_pet...@comcast.com> > <mailto:rawlin_pet...@comcast.com><mailto:rawlin_pet...@comcast.com > %3e><mailto:rawlin_pet...@comcast.com%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" <rawlin_pet...@comcast.com<mailto: > rawlin_pet...@comcast.com><mailto: > rawlin_pet...@comcast.com<mailto:rawlin_pet...@comcast.com>><mailto: > rawlin_pet...@comcast.com<mailto:rawlin_pet...@comcast.com><mailto: > rawlin_pet...@comcast.com>><mailto:rawlin_pet...@comcast.com%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 > > > > > > > > > > > > >
