All Systems Operational
pro-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
pro-eu-west-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
pro-ap-southeast-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
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 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/
Posted on Jun 21, 19:44 UTC
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/
Posted on Jun 21, 19:44 UTC
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/
Posted on Jun 21, 19:45 UTC
Past Incidents
Jun 25, 2019

No incidents reported today.

Jun 24, 2019

No incidents reported.

Jun 23, 2019

No incidents reported.

Jun 22, 2019

No incidents reported.

Jun 21, 2019

No incidents reported.

Jun 20, 2019

No incidents reported.

Jun 19, 2019

No incidents reported.

Jun 18, 2019

No incidents reported.

Jun 17, 2019

No incidents reported.

Jun 16, 2019

No incidents reported.

Jun 15, 2019

No incidents reported.

Jun 14, 2019

No incidents reported.

Jun 13, 2019

No incidents reported.

Jun 12, 2019

No incidents reported.

Jun 11, 2019

No incidents reported.