[ome-devel] OME up-and-running, initial feedback

[Chris Allan]

On Tue, Jan 11, 2005 at 09:21:43AM +0000, Graham Klyne wrote:
> Hi,

Hi Graham.

> 
> I'm typing these notes now while the experiences are relatively fresh in my 
> mind.  I've not yet seen any attempt to use the system in anger (i.e. on 
> real microscopy data).  I'm a software engineer, not a bio-researcher, by 
> background, so I don't yet know about the microscopy application 
> requirements.  My prior Linux experience is merely moderate, and I'm 
> thoroughly confused by Perl.
> 
> ...
> 
> Software version:  I've currently installed the latest stable release 
> (2.2.1.1, IIRC).  The host is Fedora Core 2 running under VMware 4.5.2., 
> with automatically supplied updates (e.g. bringing Postgresql to the level 
> of FC3).
> 
> ...
> 
> Installation:  getting all the dependencies right was a bit of a fiddle, 
> but the installation script was pretty helpful.  But when things fail, they 
> seem to do so fairly messily.  For the most part, the installation script 
> could be re-run many times without problem, which was something of a 
> blessing.  It would have been nicer if answers already given would be 
> remembered in case of installation failure.  I had problems with modules 
> not mentioned in the INSTALL.redhat file:  maybe it would be helpful to 
> place a note in this file directing new users to the up-to-date online 
> version?

Changes have been made to INSTALL and INSTALL.RedHat along the lines of
the issues you've had. These two files will go out in 2.4.0 (fastly
approaching now) and should be available for inquiring minds on the
website tonight.

> 
> It would be good if the installation script could check early on if the 
> PostgresQL database is running -- I had several failures due to forgetting 
> to start it.
> 
> One problem I experienced was running out of disk space when trying to 
> import a batch of images.  There were no diagnostics indicating what had 
> happened, and it left the database un-restartable.
> 
> After installation, I tried to change the directories used for PostgresQL 
> and OME files.  The former was very easy, but when I moved the other files 
> there seemed to be "hard-wired" directory references left in the 
> database.  I'm not really surprised by this, but given the 
> disk-space-intansive nature of OME it would be nice if it there were a 
> clear way to move data to (say) a new, larger disk.
> 
> I found it wasn't very clear where the OME system itself resides:  the 
> running system seemed to use a combination of the original directories from 
> which it was installed, and new directories under /OME.  I think the 
> default installation would probably be better to not have /OMEIS a 
> subdirectory of /OME -- when I install a live system, I expect I shall 
> place /OME on the root volume, in (say) /usr/OME, and /OMEIS, along with 
> the postgresql data, on a separate volume (say) /usr2/OMEIS and 
> /usr2/OME/pgsql.  The idea would be to separate programs (which generally 
> don't grow) from data (which is expected to grow like topsy).  Default use 
> of symlinks in the software install directory might be one way to ease the 
> data moving problem mentioned previously.

We deploy on Unix systems for just these types of reasons. Symlinks are
your friend. Scattering OME object code, configuration and dependencies
throughout the filesystem isn't something we want to do, or have the
resources to support. If you're sophisicated enough to be deploying OME
on a system that requires your OMEIS repository, for instance, to reside
on a totally seperate filesystem, we generally assume you are
sophisticated enough to run:

mv /OME/OMEIS /usr2/OMEIS; ln -s /usr2/OMEIS /OME/OMEIS

> 
> A brief section about disk/directory layout in the INSTALL file would be 
> helpful.  (Comments about directory/disk layout from folks experienced with 
> using OME would be appreciated.)
> 
> ...
> 
> When importing image files, I found the running system seems to require 
> that apache has write access to the directory+files from which they are 
> imported.  The install script suggests read access is enough, but following 
> importation I  saw the file creation times (ls -cl) were updated.  It 
> seemed that importation would fail with file-not-exists errors until apache 
> had more than just read access to the files (I say seemed, because it may 
> be something else that fixed the problems I was seeing.)

Not sure exactly what you mean, but Apache certainly does not need write
access to your import directories or the files that reside in them. The
"-c" flag to ls also does not list creation times, it lists status
change times, which include but are not limited to:

* Modifications to content
* Modifications to permissions
* Modifications to location (ie. "mv a /tmp/a")

Directories on Unix systems also need the execute bit set on them in
order to be listed. Are you sure you have these set?

> 
> ...
> 
> In use, I found the user interface wasn't immediately obvious.  Mainly, I 
> found the command links below the summary bar were not obvious:  a row of 
> buttons along the top of the window would be more menu-like.
> 
> Also in use:  for testing, I imported a small collection of my own photos 
> (from a digital camera), converted to TIFF (I recognize this isn't what OME 
> is designed for, but I needed to test *something*).  It's not clear to me 
> what kind of processing takes place during import... is there any 
> documentation about this?  (I didn't see any.)  The imported images seemed 
> to me to be too dark.  Also, when viewing them, I didn't see any way to 
> change the scale at which they were viewed, and there was no way to pan 
> large images.  I had also hoped that more camera metadata from the TIFF 
> file would be captured and displayed.  Am I missing anything here?
> 
> Beyond that, I assume that other processing is whatever the researcher may 
> want, and is supplied in the form of additional "plug-in" modules.
> 
> ...
> 
> So that's roughly where I am.  My next steps are to figure out how people 
> will actually use this software in a research environment, and proceed to 
> plan a "live" installation.
> 
> #g

Ciao.

-Chris