Charmed OpenSearch How-to | Minor Version Rollback

Do NOT trigger rollback during the running upgrade action! It may cause unpredictable OpenSearch state!

Manual Rollback

The upgrade can be halted and enter a failure state if, during the upgrade (i.e. after a juju refresh) there any version incompatibilities in charm revisions or it dependencies; or any other unexpected failure in the upgrade process.

Although the underlying OpenSearch continue to work, it’s important to rollback the charm to previous revision so an update can be later attempted after a further inspection of the failure.

To execute a rollback we take the same procedure as the upgrade, the difference being the charm revision to upgrade to. As an example following up the minor upgrades doc, one would refresh the charm back to revision 86, the steps being:

juju refresh opensearch --revision=87

When deploying from a local charm file, you need to have the previous revision’s .charm file. Then, run:

juju refresh opensearch --path=<path_to_charm_file>

After the refresh command, the juju controller revision for the application will be back in sync with the running OpenSearch revision.

Model  Controller           Cloud/Region         Version  SLA          Timestamp
test   localhost-localhost  localhost/localhost  3.3.4    unsupported  13:02:15Z

App                       Version  Status  Scale  Charm                     Channel        Rev  Exposed  Message
opensearch                         active      3  opensearch                                86  no       
self-signed-certificates           active      1  self-signed-certificates  latest/stable   72  no       

Unit                         Workload  Agent  Machine  Public address  Ports     Message
opensearch/0*                active    idle   1        10.229.18.7     9200/tcp  
opensearch/1                 active    idle   2        10.229.18.182   9200/tcp  
opensearch/2                 active    idle   3        10.229.18.34    9200/tcp  
self-signed-certificates/0*  active    idle   0        10.229.18.118             

Machine  State    Address        Inst id        Base          AZ  Message
0        started  10.229.18.118  juju-d69356-0  ubuntu@22.04      Running
1        started  10.229.18.7    juju-d69356-1  ubuntu@22.04      Running
2        started  10.229.18.182  juju-d69356-2  ubuntu@22.04      Running
3        started  10.229.18.34   juju-d69356-3  ubuntu@22.04      Running

Check cluster health

Check the cluster is healthy. OpenSearch’s upstream documentation suggests the following check:

GET "/_cluster/health?pretty"

The response should look similar to the following example:

{
  "cluster_name" : "test-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "discovered_master" : true,
  "active_primary_shards" : 1,

...

  "active_shards_percent_as_number" : 100.0
}
1 Like