Hey everyone,
One of the proposed features for this iteration is Status Reporting.
There are four main components to it:
* Handling changes that happen on the backend provider
* Storing & displaying user actions
* Generating and exporting reports
* API to notify and get notified by external services (Matahari)
Below, I'll go over each of these and comment on what we have and what
needs to happen. At the end I wrote some features and tasks that I think
should go into Redmine.
Please, do speak your mind and write your suggestions and feedback in
this thread.
Out-of-band Changes
===================
Most of the functionality is already in place: when an instance crashes
or is stopped outside of Conductor, Condor picks it up and updates the
status accordingly.
Additionally, we calculate instance's uptime and as far as I could tell,
it's as accurate as we can reasonably get without running an agent
directly on the instance (hello, Matahari).
What's missing here is mostly the UI: Instance's uptime is not displayed
at all. We do show uptime for Deployments, but that one is not
calculated correctly, so that needs to be fixed.
It would also improve the user experience, if we updated these values
automatically -- without having to reload the page.
So when you launched a deployment, you'd get the deployment-details page
that shows its status as 'pending'. Once the deployment is running, the
status would change to 'running' automatically and the uptime would
start to count.
Doing this consistently across the app would be great but isn't trivial.
If we just hacked a JavaScript snipet for every time we needed this, it
would soon became a mess. Libraries like Backbone.js[1] should help, but
it takes some time and effort getting them in. Backbone in particular
isn't a drop-in solution. Others may be. Suggestions?
User Actions
============
Again, some of it is in place already: we have a model called Event that
is hooked to the `after_save` callback of Instance and it writes a
timestamped entry every time an instance changes.
What needs to be done here:
* Better UI
- Right now we show instance's history in the ugly & forgotten
instance#show page. It would make sense to make it look prettier, and
possibly display the events on the Deployment page for all its
associated instances.
* Make the event log persistent
When an instance gets deleted now, all events get deleted with it. What
we want to do instead is to hide the instance from the UI but keep it
and the events around so that we can still generate correct reports.
Matt Wagner suggested a couple of gems[2][3] that should handle this
pretty transparently. They're worth looking into as doing this by
ourselves could get tricky.
* More events as needed
Generating And Exporting Status Reports
=======================================
Right now, this will mean creating a simple CSV file that can be downloaded.
Possibly something like:
GET /conductor/reports
plus a way of accessing that from the UI.
The first implementation of this will be for admins only, thus no
permission checking is needed. Same goes for showing a history on a
single object: if you can see the instance, you should be able to see
its history as well.
However, we'll probably end up more granular ways of displaying the
data: for instance a user will want to see what happened with their
resources. Similarly, an admin may want to check history of a particular
user or a pool. Or seeing just the last moth's activity.
For this we'll need to add permission checks and some querying
capability + UI. That's out of this iteration's scope, though.
Matahari And Other External Services
====================================
Again, this is outside of this iteration's scope.
As we'll want to get notification from Matahari (and maybe other
services) we'll need a way to get notified about events that should be
logged but that Conductor itself cannot detect.
From talking to Matahari folks, it seems they need Conductor to let
them know when an instance was started and stopped.
If I understand it correctly, the whole notion of Config Server is to
have something that communicates with the in-instance agents (matahari).
Thus, we may want to hijack that and send the messages through Config
Server rather than directly.
This will save us the trouble of creating yet another communication
interface and discovering the matahari agents. Rather, we'll piggyback
on something that's already planned anyway.
As for other services notifying Conductor, this can be as simple as:
POST /conductor/instances/3141/events
So, like, fyi, that thingy over over here has changed.
Possibly with a timestamp in the request body so that we can log when
the event happened vs. when it was received.
However, this must be tied into whatever way we implement cross-module
authentication and authorization, otherwise everyone will be able to
create phoney events.
Features & Tasks
================
As a user, I want to see the uptime of my instances and deployments
* Display uptime of instances in the UI
* Fix the uptime calculation for deployments
As a user, I want to see Conductor always show the current status
without having to press <F5> every time
* Implement Backbone.js or some other system that will make this easy for us
* Dynamically update the instance/deployment status across Conductor
* Dynamically update the scoreboards in the Monitor section
* Dynamically show/hide errors as they unfold happen on the backend
* Periodically update uptime values so that they're always semi up-to-date
As an admin, I want to see a report of everything that happened to instances
* Generate a report of all the Events in a machine-processable format
* Add a download link for the report into the UI
* Make this available to administrators only
As an admin, I want to get the full reports even when the instances have
been deleted
* Make the event logs persistent even on instance deletion
* Preserve the data associated with the deleted object for events/reports
As an admin, I want to be able to query the status report to get to the
info I need
- note: this is probably out of scope for the Iteration 4.
* Filter by a specific timeframe
* Filter by a specific user
* Filter by a specific pool
As a user, I want to be notified on changes that happen inside of an
instance
- note: this is out of scope for the Iteration 4.
* Implement a way of communicating with Matahari
* Provide an API for getting event notifications from external services
As a user, I want to be able to see and query events of objects that I
have access to
- note: this is out of scope for the Iteration 4.
* Display the status reports filtered by user's permissions
[1]:
http://documentcloud.github.com/backbone/
[2]:
https://github.com/bdurand/acts_as_trashable
[3]:
https://github.com/technoweenie/acts_as_paranoid