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.
