the cloud images for the mirrors

[Matthew Miller]

So, assuming we have a Go at the meeting tomorrow, what do we need to get
the cloud images onto the mirrors?

As we discussed before (in the cloud sig), we'd like both xz-compressed raw
and non-compressed qcow2 images. This seems to cover primary cases of
something generic that can be translated to many formats and something which
can be used immediately.

I think what we want is images built from a non-ec2-specific kickstart from
http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic.

There are several options there, and I *think* the "-cloud" one makes most
sense. It has cloud-init and should work in a number of different cloud
providers with different metadata services. Unlike the ec2 images, these use
grub2 by default so should boot with anything (e.g., KVM) which will just
boot an image. In any case, I've tested these to some degree, and although
with some big changes at the last minute it's not certain, I don't think
there's any brown-paper bag mistakes. It'd be good to spin up the official
image builds in the Fedora internal cloud, of course.

Then, those images should _go_ somewhere -- possibly "releases/18/Cloud/",
or else "releases/18/Fedora/[arch]/cloud".

[Bill Nottingham]

Matthew Miller ([e-mail]) said:
> So, assuming we have a Go at the meeting tomorrow, what do we need to get
> the cloud images onto the mirrors?
>
> As we discussed before (in the cloud sig), we'd like both xz-compressed raw
> and non-compressed qcow2 images. This seems to cover primary cases of
> something generic that can be translated to many formats and something which
> can be used immediately.
>
> I think what we want is images built from a non-ec2-specific kickstart from
> http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic.
>
> There are several options there, and I *think* the "-cloud" one makes most
> sense. It has cloud-init and should work in a number of different cloud
> providers with different metadata services. Unlike the ec2 images, these use
> grub2 by default so should boot with anything (e.g., KVM) which will just
> boot an image. In any case, I've tested these to some degree, and although
> with some big changes at the last minute it's not certain, I don't think
> there's any brown-paper bag mistakes. It'd be good to spin up the official
> image builds in the Fedora internal cloud, of course.
>
> Then, those images should _go_ somewhere -- possibly "releases/18/Cloud/",
> or else "releases/18/Fedora/[arch]/cloud".

Hm, they're not *really* cloud specific, though - they could be used in
virt-manager/boxes, or even (I suppose) splatted onto a raw disk. Is there
a  more generic name that could be used?

Bill

[Seth Vidal]

On Wed, 2 Jan 2013, Bill Nottingham wrote:
> > Then, those images should _go_ somewhere -- possibly "releases/18/Cloud/",
> > or else "releases/18/Fedora/[arch]/cloud".
>
> Hm, they're not *really* cloud specific, though - they could be used in
> virt-manager/boxes, or even (I suppose) splatted onto a raw disk. Is there
> a  more generic name that could be used?

virt-imgs?

And the 'splatted onto a raw disk' is a case I don't really care to worry 
about including in what label we apply here.

-sv

[Matthew Miller]

On Wed, Jan 02, 2013 at 03:13:04PM -0500, Bill Nottingham wrote:
> > Then, those images should _go_ somewhere -- possibly "releases/18/Cloud/",
> > or else "releases/18/Fedora/[arch]/cloud".
>
> Hm, they're not *really* cloud specific, though - they could be used in
> virt-manager/boxes, or even (I suppose) splatted onto a raw disk. Is there
> a  more generic name that could be used?

Virt? I think anything more generic than that is likely to confuse people.
And the cloud-init-enabled versions really do make some cloudy assumptions
(they look for a metadata service, for example).

My vote is to go with Cloud because that's the primary target.

[Seth Vidal]

On Wed, 2 Jan 2013, Matthew Miller wrote:
> On Wed, Jan 02, 2013 at 03:13:04PM -0500, Bill Nottingham wrote:
> > > Then, those images should _go_ somewhere -- possibly "releases/18/Cloud/",
> > > or else "releases/18/Fedora/[arch]/cloud".
> >
> > Hm, they're not *really* cloud specific, though - they could be used in
> > virt-manager/boxes, or even (I suppose) splatted onto a raw disk. Is there
> > a  more generic name that could be used?
>
> Virt? I think anything more generic than that is likely to confuse people.
> And the cloud-init-enabled versions really do make some cloudy assumptions
> (they look for a metadata service, for example).
>
> My vote is to go with Cloud because that's the primary target.

If the cloud-init bits are in there then +1 to cloud.

-sv

[Bill Nottingham]

Seth Vidal ([e-mail]) said:
> > > Hm, they're not *really* cloud specific, though - they could be used in
> > > virt-manager/boxes, or even (I suppose) splatted onto a raw disk. Is there
> > > a  more generic name that could be used?
> >
> > Virt? I think anything more generic than that is likely to confuse people.
> > And the cloud-init-enabled versions really do make some cloudy assumptions
> > (they look for a metadata service, for example).
> >
> > My vote is to go with Cloud because that's the primary target.
>
> If the cloud-init bits are in there then +1 to cloud.

Works for me.

Bill

[Dennis Gilmore]

On Wed, 2 Jan 2013 15:13:04 -0500
Bill Nottingham  wrote:
> Matthew Miller ([e-mail]) said:
> > So, assuming we have a Go at the meeting tomorrow, what do we need
> > to get the cloud images onto the mirrors?
> >
> > As we discussed before (in the cloud sig), we'd like both
> > xz-compressed raw and non-compressed qcow2 images. This seems to
> > cover primary cases of something generic that can be translated to
> > many formats and something which can be used immediately.
> >
> > I think what we want is images built from a non-ec2-specific
> > kickstart from
> > http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic.

Really this should have been added at Alpha or Beta not at the last
second. Im extremely hesitant to produce and ship anything
> > There are several options there, and I *think* the "-cloud" one
> > makes most sense. It has cloud-init and should work in a number of
> > different cloud providers with different metadata services. Unlike
> > the ec2 images, these use grub2 by default so should boot with
> > anything (e.g., KVM) which will just boot an image. In any case,
> > I've tested these to some degree, and although with some big
> > changes at the last minute it's not certain, I don't think there's
> > any brown-paper bag mistakes. It'd be good to spin up the official
> > image builds in the Fedora internal cloud, of course.
> >
> > Then, those images should _go_ somewhere -- possibly
> > "releases/18/Cloud/", or else "releases/18/Fedora/[arch]/cloud".
>
> Hm, they're not *really* cloud specific, though - they could be used
> in virt-manager/boxes, or even (I suppose) splatted onto a raw disk.
> Is there a  more generic name that could be used?

I would follow the same naming as we do for arm disk images
releases/18/Images/<arch>/

Dennis

[Matthew Miller]

On Wed, Jan 09, 2013 at 10:19:24AM -0600, Dennis Gilmore wrote:
> > > I think what we want is images built from a non-ec2-specific
> > > kickstart from
> > > http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic.
>
> Really this should have been added at Alpha or Beta not at the last
> second. Im extremely hesitant to produce and ship anything

It would have been nice, but that's not how it worked out with this
schedule. I apologize for not pushing this thread a little harder last week
so it wouldn't have been quite so last minute.

Anyway, the image is very, very similar to the Amazon image (with the
exception of the addition of grub2). I don't anticipate any problems, but I
would like an RC spin to have people test.

There is _significant_ demand for an image like this.
> > > Then, those images should _go_ somewhere -- possibly
> > > "releases/18/Cloud/", or else "releases/18/Fedora/[arch]/cloud".
> >
> > Hm, they're not *really* cloud specific, though - they could be used
> > in virt-manager/boxes, or even (I suppose) splatted onto a raw disk.
> > Is there a  more generic name that could be used?
>
> I would follow the same naming as we do for arm disk images
> releases/18/Images/<arch>/

That's okay with me too.

[Matthew Miller]

On Wed, Jan 09, 2013 at 10:19:24AM -0600, Dennis Gilmore wrote:
> Really this should have been added at Alpha or Beta not at the last
> second. Im extremely hesitant to produce and ship anything

I would have filed a rel-eng ticket for all of this a while ago, except that
you asked me not to.

[Matthew Miller]

On Wed, Jan 02, 2013 at 03:08:00PM -0500, Matthew Miller wrote:
> I think what we want is images built from a non-ec2-specific kickstart from
> http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic.

In case this helps:

xz-compressed raw is easy, as appliance creator outputs raw and then you
just xz it. (Which on my system takes 15 minutes.)

For qcow2, take the (uncompressed, obviously) raw file and:

qemu-img convert -p -O qcow2 -c Fedora18.raw Fedora18.qcow2

(The -p just gives a percentage bar and is optional; the -c does
compression.)