Moving the blocker tracking app to stable

[Tim Flink]

On Wed, 24 Apr 2013 14:11:00 -0600
Kevin Fenzi <kevin at scrye.com> wrote:

> On Wed, 24 Apr 2013 11:06:47 -0600
> Tim Flink <tflink at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130424/75ab47bb/attachment.sig>