Key/Value Fields Not Updating Properly
bradkwadsworth-mw opened this issue · 1 comments
What problem are you facing?
When removing key/value fields, the desired manifest is not updated.
object resource:
apiVersion: kubernetes.crossplane.io/v1alpha2
kind: Object
metadata:
annotations:
crossplane.io/external-create-pending: "2024-05-14T03:06:56Z"
crossplane.io/external-create-succeeded: "2024-05-14T03:06:56Z"
crossplane.io/external-name: sample-namespace
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"kubernetes.crossplane.io/v1alpha2","kind":"Object","metadata":{"annotations":{"uptest.upbound.io/timeout":"60"},"name":"sample-namespace"},"spec":{"forProvider":{"manifest":{"apiVersion":"v1","kind":"Namespace","metadata":{"labels":{"example":"true"}}}},"providerConfigRef":{"name":"kubernetes-provider"}}}
uptest.upbound.io/timeout: "60"
creationTimestamp: "2024-05-14T03:06:56Z"
finalizers:
- finalizer.managedresource.crossplane.io
generation: 3
name: sample-namespace
resourceVersion: "30070"
uid: 745a73ee-9447-47f7-b3c8-0105fcc2e3b4
spec:
deletionPolicy: Delete
forProvider:
manifest:
apiVersion: v1
kind: Namespace
metadata:
labels:
example: "true"
foo: bar
managementPolicies:
- '*'
providerConfigRef:
name: kubernetes-provider
readiness:
policy: SuccessfulCreate
watch: false
created resource:
apiVersion: v1
kind: Namespace
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","kind":"Namespace","metadata":{"labels":{"example":"true","foo":"bar"}}}'
creationTimestamp: "2024-05-14T03:06:56Z"
labels:
example: "true"
foo: bar
kubernetes.io/metadata.name: sample-namespace
name: sample-namespace
resourceVersion: "31736"
uid: 7174f6ef-af55-4ae2-bc81-0f6fef75384b
spec:
finalizers:
- kubernetes
object resource (removed label):
apiVersion: kubernetes.crossplane.io/v1alpha2
kind: Object
metadata:
annotations:
crossplane.io/external-create-pending: "2024-05-14T03:06:56Z"
crossplane.io/external-create-succeeded: "2024-05-14T03:06:56Z"
crossplane.io/external-name: sample-namespace
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"kubernetes.crossplane.io/v1alpha2","kind":"Object","metadata":{"annotations":{"uptest.upbound.io/timeout":"60"},"name":"sample-namespace"},"spec":{"forProvider":{"manifest":{"apiVersion":"v1","kind":"Namespace","metadata":{"labels":{"example":"true"}}}},"providerConfigRef":{"name":"kubernetes-provider"}}}
uptest.upbound.io/timeout: "60"
creationTimestamp: "2024-05-14T03:06:56Z"
finalizers:
- finalizer.managedresource.crossplane.io
generation: 3
name: sample-namespace
resourceVersion: "30070"
uid: 745a73ee-9447-47f7-b3c8-0105fcc2e3b4
spec:
deletionPolicy: Delete
forProvider:
manifest:
apiVersion: v1
kind: Namespace
metadata:
labels:
example: "true"
#foo: bar # disabled label
managementPolicies:
- '*'
providerConfigRef:
name: kubernetes-provider
readiness:
policy: SuccessfulCreate
watch: false
created resource (label still exists):
apiVersion: v1
kind: Namespace
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","kind":"Namespace","metadata":{"labels":{"example":"true"}}}'
creationTimestamp: "2024-05-14T03:06:56Z"
labels:
example: "true"
foo: bar
kubernetes.io/metadata.name: sample-namespace
name: sample-namespace
resourceVersion: "32026"
uid: 7174f6ef-af55-4ae2-bc81-0f6fef75384b
spec:
finalizers:
- kubernetes
How could Crossplane help solve your problem?
When removing key/value fields such as labels, the field should also be removed in the created resource.
We encountered this issue too. Why is it an enhancement and not a bug? If you manually create the resource without the provider, it actually removes/modifies the fields.
If a field is object type* - or array I assume - and you modify the key/value pair, it keeps adding new fields without removing the old ones. I haven't tested this with array, that's why it's an assumption.
If something is optional, that also won't get removed.
*E.g. of what I mean:
...
exampleKey:
type: object
additionalProperties:
type: string
...
It would be nice if you could fix this issue.
Also, it is pretty similar to this issue - or we can say it's the same: #114