maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

Thanks for the suggestion Scott.  I've been away on parental leave so 
apologies for the delay in replying!

On Wednesday 27 June 2012 10:22:26 Scott Moser wrote:
> The solution that I suggest is:
>  i.) modify 'B' above to include 'time_sync_url' field under 'MAAS'
>  ii.) Before cloud-init does oauthed requests for user-data in 'C'
>     above, it will first do an un-authed request to the value of
>     'time_sync_url' which will return data like:
>       Wed, 27 Jun 2012 10:13:29 -0400
>  iii.) cloud-init will then set the system clock (not the hardware clock)
>     to the given date. The subsequent oauth requests will succeed as
>     they'll have a reasonable system clock at that point.
>  iv.) if possible make cloud-init log the failure in 'C' above more
>       obviously on the console.  I believe this is less than
>       straightforward unfortunately due to the console switching around
>       that is done on boot.
> 
> Note, I skipping the 'time_sync_url' by simply directly providing a
> 'time_sync' like:
>   time_sync: Wed, 27 Jun 2012 10:13:29 -0400
> If that is seen as desirable it could probably be accommodated.  The thing
> that I do not like about it is that it writes that data to a local config
> file, and obviously the current time stamp very quickly becomes incorrect.
> Hiding it behind a url that has dynamic and correct content removes that.

I see a couple of potential problems with the first approach:

 * There may not be a time-sync url (ntp service) available
 * Unless you're talking about adding an API call to MAAS? This obviously adds 
more complexity to the SRU.

The key thing is that the node clocks need to be "near enough" to the maas 
server's clock for oauth to work.  We could just put the time right in the 
config payload but I guess that depends on whether having a more accurate 
clock time available for other purposes is desirable or not?  If not, we can 
just make the config payload item be called "oauth_time_sync" instead so it's 
a bit more obvious what it's used for (and would discourage other use).

> Note 2:  We could/should just put this in the bug.

I just did, along with this repsonse.

Cheers.