search

openshift / openshift-sdn

Apache License 2.0
69 stars 63 forks source link

Admin command to manage project network #176

Closed pravisankar closed 9 years ago

pravisankar commented 9 years ago
pravisankar commented 9 years ago

@danwinship @dcbw @marun PTAL

dcbw commented 9 years ago

Instead of "unisolate" could we do "split" or "leave"?

danwinship commented 9 years ago

That's not what unisolate does. Unisolate means "set VNID to 0". (If you want to split two previously-merged projects A and B, the only way to do that in this UI is to create a new project C, join B to C, and then delete C.)

dcbw commented 9 years ago

Yeah, looking at the patches I see there's also an unimplemented "isolate" command. Which is what I was missing.

Still, seems odd that there isn't a corresponding opposite to Join, like Leave or Split... If Isolate will eventually create a new VNID for a project/namespace, and Unisolate moves it back into the admin/VNID0 namespace, would the corresponding Leave/Split instead just be calling Isolate on the currently-joined project?

danwinship commented 9 years ago

what about:

join (change VNID of PROJECTS[1:] to VNID of PROJECTS[0]) oadm pod-network join PROJECTS... split/isolate: (assign a distinct VNID to each project in PROJECTS) oadm pod-network isolate PROJECTS... unisolate: (assign VNID 0 to each project in PROJECTS) oadm pod-network admin PROJECTS...

dcbw commented 9 years ago

what about:

join (change VNID of PROJECTS[1:] to VNID of PROJECTS[0]) oadm pod-network join PROJECTS... split/isolate: (assign a distinct VNID to each project in PROJECTS) oadm pod-network isolate PROJECTS... unisolate: (assign VNID 0 to each project in PROJECTS) oadm pod-network admin PROJECTS...

That looks a bit clearer to me. What do you think @pravisankar ?

pravisankar commented 9 years ago

We had some discussion on this before in the email chain, let me recap: We are creating overlay network for the pods and 'pod-network' was chosen to avoid any confusion with node network. Eventually 'pod-network' command will support many sub commands once we have granular network policy. '-projects' suffix was added to indicate these sub-commands are operated on the projects. I think, join-projects/isolate-projects provides clear semantics. For join projects, --to option is explicitly used to eliminate any confusion on which project to join, first one or the last one and this pattern is used in other openshift cmds. When we have more than 2 projects sharing the pod network, split operation might be confusing. splitting from given project or existing pod network? I think, 'isolate' word is less confusing! For VNID 0 projects: 'unisolate' was chosen to imply 'no isolation' and the help message clears any confusion. 'admin'/'global' are generic, they have other connotations. 'admin network' also needs explanation and this is completely different from the admin we use in ACLs. We need better alternatives if we are not happy with 'unisolate'.

pravisankar commented 9 years ago

Updated, PTAL

danwinship commented 9 years ago

When we have more than 2 projects sharing the pod network, split operation might be confusing. splitting from given project or existing pod network? I think, 'isolate' word is less confusing!

I think in the case where you pass more than one project, it's not obvious whether that means they all become isolated from each other (each gets its own new VNID), or they all become isolated from everyone else (they all get the same new VNID). The example suggests it's the latter, but I would have guessed the former, since having them share the same VNID means "isolate" also does a "join".

(At any rate, that code isn't hooked up yet, so it doesn't matter that much today.)

For VNID 0 projects: 'unisolate' was chosen to imply 'no isolation' and the help message clears any confusion.

I think that violates the ordinary meaning of "isolation" though. If project A is described as being "isolated", and project B as "not isolated", no one would expect that to mean that B has full access to A. Because if B has full access to A, then A isn't really isolated. That's why I was suggesting something like "admin"; then we can say that A really is isolated, it's just that B has superpowers and can bypass the isolation. (Although I guess "admin" has the reverse problem; it implies "I can access everyone else", but doesn't imply "everyone else can access me"...)

Let's get the code in at least. Presumably we can still potentially rename it post-dev-cut

dcbw commented 9 years ago

Agreed, I had no real problems with the code, just the UX.

pravisankar commented 9 years ago

On Mon, Oct 12, 2015 at 9:07 AM, Dan Winship notifications@github.com wrote:

When we have more than 2 projects sharing the pod network, split operation might be confusing. splitting from given project or existing pod network? I think, 'isolate' word is less confusing!

I think in the case where you pass more than one project, it's not obvious whether that means they all become isolated from each other (each gets its own new VNID), or they all become isolated from everyone else (they all get the same new VNID). The example suggests it's the latter, but I would have guessed the former, since having them share the same VNID means "isolate" also does a "join".

(At any rate, that code isn't hooked up yet, so it doesn't matter that much today.)

For VNID 0 projects: 'unisolate' was chosen to imply 'no isolation' and the help message clears any confusion.

I think that violates the ordinary meaning of "isolation" though. If project A is described as being "isolated", and project B as "not isolated", no one would expect that to mean that B has full access to A. Because if B has full access to A, then A isn't really isolated. That's why I was suggesting something like "admin"; then we can say that A really is isolated, it's just that B has superpowers and can bypass the isolation. (Although I guess "admin" has the reverse problem; it implies "I can access everyone else", but doesn't imply "everyone else can access me"...)

Instead of admin, may be we can use 'global' (making the project global within the cluster). Something like 'make-global-projects'?

Let's get the code in at least. Presumably we can still potentially rename it post-dev-cut

— Reply to this email directly or view it on GitHub https://github.com/openshift/openshift-sdn/pull/176#issuecomment-147447697 .

-Ravi