add granular update & delete options to GenericController

[AmitKumarDas]

Problem Statement: A GenericController can create, update or delete any attachments. There are no visible issues if this controller deletes or updates the attachments which were created by this controller. However, one would like to exercise finer control via GenericController while trying to delete or update resources that were not created by the same controller. GenericController already supports UpdateAny & DeleteAny options which is common to all the attachments specified in its spec. However, this is too liberal and can create problems if not programmed properly. There are also other scenarios where one would like to only Update certain kind of attachments whereas Delete certain kind of attachments and at the same time do nothing for certain kind of attachments. All these scenarios calls for finer granularity while exercising these Update/Delete/Noop operations.

Possible Solution: One of the possible approaches can be to expose new tunables in GenericController's HookResponse API. This new tunables can be set by controller developers who write the reconcile logic. In other words, this will be controlled from inside the hook code & not by Metac. This also allows us to avoid setting generic tunables like UpdateAny & DeleteAny in the spec.

sample hook response

response: 
  allowedDeletes:
    # gvk: namespace/name
    # __ i.e. double underscore is the separator used
    # / i.e. forward slash can be used instead once verified if it works for all cases
    openebs.io__v1alpha1__Deployment: default/cool
  allowedUpdates:
    openebs.io__v1alpha1__Pod: default/nginx

type GenericControllerWebHookResponse struct {
 // existing fields...

 // new fields
  allowedUpdates map[string]string
  allowedDeletes map[string]string
}

[AmitKumarDas]

It will be better to use specific ObjectMeta & ObjectType fields to determine what is eligible to be updated &/ deleted. Logic can make use of kind, apiVersion, name & namespace to find the resources that are eligible for update or delete or both. For example a sample response will be as follows:

response: 
  allowedDeletes:
  - kind:
    apiVersion:
    name:
    namespace:
  allowedUpdates:
  - kind:
    apiVersion:
    name:
    namespace:

In addition, a few scenarios might want to expose those resources that are eligible to be sync-ed (i.e. both update, delete). OTH the response structure can look like the following:

response: 
  allowedSyncs:
  - kind:
    apiVersion:
    name:
    namespace:
  allowedDeletes:
  - kind:
    apiVersion:
    name:
    namespace:
  allowedUpdates:
  - kind:
    apiVersion:
    name:
    namespace:

[AmitKumarDas]

We might want to consider following cases:

• updates can be granted based on specified kind & apiVersion
• deletes can be granted based on specified kind, apiVersion, name & namespace
• avoid using syncs are a api option (refer previous comment)

response: 
  allowedDeletes:
  - kind:
    apiVersion:
    name:
    namespace:
  allowedUpdates:
  - kind:
    apiVersion:

NOTE: One might consider using wildcards i.e. '*' as well. For example:

response: 
  allowedDeletes:
  - kind:
    apiVersion:
    name:
    namespace:
  allowedUpdates:
  - kind: *
    apiVersion: *
    namespace: * # * is the default value for namespace
    name: * # * is the default value for name

[AmitKumarDas]

I have started working on this!

Generic controller's hook response will have two new fields:

• ExplicitUpdates of type []*unstructured.Unstructured
• ExplicitDeletes of type []*unstructured.Unstructured

[AmitKumarDas]

closing this as part of #141