Merge lp:~sinzui/charmworld/heartbeat into lp:~juju-jitsu/charmworld/trunk
Status: | Merged |
---|---|
Approved by: | Curtis Hovey |
Approved revision: | 338 |
Merged at revision: | 323 |
Proposed branch: | lp:~sinzui/charmworld/heartbeat |
Merge into: | lp:~juju-jitsu/charmworld/trunk |
Diff against target: |
328 lines (+258/-12) 6 files modified
charmworld/health.py (+64/-0) charmworld/routes.py (+2/-11) charmworld/templates/heartbeat.pt (+28/-0) charmworld/tests/test_health.py (+94/-0) charmworld/views/misc.py (+18/-0) charmworld/views/tests/test_misc.py (+52/-1) |
To merge this branch: | bzr merge lp:~sinzui/charmworld/heartbeat |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Harding (community) | Approve | ||
Review via email: mp+176530@code.launchpad.net |
Commit message
Add /heartbeat to verify the app is operational.
Description of the change
RULES
* A review of API3 noted that the "latest" routes were updated and
that they were moved. The routes were added for webops who were confused
when APIs were removed. The 'latest' hack does not server webops well
because they don't care about the API. They care about the app's
operational health
* We want a page that allows webops to see that the site is up
* The page can list the checks it performed with pass and fail
marks.
* Developers can add checks as the site grows features
* Webops can adapt the nagios checks to verify the site is operational.
QA
* Visit http://
* Verify all the checks pass.
* They might not pass if there are no featured charms!
* Verify the response headers state the data is not cacheable.
A couple of notes. First, thanks for this. I think it's a great step.
This actually has me wondering if we can't move the logic into a charmworld/ lib/health. py and keep the logic of adding/checking there make it more reusable. I'm actually thinking I'd love to provide a cli tool to sanity check your charmworld install for devs as well.
In the failing cases where we have on charm, for #IS I'd think that's a failing condition. So in #97 and the other checks like it should that set the status to fail?
Finally, if we're going to FAIL for no featured charms, should we adjust our bootstrap to auto select at least one charm to be featured automatically. This would help with the 'new dev setup' story as well as they could be sure to have featured already and be able to point the GUI at the dev instance without issue.
Sorry, this grew.
tl;dr
1. Looks good!
2. I think it'd be nice if the health checks were a module vs in the view.
3. I think we should auto select a single featured charm during install/setup?
4. Should 0 charms be failing for IS purposes?