-----BEGIN PGP SIGNED MESSAGE-----
El Thu, 31 Oct 2013 15:34:39 +0100
"Sandro \"red\" Mathys" <red(a)fedoraproject.org> escribió:
On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler
> ----- Original Message -----
>> From: "David Nalley" <david(a)gnsa.us>
>> To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>
>> Sent: Thursday, October 31, 2013 10:02:17 AM
>> Subject: Re: ZOMG WHAT ARE WE BUILDING?!
>> From the peanut gallery, feel free to treat accordingly.
>> On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer
>> <jwboyer(a)fedoraproject.org> wrote:
>> > On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier <jzb(a)redhat.com>
>> > wrote:
>> >> Hi all,
>> >> (For those who weren't in today's IRC meeting, I sorta
>> >> apologize for the subject line. Sorta.)
>> >> As we were discussing today - we need to decide what we are
>> >> building, and (almost as importantly) what we're not building.
>> >> We've agreed that we want to be cooperating with the server
>> >> SIG, but don't necessarily plan to build a foundation for an
>> >> IaaS ourselves.
>> >> Some of the questions that were raised during the meeting:
>> > Note: I am a cloud newbie. Please bear with my stupid
>> > questions.
>> >> - Should we drop 32-bit?
>> > I was under the impression that 32-bit guests on 64-bit hosts
>> > were fairly common for applications where the advantages of
>> > 64-bit address space isn't needed. E.g. "64-bit python sucks a
>> > lot". Maybe that's becoming less of a concern?
>> Agree - lots of situations where 32-bit is preferable, and in many
>> cases still the defacto arch.
> It's getting harder and harder to find 32 bit x86 hardware. There's
> exactly one use case for 32 bit in the cloud setting (IMO), which
> dgilmore and I briefly spoke about after the meeting yesterday -
> extremely memory constrained environments. The python memory
> consumption issues on 64 bit fall into that category. Does anyone
> have other use cases that aren't support for older hardware or
> memory usage with smaller amounts of mem?
This is pretty much the only use case I hear of for 32bit images.
Stupid question: is it somehow possible to force Python to behave like
it was a 32bit system even though both the instance/VM and the image
are actually 64bit?
>> >> - Should we be targeting ARM?
>> > Now? Maybe. In the future? Probably should, yes.
>> From a Cloud perspective, I don't know of a single public cloud
>> using ARM. There are tons of benefits to using ARM, but I am not
>> seeing deployments personally. This is a nice to have IMO at this
>> stage, though we shouldn't ignore it, I think the power savings
>> will make it prominent in very short order, but not sure that it's
>> in the purview of
I now we're getting closer to actually see ARM clouds (and think some
private cloud proof of concepts are in their final stages). So yes, we
should eventually support ARM. But right now? No. We really have
enough on our plates by 1) defining how many and what images to
produce, 2) implement all of them, 3) make sure we deliver the
expected features and quality. Once we feel we're doing the right
thing and are good at what we're doing, we can add the added
complexity of ARM. Maybe we also have the necessary HW (or public
clouds) to actually test ARM images by then.
I know ubuntu is working on supporting ARM in openstack, I really think
we should as well. We should go big or go home. all of this change is
about making Fedora bigger and better. This is a avenue we should
pursue. while ppc is a secondary arch we need to also consider it.
there is a lot of work inside of IBM on KVM and openstack.
>> >> - Do we worry about supporting ALL THE METHODS of building the
>> >> image, or no? (I recommend we focus on One True Way so as not
>> >> to confuse everyone with 80 different ways they *could* do it.)
>> > So, from a person that doesn't use cloud stuff but might
>> > actually want to try and create an image to make sure I don't
>> > break things (kernel maintenance is fun!), I'd really like one
>> > way to make images. Knowing all of the images are made one way
>> > makes it easier to spin my own to recreate and then test fixes,
>> > etc. If I have to worry about person X building one way and
>> > something breaking, but person Y building another way and it
>> > works, it's going to drive me crazy.
>> So Fedora should have a way of building images - and that way
>> should also be easily consumable by others. (e.g. Koji is probably
>> not the best answer). Image Factory, Boxgrinder, Vagrant. Bonus
>> points if we don't reinvent a tool and adopt something that the
>> rest of the world is already consuming and familiar with.
+1 on supporting a single (or if good use cases are given) a very few
methods. +1 on using an readily available, easy-to-use, flexible tool
that everyone can spin up on their laptop if they want to do their own
images. Bonus points if the tool is already widely adopted (which I
don't think any is).
+1 on using a tool/method that is not specific to Fedora (i.e. let
e.g. Ubuntu users build Fedora images the same way).
IMHO it's also important that the method does not require the user to
disable SELinux (as about half of them do).
More bonus points if the method allows for cross-building ARM images
on x86(_64) systems. Not sure that's actually a good idea, though - I
hear there's reasons Koji doesn't do this for package building.
We need one way, it needs to work both inside koji and outside. there
is work to migrate to oz/imagefactory using qemu building images on x86
should be possible.
>> >> Other questions, thoughts, comments, flames?
>> >> I also want to recommend that we think hard about not just what
>> >> we build, but accompanying it with appropriate amounts of
>> >> documentation for the developers/users we expect to be
>> >> consuming the image. I'm sure it goes without saying that we
>> >> would document what we do, but I would like to see this thought
>> >> about each step of the way so that when we get to a finished
>> >> product, it's dead easy to adopt.
>> > Please! I really want to use more virt/cloudy things myself,
>> > but I'm lost in a sea of acronyms and ever-changing tools.
>> > Probably the nature of the ecosystem at the moment, but having
>> > clear documentation that a dumb kernel maintainer can read to
>> > make shiny things would be good.
Not sure if that should be added to this discussion or not: we really
need to find a way to release updated images more often. Spinning up
dozens or hundreds of instances just to pull in hundreds of MBs of
updates right away with each and every single one sucks.
This is part of why I want someone from the cloud space to join releng
and work on the tooling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----