storage uuids are not randomized with init

[butonic]

Currently every deployment uses tha same uuid for the users storage ... that is a non starter for a federated deployment.

We have to initialize the Storageid for the users storage (which in fact currently also is our project storage ... so it is already misused, but that is a separate issue) so that it is possible to determine the storageprovider and distinguish an which instance a space is located ...

ocis/services/gateway/pkg/revaconfig/config.go

Line 130 in da1c18a

"providerid": "1284d238-aa92-42ce-bdc4-0b0000009157",

needs to be made configurabe and set to a random uuid with init

Breaking Change

All WebDAV urls will change

The providerID is the first part of the ID string in the url. It will change from the existing hardcoded uuid (1284d238-aa92-42ce-bdc4-0b0000009157) to a new random uuid.

- "webDavUrl": "https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51"
+ "webDavUrl": "https://localhost:9200/dav/spaces/bc631809-54a9-4b1e-9d6e-d9bdf5088eab$4c510ada-c86b-4815-8820-42cdf82c3d51"

Consequences for Clients

• Web: Can handle it
• iOS: Can handle it
• Android: not known
• Desktop: All sync connections need to be recreated

Alternative Solution

• Fallback to the existing mount ID
• This is not a good approach IMO, we really risk to have a lot of storage providers out there with the same ID
• Later migrations will be even more painful

[micbar]

@michaelstingl @TheOneRing This would become a problem for all existing sync connections for the desktop because all WebDAV Urls will change.

[micbar]

@TheOneRing I updated the top post

[michaelstingl]

@micbar could you post the full information of a Space before and after this change from the Graph API?

[wkloucek]

All references to a fileid will be broken after a storage uuid change. This affects:

• private shares
• public shares
• bookmarks (Web)
• thumbnails cache

[wkloucek]

My proposal would be:

• Don't change the hardcoded UUID for now
• Introduce support for multiple storage providers in oCIS. Because then we need also support the move of spaces from one to another storage.
• Then we have a migration path "for free" because we can move all spaces from the "well-known / non unique uuid" storage to a new random uuid storage, that we later can use for federation.

This proposal assumes that we will do multi-storage oCIS instances before we will do federated oCIS instances.

[micbar]

@wkloucek what is the gain of value?

If we do it now, only a few people need to recreate the desktop sync.

If we do nothing now, we would have thousands of storage providers out there which all have the same provider id. This will explode and cause a lot of painful migrations.

[wkloucek]

If we do it now, only a few people need to recreate the desktop sync.

At least I have no numbers. So I don't know how many installations are out there already.
But introducing a that huge breaking change between a rc.1 and rc.2 sounds odd.

If we do nothing now, we would have thousands of storage providers out there which all have the same provider id. This will explode and cause a lot of painful migrations.

If we find a way to use a random UUID only for new storages, we would have "only a few people" that need a migration later on. And the migration is needed when these instances will be using federation.

[butonic]

The problem I see with the hardcoded UUID for the storageprovider is that we will get collisions of storage provider ids that exist in multiple ocis deployments. hmmm ... clients will have to deal with that anyway because there might be malicious instances that could reuse the storageid of a resoucre to try and confuse clients to send them data ...

the current user storage uuid was handcrafted by me to contain the port number at the end ... to make debugging easier ... but the idea was always to initialize with a unique identifier.

while cern is using human readable names I am strongly recommending uuids because we will run into merge scenarios. And for those provider id collisions ... suck big time. Maybe I overthought this. But I have been ther and I don't want to start rolling out ocis deployments with the same fallback uuid everywhere.

I would change the uuid now.