gainsley
commented
2 months ago Thanks Lev. I'm going through the corresponding edge-cloud-director changes, looks like I may need to make a few tweaks to this code in support, but just going to be some minor changes.
This removes the CloudletKey from the AppInstKey and ClusterInstKey, allowing for a separation of concerns from the AppInst/ClusterInst keys (owned by the developer) and the Cloudlet keys (owned by the operator). The main reason for this is for the upcoming Zones feature, which intends to hide Cloudlets from developers by putting Cloudlets in a new Zone object. This also moves us closer to the CAMARA APIs which use a single string ID as the unique identifier for objects. So now the AppInstKey and ClusterInstKeys only have a single unique string "name" (although scoped to the organization for multi-tenancy).
Due to the changes of the keys:
The bulk of the changes here are mechanical, moving the CloudletKey from the AppInstKey to the AppInst body, and from the ClusterInstKey to the ClusterInst body. No functional change, as the same information is preserved.
Some functional changes were required in places where we were passing just the instance key around, but now the key doesn't have the cloudletKey information, and these places didn't have easy access to the full instance body that now contains the cloudletKey info.
The remaining functional changes are to deal with the change in scope of the AppInst/ClusterInst key. Previously the key only needed to be unique within the scope of a single cloudlet (CloudletKey). Now, the instance key must be unique within the region. This requires renaming instances that have conflicts during upgrade. It also then requires being able to reference the old name for existing data (files, infra object names, etc) that need to remain accessible using the old name.