TODO ==== See KNOWN_BUGS.markdown for real bugs. Bugs to fix and features to add for 4.3 --------------------------------------- Refactor TLS disabling. Seems to be happen twice, once in 20-setup-apt and once in 10-disable-tls. Bugs to fix and features to add for 5.0 --------------------------------------- * `xen-create-image` man page overhaul: * ambiguous option list with regards to parameters * Set Fail in more situations where the script has clearly failed i.e.: lvm exists * Test and support more file system types. Actually this should be pretty simple now that the parameters are stored in the configuration hash. * Setup locales in the hooks? Currently no locales are set and this causes several domU errors which appear in the domU's logs. * Documentation overhaul Better explain what roles /should be/ used for, and that roles are examples, and shouldn't cover every single scenario. They are also easy to write. * Think again about disk_device checks : Newer Xen provides `xvda`, older provided `sda`. The current check for valid values of `disk_device` (used for root device in DomU `/etc/fstab`) does only allow those values. This forbids any deployment of LVM/RAID _inside_ DomU, which cannot be created by xen-tools anyway. So the current check is fine with the current possibilities of xen-tools, but could become a limitation. * Is it possible/wanted to "query" xend for default device names? * Is it possible to create `/dev/mapper` devices with xend conf? * Can we just avoid to ask for this value and not specify the device in `/etc/fstab` (and use `/dev/root`, `/dev/by-uuid`, or anything?) * `xen-create-image --dist=…` / sources.list generation should be more fine-grained xen-tools should offer the possibility to enable/disable security/volatile/backports as well as contrib/non-free/universe/restricted/multiverse for each of them not only based on defaults plus the Dom0's sources.list One idea is to allow parameters like --dist="lenny:main,contrib,non-free;security;volatile:main" and maybe (if the default will be to include security) to also allow --dist="lenny;no-security" The second idea (by Mathieu Parent) is to have an `/etc/xen-tools/sources.list.d/` which then contains files like `lenny.list`, `lenny-server.list`, `karmic.list`, etc. which defaults to `$dist.list`, but can be also select with `--sources-list=lenny-server` (which looks for `./lenny-server.list`, `./lenny-server`, `/etc/xen-tools/sources.list.d/lenny-server.list` and `/etc/xen-tools/sources.list.d/lenny-server` in that order). Third variant is to use `/etc/xen-tools/sources.lists/` instead of `/etc/xen-tools/sources.list.d/` because that directory is no runparts-like directory. * LVM snapshot support as an install source. * Clean up mounts on `Ctrl-C`, causes error while installing otherwise: Removing /dev/vg0/acromantula-domu1-disk - since we're forcing the install Can't remove open logical volume "acromantula-domu1-disk" this should be a matter of unmounting the mounted volume from /tmp. * Generic grub support This will generate a much nicer `menu.lst` as a side effect, as its currently generated once at install, and is never updated. Installing a full grub into the domU should update the `menu.lst` every time a new kernel is installed and will also use the domU distro's `menu.lst` conform. * pv-grub support This is a ways away and will probably start with a `xen-pv-grub` package. * Move the hooks directory to `/etc/xen-tools/` to officially allow added and modified hooks. * Clean up the hooks directory We still have a link farm for hooks and a meta link farm for distro releases created on `make install`. It probably would be better if we would just have one directory per distro (like with debian) but without the need to created symlinks on `make install`. Currently CentOS's `25-setup-kernel` creates an fstab and `90-make-fstab` does again. It works, but that cries for debugging hell. `centos-5/25-setup-kernel` and `centos-6/25-setup-kernel` still differ and I'm not sure if that's necessary respectively what's the common denominator. `80-install-kernel` is not yet merged into one hook script. Common oneliners for code deduplication in the hooks/ directory: $ find -L . -not -xtype l -not -type d -not -path '*/common/*' | sort -t / -k3 $ fdupes -r1 . | sort -t / -k3 $ find . -type f | sim_text -ipTt 50 | tac | column -t * Create users, add ssh pubkeys to `.ssh/authorized_keys` Still have to think of a good way of doing this. It would be nice To specify a directory of public keys, parsing the hostnames parsing the usernames from the ssh comment line. Potential ideas are to add options to add a given file as `authorized_keys` (e.g. a users public key) or to just add the Dom0's `/root/.ssh/authorized_keys` as the DomU's one. * More generic roles Deploy a web server or setup ssmtp directly via flag when setting up the machine. Open to suggestions, should just be some general use-cases that are fairly common. * Sections for the xen-tools.conf file Currently it's really annoying when you are trying to create VMs on multiple subnets. It would be nice to specify with a flag what "type" of configuration you want, and a set of options specific to that flag could be parsed from xen-tools.conf * Refactor the code for less variants of calling `cp`, `rm`, `mv`, etc. E.g. always use either `cp()` from `File::Copy` or `/bin/cp`, but not both. To allow verbose copying, I (Axel) would prefer `/bin/cp` over `cp();`. * Parse numerical parameters transparently for the user The user shouldn't have to know whether he should specify size as `G` or `Gb` or ``. This should be parsed without user interaction and rely on a common format. * `xen-update-image` should mount `/dev/pts` before running apt-get * `xen-update-image` should have options for using … * aptitude instead of apt-get * dist-upgrade instead of upgrade * Support `cpu_weight` and other features from http://wiki.xensource.com/xenwiki/CreditScheduler * Make used Xen toolstack configurable, i.e. via --xen-toolstack=xl * Code Deduplication / Refactor the code for less code duplication `bin/x*` currently contain the same or similar code like e.g. in the function readConfigurationFile. This needs to be cleaned up. * Unify --debug and --dumpconfig. Likely make --debug exit gracefully. Document --debug if --dumpconfig is removed. * Use `Perl::Critic` Stuff from Steve's TODO list / Generic TODOs -------------------------------------------- * Write more test cases. * `xen-delete-image` should unallocate any used IP addresses. Axel's Break-Backwards-Compatibility Wishlist --------------------------------------------- * Make empty extension the default This would ease tab completion and CLI parameter reusage with "xm create" and friends. * Check if we can reduce `MAKEDEV` invocations in `hooks/common/55-create-dev` `MAKEDEV std` is called in any case. First comment says "Early termination if we have a couple of common devices present should speed up installs which use `--copy`/`--tar`" and then "We still need to make sure the basic devices are present" and calls `MAKEDEV` more often than otherwise. Additionally the `55-create-dev` for CentOS/Fedora just created `console`, `zero` and `null`. `zero` and `null` are part of `MAKEDEV std`, perhaps can we reduce it to that. `console` is part of `MAKEDEV generic`. Additionally the devices `hda`, `sda` and `tty1` may not necessary in any case, but instead `hvc0` should be created for sure in many cases. Nothing cares about `$serial_device` there either. Current `MAKEDEV` implementation support more than one device as parameter. That could reduce the `MAKEDEV` calls from currently six to two. * Uncouple generating auto start symlinks from `--boot`. Maybe add some `--autostart` or such. * Maybe replace findBinary with File::Which