Investigating - 70% of allocated disk for application logging has been exceeded.

The OpenShift SRE Team has identified excessive application logging on this cluster that is consuming a significant amount of the allocated storage space. If this behavior continues, it runs the risk of exhausting storage for the aggregated logging service. If this occurs, new application logs will not be stored in aggregated logging until older logs are pruned and additional capacity is available. If the amount of logging is not controlled, the logging data store is at risk of data corruption / loss. SRE has no control of the verbosity of a customers logging. Therefore, the customer needs to control the amount of logging.

Please review application logging verbosity and consider decreasing the amount of applications logging.

If you have any questions, please feel free to contact us:
https://access.redhat.com/support/policy/support_process
https://access.redhat.com/support/contact/technicalSupport/

Thank you for choosing Red Hat OpenShift Dedicated,
OpenShift SRE
Jul 22, 20:47 UTC
starter-us-east-1 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
starter-us-east-2 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
starter-us-west-2 Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
starter-us-east-2a Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
fuse-ignite Operational
90 days ago
100.0 % uptime
Today
Master API Service Operational
90 days ago
100.0 % uptime
Today
Application Creation Service Operational
90 days ago
100.0 % uptime
Today
Docker Registry Service Operational
90 days ago
100.0 % uptime
Today
etcd Service Operational
90 days ago
100.0 % uptime
Today
starter-us-east-1a Operational
Master API Service Operational
Application Creation Service Operational
Docker Registry Service Operational
etcd Service Operational
starter-us-east-1b Operational
Master API Service Operational
Application Creation Service Operational
Docker Registry Service Operational
etcd Service Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
had a major outage
had a partial outage
Scheduled Maintenance
SRE is performing maintenance on this cluster to renew SSL certificates.

The process is engineered to disrupt customer applications as little as possible, but brief outages may occur during service restarts. For short periods of time, developers may be unable to create new applications or interact with existing applications.

Thank you for choosing Red Hat OpenShift Dedicated,
OpenShift SRE
If you have any questions, please feel free to contact us:
https://access.redhat.com/support/policy/support_process
https://access.redhat.com/support/contact/technicalSupport
Posted on Jul 15, 02:39 UTC
Past Incidents
Jul 23, 2019

No incidents reported today.

Jul 21, 2019

No incidents reported.

Jul 20, 2019

No incidents reported.

Jul 19, 2019

No incidents reported.

Jul 18, 2019

No incidents reported.

Jul 17, 2019

No incidents reported.

Jul 16, 2019

No incidents reported.

Jul 15, 2019
Completed - The SSL certificate renewal maintenance on starter-us-east-2a has been completed.

If you have any questions, please feel free to contact us:
https://access.redhat.com/support/policy/support_process
https://access.redhat.com/support/contact/technicalSupport

Thank you for choosing Red Hat OpenShift Dedicated,
OpenShift SRE
Jul 15, 02:37 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 15, 02:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 15, 2019 at 02:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 15, 01:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 15, 2019 at 02:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 14, 22:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 15, 2019 at 02:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 14, 18:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 15, 2019 at 02:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 14, 02:00 UTC
Scheduled - SRE is performing maintenance on this cluster to renew SSL certificates.

The process is engineered to disrupt customer applications as little as possible, but brief outages may occur during service restarts. For short periods of time, developers may be unable to create new applications or interact with existing applications.

If you have any questions, please feel free to contact us:
https://access.redhat.com/support/policy/support_process
https://access.redhat.com/support/contact/technicalSupport

Thank you for choosing Red Hat OpenShift Dedicated,
OpenShift SRE
Jun 17, 00:43 UTC
Jul 14, 2019

No incidents reported.

Jul 13, 2019

No incidents reported.

Jul 12, 2019

No incidents reported.

Jul 11, 2019

No incidents reported.

Jul 10, 2019
Completed - The TCP SACK PANIC security remediation for starter-us-east-2a has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 10, 13:21 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 18:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 17:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 14:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 10:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 18:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:43 UTC
Jul 9, 2019
Completed - The TCP SACK PANIC security remediation for starter-us-west-2 has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 9, 23:03 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 18:04 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 17:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 14:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 10:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 18:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 18:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:44 UTC
Completed - The TCP SACK PANIC security remediation for starter-us-east-2 has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 9, 22:59 UTC
Update - Security remediation has completed on most of the cluster. However, the logging stack is currently in an unhealthy state and SRE is working to address this issue before remediating the final infra nodes.
Jul 9, 21:21 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 14:21 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 13:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 10:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 06:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 14:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:42 UTC
Completed - The TCP SACK PANIC security remediation for starter-us-east-1b has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 9, 19:24 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 14:05 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 13:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 10:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 06:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 14:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 14:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:42 UTC
Completed - The TCP SACK PANIC security remediation for starter-us-east-1a has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 9, 08:57 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 04:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 04:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 03:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 04:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 00:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 04:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 20:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 04:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 04:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:42 UTC
Completed - The TCP SACK PANIC security remediation for starter-us-east-1 has been successfully completed.

Thank you for using OpenShift.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/

Links to the CVE:
https://access.redhat.com/security/cve/cve-2019-11477
https://access.redhat.com/security/cve/cve-2019-11478
https://access.redhat.com/security/cve/cve-2019-11479
Jul 9, 05:57 UTC
In progress - Scheduled maintenance is currently starting. We will provide updates as necessary. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 9, 00:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 00:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 23:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 00:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 20:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 00:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 16:00 UTC
Update - This is a reminder regarding your upcoming scheduled maintenance on Jul 9, 2019 at 00:00 UTC. If you have any questions or concerns, please contact support at https://access.redhat.com/support/contact/technicalSupport/.
Jul 8, 00:00 UTC
Scheduled - SRE is performing a remediation to protect OpenShift Dedicated clusters against various kernel network stack vulnerabilities, described here: https://access.redhat.com/security/vulnerabilities/tcpsack

How does the maintenance work?
Master nodes are remediated first. An SRE-initiated playbook will remediate each of the master nodes, one at a time, removing them from the ELB as the maintenance is performed, until all three master nodes are patched, rebooted and confirmed to be protected from the vulnerabilities.

Compute and infrastructure nodes are remediated once the master nodes are done. Compute and infrastructure nodes are part of an AWS scale group. A new scale group will be created that includes the latest, remediated AMI. This new scale group will be activated and when all the instances are up and available, the legacy nodes will be marked not schedulable, and the new instances marked schedulable. This action will move all compute workloads to the newly created and remediated instances. Once all the workloads are migrated, the legacy scale group and associated instances will be decommissioned.

The cluster will be confirmed both operational and remediated and the maintenance window will be closed.

What should you do?
You can minimize the impact on your applications by scaling your services to more than one pod. In general, for applications to be able to continue to service clients, they should be scaled. Some pod workloads are not appropriate for scaling, such as a single-instance, non-replicated database using a persistent volume claim. In this situation, a deployment strategy of 'recreate' will ensure the pod is restarted after migration, although a brief outage will be experienced.

For more information, refer to the following guide:
https://blog.openshift.com/deploying-highly-available-applications-openshift-kubernetes/

Thank you for using OpenShift Dedicated.

Support links:
https://access.redhat.com/support
https://access.redhat.com/support/contact/technicalSupport/
Jun 21, 19:41 UTC