This repository has been archived by the owner on Oct 22, 2024. It is now read-only.
operator should delete obsolete sub-resources if any #595
Assignees
Labels
0.8
needs to be fixed in 0.8.x
Comments
Closed
pohly
added
0.8
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 1, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we solve this by annotating the Deployment CR with the list of object types & names, and the version of the operator that reconciled. On operator upgrade/degrade we check if any pre-deployed objects are still valid. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 2, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 3, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 4, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 5, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 5, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 5, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 5, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 8, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 8, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 9, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 10, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 11, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
avalluri
added a commit
to avalluri/pmem-CSI
that referenced
this issue
Sep 11, 2020
Different operator releases might result in obsolete sub-resources that were created for a deployment. Operator shall detect these obsolete objects if any and delete them in the reconcile loop. There is no direct API to detect all the objects owned by an object. So, we keep hard-coded list of all types that operator could deal and we use this list to query and fetch the pre-deployed objects and check if that object is owned by the deployment. For tesing this pperator creates an additional dummy ConfigMap object for pre-known test version. The test ensures that the ConfigMap gets deleted upon change in the operator version. FIXES intel#595
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
On upgrade, the operator must be able to find and delete obsolete sub-resources if any for a deployment.
The text was updated successfully, but these errors were encountered: