[ome-users] OMERO at big sites - delegated administration + an interesting object-storage idea.

[Josh Moore]

On Thu, Jun 18, 2015 at 12:32 PM, Jake Carroll <jake.carroll at uq.edu.au> wrote:
> Hi list!

Hi Jake. Good to hear from you ... you've been busy!


> We’re running OMERO at a fairly large scale now (big ingest, lots of
> instruments, plenty of IO and lots of compute cycles) across a significant
> network. We’re (as Jason alluded to in a previous post) doing things at a
> cloud scale with OMERO, which, still seems to be a bit unusual from what I
> have found.

You've certainly got everyone interested.


> Anyway..
>
> One thing that has come up recently is the notion of delegated
> administration. Here is an example.
>
> Org Unit “A” is the controller/unit that runs an OMERO platform. It has lots
> of users and is the main provider of the OMERO platform.
>
> Org Unit “B” says “hey…that is darn cool. We’d like some of the OMERO love,
> too! Can we join you?”
>
> Org Unit “A” says: “Of course! We share the love, and we love OMERO!”.
>
> In our LDAP binds we then allow said org unit access. But, I got to thinking
> a bit further afield about something better or even nicer. I liked the idea
> of multi-tenancy with my omero-cloud instance. Further, I liked the idea of
> my delegated administrators (as I like to call them) being in control of
> their own destiny, and to an extent, their users, such that, on a large
> omero instance, you’d have an effective waterfall model of administrative
> chains.
>
> OU “A” can oversee it all.
>
> OU “B” has some selected administrators that can access/modify/work with the
> OU “B” users who belong to that bit of the LDAP container (or some other
> access control mechanism).
>
> It would sort of make OMERO very multi-tenancy savvy in many respects.

Certainly, this depends on what exactly is meant by "control",
"administrate", etc. but I'd assume that with the group mappings[1] in
introduced in 5.1.2, you'd be able to perform at least *some* of this.

Assuming all groups are managed by LDAP, then the logic would be
something roughly equivalent to:

 * all admins of UnitA are set as owners of all groups
 * all admins of UnitB are set as owners of UnitB groups

which I think would be doable with an OR-query.


> Further, with regards to OMERO.fs, it would be really ideal to be able to
> prefix or specify in the backend multiple points of IO exit for the omero
> data storage location. Such that the omero.data.dir variable could equal or
> have multiple backends for different OU’s from the same OMERO instance. This
> would both logically and physically compartmentalise the OMERO data domain.
> [Which could be a good thing for more reasons than one, much less IO
> scheduling and performance characteristics at a filesystem level, for
> different omero workload types].

There are a couple of things here. There are a number of things stored
under ${omero.data.dir}, and it would be good to know what's causing
the most trouble. The easiest to compartmentalize as you suggest is
${omero.managed.dir}. That would cover the bulk of the READs and
WRITEs *except for* Pyramids, which would then also need to be moved
to the managed directory.

If the OMERO4 /Files or /Pixels directories are causing issues, this
will be substantially more work as would be the case for /FullText.


> Finally, I have been speaking with a colleague at Harvard about the
> semantics of parallel filesystem access, scale and the limitations of POSIX.
>
> You know what would be really cool? If we could create an object-store
> provider backend for OMERO to tape into object storage APIs. I really
> *really* like the idea of being able to natively target OpenStack SWIFT
> buckets, Amazon S3 buckets and native Ceph-RADOS-gw stores. Thinking out
> loud, there is huge potential to scale omero in the cloud further, massive
> potential for data reuse and even further extensibility benefits we can
> derive from scaling out like this.

Agreed, but again this is equivalent to the "substantially more work"
from above.


> Just a few thoughts. Apologies for the idea overload. Just needed to get it
> down on the page for the list to think about/ponder and tell me “We’ve
> already done that Jake, don’t worry…it is in the pipeline for 5.2 or 5.3”
> etc.

No worries, always good to have. A tl;dr summary might be:

 * LDAP: possibly already in 5.1.2

 * Redirecting managed.dir: conceivable in 5.1, help/testing on your
part appreciated.

 * New IO backend: was the original priority for 5.2, but we know how
those change.


> Talk soon.
> -jc


All the best,
~Josh

[1] https://github.com/openmicroscopy/openmicroscopy/pull/3798