update_cluster
ActiveTool of cloud.redu/mcp
Updates a running autoscaling cluster to a new app version IN PLACE, with NO URL change: snapshots the 'hero' VM (the source/master VM you SSH into and change — it is also the always-on baseline member that serves traffic), then Heat rolling-updates the autoscaled extra members to that snapshot ONE AT A TIME and refreshes the image the group boots future members from — the SAME load balancer and SAME *.redu.cloud URL are kept, and the service stays up during the roll. This is the ONLY way to update a cluster: you do NOT edit live members (they are disposable clones); you change the hero VM (SSH into it, deploy the new version), then update_cluster snapshots it and spreads it to the fleet (the hero already runs your change; this propagates it to the autoscaled members). The snapshot upload can take several minutes on a large disk; poll list_clusters until the stack status is UPDATE_COMPLETE.
Parameters schema
{
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"stack_name",
"stack_id",
"instance_id"
],
"properties": {
"stack_id": {
"type": "string",
"minLength": 1,
"description": "Cluster (Heat stack) id — from list_clusters (id)."
},
"stack_name": {
"type": "string",
"minLength": 1,
"description": "Cluster (Heat stack) name — from list_clusters (stack_name)."
},
"instance_id": {
"type": "string",
"minLength": 1,
"description": "The 'hero' VM to snapshot and roll to every extra member: the source/master VM you upgraded to a cluster and SSH into to make changes. It is your cluster's always-on baseline member. Its CURRENT disk state becomes the new member image, so make your changes on it FIRST, then call this."
},
"idempotency_key": {
"type": "string",
"minLength": 8
}
},
"additionalProperties": false
}No endpoints wrapped at confidence ≥ 0.70.
Parent server
cloud.redu/mcp
1/7 registries