On Wed, 24 Apr 2013 14:11:00 -0600 Kevin Fenzi kevin@scrye.com wrote:
On Wed, 24 Apr 2013 11:06:47 -0600 Tim Flink tflink@redhat.com wrote:
The blocker tracking app [1] has been in staging [2] 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
Tim