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

[storage]: Front-end Enable / Disable Namespace Proto-Bufs #178

Open
glimchb opened this issue Oct 31, 2022 · 9 comments
Open

[storage]: Front-end Enable / Disable Namespace Proto-Bufs #178

glimchb opened this issue Oct 31, 2022 · 9 comments
Assignees
Labels
Storage APIs or code related to storage area

Comments

@glimchb
Copy link
Member

glimchb commented Oct 31, 2022

@jainvipin I saw you suggested adding this...

@glimchb glimchb added the Storage APIs or code related to storage area label Oct 31, 2022
@benlwalker
Copy link

What's the use case? Specifically, the use case for having an RPC to enable/disable? Certainly namespaces will get enabled/disabled as part of other operations (during updates and such), but I don't see a flow where the client needs to do this.

@glimchb
Copy link
Member Author

glimchb commented Oct 31, 2022

@jainvipin had those APIs maybe he can comment on the use case

@jainvipin
Copy link
Contributor

jainvipin commented Nov 16, 2022

The goal is to associate the namespace to a controller. Perhaps what @benlwalker was mentioning in another thread about attach/detach. The difference between the terms attach/detach vs enable/disable is that if the namespace key id is already specified in the controller object than we can just call it enable or disable not need to specify which namespace to attach vs. detach. ping @chaitanyahuilgol
Ref #177

@glimchb
Copy link
Member Author

glimchb commented Nov 16, 2022

I think if the goal is the same, we need to pick either attach/detach or enable/disable and move on with single pair

@benlwalker
Copy link

Unless we plan to support private namespaces (we shouldn't) then the nsids are global to the subsystem and picked when a namespace is attached there.

But either way I'd still like to see a use case for this.

@jainvipin
Copy link
Contributor

when a namespace is created it is associated with the subsystem/controller, however when a namespace is enabled is when it is exposed to the host. ping @chaitanyahuilgol

@glimchb
Copy link
Member Author

glimchb commented Nov 18, 2022

I personally think that when you associate the namespace with the subsystem/controller, it should automatically be exposed to the host. I don't see the need for enable/disable... just remove it when you don't need it and re-add back when you need it again...

would love to hear explanation why I'm wrong...

@jainvipin
Copy link
Contributor

@glimchb - if you want to pre-provision things and get it all hooked up and make it easy to enable the namespace/volumens enabled on the host, this is very helpful in my experience.

@benlwalker
Copy link

I still don't understand the use case for this. It's a legitimate thing you can do in the spec, but I don't see what the flow is where you'd need this. It's certainly not in pre-provisioning - you can set everything up before creating the controller to achieve the described effect without using this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Storage APIs or code related to storage area
Projects
None yet
Development

No branches or pull requests

3 participants