On Thu, Jun 11, 2015 at 1:12 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > 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). I didn't say size doesn't matter. I'm saying I don't believe cutting python just because it is big is the right choice. We're probably going to have to disagree on this point. > 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. A post install scriptlet that removes the files in the cloud kickstarts is about as far as I'm going to go. I'm not dropping the Requires from the kernel-core package and leave everyone else in the lurch. Another option would be a dummy package that Provides linux-firmware, but that also runs the risk of non-cloud instances getting it installed since we don't have separate repos. (The third "option" is a separate cloud kernel package but that would make the rework we did in f22 pointless and wasted and we've already had that discussion.) josh _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
