Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create two namespacestore on same target-bucket with different access-mode #1166

Open
Alansyf opened this issue Jul 12, 2023 · 3 comments
Open

Comments

@Alansyf
Copy link

Alansyf commented Jul 12, 2023

Environment info

  • NooBaa Operator Version: 5.13.0
  • Platform: Kubernetes v1.22.3

Actual behavior

  1. noobaa namespacestore create s3-compatible rw-ns-test --access-mode='read-write' --endpoint='https://objectstore-3.eu-de-2.cloud.sap' --secret-name='s3-secret' --signature-version='v4' --target-bucket='lis.devops.coll-1'
    This can be created.

Then I want another namespacestore for readOnly thus

noobaa namespacestore create s3-compatible ro-ns-test --access-mode='read-only' --endpoint='https://objectstore-3.eu-de-2.cloud.sap' --secret-name='s3-secret' --signature-version='v4' --target-bucket='lis.devops.coll-1'

But I am getting

INFO[0000]
INFO[0000] NamespaceStore Wait Ready:
INFO[0000] ⏳ NamespaceStore "ro-ns-test" Phase is "": waiting...
INFO[0003] ⏳ NamespaceStore "ro-ns-test" Phase is "Creating": TemporaryError Target already in use
INFO[0006] ⏳ NamespaceStore "ro-ns-test" Phase is "Creating": TemporaryError Target already in use
INFO[0009] ⏳ NamespaceStore "ro-ns-test" Phase is "Creating": TemporaryError Target already in use
INFO[0012] ⏳ NamespaceStore "ro-ns-test" Phase is "Creating": TemporaryError Target already in use
INFO[0015] ⏳ NamespaceStore "ro-ns-test" Phase is "Creating": TemporaryError Target already in use
i345633 ~  $ noobaa namespacestore list                                                                                                                                                                                                                    
NAME         TYPE            TARGET-BUCKET       PHASE      AGE
ro-ns-test   s3-compatible   lis.devops.coll-1   Creating   51s
rw-ns-test   s3-compatible   lis.devops.coll-1   Ready      1m33s

Why this is forbidden? One namespacestore for writing, the other one for reading, i don't see any potential concurrent issue here.

@nimrod-becker
Copy link
Contributor

Trying to think what is the use case here,
so, on a single NS Bucket, if we create namespacestore1 (NSS1) and set it to both read and write (which is working today) its in fact R/W.

That would mean that I might want to create NSS1 with W/R and NSS2 (pointing to the same bucket) with R only if I want to create 2 NS buckets, set buck1 on NSS1 and buck2 on NSS2. In that case, I achieve the same outcome by setting
buck1: r:NSS1, w:NSS1
buck2: r:NSS1

We don't have an option of not setting a w target for NS buckets, so that would seem the gap here? Am I missing the intent?

@Alansyf
Copy link
Author

Alansyf commented Jul 13, 2023

The gap here is, we don't have way to define access properly.
There are bulk of tickets here related to the same question here.
#1155 #1150 and all the discussions.

Due to compliance, our underlying storage is S3-compatible, we are very hard to take access control on top of this storage level directly.

So we are seeking for a gateway solution.

Our intent is:
Different technical account can setup different privilege to access different buckets.

e.g:
My S3-compatible storage:
Bucket-1
Bucket-2
Bucket-3

tech-user-1 RO Bucket-1 , RO Bucket-2, RO Bucket-3
tech-user-2 RW Bucket-1, RO Bucket-2, RO Bucket-3
tech-user-3 RO Bucket-1, RW Bucket-2, RW Bucket-3
tech-user-4 RW Bucket-1, RW Bucket-2, RW Bucket-3

we are able to achieve before [e03f0ca](commit: e03f0ca ) as state here #1168

Now I dont have anyway to achieve my intend.

@dannyzaken
Copy link
Contributor

I believe this is the source of the error
https://github.com/noobaa/noobaa-core/blob/6a2879fe6142c6df4041bb44188b9502fc61289f/src/server/system_services/pool_server.js#L288-L294

I think we should revisit this restriction. we should at least take the candidate_target.access_mode into account

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants