-
Notifications
You must be signed in to change notification settings - Fork 612
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
[Proposal] Implement namespacing for networks #3096
Conversation
Note that the current situation has weird UX because of the inconsistency here. |
Just a note that I will wait for feedback on the idea and design before engaging with CI / test fixing. |
Thanks, the design looks good if it can pass the CI. We may want to have something like |
Ok. I'll fix whatever is needed on CI/test to make this ready.
With the current design, unnamespaced networks will show up in all namespaces. But we can talk about the details here when the PR is fully ready and with adequate tests. Will ping here when done. Thanks! |
I think maybe we should make this feature optional or experimental. Users can config it in the global config. I think this is a huge change for user |
That works for me too if you prefer to minimize impact for now. That being said, this change is transparent for the user and in most cases they would not notice it. |
ee1458f
to
b7c821a
Compare
Clarification on how this is working:
Will lookup in:
When the default network is not found and needs to be created, it will be created in the same usual location with NO namespace subfolder. When any other network is being created, it will be created under the namespaced folder instead of the global folder. Finally, when the user is deleting a network, it will first try to find it in the namespaced folder. If it cannot be found there, it will search and possibly delete in the global folder. Here as well, this aligns with the current behavior. The CI is now green - I think this is ready for formal review now (I am re-pushing right now but this is just md / documentation). Note that I am not yet adding specific tests for the new behaviors - I am currently working on cleanup of all network tests, and would like to send a PR for that soon + new network namespace tests built on top of that cleaned test suite if you don't mind. Kindly let me know your thoughts on all this, and if you want it experimental or mainline. |
e910f8a
to
fb297f4
Compare
@AkihiroSuda last push fixed your two comments (tests+doc). Pending CI (green locally). PTAL at your convenience. Thanks! |
Signed-off-by: apostasie <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
|
Hey folks.
From the conversation at #3095 I appreciate that plugins networks cannot be fully "isolated" from one another, and as such that there is no concept of namespacing in the spec.
Nevertheless, not having namespace for networks commands is very surprising for the user - especially since we do not complain at all about the use of the global
--namespace
flag alongside thenetwork
command. Furthermore, I certainly see use cases where it would make a lot of sense as a feature.This (relatively simple) proof of concept does implement "namespace-ing", effectively preventing one namespace from listing or manipulating directly networks of another.
Let me know what you are thinking about this - and if this would be a welcome feature or not.