Courtesy notice: per-Delivery-Service Routing Names

[Rawlin Peters]

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: 
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: Traffic Ops Rewrite Golang Dependency - sqlx

[Dewayne Richardson]

The deadline of Friday 09-15 at noon has passed, sqlx as a TO Golang
Dependency has been accepted. The vote tally is 6 Aye to 2 Nay's

Have a good weekend,

-Dew

Results:
Dan Kirkwood: +1
Derek Gelina: +1
Dewayne Richardson: +1
Dylan Volz: +1
Jan Van Doorn: +1
Jeremy Mitchell: +1

Chris Lemmons: -1
Rob Butts: -1

On Wed, Sep 13, 2017 at 10:05 AM, Volz, Dylan (Contractor) <
dylan_v...@comcast.com> wrote:

> I see, just looked at SliceScan, I mistakenly assumed it was how they
> implement selecting into a slice of structs which is one of the features
> that is very useful versus the straight sql implementation.
>
> On 9/13/17, 9:59 AM, "Chris Lemmons"  wrote:
>
> That's not the problem that SliceScan helps with. SliceScan helps when
> you
> don't have control of the sql statement and you don't know the columns
> that
> will be returned, or how many will be returned. MapScan does the same,
> but
> puts it into a map, so you can iterate over them. That's a major
> feature
> that isn't available in the standard `sql` library, and would
> definitely
> justify the inclusion of `sqlx`. I don't think that's something we
> really
> want, though, because we control the sql statements.
>
> On Wed, Sep 13, 2017 at 8:54 AM, Volz, Dylan (Contractor) <
> dylan_v...@comcast.com> wrote:
>
> > Yes Select, or the SliceScan is one of the reasons I would use sqlx,
> I am
> > pulling out sets using IN and left outer joins to avoid the tight
> looping
> > issues in some endpoints in the perl.
> >
> > On 9/13/17, 8:42 AM, "Chris Lemmons"  wrote:
> >
> > I see that there's a significant preference to not list the
> members of
> > the
> > struct in the Scan function. That works.
> >
> > I'm still not certain I understand why we'd prefer to bring in
> all of
> > `sqlx` instead of writing a single, fairly simple function to
> return
> > the
> > columns for the scan. Are there plans to use MapScan or
> SliceScan?
> > Cause
> > that's really where `sqlx` starts to be worth it's cost.
> >
> > Still, to be sure we're all on the same page wrt performance, the
> > reason
> > the performance is fairly good is because the cost is per-query,
> not
> > per-row. Since we're pretty good about our queries, I'm fairly
> happy
> > with
> > it's performance. If we're doing queries in a tight loop, it will
> > start to
> > bite us, but network delay would bite us harder.
> >
> > On Wed, Sep 13, 2017 at 8:18 AM, Dewayne Richardson <
> dewr...@gmail.com
> > >
> > wrote:
> >
> > > I also agree but I think your argument about future cost is
> more
> > > "speculative" than reality.  If we're smart about how we
> integrate
> > sqlx,
> > > then we can hedge the bet.
> > >
> > > -Dew
> > >
> > > On Tue, Sep 12, 2017 at 7:52 PM, Robert Butts <
> > robert.o.bu...@gmail.com>
> > > wrote:
> > >
> > > > I am a pretty big -1 on sqlx. Those PRs are extremely
> deceptive.
> > > >
> > > > Those lines are entirely unnecessary.
> > > >
> > > > I have created an example PR at
> https://github.com/apache/incu
> > > > bator-trafficcontrol/pull/1165
> > > >
> > > > The relevant commits are
> > > > https://github.com/apache/incubator-trafficcontrol/pull/1165
> > > > /commits/6fc735d7f97eaaffbf08e8457b7ccb6bf14baca0
> > > > https://github.com/apache/incubator-trafficcontrol/pull/1165
> > > > /commits/6939ee1d401c571af139db53b018a5e53f80c02a#diff-219ca
> > > > ea1a282285fe1cc21e53bf9dafbL26
> > > >
> > > > As you can see, the only difference is that
> `rows.StructScan()`
> > > becomes `
> > > > rows.Scan(, , ,
> , 
> > > > DomainName, , , , ,
> > ,
> > > 
> > > > IloIpGateway, , ,
> , 
> > > > InterfaceMtu, , , ,
> > > ,
> > > > , , ,
> , 
> > > > MgmtIpGateway, , ,
> > , 
> > > > PhysLocationId, , , ,
> ,
> > 
> > > > RevalPending, , ,
> ,
> > > ,
> > > > , , , ,
> > , 
> > > > XmppPasswd)`
> > > >
> > > > It is a one-line difference per endpoint, not 100 lines.
> (Plus
> > column
> > > > annotations on every struct field for sqlx)
> > > >
> > > > That said, I agree the former is better for readability. The
> issue
> > is the
> > > > maintenance cost, when-not-if sqlx stops being maintained.
> It will
> > be
> > > > embedded in Traffic Ops, in every single endpoint and query.
> We'll
> > be in
> > > > exactly the same position we are with Goose, stuck with an
> > unmaintained
> > > and
> > > > probably 

Re: Removing installation dependencies

[Eric Friedrich (efriedri)]

Jan-
  No need to apologize! 

One of my favorite things about open source is that we solve problems for each 
other and can improve on each solutions. 

I’m really glad you took the time to move those mid rewrite params out into a 
separate profile and even happier that there was automation for it. We have 
some different goals than you do, so we’re glad to iterate on this and 
hopefully contribute something useful for others in a similar position to us

—Eric

> On Sep 14, 2017, at 12:20 PM, Jan van Doorn  wrote:
> 
> The go migration is my fault…. I couldn’t figure out how to do some of that 
> stuff in SQL, and I think anyone would be hard pressed to do that. 
> 
> Wasn’t aware we need the go compiler for that when I went down that path 
> though. 
> 
> Maybe another alternative is to make a “light migration”? Here’s my thinking 
> - if I remember correctly most of that go code deals with the MSO config 
> moving from parameter overrides in header_rewrite to parent.config. If you 
> don’t have MSO, or are willing to migrate that stuff by hand, we can create a 
> simple SQL migration that just does the schema changes… 
> 
> I’ll be more careful pulling in something new like that next time, sorry… 
> 
> Cheers,
> JvD
> 
> 
>> On Sep 14, 2017, at 10:06 AM, Eric Friedrich (efriedri)  
>> wrote:
>> 
>> As we’re moving to TC2.1, we’ve found that the goose migration requires not 
>> just the goose binary to be installed, but also the go compiler and a fairly 
>> large set of dependencies. Most of these are a result of the migration of 
>> the MSO parent_retry parameters from the DS table into the 
>> profile_parameters table.
>> 
>> We have a very hard requirement that our product CANNOT require Internet 
>> access for installation.
>> 
>> We’d like to avoid vendoring (in one form or another) all of the goose 
>> dependencies, the same way we’ve had to do with web-deps and CPAN.
>> 
>> We are considering two solutions:
>> 1) Replace the .go migration with a PL/SQL file that does not require all of 
>> the go dependencies. In this case we would compile goose and ship it as a 
>> binary in our RPM to eliminate the ‘go get goose'
>> 
>> 2) Switch to a different fork of goose (https://github.com/pressly/goose) 
>> that can execute binary migrations. Here we would compile the .go migration 
>> into a binary and ship both the new goose binary and the migration binary in 
>> our RPM.
>> 
>> —Eric
>> 
>> 
> 

'Multi Site Origin Algorithm' is removed in delivery service UI in traffic_ops in TC-2.1

[York Ma (yorma)]

Hi,

'Multi Site Origin Algorithm' field is not found in delivery service UI in 
traffic_ops in TC-2.1. This existed in TC-1.7. In the MSO doc 
https://trafficcontrol.incubator.apache.org/docs/latest/admin/quick_howto/multi_site.html,
 it still mentions “Multi Site Origin Algorithm” drop-down list.

The MSO doc is out of date?
thanks,
-York