There are lot of howtos to create a generic openstack image, and even some specific to gentoo. That would probably means pre-installing app-emulation/openstack-guest-agents-unix app-emulation/cloud-init Ideally building of such an image would be automatic (such as, i guess, current ISO), not a "one shot" release that would quickly become obsolate. And there would be some documentation on how to use it, too ;-) I could help doing it. Reproducible: Always
> There are lot of howtos to create a generic openstack image, and even some specific to gentoo. Can you provide a link or links to some guides that you find particular well written?
This link was mentionned on the forum http://blog.condi.me/base/ It provides an image, must mort importantly it says how it was done. Quite old (2013), but still interesting i think.
I've rummaged around a bit and am working on a mostly automated tool to build images. I'll post the results on github in the next day or two after a bit more testing.
OK, it's pretty crude but I feel it's in good enough shape for some feedback at this point. https://github.com/travisghansen/gentoo-cloud-image-builder It produces a workable image for me anyway. Biggest issue I've seen so far is newly attached volumes don't automagically appear like some kernel param is missing or something.
Hi travis, I tried your scripts. I got a bunch of modification that i'd like to talk to you. Ever on IRC ? My nick is 'orzel'. Most importantly, the chroot env wont be able to resolve name until /etc/resolv.conf is copied to /mnt/gentoo/etc (as done in the official gentoo installation guide). This prevent 'kernel-sources' to be fetched here. (not the other one, i dont know why). Also, i've removed the 'v' argument to tar for portage/stage3, this speeds up untarring. And lot of other misc changes.
Thomas It should be copying over the resolv.conf https://github.com/travisghansen/gentoo-cloud-image-builder/blob/master/builder/full_install.sh#L14 I have no problem removing the v from the tar command either. I'd love to collaborate on the project. Big picture it may be better to approach it completely differently (not boot from the installation cd as it doesn't provide much). For example we could simply create a loopback image on the build host (not a live image booted to qemu) and mount/install/configure from there and only use qemu for testing the final product. That would certainly make it easier to *fully* automate for example which is key IMO. Which channel are you normally in on irc? I generally hang out in #gentoo-desktop (thansen)
I have a very trimmed down kernel at this point and feel like all the options are working as they 'should' for the time being if anyone want to try it out. I'll upload my latest image as an initial 'gold' image at this point. I've tried to enable all the hyperv/xen options as well so if anyone has any experience with either of those it would be great to test the image in those environments.
I do have some images built, but need help with the last step. converting the stage4 to a qcow file via catalyst. http://distfiles.gentoo.org/experimental/amd64/openstack/ Here are my build scripts, it is specifically the third script that I am having trouble with. https://github.com/prometheanfire/gentoo-cloud-prep
Now providing releases here til I can get them built for infra automated like.
Images from http://distfiles.gentoo.org/experimental/amd64/openstack/ work with flavours up to 61,440MB memorry and 12 cores, but Kernel Panic on a 16 core/122,880MB flavour. I've also tried Ubuntu and CentOS 7 images, which work as expected on VMs with this specification, so it appears to be a kernel issue with the openstack-amd64-hardened-nomultilib-20150726.qcow2 image. I'll download the updated image from the 12th August and see whether anything has changed...
Created attachment 409750 [details] Kernel output from failing highmem instance boot Kernel log from openstack-amd64-hardened-nomultilib-20150726.qcow2 image with 16-core/122GB VM. This panic is repeatable with 100% incidence for this flavour, whereas all smaller flavours boot correctly with otherwise the same configuration.
Created attachment 409752 [details] 20150812 image panic Yeah, unfortunately the latest 20150812 image also fails in the same way - log attached :(
I'm pretty sure these stage4's have been available a while now alongside our standard stage3s, please reopen if I'm incorrect http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage4-amd64-cloud/
That's certainly interesting, but i was more thinking about proper actual 'images'. With those images, you need to start an openstack instance, follow the whole install process (and use those tarballs). At the end you stop the instance, and your virtual hard disk is the kind of 'images' i was talking about.
