Merge lp:~jtv/maas/bug-1058313 into lp:~maas-committers/maas/trunk
Proposed by
Jeroen T. Vermeulen
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 1114 |
Proposed branch: | lp:~jtv/maas/bug-1058313 |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
59 lines (+21/-3) 2 files modified
src/metadataserver/api.py (+8/-1) src/metadataserver/tests/test_api.py (+13/-2) |
To merge this branch: | bzr merge lp:~jtv/maas/bug-1058313 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel (community) | Approve | ||
Review via email:
|
Commit message
Return, not raise, a 404 when an enlisting node asks for public-keys on the metadata service. It still doesn't have any (and as per the bug report things work just fine without) but this will suppress useless tracebacks in the log.
Description of the change
Discussed with Julian. No changes in cloud-init; it has no conception of enlistment so we have no good way to stop it from asking. But we can make the server not take it so badly.
Jeroen
To post a comment you must log in.
Are there any times other than during enlistment where public-keys are requested and it would be better to put something in the log? Found(" No SSH keys available for this node.")
if
22 + if item == 'public-keys':
23 + return HttpResponseNot
is only in the 'enlistment' codepath, then it seems perfectly reasonable. And I certainly agree that not logging errors when there aren't any is a good thing.