Rename provider

[briantopping]

Hello!

@stoyanr pointed me to this provider and I believe that it is usable as is on Ceph as an etcd backup provider. Path-style S3 is the key differentiator that I have found while using Ceph S3, that's enabled here.

Does it make sense that this provider would be renamed and remove references to OCS so that it is easier to recognize for those who follow?

I will follow up to this issue once I get it deployed.

[stoyanr]

@briantopping Indeed, this makes sense if you could confirm that it works with any Ceph outside of OpenShift. Back when I tested it, the only test environment I had access was OpenShift. Right now I don't have access to any test environment or capacity to work on it.

If your tests on a non-OpenShift Ceph are successful, it would be great if you could contribute a PR renaming (from openshift to e.g. ceph) in this repo. Once it's merged, I will then take care to move it to an appropriate repo (e.g. gardener-extension-provider-ceph).

[briantopping]

Well then we exclude openshift, right? :)

Does it make sense to just call it S3-storage? I initially thought to include the word "generic" in there, but why preclude the introduction of specific deployment targets as a strategy configuration selector? Then we don't have to clone the repo when things change.

[stoyanr]

Does it make sense to just call it S3-storage?

No. I also had the idea to implement a "generic" S3 storage provider. But when testing on OpenShift and comparing with Amazon S3 I realized this is not a good idea. The OCS S3-compatible API was only partially compatible and the incompatibilities are storage-provider (likely Ceph) specific.

Well then we exclude openshift, right? :)

My idea was that you test on a non-OpenShift Ceph and the tests are successful without the need of any changes to the current implementation, then we could rename it to ceph and it would still work also on OpenShift. If any code changes are required, then we should discuss this again.

[stoyanr]

@briantopping Do you still plan to work on this, or should it be closed?

[briantopping]

Hi Stoyan, I had to take a break for income reasons but am getting back in to these tickets now. The first tickets I’m looking at is public IP addresses in metallb/metallb#887. I may be working on VMware shortly as well ;). Do you prefer this is closed until I can reopen it?

…

Sent from my iPhone

On Oct 16, 2021, at 08:15, Stoyan Rachev ***@***.***> wrote:  @briantopping Do you still plan to work on this, or should it be closed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[stoyanr]

Do you prefer this is closed until I can reopen it?

No, if you still plan to work on it, let's keep it open.