Re: Backup Cache Group Selection

If we start by putting this in the Cache Group API first, then later we really only have to worry about adding the CIDRs to the API. The backup config is really just relationships between cache groups, which makes perfect sense to model in a relational DB rather than the CZF. Why put something in

Re: Delivery Service Origin Refactor

Hey Nir, I think part of the motivation for doing this in Traffic Router rather than the Caching Proxy is separation of concerns. TR is already concerned with routing a client to the best cache based upon the client's location, so TR is already well-equipped to make the decision of how Delivery

Re: Backup Cache Group Selection

Good point Rawlin, but I think it does answer your questions. CZF for now, whatever the new CZF thing is after that. On Mon, Mar 12, 2018 at 1:44 PM, Rawlin Peters wrote: > The original scope of this thread was determining where the Backup > Cache Group config should

Fwd: Delivery Service Origin Refactor

Hi Rawlin, Can you please add a few word for the motivation behind basing the steering target selection on the location of the client? As the content goes through the caches, isn't it the job of the cache to select the best origin for the cache? Why the client should be the one to take the origin

Delivery Service Origin Refactor

Hey folks, As promised, this email thread will be to discuss how to best associate an Origin Latitude/Longitude with a Delivery Service, primarily so that steering targets can be ordered/sent to the client based upon the location of those targets (i.e. the Origin), a.k.a. Steering Target

Re: Backup Cache Group Selection

The original scope of this thread was determining where the Backup Cache Group config should live (API vs CZF), not necessarily about building the entire CZF in the database, although I'm +1 on that idea as well. I think any decisions made about doing that should probably be started in a separate

Re: Traffic Ops Access Control v2

This sounds great Jeremy, looking forward to it getting implemented. A few things though: 1) The "proposed roles" are really just "default roles" right? Meaning we will provide a way to create new roles and assign capabilities to them? 2) We will provide a way to CRUD capabilities, correct? 3)

Re: Backup Cache Group Selection

@VijayAnand: Right, a Coverage Zone that doesn't map to a Cache Group in TO won't be chosen as a backup in case of failure, but you could have a Coverage-Zone-not-in-TO that configures Coverage-Zones-in-TO as backups. But, I think the general sentiment right now is that all Coverage Zones in the

Re: Backup Cache Group Selection

Eric, I agree with this as well, maybe we build separate API's for "loading" CZF formats (or any other types of external data) into the same area of the data model (however that ultimately looks). If we keep the CZF data centralized it'll be easier to build relationships if needed. -Dew On

Re: Backup Cache Group Selection

Rawlin, I believe the following statement is not correct. However, after reading your initial proposal below, it sounds like you might have Coverage Zones in your CZF that don't necessarily map back to Cache Groups in TO. Might that be the case? We can have Coverage Zones in CZF which

Re: Backup Cache Group Selection

Good point. I think it makes sense to move both the backupList and coordinates into the CG API. By move coordinates into the API, I’m implying that we consolidate into 1 set of coordinates per CG. The existing CG coordinates would now be used for both backup edge CG selection and initial edge