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