LAMP Proposal

A draft spec for the BRICCS services is attached at the end...
Discussion points, not in any particular order:

Live Production Systems

Following details are required:

• Number of users
• Hours of use during the day
• Peak or sensitive periods
• Level of activity (transactions per day)
• Quality of service
  1. Speed of response for a user
  2. Speed of restore after failure
  3. Can we afford to lose transactions?
  4. Turn around time for a support request. _Advice please on this one_.
• Type of data stored and usage. I'm not sure how to characterize this. What about:
  1. Transactional
  2. Research

These are my guesses so far for...

Labels Webapp:

(The Labels Webapp and the UIDGen have been moved to the hospital environment.)

caTissue:

• Number of users: 10 at any one time. (At the moment there are only three)
• Hours of use during the day: 8:00 to 17:00
• Peak or sensitive periods: None.
• Level of activity. 300 transactions per week?
• Quality of service:
  1. Speed of response: within 5 seconds.
  2. Speed of restore after a failure: ?
  3. We cannot afford to lose transactions, which would give rise to losing the locality of samples.
• Type of data: Transactional

i2b2:

• Number of users: ?
• Hours of use during the day: 8:00 to 17:00 by clients. However, it is possible updating/inserts into the system might become an overnight batch task.
• Peak or sensitive periods: None, but reference the above.
• Level of activity: ?
• Quality of service:
  1. Speed of response: ?
  2. Speed of restore after a failure: ?
  3. Some client side activity is transactional: System admin at least. What about batched updates/inserts?
• Type of data: largely Research.

VM's and Applications

To keep applications separate, it would be a good idea to have one application per VM.

Is this a good idea? Can anyone see variations on this? For example:

• Does it apply to test systems?
• Does it apply to dev systems (eg: TRAC, svn)?

Managed versus Capacity only Systems

This is my (Jeff's) understanding of this. "Managed" is seen from an RCS point of view. That is:

• A "Managed" system would be one administered by RCS.
• A "Capacity Only" one is seen as being administered elsewhere. RCS supplies only the capacity.

I'm not sure exactly what this would mean in practice. Perhaps it's just a rule of thumb. But there are important considerations behind this...

• Will the live production systems (eg: caTissue, i2b2) be administered by RCS? If not BRICCS must supply the admin side of things.
• The level of admin might need to vary. Take test systems. This could be Unit testing, Integration testing, or Acceptance testing. I can see this range of testing being required where the admin side of a live system is complicated. See next point.
• Whoever manages the i2b2 data warehouse (University or UHLT), the live systems cannot be administered in isolation. The two systems must be synchronized in some way. A failure on one side will have ramifications for the other.
• The i2b2 side can support numbers of projects and within a project, numbers of ontologies. What constitutes a project is open to debate, but a good first idea is to take a source/stream of data (eg: the Onyx questionnaire) as a project. Now each project has its own set of SQL tables, and each ontology within a single project can have one or more ontology SQL tables. So one could expect over time that a live system would change the number of SQL tables within its remit, which would suppose some DBA activity. Who would own that activity?

I cannot see a simple way through this wood at the moment. If I were asked to administer a system, I would like to have some say before I took it over, even if it were only to vet and test the procedures.

Acquisition of VMs

It seems unlikely there will be creation and access to new VM's on demand. So there would need to be some forward planning of what is required for a given future period.