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 <[email protected]> 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 <[email protected]> > 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 >>
