Allow updating of resources managed by operator

[VaishnaviHire]

This commit adds a custom plugin that allows the operator to determine if an
updated resource needs to be overwritten by reconcilation. An object is not
overwritten only when it has opendatahub.io/configurable label in addition to opendatahub.io/modified
label added by the end user.

Jira Issue: https://issues.redhat.com/browse/ODH-375

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: VaishnaviHire
To complete the pull request process, please assign tmckayus after the PR has been reviewed.
You can assign the PR to them by writing /assign @tmckayus in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[VaishnaviHire]

The operator now supports both - adding custom plugins through KfDef or adding plugins directly to the operator as default plugins. The custom plugin implemented in this PR is being added as a default plugin. However, if a user wants to add a plugin through KfDef, an example KfDef and config is provided in the kustomize-fns/v1alpha1/applyresources/example folder.

There are two cases that need to be tested for the applyResources plugin:

1. Allowing users to modify a resource
2. Add new fields from updated manifests to a modified resource with needs-update label

Testing Steps:

1. Apply ConfigMap containing plugin config. FiledSpecs in config consists of resource kind that can be configurable.

oc create -f bundle/manifests/default_plugins_configmap.yaml -n ${OPERATOR_NAMESPACE}

2. Add opendatahub.io/configurable=true label to the resources in manifest repo. To add the label to the resource file update the file with following fields:

metadata:
   labels:
      opendatahub.io/configurable: "true"

3. Deploy operator and add KfDef instance.

4. To modify a resource, first add opendatahub.io/modified label .

• To add the label by OpenShift console, go to the Details page for the resource and click Edit on the list of labels. Add opendatahub.io/modified=true label to the list.
• To add label in the yaml format, update the yaml with -

metadata:
   labels:
      opendatahub.io/modified: "true"

Once the label is added, modify the field data in the resource. This will cause operator reconciliation, but the resource would not be overwritten.

6. To add new fields of an updated resource, add opendatahub.io/needs-update label in manifests. To add the label to the resource file update the file with following fields:

metadata:
   labels:
      opendatahub.io/needs-update: "true"

Once the label is added, re-deploy the manifests. The operator checks the difference between the local and cluster resource and add fields that are not included in the cluster resource. This is when we want to update the resource during upgrades.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: VaishnaviHire
To complete the pull request process, please assign tmckayus after the PR has been reviewed.
You can assign the PR to them by writing /assign @tmckayus in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[LaVLaS]

With your update to Dockerfile , do we still need to maintain Dockerfile.ubi?

[VaishnaviHire]

With your update to Dockerfile , do we still need to maintain Dockerfile.ubi?

@LaVLaS I am not entirely sure about this.

[nakfour]

@VaishnaviHire I am trying to understand the use case for this. Is the user supposed to manually add these tags to the operator pod?
opendatahub.io/configurable
opendatahub.io/modified

After they install the operator?

[nakfour]

I am not clear what this specifically does. Are we suggesting we change the Kfdef format to allow for globals:?

[VaishnaviHire]

This is required to add custom transformer. In our case its resourceApply. The file has the config required for the plugin

[VaishnaviHire]

#126 (comment)

The labels are added to the objects that are being changed and not the operator pod.

The user is only supposed to add modified label before modifying any object. This lets us know that the update was intentional.

configurable and force-update labels are added as part of manifests.

[crobby]

@VaishnaviHire I'm thinking about the upgrade process where the incoming update has a manifest that contains "force-update". That part makes good sense to me. It would work as expected. But for the next update, would we need to remove the "force-update" label from the manifests? I guess I'm wondering if we need some sort of "force update only once" sort of functionality. Seems like it might be tricky to implement and I might just be overthinking it. Admittedly, I'm not entirely sure that I've thought it through, but maybe you or someone else has and can set me straight.

[VaishnaviHire]

@VaishnaviHire I'm thinking about the upgrade process where the incoming update has a manifest that contains "force-update". That part makes good sense to me. It would work as expected. But for the next update, would we need to remove the "force-update" label from the manifests? I guess I'm wondering if we need some sort of "force update only once" sort of functionality. Seems like it might be tricky to implement and I might just be overthinking it. Admittedly, I'm not entirely sure that I've thought it through, but maybe you or someone else has and can set me straight.

@crobby I will update the comment on PR. We have updated the design details here - #123 (comment)
So essentially we will have a label called opendatahub.io/needs-update that is added to a resource. On adding this label, the operator will just check for new fields and add them to the user-modified resource. Let me know if this looks good.

[crobby]

@VaishnaviHire I'm thinking about the upgrade process where the incoming update has a manifest that contains "force-update". That part makes good sense to me. It would work as expected. But for the next update, would we need to remove the "force-update" label from the manifests? I guess I'm wondering if we need some sort of "force update only once" sort of functionality. Seems like it might be tricky to implement and I might just be overthinking it. Admittedly, I'm not entirely sure that I've thought it through, but maybe you or someone else has and can set me straight.

@crobby I will update the comment on PR. We have updated the design details here - #123 (comment)
So essentially we will have a label called opendatahub.io/needs-update that is added to a resource. On adding this label, the operator will just check for new fields and add them to the user-modified resource. Let me know if this looks good.

Thanks. I will take a look at the updated design.

[nakfour]

@VaishnaviHire we do need an update to documentation telling the user how to use this feature

[VaishnaviHire]

@VaishnaviHire we do need an update to documentation telling the user how to use this feature

Yes. I will create a doc in docs/update_resources.md.

[nakfour]

/hold need to discuss the kfdef transformer entry in the kfdef

[vpavlin]

@nakfour When/How do you want to discuss the KFdef extension?

I am fine with this in general, did not test it though

[VaishnaviHire]

@nakfour When/How do you want to discuss the KFdef extension?

I am fine with this in general, did not test it though

@vpavlin We discussed this in Thursday's meeting. It was decided that since we need the applyresource custom plugin as a required plugin, the entry for it should be removed from the kfdef.

Next steps would be to add this as a default plugin for the ODH operator. Let me know if that works for you.

[VaishnaviHire]

Updated the PR to include ConfigMap for adding default plugins. Testing instructions are updated here

[crobby]

/test all

[VaishnaviHire]

/retest

[crobby]

Is everyone happy with the changes here? @vpavlin @nakfour

[HumairAK]

Any ETA on this? We (Operate-First) are also interested in this, our usecase here. Would also appreciate suggestions for workarounds if they exist.

[openshift-ci]

@VaishnaviHire: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[VaishnaviHire]

Any ETA on this? We (Operate-First) are also interested in this, our usecase here. Would also appreciate suggestions for workarounds if they exist.

This is slated to be in the release after v1.1.1 . A possible workaround to update any resources is to not deploy them through KfDef instance. You would need to deploy them separately as yaml files. The reason being KfDef adds annotation to the resources that the kfdef-controller watches for any changes.