Nextcloud container version selected dynamically

[Narcolapser]

What this PR does / why we need it:

Allows for the Ansible-NAS community to manage multiple versions of Nextcloud with the hopes to allow everyone to upgrade to the latest version moving forward. So far the script will figure out the Nextcloud version of Nextcloud currently in use.

Any other useful info:

I've been toying around with the idea of setting up a system for doing upgrades with Ansible-NAS. But before I do a bunch of un-wanted work I figured I'd ask how exactly you envisioned Ansible-NAS working? I use Ansible at home and at work for maintenance. but Ansible-NAS seems to be setup primarily as an install script. Is that the way you want it or is the addition of maintenance features, like upgrading NextCloud to newer versions, a welcome addition?

[davestephens]

The "problem" is that Nextcloud's upgrades are totally manual.

What I want to do:

• upgrade to latest
• not break people using an old version

What I don't want to do:

• automate the nextcloud upgrade process

I think your detection is useful.

What I had in my head (and hadn't verbalised or documented anywhere):

• The nextcloud docker image gets parameterised, and set to the latest version (not latest- an actual version number)
• When the role runs, it errors if people are using something other than what the parameter is set as.
• User can decide what to do - manual upgrade, set the param to their version, etc

Thoughts?

[Narcolapser]

Good to know. I figured you probably had ideas in your head that weren't documented, I know I sure do.

Actually upgrading Nextcloud shouldn't be to hard in theory. I've manually upgraded NC as part of my experimenting with this. For the Docker based install the official upgrade process is to do one version higher than your current NC container. 14 -> 15, 15 -> 16. etc. So to upgrade to 20 from 14 will be 5 upgrades, but it is automatable (in theory, the exact ansible script is still very much so an experiment.)

But this kind of comes back to the question of "Is Ansible-NAS an installer or a maintainer?" Even if we were to make ansible scripts for upgrading things, Does ANAS tell you there is an upgrade? Does it provide a (y/n) option? Or are you expected to be aware of this yourself (some containers, like plex, will tell you there is a new version available.) and then you go in and change the group vars:

NexCloud_Version: 15

Something I was going to fiddle around with was creating a command line program to assist with ANAS tasks. So instead of having to remember ansible-playbook -i inventories/alfheim/inventory ./nas.yml -b -K you type "./ansible-nas.sh" or something and it asks "Run? Update? Change?" sorts of dialog questions. The ideal would be to setup a fancyshmancy web interface like YUNOhost or sandstorm, but making a little management script is definitely a much easier task to experiment on. Which is why I asked the above question, if you only saw ANAS as a setup to and not a maintenance tool, I'll make a new repo with this as a dependency. If maintenance tasks are welcome, I'll create a branch and send my commits upstream when I have something useful.

[davestephens]

The main thing for me is that Ansible-NAS is (mostly) idempotent. As in, you can run it 20 times and nothing should change. Those runs should be possible to do at different times, too, so we don't break people that dip in and out of the project.

On my personal setup I also run watchtower, which keeps things nicely up to date. I've been debating whether this should be installed as default, and I think I'll probably change that soon. I think in the few years I've run it, the only applicatiosn that barfed were Grafana, Cloudflare and Transmission, because they changed some security stuff in the container that required an extra env vars or something.

So in answer to your question of "is ansible-nas a maintainer" - yes, to a point, but through the process of "installing". It should set up a box so that it "just works" without having to knob about with it every few weeks, unless you want to of course. What I don't want to do though is build lots of automation for shittily designed applications like Nextcloud. I'd prefer the owners were pressured to design their applications properly, like everyone else on the planet seems to be able to do :)

[Narcolapser]

I've cleaned up the last of the linting errors. I had to add an exception to get it to allow the shell command usage.

At this point I think this is ready to merge, I'm not going to bother making scripts for upgrading, like you said, let Nextcloud deal with that. I think this approach works well though and I'll see if I can duplicate something like this for other applications. i.e. figure out what version you've got and ensure the correct container is requested. Maintains that idempotence as you said but also should allow for the default version for a new install to be the latest (instead of 6 versions behind).

I think the toy I want to build runs counter to what you want to build. One of those "not wrong just different" moments. I'll submit updates like this one as they are applicable to your project but then avoid dragging you down with junk you don't want to maintain. Cheers.

~TA

[davestephens]

I like the idea, but unless I'm missing something, this locks you into the version that happens to be latest the first time you enable Nextcloud in Ansible-NAS?

What about if we set a commented out nextcloud_version in the defaults, which can override what is detected from version.php when enabled?

[PurpleNinja225]

I know it might be some effort to maintain but now that apps are moving to roles couldn't we just have a roles/nextcloud/ and under that have

nextcloud-14
    defaults
        main.yml
    tasks
        main.yml
nextcloud-15
    defaults
        main.yml
    tasks
        main.yml
nextcloud-16
    defaults
        main.yml
    tasks
        main.yml
nextcloud-17
    defaults
        main.yml
    tasks
        main.yml
nextcloud-18
    defaults
        main.yml
    tasks
        main.yml
nextcloud-19
    defaults
        main.yml
    tasks
        main.yml
nextcloud-20
    defaults
        main.yml
    tasks
        main.yml
etc

It would be a bit of work to implement, but after that all the older versions are done so they won't likely need to be touched again. This way we can write up documentation on a way to upgrade to more up to date version (if users want to).

[Narcolapser]

@davestephens Yes, it would lock you into the latest version if you are making a fresh install. But I don't see that being a common use case. So I would say leave as is until the hypothetical becomes a reality and some one asks for the ability to specify version. Edit: the reason why I hesitate is that Ansible's variable system is kinda funky. If you put registering a variable with a conditional so that it only runs when under certain conditions, that variable still gets registered (or overwritten) with a little notice that the step was skipped. That's why I had to do what I did in what is basically an exception handling block. It is annoying to work with.

@PurpleNinja225 This approach may be necessary for some of the other apps. I don't know if ascertaining version will be as easy as parsing a file for everything, and so more through and creative methods will need to be used. That being said it does introduce a lot of redundant work. For Nextcloud it doesn't appear to be necessary. Now if an app has different docker commands for different versions that would necessitate the multiple roles approach.

[davestephens]

Sorry for not getting to this sooner. Whilst I like the idea of this, I'm still not sold on the approach.

What we need is essentially this:

• New users get latest, and watchtower keeps them up to date.
• Old users get warned they are on an ancient version, and need to do the daft hoop-jumping dance.

I believe that NExtcloud would error if you tried to jump more than one version, so I'm minded to say just set it to latest but allow the image to be configurable. That way, people can do the upgrade themselves if they want to.

Thoughts?

[davestephens]

I've updated Nextcloud image to default to stable. If users want to they can pin to specific versions, but this PR is now no longer required.