>From the peanut gallery, feel free to treat accordingly. On Thu, Oct 31, 2013 at 9:02 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier <jzb@xxxxxxxxxx> 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. > >> - 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
