-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Thu, 31 Oct 2013 15:34:39 +0100 "Sandro \"red\" Mathys" <r...@fedoraproject.org> escribió: > On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler <skott...@redhat.com> > wrote: > > > > > > ----- Original Message ----- > >> From: "David Nalley" <da...@gnsa.us> > >> To: "Fedora Cloud SIG" <cloud@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 > >> <jwbo...@fedoraproject.org> wrote: > >> > On Wed, Oct 30, 2013 at 4:30 PM, Joe Brockmeier <j...@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----- _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
