dchirikov/luna

Provisioning tool for clusters

luna's Issues

Add support for diskless nodes

Please, add support for diskless nodes, like stateless/statelite in xCAT.

kernel cmdline different for some nodes

I am using luna to install nodes in a cluster made of heterogeneous nodes (completely different vendors). Some nodes need kernel option console=ttyS0 some console=ttyS1. I tried changing options in the Console Redirection settings in the BIOS, but to no avail. And you cannot specify both console=tty[0,1] at the same time, due to a limitation of the Linux kernel.

Otherwise, all nodes use the same image (most configuration is done on first by boot anyway).
Since the kernel options are tied to the osimage, I clone the image now and then change the kernopts parameter. The nodes are put in different groups and then each group gets a different (cloned) image.
Is this the way to do it?

It would be easier if nodes could add/override kernel options. Or that images could be cloned "lightly", where no files are copied, just reused.

luna2 API work

Hello team,
I just wanted to express interest in luna2 branch where your team seem to work on an API for the Luna baremetal provisioning tool. Looking forward to it becoming available in master/stable branch.

The project I'm involved in, Airship, has a component Airship-Drydock. It is a small orchestrator, which takes a YAML document as an input, and follows it to deploy baremetal nodes with a help of baremetal node deployment tool and do post-install configuration on them.

At the moment Airship-Drydock supports only Ubuntu MAAS as a node driver. There is an ongoing work on blueprint with plans to support OpenStack Ironic as a driver for the same purpose. Drydock talks to the API of the deployment tool, that is why I'm particularly interested in the API development you are working on.

Keeping an eye on Luna development, I would like to thank you for your great project, and hope to work on inclusion of Luna with it's unique features (esp. rapid deployment speed) as a possible node driver for the Drydock.

Thank you.

Remarks on installation of RHEL6

We have a large cluster (>800 nodes) that still use a RHEL6 based distribution (yeah, it's old). I have been trying to set up luna for the last week to get rid of the old deploy software (which is very slow and unreliable) and now it works. These notes are just in case my work is useful for other people (or just for posterity). I had make the following changes:

• luna/osimage.py
  The dracut (from dracut-004-388 rpm) syntax is different, for example it doesn't know the --kver option. Instead, the kernel version is the last argument:
  # dracut_cmd = (['/usr/sbin/dracut', '--force', '--kver', kernver] +
# modules_add + modules_remove + drivers_add +
# drivers_remove + [tmp_path + '/' + initrdfile])
dracut_cmd = (['/usr/sbin/dracut', '--force'] +
['--add', " ".join(modules_add) ] + ['--omit', " ".join(modules_remove)] + drivers_add + drivers_remove + [tmp_path + '/' + initrdfile] + [kernver])

Also had to tweak the argument to --add and --omit there a bit.
I do not know how stable the dracut syntax is, maybe it would be an idea to define a template of this in the database, so this was changeable without touching the code.
Since this dracut is so old, I also had to create "check" and "install" files from the contrib/dracut/95luna/module-setup.sh file, but this is straightforward.

• Compatibility symlinks:
  In the scripts luna-start.sh and templ_install.sh, external programs are called with full path, i.e.:
  luna-start:109: /usr/bin/ps ...
  Since ps is in /bin/ on this old Linux, I created a symlink. Also for tar and dracut.
  Personally, I prefer to set the PATH at the start of the script properly and then use command -p to save the full path in a variable. Then I can also check if this executable is actually present.

• contrib/dracut/95luna/luna-start.sh and templates/templ_install.cfg:
  At first, dracut only installed dash, not bash, into the initrd. dash wouldn't understand the function definitions, e.g.,
  luna-start.sh:25: function are_macs_equal () {
  It did not understand the "function" keyword and I think it also didn't like the space between the function name and the (empty) argument parentheses.
  For compatibility, I think omitting the "function" and deleting the whitespace would be a good idea. By the way, the functions in templ_install.cfg don't have parentheses:
  templ_install.cfg:6: function update_status {
  Maybe it would also be a good idea to use /bin/bash instead of /bin/sh in luna-start.sh when calling the install script:
  luna-start.sh:162: /bin/sh /luna/install.sh && RES="success"
  since bash is also used explicitly in other places, e.g. in the shebang of luna-start.sh (and also in the shebang of templ_install.cfg, but this is obviously not used when running the install script)

• Compiling a recent rb_libtorrent (1.0.9) with the old gcc 4.4.7 was also not directly successful, but it worked eventually. Considerably older version did not work well together with ltorrent (performance was very low).

• Lastly, I build these images on a Centos 7 node, which is means yum and rpm are much more recent, so I have to rebuild the RPM db (rm -f /var/lib/rpm/Name && rpm --rebuilddb) once a node is installed or the old rpm will not be able to read the db.

• One feature I added was to have the option to change the localboot parameter in the same way the status is updated using curl. Our nodes are set to boot from the network first. To deploy, localboot must be off, but not every reboot should be a deploy. I put one function in node.py (update_localboot) and a branch in get() in manager.py which sets localboot to 'yes'. This is triggered from a function update_localboot (which calls curl) in templ_install.cfg, which is called from the postscript script after the boot loader is installed:
  curl -s [...]/luna?step=configure&node={{ p['name'] }}&localboot=$1
  But maybe this is superseded by the REST API being developed?

I don't expect any changes to your upstream for such an old system (which is hopefully scrapped next year). But if any of the above sound like they a good idea, I'll be happy to send a patch.