@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]> 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]> > > > From: Jan van Doorn <[email protected]> > Reply-To: "[email protected]" < > [email protected]> > Date: Friday, August 4, 2017 at 8:04 AM > To: "[email protected]" < > [email protected]> > 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]>> > 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 > < > 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]%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]>>> 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 > > > > > >
