Comment 0 for bug 978127

In this simple scenario:
 a. hardware installed
 b. hardware booted and enlisted
 c. commissioning
 d. install to hardware
 e. cloud-init boot

At this point steps 'b' and 'e' do OAUTH to get user-data.

If the clock on the system is sufficiently off, then oauth will fail as shown in the attached screenshot.

it seems to make sense that 'b' would set the clock. Once the user enlists the systme to MAAS, it seems OK to start changing their hardware settings.

There is still a potential for really bad hardware clock that could forget its settings on reboot, or somehow get off between 'b' and 'c'. If we were really interested in fixing that, cloud-init could read a kernel command line parameter pointing to a system that ran an ntp server and just run that very early in boot to set the local date.