Approving a change
When the agent proposes changing a database or your cluster, see exactly what would run, then approve or skip it. It's one of the fix options.
Sometimes the fix for a ticket is a change to your live system, not your code. For example, correcting a wrong record in a database, or restarting a stuck service in your Kubernetes cluster. The agent can't make these changes itself. It proposes one, as a fix option, for you to approve.
A live change is usually quick, but it may not last: if the same setting lives in a repository, the next deploy puts the old value back. So the agent often proposes the repository fix too, next to it. See Fix options.
Find it#
Open the ticket from the Queue. Under Now, Fix options shows the live change as Change the live cluster (or Change the bookings database), with what it changes, and what is good (+) and not so good (–) about it. The agent: above the options says which to choose, and why.
The reply to the requester is separate, under Reply to the requester. It doesn't wait for the change: send it whenever you like.
Check what would run#
Click Review and approve. Under the option:
| Part | What it means |
|---|---|
| Risk | The agent's view: low, medium or high. |
| Exactly what will run | For a database: the exact statements (on MongoDB, operations), and the most rows they may change. For the cluster: each operation in plain words, with any settings it changes. |
Database changes#
You see the exact statements, for example:
UPDATE bookings SET status = 'confirmed' WHERE id = 'B-78';
They run in one transaction with the database's change login. If more rows would change than stated, nothing changes. Only INSERT, UPDATE and DELETE statements can be proposed.
On a MongoDB database, you see operations written in JSON instead, for example:
{"collection": "bookings", "update_one": {"filter": {"bookingId": "B-78"}, "update": {"$set": {"status": "confirmed"}}}}
Only inserts, updates and deletes can be proposed there, and they too run in one transaction. If more documents would change than stated, nothing changes.
Cluster changes#
| Operation | Example |
|---|---|
| Restart | Restart deployment/api in production |
| Scale | Scale deployment/worker in production to 3 replicas |
| Delete | Delete pod/api-7f9c in production |
| Change | Change configmap/api-settings in production |
| Create | Create job/cleanup in production |
| Run a cronjob now | Run cronjob nightly-report now, in production |
Every operation is tried first without changing anything; if one fails, none runs. Cluster changes can never touch Secrets, permissions or namespaces other than the ones you allowed.
Approve it#
- 1
Click Review and approve under the change.
- 2
Read what will run. This is what will happen, character for character.
- 3
Click Approve.
The option says Being made now. A moment later it says ✓ Done, or It didn't work, with the reason and Try again.
Then the agent looks again. It checks the result if it can, writes the reply to the requester about it, and says whether the other fix option still stands: a repository fix that keeps the change on the next deploy usually does.
When two people must approve#
Your organisation may ask for two different people to approve each change of a kind (see Two people to approve). Then the first Approve doesn't run the change. The option says, for example, Approved by Ann at 10:42. Needs a second person. The people who can approve are told.
You can't give the second approval yourself: Approve is greyed out, with You approved it. A second person must approve it before it runs. Someone else opens the ticket, reads the change and clicks Approve. Then it runs.
If the second person edits the change first, your approval no longer counts: theirs is the first of the new version, and it needs another person. Anyone can still click Skip to stop it.
Skip it#
Click Skip. Nothing is done, and nothing else on the ticket changes: the reply and the other fix option still wait for you. The change stays, saying You skipped it, with Review and approve in case you change your mind.
To tell the agent what to do instead, write to it in Write at the bottom of the ticket. When it looks again it may say the change is No longer needed, and why.
Afterwards#
Every change, who approved or skipped it, and its result stay in the ticket's What happened. See Tickets and the ticket page.