Merge lp:~smoser/cloud-init/run-status into lp:~cloud-init-dev/cloud-init/trunk
Proposed by
Scott Moser
Status: | Merged |
---|---|
Merged at revision: | 964 |
Proposed branch: | lp:~smoser/cloud-init/run-status |
Merge into: | lp:~cloud-init-dev/cloud-init/trunk |
Diff against target: |
280 lines (+175/-15) 3 files modified
bin/cloud-init (+121/-14) cloudinit/util.py (+3/-1) doc/status.txt (+51/-0) |
To merge this branch: | bzr merge lp:~smoser/cloud-init/run-status |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
cloud-init Commiters | Pending | ||
Review via email: mp+208056@code.launchpad.net |
Description of the change
Add 'status' output
This adds a 'status' output in /var/lib/
status.json provides status of each of the cloud-init modes (init, init-local, config-modules, config-final).
result.json provides a more simplistic "did it finish successfully", and "did it finish".
The presense of result.json will tell you if it ran already, and parsing and looking at len(errors) tells you if there were errors.
There are symlinks provided to /run to make sure these files aren't confused with prior boots.
One less than ideal thing is that none of this is configurable at the moment.
To post a comment you must log in.
This looks great, and I believe the behaviour you describe will fulfil my use case. Thanks!
One minor nitpick. When you overwrite status.json, is there a race when a reader might see an incompletely written file, or have I missed something? Can you rename the file in atomically? Same for result.json. Then readers are guaranteed to always be able to parse the files if they exist. I don't see the symlinks needing any special behaviour here, as they'll atomically switch to pointing to the new (complete) files as soon as they are renamed in.