Replace the default centos template that comes bundled with cloudstack installation

[kiranchavala]

Currently, the default centos template that comes with cloudstack installation for all hypervisors is pretty outdated

CentOS 5.5(64-bit) no GUI (KVM (http://download.cloudstack.org/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2)

CentOS 5.6(64-bit) no GUI (XenServer) http://download.cloudstack.org/templates/builtin/centos56-x86_64.vhd.bz2

CentOS 5.3(64-bit) no GUI (vSphere) http://download.cloudstack.org/releases/2.2.0/CentOS5.3-x86_64.ova

I would like to see a new small sized template as the current centos is pretty outdated one

1. That is up to date with the current market trends

2. A small-sized template that can be used for quick testing purposes once CloudStack is installed.

The template can be a minimal cloud image template from well-known operating systems or can be a customised one for cloudstack testing only. the template should be support root passwords, ssh keys and user data scripts, cloud-init

Here are my choices

https://github.com/NuxRo/macchinina
https://alpinelinux.org/cloud/
https://github.com/cirros-dev/cirros
https://cloud.debian.org/images/cloud/
https://cloud-images.ubuntu.com/minimal/releases/
https://wiki.almalinux.org/cloud/Generic-cloud.html
https://wiki.rockylinux.org/rocky/image/
https://fedoraproject.org/cloud/download/

I personally would go for the following 2 choices

https://github.com/NuxRo/macchinina
https://alpinelinux.org/cloud/

Leaving it open for community discussion and polling

cc @DaanHoogland @NuxRo

[DaanHoogland]

@kiranchavala I am completely on your side but had pushback for similar ideas in the past. The argument was that the template should be a full functional open source desktop/server implementation that new users could use. I do not think it should be usable to anyone but an (aspiring) operator, myself.

From your list, doe sit hurt to include all of them?

Nux’ template is kind of old so could do with an update, though ;) the rest all are fine to me.

[kiranchavala]

@DaanHoogland

The current builtin centos template is pretty much unusable, and not at all usable for quick testing.

Though it deploys it fine on the hypervisor, the ssh service doesn't work

From my perspective, we should use the template which has the smallest footprint size and covers the basic tesiting scenarios of
root passwords, ssh keys and user data scripts, cloud-init

Either we can improve the @NuxRo macchinia template and maintain it properly or we can go for Alpine Cloud image for which we should run some tests

Other popular cloud os image are pretty large in size ( 500 to 600 mb)

[DaanHoogland]

you dont have to convince me @kiranchavala . I agree. The argument I am giving as the devils advocate, is that though these templates are good for testing they may be insufficient for evaluation. cc @andrijapanicsb @NuxRo @gsirett .

[dheeraj12347]

Hi @kiranchavala, @DaanHoogland

I'd like to contribute to the default VM template replacement initiative. I can help validate a candidate image against the basic CloudStack requirements, particularly SSH access, root-password handling, SSH keys, user-data, and cloud-init.

To start with a manageable scope, would it be useful for me to prepare a lightweight validation checklist and investigate the existing template configuration and tests? Please let me know which candidate image and specific task would be most useful to the project.

Thanks!

[NuxRo]

@dheeraj12347 Testing welcome

https://lists.apache.org/thread.html/ndcd62hpgo8f685c818gy4hfvp598h3o

[nickaccuweb]

@kiranchavala

I agree that the default CentOS templates need to be updated. CentOS 5.x is quite old, and it doesn't make much sense to use it for testing a new CloudStack installation.

My preference would be Alpine Linux with cloud-init. It is lightweight, actively maintained, and should be suitable for quick VM deployment and basic functionality testing.

Before selecting it as the default template, I think we should verify a few things:

• VM deployment and network connectivity
• SSH key authentication and password management
• Cloud-init and user-data script execution
• Compatibility with KVM, XenServer, and VMware

It would also be useful to keep a Debian or Ubuntu cloud image as an alternative for users who want to test with a more commonly used server OS.

Overall, I would vote for Alpine Linux, provided it passes the basic CloudStack functionality tests.

[weizhouapache]

@kiranchavala

I agree that the default CentOS templates need to be updated. CentOS 5.x is quite old, and it doesn't make much sense to use it for testing a new CloudStack installation.

My preference would be Alpine Linux with cloud-init. It is lightweight, actively maintained, and should be suitable for quick VM deployment and basic functionality testing.

Before selecting it as the default template, I think we should verify a few things:

• VM deployment and network connectivity
• SSH key authentication and password management
• Cloud-init and user-data script execution
• Compatibility with KVM, XenServer, and VMware

It would also be useful to keep a Debian or Ubuntu cloud image as an alternative for users who want to test with a more commonly used server OS.

Overall, I would vote for Alpine Linux, provided it passes the basic CloudStack functionality tests.

I agree with the requirements.

However, as Lucian (@NuxRo) mentioned somewhere, Debian and Ubuntu cloud images are actually quite small (around 300–400 MB), so I wouldn't consider image size a deciding factor.

In my opinion, we should choose a popular OS that is easy for most users to work with. To be clear, I would recommend using one of Ubuntu, Debian, or Enterprise Linux (EL) and its derivatives as the built-in template.

Considering that Debian is vendor-neutral, I agree it's a good option, although I personally prefer Ubuntu.

[nickaccuweb]

@weizhouapache

I agree with your point. Since Debian and Ubuntu cloud images are already quite small, image size shouldn't be the main concern.

I think Debian would be a good choice for the default template, considering its stability, wide support, and vendor-neutral approach.

The main thing is to ensure it works properly with CloudStack features like cloud-init, SSH keys, password management, and user-data scripts.

Regards,
Nick R
Accuweb.Cloud

[weizhouapache]

may be not accurate

Enterprise Linux Distribution Share:
┌──────────────────────────────────────────────┐
│ Ubuntu Server (Canonical): 46.2%             │
├──────────────────────────────────────────────┤
│ Debian GNU/Linux: 24.5%                      │
├──────────────────────────────────────────────┤
│ Red Hat Enterprise Linux (RHEL): 14.1%       │
├──────────────────────────────────────────────┤
│ AlmaLinux / Rocky Linux (CentOS heirs): 10.8%│
├──────────────────────────────────────────────┤
│ Others (Alpine, Amazon Linux, SUSE): 4.4%    │
└──────────────────────────────────────────────┘

https://nextgen.pk/blog/linux-and-windows-server-market-share-statistics

[weizhouapache]

for your information, I am working on replacing built-in templates with debian 13 templates, which is built on top of debian 13 cloud images (refer to @NuxRo 's comments and replies)

[dheeraj12347]

Hi @NuxRo, @weizhouapache,

I've completed an initial static review of the Debian 13 candidate build script and prepared a QA checklist covering VM deployment, networking, SSH-key injection, root-password handling, user-data, cloud-init, and reboot behavior.

A few observations from the review:

1. The generated 99_cloudstack.cfg contains two system_info keys. PyYAML 6.0.1 accepts the configuration and retains the second mapping, but I haven't established whether this causes any functional issue with the target Debian 13 cloud-init version.
2. The build script conditionally enables root SSH password login when the current root-password hash differs from the saved initial hash. This behavior still needs validation against CloudStack password injection and the intended security policy.
3. I couldn't find an explicit checksum verification of the downloaded Debian base image before customization. I also developed a small SHA-512 verification proof of concept and tested it with local fixtures; it has not been integrated into the build script or tested against the actual image.

I haven't deployed the candidate because I currently don't have access to a CloudStack test environment, so these are static observations rather than confirmed runtime defects.

Would you recommend focusing next on improving the build script's image-integrity verification, or is there another specific part of the Debian 13 template that would be more useful for me to investigate?

Thanks!

[NuxRo]

@dheeraj12347 well spotted the double key, I edited my script.
Re 2, not sure what you mean by that. The behaviour of the default template is that it should be accessible with "password" locally, but doing so via SSH is dangerous, so that's why going through all that dance.

[nickaccuweb]

@dheeraj12347

Thanks for reviewing the script and sharing your findings.

I think checksum verification would be a good starting point. After that, I'd suggest checking the root password and SSH login behavior to make sure everything works securely with CloudStack.

The duplicate system_info keys are also worth fixing.

Of course, we'll still need to test the template in a real CloudStack environment to confirm everything works as expected.

Nick R
Accuweb.Cloud