MAISTRA-817 document networking configuration details #92
Conversation
| @@ -12,6 +12,22 @@ ways. The modifications to Maistra are sometimes necessary to resolve issues, | |||
| provide additional features, or to handle differences when deploying on | |||
| OpenShift or OKD. | |||
|
|
|||
| === Multitenancy | |||
|
|
|||
There was a problem hiding this comment.
Would it make sense to put the networking differences in the installation details instead? I see this comparison section as a high level 30 second sales pitch of why someone should use Maistra instead of Istio, not necessarily something someone will read through when trying to understand how to use the product.
There was a problem hiding this comment.
This is not really marketing speak as it is though ;) Let's have the sales pitch somewhere else (index?) and keep this to document technical differences
There was a problem hiding this comment.
Agree :) Need to reword index. I'm thinking something similar to:
Maistra is an opinionated version of Istio that builds on top of the functionality you expect from OpenShift. Among the changes that Maistra includes are:
- multi-tenant control plane to support multiple cluster users
- Removal of cluster scoped resources
- No required special privileges
- Addition of templates in order to support reusable configurations
That said, that I've found, we're the only project with a "differences" page, and I think this page should eventually go away.
|
|
||
| NOTE: This also restricts ingress to only member projects. If ingress from non-member projects is required, you need to create a `NetworkPolicy` to allow that traffic through. | ||
|
|
||
| * `Multitenant`: Maistra joins the `NetNamespace` for each member project to the `NetNamespace` of the control plane project (for example, invoking `oc adm pod-network join-projects --to control-plane-project member-project`). If you remove a member from the mesh, its `NetNamespace` is isolated from the control plane (for example, invoking `oc adm pod-network isolate-projects member-project`). |
There was a problem hiding this comment.
I think this should now be <control-plane-project> and <member-project>, right? Not entirely sure, as this is not really a copy-paste example
There was a problem hiding this comment.
In an example, it's fine to subsitute an actual namespace. But in documentation this should be <control-plane-project>. In this case, this is documentation so should be <control-plane-project>
| Markup in command syntax | Description | Substitute value in Example block |
|---|---|---|
<project> |
Name of project | myproject |
<app> |
Name of an application | myapp |
| @@ -12,6 +12,22 @@ ways. The modifications to Maistra are sometimes necessary to resolve issues, | |||
| provide additional features, or to handle differences when deploying on | |||
| OpenShift or OKD. | |||
|
|
|||
| === Multitenancy | |||
|
|
|||
| The main difference between a multi-tenant installation and a cluster-wide installation is the scope of privileges used by the control plane deployments, for example, Galley and Pilot. The components no longer use cluster-scoped Role Based Access Control (RBAC) `ClusterRoleBinding`, but rely on project-scoped RBAC. | |||
There was a problem hiding this comment.
I think this should either be:
The components no longer use cluster-scoped Role Based Access Control (RBAC) (ClusterRoleBinding)
or
The components no longer use the cluster-scoped Role Based Access Control (RBAC) resource ClusterRoleBinding
Signed-off-by: rcernich <rcernich@redhat.com>
rcernich
force-pushed
the
MAISTRA-817
branch
from
2c550e2
to
356f81f
Compare
Signed-off-by: rcernich rcernich@redhat.com