Documentation regarding the different activity actions (ECE v1.1)

Elastic Orchestration Elastic Cloud Enterprise (ECE)
1

When reading through my clusters' activity through the following endpoint https://www.elastic.co/guide/en/cloud-enterprise/1.1/get-es-cluster-plan-activity.html I noticed there are different activity actions found in the https://www.elastic.co/guide/en/cloud-enterprise/1.1/ChangeSourceInfo.html. Specifically, in the source.action. The following is a list of all of the unique actions i've seen across all of my clusters.

elasticsearch.update-cluster-plan
vacate-allocator
elasticsearch.create-cluster
elasticsearch.stop-cluster
elasticsearch.reboot-cluster
elasticsearch.restart-cluster
create-logging-and-metrics-cluster
create-admin-console-backend

Is there any additional documentation describing what each of these activity actions do to a cluster? Specifically, which activity actions stop and restart a cluster.

Based on my own analysis, I've seen that the 3 create actions, elasticsearch.restart-cluster and elasticsearch.update-cluster-plan restart a cluster, and elasticsearch.stop-cluster stops a cluster. Is this a safe assumption to make that no other activity actions correspond to a restart/stop?

2

@Simon_Khan

That's a great point, we don't document the different source.action fields and we should.

Here's the full list that can be generated by the v1 API at the moment (the last 2 from your list are special cases, those clusters are created using the legacy API; the vacate-cluster is also a legacy value, corresponding to move-instances, though that is still in use in the UI)

Here's the new values that are currently accessible from plan changes (others are visible in the audit logs, eg delete-cluster):

  val `reboot-cluster` =  // POST clusters/elasticsearch/:id/_restart
  val `restart-cluster` = // POST clusters/elasticsearch/:id/_restart
  val `stop-cluster` = // POST clusters/elasticsearch/:id/_shutdown
  val `create-cluster` = // POST clusters/elasticsearch
  val `update-cluster-plan` = // clusters/elasticsearch/:id
  val `move-instances` =  // POST clusters/elasticsearch/:id/instances/:instance-list/_move

I added the document endpoints that can result in the different sources

One complication is that update-cluster-plan can result in a stop or restart of a cluster, eg from the transient.plan_configuration.cluster_reboot (restart) or running a plan change with transient.strategy.rolling and transient.strategy.rolling.group_by set to "__all__" (restart), or by clearing the cluster_topology element (shutdown) ... basically all activities are implemented as special cases of update-cluster-plan

3

Thank you @Alex_Piggott for your quick reply, I really appreciate your help.

And thank you for defining what the update-cluster-plan does and how it can trigger a stop event, that helps a lot.

I just have a few more follow up questions from your reply.

  1. You mentioned the vacate-cluster is a legacy value, is that true for vacate-allocator as well? Or vacate- anything for that matter?

  2. Also for the audit logs, to clarify, you are referring to the Elasticsearch logs that's accessible from the ECE admin UI under the external links correct? Or is this a separate set of logs?

  3. And finally, what exactly is the difference between a restart-cluster and a reboot-cluster action? The documentation for https://www.elastic.co/guide/en/cloud-enterprise/1.1/restart-es-cluster.html states that the endpoint will restart an Elasticsearch cluster but applies a cluster_reboot.

Thank you again for your help, it is greatly appreciated.

4

You mentioned the vacate-cluster is a legacy value, is that true for vacate-allocator as well? Or vacate- anything for that matter?

Apologies, vacate-cluster was just a typo, I meant vacate-allocator, there are 2 v1 API equivalents:

though both of which show up as move-instances.

Also for the audit logs ...

Err sorry, I misspoke there. I was talking about the audit log files of all ECE API access that the adminconsole container in the coordinator role ships to the L+M cluster in ECE 2.x - but actually that log provides the endpoints, sanitized bodies, and response codes (we had at one point planned to expand the source.action for use in an activity log but ended up going in a different direction)

And finally, what exactly is the difference between a restart-cluster and a reboot-cluster action

reboot-cluster starts with a running cluster and stops and then restarts each instance according to the transient.strategy (by default, one instance at a time)

restart-cluster starts with a stopped cluster (ie with no instances), restores its last good configuration (and also refills it with data from its snapshot if possible).

The slightly confusing bit is that they are both triggered by the _restart endpoint (https://www.elastic.co/guide/en/cloud-enterprise/current/restart-es-cluster.html), which one happens depends on the state of the cluster.

Alex

5

Ah I see, thank you for the clarification, that helps a lot.

Since we will eventually be upgrading to ECE 2.0, would you mind providing the list of possible source.action fields for the v2 API? With the document endpoints that can result in the different sources? Just so I have an idea of what might change with the source.action fields in the new version.

Thanks!

-Simon

6

would you mind providing the list of possible source.action fields for the v2 API?

Actually ECE 2.0 still uses the v1 API (there are extra fields in ECE 2.0 for the new features but it is backwards-compatible with ECE 1.x) and has the same set of source.actions.

The v2 API is under development, and will change some of the source.actions but it's not close enough to delivery yet to be able to share confidently any of the new values.

7

I see, that makes sense.

thank you for all your help @Alex_Piggott! I appreciate it!

-Simon

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.