Re: Adding support for per-DeliveryService routing names

Ok, I think what it really comes down to is whether or not we really want to provide configurable default routing names and thus perpetuate the DNS vs HTTP routing name convention after we have support for per-DS routing names. Some CDNs might find it useful to force new DSes to that convention

Re: Adding support for per-DeliveryService routing names

+1 on setting the default in the DB. Also, +1 on doing the right thing in the code like Jeremy is describing. On Tue, Aug 15, 2017 at 10:06 AM, Jeremy Mitchell wrote: > basically what i'm saying is if you are going to keep routing_name as a non > null column you are going to have to handle it's

Re: Adding support for per-DeliveryService routing names

basically what i'm saying is if you are going to keep routing_name as a non null column you are going to have to handle it's potential absence in the api layeri think... jeremy On Tue, Aug 15, 2017 at 10:02 AM, Jeremy Mitchell wrote: > thb i'm not 100% sure how db defaults work but i think

Re: Adding support for per-DeliveryService routing names

thb i'm not 100% sure how db defaults work but i think in the DS api create/update since routing_name is going to be optional, you'll want to see if it exists (and not "") in the request json and if so, use that value to update the db else retrieve the default (from wherever you decide) and use tha

Re: Adding support for per-DeliveryService routing names

How do we feel about setting a default for the column in the DB schema? The routing name can be any arbitrary hostname (without periods) after this support is added, and if someone doesn’t like the default we choose, they can always provide/update their own routing_name via the UI/API. --Rawlin

Re: Adding support for per-DeliveryService routing names

Rawlin, That sounds like a solid plan, however, keep in mind that although it's unlikely, we may have users that have elected to change the default routing name for DNS delivery services. Thus, step 2 should not be run as defined, and steps 3 and 4 should be applied to the DNS routing name case in

Re: Adding support for per-DeliveryService routing names

+1 A new requirement is a breaking change, needs to be a new major version, or a default value that doesn't break existing usage. On Tue, Aug 15, 2017 at 8:40 AM, Dewayne Richardson wrote: > This is a tough one because the obvious ways of breaking an API are "URL > format changes", "Request or

Re: Adding support for per-DeliveryService routing names

This is a tough one because the obvious ways of breaking an API are "URL format changes", "Request or Response format changes", etc. But I think the more obvious way to think about the API is, do the clients have to change their code? If the answer is yes, it's a breaking API change. So, really

Re: Adding support for per-DeliveryService routing names

I don't think you can add a new not null column to the ds table because that would break the DS api. For example, on DS create/update you are saying routing_name is now required, right? This is an API breaking change that would require a new version of the API, no? Hence my suggestion for a defaul

Re: Adding support for per-DeliveryService routing names

Jeremy’s suggestion could work, but the param would probably be created in a TR_PROFILE per-CDN. However, that still wouldn’t fix the visibility problem. If a CDN isn’t using the default “tr” HTTP routing name, operators would still need to know that there is a new profile parameter that needs u

Re: Adding support for per-DeliveryService routing names

I don't think that solves the issue Rawlin was describing. The issue that Rawlin was describing is that someone has already defined a different routing name in traffic_router/http.properties which is no longer going to be used after the upgrade. The upgrade needs to somehow know about this other

Re: Adding support for per-DeliveryService routing names

Adding a temp parameter would work but I worry that someone won't read the upgrade documentation and forget to create this temporary parameter before running the upgrade. Here's another option. Create 2 global TO parameters (http.routing.name and dns.routing.name ) that

Re: Adding support for per-DeliveryService routing names

Good info Rawlin. My vote would be for a parameter to be used during the upgrade. We can set a param called `upgrade_routing_name` or something similiar so that it is obvious that it is a param used for upgrade only. We should also document that A) the param needs to be set before upgrade and B)

Re: Adding support for per-DeliveryService routing names

Hey all, I’ve dug through this a bit more, and defaulting a new DeliveryService.routing_name column to ‘tr’ for HTTP delivery services presents an upgrade issue if a CDN has chosen to use a custom “http.routing.name” parameter for the Traffic Routers in that CDN (by editing the http.properties fi

Re: Adding support for per-DeliveryService routing names

cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>> cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>> >> >> >> From: David Neuman mailto:david.neuma...@gmail.com>> >> Reply-To: "dev@trafficcontrol.in

Re: Adding support for per-DeliveryService routing names

.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@trafficcontr

Re: Adding support for per-DeliveryService routing names

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 DurfeyM | 303-524-5099 >> CDN Support (24x7): 866-405-2993 or >> cdn_sup

Re: Adding support for per-DeliveryService routing names

st.com>cdn_supp...@comcast.com<mailto:cdn_supp...@comcast.com>> > > >From: David Neuman mailto:david.neuma...@gmail.com>> >Reply-To: "dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org>"

Re: Adding support for per-DeliveryService routing names

>From: Jan van Doorn > 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://traf

Re: Adding support for per-DeliveryService routing names

ubator.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@trafficco

Re: Adding support for per-DeliveryService routing names

: 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 routi

Re: Adding support for per-DeliveryService routing names

ubator.apache.org> > Date: Friday, August 4, 2017 at 8:40 AM > To: "dev@trafficcontrol.incubator.apache.org" < > dev@trafficcontrol.incubator.apache.org> > Subject: Re: Adding support for per-DeliveryService routing names > > @Ryan: &

Re: Adding support for per-DeliveryService routing names

@Dave @JvD Thanks for the feedback. I think I can get on board with defaulting the DS columns to ‘edge’ and ‘tr’. I was thinking the CDN columns might be useful if the user just wants to set it CDN-wide and not individually on each DS, but I guess if we default it as part of the upgrade migrati

Re: Adding support for per-DeliveryService routing names

@trafficcontrol.incubator.apache.org" < > dev@trafficcontrol.incubator.apache.org> > Date: Friday, August 4, 2017 at 8:40 AM > To: "dev@trafficcontrol.incubator.apache.org" < > dev@trafficcontrol.incubator.apache.org> > Subject: Re: Adding support for

Re: Adding support for per-DeliveryService routing names

2017 at 8:40 AM To: "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 has

Re: Adding support for per-DeliveryService routing names

control.incubator.apache.org> > Date: Friday, August 4, 2017 at 8:04 AM > To: "dev@trafficcontrol.incubator.apache.org" < > dev@trafficcontrol.incubator.apache.org> > Subject: Re: Adding support for per-DeliveryService routing names > > Agree with Dave on > > [*DN] we sho

Re: Adding support for per-DeliveryService routing names

: "dev@trafficcontrol.incubator.apache.org" Date: Friday, August 4, 2017 at 8:04 AM To: "dev@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" f

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 se

Re: Adding support for per-DeliveryService routing names

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/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E

Re: Adding support for per-DeliveryService routing names

Inline On Thu, Aug 3, 2017 at 1:57 PM, Peters, Rawlin 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" wrote: > > Hello All, > > I’ve been working on adding support for configurable per-

Re: Adding support for per-DeliveryService routing names

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" wrote: Hello All, I’ve been working on adding support for configurable per-CDN and per-DeliveryService routing names [1] (what are currently hardc

Adding support for per-DeliveryService routing names

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 tab