Cause. The server is in a state that does not allow the operation. Most operations need the state active. Leaving rescue mode needs the state rescue. A server in the state creating, deleted or failed accepts none of them. The same code is used when the server has no virtual machine yet.
Remedy.
Show the state of the server: kyvernon servers <tenant> get <server>.
When the state is creating, wait until it is active, then repeat the operation.
When the state is rescue, leave rescue mode first: kyvernon servers <tenant> unrescue <server>.
When the state is failed, an administrator reads the failed task for the cause: kyvernon tasks list. Pass on the id of the server.
the request field that holds the rejected plan, here plan.
Cause. A server can move only to a plan that is at least as large as its plan in vCPUs, memory and disk, and is not the same plan. A move to a smaller or equal plan is refused.
Remedy.
List the plans: kyvernon plans list.
Choose a plan that is not smaller in any dimension: kyvernon servers <tenant> resize <server> <plan>.
To end up with a smaller server, create a new server on a smaller plan and move the data.
the request field that holds the rejected value, image or plan.
Cause. The plan restricts the images that may be used with it, and the image is not on that list. The same check applies when a server is resized to a plan that does not allow its image.
Remedy.
Choose an image that the plan allows, or a plan that allows the image.
An administrator can add the image to the plan: kyvernon plans update <id> --body-file <file>.
Cause. Rescue mode was started without naming an image, and no image of the catalogue is marked as a rescue image.
Remedy.
Name a rescue image: kyvernon servers <tenant> rescue <server> --image <image>.
An administrator marks a template as the rescue image: kyvernon catalogue set <id> --body '{"catalogue":false,"rescue":true}', then adds the other catalogue fields that the template needs.