ome / ansible-role-omero-web

Installs and configures OMERO.web and Nginx
BSD 2-Clause "Simplified" License
1 stars 14 forks source link

Upgrade OMERO.web automatically #11

Closed manics closed 6 years ago

manics commented 6 years ago

omero_web_upgrade is now an internal variable that should never need to be set in normal usage since it is possible to determine whether an upgrade is needed by checking the latest version on downloads. omero_web_release: can be set to present, latest or a fixed version This matches the behaviour of the omero-server role.

Closes #7

joshmoore commented 6 years ago

Restarted (failed on downloads.o.org)

joshmoore commented 6 years ago

Proposed as 1.0.3, 1.1.0, ... ?

manics commented 6 years ago

I was thinking to treat it as a breaking change since the default behaviour has changed from never upgrade to "do the expected thing based on the release specification". See https://github.com/openmicroscopy/ansible-role-omero-web/pull/13

joshmoore commented 6 years ago

So 2.0.0 like the bump in https://github.com/openmicroscopy/ansible-role-omero-server/pull/18 ?

Certainly the code changes look sensible.

jburel commented 6 years ago

I have tested this PR to upgrade demo by running ansible-playbook --ask-become-pass playbooks/ome-demoserver.yml -i ../ansible/inventory/prod-hosts --extra-vars omero_server_upgrade=True --diff The --extra-vars omero_web_upgrade=True is no longer needed. Everything went smoothly

joshmoore commented 6 years ago

Is the idea to include gh-8 now in 2.0.0?

manics commented 6 years ago

Potentially. We can discuss.

manics commented 6 years ago

How about release this is 2.0.0 since it's only technically a breaking change and is a straightforward upgrade, then another breaking change for #8?

sbesson commented 6 years ago

Reading this, my main concern is about the proposed 1.0.0 -> 2.0.0 -> 3.0.0 sequence in a very short amount of time. If we start breaking our role API too often, I do not expect potential consumers or even to be able to follow our pace. That being said, if we would like this change to get released to roll it out into a few deployments, would it help to release it as 2.0.0b1 (this should prevent the PEP versioning issue we encountered last time) and plan a 2.0.0 that also includes #8? Would this new version be bumped in IDR? prod-playbooks?

manics commented 6 years ago

There's no benefit to the IDR from this PR because the IDR OMERO version numbers are unrelated to the output of omero version.

In terms of breaking versions I'd treat #8 as breaking because it's a major change to how the role works and it will only work with 5.4+. However from a user's point of view the current role parameters for modifying the generated omero-web.conf are non-existent, so it should be possible to implement with no API change.

joshmoore commented 6 years ago

After discussing with @manics @kennethgillen and @sbesson, merging for 2.0.0 though this may not immediately be bumped across our requirements files. (See 1.0.3 if a non-breaking change is needed)