There are some things which can be done from the first boot and don't need to be in the init scripts. So evaluate what can be moved around.

There's a lot of code duplicated between setup-suse-crowbar and setup-suse-crowbar_embedded. This should be extracted out into a separate library file which both appliances consume.

suse_studio_firstboot mounts these ISOs to /mnt and then rsyncs the files to /srv/tftpboot. This makes the firstboot much longer and also needlessly wastes disk space which is a problem on laptops (especially with SSDs!) Instead it should just add entries to fstab to auto-mount the ISOs directly on the target mountpoints.

Some of the code is indented 2 columns, some 4, some not at all ... I recommend 4 columns as that's a pretty common standard.

This golden rule applies everywhere ;-) But the example I am thinking of right now is these new suse-cloud-[34]-admin hierarchies. The industry standard way of dealing with different releases is to use git branches. This brings huge advantages because you can use all the tools in the git ecosystem for managing the branches separately (and in tandem) for standard tasks like comparing, porting, tagging. In contrast, with the current approach you have to do all this stuff manually, and it leads to other ugliness like not being able to restrict git log to commits which only affect Cloud 3 appliances.

So unless there is a really compelling to do this, I'd much prefer to have two branches. I suggest suse-cloud-3 for Cloud 3 and master for Cloud 4.

adding

Remove zypper repos

rm -fv /etc/zypp/repos.d/*

With 1.1.0 it's defaulting to a random hostname and domain name site. It also defaults to changing hostname via DHCP, which we don't want.

Once #5 is addressed, maybe we can start improving the guide so that it gives more details about the differences between the two appliances. Ditto for everything else in this repo.

https://susestudio.com/a/Mrr6vv/suse-openstack-cloud-5-admin links to https://github.com/cseader/suse-cloud-appliances/blob/master/docs/SUSE-Cloud-AA-Guide.md not to the suse-openstack-cloud-5 branch. And unfortunately master still refers to Cloud 4. (Well, so does the suse-openstack-cloud-5 branch, but hopefully you're gonna fix that ;-)

Noticed on several runs, that screen install-suse-cloud errors. In the log, complains of not being able to install ipmitools. With login to system, one can easily search for and find this package, then install-suse-cloud proceeds to completion

The walk-through guide in the suse-openstack-cloud-5 branch still refers to Cloud 4:

https://github.com/cseader/suse-cloud-appliances/blob/suse-openstack-cloud-5/docs/SUSE-Cloud-AA-Guide.md

It should be suse-openstack-cloud-5.

By default the appliance should work without any NCC / SMT registration, to keep the barrier to entry as low as possible. Of course it should still support NCC / SMT setup, but only as a non-intrusive option.

The path of the repository is registered as /SUSE-Cloud-3-Updates and as an ISO. This causes screen install-suse-cloud to apprently hang at that step indefinitely. Correcting this with a login to the system via YaST/Software Repositories by deleting errant entry and pointing to a local directory under /srv/tftpboot/repos/SUSE-Cloud-3-Updates allows the process to complete

I managed to create an appliance which forever does the firstboot thing and then switches to runlevel 0 ...

The guide for the appliance is only linked from the appliance on susestudio.com. Please check it in here so that other people can help editing it.

In most cases people will install with standard network setup, i.e. 192.168.124.10. So it makes sense to make that the default, and to skip the requirement to go through the annoying yast process. But of course there still needs to be an option to change it to non-default.

Please commit the kiwi config you are using, and a README for how to use it would be great too ;-)

Pretty sure there is an SMT server pattern which would be more appropriate than lamp_server.

setup-suse-crowbar_embedded does:

cat /srv/tftpboot/txz/SUSE-Cloud-3-repos-03182014.txz.part0* > /srv/tftpboot/txz/SUSE-Cloud-3-repos-03182014.txz
tar -xJvf /srv/tftpboot/txz/SUSE-Cloud-3-repos-03182014.txz -C $repo_dir

but this instantly eats up a load of disk which is bad for reasons already mentioned in #1 ... and the files are not even removed after extraction (but even if they were, the damage might still be irreversible because of how sparse .qcow2 files work).

So something like this might be better:

if cat /srv/tftpboot/txz/SUSE-Cloud-3-repos-03182014.txz.part0* | tar -xJv -C $repo_dir; then
    rm /srv/tftpboot/txz/SUSE-Cloud-3-repos-03182014.txz.part0*
fi

(I may have got the tar options wrong, but you get the idea - do the concatenation on STDIN/OUT rather than to a temporary file.)

If you work on this, it would be really useful to compare the output of running du on a vdisk of a fully installed appliance with and without this change, to make sure I'm not talking rubbish ;-)

For some reason SUSE Cloud 3 has a problem with bind 9.9 which is part of the updates of SLES 11 SP3. So moving back to the other version fixes the problems it has.

Add SMT ISO on image with small script which can mount and install SMT pattern for using SMT with SUSE Cloud if its needed later.

Change to 3.0 to match mirror repos

Currently the 1GB .tar files are concatenated and unpacked when the appliance is first booted. This is dumb ;-) It means firstboot is really slow, and also it wastes a TON of disk space.

Instead we should make .tar.bz2 files which are overlays, i.e. they get unpacked directly into the appliance's / filesystem at build time. I think it would make sense to have one .tar.bz2 per repo, e.g. SLES11-SP3-Updates.tar.bz2.

Also, we need a simple script which generates these overlay files, so that anyone can regenerate them if they want to rebuild the appliance either via kiwi or via http://susestudio.com.