Upgrade ignition version about ignition-docker HOT 8 CLOSED

@sanderd17, you correct in that the formal upgrade process isn't fully in place with the container. I have tested some upgrade scenarios and there are some issues that need addressed:

1. When you launch a newer version container (lets assume that you have preserved your gateway data in a volume against /var/lib/ignition, the system will appear upgraded, but all of the modules will still be the old version (since those are within your volume mount with the rest of your preserved gateway data).
2. I'm not sure that any db schema updates are being applied when the newer version gateway launches.

I think both of the above are possible to integrate handling for, but it isn't done just yet. Better handling for installed (and user-installed) modules and upgrades are on my list for improvements. I need to double check whether the gateway itself performs any schema upgrades when it sees an older version gateway on first launch. It very well might, which would just leave handling the Ignition modules properly as the remaining task for an upgrade.

Ideally, once everything is working as it should, you should be able to simply pull a new[er] container image and then destroy/recreate the container against the existing volume and you should be upgraded.

Thanks for the feedback and I'll work to push this toward the front of my queue. I appreciate the feedback of anyone else who might have any comments or suggestions.

from ignition-docker.

Alright, @SystemParadox and @sanderd17, version upgrades should now function. I have tested the following cases (albeit with simple, default gateways):

• Test Run newer version to older (aborts, disallowed)
• Test Upgrade from 8.0.0 to 8.0.2
• Test Upgrade from 7.9.8 to 8.0.2
• Test Upgrade from 7.9.11 to 8.0.2
• Test Upgrade from 7.9.8 to 7.9.11

I've set things up so that when the entrypoint script detects an older data volume (this will only work if you are setup with named volumes against /var/lib/ignition/data, as mentioned above), it will run the Upgrader class (as described in the zip installer README) and then take the appropriate follow-up actions (commissioning process on a 7.9.x->8 upgrade, etc). The upgrade process has been back ported to the 7.9 branch as well, so future 7.9.x maintenance releases should still be able to leverage the upgrade process.

As described in the updated docs, it should be as simple as just stopping/removing the old container and starting up a new[er] one (with the same volume).

Let me know in this issue if you have a chance to try this and have any feedback.

NOTE: I did try an upgrade from 7.8.5 to 7.9.11, and it seems to have worked--only strange thing that I encountered was that the wrapper log seems to be outputting DEBUG events. The ignition.conf isn't any different, so I'm not sure why that is at the moment. I didn't go super deep on it--I doubt many folks are going to be going that far back and trying to upgrade their containers. After all, you can always spool up a fresh one and bind-mount a gateway backup. Lots of options. 😎

from ignition-docker.

One other thing that I need to test is just having the volume pointed at /var/lib/ignition/data so that /var/lib/ignition/user-lib is handled by the image (this is where the modules subfolder lives). That might be a reasonable workaround at the moment, but we still need to handle user-installed modules.

from ignition-docker.

Looked at this a little tonight and wanted to leave a couple notes here. First thing, it seems that tying the named volume to /var/lib/ignition/data seems to be a workable solution for the most part. I tested creating a fresh container with an older image and then destroying that container and creating another one against a newer image (with the same volume mount) and everything started up right. By tying it to data, the user-lib folder upgraded with the newer image and everything appears to be working well.

I also took a look inside the image at some of the guidance left behind in the /usr/local/share/ignition/README file and it indicates that what I described above is likely to be a reasonable upgrade procedure, except for updating content in /var/lib/ignition/data/ignition.conf. It directs usage of the following command:

java -classpath "lib/core/common/common.jar" com.inductiveautomation.ignition.common.upgrader.Upgrader . data logs file=ignition.conf

I think that I can probably augment the entry point script to perform this adjustment when it detects an existing installation in /var/lib/ignition/data. The /usr/local/share/ignition/lib/install-info.txt file contains a gateway.version definition that I should be able to use. I might go ahead and have the .docker-init-complete file that the entry point script places in /var/lib/ignition/data be loaded with the Ignition version from the Docker Image so I can know when I need to run that upgrade process against the ignition.conf file.

I still need a good solution for handling user-installed modules though. With what I've described above, user-installed modules would be lost during an upgrade.

from ignition-docker.

Using a named volume for /var/lib/ignition/data works for the most part, but we've found that it sometimes causes issues if you change the version of Ignition. For example, upgrading from 7.9.4 to 7.9.10 resulted in an "incorrect number of arguments" error when trying to log in to any project.

My suspicion is that the project upgrade process is only run by the installer, or when restoring a backup.

It would seem that the safest way is to take a gateway backup, delete the old container, delete the volume, recreate a blank volume, start the new container and then restore the gateway backup.

from ignition-docker.

Some of the recent updates to add third-party module integration will help with this upgrade situation.. I still need to execute my suggestion above (related to running the com.inductiveautomation.ignition.common.upgrader.Upgrader when a volume with a previous version .docker-init-complete file is detected). Also need to further align the paths for the new zip-based install in 8.0.0 with the previous installer executable config from the 7.9.x images.

from ignition-docker.

Great job! I look forward to trying this out 😀

from ignition-docker.

I believe this continues to work well for folks, so closing this issue out. Thanks everybody!

from ignition-docker.