Merge lp://staging/~sinzui/charms/precise/juju-gui/nagios into lp://staging/charms/juju-gui
Status: | Merged |
---|---|
Merged at revision: | 74 |
Proposed branch: | lp://staging/~sinzui/charms/precise/juju-gui/nagios |
Merge into: | lp://staging/charms/juju-gui |
Diff against target: |
446 lines (+378/-3) 8 files modified
config.yaml (+11/-1) files/nrpe-external-master/check-app-access.sh (+18/-0) metadata.yaml (+3/-0) revision (+1/-1) scripts/charmsupport/hookenv.py (+150/-0) scripts/charmsupport/nrpe.py (+169/-0) scripts/update-nrpe.py (+14/-0) tests/20-functional.test (+12/-1) |
To merge this branch: | bzr merge lp://staging/~sinzui/charms/precise/juju-gui/nagios |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Benji York (community) | Approve | ||
charmers | Pending | ||
Review via email: mp+177588@code.staging.launchpad.net |
Description of the change
Add nagios support.
RULES
Pre-
* We want to support the nagios subordinate charm to monitor production.
* Webops prefer to use the nrpe module from charmsupport.
* The project merged with charmhelpers (not related to the charm-helpers
ppa that all PPA configured juju deploys get).
* Webops write a custom script for each charm they deploy to embed the
library in the charm; they alway deploy a forked charm. The charm
runs with a modified python path to find that included libs.
* Webops require the charm to ensure errors installing dependencies are
are ignored since they have ensured the libs are already in the charm.
* Or have they? Every change to the charm requires review of a webop
to ensure the building of a fat charm really works.
* I decided to include just the nrpe module and its dependencies in
the charm's tree.
* No action is needed to build out a fat charm.
* No future coordination with webops to ensure the charm really
installs its deps.
* I chose an older version of nrpe because it has fewer deps than
the current version. I chose the same version used by charmworld.
I'd like to keep these two charms synced to simplify the parts used
to deploy charmworld.com
QA
DEPLOY JUJU-GUI AND NAGIOS
juju bootstrap
juju deploy --repo=
juju deploy nagios
juju add-relation nagios juju-gui
juju expose nagios
Verify you can see juju-gui in nagios with a single ssh check
DEPLOY NRPE-EXTERNAL-
juju deploy nrpe-external-
juju set nrpe-external-
juju add-relation nrpe-external-
Verify you can see the nagios external cfg files in juju-gui's file system.
ls /var/lib/
Verify the unit config "host__
IMPLEMENTATION
* I added just the parts of the nrpe library needed.
scripts/
scripts/
scripts/
* I added a hook that calls the update-nrpe.py script that in turn
registers the check-front-page.sh script. nrpe requires the
check scripts to be in files/nrpe-
hooks/
scripts/
files/
* I updated the metadata and config to enable the subordinate charm.
config.yaml
metadata.yaml
revision
Thanks for wiring this up. Monitoring is essential.
Given that this MP doesn't have Reitveld links, I assume you didn't use
lbox to propose it. Despite it's many annoyances, lbox is the
prescribed way of proposing and landing GUI branches. The most
important thing it does is to run "make check" before proposing a
branch. Please manually run that command before landing. Thanks.
> I decided to include just the nrpe module and its dependencies in the
> charm's tree.
It's a shame that our policies push us toward doing things like copy
chunks of code from outdated dependencies, but I can't proffer anything
better.
In check-front-page.sh (line 31 of the diff) shouldn't it be "sites-enabled"
instead of "sites-available"?
Also, I suggest using "https:/ /127.0. 0.1:443/ juju-ui/ version. js" for ADDRESS Info" for LIFE_SIGN. Being code, that is less likely Endpoint"
and "jujuGuiVersion
to change because of a UI/UX redesign and we can write a test for it
that ensures if it does change a test named "testMonitoring
will fail. Oh, and we need that test in this branch too.
Once the above are addressed, this will be ready to land.