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.
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@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
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.
- 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.
- The console log is empty. It would be rather helpful to add
'console=ttyS0' for debugging potential boot issues.
Good suggestion.
- 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.
- 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.
- 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?
- 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!
On Wed, Jan 16, 2013 at 4:05 PM, Matthew Miller mattdm@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.
- 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.
- The console log is empty. It would be rather helpful to add
'console=ttyS0' for debugging potential boot issues.
Good suggestion.
- 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)?
- 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.
- 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?
- 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@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
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. :)
On Wed, Jan 16, 2013 at 4:05 PM, Matthew Miller mattdm@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.
- 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.
- The console log is empty. It would be rather helpful to add
'console=ttyS0' for debugging potential boot issues.
Good suggestion.
- 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.
- 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.
- 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?
- 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@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
On Tue, Jan 15, 2013 at 12:26 PM, Matthew Miller mattdm@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
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. :)
On Wed, Jan 16, 2013 at 1:37 PM, Matthew Miller mattdm@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@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
-
Andy Grimm -
Juerg Haefliger -
Matthew Miller