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

Labels Webapp:

• Number of users: 1 at any one time
• Hours of use during the day: 8:00 to 17:00
• Peak or sensitive periods: None.
• Level of activity. Fifty transactions per week if recruiting 50 participants per week,
• Quality of service:
  1. Speed of response: within 10 seconds.
  2. Speed of restore after a failure: ?
  3. We cannot afford to lose transactions, which would give rise to the possibility of duplicate id's.
• Type of data: Transactional.

caTissue:

i2b2:

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: Labels Webapp, 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.