You're not mistaken, Jonathan, that is how the logic basically flows
today; however, with cachegroup fallback configuration now it can be
deep[if enabled] -> cz -> geo[if fallback config allows].
Marking a cachegroup as "CZ-only" is really about filtering possible
cachegroups in selection *after* a client's location is discovered (by
geoIP DB). So it can really be described as "given the method of
client localization, filter out certain cachegroup targets".
"Deep-only": filtered out after the "CZ localization" and "post-Geo
localization" steps
"CZ-only": filtered out after the "Geo localization" step
"Geo-only": filtered out after the "deep/regular-CZ" steps
Right now, those all seem somewhat mutually exclusive (except CZ kind
of includes both deep and regular CZ), unless you wanted to do
something like "Deep and Geo only". I don't know if that's a valid use
case, but maybe "CZ and Future-thing only" would make sense. So maybe
cachegroups should really be described as:
"Deep-enabled": allowed after "deep-CZ localization" step
"CZ-enabled": allowed after the "regular-CZ localization" step
"Geo-enabled": allowed after the "geo localization" step
"Future-thing-enabled": allowed after the "future-thing" step
Then we could add multiple permissions to a cachegroup rather than
making them mutually exclusive. For the initial use case I proposed
this for, I would just be marking the cachegroups that aren't directly
connected to the internet as "Deep-enabled, CZ-enabled,
future-thing-enabled" rather than "CZ-only". "Deep-only" cachegroups
would be marked "deep-enabled".
If no permissions are configured, all permissions are given. Enabling
one permission means all other permissions are disabled.
I think this could be done by adding an array-type column to the
cachegroup table/API like so:
{
"name": "cache_group_edge",
"shortName": "cg_edge",
"latitude": 12,
"longitude": 45,
"permissions": [
"DEEP",
"CZ",
"GEO"
],
"typeId": 6
}
The "permissions" field would remain optional, meaning that no
permissions chosen assumes *all* permissions are enabled (giving you
the existing default behavior). Postgres has array-type columns which
would map to this API quite nicely. In fact, I'm also kind of
rethinking the "Cachegroup Fallback" API after going over this,
because listing a cachegroup's fallbacks in an array like this could
make sense and remove the need for the new cachegroup_fallbacks API...
On Wed, Jul 4, 2018 at 3:47 PM Gray, Jonathan <[email protected]> wrote:
>
> 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" <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> > 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
> > > <[email protected]> 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" <[email protected]>
> 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
> > > >
> > > >
> > >
> >
>
>
