Rock-on install wizard obfuscates share container info

[phillxnet]

During install of multi-container Rock-ons, the current Rock-on install front-end (wizard) drops container relevancy: i.e. for a reproducer Rock-on in draft PR form ("bare os server set": rockstor/rockon-registry#379) we have the following share info passed to the Rock-on creation back-end during Rock-on install:

from #1588 (comment)

[12/Aug/2024 16:40:55] DEBUG [storageadmin.views.rockon_id:109] install request with share_map={'bareos-backups': '/var/lib/bareos/storage', 'bareos-catalog-backup': '/var/lib/bareos', 'bareos-catalog': '/var/lib/postgresql/data', 'bareos-dir-config': '/etc/bareos', 'bareos-storage-config': '/etc/bareos', 'bareos-webui-config': '/etc/bareos-webui'}

With the following DB instantiated as a result:

id	dest_dir	uservol	description	min_size	label	container_id	share_id
133	/ var/ lib/ postgresql/ data	false	BareOS 'Catalog' (Postgres DB) Share.	NULL	'Catalog' data[e. g. bareos-catalog]	85	17
135	/ var/ lib/ bareos	false	BareOS Catalog-Backup Share	NULL	Catalog-backup data [e. g. bareos-catalog-backup]	86	14
134	/ etc/ bareos	false	BareOS 'Director' configuration Share.	NULL	'Director' config [e. g. bareos-dir-config]	86	16
137	/ var/ lib/ bareos/ storage	false	BareOS 'Storage' Share for all backups.	NULL	Backups data [e. g. bareos-backups]	87	9
136	/ etc/ bareos	false	BareOS 'Storage' configuration Share.	NULL	'Storage' config [e. g. bareos-storage-config]	87	16
138	/ etc/ bareos-webui	false	BareOS 'WebUI' configuration Share.	NULL	'WebUI' config [e. g. bareos-webui-config]	88	13

I.e. repeat use of share id 16 associated with /etc/bareos but for two different containers:

Requested share mapping

Resulting share mapping

---

Above finding by-way of development on a suspected parallel issue affecting environment container relevance obfuscation: see Issue #1588 PR #2885

Related issue by @FroggyFlox re adding Shares to an existing Rock-on: "[Rock-Ons] Add_storage affects all containers in a Rock-On" #2000

[phillxnet]

Assuming as-yet un-merged PR #2887 (removing the initial install blocker) we have the following share mapping within the resulting bareos-director container:

docker inspect bareos-director
...
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/mnt2/bareos-catalog-backup",
                "Destination": "/var/lib/bareos",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/mnt2/bareos-storage-config",
                "Destination": "/etc/bareos",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/etc/localtime",
                "Destination": "/etc/localtime",
                "Mode": "ro",
                "RW": false,
                "Propagation": "rprivate"
            }
        ],
...
            "Image": "barcus/bareos-director:latest",
            "Volumes": {
                "/etc/bareos": {},
                "/var/lib/bareos": {}
            },
...

I.e. our bareos-director container has had its /etc/bareos mapped to the share intended for the bareos-storage container: likely due to a first match error in reverse engineering which container definition contained a "/etc/bareos" target. Ergo the proposal here that we have a parallel issue to what we observed with our env interpretation: and the back-end similarly having to reverse match from the Rock-on install wizard's obfoscating info re flat presentation of all container shares, rather than preserving user preference per container as presented/explained during the wizard's run: where the presented text indicates what each share is intended for.

Similarly we have the following from an inspection of the bareos-storage container in the issue reproducer proposed multi-container Rock-on - in this case these are the intended mappings:

docker inspect bareos-storage
...
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/mnt2/bareos-backups",
                "Destination": "/var/lib/bareos/storage",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/mnt2/bareos-storage-config",
                "Destination": "/etc/bareos",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "bind",
                "Source": "/etc/localtime",
                "Destination": "/etc/localtime",
                "Mode": "ro",
                "RW": false,
                "Propagation": "rprivate"
            }
        ],
...
            "Image": "barcus/bareos-storage:latest",
            "Volumes": {
                "/etc/bareos": {},
                "/var/lib/bareos/storage": {}
            },
...

[phillxnet]

Proposal

We do, as per PR #2887 re a Rock-ons per-container environment' definition, but for the per-container volumes` definition:

[15/Aug/2024 13:44:33] DEBUG [storageadmin.views.rockon_id:109] install request with share_map={'1': {'bareos-catalog': '/var/lib/postgresql/data'}, '2': {'bareos-catalog-backup': '/var/lib/bareos', 'bareos-dir-config': '/etc/bareos'}, '3': {'bareos-backups': '/var/lib/bareos/storage', 'bareos-storage-config': '/etc/bareos'}, '4': {'bareos-webui-config': '/etc/bareos-webui'}}

hence easing the back-ends job of matching share to the appropriate container in multi-container Rock-ons - when two rock-ons can very-well have the same internal mapping. I.e.:

1. container bareos-director user-input has /etc/bareos mapped to Share 'bareos-dir-config'.
2. container bareos-storage user-input has /etc/bareos mapped to Share 'bareos-storage-config'.

Our prior front-end share_map (see: original issue text) does not preserve this info. However the above proposal of an additional dimension does. Enabling more robust share to container mapping.

[phillxnet]

Closing as:
Fixed by #2888