Proposed by: CUNY School of Professional Studies / New York City Office of Emergency Management
Contact (name, email, irc, skype): Chad Heuschober, chad.heuschober@mail.cuny.edu, chadheus@freenode, cunychad
Best way and times to contact during RHoK 2.0 Dec 4/5 2010: email, available most other means late mornings through evenings EST
Most emergency management organizations have a series of pre-defined processes, tools, and roles. For an application to be a viable option, it must be configurable to the point of enabling organization-specific modules to be installed and maintained independent of other system modules. This problem supports the creation of a symfony module manager and the changes required to the UI menu to enable, disable, install and potentially upgrade Sahana Agasti modules.
The City of Bob uses a proprietary hospital management system known as BobHealth developed in Fortran over thirty years ago. Their operational plan for a biological attack requires Sahana Agasti to interact with BobHealth. As a result, the City of Bob develops an agBobHealth module for Sahana Agasti. Because the City of Bob doesn't wish to fork Sahana Agasti and wants to be able to benefit from global Sahana Agasti updates, they need a system to manage their module independently.
The agBobHealth developers, following a series of pre-defined metadata and packaging guidelines create an agBobHealth package that works against the current Agasti Mayon version. A City of Bob (CoB) administrator downloads the module, signs into Sahana Agasti, and goes to the module management page. There, the systems staffperson uploads the module which undergoes a sanity check before asking for an installation confirmation. Once confirmed, agBobHealth is installed in a disabled state. To see what the package actually did, our diligent sysadmin dials into a terminal, checks the Agasti folder structure, and notes that the package is self-inclusive, even post-install, with all the relevant files still in one location. Returning to the Agasti screen, our sysadmin refreshes the module manager to see that the agBobHealth module is installed, that is it currently recognized by the system as being version 1.0, and is disabled. The sysadmin clicks a link to enable the module and the plugin is enabled with changes reflecting in the system menu, where module features and sub-features can be accessed as well as the module management page where the module is now shown to be enabled.
Following its installation, the BobHealth Administrators started noticing major performance problems. It turns out that agBobHealth had a bug and was querying BobHealth thousands of times per second. Since Sahana Agasti and BobHealth both have duties outside of their integration and BobHealth needed to keep its API open for other consumers, the Sahana Agasti administrators agree to temporarily disable agBobHealth until the bug can be fixed. The Sahana administrator returns to the module management screen and disables agBobHealth. Immediately, all agBobHealth functions stop and BobHealth is no longer under high load from Sahana Agasti.
The agBobHealth developers work all night to develop a fix. They soon find the missing comma and send a new version of agBobHealth along, version 1.1. The system administrator returns to the module management screen and uploads agBobHealth 1.1. The system checks for agBobHealth and discovers that a previous version exists. It asks the administrator if he or she wishes to upgrade agBobHealth from v 1.0 to v 1.1. The administrator agrees, and the system continues with the upgrade, porting any relevant agBobHealth configuration or settings from agBobHealth 1.0 to agBobHealth 1.1.
Upon upgrade completion the module manager still lists agBobHealth as disabled but shows the new version number (1.1). The administrator re-enables the agBobHealth plugin and the old features, and new ones appear.
To fix the issues in agBobHealth 1.0, the agBobHealth developers disabled a key piece of functionality that resulted in the bug. A user with administrator privileges, unaware of the 1.0 bug, has noticed that this functionality is missing in agBobHealth 1.1. To solve this the user attempts to "upgrade" to agBobHealth 1.0 using the module manager. When the user uploads agBobHealth 1.0 the Agasti module manager version and sanity check sees that agBobHealth 1.1 is already installed and fails the upgrade, informing the user that regressions are not allowed.
Because agBobHealth proved to be so popular, it saw several months of strong development and was developed up to version 1.4 with a 2.0 version on the horizon. At that point, a talented developer realized that agBobHealth could also be used to syndicate BobHealth data to the City of Bob's Medical Examiner's Office. This developer creates agBobHealthMe to satisfy this need.
The Sahana Agasti administrators in the City of Bob think agBobHealthMe is a great extension for their functionality and decide to install it. Upon module upload, however, they are told that because their agBobHealth version is only version 1.1, they can't install agBobHealthMe. Not wishing to upgrade more than is necessary the CoB administrators grab the newly released 2.0 version of agBobHealth and install it. Unfortunately their Sahana Agasti installation is rather old and, when they attempt to install agBobHealth 2.0, they are instructed to upgrade it. Following successful upgrades of Sahana Agasti and installation of agBobHealth 2.0, they attempt to install agBobHealthMe only to discover it doesn't recognize agBobHealth's version (v2.0) and can't install. Realizing they should have read the release notes in agBobHealthMe, they return to the files to discover that agBobHealthMe only works with agBobHealth versions 1.3 through 1.4.
Knowing that they can't regress, the administrators return to the backups they made prior to the installation of agBobHealth 2.0. This time the administrators install agBobHealth v1.4 and, upon attempt, realize they have satisfied the dependency requirements of agBobHealthMe.
In version 1.4.2, agBobHealth introduced a bug that forced administrators to disable it while an update was being prepared. While disabled, agBobHealthMe, as a module dependent on agBobHealth, was also disabled until the bug was fixed and agBobHealth was brought back online.
Deciding there was no reason to develop two different branches, the developers of agBobHealth and agBobHealthMe decide to merge their code into the upcoming agBobHealth 2.1 release. Since this release will not work with agBobHealthMe, the administrators must uninstall agBobHealth me. They go to the module manager and click the uninstallation button of agBobHealthMe. They are asked to confirm their selection, which they do and, as a result, agBobHealthMe is removed from the Sahana Agasti installation, it's folders destroyed, and the tables it owns, dropped from the database.
Modules must live in their own directories and have their own data tables (without changing existing table structures). Modules must also be aware of their versions and version dependencies with other Sahana Agasti versions and core components.
To participate:
The Agasti Mayon trunk can be found on Launchpad at: https://code.launchpad.net/~sahanaphp-committers/sahana-agasti/mayon
Documentation for Agasti Mayon can be found at: http://wiki.sahanafoundation.org/doku.php/agasti:mayon:start
More information about Agasti Mayon and links to other resources can be found at the official documentation wiki with special note given to the Mayon 911 page.[1]
Sahana Agasti is an open-source PHP-based disaster management software registered by the Sahana Software Foundation, first created in response to the 2004 Tsunami, and used by emergency management organizations and grassroots organizers alike to coordinate preparedness, response, and recovery tasks throughout disaster operations. Used by the New York City Office of Emergency Management (NYC OEM), and supported by development efforts from the City University of New York School of Professional Studies (CUNY SPS), the National Library of Medicine, Respere, and an international community of developers, Sahana Agasti is an internationally recognized platform for disaster operations management.
The Agasti Mayon (2.0) branch is currently being headed by the CUNY SPS team, a subset of whom will be actively participating in RHoK #2 to try to merge any solutions directly into the Mayon trunk. The CUNY SPS team is also supported by their partner, the New York City Office of Emergency Management who is slated to be the first active installation of the Agasti Mayon in 2011.
All Sahana Agasti projects are registered under the Sahana Software Foundation (SSF). For more information about the SSF, please see: http://sahanafoundation.org/
Sahana Agasti Mayon is developed in Symfony, meaning that it is largely a modular design. Additionally, the database is developed in as-close to fourth normal form as possible, meaning that data tables should not require adjustment to extend functionality in modules. Also, the schema definition files have already been separated into modules (see http://wiki.sahanafoundation.org/doku.php/agasti:mayon:schema) so it should be relatively simple to separate the bundled pieces. Of more difficulty is adjusting the menu system to be more dynamic, and setting up dependency detection.