apiclient: add high-level update subcommands

[tjkirch]

Issue number:

Hopefully makes #1164 and #1165 no longer pressing, as users won't have to script around apiclient for common use cases.

Description of changes:

There are a number of API calls you have to issue to update a host, generally requiring an outside reference and some scripting, which is more difficult than it should be for such a fundamental task. (If you have access to the admin container, you can use updog directly, but the admin container shouldn't be required on production hosts.)

This aims to simplify updates by adding update check, update apply, update cancel, and reboot subcommands to apiclient. You can do everything in one call with apiclient update apply --check --reboot if desired.

Testing done:

apiclient check by itself gives the update status in JSON (as received from the API, just pretty-printed) which can be used for manual decision-making as required.

[ec2-user@ip-192-168-3-231 ~]$ apiclient update check
19:44:06 [INFO] Refreshing updates...
{
  "active_partition": {
...
  "update_state": "Ready"
}

update apply --check checks and confirms there's no update available:

[ec2-user@ip-192-168-19-156 ~]$ apiclient update apply --check
23:51:02 [INFO] Refreshing updates...
{
...
  "update_state": "Idle"
}
23:51:03 [INFO] No updates available.
[ec2-user@ip-192-168-19-156 ~]$ echo $?
0

I then added an update to the repo and applied it OK:

[ec2-user@ip-192-168-19-156 ~]$ apiclient update apply --check
23:53:09 [INFO] Refreshing updates...
{
...
  "update_state": "Available"
}
23:53:09 [INFO] Downloading and applying update to disk...
23:53:14 [INFO] Still waiting for updated status, will wait up to 594.5s longer...
23:53:19 [INFO] Setting the update active so it'll apply on the next reboot...
23:53:19 [INFO] Update has been applied and will take effect on next reboot.
[ec2-user@ip-192-168-19-156 ~]$ echo $?
0

Another apply will tell you it's already done:

[ec2-user@ip-192-168-19-156 ~]$ apiclient update apply --check
23:53:31 [INFO] Refreshing updates...
{
...
  "update_state": "Ready"
}
23:53:31 [INFO] Update already applied; reboot for it to take effect, or request a cancel.
[ec2-user@ip-192-168-19-156 ~]$ echo $?
0

cancel works, and allowed me to do another apply.

[ec2-user@ip-192-168-3-231 ~]$ apiclient update cancel --log-level trace
19:45:58 [INFO] Canceling update...

I ran an apply/cancel loop for nearly 2 hours, which each cycle taking about 10 seconds, or about 720 updates with no issues.

I also ran with --reboot, which worked and updated into the new version, and tested apiclient reboot on its own OK.

I confirmed I get the expected "failed to prepare update" when I make an object in my repo private, causing a 403.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[tjkirch]

^ This push uses @etungsten's suggestion to simplify the pretty-printing of check output. I built an AMI and confirmed check output is still so pretty. 💅

[zmrow]

Nice work!

[zmrow]

⛱️

[tjkirch]

^ This push addresses @bcressey 's comments.

The wait timing still works fine:

[ec2-user@ip-192-168-14-48 ~]$ apiclient update apply --check --log-level trace
18:11:03 [INFO] Refreshing updates...
...
18:11:04 [DEBUG] (1) apiclient::update: Saw state 'Available', assuming update is required
18:11:04 [INFO] Downloading and applying update to disk...
18:11:04 [DEBUG] (1) apiclient::update: Found initial timestamp '2020-11-20T18:11:04.323000276Z'
18:11:04 [TRACE] (1) apiclient::update: [api/apiclient/src/update.rs:272] Lock still held, presumably by our request...
18:11:05 [TRACE] (1) apiclient::update: [api/apiclient/src/update.rs:272] Lock still held, presumably by our request...
...
18:11:18 [INFO] Setting the update active so it will apply on the next reboot...
18:11:18 [DEBUG] (1) apiclient::update: Found initial timestamp '2020-11-20T18:11:18.302010788Z'
18:11:18 [TRACE] (1) apiclient::update: [api/apiclient/src/update.rs:272] Lock still held, presumably by our request...
18:11:18 [TRACE] (1) apiclient::update: [api/apiclient/src/update.rs:272] Lock still held, presumably by our request...
18:11:18 [DEBUG] (1) apiclient::update: Found timestamp '2020-11-20T18:11:18.613418587Z' and command 'activate' (looking for command 'activate' and a change from initial timestamp '2020-11-20T18:11:18.302010788Z')
18:11:18 [INFO] Update has been applied and will take effect on next reboot.