docs/design: s3gw-ui backend design document

[jecluis]

With this patch we are introducing a design document ADR on the proposed s3gw-ui backend.

Feedback welcome.

Signed-off-by: Joao Eduardo Luis <joao@suse.com>

[jhmarina]

Closes https://github.com/aquarist-labs/s3gw/issues/400

[jhmarina]

lgtm but I'll leave the review to @votdev or @l-mb 🙂

[giubacc]

I know we already discussed this and for sure the solution proposed here works; however I have the sensation that all this architecture could be a bit too much overcomplicated for the problem we have.
I'd like all the clients could be logically equivalent; without special handling for the browser client.
IMO, regardless of what the client is, it should speak to s3gw using the natural protocol, that is S3.
What if an user wants to install and use his personal web client that works with other S3 backends?
Could he be able to use it with s3gw?
I'd like the user could be able to configure CORS for his buckets depending on what he wants those to be.
Are we, with this solution, hiding something that should be under the control of the user?
What if, instead, we modify the radosgw to default assign the allow-all policy for CORS to newly created buckets?
The user then, via the UI or other, could choose to keep that or change that.

[votdev]

What if an user wants to install and use his personal web client that works with other S3 backends?

This will work (in addition to our REST based layer) because the S3 endpoints still exist and can be used by whatever client. This excludes RGW Admin Ops calls (user and bucket management) which are not S3, therefore they are reserved for the s3gw ui.

I'd like the user could be able to configure CORS for his buckets depending on what he wants those to be.
Are we, with this solution, hiding something that should be under the control of the user?
What if, instead, we modify the radosgw to default assign the allow-all policy for CORS to newly created buckets?
The user then, via the UI or other, could choose to keep that or change that.

This solution counteracts the sense of an administration interface that should have access to everything.

BTW, as it seems now we have to add an UI into Longhorn as well, a REST API makes more sense than before.

[jecluis]

What Volker said, and I would like to expand on a few things.

I'd like all the clients could be logically equivalent; without special handling for the browser client. IMO, regardless of what the client is, it should speak to s3gw using the natural protocol, that is S3.

And they can. They can speak to s3gw all they want. If they are a browser client, then they will have to find their own way to talk to s3gw, and address CORS themselves.

What if an user wants to install and use his personal web client that works with other S3 backends? Could he be able to use it with s3gw?

They can, as long as they solve the CORS issue themselves. If that ever happens, and if they then believe s3gw should address the CORS issue for them, then they can open an issue and we can discuss it then.

I'd like the user could be able to configure CORS for his buckets depending on what he wants those to be. Are we, with this solution, hiding something that should be under the control of the user?

They can. They can configure CORS on their buckets. We're not removing that ability.

What if, instead, we modify the radosgw to default assign the allow-all policy for CORS to newly created buckets? The user then, via the UI or other, could choose to keep that or change that.

That's a no, because that doesn't solve the CORS issue for the s3gw-ui, which is what this design document addresses. Not only we would be making an assumption on what the administrator wants as a default CORS policy (we don't know if an "allow all" is what the administrator wants), we would be essentially saying that any bucket could share its resources with any website (assuming the client had the right privileges) by default. That is not okay. If the CORS policy is to be "allow all", it should be set explicitly.

On top of it, relying on user-specific CORS policies for administration and management of s3gw via s3gw-ui would break access to those buckets we intend to administrate and manage. That is not acceptable for s3gw-ui.

[giubacc]

ok, with the given rationale, I don't see motivations against the proposed design.

[jecluis]

@irq0 pushed with additional information on the behavior of s3gw-ui. Let me know if you need more specifics. I didn't want to go into actually mapping operations though, because those should be implemented on a case-by-case need, instead of having to define which operations map to what.

[jecluis]

@jhmarina doesn't seem like anyone has particular strong feelings against merging this. Mind approving so this can be merged?