-
Notifications
You must be signed in to change notification settings - Fork 1.8k
OSSMDOC-40 and OSSMDOC-113 New SMCP and configuration topics #26265
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
Conversation
The preview will be available shortly at: |
cb01573
to
538e989
Compare
@yxun Can you take a look? Thanks! |
8b8d806
to
275cfef
Compare
732ecad
to
0d369cd
Compare
modules/ossm-cr-example.adoc
Outdated
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.
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.)
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.
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.
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.
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.
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.
@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.
modules/ossm-auto-route.adoc
Outdated
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.
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.
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.
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...
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.
39b4160
to
e454a15
Compare
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.
Did we want to update any legacy 1.x examples using SMCP v1 to SMCP v2?
@neal-timpe I think it needs a rebase. |
bbc347e
to
760c9b5
Compare
modules/ossm-auto-route.adoc
Outdated
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.
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)
b8426ab
to
f0328ed
Compare
/cherry-pick enterprise-4.6 |
@JStickler: new pull request created: #27061 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/cherry-pick enterprise-4.7 |
@JStickler: new pull request created: #27062 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR addresses changes in the configuration documentation and SMCP for ossm20.
It will be merged with #26354 for migration, and #26261 for installation.
https://issues.redhat.com/browse/OSSMDOC-40
https://issues.redhat.com/browse/OSSMDOC-113