Bug 982035 - [RFE] Include Fedora cloud images in some nice way
[RFE] Include Fedora cloud images in some nice way
Status: CLOSED UPSTREAM
Product: RDO
Classification: Community
Component: openstack-packstack (Show other bugs)
unspecified
Unspecified Unspecified
high Severity medium
: GA
: Havana
Assigned To: Lars Kellogg-Stedman
Shai Revivo
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-07 19:34 EDT by Matthew Miller
Modified: 2017-01-16 13:50 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-16 13:50:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2013-07-07 19:34:23 EDT
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.
Comment 1 Alvaro Lopez Ortega 2013-10-01 06:06:17 EDT
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.
Comment 2 Perry Myers 2013-10-01 06:21:04 EDT
(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.
Comment 3 Martin Magr 2013-10-01 06:32:26 EDT
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.
Comment 4 Martin Magr 2013-10-01 07:19:06 EDT
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.
Comment 5 Stephen Gordon 2013-10-02 09:27:48 EDT
(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.
Comment 6 Matthew Miller 2013-10-02 10:13:18 EDT
(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.)
Comment 7 Matthew Miller 2013-10-30 10:59:22 EDT
(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?
Comment 8 Gilles Dubreuil 2014-03-18 23:35:00 EDT
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.
Comment 9 Kashyap Chamarthy 2014-12-17 04:35:22 EST
[Triaging bugs here.]

It's been 8 months, any movement or agreement on approach for having this option in Packstack?
Comment 10 Alvaro Lopez Ortega 2014-12-17 06:23:12 EST
Arthur, we have a hand from you here.
Comment 11 Arthur Berezin 2014-12-17 07:51:02 EST
(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
Comment 12 Matthew Miller 2014-12-17 10:09:52 EST
FWIW, we're down to 100MB raw.xz and 151MB qcow2. :)
Comment 13 Lars Kellogg-Stedman 2015-03-18 15:38:23 EDT
I've proposed a change upstream that would make this configureable:

  https://review.openstack.org/#/c/165576/

Note You need to log in before you can comment on or make changes to this bug.