On Thu, Jun 11, 2015 at 12:40 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 11, 2015 at 12:31:10PM -0400, Josh Boyer wrote: >> I don't see how that is going to help with "you need to use Docker. >> No wait, rocket. No, I mean this other thing. Wait, containers? >> Those are terrible. Use xzy." in a model where you're spitting out >> images per technology. Modularization _enables_ you to spit out those >> images at a lower cost, but it doesn't help with churn at all. > > Maybe you can define the problem you are calling "churn"? I understood > you to mean something like "django version changing too quickly in > Fedora". But it sounds like you mean "cloud computing world overall > changing really fast"? s/cloud//, but yes. For example, if the idea is to ship a cloud image per technology then after one release you're going to have a bunch of images that nobody cares about. That means we carry those images on the mirrors until EOL and they're wasted. It also means that when the image isn't generated for the next release (or maybe the release after), you lack consistency around both what Fedora Cloud is providing and what you can market it as. You aren't helping people navigate this problem at all, you're just feeding into it. 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. josh _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
