You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Rawlin Peters <ra...@gmail.com> on 2017/09/15 21:19:13 UTC
Courtesy notice: per-Delivery-Service Routing Names
Hey folks,
A new feature for Delivery Services has been merged into master
recently - per-Delivery-Service Routing Names [1] - and will end up in
release 2.2. Just so you're not surprised next time you upgrade your
environments, you will now see a "Routing Name" field when creating or
editing a Delivery Service. This field fulfills the role of the "edge"
and "tr" names (e.g. http://tr.deliveryservice.cdn-domain.com) that
have been traditionally used for DNS and HTTP Delivery Services,
respectively, except now there is no longer that distinction. A
Delivery Service's routing name can now be any valid hostname without
periods, and if left unspecified the routing name defaults to 'cdn'
(e.g. http://cdn.deliveryservice.cdn-domain.com).
Changing the routing name of a Delivery Service after it's been
deployed is not recommended, however, because it changes the Delivery
URL and will require all clients of the Delivery Service to transition
to the new URL (as well as possibly invalidating SSL certs among other
things). Right now it's an editable field, but if it causes a lot of
problems we may find it better to lock that field down and make it
read-only after creation.
I will put this in the release notes for 2.2 as well, but if you are
using an `http.routing.name` other than "tr" (i.e. your HTTP Delivery
Services use a URL that does not match this regex: |https?://tr\..*|),
then you will have to create one or more temporary upgrade parameters
before performing your next upgrade. This is possible by changing the
Traffic Router config file named `http.properties` to add an
`http.routing.name=foo` line, which would make your HTTP Delivery
Services URLs look like "http://foo.deliveryservice.cdn-domain.com".
If you have changed `http.routing.name` for your CDNs to something
other than "tr" like I've described, then you have to perform the
following steps *before* upgrading to the latest version of Traffic
Ops:
1. In Traffic Ops, create the following parameter (double-check for typos):
name: upgrade_http_routing_name
config file: temp
value: <whatever value is used for your CDN's http.routing.name>
2. Add this parameter to a *single* profile in each CDN that uses that
`http.routing.name`
3. Repeat steps 1 and 2 for each unique `http.routing.name` in use
After these parameters have been properly created, the Traffic Ops 2.2
upgrade may be done, and the Routing Name fields for pre-existing
Delivery Services will be populated with the proper values. Note:
these parameters can safely be created at any time before upgrading to
Traffic Ops 2.2 and can be removed safely after a successful upgrade
has been completed.
If you have any questions or concerns regarding this new feature,
please let me know.
- Rawlin
P.S. if you have any external tooling that relies on the stale
assumption that HTTP Delivery Service URLs start with "tr" and DNS
Delivery Service URLs start with "edge", now may be the best time to
think about updating that tooling.
[1] https://github.com/apache/incubator-trafficcontrol/pull/865
Re: Courtesy notice: per-Delivery-Service Routing Names
Posted by Rawlin Peters <ra...@gmail.com>.
Steve,
I believe we found your problem in the github issue [1], but to answer
your question for the mailing list record:
No, there is only the one `upgrade_http_routing_name` parameter which
will be used to populate the routing_name column for preexisting HTTP
Delivery Services. Preexisting DNS Delivery Services will keep their
current 'edge' routing_name.
- Rawlin
[1] https://github.com/apache/incubator-trafficcontrol/issues/1630
On Thu, Dec 7, 2017 at 9:05 PM, Steve Malenfant <sm...@gmail.com> wrote:
> Rawlin,
>
> All my "edge." are gone after an upgrade. Is there a different parameter to
> used for the DNS delivery services migration?
>
> Thanks,
>
> Steve
>
> On Fri, Sep 15, 2017 at 5:19 PM, Rawlin Peters <ra...@gmail.com>
> wrote:
>
>> Hey folks,
>>
>> A new feature for Delivery Services has been merged into master
>> recently - per-Delivery-Service Routing Names [1] - and will end up in
>> release 2.2. Just so you're not surprised next time you upgrade your
>> environments, you will now see a "Routing Name" field when creating or
>> editing a Delivery Service. This field fulfills the role of the "edge"
>> and "tr" names (e.g. http://tr.deliveryservice.cdn-domain.com) that
>> have been traditionally used for DNS and HTTP Delivery Services,
>> respectively, except now there is no longer that distinction. A
>> Delivery Service's routing name can now be any valid hostname without
>> periods, and if left unspecified the routing name defaults to 'cdn'
>> (e.g. http://cdn.deliveryservice.cdn-domain.com).
>>
>> Changing the routing name of a Delivery Service after it's been
>> deployed is not recommended, however, because it changes the Delivery
>> URL and will require all clients of the Delivery Service to transition
>> to the new URL (as well as possibly invalidating SSL certs among other
>> things). Right now it's an editable field, but if it causes a lot of
>> problems we may find it better to lock that field down and make it
>> read-only after creation.
>>
>> I will put this in the release notes for 2.2 as well, but if you are
>> using an `http.routing.name` other than "tr" (i.e. your HTTP Delivery
>> Services use a URL that does not match this regex: |https?://tr\..*|),
>> then you will have to create one or more temporary upgrade parameters
>> before performing your next upgrade. This is possible by changing the
>> Traffic Router config file named `http.properties` to add an
>> `http.routing.name=foo` line, which would make your HTTP Delivery
>> Services URLs look like "http://foo.deliveryservice.cdn-domain.com".
>>
>> If you have changed `http.routing.name` for your CDNs to something
>> other than "tr" like I've described, then you have to perform the
>> following steps *before* upgrading to the latest version of Traffic
>> Ops:
>>
>> 1. In Traffic Ops, create the following parameter (double-check for typos):
>> name: upgrade_http_routing_name
>> config file: temp
>> value: <whatever value is used for your CDN's http.routing.name>
>> 2. Add this parameter to a *single* profile in each CDN that uses that
>> `http.routing.name`
>> 3. Repeat steps 1 and 2 for each unique `http.routing.name` in use
>>
>> After these parameters have been properly created, the Traffic Ops 2.2
>> upgrade may be done, and the Routing Name fields for pre-existing
>> Delivery Services will be populated with the proper values. Note:
>> these parameters can safely be created at any time before upgrading to
>> Traffic Ops 2.2 and can be removed safely after a successful upgrade
>> has been completed.
>>
>> If you have any questions or concerns regarding this new feature,
>> please let me know.
>>
>> - Rawlin
>>
>> P.S. if you have any external tooling that relies on the stale
>> assumption that HTTP Delivery Service URLs start with "tr" and DNS
>> Delivery Service URLs start with "edge", now may be the best time to
>> think about updating that tooling.
>>
>> [1] https://github.com/apache/incubator-trafficcontrol/pull/865
>>
Re: Courtesy notice: per-Delivery-Service Routing Names
Posted by Steve Malenfant <sm...@gmail.com>.
Rawlin,
All my "edge." are gone after an upgrade. Is there a different parameter to
used for the DNS delivery services migration?
Thanks,
Steve
On Fri, Sep 15, 2017 at 5:19 PM, Rawlin Peters <ra...@gmail.com>
wrote:
> Hey folks,
>
> A new feature for Delivery Services has been merged into master
> recently - per-Delivery-Service Routing Names [1] - and will end up in
> release 2.2. Just so you're not surprised next time you upgrade your
> environments, you will now see a "Routing Name" field when creating or
> editing a Delivery Service. This field fulfills the role of the "edge"
> and "tr" names (e.g. http://tr.deliveryservice.cdn-domain.com) that
> have been traditionally used for DNS and HTTP Delivery Services,
> respectively, except now there is no longer that distinction. A
> Delivery Service's routing name can now be any valid hostname without
> periods, and if left unspecified the routing name defaults to 'cdn'
> (e.g. http://cdn.deliveryservice.cdn-domain.com).
>
> Changing the routing name of a Delivery Service after it's been
> deployed is not recommended, however, because it changes the Delivery
> URL and will require all clients of the Delivery Service to transition
> to the new URL (as well as possibly invalidating SSL certs among other
> things). Right now it's an editable field, but if it causes a lot of
> problems we may find it better to lock that field down and make it
> read-only after creation.
>
> I will put this in the release notes for 2.2 as well, but if you are
> using an `http.routing.name` other than "tr" (i.e. your HTTP Delivery
> Services use a URL that does not match this regex: |https?://tr\..*|),
> then you will have to create one or more temporary upgrade parameters
> before performing your next upgrade. This is possible by changing the
> Traffic Router config file named `http.properties` to add an
> `http.routing.name=foo` line, which would make your HTTP Delivery
> Services URLs look like "http://foo.deliveryservice.cdn-domain.com".
>
> If you have changed `http.routing.name` for your CDNs to something
> other than "tr" like I've described, then you have to perform the
> following steps *before* upgrading to the latest version of Traffic
> Ops:
>
> 1. In Traffic Ops, create the following parameter (double-check for typos):
> name: upgrade_http_routing_name
> config file: temp
> value: <whatever value is used for your CDN's http.routing.name>
> 2. Add this parameter to a *single* profile in each CDN that uses that
> `http.routing.name`
> 3. Repeat steps 1 and 2 for each unique `http.routing.name` in use
>
> After these parameters have been properly created, the Traffic Ops 2.2
> upgrade may be done, and the Routing Name fields for pre-existing
> Delivery Services will be populated with the proper values. Note:
> these parameters can safely be created at any time before upgrading to
> Traffic Ops 2.2 and can be removed safely after a successful upgrade
> has been completed.
>
> If you have any questions or concerns regarding this new feature,
> please let me know.
>
> - Rawlin
>
> P.S. if you have any external tooling that relies on the stale
> assumption that HTTP Delivery Service URLs start with "tr" and DNS
> Delivery Service URLs start with "edge", now may be the best time to
> think about updating that tooling.
>
> [1] https://github.com/apache/incubator-trafficcontrol/pull/865
>