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 > >
