Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions _topic_map.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2179,6 +2179,8 @@ Topics:
# File: ossm-security
# - Name: Traffic management
# File: ossm-traffic-manage
# - Name: Custom resources
# File: ossm-custom-resources
# - Name: Extensions
# File: ossm-extensions
# - Name: Using the 3scale Istio adapter
Expand Down Expand Up @@ -2206,6 +2208,8 @@ Topics:
File: ossm-security
- Name: Traffic management
File: ossm-traffic-manage
- Name: Custom resources
File: ossm-custom-resources
- Name: Using the 3scale Istio adapter
File: threescale-adapter
---
Expand Down
2 changes: 1 addition & 1 deletion modules/ossm-auto-route.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ Then, the following OpenShift Routes are created automatically. You can check th

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in 2.0 IOR spec path has been changed and it is enabled true by default in 2.0 SMCP.
"Enabling Automatic Route Creation" looks out of date. @jwendell may help a review of this section.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in 2.0 IOR spec path has been changed and it is enabled true by default in 2.0 SMCP.
"Enabling Automatic Route Creation" looks out of date. @jwendell may help a review of this section.

Where's that section? I can't find it in the deploy preview...

Copy link
Copy Markdown
Contributor Author

@neal-timpe neal-timpe Nov 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[source,terminal]
----
$ oc -n <your-control-plane-namespace> get routes
$ oc -n <control_plane_namespace> get routes
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commenting here about this IOR section. I think it could be rewritten as:

Disabling Automatic Route Creation

By default, Red Hat OpenShift Service Mesh control plane automatically synchronizes the Gateway resources with OpenShift routes.

If you do not wish this integration between Istio Gateways and OpenShift Routes to happen, you can disable it by setting the ServiceMeshControlPlane field gateways.openshiftRoute.enabled to false. For example, see the following resource snippet:

spec:
  gateways:
    openshiftRoute:
      enabled: false

@neal-timpe Note that "Enabling" became "Disabling", because it comes enabled by default in 2.0, in contrast with 1.1, that had to be manually enabled. Also, this sentence: "If the Gateway contains a TLS section, the OpenShift Route will be configured to support TLS." I think could be moved up to the section above (Automatic Route creation)

----

.Expected output
Expand Down
291 changes: 245 additions & 46 deletions modules/ossm-cr-example.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -18,63 +18,262 @@ This example `ServiceMeshControlPlane` definition contains all of the supported

[IMPORTANT]
====
The 3scale Istio Adapter is deployed and configured in the custom resource file. It also requires a working 3scale account (link:https://www.3scale.net/signup/[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.4/html/infrastructure/onpremises-installation[On-Premises]).
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
The 3scale Istio Adapter is deployed and configured in the custom resource file. It also requires an active 3scale account (link:https://www.3scale.net/signup/[SaaS] or link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.4/html/infrastructure/onpremises-installation[On-Premises]).
====

.Example istio-installation.yaml
.Example `ServiceMeshControlPlane` resource

[source,yaml]
----
apiVersion: maistra.io/v1
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: basic-install
name: basic
spec:
proxy:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 128Mi
tracing:
type: Jaeger
gateways:
ingress: # istio-ingressgateway
service:
type: ClusterIP
ports:
- name: status-port
port: 15020
- name: http2
port: 80
targetPort: 8080
- name: https
port: 443
targetPort: 8443
meshExpansionPorts: []
egress: # istio-egressgateway
service:
type: ClusterIP
ports:
- name: status-port
port: 15020
- name: http2
port: 80
targetPort: 8080
- name: https
port: 443
targetPort: 8443
additionalIngress:
some-other-ingress-gateway: {}
additionalEgress:
some-other-egress-gateway: {}

istio:
global:
proxy:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 128Mi

gateways:
istio-egressgateway:
autoscaleEnabled: false
istio-ingressgateway:
autoscaleEnabled: false
ior_enabled: false

mixer:
policy:
autoscaleEnabled: false

telemetry:
autoscaleEnabled: false
resources:
requests:
cpu: 100m
memory: 1G
limits:
cpu: 500m
memory: 4G

pilot:
autoscaleEnabled: false
traceSampling: 100

kiali:
enabled: true
policy:
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
type: Istiod # or Mixer
mixer: # only applies if policy.type: Mixer
enableChecks: false
failOpen: false

telemetry:
type: Istiod # or Mixer
mixer: # only applies if telemetry.type: Mixer, for v1 telemetry
sessionAffinity: false
batching:
maxEntries: 100
maxTime: 1s
adapters:
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
kubernetesenv: true
stdio:
enabled: true
outputAsJSON: true
addons:
grafana:
enabled: true

tracing:
install:
config:
env: {}
envSecrets: {}
persistence:
storageClassName: ""
accessMode: ReadWriteOnce
capacity: 5Gi
service:
ingress:
contextPath: /grafana
tls:
termination: reencrypt
kiali:
name: kiali
enabled: true
jaeger:
template: all-in-one
install: # install kiali CR if not present
dashboard:
viewOnly: false
enableGrafana: true
enableTracing: true
enablePrometheus: true
service:
ingress:
contextPath: /kiali
jaeger:
name: jaeger
install:
storage:
type: Memory # or Elasticsearch
memory:
maxTraces: 100000
elasticsearch:
nodeCount: 3
storage: {}
redundancyPolicy: SingleRedundancy
indexCleaner: {}
ingress: {} # jaeger ingress configuration
runtime:
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
components:
pilot:
deployment:
replicas: 2
pod:
affinity: {}
container:
resources:
limits: {}
requirements: {}
grafana:
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
deployment: {}
pod: {}
kiali:
deployment: {}
pod: {}
----

The following table lists the parameters for the `ServiceMeshControlPlane` resource.
Comment thread
neal-timpe marked this conversation as resolved.
Outdated

.`ServiceMeshControlPlane` resource parameters
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we've presented this information in tables before, I'm not sure this particular organization works very well. I think I'd have a really hard time turning these tables into a properly formatted and nested YAML file. I think it might be better to do something like we did in V1, where we had a table for each chunk of the configuration file (gateways, policy, telemetry, runtime, addons). (if we don't have time before the release, then we should definitely do it ASAP after the release.)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how effective these tables are as configuration documentation. I think that they're recreations of api docs that are better hosted elsewhere.

I think we should be writing configuration docs in the user guide rather than these tables. I think we should talk to @heathjoy about where we add that content.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whatever you decide is fine by me. I've attempted a start at a table-ized version of api docs here, although they are very rough and need to be regenerated and merged into istio-operator.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@neal-timpe let's look at this right after the release. If we have a lot of tables that make up config topics, then I agree that they should be in a guide and xref'd as appropriate.

|===
|Name |Description |Type

|`apiVersion`
|APIVersion defines the versioned schema of this representation of an object. Servers convert recognized schemas to the latest internal value, and may reject unrecognized values. The value for {ProductName} version 2.0 is `maistra.io/v2`.
|The value for {ProductName} version 2.0 is maistra.io/v2.

|kind
|Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated.
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
|CamelCase string

|metadata
|Metadata about this `ServiceMeshControlPlane` instance You can provide a name for your control plane installation to keep track of your work, for example, `basic-install`, or `production`.
|string

|spec
|The specification of the desired state of this `ServiceMeshControlPlane`. This includes the configuration options for all components that comprise the control plane.
|For more information, see Table 2.

|status
|The current status of this `ServiceMeshControlPlane` and the components that comprise the control plane.
|For more information, see Table 3.
|===

The following table lists the specifications for the `ServiceMeshControlPlane` resource. These parameters configure {ProductName} for your microservices and apps.

.`ServiceMeshControlPlane` resource spec
|===
|Name |Description |Configurable parameters
Comment thread
neal-timpe marked this conversation as resolved.
Outdated

|addons
|Addons is used to configure additional features beyond core control plane components, such as visualization, or metric storage.
|`3scale`, `grafana`, `jaeger`, `kiali`, and `prometheus`.

|cluster
|Cluster is the general configuration of the cluster (cluster name, network name, multi-cluster, mesh expansion, etc.)
|`meshExpansion`, `multiCluster`, `name`, and `network`

|gateways
|Gateways configures ingress and egress gateways for the mesh.
|`enabled`, `additionalEgress`, `additionalIngress`, `egress`, `ingress`, and `openshiftRoute`

|general
|General represents general control plane configuration that does not fit anywhere else.
|`logging` and `validationMessages`

|policy
|Policy configures policy checking for the control plane. If `spec.policy.enabled` is set to `true`, policy checking is enabled.
|`mixer` `remote`, or `type`. `type` can be set to `Istiod`, `Mixer` or `None`.

|profiles
|Profiles selects the `ServiceMeshControlPlane` profile to use for default values.
|`default`

|proxy
|Proxy configures the default behavior for sidecars.
|`accessLogging`, `adminPort`, `concurrency`, and `envoyMetricsService`

|runtime
|Runtime configuration for the control plane components.
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
|`components`, and `defaults`

|security
|Security configures aspects of security for the control plane.
|`certificateAuthority`, `controlPlane`, `identity`, `dataPlane` and `trust`

|techPreview
|TechPreview is used to enable early access to features that are technology previews.
|N/A

|telemetry
|If spec.mixer.telemetry.enabled is set to true, telemetry is enabled.
|`mixer`, `remote`, and `type`. `type` can be set to `Istiod`, `Mixer` or `None`.

|tracing
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
|Tracing enables distributed tracing for the mesh.
|`sampling`, `type`. `type` can be set to `Jaeger` or `None`.

|version
|Version specifies what Maistra version of the control plane to install. When creating a `ServiceMeshControlPlane` with an empty version, the admission webhook sets the version to the current version. New `ServiceMeshControlPlanes` with an empty version are set to v2.0. Existing `ServiceMeshControlPlanes` with an empty version keep their setting.
|string
|===

ControlPlaneStatus represents the current state of your service mesh.

.`ServiceMeshControlPlane` resource `ControlPlaneStatus`
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
|===
|Name |Description |Type

|annotations
|Annotations is an unstructured key value map used to store additional, usually redundant status information, such as the number of components deployed by the `ServiceMeshControlPlane`. These statuses are used by the command line tool, `oc`, which does not yet allow counting objects in JSONPath expressions.
|Not configurable

|conditions
Represents the latest available observations of the object’s current state. `Reconciled` indicates whether the operator has finished reconciling the actual state of deployed components with the the configuration in the `ServiceMeshControlPlane` resource. `Installed` indicates whether the control plane has been installed. `Ready` indicates whether all control plane components are ready
|string

|components
|Shows the status of each deployed control plane component.
|string

|appliedSpec
|The resulting specification of the configuration options after all profiles have been applied.
|`ControlPlaneSpec`

|appliedValues
|The resulting values.yaml used to generate the charts.
|`ControlPlaneSpec`

|chartVersion
|The version of the charts that were last processed for this resource.
|string

|observedGeneration
Comment thread
neal-timpe marked this conversation as resolved.
Outdated
|The generation observed by the controller during the most recent reconciliation. The information in the status pertains to this particular generation of the object. The `status.conditions` are not up-to-date if the `status.observedGeneration` field doesn't match `metadata.generation`.
|integer

|operatorVersion
|The version of the operator that last processed this resource.
|string

|readiness
|The readiness status of components & owned resources
|string
|===
Loading