Eric,

The use case is better customizability by allowing a delivery service’s routing 
name
(e.g. “edge” or “tr” currently) to be whatever you want. Right now a DS’s FQDN
typically follows this format: <routing_name>.<xml_id>.<cdn_domain>

For example: edge.my-ds.mycdn.com

However, that <xml_id> portion really comes from the chosen HOST_REGEXP (Order: 
0),
which the API auto-creates for you using the xml_id like so:
.*\.<xml_id>\..*

For example: .*\.my-ds\..*

If a different HOST_REGEXP (Order: 0) is created for that DS, for instance 
“.*\.still-my-ds\..*”,
the DS’s FQDN would be “edge.still-my-ds.mycdn.com”. So, the DS xml_id isn’t 
really tied to the
DS’s FQDN; it’s just what is used by default. With customizable routing names, 
that FQDN could
be “foo.still-my-ds.mycdn.com” or “bar.still-my-ds.mycdn.com”.

Today, you can change the HTTP routing name for a CDN (currently defaulted to 
“tr”) by changing
the “http.routing.name” parameter in the Traffic Router’s “http.properties” 
file for all Traffic
Routers in the CDN. However, this parameter isn’t tied back to Traffic Ops, 
which is why in the UI
an HTTP delivery service’s example URL uses the routing name “ccr”. That 
mismatches with the
current functional default of “tr”. With customizable routing names, the user 
will be able to choose
through the UI or API whatever they want, and the shown example URLs will 
actually be functional.

--Rawlin

On 8/7/17, 6:16 AM, "Eric Friedrich (efriedri)" <efrie...@cisco.com> wrote:

    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) <zhilh...@cisco.com> 
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)" <efrie...@cisco.com> 
wrote:
    > 
    > 
    >> 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
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    > 
    > 
    > 
    
    

Reply via email to