11:26 a.m.
<http://mattdm.fedorapeople.org/cloud-images/>
This is a basic Fedora 18 spin designed to work in OpenStack and other
private cloud environments. It's configured with cloud-init so it will take
advantage of ec2-compatible metadata services for provisioning ssh keys.
That also currently creates an ec2-user account; we'll probably want to make
that something generic by default in a future iteration. The root password
is empty by default.
These images were built using appliance-creator and the kickstart files from
http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic
They include the final F18 release plus all relevant zero-day updates.
Note that unlike the standard F18 install, this image has /tmp on disk
rather than in tmpfs, since memory is usually at a premium.
The raw.xz files are compressed raw images; they consist of 10GB of mostly
zeros and will need to be uncompressed to use. The .qcow2 images are also
compressed but can be used immediately by anything which (like OpenStack
Glance) can use that format natively.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:32 a.m.
Hi Matt,
<http://mattdm.fedorapeople.org/cloud-images/>
This is a basic Fedora 18 spin designed to work in OpenStack and other
private cloud environments. It's configured with cloud-init so it will take
advantage of ec2-compatible metadata services for provisioning ssh keys.
That also currently creates an ec2-user account; we'll probably want to make
that something generic by default in a future iteration. The root password
is empty by default.
These images were built using appliance-creator and the kickstart files from
http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic
They include the final F18 release plus all relevant zero-day updates.
Note that unlike the standard F18 install, this image has /tmp on disk
rather than in tmpfs, since memory is usually at a premium.
The raw.xz files are compressed raw images; they consist of 10GB of mostly
zeros and will need to be uncompressed to use. The .qcow2 images are also
compressed but can be used immediately by anything which (like OpenStack
Glance) can use that format natively.
I'm the creator and current maintainer of the (unfortunately rather
old) Fedora 16 image in the HP cloud (www.hpcloud.com) which runs
OpenStack. I'm very much interested in leveraging Fedora-built images
so that I can get out of the business of building guest images for the
HP cloud :-)
I took your qcow2 64-bit image for a spin and identified the following
issues when running it in our environment:
1) The default username ec2-user is too Amazon centric. I don't know
what the greater implications are of changing the default user but I'd
rather see something generic like 'fedora'.
2) The console log is empty. It would be rather helpful to add
'console=ttyS0' for debugging potential boot issues.
3) There's no growroot initramfs script so the root partition doesn't
get automatically enlarged to consume the whole disk. I'm working on
creating the missing packages cloud-utils and cloud-initramfs-tools. I
have them ready for EPEL 6 but not yet Fedora because it uses GPT.
4) dnsdomainname returns 'localhost' when it should return 'novalocal'
in our environment. Quite frankly I don't know how the domainname is
retrieved and need to look into it.
5) The timezone is set to EST which doesn't necessarily match the
location of the VM. I think UTC would make more sense.
6) Is there a file with the image version or builddate somewhere in
the image? I couldn't find one but think it's a useful thing to have.
Do you think these could be addressed with a single generic image that
works both in EC2 and OpenStack, just like Canonical's Ubuntu images?
Let me know what you think and how I can help.
Also, would you (or the greater Fedora project in general) be
interested in a free account in the HP cloud? I think I should be able
to make that happen. Note that at the moment user's can't upload their
own images, they all have to be uploaded by HP (read me) until we make
the Glance API publicly available.
Regards
...Juerg
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
9:05 a.m.
On Wed, Jan 16, 2013 at 03:32:04PM +0100, Juerg Haefliger wrote:
Hi Matt,
Hi! Thanks for your comments and interest -- it's very helpful.
1) The default username ec2-user is too Amazon centric. I don't
know
what the greater implications are of changing the default user but I'd
rather see something generic like 'fedora'.
Yeah, I think there's general agreement about that, but we couldn't come to
agreement about what it should be, so we stuck with that for this release.
2) The console log is empty. It would be rather helpful to add
'console=ttyS0' for debugging potential boot issues.
Good suggestion.
3) There's no growroot initramfs script so the root partition
doesn't
get automatically enlarged to consume the whole disk. I'm working on
creating the missing packages cloud-utils and cloud-initramfs-tools. I
have them ready for EPEL 6 but not yet Fedora because it uses GPT.
Cool. Let's put that in the plan for F19.
4) dnsdomainname returns 'localhost' when it should return
'novalocal'
in our environment. Quite frankly I don't know how the domainname is
retrieved and need to look into it.
Let me know what you find and if there are any fixes needed.
5) The timezone is set to EST which doesn't necessarily match
the
location of the VM. I think UTC would make more sense.
I think you're right; anyone object?
6) Is there a file with the image version or builddate somewhere in
the image? I couldn't find one but think it's a useful thing to have.
There is not. I suppose we could write it to /etc/issue or to /etc/motd.
Do you think these could be addressed with a single generic image
that
works both in EC2 and OpenStack, just like Canonical's Ubuntu images?
We'd like to as much as possible, yeah.
Let me know what you think and how I can help.
The above is a great start. Are you coming to FUDcon?
Also, would you (or the greater Fedora project in general) be
interested in a free account in the HP cloud? I think I should be able
to make that happen. Note that at the moment user's can't upload their
own images, they all have to be uploaded by HP (read me) until we make
Yes, that would be very helpful. Thanks!
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:09 a.m.
On Wed, Jan 16, 2013 at 4:05 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Wed, Jan 16, 2013 at 03:32:04PM +0100, Juerg Haefliger wrote:
> Hi Matt,
Hi! Thanks for your comments and interest -- it's very helpful.
> 1) The default username ec2-user is too Amazon centric. I don't know
> what the greater implications are of changing the default user but I'd
> rather see something generic like 'fedora'.
Yeah, I think there's general agreement about that, but we couldn't come to
agreement about what it should be, so we stuck with that for this release.
> 2) The console log is empty. It would be rather helpful to add
> 'console=ttyS0' for debugging potential boot issues.
Good suggestion.
> 3) There's no growroot initramfs script so the root partition doesn't
> get automatically enlarged to consume the whole disk. I'm working on
> creating the missing packages cloud-utils and cloud-initramfs-tools. I
> have them ready for EPEL 6 but not yet Fedora because it uses GPT.
Cool. Let's put that in the plan for F19.
What's the drop dead date for getting stuff into F19? Speaking of
EPEL6, I'm not that familiar with the Fedora/EPEL build process and
was wondering if I need to create a single src RPM that can produce
both EPEL and Fedora RPMs or can I have two different src RPMs one for
Fedora and one for EPEL with different contents (and different spec
files)?
> 4) dnsdomainname returns 'localhost' when it should
return 'novalocal'
> in our environment. Quite frankly I don't know how the domainname is
> retrieved and need to look into it.
Let me know what you find and if there are any fixes needed.
> 5) The timezone is set to EST which doesn't necessarily match the
> location of the VM. I think UTC would make more sense.
I think you're right; anyone object?
> 6) Is there a file with the image version or builddate somewhere in
> the image? I couldn't find one but think it's a useful thing to have.
There is not. I suppose we could write it to /etc/issue or to /etc/motd.
> Do you think these could be addressed with a single generic image that
> works both in EC2 and OpenStack, just like Canonical's Ubuntu images?
We'd like to as much as possible, yeah.
> Let me know what you think and how I can help.
The above is a great start. Are you coming to FUDcon?
Unfortunatley no. That's a little bit of a short notice :-)
> Also, would you (or the greater Fedora project in general) be
> interested in a free account in the HP cloud? I think I should be able
> to make that happen. Note that at the moment user's can't upload their
> own images, they all have to be uploaded by HP (read me) until we make
Yes, that would be very helpful. Thanks!
Ok, I'll start to bug people.
...Juerg
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
4:46 p.m.
On Thu, Jan 17, 2013 at 05:09:29PM +0100, Juerg Haefliger wrote:
What's the drop dead date for getting stuff into F19? Speaking
of
EPEL6, I'm not that familiar with the Fedora/EPEL build process and
The feature deadline is January 29th. However, not everything needs to be a
feature. (Enhanceents like this might not be really a "feature", although we
could make a "make cloud image better" feature.) The rest of the F19
schedule isn't set yet, but in general if we have the packages there before
the branch from rawhide it's nicer.
was wondering if I need to create a single src RPM that can produce
both EPEL and Fedora RPMs or can I have two different src RPMs one for
Fedora and one for EPEL with different contents (and different spec
files)?
It's nicest to keep them as close as possible but you can have them be
completely different if you want.
> The above is a great start. Are you coming to FUDcon?
Unfortunatley no. That's a little bit of a short notice :-)
Next time. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:48 a.m.
On Wed, Jan 16, 2013 at 4:05 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Wed, Jan 16, 2013 at 03:32:04PM +0100, Juerg Haefliger wrote:
> Hi Matt,
Hi! Thanks for your comments and interest -- it's very helpful.
> 1) The default username ec2-user is too Amazon centric. I don't know
> what the greater implications are of changing the default user but I'd
> rather see something generic like 'fedora'.
Yeah, I think there's general agreement about that, but we couldn't come to
agreement about what it should be, so we stuck with that for this release.
> 2) The console log is empty. It would be rather helpful to add
> 'console=ttyS0' for debugging potential boot issues.
Good suggestion.
> 3) There's no growroot initramfs script so the root partition doesn't
> get automatically enlarged to consume the whole disk. I'm working on
> creating the missing packages cloud-utils and cloud-initramfs-tools. I
> have them ready for EPEL 6 but not yet Fedora because it uses GPT.
Cool. Let's put that in the plan for F19.
> 4) dnsdomainname returns 'localhost' when it should return
'novalocal'
> in our environment. Quite frankly I don't know how the domainname is
> retrieved and need to look into it.
Let me know what you find and if there are any fixes needed.
Hmm. Can't reproduce this anymore. Maybe my environment was misconfigured.
> 5) The timezone is set to EST which doesn't necessarily match
the
> location of the VM. I think UTC would make more sense.
I think you're right; anyone object?
> 6) Is there a file with the image version or builddate somewhere in
> the image? I couldn't find one but think it's a useful thing to have.
There is not. I suppose we could write it to /etc/issue or to /etc/motd.
7) [ec2-user@juergh-96-3-015558-001 ~]$ sudo sgdisk -i 2 /dev/vda | grep code
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
The partition code of the root partition is 0700 (Microsoft basic
data). How did that happen??
...Juerg
> Do you think these could be addressed with a single generic image
that
> works both in EC2 and OpenStack, just like Canonical's Ubuntu images?
We'd like to as much as possible, yeah.
> Let me know what you think and how I can help.
The above is a great start. Are you coming to FUDcon?
> Also, would you (or the greater Fedora project in general) be
> interested in a free account in the HP cloud? I think I should be able
> to make that happen. Note that at the moment user's can't upload their
> own images, they all have to be uploaded by HP (read me) until we make
Yes, that would be very helpful. Thanks!
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
11:51 a.m.
On Tue, Jan 15, 2013 at 12:26 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
<http://mattdm.fedorapeople.org/cloud-images/>
This is a basic Fedora 18 spin designed to work in OpenStack and other
private cloud environments. It's configured with cloud-init so it will take
advantage of ec2-compatible metadata services for provisioning ssh keys.
That also currently creates an ec2-user account; we'll probably want to make
that something generic by default in a future iteration. The root password
is empty by default.
These images were built using appliance-creator and the kickstart files from
http://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/generic
They include the final F18 release plus all relevant zero-day updates.
Note that unlike the standard F18 install, this image has /tmp on disk
rather than in tmpfs, since memory is usually at a premium.
The raw.xz files are compressed raw images; they consist of 10GB of mostly
zeros and will need to be uncompressed to use. The .qcow2 images are also
compressed but can be used immediately by anything which (like OpenStack
Glance) can use that format natively.
Just a quick data point here: I downloaded the raw.xz onto a CentOS 6
system, and ran unxz on it. It seems the version of xz there does not
preserve the file's sparseness. Fedora 17 and 18 have new enough xz
that they work fine, but I wonder if it would be worth encapsulating
the sparse file inside tar (i.e., make a tar.xz file) to work around
this for older systems. I'm not sure how much people care, but it's a
simple change.
Andy
12:37 p.m.
On Wed, Jan 16, 2013 at 12:51:14PM -0500, Andy Grimm wrote:
Just a quick data point here: I downloaded the raw.xz onto a CentOS
6
system, and ran unxz on it. It seems the version of xz there does not
preserve the file's sparseness. Fedora 17 and 18 have new enough xz
that they work fine, but I wonder if it would be worth encapsulating
the sparse file inside tar (i.e., make a tar.xz file) to work around
this for older systems. I'm not sure how much people care, but it's a
simple change.
Sure, I'll go ahead and do that. It'll take a little bit, because it takes
my system a very long time to xz the file. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:54 p.m.
On Wed, Jan 16, 2013 at 1:37 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Wed, Jan 16, 2013 at 12:51:14PM -0500, Andy Grimm wrote:
> Just a quick data point here: I downloaded the raw.xz onto a CentOS 6
> system, and ran unxz on it. It seems the version of xz there does not
> preserve the file's sparseness. Fedora 17 and 18 have new enough xz
> that they work fine, but I wonder if it would be worth encapsulating
> the sparse file inside tar (i.e., make a tar.xz file) to work around
> this for older systems. I'm not sure how much people care, but it's a
> simple change.
Sure, I'll go ahead and do that. It'll take a little bit, because it takes
my system a very long time to xz the file. :)
Just tried one of the new files to make sure it works. Much better, thanks!
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
4098
days inactive
4113
days old
8 comments
3 participants
participants (3)
-
Andy Grimm -
Juerg Haefliger -
Matthew Miller