Effi Ofer

Nice. It's possible to validate that the OTP version passed into the KS helm chart matches the version of the transport-plugin-api?

Update: I managed to reproduce a second time. Here's the manifest works object from imbs: ``` apiVersion: work.open-cluster-management.io/v1 kind: ManifestWork metadata: annotations: transport.kubestellar.io/originOwnerReferenceBindingGeneration: "1" creationTimestamp: "2024-03-10T15:48:09Z" deletionGracePeriodSeconds: 0 deletionTimestamp: "2024-03-10T15:48:10Z"...

I concur with Paolo. Regardless of eventual consistency why does it take so long? I agree that we should test on pure OCM but I dread doing so as it's...

It took me a while to get back to this issue, but I finally did and reproduced the following on pure OCM environment. Steps: Create OCM environment based on instructions...

https://github.com/open-cluster-management-io/ocm/issues/379 opened against ocm.

This is a very interesting issue and a great graph. It would be interesting to see the time spent in each phase (object creation in WDS, binding object creation, manifestwork...

This is how OCM handles upgrades: https://open-cluster-management.io/getting-started/administration/upgrading/ As long as we don't change the API and break backwards compatibility we can potentially do something similar.