cloud-init pulls in some, um, not exactly minimal stuff. python-cheetah? (which then brings in, for example, freetype...)
Can we narrow this down without significantly killing functionality?
On Fri, Nov 09, 2012 at 11:16:21AM -0500, Matthew Miller wrote:
cloud-init pulls in some, um, not exactly minimal stuff. python-cheetah? (which then brings in, for example, freetype...)
and python-imaging, and python-pygments.
On Fri, Nov 09, 2012 at 11:28:49AM -0500, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 11:16:21AM -0500, Matthew Miller wrote:
cloud-init pulls in some, um, not exactly minimal stuff. python-cheetah? (which then brings in, for example, freetype...)
and python-imaging, and python-pygments.
All told, cloud-init and dependencies add 50MB to the on-disk size of the current F18 cloud image I'm working on.
Graphics and templating languages. Plus xfsprogs. And a large amount of selinux stuff. And libcgroup, which despite its name is a collection of (somewhat klunky) utilities for something actually handled better by systemd.
Cloud-init is nifty, but this seems like a kitchen sink of random stuff. Opinions, everyone? Should this go in the EC2 cloud image? Should it go in the downloadable one? Should we offer options? Should we have something more lightweight which just pulls in ssh keys?
On Fri, Nov 9, 2012 at 3:20 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Nov 09, 2012 at 11:28:49AM -0500, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 11:16:21AM -0500, Matthew Miller wrote:
cloud-init pulls in some, um, not exactly minimal stuff. python-cheetah? (which then brings in, for example, freetype...)
and python-imaging, and python-pygments.
All told, cloud-init and dependencies add 50MB to the on-disk size of the current F18 cloud image I'm working on.
Graphics and templating languages. Plus xfsprogs. And a large amount of selinux stuff. And libcgroup, which despite its name is a collection of (somewhat klunky) utilities for something actually handled better by systemd.
Cloud-init is nifty, but this seems like a kitchen sink of random stuff. Opinions, everyone? Should this go in the EC2 cloud image? Should it go in the downloadable one? Should we offer options? Should we have something more lightweight which just pulls in ssh keys?
I could see an argument for separating some of the cloud-init plugins into subpackages. Of course, then someone is going to request that cloud-init be executed in such a way that it can install packages and then reread its configuration & load newly installed plugins. That'll be fun. :-)
On Fri, Nov 09, 2012 at 04:27:04PM -0500, Andy Grimm wrote:
I could see an argument for separating some of the cloud-init plugins into subpackages. Of course, then someone is going to request that cloud-init be executed in such a way that it can install packages and then reread its configuration & load newly installed plugins. That'll be fun. :-)
Um, yeah, I thought of that and then decided not to mention it. :)
On 11/09/2012 10:27 PM, Andy Grimm wrote:
I could see an argument for separating some of the cloud-init plugins into subpackages. Of course, then someone is going to request that cloud-init be executed in such a way that it can install packages and then reread its configuration& load newly installed plugins. That'll be fun.:-)
This would make it makes easier to deploy custom plugins. Currently we need to add them in the image, which is cumbersome.
So yes, it would be fun, but it would also be great :)
cheers, Jan
On Fri, Nov 9, 2012 at 2:34 PM, Florian La Roche Florian.LaRoche@gmx.net wrote:
All told, cloud-init and dependencies add 50MB to the on-disk size of the current F18 cloud image I'm working on.
Ow. That's a lot more than I expected. :-\
It's precisely the fact that it's built into the image that makes cloud-init so useful. You only get one user-data file when you run an instance, so if we remove cloud-init from the image and make using it a multi-step bootstrapping process then there isn't much point in offering it at all. Maybe there's a way to make it more modular.
There should be a minimal version of it, whatever the packaging solution then looks like...
Right now it relies on a config file to list what plugins it's supposed to run since said list of plugins can differ by distro, but I bet one could make it try to compute the list automatically by looking at all of the plugins. Once it can do that, making it run with the additional plugins should actually be quite straightforward.
On Tue, Nov 13, 2012 at 02:59:50PM -0800, Garrett Holmstrom wrote:
It's precisely the fact that it's built into the image that makes cloud-init so useful. You only get one user-data file when you run an instance, so if we remove cloud-init from the image and make using it a multi-step bootstrapping process then there isn't much point in offering it at all. Maybe there's a way to make it more modular.
You can ask for that user-data file more than once, though. It'd be kind of nice if *that* listed the plugins needed.
On Tue, Nov 13, 2012 at 3:59 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Nov 13, 2012 at 02:59:50PM -0800, Garrett Holmstrom wrote:
It's precisely the fact that it's built into the image that makes cloud-init so useful. You only get one user-data file when you run an instance, so if we remove cloud-init from the image and make using it a multi-step bootstrapping process then there isn't much point in offering it at all. Maybe there's a way to make it more modular.
You can ask for that user-data file more than once, though. It'd be kind of nice if *that* listed the plugins needed.
You might actually be able to do that now, but cloud-init doesn't yet have a way to install plugins that are missing. If that gets implemented then this becomes easy! :-)
On Tue, Nov 13, 2012 at 04:27:45PM -0800, Garrett Holmstrom wrote:
You can ask for that user-data file more than once, though. It'd be kind of nice if *that* listed the plugins needed.
You might actually be able to do that now, but cloud-init doesn't yet have a way to install plugins that are missing. If that gets implemented then this becomes easy! :-)
What about a service that runs before cloud-init itself, scans the user-data for needed plugins, and then yum-installs them if they're missing?
It woudn't have to be that smart -- if it hit something complicated, it could just throw up its hands and install the whole shebang.
The primary downside I can see is that it's probably slower to do that than to just have it all there.
I'm kinda thinking we should offer a super-small-no-cloud-init image (maybe even stripped of locale info and whatever), and a larger "batteries included" version.
On Tue, Nov 13, 2012 at 4:38 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Nov 13, 2012 at 04:27:45PM -0800, Garrett Holmstrom wrote:
You can ask for that user-data file more than once, though. It'd be kind of nice if *that* listed the plugins needed.
You might actually be able to do that now, but cloud-init doesn't yet have a way to install plugins that are missing. If that gets implemented then this becomes easy! :-)
What about a service that runs before cloud-init itself, scans the user-data for needed plugins, and then yum-installs them if they're missing?
It woudn't have to be that smart -- if it hit something complicated, it could just throw up its hands and install the whole shebang.
The primary downside I can see is that it's probably slower to do that than to just have it all there.
That isn't going to work for every case, but it sounds like a great "90%" starting point. Maybe a little script could read user-data, and if it contains cloud-config data, the script reads that and takes action on the bits that it has to.
What do you folks think? Anyone itching to give it a try?
On Tue, Nov 13, 2012 at 05:05:42PM -0800, Garrett Holmstrom wrote:
What about a service that runs before cloud-init itself, scans the user-data for needed plugins, and then yum-installs them if they're missing?
That isn't going to work for every case, but it sounds like a great "90%" starting point. Maybe a little script could read user-data, and if it contains cloud-config data, the script reads that and takes action on the bits that it has to.
What do you folks think? Anyone itching to give it a try?
I can take a stab at it. Any suggestions for how we should split up the cloud-init package?
On 11/14/2012 01:02 PM, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 05:05:42PM -0800, Garrett Holmstrom wrote:
What about a service that runs before cloud-init itself, scans the user-data for needed plugins, and then yum-installs them if they're missing?
That isn't going to work for every case, but it sounds like a great "90%" starting point. Maybe a little script could read user-data, and if it contains cloud-config data, the script reads that and takes action on the bits that it has to.
What do you folks think? Anyone itching to give it a try?
I can take a stab at it. Any suggestions for how we should split up the cloud-init package?
Having a service that scans the user-data and then attempts to yum installing needed bits at boot time might be problematic. It might guess wrong at the needed packages, it might not have the access to expected repos...
Another approach might be to create a very simple cloud-init that only acts on a user-data shell script and rely on the user to write there own shell scripts.
This could result in a very small piece of code that only does what the user provided script does and the user should know best what they want to do.
This would keep the solution small and simple and, I could be wrong, but I think this approach could satisfy the needs of many users.
Just a thought. Joe
Hi,
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
Any advice appreciated.
Regards Chris Horn
On Thu, Nov 15, 2012 at 4:12 AM, Chris Horn hosting@cristabel.com.au wrote:
Hi,
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
Any advice appreciated.
File a ticket with rel-eng as I believe it's them that push the AMIs out to the various EC2 instances.
https://fedorahosted.org/rel-eng/newticket
Peter
On Thu, Nov 15, 2012 at 03:12:19PM +1100, Chris Horn wrote:
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
Release engineering does it.
However, when we move to the new AWS Marketplace, we'll provide one image and Amazon will copy it to the other regions, including adding it to new regions as they come online.
Thanks Peter and Matthew for the information. I have put a ticket in with Release Engineering.
On 16/11/12 2:08 AM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Thu, Nov 15, 2012 at 03:12:19PM +1100, Chris Horn wrote:
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
Release engineering does it.
However, when we move to the new AWS Marketplace, we'll provide one image and Amazon will copy it to the other regions, including adding it to new regions as they come online.
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 16 Nov 2012 10:13:29 +1100 Chris Horn hosting@cristabel.com.au escribió:
Thanks Peter and Matthew for the information. I have put a ticket in with Release Engineering.
On 16/11/12 2:08 AM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Thu, Nov 15, 2012 at 03:12:19PM +1100, Chris Horn wrote:
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
ap-southeast-2 x86_64 EBS-backed ami-e3a433d9 ap-southeast-2 i386 EBS-backed ami-87a433b
Thanks Dennis.
On 27/11/12 11:00 PM, "Dennis Gilmore" dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 16 Nov 2012 10:13:29 +1100 Chris Horn hosting@cristabel.com.au escribió:
Thanks Peter and Matthew for the information. I have put a ticket in with Release Engineering.
On 16/11/12 2:08 AM, "Matthew Miller" mattdm@fedoraproject.org wrote:
On Thu, Nov 15, 2012 at 03:12:19PM +1100, Chris Horn wrote:
Just wondering if anyone knows who builds the Fedora AMI images on Amazon AWS. With the new Sydney Data Centre just being opened, I am keen to use Fedora there. I tried copying an existing image from another region, but ran into all sorts of problems.
ap-southeast-2 x86_64 EBS-backed ami-e3a433d9 ap-southeast-2 i386 EBS-backed ami-87a433b -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlC0q2AACgkQkSxm47BaWfeRtACghXpe2cOe+O2rEuVYXy0lv6Td 3PcAn0b/BwNzkc6kdLAy3S+G2w2ceWUy =RL2j -----END PGP SIGNATURE----- _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
-
Andy Grimm -
Chris Horn -
Dennis Gilmore -
Florian La Roche -
Garrett Holmstrom -
Jan van Eldik -
Joseph VLcek -
Matthew Miller -
Peter Robinson