clustervision
Rocky 8 image creation places luna.ini in {{ image_path }}/{{ trix_luna }}/node/config/luna.ini
Image creation (and others) places luna.ini in {{ image_path }}/{{ trix_luna }}/node/config/luna.ini by extend.yml (e3b86bc, 230d9be and a88bc28). During image deployment this file is called as /trinity/local/luna/node/config/luna.ini (I suppose it's a hardcoded path) Since trix_luna defaults to '{{ trix_local }}/luna' and trix_local defaults to '{{ trix_root }}/local' in all.yml this fails when {{ trix_root }} and/or {{ trix_local }} is different from the default.
I don't see any reason why the images should inherit the locations of {{ trix_root }} and/or {{ trix_local }} from the controller, it would perhaps be better if the playbook writes luna.ini to {{ image_path }}/trinity/local/luna/node/config/luna.ini If it is desirable to inherit the directory structure then the call should be made to the variable location.
True. this is a known issue and will be resolved/determined (soon). Note that TrinityX came out during 'the great Python battle' where many different releases were bundled with the OS-es, which all were incompatible with each other. For this reason we made the choice to bundle our own python release, which currently installs (rpm - hardcoded) in /trinity/local/python. The variable {{ trix_root }} currently gives the feeling of freedom, but should/would/will/might be set in the future as hardcoded if the above, and others parts can not be fixed in a reliable fashion. I keep you informed.
Should we expect issues when we move everything to /trinity manually? Since we intend to clone and update future images, this would be a one time thing
what is meant by 'everything'? some files are coded into config files, e.g. the location of certificates is 'dynamic' (e.g. {{ trix_ssl }}), but is set into config files (for .e.g. openldap) during installation. in short, not everything can be moved without modifying these affected config files.
one utility that might help cloning, moving and backuping images is: lexport:
usage: lexport <-c|-o> <-e|-i> [file]
Luna configuration im/exporter.
positional arguments: -c, --cluster cluster level. -o, --osimage osimage level. -e, --export exports configuration. -i, --import imports configuration/data.
what is meant by 'everything'? some files are coded into config files, e.g. the location of certificates is 'dynamic' (e.g. {{ trix_ssl }}), but is set into config files (for .e.g. openldap) during installation. in short, not everything can be moved without modifying these affected config files.
With 'everything' I meant that osimages don't use the different location-variables as defined in all.yml. They could use the defaults, which would mean that 'everything' falls under /trinity in de osimages. I think it is plausible that the decisions for file locations are different between the controller-nodes and the compute-nodes.
The other option is to keep using the variables for the controller-nodes, but then it should be done consistently.
We assume /trinity on the controller as well in the images for trinityX related things. We do out utmost best to allow for tuning, but we are bound to some dependencies, e.g. our provided python release where this will always be installed in /trinity/local/python. I wish we could do a more dynamic approach, but using the distro python breaks more things. The choice of using our own python l, which delivers stability comes with the cost loosing some flexibility. We try to keep things as flexible as possible, but it seems that /trinity is becoming a more hard defined path; too many outside ansible components that influence this.
-A