On Thu, Jun 11, 2015 at 12:53:42PM -0400, Josh Boyer wrote: > You can get around this with on-the-fly image generation as I > previously mentioned, or by creating a small (and I mean small in > number not size) set of images that are flexible enough to hit the > major categories while not being strictly tied 1:1 to a particular > technology. E.g. you have a "Cloud Container image" that can be used > for Docker, rkt, or systemd-nspawn. Yes, that makes it potentially > larger in size but it also means you have less to QA, market, and > carry. The bitnami link I sent before was probably a bit broad; our previous dicussions were more around something like this: <https://bitnami.com/stacks/infrastructure> -- which I think matches what you are saying. And I *do* think it'd be nice to have an "app store" built on top of that. First, though, the Cloud Base image, which is intended to underly all of that (and also be, as we have said, a generic platform to build up anything). Size _does_ matter, though, because it translates directly into network transfer and deploy time. Python is in the crosshairs because it's relatively large. In fact, with your kernel-core stuff and the glibc documentation split, it's the biggest thing (coming in just above systemd). Well, and linux-firmware, which isn't needed at runtime but is pulled in for kernel upgrades, and which to my knowledge is not needed in any cloud environments. You might be the right person to talk to about figuring out if we can do anything about this. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
