Open dpwrussell opened 8 years ago
I've done some work in our Ansible repo on OMERO.server: https://github.com/openmicroscopy/infrastructure/pull/61
using our omego
helper utility: https://github.com/ome/omego
There's a lot of conditionals in there to ensure idempotency, but it has crossed my mind that an OMERO Ansible module/library would be useful, e.g. importing omego
instead of running it as a command line app.
I think the best solution to this could be a new command
exists
for things which are lists.For the
omero.web.ui.top_links
example:omero config exists omero.web.ui.top_links '["Figure", "figure_index"]' omero config exists omero.web.ui.top_links '["Tag Search", "tagsearch"]'
...
Noted. Thanks.
Plugin scripts are installed with
upload
and then replaced withreplace
. This is fine when doing things manually, but when using config management, it has no way of knowing what to do. If you runupload
every time this results in the original script not being replaced. On the flip side, even if the script is already installed, it can't be replaced without some nasty bash foo to get the ID.
Have you tried just putting it into its location?
mv my_script.py $OMERO_DIST/lib/scripts/my_script.py
Using the regular ansible move logic, this should be idempotent. Add a handler "if moved, then run bin/omero scripts list".
Finally, if Ansible is what we are all using, then perhaps an action plugin or module could be developed (perhaps making use of underlying idempotent commands with nice return types) so that one could do something like:
...
In general, definitely a good idea. If anyone has suggestions on concrete actions, we'd love to see them.
Cheers, ~Josh
@joshmoore
Have you tried just putting it into its location?
I did try variations on this, but in the end I decided not to do that because in the end you have to fall back on the bash foo. This happens when:
This is working for now until an idempotent configuration becomes available.
This happens when:
- The script has been installed.
- The server is then rebuilt from scratch
- The file is now missing, but the script is installed in the database, so you need to then determine if it should be moved into place, or if it needs to be installed.
I still think it'd be safe if using cp
to just always put it into place. The server will know if it's been changed or not.
The only other alternative I can provide before a full solution is use of git. lib/scripts
contains a .git
directory. Assuming there are suitable ansible modules for git, you should be able to come up with a merge workflow that will provide you what you want.
Long-term, I'd like to see a registry in the server where you register locations using exists
(above) and the server automatically copies them on startup.
The cp
would be ok if you assume you're never building a server from scratch (I.e. has never had the script installed) as in this case it has to run the install
with --official
etc.
I think the way it's working in our ansible configuration at the moment is fine, it was just a good example of something that was hard to deal with idempotently.
The cp would be ok if you assume you're never building a server from scratch (I.e. has never had the script installed) as in this case it has to run the install with --official etc.
I disagree. You can still simply cp the file into place. That counts as an "official installation".
I think the way it's working in our ansible configuration at the moment is fine, it was just a good example of something that was hard to deal with idempotently.
Can certainly understand that if something is working you don't want to change it!
@joshmoore Ok, I think I understand what you are saying now after some experiments.
I thought that the omero script upload
step was necessary to register the script with the database, but I see now that OMERO is monitoring this directory and assigning IDs to anything it finds which is new or has changed since the last time since it was assigned an ID.
I might do this as it's a lot simpler. Thanks.
During our recent ansible configuration of OMERO I had to do some less than desirable things to make it work because some of the configuration can not be done idempotently.
Examples:
When configuring
omero.web.ui.top_links
it is not possible to useappend
because this will result in (after multiple runs) repeated entries, so instead it is necessary to useset
which necessitates specifying all of the defaults (which could easily change with a new OMERO version).I think the best solution to this could be a new command
exists
for things which are lists.For the
omero.web.ui.top_links
example:This one could probably be configured by manipulating XML instead, but as that is not the recommended way to do these changes then I think this makes more sense. Here is another example which could not be done that way though.
Plugin scripts are installed with
upload
and then replaced withreplace
. This is fine when doing things manually, but when using config management, it has no way of knowing what to do. If you runupload
every time this results in the original script not being replaced. On the flip side, even if the script is already installed, it can't be replaced without some nasty bash foo to get the ID.I'm not certain what the best way to fix that one is. Perhaps a command that is not based on ID like
replace_or_install_script_at_location
or something.It would be really nice to be able to have any idempotent commands return values be such that config management could determine if something has
changed
or not.Finally, if Ansible is what we are all using, then perhaps an action plugin or module could be developed (perhaps making use of underlying idempotent commands with nice return types) so that one could do something like: