Hi KB,

Sorry for the delayed response, I wasn't subscribed to the devel list. I'm also replying to some of the comments that other users posted. Sorry for messing up the thread.

I tested your image in OpenStack Havana with KVM so my comments are very much OpenStack centric.

Hi,

CentOS-6.4 i386 and x86_64 images targetting OpenStack are now available for testing at http://dev.centos.org/centos/hvm/ Images are available for KVM, Hyper-V, VMware, Xen and any other HVM hypervisor. Although, the 6.x kernel has the pv support enabled, so should work fine under paravirt Xen as well.

Images are published as raw, qcow2 qcow2compressed and vpc ( vhd ) for both i386 and x86_64 CentOS-6.4 The images represent media versions, and have not had an update run against them. Its highly recommended that in testing, please check this version *then* do a yum update and repeat tests to ensure that there is no test result change in the 6.4+updates tree's.

Keeping in line with the general CentOS Cloud strategy, ie to help people migrate or investigate cloud instances, we expect the images to represent as close as possible to a real machine CentOS install ( ie. no cloud specific user, people use root to login, selinux is enabled ).

I'd prefer a non-root default user to be inline with the other community images. IMHO it's a convenience to not have to create a non-root user after spinning up an instance. But cloud-init will take care of all that for you, if you configure it correctly, which doesn't seem to be the case in your image. I.e., cloud-init creates a 'cloud-user' and disables root login but for some reason the cloud-user is not allowed to sudo (should be handled by cloud-init) so there's no way to gain root permissions.

In general, the cloud environment has no business in mocking with a guest image. Yes, OpenStack is still injecting keys but that is likely to change (I believe). It should be up to the instance to configure itself which is what we have cloud-init for. In terms of users, I vote for: - A 'centos' default user without a password (no console login) and password-less sudo permissions. This follows Fedora and Ubuntu and to some degree Debian conventions. IIRC Debinan uses 'admin' as the default user. - Disabled root login and certainly no standard well-known password which is simply a security disaster waiting to happen.

I'm not too crazy about SSH password access and cloud-init disables that as well (unless you tell it not to).

In general, a cloud image should be as locked-down as possible to reduce the risk of somebody else taking over your instance before you can get to it. Providing SSH key access is the preferred method. Everything else can be enabled later or when the instance is launched (for example by providing a configuration script that cloud-init executes on first boot). Similarly, selinux should be enabled by default. The firewall can be discussed. I think it's not required since the cloud environment already provides that functionality and you have to specifically open ports to get access to your instance.

As for console logins, why would we want that in the base image? Can somebody give a use case? I just don't see it as useful. We have SSH access and as mentioned everything else required/desired should be enabled/configured once the instance is up. If SSH access doesn't work after first boot, then there's something fundamentaly broken and console access will most likely not work either.

LVM: What's the rational for using LVM? It's not like we can just add another disk to the instance and add it to the volume. IMHO it just adds unnecessary overhead and breaks the growroot functionality. dracut-modules-growroot (which I maintain in EPEL) doesn't support LVM.

swap: Providing a swap device in a cloud image is debatable as well. Some clouds charge for IOs and you don't want to pay for swap activity so the cloud images I'm aware of don't have a predefined swap device. Again, it can always be added later if need be.

console: As mentioned by others, please add 'console=tty1' to the kernel commandline to get some messages on the virtual console: 'console=tty1 console=ttyS0' (See https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1016695 for the rational to use tty1 instead of tty0).

If you try to make this image as close to regular CentOS as possible, you might confuse other cloud users that are used to certain things in other cloud images. Although those 'things' are not standardized and we're not required to follow them. It's a balancing act, I guess.

CentOS-6.4-i386-Minimal-OpenStack.image.qcow2c.bz2 CentOS-6.4-x86_64-Minimal-OpenStack.image.qcow2.bz2

Why the bzip2 compression on top of qcow compression? It doesn't create much smaller files and requires and extra step after downloading the images. No big deal, though.

Enjoy!

Good work!

...Juerg