Meta Owner Flow

Let’s define some terminologies:

• Meta Owner

  It is a resource that is being pointed by the Meta owner reference object

• Meta Ownee

  It is a resource that points to another resource by the metadata.owner_references field.

• Meta Owner Deployment

  Deployment to which Meta Owner belongs.

• Meta Ownee Deployment

  Deployment to which Meta Ownee belongs.

• Meta Owner Reference

  It is an item in metadata.owner_references array field.

We have three known cases where action is required:

1. API Server calls Save method of Store, and saved resource has non-empty meta owner refs. API Server must schedule asynchronous tasks to be executed after the resource is saved locally (We trust meta owner refs are valid). Then asynchronously:

   • deployment owning meta ownee resource must periodically check if meta owners exist in target Deployments.
   • if after some timeout it is detected that the meta owner reference is not valid, then it must be removed. If it empties all meta owner refs array, the whole resource must be deleted.
   • if meta owner reference is valid, Deployment with meta ownee resource is responsible for sending notifications to Deployment with meta owner resource. If the reference is valid, it will be successful.
   • if Deployment with meta ownee detects that version of meta owner reference is too old (during validation), then it must upgrade it.

   Note that in this flow Deployment with meta ownee resource is an actor initializing action, it must ask Deployments with meta owners if its meta ownee is valid.

2. API Server calls the Save method of Store, and the saved resource is known to be the meta-owner of some resources in various Deployments. In this case, it is meta owner Deployment responsible for actions, asynchronously:

   • it must iterate over Deployments where meta ownees may be, and verify if they are affected by the latest save. If not, no need for any action. Why however meta ownees may be affected? Let’s list the points below…
   • sometimes, meta owner reference has a flag telling that the meta owner must have a schema reference to the meta ownee resource. If this is the case, and we see that the meta owner lost the reference to a meta ownee, the meta ownee must be forced to clean up its meta owner refs. It may trigger its deletion.
   • If there was a Meta Owner Deployment version upgrade, this Deployment is responsible for updating all Meta ownee resources. Meta ownees must have meta owner references using the current version of the target Deployment.

3. API Server calls Delete method of Store, and deleted resource is KNOWN to be meta-owner of some resources in various Deployments. Deployment owning deleted meta owner resource is responsible for the following asynchronous actions:

   • It must iterate over Deployments where meta ownees may exist, and list them.
   • For each meta ownee, Meta Owner Deployment must notify about deletion, Meta Ownee Deployment.
   • API Server of meta ownee deployment is responsible for removing meta owner reference from the array list. It may trigger the deletion of meta ownee if there are no more meta owner references.

Note that all flows are pretty much asynchronous, but still ensure consistency of meta owner references. In some cases though it is meta owner Deployment reaching out, sometimes the other way around. It depends on which resource was updated last.