On Wed, 24 Apr 2013 14:11:00 -0600
Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, 24 Apr 2013 11:06:47 -0600
Tim Flink <tflink(a)redhat.com> wrote:
> The blocker tracking app  has been in staging  for a while now
> and I'd like to move it to production so that we can start proposing
> blocker and fe bugs via the web interface instead of assuming that
> everyone understands how the blocker/fe process works.
> I'd like to get that started this week, are there any objections to
> doing so?
Not too much, but 2 things:
a) we should see if we can have it run fine in selinux enforcing mode.
If possible, we should deploy it enforcing.
I think that would work - I'm not sure if I've tried that since I
changed everything up for the package, though.
b) we need to add some nagios checks for the production instances.
What would be a good thing to check from the web to confirm that it's
answering and the db is good, it's updating, etc? Some applications
have a special /heartbeat/ url that outputs info, or we could just
scrape it from existing pages.
Pulling BASE_URL/APPLICATION_NAME/current will hit the database and the
application - it would usually respond with HTTP 500s if there are
major database or application problems (assuming the app is up).
As far as checking for sync, there isn't a wonderful way to make sure
that sync is working - there is a concept of "last sync time" that I
could modify into an endpoint with "elapsed minutes since last sync"
but there are several major sync-related issues which wouldn't trigger
that and checking for cronjob failure would be just as effective. The
only thorough way I'm aware of is to watch the logs and/or wait for
someone to notice that something isn't being synced properly.
Let me know if watching the cronjob would be enough or if I should add
the "time since last sync" endpoint