S3 backend: [storage]readonly is documented but ignored #1568

New Issue

tahoe-lafs · 2011-10-22T03:37:33Z

davidsarah commented

2011-10-22 03:37:33 +00:00

This option makes sense for the S3 backend and should be implemented (preferably for both mutable and immutable shares, i.e. avoiding bug #390). Or maybe not.

tahoe-lafs added the

labels 2011-10-22 03:37:33 +00:00

tahoe-lafs added this to the 1.11.0 milestone 2011-10-22 03:37:33 +00:00

davidsarah commented

2011-10-22 03:40:11 +00:00

Hmm, but another way to implement it is to make the access permissions on the bucket read-only. So maybe we should document that this is a disk-backend-only option, or maybe (as suggested in /tahoe-lafs/trac-2024-07-25/issues/5452#comment:-1) we should remove it entirely.

Hmm, but another way to implement it is to make the access permissions on the bucket read-only. So maybe we should document that this is a disk-backend-only option, or maybe (as suggested in [/tahoe-lafs/trac-2024-07-25/issues/5452](/tahoe-lafs/trac-2024-07-25/issues/5452)#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/1568#issuecomment--1)) we should remove it entirely.

davidsarah commented

2011-10-22 03:51:49 +00:00

If we remove this option for S3 backends, we still need to test that when one server is attached to a read-only S3 bucket but other servers are accepting shares, then new shares go to those other servers.

davidsarah commented

2011-10-22 04:59:52 +00:00

Attachment s3-remove-readonly.darcs.patch (53290 bytes) added

S3 backend: remove support for storagereadonly option. refs #999, #1568

**Attachment** s3-remove-readonly.darcs.patch (53290 bytes) added S3 backend: remove support for storagereadonly option. refs #999, #1568

s3-remove-readonly.darcs.patch

52 KiB

zooko was assigned by tahoe-lafs

2011-10-22 05:02:47 +00:00

tahoe-lafs changed title from ~~S3 backend ignores [storage]readonly~~ to S3 backend: [storage]readonly is documented but ignored

2011-10-22 05:02:47 +00:00

zooko commented

2011-10-24 06:34:42 +00:00

I reviewed s3-remove-readonly.darcs.patch and give it +1. I would feel better if the two TODO's mentioned in that patch (one just in line of context) were ticketed and had TODO'ed unit tests...

For what it is worth, I increasingly think read-only storage should be deprecated for all backends, and people will have to learn how to use their operating system if they want readonliness of storage. When we invented the read-only storage option, I think partly we were thinking of users who could read our docs but didn't want to learn how to use their operating system to set policy. Nowadays I'm less interested in the idea of such users being server operators.

Also, the fact that we've never really finished implementing read-only storage (to include mutables), so that there are weird failure modes that could hit people who rely on it is evidence that we should not spend our precious engineering time on things that the operating system could do for us and do better.

I reviewed [s3-remove-readonly.darcs.patch](/tahoe-lafs/trac-2024-07-25/attachments/000078ac-722a-7e9c-6dcb-9b58be1d30ab) and give it +1. I *would* feel better if the two `TODO`'s mentioned in that patch (one just in line of context) were ticketed and had `TODO`'ed unit tests... For what it is worth, I increasingly think read-only storage should be deprecated for all backends, and people will have to learn how to use their operating system if they want readonliness of storage. When we invented the read-only storage option, I think partly we were thinking of users who could read our docs but didn't want to learn how to use their operating system to set policy. Nowadays I'm less interested in the idea of such users being server operators. Also, the fact that we've never really finished implementing read-only storage (to include mutables), so that there are weird failure modes that could hit people who rely on it is evidence that we should not spend our precious engineering time on things that the operating system could do for us and do better.

gdt commented

2011-10-24 11:49:35 +00:00

I don't really follow this. It seems reasonable for a server operator to decide to not accept new shares, and for this to be separate than whether the server process is able to write the filesystem where the shares are kept. For example, it might be reasonable to allow lease renewal, or for other metadata to be updated. It might be that not accepting shares should be similar to zero space available, so increasing the size of a mutable share also might not be allowed. And, if the purpose really is decommissioning, then presumably the mechanism used for repair should somehow signal that the share is present but should be migrated, so that a deep-check --repair can put those shares on some other server.

There's a difference between people that don't understand enough to sysadmin a server, and the server having uniform configuation for server-level behavior. When tahoe is ported to ITS, it should still be possible to tell it to stop taking shares.

I don't really follow this. It seems reasonable for a server operator to decide to not accept new shares, and for this to be separate than whether the server process is able to write the filesystem where the shares are kept. For example, it might be reasonable to allow lease renewal, or for other metadata to be updated. It might be that not accepting shares should be similar to zero space available, so increasing the size of a mutable share also might not be allowed. And, if the purpose really is decommissioning, then presumably the mechanism used for repair should somehow signal that the share is present but should be migrated, so that a deep-check --repair can put those shares on some other server. There's a difference between people that don't understand enough to sysadmin a server, and the server having uniform configuation for server-level behavior. When tahoe is ported to [ITS](http://en.wikipedia.org/wiki/Incompatible_Timesharing_System), it should still be possible to tell it to stop taking shares.

zooko commented

2011-10-24 15:27:34 +00:00

Excellent points, gdt. And I was thinking of you as an example "minimalist unixy sysadmin" when I wrote what I wrote. Would you please post your comments over at #390? I'll post mine first so you can reply to mine...

davidsarah commented

2011-10-24 18:29:23 +00:00

Replying to gdt:

For example, it might be reasonable to allow lease renewal, or for other metadata to be updated.

However, that doesn't affect the S3 backend, which doesn't store lease data in shares. We plan to store it in a leasedb that is local to the server.

It might be that not accepting shares should be similar to zero space available, so increasing the size of a mutable share also might not be allowed.

Making the storage read-only has the effect of preventing any changes to shares.

If we want a "don't use any more space" option, that's different to "read-only". I think "read-only", if supported, should mean precisely that (including preventing deletion of shares or reductions in size of mutable shares).

Note that removing storagereadonly for the S3 backend now doesn't mean that we won't support it in future. Currently the option doesn't work at all for the S3 backend, and we would have to spend effort implementing it that would delay (even if not by much) finishing the backend.

And, if the purpose really is decommissioning, then presumably the mechanism used for repair should somehow signal that the share is present but should be migrated, so that a deep-check --repair can put those shares on some other server.

True, but I think that should be a separate option.

There's a difference between people that don't understand enough to sysadmin a server, and the server having uniform configuation for server-level behavior. When tahoe is ported to ITS, it should still be possible to tell it to stop taking shares.

Thanks for volunteering to do the ITS port! ;-)

Replying to [gdt](/tahoe-lafs/trac-2024-07-25/issues/1568#issuecomment-86109): > For example, it might be reasonable to allow lease renewal, or for other metadata to be updated. However, that doesn't affect the S3 backend, which doesn't store lease data in shares. We plan to store it in a leasedb that is local to the server. > It might be that not accepting shares should be similar to zero space available, so increasing the size of a mutable share also might not be allowed. Making the storage read-only has the effect of preventing any changes to shares. If we want a "don't use any more space" option, that's different to "read-only". I think "read-only", if supported, should mean precisely that (including preventing deletion of shares or reductions in size of mutable shares). Note that removing `storagereadonly` for the S3 backend now doesn't mean that we won't support it in future. Currently the option doesn't work at all for the S3 backend, and we would have to spend effort implementing it that would delay (even if not by much) finishing the backend. > And, if the purpose really is decommissioning, then presumably the mechanism used for repair should somehow signal that the share is present but should be migrated, so that a deep-check --repair can put those shares on some other server. True, but I think that should be a separate option. > There's a difference between people that don't understand enough to sysadmin a server, and the server having uniform configuation for server-level behavior. When tahoe is ported to [ITS](http://en.wikipedia.org/wiki/Incompatible_Timesharing_System), it should still be possible to tell it to stop taking shares. Thanks for volunteering to do the ITS port! ;-)

david-sarah@jacaranda.org commented

2011-10-24 18:31:36 +00:00

In [5524/ticket999-S3-backend]:

S3 backend: remove support for [storage]readonly option. refs #999, #1568

In [5524/ticket999-S3-backend]: ``` S3 backend: remove support for [storage]readonly option. refs #999, #1568 ```

gdt commented

2011-10-24 19:02:23 +00:00

Replying to [davidsarah]comment:8:

That's all fine. I was just reacting to what I perceived to be "why bother having options if someone can just chmod some directory". Deciding that read-only as a concept doesn't make sense seems entirely reasonable.

I think it does make sense for a server operator to be able to configure the server not to take new shares, and also for it to be in some sort of advertised-as-going-away mode. But as you say that may be a different concept.

As for ITS, it's been a long time - but a convenient way to point out that network server semantics and local filesystem semantics need not match.

Replying to [davidsarah]comment:8: That's all fine. I was just reacting to what I perceived to be "why bother having options if someone can just chmod some directory". Deciding that read-only as a concept doesn't make sense seems entirely reasonable. I think it does make sense for a server operator to be able to configure the server not to take new shares, and also for it to be in some sort of advertised-as-going-away mode. But as you say that may be a different concept. As for ITS, it's been a long time - but a convenient way to point out that network server semantics and local filesystem semantics need not match.

davidsarah commented

2011-11-29 22:53:19 +00:00

This is fixed on the branch, and when the branch is recorded for trunk it will be as if storagereadonly never existed for the S3 backend.

This is fixed on the branch, and when the branch is recorded for trunk it will be as if `storagereadonly` never existed for the S3 backend.

tahoe-lafs added the

fixed

label 2011-11-29 22:53:19 +00:00

davidsarah closed this issue

2011-11-29 22:53:19 +00:00

tahoe-lafs removed this from the 1.11.0 milestone 2012-03-31 23:59:05 +00:00

Sign in to join this conversation.