Re: ZOMG WHAT ARE WE BUILDING?!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 31, 2013 at 10:59:00AM -0500, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> El Thu, 31 Oct 2013 15:34:39 +0100
> "Sandro \"red\" Mathys" <red@xxxxxxxxxxxxxxxxx> escribió:
> > On Thu, Oct 31, 2013 at 3:10 PM, Sam Kottler <skottler@xxxxxxxxxx>
> > wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "David Nalley" <david@xxxxxxx>
> > >> To: "Fedora Cloud SIG" <cloud@xxxxxxxxxxxxxxxxxxxxxxx>
> > >> 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@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.
> > >
> > > 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.

AFAIK, the work was limited to supporting libvirt LXC on ARM
with OpenStack. No one in their right mind should use that since
it offers no meaningful security, since there was no work done
to make OpenStack request use of SELinux or AppArmour for LXC.

I've not seen any patches (upstream at least) to support KVM on
ARM in OpenStack from any Ubuntu devs, or indeed from anyone at
all.

We're still pretty early in terms of KVM support for ARM, so one
of the bigger problems is anyone getting access to hardware to
actually test it with. I expect that will change significantly
over the next year, to the extent that KVM + ARM will be more
easily consumable by devs, and thus I'd expect OpenStack to have
support for KVM ARM at some point during this next year. If no
one else submits the changes required, I'll likely try to do
them myself.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux