Official Fedora Cloud images are now available from http://cloud.fedoraproject.org/fedora-$release.$arch.qcow2 where "$release" is either "latest" or "19" (and eventually 20 and so on) and $arch is x86_64 or i386. It would be awesome to make this easily available to RDO users. The current x86_64 image is 226MB. There are several ways this could be done -- perhaps the easiest is to add a bit to packstack which will add the Fedora images after configuring glance. That way, newly deployed clouds will automatically have nice runnable images ready to go.
This would be certainly a great usability improvement. Big +1 from me. A few questions come to my mind though: - Should Packstack download +200Mb as part of a regular deployment? If not activated by a flag, I guess we should provide a CLI flag to disable this feature. - Would it be acceptable to consume the images without checking their GnuPG signature? - Would it be worth caching the image just in case packstack is run again? - It's clearly a convenience feature, so it'd go for keeping it as simple as possible, and just download the latest stable version of Fedora. It'd be fairly simple for the user to add more images, so I cannot see any reason to implement anything more complex than that.
(In reply to Alvaro Lopez Ortega from comment #1) > - Should Packstack download +200Mb as part of a regular deployment? If not > activated by a flag, I guess we should provide a CLI flag to disable this > feature. it should be disabled by default, and enabled by explicit passing of a config option or cmdline flag like: --download-fedora-image Or something > - Would it be acceptable to consume the images without checking their GnuPG > signature? I think this should be checked, yes > - Would it be worth caching the image just in case packstack is run again? Indeed. Question is where should it be cached? packstack should not require root privs to run and does not need to run explicitly in a users homedir. So should the image just be cached to current directory? Or do we just put into /var/tmp? > - It's clearly a convenience feature, so it'd go for keeping it as simple as > possible, and just download the latest stable version of Fedora. It'd be > fairly simple for the user to add more images, so I cannot see any reason to > implement anything more complex than that. Agreed. Latest stable x86_64 image should be the goal.
The provision puppet module enables to download only one image currently. So the proposed solution would be to add option to Packstack which will enable selection of image to download. Cirros will be the default.
Looking at the provision manifest from puppet-openstack module and considering Puppet possibilities it probably won't be possible to modify module to accept more than one image unless duplicating relevant parameters of openstack::provision class. So in case it is really necessary to have Fedora image as a second, we would need to paste glance_image resource to Packstack's provision manifest. CC'ing Ryan in case he has different opinion.
(In reply to Perry Myers from comment #2) > > - Would it be acceptable to consume the images without checking their GnuPG > > signature? > > I think this should be checked, yes Additionally the address Matt provided is also available via https, so ideally use that for the download instead of plain http - just my 2c.
(In reply to Stephen Gordon from comment #5) > (In reply to Perry Myers from comment #2) > > > - Would it be acceptable to consume the images without checking their GnuPG > > > signature? > > > > I think this should be checked, yes > > Additionally the address Matt provided is also available via https, so > ideally use that for the download instead of plain http - just my 2c. Two things of note here. First, the URL links above are powered by MirrorManager, and should return a roughly-geographically-appropriate mirror (by country at least). That mirror may be plain http instead of https. In fact, it's very likely to be. I don't think it hurts to use https initially but it doesn't necessarily gain much. (On the plus side, because mirrormananger is smart like that, it should take about 10 seconds to download the qcow2 on a typical i2-connceted university network.) Second, the images aren't GPG signed. They are accompanied by a checksum file which *is* signed. There's no short URL for that but the general mirrormanager redirector can be used; e.g. http://download.fedoraproject.org/pub/fedora/linux/releases/19/Images/x86_64/Fedora-Images-x86_64-19-CHECKSUM You could either pull that file and verify the signature and use the checksum, or just hardcode the per-release checksum in packstack. (We're working with the security team on providing updated images at some point, but right now they stay the same for the lifetime of the release.)
(In reply to Alvaro Lopez Ortega from comment #1) > - Should Packstack download +200Mb as part of a regular deployment? With F20 beta, we're actually down to a smidge under 200MB as qcow2, and 117MB as raw.xz. Is there a particular (exact or vague) threshold that it'd be worthwhile working towards?
Where do we draw the line between Packstack provisioning from configuration features? Would it make sense to decouple the two? It seems there are more likely other images or default values that would be helpful. In such case, a separate tool to seed OpenStack could be used and - Could be called from Packstack but not build-in. - Could be reused separately (Foreman?). My 2c divide and conquer approach.
[Triaging bugs here.] It's been 8 months, any movement or agreement on approach for having this option in Packstack?
Arthur, we have a hand from you here.
(In reply to Alvaro Lopez Ortega from comment #10) > Arthur, we have a hand from you here. It seems a very nice addition. I agree with comment#2 it should be an opt-in feature. Also, we need to make sure with downstream PackStack in OSP, it downloads the supported "RHEL Guest Image"[1] instead of Fedora Cloud Image. [1] https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.0/x86_64/product-downloads
FWIW, we're down to 100MB raw.xz and 151MB qcow2. :)
I've proposed a change upstream that would make this configureable: https://review.openstack.org/#/c/165576/