Monitoring - The fuse-ignite cluster is undergoing an upgrade.
The upgrade process is engineered to disrupt applications as little as possible, but brief outages may occur during the upgrade. For short periods of time, developers may be unable to create new applications or interact with existing applications.
In addition to the OpenShift upgrade, applications using the following imagestreams will be automatically updated:
apicast-gateway
dotnet
dotnet-runtime
fis-java-openshift
fis-karaf-openshift
httpd
jboss-amq-63
jboss-datagrid71-client-openshift
jboss-datagrid71-openshift
jboss-eap70-openshift
jboss-eap71-openshift
jboss-webserver30-tomcat7-openshift
jboss-webserver30-tomcat8-openshift
jboss-webserver31-tomcat7-openshift
jboss-webserver31-tomcat8-openshift
jenkins
mariadb
mongodb
mysql
nodejs
perl
php
postgresql
python
redhat-openjdk18-openshift
redis
ruby
wildfly
To disable automatic upgrade of these applications, modify the imageChangeTrigger in the application's DeployConfig or BuildConfig.
https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/basic_deployment_operations.html#image-change-trigger
How does the upgrade work?
During the 3.7 in-place upgrade, existing nodes will be evacuated, which requires pods to be stopped and moved to other nodes in the cluster (including any temporary nodes).
What should you do?
You can minimize the impact on your applications by scaling your services to more than one(1) 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/
Apr 19, 15:21 UTC