As it stands, you can choose a subset of edge and mid caches, which is a big change from where we stand today.
I think it can lay the groundwork for n-tier hierarchies. Right now one of these groups can contain both edges and mids. We could extend the group to have a parent/child relationship with other groups (any group that has children I believe would need to contain only Mids). —Eric > On May 12, 2019, at 8:40 PM, Dave Neuman <neu...@apache.org> wrote: > > This is exciting, thanks Eric. > Any idea how well this fits in with flexible cache groups? > > On Thu, May 9, 2019 at 10:51 Eric Friedrich <efriedr...@synamedia.com> > wrote: > >> GH Issue Link: https://github.com/apache/trafficcontrol/issues/3557 >> >> Background >> ---------- >> Edge caches can currently be assigned to delivery services in three ways: >> - By Server Profile >> - By Cache Group >> - By Individual Cache >> >> The mids of the assigned edges are chosen based only on the parent and >> secondary_parent cachegroup settings. >> >> Use Cases >> ---------------- >> Create a more flexible method of assigning mid/edge caches to delivery >> services. This allows users to solve the following problems: >> - Dedicating a subset of caches to particular content providers/CDN >> services >> - Dedicating a subset of caches to particular content types (i.e. PDL or >> HTTPS content) >> - Specifying exactly which mid-caches are used for a particular delivery >> service. >> >> The existing "assign by profile" is not sufficient because servers can >> only be in a single Profile. This proposal introduces a new Cache >> Assignment Group, of which a server can be in more than one. Also, there is >> no existing way to influence the selection of mid-caches on a DS-by-DS >> basis. >> >> The first two uses cases can be accomplished with individual server >> assignments, but this is cumbersome when you need to match assignments of >> lots of servers across lots of delivery services. Let's have the DB >> relations manage these logical groupings for us instead. >> >> >> Requirements >> ------------ >> 1) Create Cache Assignment Group in Traffic Ops with a name and description >> 2) Allow many to many association of caches to cache assignment groups >> 3) Allow many to many association of cache assignment groups to Delivery >> Services. >> 4) Consider the union of individual cache assignments (in >> deliveryservice_server table) and CAG assignments (in new >> deliveryservice_assignmentgroup table) when creating remap.config and >> CRConfig.json >> >> 5) Mid-Cache Override: If a mid cache is present in a cache assignment >> group, edge caches in that cache assignment group will disregard the parent >> and secondary_parent hierarchy. Instead those edges will use only the mids >> from that cache assignment group. (No secondary parent support yet). If no >> mid is present, edge caches will continue to use parent and >> secondary_parent as today. >> >> >> Proposed API changes >> -------------------- >> >> /api/1.4/cacheassignmentgroups >> Methods: POST, GET (Get all) >> /api/1.4/cacheassignmentgroups/:id >> Methods: PUT, GET, DELETE >> >> Structure: >> FieldTypeMethod Present >> namestringPOST, PUT, GET >> descriptionstringPOST, PUT, GET >> cdnIdintPOST, PUT, GET >> idintGET >> lastUpdated stringGET >> >> >> /api/1.4/cacheassignmentgroupserver >> Methods: GET, POST >> >> Structure: >> FieldTypeDescription >> cagIdintID of assignment group to which servers will be assigned >> replaceboolTrue to overwrite existing assignments, false to only add >> additional >> serversint array Server ids to assigned into the Cache Assignment >> Group >> >> >> /api/1.4/deliveryservicecacheassignmentgroup >> Methods: GET, POST >> >> Structure: >> FieldType Description >> dsIdint ID of delivery service to which cache assignment groups will >> be assigned >> replacebool True to overwrite existing assignments, false to only add >> additional >> cacheassignmentgroups int array CAG IDs to assign into the Delivery >> Service >> >> >> Proposed DB Schema Changes >> ----------------- >> New Table: cacheassignmentgroup >> >> FieldTypeNotes >> idbigintPrimary Key, auto increment >> nametextUnique >> descriptiontext >> cdn_idbigintForeign Key to cdn(id), trigger to pick one as default >> last_updatedtimestampDefault now(), trigger to autoupdate >> >> New Table: cacheassignmentgroup_server >> FieldTypeNotes >> cacheassignmentgroupbigintForeign Key to cacheassignmentgroup(id) >> serverbigintForeign Key to server(id) >> >> PrimaryKey/Unique constraint on {cag, server} >> >> New Table: deliveryservice_cacheassignmentgroup >> FieldTypeNotes >> deliveryservice bigintForeign Key to deliveryservice(id) >> cacheassignmentgroup bigintForeign Key to cacheassignmentgroup(id) >> >> PrimaryKey/Unique constraint on {deliveryservice, cacheassignmentgroup} >> >> >> Limitations >> ----------- >> If multiple delivery services share the same Origin FQDN and are >> assigned to the same caches, ATS requires they share the same set of >> parents. Traffic Ops does not currently enforce this restriction. >> Validation for this will be added. (I don't think we can accomplish it with >> a DB constraint, but if we could that would be awesome. For now, planning >> to do it in API validation). >> >> Notes >> ------ >> I expect this will take at least 4 PRs (TO API/DB changes, Portal, TO ATS >> config Gen, TO CRConfig Gen) with maybe some intermediate steps to do some >> minor refactoring. We have a working implementation in Perl TO, but the >> config generation is pretty messy. As part of this I'll be porting the API >> to Go and trying to create a cleaner, more modular implementation of the >> remap and parent config generation. >> >> We also have a feature coming up after this which will modify the "cache >> unit of assignment". In that next feature, we'll allow assignment of a >> specific IP address to a Delivery Service (or Cache Assignment Group), so >> please keep that in mind as you review the API and schema proposals. >> Specifically, anywhere we assign a server now, will soon change to server >> and/or optionally ip. >> >> >> This message and any attachment are confidential and may be privileged or >> otherwise protected from disclosure. If you are not the intended recipient, >> please notify the sender immediately and delete this message and any >> attachment from your system. Do not copy them or disclose the contents to >> any other person. >>
