More and more, we will deliver Multi-OS clusters. Clara should learn how to deal with that. One way to acheive that is to add a section per distribution in the config file (e.g.: "repo/calibre8" and "repo/calibre9") and put the name of the default one in section "repo". Same remark for plugin "images".

The "slurm" plugin should allow the admin to do some simple admin tasks. I suggest the following commands :

• clara slurm health hostlist : is left as is
• clara slurm drain [hostlist] : Shows drained nodes (and reason why they have been drained) if given hostlist is empty... and drains specified nodes otherwise
• clara slurm down [hostlist] : Same as above but for down state.
• clara slurm CMD SUBJECT OP SPEC which (basically) runs scontrol where
  • CMD is one of job{,s}, node{,s}, steps, frontend, partition{,s}, reservation{,s}
  • SUBJECT is a name or a hostlist, basically a string.
  • OP is in show, create, update, delete
  • SPEC is the rest and given to scontrol as is
    If OP and SPEC are not specified, then the default is "OP=show"
    If OP is missing and SPEC is specified, then the default is "OP=update"
    OP=create|delete is valid only for frontend, partition{,s} and reservation{,s}

FWIW, here is the documentation of the "scontrol" command : http://slurm.schedmd.com/scontrol.html

clara repo sync doesn't sync installer components. syncrhonized sections should be specified in the configuration file.

Add functionality to change passwords of root user in clara images.
IMHO you can add a new variable in main configuration file:
pass='crypted_password'
echo "root:${pass}" |/usr/sbin/chpasswd -e

Just a stupid ticket so that we don't forget about it.

For now, clara takes a hostlist and appends "imm" before calling ipmitool. It would be very handy if it also supported plain IP addresses (and even more nicer, IP address ranges of the form 10.10.12.[15-254] for example).

We don't need them printed.

When a value isn't specified in the config file, clara retuens exeptions like this :

BB03654S@clausn24:~$ clara repo key
Traceback (most recent call last):
File "/usr/bin/clara", line 68, in
m.main()
File "/usr/lib/python2.7/dist-packages/clara/plugins/clara_repo.py", line 174, in main
do_key()
File "/usr/lib/python2.7/dist-packages/clara/plugins/clara_repo.py", line 65, in do_key
cmd = ['gpg', '--list-secret-keys', get_from_config("repo", "gpg_key")]
File "/usr/lib/python2.7/dist-packages/clara/utils.py", line 68, in get_from_config
return getconfig().get(section, value)
File "/usr/lib/python2.7/ConfigParser.py", line 618, in get
raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'gpg_key' in section: 'repo'

This patch should resolve the problem :
commit 9ec75f2b747acc66fdc1ef1296c6e8eee868dc79
Author: BB03654S [email protected]
Date: Fri Sep 5 16:48:18 2014 +0200

Correct behavior when value nor found in config file

diff --git a/clara/utils.py b/clara/utils.py
index db8f202..28ff673 100644
--- a/clara/utils.py
+++ b/clara/utils.py
@@ -65,20 +65,23 @@ def run(cmd):
def get_from_config(section, value, dist=''):
""" Read a value from config.ini and return it"""
if dist == '':

- return getconfig().get(section, value)

•    try:
  

•        return getconfig().get(section, value)
  

•    except:
  

•        sys.exit("E: Value '%s' not found in section '%s'" % (value,section)) 
  

  elif dist in getconfig().get("common", "distributions"):
  or_section = section+"-"+dist

•    # Check if override section exist, if not read the value from base section
  

•    if getconfig().has_section(or_section):
  

•        # If the value is not in the override section, return the base value
  

•        if getconfig().has_option(or_section, value):
  

•    # If the value is not in the override section, return the base value
  

•    if getconfig().has_option(or_section, value):
  

•         try:
           return getconfig().get(or_section, value)
  

•        else:
  

•            return getconfig().get(section, value)
  

•         except:
  

•            sys.exit("E: Value '%s' not found in section '%s'" % (value,section))
   else:
  

•         try:
           return getconfig().get(section, value)
  

•         except:
  

•            sys.exit("E: Value '%s' not found in section '%s'" % (value,section))
  

  else:
  sys.exit("{0} is not a know distribution".format(dist))

To be discussed

Reading the code, I see no way to abort an image edition if I wanted to (except backuping the old one, and then restore it). Am I missing something?

When a session is already started, this kind of message is printed by conman :

clara ipmi connect pocritical2

ERROR: Found console already in use.
Console [pocritical2] open R/W by root@localhost on pts/0 (idle 24m25s).
Do you want to force (-f) or join (-j) the connection?
clara - conman -d poadmin pocritical2

It would be nice to add -j and -f cli flags for use in the "connect" context. So that we will be able to do :
clara ipmi connect -j pocritical2
or clara ipmi connect -f pocritical2
or even clara ipmi connect -j -f pocritical2
and clara ipmi connect -f -j pocritical2

Note that those flags are only relevant when running conman. ipmitool doesn't support them.

The name of the field for the imm password isn't very clear. We can change it to be more specific (like "IMMUSER")

A plugin to show, edit and create encrypted files using configurable methods to get the encryption key and encrypt/decrypt files.
Basic operations :

• clara enc show [file]
• clara enc edit [file]
• clara enc create [file]
• clara enc encode [file](with possibility of taking source from stdin and/or output on stdout)
• clara env decode [file](with possibility of taking source from stdin and/or output on stdout)
  It is not necessary to implement many enc methods to start but only the one we are using currently.

For now, the interface of the images plugin looks like:
clara images create [] [--keep-chroot-dir] [--dist=]
clara images unpack [] [--dist=]
clara images repack [] [--dist=]
clara images edit [] [--dist=]
clara images initrd [--dist=] [--output=]

Same remark as for the repo plugin, the dist parameter should be mandatory:
clara images create [] [--keep-chroot-dir]
clara images unpack [] []
clara images repack [] [--dist=]
clara images edit [ | ]
clara images initrd [--output=]

I dunno what is the best approach for unpack and repack though.

Currently, clara repo plugin necessarily sync all distributions of a debian mirror. It would be nice it is able to only select a specific distribution as it could significantly drop the number of packages to download from a mirror.

The typical use case is downloading the xxx-backports distribution from one mirror in addition to xxx from another mirror.

We currently use apt-mirror for such use case, it would be great if clara was able to do so!

Eventually, clara should have a logging system

"clara repo add" should handle .dsc and .changes files. Corresponding reprepro commands are "includedsc" and "include".

For now, the interface is like:
clara repo key
clara repo init [--dist=]
clara repo sync (all|...|--dist=)
clara repo add ... [--dist=] [--reprepro-flags="list of flags"...]
clara repo del ...[--dist=]
clara repo list [--dist=]

It turns out that it is very error-prone and one can easily forget the --dist parameter :)
Ideally, the interface should be:
clara repo init [dist]
clara repo sync (all|/...|)
clara repo add ... [--reprepro-flags="list of flags"...]
clara repo del ...
clara repo list

clara could then make the parameter optional if config.ini:distributions contains only one distribution. Dunno if the latter is easy to implement though.

For now, clara images edit asks the user to touch a file /IGNORE if he wants to discard the changes... which can be error-prone because we don't always chroot into the image.

I see two ways to make our lives less miserable :-)

1. chroot into the image by default
2. Ask a question about saving or not the changes : "Save changes? (Y/n)"

We need to test return code 3 if we use systemd in clara_nodes.py when testing a service.

I suggest to change the format of the list called etc_hosts.
Old format:
ipadd,hosname,ipadd,hosname

Proposed new format:
ipadd:hosname,ipadd:hosname

Low priority issue.

In clara_nodes, it will be better if we have the hostname before the action.
Today:
clara nodes
Ex : clara nodes connect poadmin
Tomorrow:
clara nodes
Ex : clara nodes poadamin connect
We often have many successives actions on the same hostslist, so it's easier with hostslist at the end of the line.

Same thing as dpatch-edit-patch but to edit the squashfs image : spawns a shell where the specified squashfs has been extracted and then build the squashfs image back. Possibly, the "editimg" function could chroot into the extracted image and let the user do his changes from the chroot, to avoid any confusion with the system.

mldonkey_servers and trackers should be the same.... modulo adding new variables : trackers_port (default : 6881) et trackers_schema (default : http)

When editing an image, the PROMPT_COMMAND is set to "clara images>". It would be nice if the dist name is also shown.

Remove useless option (replaced by editimg, unpack and repack).

As per subject. For now, Clara expects those files to exist while they are not necessary to generate an image.

Clara can't umount /proc in chroot because it's still in use.
Unmounting /proc/sys/fs/binfmt_misc before /proc seems to solve the problem.

We moved away from our local check_node_health.sh to Warewulf NHC. So "clara slurm health" should be updated. Instead of updating the script's path, it would be nice to be able to specify the health check program directly in config.ini.

When one of the files used to generate the image don't exist, the program exit in error without cleaning temporary files:

clara images genimg

I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
I: Retrieving Packages
...
Traceback (most recent call last):
File "/usr/bin/clara", line 67, in
m.main()
File "/usr/lib/python2.7/dist-packages/clara/plugins/clara_images.py", line 259, in main
install_files()
File "/usr/lib/python2.7/dist-packages/clara/plugins/clara_images.py", line 148, in install_files
with open(list_files_to_install, "r") as file_to_read:
IOError: [Errno 2] No such file or directory: '/admin/website/diskless/calibre9/install'

ls /tmp/tmp4RMxU0/

bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

conman's configuration usually refers to hostnames. So it will fail if we call "clara ipmi connect" on an IP address.

We have now a plugin "p2p", this option is useless.

Subsections like repo-foo and repo-bar can share some configuration items. It would be nice if those items can be stored in the repo section instead of repeating them.
(Same remark for images-* subsections)

As per subject. For now, debmirror is called the same way even if debug mode is turned on

a) possibility to override a parameter
b) possibility to supply a config.ini

• Delete useless part for decoding master_password (puppet already do that)
• New init function : test if master_paswword exist
  set variables for others functions
• Cleaning others functions

Just like for the system image, we should be able to specify the path of the generated initrd and vmlinuz... and use the one used today if nothing is specified.

We must verufy we have only one host when using "clara nodes connect".

It would be nice to be able to pass random flags to reprepro like --reprepro-flag="--ignore=wrongdistribution --ignore=foo"

When we use the "--version" option, clara return the help message.

If "clara image create" fails, it cleans up the work_dir used in /tmp. In such cases, it would be useful to keep work_dir around for debugging purposes.

One can do "clara ipmi connect -j cn001" but not "clara ipmi cn001 connect -j". Is this intentional?

For now, it is left as a TODO. We should test it and release with this feature enabled.

Clara does not print to users the commands that are run. Although I think it's a sane default behaviour, it could be usefull to have a debug mode that does basically this. It helps new users gaining trust in the software :)

Just have to issue "raw cold reset" command.