Open DillonN opened 1 year ago
I think I stumbled on this one too
Defining a PersistentVolumeClaim... then when pod dies it deletes my PVC, after some time it generates new one, with a clean one from beginning... empty, and the cycle continues.
This is only issue with yaml way (Kustomization). I haven't seen troubles with helm charts.
For now I manually generate PVCs as a workaround, other would be to write helm charts.
I believe we are running into this issue as well.
We are creating a resource (type: AWSCluster
) using Cluster API. Cluster API creates several resources, one of which is a network load balancer. Once the NLB is created, the object is patched with the .spec.controlPlaneEndpoint
object.
It's at this point that Fleet attempts to overwrite the resource with the default (zero) values. Before finding this issue I tried what @DillonN did, which was to use the diff
configuration like the one included below.
Unfortunately this does not prevent Fleet from trying to overwrite the resource and my bundle stays in the ErrApplied
state.
diff:
comparePatches:
- kind: AWSCluster
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
namespace: <namespace>
name: <resource name>
operations:
- {"op":"remove", "path":"/spec/controlPlaneEndpoint"}
jsonPointers:
- "/spec/controlPlaneEndpoint"
Facing same issue. Do we have any fix or workaround for this. Tried comparePatches to ignore /spec path but its not doing anything.
Is there an existing issue for this?
Current Behavior
After the volume is dynamically provisioned, any future changes to the bundle will throw result in an error because fleet keeps trying to replace the generated
volumeName
with empty string:I tried following this guide and added this diff entry (under bundle
spec
) but it did nothing:Expected Behavior
Fleet supports dynamically provisioned volumes, maybe with a diff workaround. But I've searched everywhere and can't find any mention of anyone using fleet with dynamic volumes. Even the
force
option does not help.Steps To Reproduce
Environment
Logs
No response
Anything else?
The only workaround I've found is to copy the generated PV name into the bundle git, but I don't think that's a sufficient long-term solution.