You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Peters, Rawlin" <Ra...@comcast.com> on 2017/08/03 19:51:42 UTC
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 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.
1. 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.
1. 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
Re: Adding support for per-DeliveryService routing names
Posted by Dave Neuman <ne...@apache.org>.
Inline
On Thu, Aug 3, 2017 at 1:57 PM, Peters, Rawlin <Ra...@comcast.com>
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" <Ra...@comcast.com> 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.
>
> [DN] +1 from me
>
> 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.
>
>
[DN] I don't really mind either way, but I lean towards adding a column to
the DS table. Just because we already have a lot of columns isn't a good
reason to not add another one. I assume that in most of the places that we
are setting the routing name we already have the DS "object" in memory so
it would probably avoid an extra call to the database to get a parameter.
>
> 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’.
>
[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.
>
> 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
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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 for troubleshooting purposes, but the reality is that the routing name is arbitrary after that point. Maybe they might even want to take the convention further by choosing “edge-live” for DNS_LIVE Delivery Services now that they can do so.
For that reason, maybe it would be better to just default the routing_name in the DB schema to something other than “tr” or “edge”. Then it would remain optional in the API and maybe lead to the realization that the routing name doesn’t have to be “tr” or “edge” and that new conventions could be formed at will.
--Rawlin
On 8/15/17, 10:41 AM, "Dave Neuman" <ne...@apache.org> wrote:
+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 <mi...@gmail.com>
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 potential absence in the
> api layer....i think...
>
> jeremy
>
> On Tue, Aug 15, 2017 at 10:02 AM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > 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 that value to update the db.
> >
> > jeremy
> >
> >
> >
> > On Tue, Aug 15, 2017 at 9:14 AM, Peters, Rawlin <
> Rawlin_Peters@comcast.com
> > > wrote:
> >
> >> 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
> >>
> >> On 8/15/17, 8:42 AM, "Robert Butts" <ro...@gmail.com> wrote:
> >>
> >> +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 <
> >> dewrich@gmail.com>
> >> wrote:
> >>
> >> > 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 the only way around this is to "default" the new
> field's
> >> value
> >> > and make it optional, otherwise the API needs to rev.
> >> >
> >> > -Dew
> >> >
> >> > On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <
> >> mitchell852@gmail.com>
> >> > wrote:
> >> >
> >> > > 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 default. But, yes, i forgot about the
> >> per CDN
> >> > > thing.
> >> > >
> >> > > Jeremy
> >> > >
> >> > > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
> >> > Rawlin_Peters@comcast.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > 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
> >> > > > updating post-upgrade but before a snap/queue. So either way
> >> there
> >> > needs
> >> > > to
> >> > > > be sufficient upgrade notes, but personally I still prefer
> >> keeping the
> >> > > > routing_name column non-null.
> >> > > >
> >> > > > That said, this is my current proposal for the DB migration
> >> which also
> >> > > > gets us past the upgrade issue:
> >> > > > 1. Add a routing_name column to the DeliveryService table.
> >> > > > 2. Update the routing_name for DNS Delivery Services to
> “edge”.
> >> > > > 3. Update the routing_name of non-DNS Delivery Services to the
> >> value
> >> > of a
> >> > > > temporary upgrade parameter associated with the Delivery
> >> Service’s CDN
> >> > > (if
> >> > > > the upgrade parameter doesn’t exist, the routing_names will
> >> remain
> >> > null).
> >> > > > 4. Update the remaining null routing_names to “tr”.
> >> > > > 5. Make the routing_name column non-null and add a non-empty
> >> > constraint.
> >> > > >
> >> > > > So these would be an operator’s pre-upgrade steps:
> >> > > > 1. Verify if a custom http.routing.name has been configured
> for
> >> > Traffic
> >> > > > Routers in their CDNs.
> >> > > > 2. If custom http.routing.name, do the following. Otherwise,
> no
> >> > > > pre-upgrade steps needed (for per-DS routing names at least):
> >> > > > a. create a parameter named “upgrade_http_routing_name”
> >> with the
> >> > > value
> >> > > > of the target CDN’s custom http.routing.name
> >> > > > b. associate this parameter to the TR_PROFILE belonging to
> >> the
> >> > target
> >> > > > CDN
> >> > > > c. repeat steps 2a and 2b for each CDN using a custom
> >> > > > http.routing.name
> >> > > >
> >> > > > This would keep everything working the same post-upgrade as it
> >> did
> >> > > > pre-upgrade, and from that point on you’d be able to change a
> >> Delivery
> >> > > > Service’s routing name to any arbitrary hostname (without
> >> periods).
> >> > > >
> >> > > > --Rawlin
> >> > > >
> >> > > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> >> > > >
> >> > > > 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 routing name and use that when it creates the
> >> database column
> >> > > and
> >> > > > populates it with the pre-defined defaults (edge, tr).
> >> > > >
> >> > > > Also, creating a global param doesn't help those with more
> >> than 1
> >> > > CDN.
> >> > > >
> >> > > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> >> > > > mitchell852@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > 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
> >> > > > > <http://http.routing.name/>) that default to tr and
> edge
> >> > > > respectively and
> >> > > > > make the ds.routing_name an optional field.
> >> > > > >
> >> > > > > in seeds.sql
> >> > > > >
> >> > > > > insert into parameter (name, config_file, value) values
> ('
> >> > > > > http.routing.name',
> >> > > > > 'global', 'tr') ON CONFLICT (name, config_file, value)
> DO
> >> > NOTHING;
> >> > > > > insert into parameter (name, config_file, value) values
> ('
> >> > > > dns.routing.name
> >> > > > > ',
> >> > > > > 'global', 'edge') ON CONFLICT (name, config_file, value)
> >> DO
> >> > > NOTHING;
> >> > > > >
> >> > > > > in code (warning. ugly pseudo code to follow):
> >> > > > >
> >> > > > > function getRoutingName(ds) {
> >> > > > > return ds.routing_name if not null
> >> > > > > if (ds.type = HTTP) {
> >> > > > > return parameter.http.routing.name
> >> > > > > } else
> >> > > > > return parameter.dns.routing.name
> >> > > > > }
> >> > > > > }
> >> > > > >
> >> > > > > Just my 2 cents.
> >> > > > >
> >> > > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <
> >> neuman@apache.org
> >> > >
> >> > > > wrote:
> >> > > > >
> >> > > > > > 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)
> >> TR will
> >> > > now
> >> > > > > ignore
> >> > > > > > the setting in the config file. Ideally we would
> >> remove the
> >> > > param
> >> > > > from
> >> > > > > the
> >> > > > > > default config and the need for the param in the code.
> >> > > > > >
> >> > > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> >> > > > > Rawlin_Peters@comcast.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > 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 files of
> >> the
> >> > > Traffic
> >> > > > > > Routers).
> >> > > > > > >
> >> > > > > > > For instance, if “http.routing.name” has been set
> to
> >> “ccr”,
> >> > > the
> >> > > > new
> >> > > > > > > routing name
> >> > > > > > > “tr” will break all of the clients using the old
> “ccr”
> >> > delivery
> >> > > > service
> >> > > > > > > URL.
> >> > > > > > >
> >> > > > > > > Basically we need to provide a one-time upgrade step
> >> to allow
> >> > > > CDNs
> >> > > > > using
> >> > > > > > a
> >> > > > > > > custom
> >> > > > > > > “http.routing.name” to default the new routing_name
> >> column
> >> > to
> >> > > > that
> >> > > > > value
> >> > > > > > > for
> >> > > > > > > existing HTTP delivery services. What would be the
> >> best way
> >> > to
> >> > > > do this?
> >> > > > > > > Some options
> >> > > > > > > might be:
> >> > > > > > > 1. Add a profile parameter to the TR_PROFILE for
> that
> >> CDN. On
> >> > > > upgrade,
> >> > > > > > > read that
> >> > > > > > > parameter and use it to update the routing_name
> >> for
> >> > > existing
> >> > > > HTTP
> >> > > > > > > delivery services.
> >> > > > > > > After upgrade, you can safely remove the profile
> >> > parameter.
> >> > > > > > > 2. Let the upgrade automatically default the
> >> routing_name to
> >> > > > ‘tr’ or
> >> > > > > > > ‘edge’. After
> >> > > > > > > upgrading, manually update each HTTP delivery
> >> service to
> >> > > use
> >> > > > the
> >> > > > > > > current
> >> > > > > > > “http.routing.name” in use (we could provide an
> >> API
> >> > > > endpoint to
> >> > > > > > “bulk
> >> > > > > > > update” the
> >> > > > > > > routing names for all HTTP delivery services in
> a
> >> CDN).
> >> > > > > > >
> >> > > > > > > Note this is not an exhaustive list, this is a just
> a
> >> couple
> >> > > > options
> >> > > > > that
> >> > > > > > > have come up in
> >> > > > > > > discussion so far. Feel free to add any more ideas
> to
> >> this
> >> > > list.
> >> > > > > > >
> >> > > > > > > After the upgrade has been completed, the “
> >> http.routing.name
> >> > ”
> >> > > > > parameter
> >> > > > > > > in the
> >> > > > > > > Traffic Router’s “http.properties” file will be
> >> ignored (same
> >> > > > with the
> >> > > > > “
> >> > > > > > > dns.routing.name”
> >> > > > > > > parameter in “dns.properties” which I’m not sure can
> >> even be
> >> > > > changed
> >> > > > > > > safely today).
> >> > > > > > >
> >> > > > > > > Thoughts?
> >> > > > > > >
> >> > > > > > > --Rawlin
> >> > > > > > >
> >> > > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> >> > > Rawlin_Peters@comcast.com
> >> > > > >
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > > @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
> >> > > > migration,
> >> > > > > > we
> >> > > > > > > should also provide an API endpoint to set the
> >> routing names
> >> > on
> >> > > > all
> >> > > > > DSes
> >> > > > > > in
> >> > > > > > > a CDN to a single value, thus still providing a
> >> “per-CDN”
> >> > > option.
> >> > > > > Would a
> >> > > > > > > “bulk” update also be useful, in case a user wants
> to
> >> update
> >> > a
> >> > > > handful
> >> > > > > of
> >> > > > > > > DSes to the same routing names at once?
> >> > > > > > >
> >> > > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> >> > > > > > > The default would come from a TR_PROFILE linked
> >> to the
> >> > CDN,
> >> > > > and the
> >> > > > > > > override would come from a DS_PROFILE linked to that
> >> specific
> >> > > > DS. I
> >> > > > > > looked
> >> > > > > > > into those options to cover all my bases, but I
> think
> >> adding
> >> > > > columns to
> >> > > > > > at
> >> > > > > > > least the DS table and not touching profiles at all
> >> is the
> >> > > better
> >> > > > > option.
> >> > > > > > >
> >> > > > > > > -Rawlin
> >> > > > > > >
> >> > > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <
> >> jvd@knutsel.com>
> >> > > wrote:
> >> > > > > > >
> >> > > > > > > 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)
> >> > > > <
> >> > > > > > > efriedri@cisco.com>
> >> > > > > > > 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
> >> > > > > > > > <
> >> > > > > > > > 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_Peters@comcast.com
> >> > > > > > > > <ma...@comcast.com>>
> 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_Peters@comcast.com<
> >> > > > > > > mailto:
> >> > > > > > > > Rawlin_Peters@comcast.com>> 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
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Dave Neuman <ne...@apache.org>.
+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 <mi...@gmail.com>
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 potential absence in the
> api layer....i think...
>
> jeremy
>
> On Tue, Aug 15, 2017 at 10:02 AM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > 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 that value to update the db.
> >
> > jeremy
> >
> >
> >
> > On Tue, Aug 15, 2017 at 9:14 AM, Peters, Rawlin <
> Rawlin_Peters@comcast.com
> > > wrote:
> >
> >> 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
> >>
> >> On 8/15/17, 8:42 AM, "Robert Butts" <ro...@gmail.com> wrote:
> >>
> >> +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 <
> >> dewrich@gmail.com>
> >> wrote:
> >>
> >> > 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 the only way around this is to "default" the new
> field's
> >> value
> >> > and make it optional, otherwise the API needs to rev.
> >> >
> >> > -Dew
> >> >
> >> > On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <
> >> mitchell852@gmail.com>
> >> > wrote:
> >> >
> >> > > 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 default. But, yes, i forgot about the
> >> per CDN
> >> > > thing.
> >> > >
> >> > > Jeremy
> >> > >
> >> > > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
> >> > Rawlin_Peters@comcast.com
> >> > > >
> >> > > wrote:
> >> > >
> >> > > > 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
> >> > > > updating post-upgrade but before a snap/queue. So either way
> >> there
> >> > needs
> >> > > to
> >> > > > be sufficient upgrade notes, but personally I still prefer
> >> keeping the
> >> > > > routing_name column non-null.
> >> > > >
> >> > > > That said, this is my current proposal for the DB migration
> >> which also
> >> > > > gets us past the upgrade issue:
> >> > > > 1. Add a routing_name column to the DeliveryService table.
> >> > > > 2. Update the routing_name for DNS Delivery Services to
> “edge”.
> >> > > > 3. Update the routing_name of non-DNS Delivery Services to the
> >> value
> >> > of a
> >> > > > temporary upgrade parameter associated with the Delivery
> >> Service’s CDN
> >> > > (if
> >> > > > the upgrade parameter doesn’t exist, the routing_names will
> >> remain
> >> > null).
> >> > > > 4. Update the remaining null routing_names to “tr”.
> >> > > > 5. Make the routing_name column non-null and add a non-empty
> >> > constraint.
> >> > > >
> >> > > > So these would be an operator’s pre-upgrade steps:
> >> > > > 1. Verify if a custom http.routing.name has been configured
> for
> >> > Traffic
> >> > > > Routers in their CDNs.
> >> > > > 2. If custom http.routing.name, do the following. Otherwise,
> no
> >> > > > pre-upgrade steps needed (for per-DS routing names at least):
> >> > > > a. create a parameter named “upgrade_http_routing_name”
> >> with the
> >> > > value
> >> > > > of the target CDN’s custom http.routing.name
> >> > > > b. associate this parameter to the TR_PROFILE belonging to
> >> the
> >> > target
> >> > > > CDN
> >> > > > c. repeat steps 2a and 2b for each CDN using a custom
> >> > > > http.routing.name
> >> > > >
> >> > > > This would keep everything working the same post-upgrade as it
> >> did
> >> > > > pre-upgrade, and from that point on you’d be able to change a
> >> Delivery
> >> > > > Service’s routing name to any arbitrary hostname (without
> >> periods).
> >> > > >
> >> > > > --Rawlin
> >> > > >
> >> > > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> >> > > >
> >> > > > 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 routing name and use that when it creates the
> >> database column
> >> > > and
> >> > > > populates it with the pre-defined defaults (edge, tr).
> >> > > >
> >> > > > Also, creating a global param doesn't help those with more
> >> than 1
> >> > > CDN.
> >> > > >
> >> > > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> >> > > > mitchell852@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > 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
> >> > > > > <http://http.routing.name/>) that default to tr and
> edge
> >> > > > respectively and
> >> > > > > make the ds.routing_name an optional field.
> >> > > > >
> >> > > > > in seeds.sql
> >> > > > >
> >> > > > > insert into parameter (name, config_file, value) values
> ('
> >> > > > > http.routing.name',
> >> > > > > 'global', 'tr') ON CONFLICT (name, config_file, value)
> DO
> >> > NOTHING;
> >> > > > > insert into parameter (name, config_file, value) values
> ('
> >> > > > dns.routing.name
> >> > > > > ',
> >> > > > > 'global', 'edge') ON CONFLICT (name, config_file, value)
> >> DO
> >> > > NOTHING;
> >> > > > >
> >> > > > > in code (warning. ugly pseudo code to follow):
> >> > > > >
> >> > > > > function getRoutingName(ds) {
> >> > > > > return ds.routing_name if not null
> >> > > > > if (ds.type = HTTP) {
> >> > > > > return parameter.http.routing.name
> >> > > > > } else
> >> > > > > return parameter.dns.routing.name
> >> > > > > }
> >> > > > > }
> >> > > > >
> >> > > > > Just my 2 cents.
> >> > > > >
> >> > > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <
> >> neuman@apache.org
> >> > >
> >> > > > wrote:
> >> > > > >
> >> > > > > > 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)
> >> TR will
> >> > > now
> >> > > > > ignore
> >> > > > > > the setting in the config file. Ideally we would
> >> remove the
> >> > > param
> >> > > > from
> >> > > > > the
> >> > > > > > default config and the need for the param in the code.
> >> > > > > >
> >> > > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> >> > > > > Rawlin_Peters@comcast.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > 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 files of
> >> the
> >> > > Traffic
> >> > > > > > Routers).
> >> > > > > > >
> >> > > > > > > For instance, if “http.routing.name” has been set
> to
> >> “ccr”,
> >> > > the
> >> > > > new
> >> > > > > > > routing name
> >> > > > > > > “tr” will break all of the clients using the old
> “ccr”
> >> > delivery
> >> > > > service
> >> > > > > > > URL.
> >> > > > > > >
> >> > > > > > > Basically we need to provide a one-time upgrade step
> >> to allow
> >> > > > CDNs
> >> > > > > using
> >> > > > > > a
> >> > > > > > > custom
> >> > > > > > > “http.routing.name” to default the new routing_name
> >> column
> >> > to
> >> > > > that
> >> > > > > value
> >> > > > > > > for
> >> > > > > > > existing HTTP delivery services. What would be the
> >> best way
> >> > to
> >> > > > do this?
> >> > > > > > > Some options
> >> > > > > > > might be:
> >> > > > > > > 1. Add a profile parameter to the TR_PROFILE for
> that
> >> CDN. On
> >> > > > upgrade,
> >> > > > > > > read that
> >> > > > > > > parameter and use it to update the routing_name
> >> for
> >> > > existing
> >> > > > HTTP
> >> > > > > > > delivery services.
> >> > > > > > > After upgrade, you can safely remove the profile
> >> > parameter.
> >> > > > > > > 2. Let the upgrade automatically default the
> >> routing_name to
> >> > > > ‘tr’ or
> >> > > > > > > ‘edge’. After
> >> > > > > > > upgrading, manually update each HTTP delivery
> >> service to
> >> > > use
> >> > > > the
> >> > > > > > > current
> >> > > > > > > “http.routing.name” in use (we could provide an
> >> API
> >> > > > endpoint to
> >> > > > > > “bulk
> >> > > > > > > update” the
> >> > > > > > > routing names for all HTTP delivery services in
> a
> >> CDN).
> >> > > > > > >
> >> > > > > > > Note this is not an exhaustive list, this is a just
> a
> >> couple
> >> > > > options
> >> > > > > that
> >> > > > > > > have come up in
> >> > > > > > > discussion so far. Feel free to add any more ideas
> to
> >> this
> >> > > list.
> >> > > > > > >
> >> > > > > > > After the upgrade has been completed, the “
> >> http.routing.name
> >> > ”
> >> > > > > parameter
> >> > > > > > > in the
> >> > > > > > > Traffic Router’s “http.properties” file will be
> >> ignored (same
> >> > > > with the
> >> > > > > “
> >> > > > > > > dns.routing.name”
> >> > > > > > > parameter in “dns.properties” which I’m not sure can
> >> even be
> >> > > > changed
> >> > > > > > > safely today).
> >> > > > > > >
> >> > > > > > > Thoughts?
> >> > > > > > >
> >> > > > > > > --Rawlin
> >> > > > > > >
> >> > > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> >> > > Rawlin_Peters@comcast.com
> >> > > > >
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > > @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
> >> > > > migration,
> >> > > > > > we
> >> > > > > > > should also provide an API endpoint to set the
> >> routing names
> >> > on
> >> > > > all
> >> > > > > DSes
> >> > > > > > in
> >> > > > > > > a CDN to a single value, thus still providing a
> >> “per-CDN”
> >> > > option.
> >> > > > > Would a
> >> > > > > > > “bulk” update also be useful, in case a user wants
> to
> >> update
> >> > a
> >> > > > handful
> >> > > > > of
> >> > > > > > > DSes to the same routing names at once?
> >> > > > > > >
> >> > > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> >> > > > > > > The default would come from a TR_PROFILE linked
> >> to the
> >> > CDN,
> >> > > > and the
> >> > > > > > > override would come from a DS_PROFILE linked to that
> >> specific
> >> > > > DS. I
> >> > > > > > looked
> >> > > > > > > into those options to cover all my bases, but I
> think
> >> adding
> >> > > > columns to
> >> > > > > > at
> >> > > > > > > least the DS table and not touching profiles at all
> >> is the
> >> > > better
> >> > > > > option.
> >> > > > > > >
> >> > > > > > > -Rawlin
> >> > > > > > >
> >> > > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <
> >> jvd@knutsel.com>
> >> > > wrote:
> >> > > > > > >
> >> > > > > > > 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)
> >> > > > <
> >> > > > > > > efriedri@cisco.com>
> >> > > > > > > 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
> >> > > > > > > > <
> >> > > > > > > > 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_Peters@comcast.com
> >> > > > > > > > <ma...@comcast.com>>
> 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_Peters@comcast.com<
> >> > > > > > > mailto:
> >> > > > > > > > Rawlin_Peters@comcast.com>> 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
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 layer....i think...
jeremy
On Tue, Aug 15, 2017 at 10:02 AM, Jeremy Mitchell <mi...@gmail.com>
wrote:
> 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 that value to update the db.
>
> jeremy
>
>
>
> On Tue, Aug 15, 2017 at 9:14 AM, Peters, Rawlin <Rawlin_Peters@comcast.com
> > wrote:
>
>> 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
>>
>> On 8/15/17, 8:42 AM, "Robert Butts" <ro...@gmail.com> wrote:
>>
>> +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 <
>> dewrich@gmail.com>
>> wrote:
>>
>> > 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 the only way around this is to "default" the new field's
>> value
>> > and make it optional, otherwise the API needs to rev.
>> >
>> > -Dew
>> >
>> > On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <
>> mitchell852@gmail.com>
>> > wrote:
>> >
>> > > 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 default. But, yes, i forgot about the
>> per CDN
>> > > thing.
>> > >
>> > > Jeremy
>> > >
>> > > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
>> > Rawlin_Peters@comcast.com
>> > > >
>> > > wrote:
>> > >
>> > > > 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
>> > > > updating post-upgrade but before a snap/queue. So either way
>> there
>> > needs
>> > > to
>> > > > be sufficient upgrade notes, but personally I still prefer
>> keeping the
>> > > > routing_name column non-null.
>> > > >
>> > > > That said, this is my current proposal for the DB migration
>> which also
>> > > > gets us past the upgrade issue:
>> > > > 1. Add a routing_name column to the DeliveryService table.
>> > > > 2. Update the routing_name for DNS Delivery Services to “edge”.
>> > > > 3. Update the routing_name of non-DNS Delivery Services to the
>> value
>> > of a
>> > > > temporary upgrade parameter associated with the Delivery
>> Service’s CDN
>> > > (if
>> > > > the upgrade parameter doesn’t exist, the routing_names will
>> remain
>> > null).
>> > > > 4. Update the remaining null routing_names to “tr”.
>> > > > 5. Make the routing_name column non-null and add a non-empty
>> > constraint.
>> > > >
>> > > > So these would be an operator’s pre-upgrade steps:
>> > > > 1. Verify if a custom http.routing.name has been configured for
>> > Traffic
>> > > > Routers in their CDNs.
>> > > > 2. If custom http.routing.name, do the following. Otherwise, no
>> > > > pre-upgrade steps needed (for per-DS routing names at least):
>> > > > a. create a parameter named “upgrade_http_routing_name”
>> with the
>> > > value
>> > > > of the target CDN’s custom http.routing.name
>> > > > b. associate this parameter to the TR_PROFILE belonging to
>> the
>> > target
>> > > > CDN
>> > > > c. repeat steps 2a and 2b for each CDN using a custom
>> > > > http.routing.name
>> > > >
>> > > > This would keep everything working the same post-upgrade as it
>> did
>> > > > pre-upgrade, and from that point on you’d be able to change a
>> Delivery
>> > > > Service’s routing name to any arbitrary hostname (without
>> periods).
>> > > >
>> > > > --Rawlin
>> > > >
>> > > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
>> > > >
>> > > > 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 routing name and use that when it creates the
>> database column
>> > > and
>> > > > populates it with the pre-defined defaults (edge, tr).
>> > > >
>> > > > Also, creating a global param doesn't help those with more
>> than 1
>> > > CDN.
>> > > >
>> > > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
>> > > > mitchell852@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > 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
>> > > > > <http://http.routing.name/>) that default to tr and edge
>> > > > respectively and
>> > > > > make the ds.routing_name an optional field.
>> > > > >
>> > > > > in seeds.sql
>> > > > >
>> > > > > insert into parameter (name, config_file, value) values ('
>> > > > > http.routing.name',
>> > > > > 'global', 'tr') ON CONFLICT (name, config_file, value) DO
>> > NOTHING;
>> > > > > insert into parameter (name, config_file, value) values ('
>> > > > dns.routing.name
>> > > > > ',
>> > > > > 'global', 'edge') ON CONFLICT (name, config_file, value)
>> DO
>> > > NOTHING;
>> > > > >
>> > > > > in code (warning. ugly pseudo code to follow):
>> > > > >
>> > > > > function getRoutingName(ds) {
>> > > > > return ds.routing_name if not null
>> > > > > if (ds.type = HTTP) {
>> > > > > return parameter.http.routing.name
>> > > > > } else
>> > > > > return parameter.dns.routing.name
>> > > > > }
>> > > > > }
>> > > > >
>> > > > > Just my 2 cents.
>> > > > >
>> > > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <
>> neuman@apache.org
>> > >
>> > > > wrote:
>> > > > >
>> > > > > > 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)
>> TR will
>> > > now
>> > > > > ignore
>> > > > > > the setting in the config file. Ideally we would
>> remove the
>> > > param
>> > > > from
>> > > > > the
>> > > > > > default config and the need for the param in the code.
>> > > > > >
>> > > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
>> > > > > Rawlin_Peters@comcast.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > 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 files of
>> the
>> > > Traffic
>> > > > > > Routers).
>> > > > > > >
>> > > > > > > For instance, if “http.routing.name” has been set to
>> “ccr”,
>> > > the
>> > > > new
>> > > > > > > routing name
>> > > > > > > “tr” will break all of the clients using the old “ccr”
>> > delivery
>> > > > service
>> > > > > > > URL.
>> > > > > > >
>> > > > > > > Basically we need to provide a one-time upgrade step
>> to allow
>> > > > CDNs
>> > > > > using
>> > > > > > a
>> > > > > > > custom
>> > > > > > > “http.routing.name” to default the new routing_name
>> column
>> > to
>> > > > that
>> > > > > value
>> > > > > > > for
>> > > > > > > existing HTTP delivery services. What would be the
>> best way
>> > to
>> > > > do this?
>> > > > > > > Some options
>> > > > > > > might be:
>> > > > > > > 1. Add a profile parameter to the TR_PROFILE for that
>> CDN. On
>> > > > upgrade,
>> > > > > > > read that
>> > > > > > > parameter and use it to update the routing_name
>> for
>> > > existing
>> > > > HTTP
>> > > > > > > delivery services.
>> > > > > > > After upgrade, you can safely remove the profile
>> > parameter.
>> > > > > > > 2. Let the upgrade automatically default the
>> routing_name to
>> > > > ‘tr’ or
>> > > > > > > ‘edge’. After
>> > > > > > > upgrading, manually update each HTTP delivery
>> service to
>> > > use
>> > > > the
>> > > > > > > current
>> > > > > > > “http.routing.name” in use (we could provide an
>> API
>> > > > endpoint to
>> > > > > > “bulk
>> > > > > > > update” the
>> > > > > > > routing names for all HTTP delivery services in a
>> CDN).
>> > > > > > >
>> > > > > > > Note this is not an exhaustive list, this is a just a
>> couple
>> > > > options
>> > > > > that
>> > > > > > > have come up in
>> > > > > > > discussion so far. Feel free to add any more ideas to
>> this
>> > > list.
>> > > > > > >
>> > > > > > > After the upgrade has been completed, the “
>> http.routing.name
>> > ”
>> > > > > parameter
>> > > > > > > in the
>> > > > > > > Traffic Router’s “http.properties” file will be
>> ignored (same
>> > > > with the
>> > > > > “
>> > > > > > > dns.routing.name”
>> > > > > > > parameter in “dns.properties” which I’m not sure can
>> even be
>> > > > changed
>> > > > > > > safely today).
>> > > > > > >
>> > > > > > > Thoughts?
>> > > > > > >
>> > > > > > > --Rawlin
>> > > > > > >
>> > > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
>> > > Rawlin_Peters@comcast.com
>> > > > >
>> > > > > wrote:
>> > > > > > >
>> > > > > > > @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
>> > > > migration,
>> > > > > > we
>> > > > > > > should also provide an API endpoint to set the
>> routing names
>> > on
>> > > > all
>> > > > > DSes
>> > > > > > in
>> > > > > > > a CDN to a single value, thus still providing a
>> “per-CDN”
>> > > option.
>> > > > > Would a
>> > > > > > > “bulk” update also be useful, in case a user wants to
>> update
>> > a
>> > > > handful
>> > > > > of
>> > > > > > > DSes to the same routing names at once?
>> > > > > > >
>> > > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
>> > > > > > > The default would come from a TR_PROFILE linked
>> to the
>> > CDN,
>> > > > and the
>> > > > > > > override would come from a DS_PROFILE linked to that
>> specific
>> > > > DS. I
>> > > > > > looked
>> > > > > > > into those options to cover all my bases, but I think
>> adding
>> > > > columns to
>> > > > > > at
>> > > > > > > least the DS table and not touching profiles at all
>> is the
>> > > better
>> > > > > option.
>> > > > > > >
>> > > > > > > -Rawlin
>> > > > > > >
>> > > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <
>> jvd@knutsel.com>
>> > > wrote:
>> > > > > > >
>> > > > > > > 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)
>> > > > <
>> > > > > > > efriedri@cisco.com>
>> > > > > > > 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
>> > > > > > > > <
>> > > > > > > > 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_Peters@comcast.com
>> > > > > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
>> > > > > > > mailto:
>> > > > > > > > Rawlin_Peters@comcast.com>> 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
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>>
>>
>
Re: Adding support for per-DeliveryService routing names
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 that value to update the db.
jeremy
On Tue, Aug 15, 2017 at 9:14 AM, Peters, Rawlin <Ra...@comcast.com>
wrote:
> 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
>
> On 8/15/17, 8:42 AM, "Robert Butts" <ro...@gmail.com> wrote:
>
> +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 <dewrich@gmail.com
> >
> wrote:
>
> > 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 the only way around this is to "default" the new field's
> value
> > and make it optional, otherwise the API needs to rev.
> >
> > -Dew
> >
> > On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <
> mitchell852@gmail.com>
> > wrote:
> >
> > > 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 default. But, yes, i forgot about the
> per CDN
> > > thing.
> > >
> > > Jeremy
> > >
> > > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
> > Rawlin_Peters@comcast.com
> > > >
> > > wrote:
> > >
> > > > 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
> > > > updating post-upgrade but before a snap/queue. So either way
> there
> > needs
> > > to
> > > > be sufficient upgrade notes, but personally I still prefer
> keeping the
> > > > routing_name column non-null.
> > > >
> > > > That said, this is my current proposal for the DB migration
> which also
> > > > gets us past the upgrade issue:
> > > > 1. Add a routing_name column to the DeliveryService table.
> > > > 2. Update the routing_name for DNS Delivery Services to “edge”.
> > > > 3. Update the routing_name of non-DNS Delivery Services to the
> value
> > of a
> > > > temporary upgrade parameter associated with the Delivery
> Service’s CDN
> > > (if
> > > > the upgrade parameter doesn’t exist, the routing_names will
> remain
> > null).
> > > > 4. Update the remaining null routing_names to “tr”.
> > > > 5. Make the routing_name column non-null and add a non-empty
> > constraint.
> > > >
> > > > So these would be an operator’s pre-upgrade steps:
> > > > 1. Verify if a custom http.routing.name has been configured for
> > Traffic
> > > > Routers in their CDNs.
> > > > 2. If custom http.routing.name, do the following. Otherwise, no
> > > > pre-upgrade steps needed (for per-DS routing names at least):
> > > > a. create a parameter named “upgrade_http_routing_name” with
> the
> > > value
> > > > of the target CDN’s custom http.routing.name
> > > > b. associate this parameter to the TR_PROFILE belonging to
> the
> > target
> > > > CDN
> > > > c. repeat steps 2a and 2b for each CDN using a custom
> > > > http.routing.name
> > > >
> > > > This would keep everything working the same post-upgrade as it
> did
> > > > pre-upgrade, and from that point on you’d be able to change a
> Delivery
> > > > Service’s routing name to any arbitrary hostname (without
> periods).
> > > >
> > > > --Rawlin
> > > >
> > > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> > > >
> > > > 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 routing name and use that when it creates the database
> column
> > > and
> > > > populates it with the pre-defined defaults (edge, tr).
> > > >
> > > > Also, creating a global param doesn't help those with more
> than 1
> > > CDN.
> > > >
> > > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> > > > mitchell852@gmail.com>
> > > > wrote:
> > > >
> > > > > 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
> > > > > <http://http.routing.name/>) that default to tr and edge
> > > > respectively and
> > > > > make the ds.routing_name an optional field.
> > > > >
> > > > > in seeds.sql
> > > > >
> > > > > insert into parameter (name, config_file, value) values ('
> > > > > http.routing.name',
> > > > > 'global', 'tr') ON CONFLICT (name, config_file, value) DO
> > NOTHING;
> > > > > insert into parameter (name, config_file, value) values ('
> > > > dns.routing.name
> > > > > ',
> > > > > 'global', 'edge') ON CONFLICT (name, config_file, value) DO
> > > NOTHING;
> > > > >
> > > > > in code (warning. ugly pseudo code to follow):
> > > > >
> > > > > function getRoutingName(ds) {
> > > > > return ds.routing_name if not null
> > > > > if (ds.type = HTTP) {
> > > > > return parameter.http.routing.name
> > > > > } else
> > > > > return parameter.dns.routing.name
> > > > > }
> > > > > }
> > > > >
> > > > > Just my 2 cents.
> > > > >
> > > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <
> neuman@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > > 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)
> TR will
> > > now
> > > > > ignore
> > > > > > the setting in the config file. Ideally we would remove
> the
> > > param
> > > > from
> > > > > the
> > > > > > default config and the need for the param in the code.
> > > > > >
> > > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > > > > Rawlin_Peters@comcast.com>
> > > > > > wrote:
> > > > > >
> > > > > > > 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 files of
> the
> > > Traffic
> > > > > > Routers).
> > > > > > >
> > > > > > > For instance, if “http.routing.name” has been set to
> “ccr”,
> > > the
> > > > new
> > > > > > > routing name
> > > > > > > “tr” will break all of the clients using the old “ccr”
> > delivery
> > > > service
> > > > > > > URL.
> > > > > > >
> > > > > > > Basically we need to provide a one-time upgrade step
> to allow
> > > > CDNs
> > > > > using
> > > > > > a
> > > > > > > custom
> > > > > > > “http.routing.name” to default the new routing_name
> column
> > to
> > > > that
> > > > > value
> > > > > > > for
> > > > > > > existing HTTP delivery services. What would be the
> best way
> > to
> > > > do this?
> > > > > > > Some options
> > > > > > > might be:
> > > > > > > 1. Add a profile parameter to the TR_PROFILE for that
> CDN. On
> > > > upgrade,
> > > > > > > read that
> > > > > > > parameter and use it to update the routing_name for
> > > existing
> > > > HTTP
> > > > > > > delivery services.
> > > > > > > After upgrade, you can safely remove the profile
> > parameter.
> > > > > > > 2. Let the upgrade automatically default the
> routing_name to
> > > > ‘tr’ or
> > > > > > > ‘edge’. After
> > > > > > > upgrading, manually update each HTTP delivery
> service to
> > > use
> > > > the
> > > > > > > current
> > > > > > > “http.routing.name” in use (we could provide an
> API
> > > > endpoint to
> > > > > > “bulk
> > > > > > > update” the
> > > > > > > routing names for all HTTP delivery services in a
> CDN).
> > > > > > >
> > > > > > > Note this is not an exhaustive list, this is a just a
> couple
> > > > options
> > > > > that
> > > > > > > have come up in
> > > > > > > discussion so far. Feel free to add any more ideas to
> this
> > > list.
> > > > > > >
> > > > > > > After the upgrade has been completed, the “
> http.routing.name
> > ”
> > > > > parameter
> > > > > > > in the
> > > > > > > Traffic Router’s “http.properties” file will be
> ignored (same
> > > > with the
> > > > > “
> > > > > > > dns.routing.name”
> > > > > > > parameter in “dns.properties” which I’m not sure can
> even be
> > > > changed
> > > > > > > safely today).
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > --Rawlin
> > > > > > >
> > > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> > > Rawlin_Peters@comcast.com
> > > > >
> > > > > wrote:
> > > > > > >
> > > > > > > @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
> > > > migration,
> > > > > > we
> > > > > > > should also provide an API endpoint to set the routing
> names
> > on
> > > > all
> > > > > DSes
> > > > > > in
> > > > > > > a CDN to a single value, thus still providing a
> “per-CDN”
> > > option.
> > > > > Would a
> > > > > > > “bulk” update also be useful, in case a user wants to
> update
> > a
> > > > handful
> > > > > of
> > > > > > > DSes to the same routing names at once?
> > > > > > >
> > > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > > > > The default would come from a TR_PROFILE linked to
> the
> > CDN,
> > > > and the
> > > > > > > override would come from a DS_PROFILE linked to that
> specific
> > > > DS. I
> > > > > > looked
> > > > > > > into those options to cover all my bases, but I think
> adding
> > > > columns to
> > > > > > at
> > > > > > > least the DS table and not touching profiles at all is
> the
> > > better
> > > > > option.
> > > > > > >
> > > > > > > -Rawlin
> > > > > > >
> > > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <
> jvd@knutsel.com>
> > > wrote:
> > > > > > >
> > > > > > > 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)
> > > > <
> > > > > > > efriedri@cisco.com>
> > > > > > > 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
> > > > > > > > <
> > > > > > > > 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_Peters@comcast.com
> > > > > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > > > > mailto:
> > > > > > > > Rawlin_Peters@comcast.com>> 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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
On 8/15/17, 8:42 AM, "Robert Butts" <ro...@gmail.com> wrote:
+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 <de...@gmail.com>
wrote:
> 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 the only way around this is to "default" the new field's value
> and make it optional, otherwise the API needs to rev.
>
> -Dew
>
> On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > 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 default. But, yes, i forgot about the per CDN
> > thing.
> >
> > Jeremy
> >
> > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
> Rawlin_Peters@comcast.com
> > >
> > wrote:
> >
> > > 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
> > > updating post-upgrade but before a snap/queue. So either way there
> needs
> > to
> > > be sufficient upgrade notes, but personally I still prefer keeping the
> > > routing_name column non-null.
> > >
> > > That said, this is my current proposal for the DB migration which also
> > > gets us past the upgrade issue:
> > > 1. Add a routing_name column to the DeliveryService table.
> > > 2. Update the routing_name for DNS Delivery Services to “edge”.
> > > 3. Update the routing_name of non-DNS Delivery Services to the value
> of a
> > > temporary upgrade parameter associated with the Delivery Service’s CDN
> > (if
> > > the upgrade parameter doesn’t exist, the routing_names will remain
> null).
> > > 4. Update the remaining null routing_names to “tr”.
> > > 5. Make the routing_name column non-null and add a non-empty
> constraint.
> > >
> > > So these would be an operator’s pre-upgrade steps:
> > > 1. Verify if a custom http.routing.name has been configured for
> Traffic
> > > Routers in their CDNs.
> > > 2. If custom http.routing.name, do the following. Otherwise, no
> > > pre-upgrade steps needed (for per-DS routing names at least):
> > > a. create a parameter named “upgrade_http_routing_name” with the
> > value
> > > of the target CDN’s custom http.routing.name
> > > b. associate this parameter to the TR_PROFILE belonging to the
> target
> > > CDN
> > > c. repeat steps 2a and 2b for each CDN using a custom
> > > http.routing.name
> > >
> > > This would keep everything working the same post-upgrade as it did
> > > pre-upgrade, and from that point on you’d be able to change a Delivery
> > > Service’s routing name to any arbitrary hostname (without periods).
> > >
> > > --Rawlin
> > >
> > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> > >
> > > 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 routing name and use that when it creates the database column
> > and
> > > populates it with the pre-defined defaults (edge, tr).
> > >
> > > Also, creating a global param doesn't help those with more than 1
> > CDN.
> > >
> > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> > > mitchell852@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > > <http://http.routing.name/>) that default to tr and edge
> > > respectively and
> > > > make the ds.routing_name an optional field.
> > > >
> > > > in seeds.sql
> > > >
> > > > insert into parameter (name, config_file, value) values ('
> > > > http.routing.name',
> > > > 'global', 'tr') ON CONFLICT (name, config_file, value) DO
> NOTHING;
> > > > insert into parameter (name, config_file, value) values ('
> > > dns.routing.name
> > > > ',
> > > > 'global', 'edge') ON CONFLICT (name, config_file, value) DO
> > NOTHING;
> > > >
> > > > in code (warning. ugly pseudo code to follow):
> > > >
> > > > function getRoutingName(ds) {
> > > > return ds.routing_name if not null
> > > > if (ds.type = HTTP) {
> > > > return parameter.http.routing.name
> > > > } else
> > > > return parameter.dns.routing.name
> > > > }
> > > > }
> > > >
> > > > Just my 2 cents.
> > > >
> > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <neuman@apache.org
> >
> > > wrote:
> > > >
> > > > > 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) TR will
> > now
> > > > ignore
> > > > > the setting in the config file. Ideally we would remove the
> > param
> > > from
> > > > the
> > > > > default config and the need for the param in the code.
> > > > >
> > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > > > Rawlin_Peters@comcast.com>
> > > > > wrote:
> > > > >
> > > > > > 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 files of the
> > Traffic
> > > > > Routers).
> > > > > >
> > > > > > For instance, if “http.routing.name” has been set to “ccr”,
> > the
> > > new
> > > > > > routing name
> > > > > > “tr” will break all of the clients using the old “ccr”
> delivery
> > > service
> > > > > > URL.
> > > > > >
> > > > > > Basically we need to provide a one-time upgrade step to allow
> > > CDNs
> > > > using
> > > > > a
> > > > > > custom
> > > > > > “http.routing.name” to default the new routing_name column
> to
> > > that
> > > > value
> > > > > > for
> > > > > > existing HTTP delivery services. What would be the best way
> to
> > > do this?
> > > > > > Some options
> > > > > > might be:
> > > > > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On
> > > upgrade,
> > > > > > read that
> > > > > > parameter and use it to update the routing_name for
> > existing
> > > HTTP
> > > > > > delivery services.
> > > > > > After upgrade, you can safely remove the profile
> parameter.
> > > > > > 2. Let the upgrade automatically default the routing_name to
> > > ‘tr’ or
> > > > > > ‘edge’. After
> > > > > > upgrading, manually update each HTTP delivery service to
> > use
> > > the
> > > > > > current
> > > > > > “http.routing.name” in use (we could provide an API
> > > endpoint to
> > > > > “bulk
> > > > > > update” the
> > > > > > routing names for all HTTP delivery services in a CDN).
> > > > > >
> > > > > > Note this is not an exhaustive list, this is a just a couple
> > > options
> > > > that
> > > > > > have come up in
> > > > > > discussion so far. Feel free to add any more ideas to this
> > list.
> > > > > >
> > > > > > After the upgrade has been completed, the “http.routing.name
> ”
> > > > parameter
> > > > > > in the
> > > > > > Traffic Router’s “http.properties” file will be ignored (same
> > > with the
> > > > “
> > > > > > dns.routing.name”
> > > > > > parameter in “dns.properties” which I’m not sure can even be
> > > changed
> > > > > > safely today).
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > --Rawlin
> > > > > >
> > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> > Rawlin_Peters@comcast.com
> > > >
> > > > wrote:
> > > > > >
> > > > > > @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
> > > migration,
> > > > > we
> > > > > > should also provide an API endpoint to set the routing names
> on
> > > all
> > > > DSes
> > > > > in
> > > > > > a CDN to a single value, thus still providing a “per-CDN”
> > option.
> > > > Would a
> > > > > > “bulk” update also be useful, in case a user wants to update
> a
> > > handful
> > > > of
> > > > > > DSes to the same routing names at once?
> > > > > >
> > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > > > The default would come from a TR_PROFILE linked to the
> CDN,
> > > and the
> > > > > > override would come from a DS_PROFILE linked to that specific
> > > DS. I
> > > > > looked
> > > > > > into those options to cover all my bases, but I think adding
> > > columns to
> > > > > at
> > > > > > least the DS table and not touching profiles at all is the
> > better
> > > > option.
> > > > > >
> > > > > > -Rawlin
> > > > > >
> > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com>
> > wrote:
> > > > > >
> > > > > > 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)
> > > <
> > > > > > efriedri@cisco.com>
> > > > > > 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/
> > > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > > > > 3Cdev.trafficcontrol.apache.org%3E
> > > > > > > <
> > > > > > > https://lists.apache.org/thread.html/
> > > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > > > > <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_Peters@comcast.com
> > > > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > > > mailto:
> > > > > > > Rawlin_Peters@comcast.com>> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Robert Butts <ro...@gmail.com>.
+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 <de...@gmail.com>
wrote:
> 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 the only way around this is to "default" the new field's value
> and make it optional, otherwise the API needs to rev.
>
> -Dew
>
> On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > 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 default. But, yes, i forgot about the per CDN
> > thing.
> >
> > Jeremy
> >
> > On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <
> Rawlin_Peters@comcast.com
> > >
> > wrote:
> >
> > > 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
> > > updating post-upgrade but before a snap/queue. So either way there
> needs
> > to
> > > be sufficient upgrade notes, but personally I still prefer keeping the
> > > routing_name column non-null.
> > >
> > > That said, this is my current proposal for the DB migration which also
> > > gets us past the upgrade issue:
> > > 1. Add a routing_name column to the DeliveryService table.
> > > 2. Update the routing_name for DNS Delivery Services to “edge”.
> > > 3. Update the routing_name of non-DNS Delivery Services to the value
> of a
> > > temporary upgrade parameter associated with the Delivery Service’s CDN
> > (if
> > > the upgrade parameter doesn’t exist, the routing_names will remain
> null).
> > > 4. Update the remaining null routing_names to “tr”.
> > > 5. Make the routing_name column non-null and add a non-empty
> constraint.
> > >
> > > So these would be an operator’s pre-upgrade steps:
> > > 1. Verify if a custom http.routing.name has been configured for
> Traffic
> > > Routers in their CDNs.
> > > 2. If custom http.routing.name, do the following. Otherwise, no
> > > pre-upgrade steps needed (for per-DS routing names at least):
> > > a. create a parameter named “upgrade_http_routing_name” with the
> > value
> > > of the target CDN’s custom http.routing.name
> > > b. associate this parameter to the TR_PROFILE belonging to the
> target
> > > CDN
> > > c. repeat steps 2a and 2b for each CDN using a custom
> > > http.routing.name
> > >
> > > This would keep everything working the same post-upgrade as it did
> > > pre-upgrade, and from that point on you’d be able to change a Delivery
> > > Service’s routing name to any arbitrary hostname (without periods).
> > >
> > > --Rawlin
> > >
> > > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> > >
> > > 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 routing name and use that when it creates the database column
> > and
> > > populates it with the pre-defined defaults (edge, tr).
> > >
> > > Also, creating a global param doesn't help those with more than 1
> > CDN.
> > >
> > > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> > > mitchell852@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > > <http://http.routing.name/>) that default to tr and edge
> > > respectively and
> > > > make the ds.routing_name an optional field.
> > > >
> > > > in seeds.sql
> > > >
> > > > insert into parameter (name, config_file, value) values ('
> > > > http.routing.name',
> > > > 'global', 'tr') ON CONFLICT (name, config_file, value) DO
> NOTHING;
> > > > insert into parameter (name, config_file, value) values ('
> > > dns.routing.name
> > > > ',
> > > > 'global', 'edge') ON CONFLICT (name, config_file, value) DO
> > NOTHING;
> > > >
> > > > in code (warning. ugly pseudo code to follow):
> > > >
> > > > function getRoutingName(ds) {
> > > > return ds.routing_name if not null
> > > > if (ds.type = HTTP) {
> > > > return parameter.http.routing.name
> > > > } else
> > > > return parameter.dns.routing.name
> > > > }
> > > > }
> > > >
> > > > Just my 2 cents.
> > > >
> > > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <neuman@apache.org
> >
> > > wrote:
> > > >
> > > > > 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) TR will
> > now
> > > > ignore
> > > > > the setting in the config file. Ideally we would remove the
> > param
> > > from
> > > > the
> > > > > default config and the need for the param in the code.
> > > > >
> > > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > > > Rawlin_Peters@comcast.com>
> > > > > wrote:
> > > > >
> > > > > > 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 files of the
> > Traffic
> > > > > Routers).
> > > > > >
> > > > > > For instance, if “http.routing.name” has been set to “ccr”,
> > the
> > > new
> > > > > > routing name
> > > > > > “tr” will break all of the clients using the old “ccr”
> delivery
> > > service
> > > > > > URL.
> > > > > >
> > > > > > Basically we need to provide a one-time upgrade step to allow
> > > CDNs
> > > > using
> > > > > a
> > > > > > custom
> > > > > > “http.routing.name” to default the new routing_name column
> to
> > > that
> > > > value
> > > > > > for
> > > > > > existing HTTP delivery services. What would be the best way
> to
> > > do this?
> > > > > > Some options
> > > > > > might be:
> > > > > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On
> > > upgrade,
> > > > > > read that
> > > > > > parameter and use it to update the routing_name for
> > existing
> > > HTTP
> > > > > > delivery services.
> > > > > > After upgrade, you can safely remove the profile
> parameter.
> > > > > > 2. Let the upgrade automatically default the routing_name to
> > > ‘tr’ or
> > > > > > ‘edge’. After
> > > > > > upgrading, manually update each HTTP delivery service to
> > use
> > > the
> > > > > > current
> > > > > > “http.routing.name” in use (we could provide an API
> > > endpoint to
> > > > > “bulk
> > > > > > update” the
> > > > > > routing names for all HTTP delivery services in a CDN).
> > > > > >
> > > > > > Note this is not an exhaustive list, this is a just a couple
> > > options
> > > > that
> > > > > > have come up in
> > > > > > discussion so far. Feel free to add any more ideas to this
> > list.
> > > > > >
> > > > > > After the upgrade has been completed, the “http.routing.name
> ”
> > > > parameter
> > > > > > in the
> > > > > > Traffic Router’s “http.properties” file will be ignored (same
> > > with the
> > > > “
> > > > > > dns.routing.name”
> > > > > > parameter in “dns.properties” which I’m not sure can even be
> > > changed
> > > > > > safely today).
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > --Rawlin
> > > > > >
> > > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> > Rawlin_Peters@comcast.com
> > > >
> > > > wrote:
> > > > > >
> > > > > > @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
> > > migration,
> > > > > we
> > > > > > should also provide an API endpoint to set the routing names
> on
> > > all
> > > > DSes
> > > > > in
> > > > > > a CDN to a single value, thus still providing a “per-CDN”
> > option.
> > > > Would a
> > > > > > “bulk” update also be useful, in case a user wants to update
> a
> > > handful
> > > > of
> > > > > > DSes to the same routing names at once?
> > > > > >
> > > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > > > The default would come from a TR_PROFILE linked to the
> CDN,
> > > and the
> > > > > > override would come from a DS_PROFILE linked to that specific
> > > DS. I
> > > > > looked
> > > > > > into those options to cover all my bases, but I think adding
> > > columns to
> > > > > at
> > > > > > least the DS table and not touching profiles at all is the
> > better
> > > > option.
> > > > > >
> > > > > > -Rawlin
> > > > > >
> > > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com>
> > wrote:
> > > > > >
> > > > > > 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)
> > > <
> > > > > > efriedri@cisco.com>
> > > > > > 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/
> > > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > > > > 3Cdev.trafficcontrol.apache.org%3E
> > > > > > > <
> > > > > > > https://lists.apache.org/thread.html/
> > > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > > > > <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_Peters@comcast.com
> > > > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > > > mailto:
> > > > > > > Rawlin_Peters@comcast.com>> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Dewayne Richardson <de...@gmail.com>.
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 the only way around this is to "default" the new field's value
and make it optional, otherwise the API needs to rev.
-Dew
On Tue, Aug 15, 2017 at 8:09 AM, Jeremy Mitchell <mi...@gmail.com>
wrote:
> 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 default. But, yes, i forgot about the per CDN
> thing.
>
> Jeremy
>
> On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <Rawlin_Peters@comcast.com
> >
> wrote:
>
> > 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
> > updating post-upgrade but before a snap/queue. So either way there needs
> to
> > be sufficient upgrade notes, but personally I still prefer keeping the
> > routing_name column non-null.
> >
> > That said, this is my current proposal for the DB migration which also
> > gets us past the upgrade issue:
> > 1. Add a routing_name column to the DeliveryService table.
> > 2. Update the routing_name for DNS Delivery Services to “edge”.
> > 3. Update the routing_name of non-DNS Delivery Services to the value of a
> > temporary upgrade parameter associated with the Delivery Service’s CDN
> (if
> > the upgrade parameter doesn’t exist, the routing_names will remain null).
> > 4. Update the remaining null routing_names to “tr”.
> > 5. Make the routing_name column non-null and add a non-empty constraint.
> >
> > So these would be an operator’s pre-upgrade steps:
> > 1. Verify if a custom http.routing.name has been configured for Traffic
> > Routers in their CDNs.
> > 2. If custom http.routing.name, do the following. Otherwise, no
> > pre-upgrade steps needed (for per-DS routing names at least):
> > a. create a parameter named “upgrade_http_routing_name” with the
> value
> > of the target CDN’s custom http.routing.name
> > b. associate this parameter to the TR_PROFILE belonging to the target
> > CDN
> > c. repeat steps 2a and 2b for each CDN using a custom
> > http.routing.name
> >
> > This would keep everything working the same post-upgrade as it did
> > pre-upgrade, and from that point on you’d be able to change a Delivery
> > Service’s routing name to any arbitrary hostname (without periods).
> >
> > --Rawlin
> >
> > On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
> >
> > 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 routing name and use that when it creates the database column
> and
> > populates it with the pre-defined defaults (edge, tr).
> >
> > Also, creating a global param doesn't help those with more than 1
> CDN.
> >
> > On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> > mitchell852@gmail.com>
> > wrote:
> >
> > > 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
> > > <http://http.routing.name/>) that default to tr and edge
> > respectively and
> > > make the ds.routing_name an optional field.
> > >
> > > in seeds.sql
> > >
> > > insert into parameter (name, config_file, value) values ('
> > > http.routing.name',
> > > 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> > > insert into parameter (name, config_file, value) values ('
> > dns.routing.name
> > > ',
> > > 'global', 'edge') ON CONFLICT (name, config_file, value) DO
> NOTHING;
> > >
> > > in code (warning. ugly pseudo code to follow):
> > >
> > > function getRoutingName(ds) {
> > > return ds.routing_name if not null
> > > if (ds.type = HTTP) {
> > > return parameter.http.routing.name
> > > } else
> > > return parameter.dns.routing.name
> > > }
> > > }
> > >
> > > Just my 2 cents.
> > >
> > > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org>
> > wrote:
> > >
> > > > 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) TR will
> now
> > > ignore
> > > > the setting in the config file. Ideally we would remove the
> param
> > from
> > > the
> > > > default config and the need for the param in the code.
> > > >
> > > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > > Rawlin_Peters@comcast.com>
> > > > wrote:
> > > >
> > > > > 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 files of the
> Traffic
> > > > Routers).
> > > > >
> > > > > For instance, if “http.routing.name” has been set to “ccr”,
> the
> > new
> > > > > routing name
> > > > > “tr” will break all of the clients using the old “ccr” delivery
> > service
> > > > > URL.
> > > > >
> > > > > Basically we need to provide a one-time upgrade step to allow
> > CDNs
> > > using
> > > > a
> > > > > custom
> > > > > “http.routing.name” to default the new routing_name column to
> > that
> > > value
> > > > > for
> > > > > existing HTTP delivery services. What would be the best way to
> > do this?
> > > > > Some options
> > > > > might be:
> > > > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On
> > upgrade,
> > > > > read that
> > > > > parameter and use it to update the routing_name for
> existing
> > HTTP
> > > > > delivery services.
> > > > > After upgrade, you can safely remove the profile parameter.
> > > > > 2. Let the upgrade automatically default the routing_name to
> > ‘tr’ or
> > > > > ‘edge’. After
> > > > > upgrading, manually update each HTTP delivery service to
> use
> > the
> > > > > current
> > > > > “http.routing.name” in use (we could provide an API
> > endpoint to
> > > > “bulk
> > > > > update” the
> > > > > routing names for all HTTP delivery services in a CDN).
> > > > >
> > > > > Note this is not an exhaustive list, this is a just a couple
> > options
> > > that
> > > > > have come up in
> > > > > discussion so far. Feel free to add any more ideas to this
> list.
> > > > >
> > > > > After the upgrade has been completed, the “http.routing.name”
> > > parameter
> > > > > in the
> > > > > Traffic Router’s “http.properties” file will be ignored (same
> > with the
> > > “
> > > > > dns.routing.name”
> > > > > parameter in “dns.properties” which I’m not sure can even be
> > changed
> > > > > safely today).
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --Rawlin
> > > > >
> > > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <
> Rawlin_Peters@comcast.com
> > >
> > > wrote:
> > > > >
> > > > > @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
> > migration,
> > > > we
> > > > > should also provide an API endpoint to set the routing names on
> > all
> > > DSes
> > > > in
> > > > > a CDN to a single value, thus still providing a “per-CDN”
> option.
> > > Would a
> > > > > “bulk” update also be useful, in case a user wants to update a
> > handful
> > > of
> > > > > DSes to the same routing names at once?
> > > > >
> > > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > > The default would come from a TR_PROFILE linked to the CDN,
> > and the
> > > > > override would come from a DS_PROFILE linked to that specific
> > DS. I
> > > > looked
> > > > > into those options to cover all my bases, but I think adding
> > columns to
> > > > at
> > > > > least the DS table and not touching profiles at all is the
> better
> > > option.
> > > > >
> > > > > -Rawlin
> > > > >
> > > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com>
> wrote:
> > > > >
> > > > > 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)
> > <
> > > > > efriedri@cisco.com>
> > > > > 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/
> > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > > > 3Cdev.trafficcontrol.apache.org%3E
> > > > > > <
> > > > > > https://lists.apache.org/thread.html/
> > > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > > > <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_Peters@comcast.com
> > > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > > mailto:
> > > > > > Rawlin_Peters@comcast.com>> 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 default. But, yes, i forgot about the per CDN
thing.
Jeremy
On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin <Ra...@comcast.com>
wrote:
> 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
> updating post-upgrade but before a snap/queue. So either way there needs to
> be sufficient upgrade notes, but personally I still prefer keeping the
> routing_name column non-null.
>
> That said, this is my current proposal for the DB migration which also
> gets us past the upgrade issue:
> 1. Add a routing_name column to the DeliveryService table.
> 2. Update the routing_name for DNS Delivery Services to “edge”.
> 3. Update the routing_name of non-DNS Delivery Services to the value of a
> temporary upgrade parameter associated with the Delivery Service’s CDN (if
> the upgrade parameter doesn’t exist, the routing_names will remain null).
> 4. Update the remaining null routing_names to “tr”.
> 5. Make the routing_name column non-null and add a non-empty constraint.
>
> So these would be an operator’s pre-upgrade steps:
> 1. Verify if a custom http.routing.name has been configured for Traffic
> Routers in their CDNs.
> 2. If custom http.routing.name, do the following. Otherwise, no
> pre-upgrade steps needed (for per-DS routing names at least):
> a. create a parameter named “upgrade_http_routing_name” with the value
> of the target CDN’s custom http.routing.name
> b. associate this parameter to the TR_PROFILE belonging to the target
> CDN
> c. repeat steps 2a and 2b for each CDN using a custom
> http.routing.name
>
> This would keep everything working the same post-upgrade as it did
> pre-upgrade, and from that point on you’d be able to change a Delivery
> Service’s routing name to any arbitrary hostname (without periods).
>
> --Rawlin
>
> On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
>
> 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 routing name and use that when it creates the database column and
> populates it with the pre-defined defaults (edge, tr).
>
> Also, creating a global param doesn't help those with more than 1 CDN.
>
> On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <
> mitchell852@gmail.com>
> wrote:
>
> > 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
> > <http://http.routing.name/>) that default to tr and edge
> respectively and
> > make the ds.routing_name an optional field.
> >
> > in seeds.sql
> >
> > insert into parameter (name, config_file, value) values ('
> > http.routing.name',
> > 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> > insert into parameter (name, config_file, value) values ('
> dns.routing.name
> > ',
> > 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
> >
> > in code (warning. ugly pseudo code to follow):
> >
> > function getRoutingName(ds) {
> > return ds.routing_name if not null
> > if (ds.type = HTTP) {
> > return parameter.http.routing.name
> > } else
> > return parameter.dns.routing.name
> > }
> > }
> >
> > Just my 2 cents.
> >
> > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org>
> wrote:
> >
> > > 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) TR will now
> > ignore
> > > the setting in the config file. Ideally we would remove the param
> from
> > the
> > > default config and the need for the param in the code.
> > >
> > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > Rawlin_Peters@comcast.com>
> > > wrote:
> > >
> > > > 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 files of the Traffic
> > > Routers).
> > > >
> > > > For instance, if “http.routing.name” has been set to “ccr”, the
> new
> > > > routing name
> > > > “tr” will break all of the clients using the old “ccr” delivery
> service
> > > > URL.
> > > >
> > > > Basically we need to provide a one-time upgrade step to allow
> CDNs
> > using
> > > a
> > > > custom
> > > > “http.routing.name” to default the new routing_name column to
> that
> > value
> > > > for
> > > > existing HTTP delivery services. What would be the best way to
> do this?
> > > > Some options
> > > > might be:
> > > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On
> upgrade,
> > > > read that
> > > > parameter and use it to update the routing_name for existing
> HTTP
> > > > delivery services.
> > > > After upgrade, you can safely remove the profile parameter.
> > > > 2. Let the upgrade automatically default the routing_name to
> ‘tr’ or
> > > > ‘edge’. After
> > > > upgrading, manually update each HTTP delivery service to use
> the
> > > > current
> > > > “http.routing.name” in use (we could provide an API
> endpoint to
> > > “bulk
> > > > update” the
> > > > routing names for all HTTP delivery services in a CDN).
> > > >
> > > > Note this is not an exhaustive list, this is a just a couple
> options
> > that
> > > > have come up in
> > > > discussion so far. Feel free to add any more ideas to this list.
> > > >
> > > > After the upgrade has been completed, the “http.routing.name”
> > parameter
> > > > in the
> > > > Traffic Router’s “http.properties” file will be ignored (same
> with the
> > “
> > > > dns.routing.name”
> > > > parameter in “dns.properties” which I’m not sure can even be
> changed
> > > > safely today).
> > > >
> > > > Thoughts?
> > > >
> > > > --Rawlin
> > > >
> > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <Rawlin_Peters@comcast.com
> >
> > wrote:
> > > >
> > > > @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
> migration,
> > > we
> > > > should also provide an API endpoint to set the routing names on
> all
> > DSes
> > > in
> > > > a CDN to a single value, thus still providing a “per-CDN” option.
> > Would a
> > > > “bulk” update also be useful, in case a user wants to update a
> handful
> > of
> > > > DSes to the same routing names at once?
> > > >
> > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > The default would come from a TR_PROFILE linked to the CDN,
> and the
> > > > override would come from a DS_PROFILE linked to that specific
> DS. I
> > > looked
> > > > into those options to cover all my bases, but I think adding
> columns to
> > > at
> > > > least the DS table and not touching profiles at all is the better
> > option.
> > > >
> > > > -Rawlin
> > > >
> > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
> > > >
> > > > 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)
> <
> > > > efriedri@cisco.com>
> > > > 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/
> > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > > 3Cdev.trafficcontrol.apache.org%3E
> > > > > <
> > > > > https://lists.apache.org/thread.html/
> > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > > <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_Peters@comcast.com
> > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > mailto:
> > > > > Rawlin_Peters@comcast.com>> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by Jeff Elsloo <el...@apache.org>.
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 addition to the HTTP routing name case. This also
applies to the pre-upgrade steps. I think this should be acceptable as
long as we make sure to call it out in the release notes.
Along the lines of what Jeremy suggested, I think we can make the new
delivery service routing name column not-null and not break the
existing API, so long as we have suitable defaults. This should only
apply to the create case, as it can remain optional once set for any
future update. If we can leave the http.routing.name and
dns.routing.name profile parameters in place, we will have a
configurable default, and can fall back to something that's hardcoded
(tr, edge) if the parameters are missing.
--
Thanks,
Jeff
On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin
<Ra...@comcast.com> wrote:
> 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 updating post-upgrade but before a snap/queue. So either way there needs to be sufficient upgrade notes, but personally I still prefer keeping the routing_name column non-null.
>
> That said, this is my current proposal for the DB migration which also gets us past the upgrade issue:
> 1. Add a routing_name column to the DeliveryService table.
> 2. Update the routing_name for DNS Delivery Services to “edge”.
> 3. Update the routing_name of non-DNS Delivery Services to the value of a temporary upgrade parameter associated with the Delivery Service’s CDN (if the upgrade parameter doesn’t exist, the routing_names will remain null).
> 4. Update the remaining null routing_names to “tr”.
> 5. Make the routing_name column non-null and add a non-empty constraint.
>
> So these would be an operator’s pre-upgrade steps:
> 1. Verify if a custom http.routing.name has been configured for Traffic Routers in their CDNs.
> 2. If custom http.routing.name, do the following. Otherwise, no pre-upgrade steps needed (for per-DS routing names at least):
> a. create a parameter named “upgrade_http_routing_name” with the value of the target CDN’s custom http.routing.name
> b. associate this parameter to the TR_PROFILE belonging to the target CDN
> c. repeat steps 2a and 2b for each CDN using a custom http.routing.name
>
> This would keep everything working the same post-upgrade as it did pre-upgrade, and from that point on you’d be able to change a Delivery Service’s routing name to any arbitrary hostname (without periods).
>
> --Rawlin
>
> On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
>
> 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 routing name and use that when it creates the database column and
> populates it with the pre-defined defaults (edge, tr).
>
> Also, creating a global param doesn't help those with more than 1 CDN.
>
> On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> > 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
> > <http://http.routing.name/>) that default to tr and edge respectively and
> > make the ds.routing_name an optional field.
> >
> > in seeds.sql
> >
> > insert into parameter (name, config_file, value) values ('
> > http.routing.name',
> > 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> > insert into parameter (name, config_file, value) values ('dns.routing.name
> > ',
> > 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
> >
> > in code (warning. ugly pseudo code to follow):
> >
> > function getRoutingName(ds) {
> > return ds.routing_name if not null
> > if (ds.type = HTTP) {
> > return parameter.http.routing.name
> > } else
> > return parameter.dns.routing.name
> > }
> > }
> >
> > Just my 2 cents.
> >
> > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org> wrote:
> >
> > > 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) TR will now
> > ignore
> > > the setting in the config file. Ideally we would remove the param from
> > the
> > > default config and the need for the param in the code.
> > >
> > > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> > Rawlin_Peters@comcast.com>
> > > wrote:
> > >
> > > > 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 files of the Traffic
> > > Routers).
> > > >
> > > > For instance, if “http.routing.name” has been set to “ccr”, the new
> > > > routing name
> > > > “tr” will break all of the clients using the old “ccr” delivery service
> > > > URL.
> > > >
> > > > Basically we need to provide a one-time upgrade step to allow CDNs
> > using
> > > a
> > > > custom
> > > > “http.routing.name” to default the new routing_name column to that
> > value
> > > > for
> > > > existing HTTP delivery services. What would be the best way to do this?
> > > > Some options
> > > > might be:
> > > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> > > > read that
> > > > parameter and use it to update the routing_name for existing HTTP
> > > > delivery services.
> > > > After upgrade, you can safely remove the profile parameter.
> > > > 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> > > > ‘edge’. After
> > > > upgrading, manually update each HTTP delivery service to use the
> > > > current
> > > > “http.routing.name” in use (we could provide an API endpoint to
> > > “bulk
> > > > update” the
> > > > routing names for all HTTP delivery services in a CDN).
> > > >
> > > > Note this is not an exhaustive list, this is a just a couple options
> > that
> > > > have come up in
> > > > discussion so far. Feel free to add any more ideas to this list.
> > > >
> > > > After the upgrade has been completed, the “http.routing.name”
> > parameter
> > > > in the
> > > > Traffic Router’s “http.properties” file will be ignored (same with the
> > “
> > > > dns.routing.name”
> > > > parameter in “dns.properties” which I’m not sure can even be changed
> > > > safely today).
> > > >
> > > > Thoughts?
> > > >
> > > > --Rawlin
> > > >
> > > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com>
> > wrote:
> > > >
> > > > @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 migration,
> > > we
> > > > should also provide an API endpoint to set the routing names on all
> > DSes
> > > in
> > > > a CDN to a single value, thus still providing a “per-CDN” option.
> > Would a
> > > > “bulk” update also be useful, in case a user wants to update a handful
> > of
> > > > DSes to the same routing names at once?
> > > >
> > > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > > The default would come from a TR_PROFILE linked to the CDN, and the
> > > > override would come from a DS_PROFILE linked to that specific DS. I
> > > looked
> > > > into those options to cover all my bases, but I think adding columns to
> > > at
> > > > least the DS table and not touching profiles at all is the better
> > option.
> > > >
> > > > -Rawlin
> > > >
> > > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
> > > >
> > > > 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) <
> > > > efriedri@cisco.com>
> > > > 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/
> > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > > 3Cdev.trafficcontrol.apache.org%3E
> > > > > <
> > > > > https://lists.apache.org/thread.html/
> > > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > > <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_Peters@comcast.com
> > > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > > mailto:
> > > > > Rawlin_Peters@comcast.com>> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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 updating post-upgrade but before a snap/queue. So either way there needs to be sufficient upgrade notes, but personally I still prefer keeping the routing_name column non-null.
That said, this is my current proposal for the DB migration which also gets us past the upgrade issue:
1. Add a routing_name column to the DeliveryService table.
2. Update the routing_name for DNS Delivery Services to “edge”.
3. Update the routing_name of non-DNS Delivery Services to the value of a temporary upgrade parameter associated with the Delivery Service’s CDN (if the upgrade parameter doesn’t exist, the routing_names will remain null).
4. Update the remaining null routing_names to “tr”.
5. Make the routing_name column non-null and add a non-empty constraint.
So these would be an operator’s pre-upgrade steps:
1. Verify if a custom http.routing.name has been configured for Traffic Routers in their CDNs.
2. If custom http.routing.name, do the following. Otherwise, no pre-upgrade steps needed (for per-DS routing names at least):
a. create a parameter named “upgrade_http_routing_name” with the value of the target CDN’s custom http.routing.name
b. associate this parameter to the TR_PROFILE belonging to the target CDN
c. repeat steps 2a and 2b for each CDN using a custom http.routing.name
This would keep everything working the same post-upgrade as it did pre-upgrade, and from that point on you’d be able to change a Delivery Service’s routing name to any arbitrary hostname (without periods).
--Rawlin
On 8/14/17, 4:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
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 routing name and use that when it creates the database column and
populates it with the pre-defined defaults (edge, tr).
Also, creating a global param doesn't help those with more than 1 CDN.
On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <mi...@gmail.com>
wrote:
> 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
> <http://http.routing.name/>) that default to tr and edge respectively and
> make the ds.routing_name an optional field.
>
> in seeds.sql
>
> insert into parameter (name, config_file, value) values ('
> http.routing.name',
> 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value) values ('dns.routing.name
> ',
> 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
>
> in code (warning. ugly pseudo code to follow):
>
> function getRoutingName(ds) {
> return ds.routing_name if not null
> if (ds.type = HTTP) {
> return parameter.http.routing.name
> } else
> return parameter.dns.routing.name
> }
> }
>
> Just my 2 cents.
>
> On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org> wrote:
>
> > 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) TR will now
> ignore
> > the setting in the config file. Ideally we would remove the param from
> the
> > default config and the need for the param in the code.
> >
> > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> Rawlin_Peters@comcast.com>
> > wrote:
> >
> > > 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 files of the Traffic
> > Routers).
> > >
> > > For instance, if “http.routing.name” has been set to “ccr”, the new
> > > routing name
> > > “tr” will break all of the clients using the old “ccr” delivery service
> > > URL.
> > >
> > > Basically we need to provide a one-time upgrade step to allow CDNs
> using
> > a
> > > custom
> > > “http.routing.name” to default the new routing_name column to that
> value
> > > for
> > > existing HTTP delivery services. What would be the best way to do this?
> > > Some options
> > > might be:
> > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> > > read that
> > > parameter and use it to update the routing_name for existing HTTP
> > > delivery services.
> > > After upgrade, you can safely remove the profile parameter.
> > > 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> > > ‘edge’. After
> > > upgrading, manually update each HTTP delivery service to use the
> > > current
> > > “http.routing.name” in use (we could provide an API endpoint to
> > “bulk
> > > update” the
> > > routing names for all HTTP delivery services in a CDN).
> > >
> > > Note this is not an exhaustive list, this is a just a couple options
> that
> > > have come up in
> > > discussion so far. Feel free to add any more ideas to this list.
> > >
> > > After the upgrade has been completed, the “http.routing.name”
> parameter
> > > in the
> > > Traffic Router’s “http.properties” file will be ignored (same with the
> “
> > > dns.routing.name”
> > > parameter in “dns.properties” which I’m not sure can even be changed
> > > safely today).
> > >
> > > Thoughts?
> > >
> > > --Rawlin
> > >
> > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com>
> wrote:
> > >
> > > @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 migration,
> > we
> > > should also provide an API endpoint to set the routing names on all
> DSes
> > in
> > > a CDN to a single value, thus still providing a “per-CDN” option.
> Would a
> > > “bulk” update also be useful, in case a user wants to update a handful
> of
> > > DSes to the same routing names at once?
> > >
> > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > The default would come from a TR_PROFILE linked to the CDN, and the
> > > override would come from a DS_PROFILE linked to that specific DS. I
> > looked
> > > into those options to cover all my bases, but I think adding columns to
> > at
> > > least the DS table and not touching profiles at all is the better
> option.
> > >
> > > -Rawlin
> > >
> > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
> > >
> > > 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) <
> > > efriedri@cisco.com>
> > > 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/
> > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > 3Cdev.trafficcontrol.apache.org%3E
> > > > <
> > > > https://lists.apache.org/thread.html/
> > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > <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_Peters@comcast.com
> > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > mailto:
> > > > Rawlin_Peters@comcast.com>> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Dave Neuman <ne...@apache.org>.
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 routing name and use that when it creates the database column and
populates it with the pre-defined defaults (edge, tr).
Also, creating a global param doesn't help those with more than 1 CDN.
On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell <mi...@gmail.com>
wrote:
> 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
> <http://http.routing.name/>) that default to tr and edge respectively and
> make the ds.routing_name an optional field.
>
> in seeds.sql
>
> insert into parameter (name, config_file, value) values ('
> http.routing.name',
> 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value) values ('dns.routing.name
> ',
> 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
>
> in code (warning. ugly pseudo code to follow):
>
> function getRoutingName(ds) {
> return ds.routing_name if not null
> if (ds.type = HTTP) {
> return parameter.http.routing.name
> } else
> return parameter.dns.routing.name
> }
> }
>
> Just my 2 cents.
>
> On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org> wrote:
>
> > 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) TR will now
> ignore
> > the setting in the config file. Ideally we would remove the param from
> the
> > default config and the need for the param in the code.
> >
> > On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <
> Rawlin_Peters@comcast.com>
> > wrote:
> >
> > > 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 files of the Traffic
> > Routers).
> > >
> > > For instance, if “http.routing.name” has been set to “ccr”, the new
> > > routing name
> > > “tr” will break all of the clients using the old “ccr” delivery service
> > > URL.
> > >
> > > Basically we need to provide a one-time upgrade step to allow CDNs
> using
> > a
> > > custom
> > > “http.routing.name” to default the new routing_name column to that
> value
> > > for
> > > existing HTTP delivery services. What would be the best way to do this?
> > > Some options
> > > might be:
> > > 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> > > read that
> > > parameter and use it to update the routing_name for existing HTTP
> > > delivery services.
> > > After upgrade, you can safely remove the profile parameter.
> > > 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> > > ‘edge’. After
> > > upgrading, manually update each HTTP delivery service to use the
> > > current
> > > “http.routing.name” in use (we could provide an API endpoint to
> > “bulk
> > > update” the
> > > routing names for all HTTP delivery services in a CDN).
> > >
> > > Note this is not an exhaustive list, this is a just a couple options
> that
> > > have come up in
> > > discussion so far. Feel free to add any more ideas to this list.
> > >
> > > After the upgrade has been completed, the “http.routing.name”
> parameter
> > > in the
> > > Traffic Router’s “http.properties” file will be ignored (same with the
> “
> > > dns.routing.name”
> > > parameter in “dns.properties” which I’m not sure can even be changed
> > > safely today).
> > >
> > > Thoughts?
> > >
> > > --Rawlin
> > >
> > > On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com>
> wrote:
> > >
> > > @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 migration,
> > we
> > > should also provide an API endpoint to set the routing names on all
> DSes
> > in
> > > a CDN to a single value, thus still providing a “per-CDN” option.
> Would a
> > > “bulk” update also be useful, in case a user wants to update a handful
> of
> > > DSes to the same routing names at once?
> > >
> > > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > > The default would come from a TR_PROFILE linked to the CDN, and the
> > > override would come from a DS_PROFILE linked to that specific DS. I
> > looked
> > > into those options to cover all my bases, but I think adding columns to
> > at
> > > least the DS table and not touching profiles at all is the better
> option.
> > >
> > > -Rawlin
> > >
> > > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
> > >
> > > 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) <
> > > efriedri@cisco.com>
> > > 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/
> > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > > 3Cdev.trafficcontrol.apache.org%3E
> > > > <
> > > > https://lists.apache.org/thread.html/
> > > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > > <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_Peters@comcast.com
> > > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > > mailto:
> > > > Rawlin_Peters@comcast.com>> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Jeremy Mitchell <mi...@gmail.com>.
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
<http://http.routing.name/>) that default to tr and edge respectively and
make the ds.routing_name an optional field.
in seeds.sql
insert into parameter (name, config_file, value) values ('http.routing.name',
'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
insert into parameter (name, config_file, value) values ('dns.routing.name',
'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
in code (warning. ugly pseudo code to follow):
function getRoutingName(ds) {
return ds.routing_name if not null
if (ds.type = HTTP) {
return parameter.http.routing.name
} else
return parameter.dns.routing.name
}
}
Just my 2 cents.
On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman <ne...@apache.org> wrote:
> 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) TR will now ignore
> the setting in the config file. Ideally we would remove the param from the
> default config and the need for the param in the code.
>
> On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <Ra...@comcast.com>
> wrote:
>
> > 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 files of the Traffic
> Routers).
> >
> > For instance, if “http.routing.name” has been set to “ccr”, the new
> > routing name
> > “tr” will break all of the clients using the old “ccr” delivery service
> > URL.
> >
> > Basically we need to provide a one-time upgrade step to allow CDNs using
> a
> > custom
> > “http.routing.name” to default the new routing_name column to that value
> > for
> > existing HTTP delivery services. What would be the best way to do this?
> > Some options
> > might be:
> > 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> > read that
> > parameter and use it to update the routing_name for existing HTTP
> > delivery services.
> > After upgrade, you can safely remove the profile parameter.
> > 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> > ‘edge’. After
> > upgrading, manually update each HTTP delivery service to use the
> > current
> > “http.routing.name” in use (we could provide an API endpoint to
> “bulk
> > update” the
> > routing names for all HTTP delivery services in a CDN).
> >
> > Note this is not an exhaustive list, this is a just a couple options that
> > have come up in
> > discussion so far. Feel free to add any more ideas to this list.
> >
> > After the upgrade has been completed, the “http.routing.name” parameter
> > in the
> > Traffic Router’s “http.properties” file will be ignored (same with the “
> > dns.routing.name”
> > parameter in “dns.properties” which I’m not sure can even be changed
> > safely today).
> >
> > Thoughts?
> >
> > --Rawlin
> >
> > On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com> wrote:
> >
> > @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 migration,
> we
> > should also provide an API endpoint to set the routing names on all DSes
> in
> > a CDN to a single value, thus still providing a “per-CDN” option. Would a
> > “bulk” update also be useful, in case a user wants to update a handful of
> > DSes to the same routing names at once?
> >
> > @JvD Re: TR_PROFILE vs. DS_PROFILE
> > The default would come from a TR_PROFILE linked to the CDN, and the
> > override would come from a DS_PROFILE linked to that specific DS. I
> looked
> > into those options to cover all my bases, but I think adding columns to
> at
> > least the DS table and not touching profiles at all is the better option.
> >
> > -Rawlin
> >
> > On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
> >
> > 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) <
> > efriedri@cisco.com>
> > 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/
> > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> > 3Cdev.trafficcontrol.apache.org%3E
> > > <
> > > https://lists.apache.org/thread.html/
> > 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > > <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_Peters@comcast.com
> > > <ma...@comcast.com>> 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_Peters@comcast.com<
> > mailto:
> > > Rawlin_Peters@comcast.com>> 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
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
Re: Adding support for per-DeliveryService routing names
Posted by Dave Neuman <ne...@apache.org>.
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) TR will now ignore
the setting in the config file. Ideally we would remove the param from the
default config and the need for the param in the code.
On Wed, Aug 9, 2017 at 4:28 PM, Peters, Rawlin <Ra...@comcast.com>
wrote:
> 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 files of the Traffic Routers).
>
> For instance, if “http.routing.name” has been set to “ccr”, the new
> routing name
> “tr” will break all of the clients using the old “ccr” delivery service
> URL.
>
> Basically we need to provide a one-time upgrade step to allow CDNs using a
> custom
> “http.routing.name” to default the new routing_name column to that value
> for
> existing HTTP delivery services. What would be the best way to do this?
> Some options
> might be:
> 1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade,
> read that
> parameter and use it to update the routing_name for existing HTTP
> delivery services.
> After upgrade, you can safely remove the profile parameter.
> 2. Let the upgrade automatically default the routing_name to ‘tr’ or
> ‘edge’. After
> upgrading, manually update each HTTP delivery service to use the
> current
> “http.routing.name” in use (we could provide an API endpoint to “bulk
> update” the
> routing names for all HTTP delivery services in a CDN).
>
> Note this is not an exhaustive list, this is a just a couple options that
> have come up in
> discussion so far. Feel free to add any more ideas to this list.
>
> After the upgrade has been completed, the “http.routing.name” parameter
> in the
> Traffic Router’s “http.properties” file will be ignored (same with the “
> dns.routing.name”
> parameter in “dns.properties” which I’m not sure can even be changed
> safely today).
>
> Thoughts?
>
> --Rawlin
>
> On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com> wrote:
>
> @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 migration, we
> should also provide an API endpoint to set the routing names on all DSes in
> a CDN to a single value, thus still providing a “per-CDN” option. Would a
> “bulk” update also be useful, in case a user wants to update a handful of
> DSes to the same routing names at once?
>
> @JvD Re: TR_PROFILE vs. DS_PROFILE
> The default would come from a TR_PROFILE linked to the CDN, and the
> override would come from a DS_PROFILE linked to that specific DS. I looked
> into those options to cover all my bases, but I think adding columns to at
> least the DS table and not touching profiles at all is the better option.
>
> -Rawlin
>
> On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
>
> 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) <
> efriedri@cisco.com>
> 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/
> 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%
> 3Cdev.trafficcontrol.apache.org%3E
> > <
> > https://lists.apache.org/thread.html/
> 51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> > <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_Peters@comcast.com
> > <ma...@comcast.com>> 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_Peters@comcast.com<
> mailto:
> > Rawlin_Peters@comcast.com>> 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
> >
> >
> >
> >
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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 files of the Traffic Routers).
For instance, if “http.routing.name” has been set to “ccr”, the new routing name
“tr” will break all of the clients using the old “ccr” delivery service URL.
Basically we need to provide a one-time upgrade step to allow CDNs using a custom
“http.routing.name” to default the new routing_name column to that value for
existing HTTP delivery services. What would be the best way to do this? Some options
might be:
1. Add a profile parameter to the TR_PROFILE for that CDN. On upgrade, read that
parameter and use it to update the routing_name for existing HTTP delivery services.
After upgrade, you can safely remove the profile parameter.
2. Let the upgrade automatically default the routing_name to ‘tr’ or ‘edge’. After
upgrading, manually update each HTTP delivery service to use the current
“http.routing.name” in use (we could provide an API endpoint to “bulk update” the
routing names for all HTTP delivery services in a CDN).
Note this is not an exhaustive list, this is a just a couple options that have come up in
discussion so far. Feel free to add any more ideas to this list.
After the upgrade has been completed, the “http.routing.name” parameter in the
Traffic Router’s “http.properties” file will be ignored (same with the “dns.routing.name”
parameter in “dns.properties” which I’m not sure can even be changed safely today).
Thoughts?
--Rawlin
On 8/4/17, 10:19 AM, "Peters, Rawlin" <Ra...@comcast.com> wrote:
@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 migration, we should also provide an API endpoint to set the routing names on all DSes in a CDN to a single value, thus still providing a “per-CDN” option. Would a “bulk” update also be useful, in case a user wants to update a handful of DSes to the same routing names at once?
@JvD Re: TR_PROFILE vs. DS_PROFILE
The default would come from a TR_PROFILE linked to the CDN, and the override would come from a DS_PROFILE linked to that specific DS. I looked into those options to cover all my bases, but I think adding columns to at least the DS table and not touching profiles at all is the better option.
-Rawlin
On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
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) <ef...@cisco.com>
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/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
> <
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> <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_Peters@comcast.com
> <ma...@comcast.com>> 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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com>> 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
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
@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 migration, we should also provide an API endpoint to set the routing names on all DSes in a CDN to a single value, thus still providing a “per-CDN” option. Would a “bulk” update also be useful, in case a user wants to update a handful of DSes to the same routing names at once?
@JvD Re: TR_PROFILE vs. DS_PROFILE
The default would come from a TR_PROFILE linked to the CDN, and the override would come from a DS_PROFILE linked to that specific DS. I looked into those options to cover all my bases, but I think adding columns to at least the DS table and not touching profiles at all is the better option.
-Rawlin
On 8/4/17, 8:04 AM, "Jan van Doorn" <jv...@knutsel.com> wrote:
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) <ef...@cisco.com>
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/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
> <
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> <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_Peters@comcast.com
> <ma...@comcast.com>> 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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com>> 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
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
No problem. I took a look at your work, and to me it also looks different. We’re touching the
same code in a few places, but I think it will be fairly straightforward to resolve the merge conflicts
once we get to that point.
--Rawlin
On 8/7/17, 12:13 AM, "Zhilin Huang (zhilhuan)" <zh...@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)" <ef...@cisco.com> wrote:
> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <Ra...@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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: David Neuman <da...@gmail.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
> Date: Friday, August 4, 2017 at 8:40 AM
> To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
> mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: Jan van Doorn <jv...@knutsel.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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) <
> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
> <mailto:efriedri@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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com><
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
Eric,
The use case is better customizability by allowing a delivery service’s routing name
(e.g. “edge” or “tr” currently) to be whatever you want. Right now a DS’s FQDN
typically follows this format: <routing_name>.<xml_id>.<cdn_domain>
For example: edge.my-ds.mycdn.com
However, that <xml_id> portion really comes from the chosen HOST_REGEXP (Order: 0),
which the API auto-creates for you using the xml_id like so:
.*\.<xml_id>\..*
For example: .*\.my-ds\..*
If a different HOST_REGEXP (Order: 0) is created for that DS, for instance “.*\.still-my-ds\..*”,
the DS’s FQDN would be “edge.still-my-ds.mycdn.com”. So, the DS xml_id isn’t really tied to the
DS’s FQDN; it’s just what is used by default. With customizable routing names, that FQDN could
be “foo.still-my-ds.mycdn.com” or “bar.still-my-ds.mycdn.com”.
Today, you can change the HTTP routing name for a CDN (currently defaulted to “tr”) by changing
the “http.routing.name” parameter in the Traffic Router’s “http.properties” file for all Traffic
Routers in the CDN. However, this parameter isn’t tied back to Traffic Ops, which is why in the UI
an HTTP delivery service’s example URL uses the routing name “ccr”. That mismatches with the
current functional default of “tr”. With customizable routing names, the user will be able to choose
through the UI or API whatever they want, and the shown example URLs will actually be functional.
--Rawlin
On 8/7/17, 6:16 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
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) <zh...@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)" <ef...@cisco.com> wrote:
>
>
>> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <Ra...@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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>>
>>
>>
>> From: David Neuman <da...@gmail.com>>
>> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
>> Date: Friday, August 4, 2017 at 8:40 AM
>> To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
>> mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>>
>>
>>
>> From: Jan van Doorn <jv...@knutsel.com>>
>> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
>> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
>> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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) <
>> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
>> <mailto:efriedri@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_Peters@comcast.com<
>> mailto:Rawlin_Peters@comcast.com><
>> mailto:Rawlin_Peters@comcast.com>
>> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
>> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
>> Rawlin_Peters@comcast.com><mailto:
>> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
>> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
>> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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) <zh...@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)" <ef...@cisco.com> wrote:
>
>
>> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <Ra...@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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>>
>>
>>
>> From: David Neuman <da...@gmail.com>>
>> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
>> Date: Friday, August 4, 2017 at 8:40 AM
>> To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
>> mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>><mailto:
>> cdn_support@comcast.com<ma...@comcast.com>>
>>
>>
>> From: Jan van Doorn <jv...@knutsel.com>>
>> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
>> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
>> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
>> dev@trafficcontrol.incubator.apache.org<ma...@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) <
>> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
>> <mailto:efriedri@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_Peters@comcast.com<
>> mailto:Rawlin_Peters@comcast.com><
>> mailto:Rawlin_Peters@comcast.com>
>> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
>> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
>> Rawlin_Peters@comcast.com><mailto:
>> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
>> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
>> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Zhilin Huang (zhilhuan)" <zh...@cisco.com>.
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)" <ef...@cisco.com> wrote:
> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <Ra...@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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: David Neuman <da...@gmail.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
> Date: Friday, August 4, 2017 at 8:40 AM
> To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
> mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: Jan van Doorn <jv...@knutsel.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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) <
> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
> <mailto:efriedri@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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com><
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
> On Aug 4, 2017, at 3:09 PM, Peters, Rawlin <Ra...@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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: David Neuman <da...@gmail.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
> Date: Friday, August 4, 2017 at 8:40 AM
> To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
> mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: Jan van Doorn <jv...@knutsel.com>>
> Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
> trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
> dev@trafficcontrol.incubator.apache.org<ma...@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) <
> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
> <mailto:efriedri@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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com><
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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?
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)" <ef...@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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
cdn_support@comcast.com<ma...@comcast.com>>
From: David Neuman <da...@gmail.com>>
Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
Date: Friday, August 4, 2017 at 8:40 AM
To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
cdn_support@comcast.com<ma...@comcast.com>><mailto:
cdn_support@comcast.com<ma...@comcast.com>>
From: Jan van Doorn <jv...@knutsel.com>>
Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
dev@trafficcontrol.incubator.apache.org<ma...@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) <
efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
<mailto:efriedri@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_Peters@comcast.com<
mailto:Rawlin_Peters@comcast.com><
mailto:Rawlin_Peters@comcast.com>
<ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
%3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
Rawlin_Peters@comcast.com><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
Re: Adding support for per-DeliveryService routing names
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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 <Ra...@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" <ne...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
cdn_support@comcast.com<ma...@comcast.com>>
From: David Neuman <da...@gmail.com>>
Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
Date: Friday, August 4, 2017 at 8:40 AM
To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@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 <Ry...@comcast.com><
mailto:Ryan_Durfey@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_support@comcast.com<ma...@comcast.com><mailto:
cdn_support@comcast.com<ma...@comcast.com>><mailto:
cdn_support@comcast.com<ma...@comcast.com>>
From: Jan van Doorn <jv...@knutsel.com>>
Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
dev@trafficcontrol.incubator.apache.org<ma...@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<ma...@trafficcontrol.incubator.apache.org><mailto:dev@
trafficcontrol.incubator.apache.org<http://trafficcontrol.incubator.apache.org>>" <
dev@trafficcontrol.incubator.apache.org<ma...@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) <
efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
<mailto:efriedri@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_Peters@comcast.com<
mailto:Rawlin_Peters@comcast.com><
mailto:Rawlin_Peters@comcast.com>
<ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
%3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
Rawlin_Peters@comcast.com><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
@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.”, 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" <ne...@apache.org> wrote:
@Eric
It looks like Zhilin's proposal is for custom delivery service domains (eg
instead of "tr.foo.domain.com" you can have "tr.foo.otherdomain.com") while
Rawlins is for custom routing names (eg instead of "tr.foo.domain.com" you
can have "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 <Ry...@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_support@comcast.com<mailto:
> cdn_support@comcast.com>
>
>
> From: David Neuman <da...@gmail.com>
> Reply-To: "dev@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 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_Durfey@comcast.com<
> mailto:Ryan_Durfey@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_support@comcast.com<mailto:
> cdn_support@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: Jan van Doorn <jv...@knutsel.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:04 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
>
> 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) <
> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
> ><mailto:efriedri@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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com><
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>
>
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by Dave Neuman <ne...@apache.org>.
@Eric
It looks like Zhilin's proposal is for custom delivery service domains (eg
instead of "tr.foo.domain.com" you can have "tr.foo.otherdomain.com") while
Rawlins is for custom routing names (eg instead of "tr.foo.domain.com" you
can have "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 <Ry...@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_support@comcast.com<mailto:
> cdn_support@comcast.com>
>
>
> From: David Neuman <da...@gmail.com>
> Reply-To: "dev@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 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_Durfey@comcast.com<
> mailto:Ryan_Durfey@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_support@comcast.com<mailto:
> cdn_support@comcast.com><mailto:
> cdn_support@comcast.com<ma...@comcast.com>>
>
>
> From: Jan van Doorn <jv...@knutsel.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:04 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
>
> 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) <
> efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@cisco.com
> ><mailto:efriedri@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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com><
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com
> %3e><mailto:Rawlin_Peters@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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com><mailto:
> Rawlin_Peters@comcast.com>><mailto:Rawlin_Peters@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
>
>
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Durfey, Ryan" <Ry...@comcast.com>.
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_support@comcast.com<ma...@comcast.com>
From: David Neuman <da...@gmail.com>
Reply-To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Date: Friday, August 4, 2017 at 8:40 AM
To: "dev@trafficcontrol.incubator.apache.org" <de...@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 <Ry...@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_support@comcast.com<ma...@comcast.com><mailto:
cdn_support@comcast.com<ma...@comcast.com>>
From: Jan van Doorn <jv...@knutsel.com>>
Reply-To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>>
Date: Friday, August 4, 2017 at 8:04 AM
To: "dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <
dev@trafficcontrol.incubator.apache.org<ma...@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) <
efriedri@cisco.com<ma...@cisco.com><mailto:efriedri@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 <Ra...@comcast.com><
mailto:Rawlin_Peters@comcast.com>
<ma...@comcast.com><mailto:Rawlin_Peters@comcast.com%3e><mailto:Rawlin_Peters@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" <Ra...@comcast.com><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com>><mailto:Rawlin_Peters@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
Re: Adding support for per-DeliveryService routing names
Posted by David Neuman <da...@gmail.com>.
@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 <Ry...@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_support@comcast.com<mailto:
> cdn_support@comcast.com>
>
>
> From: Jan van Doorn <jv...@knutsel.com>
> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.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 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) <
> efriedri@cisco.com<ma...@cisco.com>>
> 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
> <
> 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_Peters@comcast.com<
> mailto:Rawlin_Peters@comcast.com>
> <ma...@comcast.com><mailto:Rawlin_Peters@comcast.com%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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com><mailto:
> Rawlin_Peters@comcast.com<ma...@comcast.com>>> 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
>
>
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Durfey, Ryan" <Ry...@comcast.com>.
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_support@comcast.com<ma...@comcast.com>
From: Jan van Doorn <jv...@knutsel.com>
Reply-To: "dev@trafficcontrol.incubator.apache.org" <de...@trafficcontrol.incubator.apache.org>
Date: Friday, August 4, 2017 at 8:04 AM
To: "dev@trafficcontrol.incubator.apache.org" <de...@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) <ef...@cisco.com>>
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/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
<
https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
<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 <Ra...@comcast.com>
<ma...@comcast.com><mailto:Rawlin_Peters@comcast.com%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" <Ra...@comcast.com><mailto:
Rawlin_Peters@comcast.com<ma...@comcast.com>>> 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
Re: Adding support for per-DeliveryService routing names
Posted by Jan van Doorn <jv...@knutsel.com>.
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) <ef...@cisco.com>
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/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
> <
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@
> <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_Peters@comcast.com
> <ma...@comcast.com>> 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_Peters@comcast.com<mailto:
> Rawlin_Peters@comcast.com>> 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
>
>
>
>
Re: Adding support for per-DeliveryService routing names
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
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<https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f3897da37ef5b24ac452a17cabb@<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 <Ra...@comcast.com>> 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" <Ra...@comcast.com>> 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
Re: Adding support for per-DeliveryService routing names
Posted by "Peters, Rawlin" <Ra...@comcast.com>.
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" <Ra...@comcast.com> 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