userdata directory contains instance specific configuration

[FlorianSW]

One reason why one would use docker is to separate the application from the data produced and used by this application. That means, that I can, e.g. with docker, create a "volume" with application specific data and store it somewhere (a persistent data storage), while I can simply create a container with an image of my application, starting it with the data volume and voila I've a running and functioning instance of my application.

This, however, requires a setup where data, that needs to be stored persistently, is strictly separated from the data and files that are only present to support the application or the application code itself. However, this is not entirely true for the openHAB docker container.

The volumes, included in the openHAB docker container, includes the userdata directory, too. However, there're also directories in thie userdata directory, which are used as temporary and cache directories (e.g. userdata/tmp, which is KARAF's temp directory). The files and data stored there is highly instance specific. That means, if I re-create the image (using another version of openHAB) or moving it to another host or whatever, where I've to re-create the container, the container may start, but it's possible (especially when upgrading openHAB), that it is not working well, as old files are present in the tmp and cache directory.

However, the solution may sound easy: Do not include userdata/ as a volume and let the files be in the container. That isn't a very good solution, too, as some addons (e.g. openhabcloudconnector) may create data in userdata which, by definition, identifies a specific instance, but the user expects these files to be persistent. That's why they need to be in the data storage and not in the container itself.

The solution could be:

• Having the userdata/ volume split into different volumes, where only the directories are included, which contain real data
• Having the OH entrypoint delete the instance-specific data at any restart -> This may, on the other hand, make the start of the container slower.

[cniweb]

Would not it be better to separate the instance-specific data in openhab itself?
@kaikreuzer Are not there already considerations?

[FlorianSW]

That would be the best (and for us most likely the easiest) solution, yes. I wasn't sure, if this is possible or if there're already plans, that's why I created the issue explaining my problem and what solutions I'd in mind :)

[kaikreuzer]

This, however, requires a setup where data, that needs to be stored persistently, is strictly separated from the data and files that are only present to support the application or the application code itself.

Note that the current structure of openHAB actually considers exactly this setup:

• conf is for persistent configuration
• runtime is the application
• userdata is any written instance data

So the advice for reproducible setups is to go for textual configuration.

[FlorianSW]

@kaikreuzer Sorry, if this probably wasn't clear enough: I already use a file-based configuration for items, things and so on. However, as far as I understand, the openhabcloud binding can not be configured to use a specific secret and uuid, it creates a new set of both data during the first startup if no files are already there. And this data is saved in userdata. I'm not sure, if this is the only binding doing that. What do we suggest in this case?

If userdata does contain only instance-specific data, it should therefore not be a volume in docker but therefore be saved in the container itself. It's probably enough to remove the userdata from the VOLUME declaration.

[kaikreuzer]

specific secret and uuid

Isn't this instance data? You definitely must not replicate your setup using the same settings.

[FlorianSW]

Yes, however, from a user point of view, when I upgrade I don't want to change the uuid and the secret in my myopenhab account, just because it changed. So, in my opinion, the uuid and the secret identifies the specific set of configuration on an instance. Technically, you're right, it identifies the specific openHAB instance, however, as a user I would slightly disagree here :)

[kaikreuzer]

Right, so updating an instance is something different than copying an instance.
Updating in itself is not an easy feature to handle, check out openhab/openhab-distro#299.

I don't really see a way to ensure that the userdata content is compatible with a newer version of openHAB without running some kind of migration/upgrade script.
To analyze the situation for Docker, it might help to first look at pure Karaf and how it could work on this - because I have the impression that most our file system structure issues derive from there.

[FlorianSW]

@kaikreuzer Oha, the issue you linked seems to describe what I did so far when running in docker. So, it seems, when the "problem" is solved in an installation of openHAB without docker, chances are good, that the docker installation works well with this solution, too :) Let's see, what happens in the future!

What do we do with this issue now? I believe we can't (and probably shouldn't) do much here in the docker images, like ugly workarounds or something, which could create more problems as it sovles. So closing this? Or keep it open until a proper upgrade mechanism in openHAB is implemented and then recheck, if this issue still applies? :)

[cniweb]

I think, we close this issue and when it becomes an issue again, we open it again.