CNAME: CNAME records can be used to alias one name to another. CNAME stands for Canonical Name.
All the Data in the DB & response should be CSP agnostic.
Presently the data stored in DB & API response is having the CSP provider details. Presently we are storing the absolute URL of the the assest in the DB & the same is sending in the response.
Impact areas:
Plugins loading in editors & packing as part of ECAR.
Generation of pre-signed URL used by EditorsECAR files will be having absolute paths (Need discussion on how to solve)
Data stored in the DB’s
streamingUrl
downloadUrl
variants
----------------
previewUrl
appIcon
posterImage
artifactUrl
toc_url
thumbnail
assetMap
Example:
Data for CSP migration:
https://docs.google.com/spreadsheets/d/13DaXCx8uToOwinlAPxvTat8NELxiPgG4KXATcKaJm_c/edit?usp=sharing
CSP flow diagram to migrate the data:
https://drive.google.com/file/d/1HzUob6a9_TrVWhcoo1nWoKPVN0PKzpmQ/view?usp=share_link
Solution:
Don’t store the absolute paths in the DB’s. Always store the path with CNAME as prefix.
example:
Configure the service with CNAME value as shown below
cname:[
{
"type": "blob",
"cname": "https://store.diksha.gov.in",
"default": "https://ntpproductionall.blob.core.windows.net/ ",
"properties": [
"downloadUrl",
"artifactUrl",
"streamingUrl",
"posterImage",
"previewUrl"
]
},
{
"type": "cdn",
"cname": "https://cdn.diksha.gov.in",
"default": "https://cdn-ntpproduction.core.windows.net/ "
}
]
cname: Value to be used to replace
default: Value that has to be replaced with CNAME
properties: Service will be looking for these properties while writing. Any aboslute path sending for these properties will get updaetd with CNAME value
Only while creation(POST API calls), we will be replacing the properties on the request body(CNAME_properties) with CNAME & store in the DB.
The list of CNAME_properties can be configured by any adopters as per their schema properties.
Challenges:
If service has to point to different containers then it will be a challenge.
streamingUrl will required the data migration.