ZOMG WHAT ARE WE BUILDING?!

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Thu, 31 Oct 2013 15:34:39 +0100
"Sandro \"red\" Mathys" <red at fedoraproject.org> escribió:
> On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler <skottler at redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >> From: "David Nalley" <david at gnsa.us>
> >> To: "Fedora Cloud SIG" <cloud at 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 at fedoraproject.org> wrote:
> >> > On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier <jzb at 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.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJScn5KAAoJEH7ltONmPFDRIpMQAMmK0VQ80x1xRz5nfy9AK05I
OUXseBn617qB6ep18c2hbBF34JARYBoEE3i9Dxt08b5K8hCDbjV1NBKCs7f4EVMF
2gXmwnVLJdiUX2jeb5y+aoNwFkgVcyUGQk2u+02qJIQXD0dxgUp/Y6RKQmiWXMhb
+0amfL7RhMp/H3K7Nr637FiU01KiSPwYLNeh4f6jfdmr7Xb0VAe8hnBHcPU/WX23
AAKpoB6g5qS8XrDDCh4tiM6lQ+wGg6nxRp8om2dyo8oXcCbUMs7QxHKHscP8/v0e
qC0ilky4MGqYiW0IZQ95Y8P9W53MZLZauk74HJ58EMBWZLt0+Q7184lSvx142ZV2
oKYgh6LFw1Hvc8yCOagK2dNbu6gg14qCj4RyfpAQUmH8EEWtAKmC5nPk1H8bNhD0
d04DQS7QYu0gklF9QEv5xc1fKRFm6QLjoi8byQqnfECNuW9feuqT4MPsssiSXAeJ
/OfrJntD/isc5rTMmeTMim9hmIgInQ8IgDdWxFcT1FRGFFlc8d5ua4pU7nAAs+py
xGRCWL+Kg5pUHFa2/hld4/zCXVUuhD1q472Ge91pzLK/44S2DxSBN42kKO/WpkID
tR2P1q9wJA/DmFKGbZHTgWv4DY6cmspkPKcV3llh0foZsl18npoKdz2KvNq8MlcA
YJ9lQvVUkMNP3jz4l/6x
=ZUyh
-----END PGP SIGNATURE-----