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