Document Migration 3.0 to 4.0

[mmattel]

@micbar
@kobergj
@wkloucek

[mmattel]

There is at least a comment in the docs release notes PR already, but I need details to document in the admin docs.

[kobergj]

Space index migration is done same way as xattrs -> messagepack migration. We can offer a save migration path same as last time:

• start storage-users and nats
• wait for "done" log ( NOTE: there will be 3 of those messages when upgrading from 2.0 )
• restart ocis

Remark: space index migration will be much quicker than xattrs migration unless you have thousands of spaces.

@aduffeck please correct me if I am wrong in any way

[wkloucek]

• start storage-users and nats

What speaks against running ocis server? In the oCIS Helm Chart we currently do not support running only some services.

[kobergj]

What speaks against running ocis server?

Clients will connect to the server while the migration is running. This brings a couple of problems:

• logs will be cluttered with error messages, it will be hard to find the one (info level) "done" log.
• during migration most files/spaces will be inaccessible for the users
• in cases where the migration takes very long the system looks broken to the user and the admin

You can also just block outside access to the cluster during migration. This will have the same effect.

[wkloucek]

You can also just block outside access to the cluster during migration. This will have the same effect.

Ok, this would be easier to achieve.

How can I check via automation that the migration is finished? Because I would need some way to check when I'm again allowed to put traffic onto that instance.

• in cases where the migration takes very long the system looks broken to the user and the admin

How long is it expected to run for a midsized (???) installation (1000 spaces with 1000 files/folders each) on a reasonable fast NFS?

[wkloucek]

How can I check via automation that the migration is finished? Because I would need some way to check when I'm again allowed to put traffic onto that instance.

Another way would be the storageusers and other services not returning "I'm ready" on their readiness endpoints (

ocis/ocis-pkg/service/debug/service.go

Lines 29 to 30 in de550b7

	mux.HandleFunc("/healthz", dopts.Health)
	mux.HandleFunc("/readyz", dopts.Ready)

), as proposed in owncloud/ocis-charts#339 (comment)

[kobergj]

How can I check via automation that the migration is finished? Because I would need some way to check when I'm again allowed to put traffic onto that instance.

Unfortunately the only way of finding this out is to look for a log saying "done" as described. We urgently need a better solution for migrating. As we saw already on small scale deployments: auto-migration is bad.

How long is it expected to run for a midsized (???) installation (1000 spaces with 1000 files/folders each) on a reasonable fast NFS?

I really can't tell. The only information I have is from this ticket: #6518: A "couple hundred GB" of "small files" took "over 5 hours"

[kobergj]

Another way would be the storageusers and other services not returning "I'm ready" on their readiness endpoints

Yes this a solution but wouldn't work for the single binary. I would prefer a solution that can be used independent from the deployment.

[mmattel]

As all has been completed in docs and after sync with @kobergj - closing.