Proposal for refactoring ansible OMERO roles. #73
Conversation
manics
force-pushed
the
ansible-omero-server
branch
from
d3eb36a
to
6eee6b8
Compare
manics
force-pushed
the
ansible-omero-server
branch
from
6eee6b8
to
ac3d1be
Compare
manics
changed the title
There was a problem hiding this comment.
Overall, the proposal reads well and makes sense to me and mirrors the ongoing strategy of decoupling the server and the Web client to the deployment level. A couple of inline comments with regard to the proposed implementation.
Do we have concrete immediate use case where the proposed role decoupling might be beneficial and could help drive the next steps e.g. do we have need for a Web-only release?
| This includes installing and configuring both OMERO.server and OMERO.web, and although OMERO.web can be disabled it is not possible to install OMERO.web only. | ||
|
|
||
| Further more this role bundles `omego` which could potentially be used independently of this role. | ||
| In addition Ansible 2.2 has a bug which means `omego` is installed into the wrong virtualenv, breaking the role. |
There was a problem hiding this comment.
👍 for decoupling omego which already has its own lifecycle in any case
ansible-omero-roles.md
Outdated
| ### omero-common | ||
| - Create an `omero` system user | ||
| - Create `/opt/omero` as the parent directory for all OMERO components | ||
| - Possible: Include `omero` and `omero-web` restart handlers so other roles can restart the server or web. |
There was a problem hiding this comment.
Only concern here is that omero-common conflicts with the name of a components of OMERO.server. Alternative suggestions: omero-base, omero-server-base
There was a problem hiding this comment.
Naming ... I think something that indicates it's not just for the -server would be good.
There was a problem hiding this comment.
Definitely, esp. if we consider the case discussed in #73 (comment) i.e. that we could consider creating different users for different OMERO components
There was a problem hiding this comment.
If we've got separate users for each component I think that should be delegated to the role responsible for that component.
There was a problem hiding this comment.
omero-component, omero-service, omero-instance, ...
There was a problem hiding this comment.
Thinking about it, if web and server have separate users, and all components are decoupled so there's no point in having common variables, then maybe this common role isn't needed.
ansible-omero-roles.md
Outdated
|
|
||
| ### omero-omego | ||
| - Install omego into a virtualenv: `/opt/omero/omego` | ||
| - Alternative: install `omego` globally and name this role `omego` |
There was a problem hiding this comment.
The latter would be my preference. Although it is absolutely correct that most of the development of omego has been driven in the context and for OMERO, I still believe some of its usage could be used outside it.
There was a problem hiding this comment.
I agree a global installation with pip is the easiest, especially if other people are expected to run it manually. The advantage of a virtualenv is it minimises the number of non-distribution-packaged python modules, especially if web runs from a virtualenv. Ice is probably the main exception.
ansible-omero-roles.md
Outdated
| - Alternative: install `omego` globally and name this role `omego` | ||
|
|
||
| ### omero-web | ||
| - Parent directory: `/opt/omero/web` |
There was a problem hiding this comment.
Would that need a separate user or would this reuse the common role with the omero user.
There was a problem hiding this comment.
Good question. Reusing the omero user is convenient and what we currently use. From a security perspective it'd be more secure to run web as a different user since it shouldn't require access to omero.data.dir.
There was a problem hiding this comment.
👍 for each component/service/whatever having its own user (if feasible)
|
There's an IDR-0.3.4 card for deploying web on a separate VM to see if that improves performance. |
|
Updated following comments. One more thing that springs to mind: |
|
That won't suffice for the server but for the web and general use, but it's probably simplest to just let web install its own, and if we ever need a role for just |
|
👍 for pushing through the implementation. It leaves a question for me of what to do with the design proposal. (i.e. should it have been merged before the implementation, etc) |
|
With tagging going on today, just making a call and merging this so it's in the history. We'll need to review that though as more designs are merged. |
No description provided.