MAAS

Merge lp://staging/~smoser/maas/trunk.maas-signal-clockskew into lp://staging/~maas-committers/maas/trunk

trunk.maas-signal-clockskew
Merge into trunk

Proposed by Scott Moser on 2012-10-09

Status:

Merged

Approved by:

Scott Moser on 2012-10-09

Approved revision:

no longer in the source branch.

Merged at revision:

1242

Proposed branch:

lp://staging/~smoser/maas/trunk.maas-signal-clockskew

Merge into:

lp://staging/~maas-committers/maas/trunk

Diff against target:

82 lines (+44/-9)

1 file modified

etc/maas/commissioning-user-data (+44/-9)

To merge this branch:

bzr merge lp://staging/~smoser/maas/trunk.maas-signal-clockskew

Critical

Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Robie Basak (community)		2012-10-09	Approve on 2012-10-09
Review via email: mp+128794@code.staging.launchpad.net

Commit message

make maas-signal adjust clock and retry on 401 or 403 errors.

oauth failures due to incorrect clock by maas return error 401.
If we see this error, then maas-signal will read the timestamp in the
response header and update future requests based on that time.

This is the same approach fix that went into cloud-init.

Description of the change

make maas-signal adjust clock and retry on 401 or 403 errors.

oauth failures due to incorrect clock by maas return error 401.
If we see this error, then maas-signal will read the timestamp in the
response header and update future requests based on that time.

This is the same approach fix that went into cloud-init.

Revision history for this message

Robie Basak (racb) wrote on 2012-10-09:

Looks good! I've tested this and it appears to work. Commissioning does not set the RTC as expected, but the install step does.

A couple of comments, although I understand the criticality of this fix and the imminent deadline so we don't necessarily need to consider this now. Go ahead and land it.

1. Instead of hardcoding 401 and 403, we should use httplib constants.

2. I'm not sure about the use of exc to carry through the exception. In the catch clause, does that exc stay in scope for after it is set, or is there a new scope that hides the outer exc? I'm not sure. For readability, it might be worth using a different name for the inner scope and explicitly setting the one defined in the outer scope. I'm not sure about the whole mechanism, actually, but I won't think about it any longer. It'll work for now.

review: Approve

Revision history for this message

Scott Moser (smoser) wrote on 2012-10-09:

Reguarding '2', the exc works as expected:
#!/usr/bin/python
import sys
def main():
    print "HI WORLD"
    exc = Exception("unexpected error")
    for i in (1,2,3,4):
       try:
          raise(TypeError("foobar: %d" % i))
       except TypeError as exc:
          sys.stderr.write("caught exc: %s\n" % exc)
       except Exception as exc:
          sys.stderr.write("caught EXC: %s\n" % exc)
    raise exc
main()