openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

OSDOCS-3730: Swapping Jira links for BZ links

Browse Source
This commit is contained in:
Kathryn Alexander
2022-08-11 16:09:36 -04:00
parent 04289d3381
commit e9b4296209
8 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
contributing_to_docs/contributing.adoc
View File

@@ -14,7 +14,7 @@ toc::[]
There are a few different ways you can contribute to OpenShift documentation:
* Email the OpenShift Docs team at openshift-docs@redhat.com.
* Create a link:https://github.com/openshift/openshift-docs/issues/new[GitHub], link:https://issues.redhat.com/secure/CreateIssue!default.jspa[Jira], or link:https://bugzilla.redhat.com/enter_bug.cgi?product=OpenShift%20Container%20Platform[Bugzilla] documentation ticket.
* Create a link:https://github.com/openshift/openshift-docs/issues/new[GitHub] or link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Documentation_issue&issuetype=1&components=12367614&priority=10200&versions=12385624[Jira issue] for the most relevant documentation component.
* Submit a pull request (PR). You can create a local clone of your own fork of the link:https://github.com/openshift/openshift-docs[openshift-docs repository], make your changes, and submit a PR. This option is best if you have substantial changes. If you open a PR, be sure that all of its contents are related and apply to the same versions.
*What happens when you submit a PR?*

3
modules/monitoring-default-monitoring-targets.adoc
View File

@@ -25,7 +25,8 @@ In addition to the components of the stack itself, the default monitoring stack
[NOTE]
====
Each {product-title} component is responsible for its monitoring configuration. For problems with the monitoring of an {product-title} component, open a bug in Bugzilla against that component, not against the general monitoring component.
Each {product-title} component is responsible for its monitoring configuration. For problems with the monitoring of an {product-title} component, open a
link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Monitoring_issue&issuetype=1&priority=10200&versions=12385624[Jira issue] against that component, not against the general monitoring component.
====
Other {product-title} framework components might be exposing metrics as well. For details, see their respective documentation.

2
modules/rosa-getting-support.adoc
View File

@@ -19,4 +19,4 @@ If you experience difficulty with a procedure described in this documentation, v
You can also get support from link:https://aws.amazon.com/premiumsupport/[AWS Support] as long as you have a valid AWS support contract.
If you have a suggestion for improving this documentation or have found an error, submit a link:https://bugzilla.redhat.com/index.cgi[Bugzilla] report against the OpenShift Container Platform product for the Documentation component. Be sure to provide specific details, such as the section name and {product-title} version.
If you have a suggestion for improving this documentation or have found an error, submit a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Documentation_issue&issuetype=1&components=12367614&priority=10200&versions=12385624[Jira issue] for the most relevant documentation component. Be sure to provide specific details, such as the section name and {product-title} version.

2
modules/router-performance-optimizations.adoc
View File

@@ -34,7 +34,7 @@ You can update the `timeoutSeconds` value on the `livenessProbe`, `readinessProb
[IMPORTANT]
====
The timeout configuration option is an advanced tuning technique that can be used to work around issues. However, these issues should eventually be diagnosed and possibly a support case or Bugzilla report opened for any issues that causes probes to time out.
The timeout configuration option is an advanced tuning technique that can be used to work around issues. However, these issues should eventually be diagnosed and possibly a support case or https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Jira issue] opened for any issues that causes probes to time out.
====
The following example demonstrates how you can directly patch the default router deployment to set a 5-second timeout for the liveness and readiness probes:

3
modules/support.adoc
View File

@@ -22,6 +22,5 @@ To identify issues with your cluster, you can use Insights in {cluster-manager-u
// TODO: verify that these settings apply for Service Mesh and OpenShift virtualization, etc.
If you have a suggestion for improving this documentation or have found an
error, submit a link:http://bugzilla.redhat.com[Bugzilla report] against the
*OpenShift Container Platform* product for the *Documentation* component. Please
error, submit a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Documentation_issue&issuetype=1&components=12367614&priority=10200&versions=12385624[Jira issue] for the most relevant documentation component. Please
provide specific details, such as the section name and {product-title} version.

2
osd_support/remote_health_monitoring/about-remote-health-monitoring.adoc
View File

@@ -23,7 +23,7 @@ More information is provided in this document about these two processes.
Telemetry and the Insights Operator enable the following benefits for end-users:
* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red Hat from a broader perspective across a fleet of clusters. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a Bugzilla.
* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red Hat from a broader perspective across a fleet of clusters. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Jira issue].
* *Advanced release management*. {product-title} offers the `candidate`, `fast`, and `stable` release channels, which enable you to choose an update strategy. The graduation of a release from `fast` to `stable` is dependent on the success rate of updates and on the events seen during upgrades. With the information provided by connected clusters, Red Hat can improve the quality of releases to `stable` channels and react more rapidly to issues found in the `fast` channels.

2
serverless/serverless-support.adoc
View File

@@ -8,7 +8,7 @@ toc::[]
If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at http://access.redhat.com. You can use the Red Hat Customer Portal to search or browse through the Red Hat Knowledgebase of technical support articles about Red Hat products. You can also submit a support case to Red Hat Global Support Services (GSS), or access other product documentation.
If you have a suggestion for improving this guide or have found an error, you can submit a Bugzilla report at http://bugzilla.redhat.com against *Product* for the *Documentation* component. Provide specific details, such as the section number, guide name, and {ServerlessProductName} version so we can easily locate the content.
If you have a suggestion for improving this guide or have found an error, you can submit a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Documentation_issue&issuetype=1&components=12367614&priority=10200&versions=12385624[Jira issue] for the most relevant documentation component. Provide specific details, such as the section number, guide name, and {ServerlessProductName} version so we can easily locate the content.
// TODO: Update once https://issues.redhat.com/browse/OSDOCS-3730 is done to update this to Jira
// Generic help topics

2
support/remote_health_monitoring/about-remote-health-monitoring.adoc
View File

@@ -23,7 +23,7 @@ More information is provided in this document about these two processes.
Telemetry and the Insights Operator enable the following benefits for end-users:
* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red Hat from a broader perspective across a fleet of clusters. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a Bugzilla.
* *Enhanced identification and resolution of issues*. Events that might seem normal to an end-user can be observed by Red Hat from a broader perspective across a fleet of clusters. Some issues can be more rapidly identified from this point of view and resolved without an end-user needing to open a support case or file a link:https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200versions=12385624[Jira issue].
* *Advanced release management*. {product-title} offers the `candidate`, `fast`, and `stable` release channels, which enable you to choose an update strategy. The graduation of a release from `fast` to `stable` is dependent on the success rate of updates and on the events seen during upgrades. With the information provided by connected clusters, Red Hat can improve the quality of releases to `stable` channels and react more rapidly to issues found in the `fast` channels.