# Cluster becoming red during rolling upgrade
**URL:** https://discuss.elastic.co/t/cluster-becoming-red-during-rolling-upgrade/139265
**Category:** Elasticsearch
**Created:** [July 10, 2018, 5:16am UTC](https://discuss.elastic.co/t/cluster-becoming-red-during-rolling-upgrade/139265 "2018-07-10T05:16:11Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@bsarkar](https://discuss.elastic.co/u/bsarkar)
#### Post date: [July 10, 2018, 5:16am UTC](https://discuss.elastic.co/t/cluster-becoming-red-during-rolling-upgrade/139265/1 "2018-07-10T05:16:11Z")
As per the rolling upgrade process documented [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/rolling-upgrades.html), it is advised to set the value of `"cluster.routing.allocation.enable"` to `"none"` before bringing a node down for servicing and set it back to `"all"` once the node is serviced. The problem is if a new index gets created while the node is being serviced, the cluster goes to `RED` state. This is a real scenario when `xpack` creates new monitoring indices every day at `00:00 UTC`. Of course it will go back to `YELLOW` and then to `GREEN` state once allocation is enabled, but we would never want the cluster to be in `RED` state. Instead of setting it to `"none"`, doesn't it make sense to set it to `"new_primaries"`? That way it is guaranteed that the cluster will not go into `RED` state when there is no problem with the system. Please advise if there is anything wrong with this approach. If not, should we change the official documentation as well?
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 7, 2018, 5:16am UTC](https://discuss.elastic.co/t/cluster-becoming-red-during-rolling-upgrade/139265/2 "2018-08-07T05:16:25Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.