NO-JIRA: docs/FAQ: link KCS for mixed composefs state#1939
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@jbtrystram: This pull request explicitly references no jira issue. DetailsIn 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
added
the
approved
|
/lgtm |
angelcerveraroldan
left a comment
angelcerveraroldan
left a comment
There was a problem hiding this comment.
Other than the small nits above, LGTM
In some cases, after a cluster upgrades, some nodes may have composefs enabled but not others. This is due to a MCO bug [1] that triggers an extra deployment then removes it, which end up with the composefs EROFS image being created on those. This result in the node using composefs sooner than the other nodes. This inconsistency is not causing any problem and will solve itself at the next upgrade, but we have had the questions asked enough times to link this KCS here. [1] https://redhat.atlassian.net/browse/OCPBUGS-59958
jbtrystram
force-pushed
the
faq-composefs-add-kcs
branch
from
47fa7ef to
d548b24
Compare
angelcerveraroldan
left a comment
angelcerveraroldan
left a comment
There was a problem hiding this comment.
/lgtm, thanks!
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: angelcerveraroldan, c4rt0, cverna, jbtrystram The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Rolv-Apneseth
left a comment
Rolv-Apneseth
left a comment
There was a problem hiding this comment.
Just minor wording suggestion, but LGTM
| With composefs, `/` is backed by `/sysroot` and any disk monitoring tools should be updated to watch the `/sysroot` mountpoint, which is the real physical root. | ||
|
|
||
| In some cases, after an upgrade, some nodes may have composefs enabled but not all of them. This is a known state caused by a bug in the MCO that | ||
| cause some nodes to apply the update twice, causing them to get composefs enabled sooner than other. This has no impact and will resolve itself |
There was a problem hiding this comment.
| cause some nodes to apply the update twice, causing them to get composefs enabled sooner than other. This has no impact and will resolve itself | |
| causes some nodes to apply the update twice, causing them to get composefs enabled sooner than others. This has no impact and will resolve itself |
|
@jbtrystram: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
Hum, https://access.redhat.com/solutions/7139041 is marked as internal only. Maybe we should open it up. |
openshift-ci
Bot
added
the
do-not-merge/hold
openshift-ci-robot
added
the
verified
|
@travier: This PR has been marked as verified by DetailsIn 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 openshift-eng/jira-lifecycle-plugin repository. |
7 participants
In some cases, after a cluster upgrades, some nodes may have composefs enabled but not others. This is due to a MCO bug [1] that triggers an extra deployment then removes it, which end up with the composefs EROFS image being created on those.
This result in the node using composefs sooner than the other nodes. This inconsistency is not causing any problem and will solve itself at the next upgrade, but we have had the questions asked enough times to link this KCS here.
[1] https://redhat.atlassian.net/browse/OCPBUGS-59958