cseader / suse-cloud-appliances Goto Github PK
View Code? Open in Web Editor NEWSUSE Cloud Admin Appliance
License: GNU General Public License v2.0
SUSE Cloud Admin Appliance
License: GNU General Public License v2.0
suse_studio_firstboot mounts these ISOs to /mnt
and then rsync
s 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.
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.
The walk-through guide in the suse-openstack-cloud-5
branch still refers to Cloud 4:
Please commit the kiwi config you are using, and a README for how to use it would be great too ;-)
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.
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.
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 ;-)
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.
It should be suse-openstack-cloud-5
.
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.
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
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.
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
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 ;-)
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.
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.
Pretty sure there is an SMT server pattern which would be more appropriate than lamp_server
.
Change to 3.0 to match mirror repos
I managed to create an appliance which forever does the firstboot thing and then switches to runlevel 0 ...
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.
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.
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.
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.
adding
rm -fv /etc/zypp/repos.d/*
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.