-
Notifications
You must be signed in to change notification settings - Fork 1.8k
OSDOCS 15776 retry #97806
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
OSDOCS 15776 retry #97806
Conversation
🤖 Mon Aug 25 14:45:31 - Prow CI generated the docs preview: |
|=== | ||
| | ||
|4.19 | ||
|4.19z |
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 might take this out of a table format because we typically do not lump known issues together like this in our docs. What would be most helpful, I think, is to provide more context for these issues and links for users to get more information.
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.
Heard
|4.19z | ||
|
||
|Excess istio-ca-root-cert configmaps | ||
|Y |
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 expect to see more context pulled from the bug, such as:
By default, istiod will create a ConfigMap istio-ca-root-cert in every namespace it watches. This behavior depends on the discoverySelectors
, so that any proxy that might be injected in those namespaces has istiod's CA root certificate. This is needed for the proxies to verify the istiod's certificate when performing the initial connection. No 'normal' sidecar injections are planned. The only injection necessary is Gateway injection based on k8s Gateway API resources. Therefore, avoid the creation of potentially unneeded ConfigMaps in the entire cluster. This issue was fixed for Red Hat OpenShift Service Mesh 3.0.1. However, istiod does not clean up existing ConfigMaps. https://issues.redhat.com/browse/OSSM-9076
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.
Sounds good!
71455af
to
96d0490
Compare
76ffd19
to
7542c81
Compare
fc0d161
to
7af2b84
Compare
/retest |
/retest-required |
7af2b84
to
0f3b969
Compare
0f3b969
to
f9110fb
Compare
@jmanthei: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
@candita please review |
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 think we need to get some more SME details put into each of these line items that explain what actions a user can preform (even if it is wait for updates - see bug).
Many of these potentially define 'expected user behaviors' that likely need to go into the docs directly (but that depends on if/how we plan to fix the bugs - that are connected to them). As such I don't know that they warrant 'release note' (known issues status); as we typically reserve that for 'major' bugs/issues.
|
||
* By default, `istiod` will create a ConfigMap `istio-ca-root-cert` in every namespace it watches, which can create unnecessary ConfigMaps. (link:https://issues.redhat.com/browse/OSSM-9076[OSSM-9076]) | ||
|
||
* When using Gateway API via the Cluster Ingress Operator (CIO), any Istio specific resources (e.g. VirtualService) are not allowed or supported. (link:https://issues.redhat.com/browse/OSSM-9154[OSSM-9154]) |
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.
Not allowed? As In I shouldn't create these; or the server will reject them (which is it)?
When you say supported; does this mean it breaks something or are we just not testing/validating this (thus its not supported)?
In short the verbage here leave a lot to the reader to interpret; and we want to where possible remove ambiguity; is there a way we can clean this up to be more explicit about what we mean here?
@@ -2809,6 +2809,40 @@ To save the `vmcore` file, use the `crashkernel` setting to reserve 1024 MB of m | |||
|
|||
* NFS volumes exported from VMware vSAN Files cannot be mounted by clusters running {product-title} 4.19 due to RHEL-83435. To avoid this issue, ensure that you are running VMware ESXi and vSAN at the latest patch versions of 8.0 P05, or later. (link:https://issues.redhat.com/browse/OCPBUGS-55978[OCPBUGS-55978]) | |||
|
|||
Known Gateway API issues | |||
|
|||
* By default, `istiod` will create a ConfigMap `istio-ca-root-cert` in every namespace it watches, which can create unnecessary ConfigMaps. (link:https://issues.redhat.com/browse/OSSM-9076[OSSM-9076]) |
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.
What is the workaround? Do we have one (or is this something that people just have to deal with)?
If your 'affected' by this what action should you be taking (watch the bug for updates)?
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.
@sferich888 Most of these are open OSSM or NE bugs that we know about but haven't had time to fix. No workarounds, and very little other information.
|
||
* When using Gateway API via the Cluster Ingress Operator (CIO), any Istio specific resources (e.g. VirtualService) are not allowed or supported. (link:https://issues.redhat.com/browse/OSSM-9154[OSSM-9154]) | ||
|
||
* Istio will copy all labels and annotations from your Gateway objects to the child resources it creates. (link:https://issues.redhat.com/browse/OSSM-8989[OSSM-8989]) |
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.
What problem does this create? Why is a release note needed for this? Should we have a KCS for this instead?
The same applies for the next ~7 line items.
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.
@sferich888 we are basically trying to tell people - we know these are issues so please don't report duplicate issues. We're trying to get ahead of bug reports, in other words. If this is not the right approach, please let me know.
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.
Do the majority of issues in SM come from customer direct filed bug reports? If not; I think it might be better to speak with CEE about why so many bug reports are being filed (that the team is having to close as duplicates).
What is the duplicate bug count (and/or closure rate); compared to the overall backlog of issues the team is managing? cc: @CFields651 (as you might be needed to help look into this).
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.
@sferich888 I was more concerned with the unnecessary effort that the support person would need to go through to finally get to the point where they open a bug, and then we find that it is for an issue we already know about. Or a customer, who, for example, makes grand plans to enable Gateway API on BareMetal without realizing it won't work.
I think the most important items can be summarized and added to existing 4.19 docs instead of release notes. No doubt they will be more visible there anyway.
@jmanthei I spoke to my team leads/manager, and I will try to come up with something like a "Things you need to know before enabling Gateway API" section. For now, you can close this PR. My apologies for the false start and thanks for the effort.
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.
@candita I really appreciate the heads up.
|
||
* Gateway API has no OpenShift Console command line integration. (link:https://issues.redhat.com/browse/NE-1102[NE-1102]) | ||
|
||
* Gateway API has no configuration of access logs or other Istio options. (link:https://issues.redhat.com/browse/NE-1926[NE-1926]) |
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.
Is there some corrective action a user can take?
@candita is this something someone on your team can provide inputs into? |
/assign |
Version(s): 4.19
Issue: https://issues.redhat.com/browse/OSDOCS-15776
Link to docs preview:
QE review:
Additional information: