Remove send_metadata logic related to zero-copy replication

[alesapin]

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Removed experimental send_metadata logic related to experimental zero-copy replication. It wasn't ever used and nobody supports this code. Since there were even no tests related to it, there is a high chance that it's broken long time ago.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[clickhouse-gh]

Workflow [PR], commit [80de4fc]

Summary: ✅

[alexey-milovidov]

Thanks!

The main reason is to fix the architectural problem in the implementation of "root_path" for disks. The right way to do it is to make sure the "root_path" is not exposed in the disk's interface, and the disks with different "chroots" have the same interface.

When people implemented "send_metadata" they messed up with the interface, preventing clean architecture.

[alesapin]

> The main reason is to fix the architectural problem in the implementation of "root_path" for disks
What exactly do you mean? If it's getPath() method, than I agree that it looks weird. However it was introduced together with IDisk interface and used widely across our codebase :(. How is it related to send_metadata?

[alexey-milovidov]

Alexey Milovidov
Feb 20th at 21:43
virtual std::string getCommonKeyPrefix() const = 0;
Missing comments.
It's strange to have this method - the "chroot" should be not exposed from Object Storage.

Kseniia
Feb 20th at 22:39
It’s strange to have this method - the “chroot” should be not exposed from Object Storage.
I agree, I can try to remove it from everywhere.
Its exposure from object storage started because of DiskObjectStorageRemoteMetadataRestoreHelper (I would vote for deleting this code btw, I think it does not make sense to have now that we have plain-rewritable disk).

Alexey Milovidov
Feb 20th at 22:47
Yes, let's do it. We can start with deleting the "metadata restore" feature, then get rid of getCommonKeyPrefix as well.

Alexey Milovidov
Apr 23rd at 13:51
Yes, let’s remove this code and reorganize.
julia.kartseva found a bug related to “getCommonKeyPrefix”

julia.kartseva
This method is used to set the chroot for plain disks' metadata, as the metadata is stored in the object storage.
Also, chroot is exposed in some of our system tables, e.g., system.disks and system.tables: ...

Alexey Milovidov
Apr 24th at 10:24
It’s a matter of code organization, so chroot is encapsulated, and the users of the interfaces use abstracted paths.

Alexey Milovidov
Jun 7th at 01:00
Kseniia, let's finish removing the exposure of chroot from disks and send_metadata feature! Thank you