The check for disk devices was completly broken, fix it temporarily. This check is also kinda wrong, but is still an improvement over the current test, so submit it waiting for a better idea.
165 lines
5.9 KiB
Plaintext
165 lines
5.9 KiB
Plaintext
TODO
|
|
====
|
|
|
|
See KNOWN_BUGS for real bugs.
|
|
|
|
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
|
|
|
|
Currently we have one directory for Ubuntu and Fedora named after
|
|
the first supported release which is then duplicated for each
|
|
subsequent release.
|
|
|
|
I'm sure this won't scale forever. So to minimise code duplication
|
|
I'd like to have one common directory per distribution (e.g. called
|
|
ubuntu-common, fedora-common, debian-common, maybe even deb-common,
|
|
rpm-common or yum-common for dpkg/apt-, rpm/yum-based
|
|
distributions, etc.) with generic hooks valid for all or most of
|
|
the releases of one distribution and then one hook directory per
|
|
release (e.g. called ubuntu-10.04 or ubuntu-lucid or so) which has
|
|
symbolic links to everything which can be used unchanged from the
|
|
common directory and new files for everything which has to be
|
|
different or only there.
|
|
|
|
* 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
|
|
|
|
* 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 code duplication
|
|
|
|
Like e.g. readConfigurationFile in xen-create-image and
|
|
xen-resize-image which are not completely identical.
|
|
|
|
* 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 weather he should specify size
|
|
as <size>G or <size>Gb or <size>. 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
|
|
|
|
* Use Perl::Critic
|
|
|
|
Stuff from Steve's TODO list / Generic TODOs
|
|
--------------------------------------------
|
|
|
|
* Write more test cases.
|
|
|
|
* xen-delete-image should unallocate any used IP addresses.
|