Create Ubuntu Core Reinstall device connector

[jocave]

Description

This a frequently used speciialistion of the OemRecovery device connector. To reduce the need to frequently configure the same recovery commands create a device connector for this purpose.

Resolved issues

None

Documentation

Web service API changes

None

Tests

Testing

[kevinyehk]

I think your PR wants to eliminate too many customized agent-configs that store in cc-tool-box or elsewhere, but some of oemrecovery machines with FDE need to run - echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request before running sudo snap reboot --install.

For now, there isn't a field or a place in C3 can tell if the image running on the DUT has FDE enable, so it can't be populated when running cc-lab-manager.

I'm not sure whether if we keep using the customized config for those special cases is acceptable, if yes then I don't have any question for your PR now.

[jocave]

I think your PR wants to eliminate too many customized agent-configs that store in cc-tool-box or elsewhere, but some of oemrecovery machines with FDE need to run - echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request before running sudo snap reboot --install.

For now, there isn't a field or a place in C3 can tell if the image running on the DUT has FDE enable, so it can't be populated when running cc-lab-manager.

I'm not sure whether if we keep using the customized config for those special cases is acceptable, if yes then I don't have any question for your PR now.

Yes this only attempts to handle devices that don't require any other commands - of which there are quite a few. We need to work through all the cases handled through exceptions configured in cc-toolbox such that is a single point of configuration (that being C3). We should at all the other cases systematically.

If this is a quick win then I think it makes sense to have it - interested to know what @plars thinks.

[plars]

Here's what I'm thinking:

1. ensure ssh access to the system. Without that, we can't provision it this way anyway! We could try to reboot if possible, but if we can't ssh to the device then we have to fail the provision.
2. check if /sys/class/tpm/tpm0/ppi/request exists

• If not, then just continue. There's no TPM to reset
• If it does exist, then we may or may not NEED to reset the tpm, but I think resetting it shouldn't hurt anything. This command must succeed though, because if it DOES need to have the tpm reset, then trying to proceed with provisioning without resetting it will make it unusable until someone fixes it.

3. sudo snap reboot --install

Thoughts?

[jocave]

Here's what I'm thinking:

1. ensure ssh access to the system. Without that, we can't provision it this way anyway! We could try to reboot if possible, but if we can't ssh to the device then we have to fail the provision.
2. check if /sys/class/tpm/tpm0/ppi/request exists

• If not, then just continue. There's no TPM to reset
• If it does exist, then we may or may not NEED to reset the tpm, but I think resetting it shouldn't hurt anything. This command must succeed though, because if it DOES need to have the tpm reset, then trying to proceed with provisioning without resetting it will make it unusable until someone fixes it.

3. sudo snap reboot --install

Thoughts?

I had been wondering about whether just always resetting myself in presence of a TPM, but had been wondering if this needed to be configured somewhere else. I think your suggestion is elegantly simple though and seems like it should work.