Fedora 22 is out, Fedora 23 is coming :)
jwboyer at fedoraproject.org
Thu Jun 11 16:53:42 UTC 2015
On Thu, Jun 11, 2015 at 12:40 PM, Matthew Miller
<mattdm at fedoraproject.org> 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
More information about the cloud