Thank you very much! That was very helpful information.
The fact that updates take place within the container instance is very good information. That should ensure that a mounting in e.g. /home/service1 (i.e. not in a subfolder) is safe - or not?
That would at least alleviate the current space issue a little.
However, this would mean that “system data” (the system service itself, its settings and the service settings) would be stored together with the service data. But I would think that a separation would be very useful here. Even the Podman developers probably thought that was useful, because Podman also separates system data and service data from each other (~/Volumes). Of course, I don’t know whether the Podman developers thought of integrating other drives into this path (or deeper). Technically speaking, this separation would be exactly the right entry point.
In order to use this option safely, you obviously need to know how updates to the container or container app specifically affect the path structure (temporarily) during container or app updates - because a change to the path = the previous mount path is invalid. Maybe I’m worrying too much here and the path structure (including the internal one) never changes with such updates anyway? Who could give me certain information on this?
When moving nodes within a cluster or during a restore, it is very likely that a new instance number will be assigned. I noticed this when reinstalling a container (via GUI) that I had previously deleted (GUI). That’s what made me aware of this problem in the first place. Because a new instance number = change to the path = mount path becomes invalid. This means that you would always have to adjust the mount paths after(!) creating a new container instance (or a restore?). That would be annoying at first. Here I had the idea of creating another mount (fictitious) on e.g. “/home/service2” parallel to “/home/service1”, but NETH8 will probably see the folder and spontaneously decide on “/home/service3” - right?
That is also my fear or the obstacle to creating a mount to “/home/service1” when installing the basic system. In order for the mount to be active during the subsequent container installation (and not aborted due to a lack of a target folder), the directory “/home/service1” must already exist. Would NETH8 then use this for the first instance of “service” or create the new instance “/home/service2”?
If that is the case, all built-in restore procedures are probably not available - or would they use “/home/service1” if it already exists?
Is there any way to avoid this (built-in) sequence theater? Can the check for previous instances (or their folders) be switched off if necessary?
It would be reasonably practical if you would have been affected by the sequencing that would not have been affected by the sequencing in order to mount a suitable drive there in general. This could be done. Unfortunately, the only common basic path for all (rootless) service is the same “/home”. All (!) Other containers come up with it, no matter which instance. Although these have a service -specific instance number, they are all in the same directory. The “order” of identical service types is therefore chosen via the name (with numbering), not over the path. “/home/service1”, “/home/myservice1”.
“/home” is far too unspecific if you want to assign a suitable data carrier (HD, SSD or even streamer) for each service type (as you should actually do).
Therefore, I would like to repeat myself again that I would consider it very useful if every service type had a common (specific) basic path such as: “/home/service/1”, “/home/service/2”, " /home/myservice/1 "
This would make at least a “rough” integration of suitable drive types according to the service type - and probably also harmless even when moving between nodes or the restore or when reinstalling formerly deleted containers.
Basically, one would also wish that - as usual with Linux - you can also mount directly into a deep folder structure with a container orchestrator without violating its basic concept (move/restore). Because the choice of the drive type can depend not only on the data type but also the special use. I would like to have the most mail folders on an average SSD, for example, but certain mail folders such as an archive (with rare access), I would like to be on a slow but large HD - or even a streamer (not tested but conceivable). The same should apply to certain SMB shares.
Small swipe to the developers - otherwise I very much appreciate:
With the NethServer 7, all of this was still “out of the box”. Already during installation the basic system could be roughly mounted in the respective paths:/var/lib/nethserver, /var/lib/nethserver/ibay, /var/lib/nethserver/vmail etc.
This is not predictable under NETH8 (for me) - except the instance number could be predefinable or fixable - which may also be a way to adjust this for future versions.
Of course, I don’t know to what extent it is realistic to get something of it in the future. Adjusting the administrative code to adapt to this does the greatest work.
And I couldn’t even say whether I could look forward to such an upgrade later - if I had “bent” my system myself until then. Because as long as everything is on a drive, such an upgrade would probably be done with a few hard links and a code -update. If the hard links cannot work because they are different drives - then when upgrading, what I fear would now happen.
Please excuse my long versions - these are not the first on the subject - but I am still looking intensively for solutions because without a solution you cannot move a single NethServer7 to Neth8.
Greetings Yummiweb