Migrate from version 1.X to 2.X

[cpanato]

Hello

We are using the minio operator 1.x version but I saw there are an upgrade release and the API move to v1.
However, I did not find any documentation on how to upgrade existing deployments and how to upgrade from v1 to v2.

There is any guide?
thanks!

[kerneltime]

@cpanato can you tell us more about your environment? You can reach out to us https://subnet.min.io/support if you need help with production deployments.

[nitisht]

However, I did not find any documentation on how to upgrade existing deployments and how to upgrade from v1 to v2.

We are working on another major change and will be releasing v3.0.0 soon, if you want to migrate, it is probably better to wait for operator release v3.0.0

[cpanato]

@kerneltime @nitisht thanks for the reply, usually when you deprecate the v1beta1 and move to v1 you have some time that you serve both in order to have the users to migrate to the new. My understanding to achieve that is we write some webhook conversion to make that transition and not just delete and recreate the API version including the crd.

We use minIO operator together with our operator but, now I don't know how we can upgrade to use the current one without breaking existing deployments.

Do you have any migration doc that we can transition from v1beta1 to v1? or this is not possible and we need to break and reinstall

thanks again!

[dvaldivia]

@cpanato do you have any multi zone deployments?

[cpanato]

@dvaldivia we dont have in our side, but cannot say if other users have it.

[harshavardhana]

@kerneltime @nitisht thanks for the reply, usually when you deprecate the v1beta1 and move to v1 you have some time that you serve both in order to have the users to migrate to the new. My understanding to achieve that is we write some webhook conversion to make that transition and not just delete and recreate the API version including the crd.

We use minIO operator together with our operator but, now I don't know how we can upgrade to use the current one without breaking existing deployments.

Do you have any migration doc that we can transition from v1beta1 to v1? or this is not possible and we need to break and reinstall

thanks again!

@cpanato what is the intention of upgrade here? is there anything specific you are looking to upgrade to?

[dvaldivia]

@cpanato for single zone deployments there may be an easy path to upgrade as long as the PVCs attached to the statefulset are not destroyed, however there may be a problem where you need to spread the tenants across multiple namespaces.

Are you running multiple MinIO instances in the same namespace?

[cpanato]

@harshavardhana @dvaldivia No, each MinIO instance has his own namespace.

For me the major issue is the v1beta1 does not exist anymore and how do I smoothly transition to v1 without deleting the existing deployment. Also, the CRD changed, do we need to keep both during the transition?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[andrej-urvantsev]

Also would like to migrate from 1.x version to the latest. Is it even possible without re-creating MinIO cluster?

[fabriciozubelli]

Also would like to migrate versions, but couldn't find any relevant information/documentation as well. Would anyone be able to point out the way to do that?

[blachniet]

I re-created the MinIO cluster in order to upgrade to the latest version of the operator.

When creating the new cluster, you must create new PersistentVolumes, since the old ones are already claimed. As long as the new Persistent Volumes have the same data in them as the old Persistent Volumes (e.g. manually by copying from the old to the new), you should be able to keep all the data. That said, you should always backup first 😄 .

For my scenario, we were using local persistent volumes with a persistentVolumeReclaimPolicy: Retain. When I created my new MinIO cluster, I simply deleted my old local persistent volumes (which were claimed by the old MinIO cluster) and then re-created them. Since the reclaim policy is Retain (and we aren't using the Local Persistence Volume Static Provisioner anyways) deleting the persistent volume leaves the underlying data intact.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-pv-0
spec:
  # ...
  persistentVolumeReclaimPolicy: Retain
  storageClassName: minio-local-storage
  local:
    path: /mnt/disks/ssd1

[nitisht]

#423 adds a way to migrate. Closing this now