ZOMG WHAT ARE WE BUILDING?!

[Sam Kottler]

----- 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? 

> 
> >
> >> - 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
> 
> 
> >
> >> - 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.
> 
> 
> >
> >> 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.
> >
> > josh
> > _______________________________________________
> > cloud mailing list
> > cloud at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/cloud
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>