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

Reply via email to