Skip to content

Change default cachekey prefix from base origin url to xmlid #3994

Open
@jhg03a

Description

I'm submitting a ...

  • bug report
  • new feature / enhancement request
  • improvement request (usability, performance, tech debt, etc.)
  • other

Traffic Control components affected ...

  • CDN in a Box
  • Documentation
  • Grove
  • Traffic Control Client
  • Traffic Monitor
  • Traffic Ops
  • Traffic Ops ORT
  • Traffic Portal
  • Traffic Router
  • Traffic Stats
  • Traffic Vault
  • unknown

Current behavior:

The default ATS cachekey constructed by TO is to use the Base Origin URL delivery service field as a prefix, unless manual intervention has been undertaken through the raw remap line and DS profiles. While those URL mostly stay the same, they do sometimes change. Operations teams must remember when changing origins to force the customer to signoff on breaking their cache, or manual cachekey plugin configuration must occur. When MSO is being used, this breakage can occur without changing the actual origin FQDNs.

Expected / new behavior:

I'd like to see us instead of using the Base Origin URL DS field, use the DS XMLID since it's actually a true primary key that ought not ever change. Manual configuration must still be honored for more advanced use cases or legacy conversions of this exact scenario. This prevents accidental cold-caching of changed origins.

Minimal reproduction of the problem with instructions:

Anything else:

Cache key itself probably needs to be a first class citizen as a concept and we may also want to stop doing things behind the scene with it like with qsting and start requiring specific direction at the time of DS creation. This would enable us to provide more tailored solutions up front for things that are possible with manual configuration, but not common to ask such as whitelist/blacklists for query params, sorting of query params, dropping segments of the url path, etc. As TR continues to adopt similar concepts for routing distribution this becomes an additional opportunity to make things more cohesive. Today the average Delivery Service owner has no concept of this, how central it is to what CDNs do, or how doing it wrong affects their CDN efficiency.

Metadata

Assignees

No one assigned

    Labels

    Traffic Opsrelated to Traffic Opscache-configCache config generationconfigurationrelated to configuration - not limited to any one componentimprovementThe functionality exists but it could be improved in some way.medium impactimpacts a significant portion of a CDN, or has the potential to do sotech debtrework due to choosing easy/limited solution

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions