If I'm not mistaken, today the logic is fall through on miss (deep[if enabled]
-> cz -> geo). The suggestion to make a 1:* relationship moves that from being
implicit in the code to explicit choice by the DS owner. Changing the
database/apis is expensive enough that maybe we can't make that jump near term.
If you do only add a single field for this using an enum, there should be a
default 'fallthrough' or 'native' option to replicate the old behavior. Also,
I misspoke earlier, this isn't about the routing methods it's about
localization methods.
On 7/4/18, 11:18 AM, "Jeremy Mitchell" <mitchell...@gmail.com> wrote:
Can a cache group have many "routing methods". If not, would one column
(cachegroup.routing_method) suffice where acceptable values are an enum? (
CZ, DEEP, GEO)
On Tue, Jul 3, 2018 at 7:05 PM, Mark Torluemke <mtorlue...@apache.org>
wrote:
> Feels like columns in the cachegroup table could go a long way in the
short
> term -- routing_cz, routing_geo, routing_deep?
>
> On Tue, Jul 3, 2018 at 1:04 PM, Rawlin Peters <rawlin.pet...@gmail.com>
> wrote:
>
> > Thanks for the suggestion, Jonathan. I wasn't even thinking about the
> > possibility of "deep-only" cachegroups, but I could definitely see
> > that as a future use case.
> >
> > Do you envision something like a table of cachegroup permissions
> > (cachegroup_id, cachegroup_permission enum type), where the enums
> > would be DEEP_ONLY and CZ_ONLY to start with? That would definitely
> > increase initial dev time a bit and might require some new API
> > endpoints to add/remove permissions unless we can make the new API
> > field use an array value.
> > On Tue, Jul 3, 2018 at 12:23 PM Gray, Jonathan
> > <jonathan_g...@comcast.com> wrote:
> > >
> > > Rather than a cz_only flag, it might be more powerful to have a join
> > table with allowed routing methods. You could cover the same use case,
> but
> > it would also allow you to do certain things like deep_only or
> effectively
> > not-geo.
> > >
> > > - Jonathan
> > >
> > > On 7/3/18, 12:03 PM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote:
> > >
> > > Hey Traffic Controllers,
> > >
> > > I'd like to be able to mark a cachegroup as "CZ-only" via the API
> so
> > > that off-net clients (i.e. IPs that aren't included in the
Coverage
> > > Zone File) don't get routed to "CZ-only" cachegroups. This is
> because
> > > some cachegroups aren't directly connected to the internet and
> > routing
> > > off-net clients to those cachegroups is expensive. This proposal
> > would
> > > change Traffic Router behavior to route these clients to the
> closest
> > > available cachegroup that's NOT marked as "CZ-only".
> > >
> > > My proposal is to add a boolean column to the cachegroup table -
> > > cz_only - which is then included in the CRConfig's "edgeLocations"
> > for
> > > Traffic Router to parse and look up when routing off-net clients.
> By
> > > default it will be false to keep the existing behavior. The new
> field
> > > will be optional in the API but NOT NULL in the DB, so null values
> in
> > > requests will explicitly be set to false in the DB.
> > >
> > > Questions/concerns?
> > >
> > > - Rawlin
> > >
> > >
> >
>
