[meta-sig][multi-arch] propose forming a Multi-arch SIG
kevinzs2048 at gmail.com
Thu Nov 21 13:39:01 UTC 2019
We(Linaro) will be very honor to help upstream setup the OpenStack CI on
Arm64 to make OpenStack functional supporting. Also thanks OpenStack Infra
team for the help.
Actually we have done Kolla porting and release Kolla images
<https://hub.docker.com/r/linaro/debian-source-ironic-api> for Arm64 since
Rocky version last year, also we have used those images to deploy a Arm64
production class cloud(OpenStack Rocky + Ceph Lumious). It is Linaro
Developer Cloud, it is free to offer cloud instance to Upstream and welcome
Again, thanks everyone for the help. We will continue to work for Arm64
supporting with upstream.
On Thu, Nov 21, 2019 at 10:14 AM Chris Apsey <bitskrieg at bitskrieg.net>
> This will be a long-winded response, so bare with me...
> I brought up a semi-related topic on the mailing list last year ,
> namely that nova should ingest the hw_architecture field that is available
> in glance images and intelligently schedule it on compute nodes - not only
> in cases where you have actual hardware, but also using just qemu emulation
> when no 'real' hardware is available.
> My area of focus over the past few years hasn't been the traditional
> enterprise use case (e.g. doing what aws, azure, etc. can do but on a
> private cloud) but rather on security research. The vast majority of
> highly vulnerable systems (industrial control, healthcare, transportation,
> etc.), whose compromise would have globally felt impacts rarely run on
> traditional x86 platforms and instead use esoteric, long-dead architectures
> that many times only exist in qemu (if at all). In addition, some pieces
> of equipment can only be studied and replicated in FPGAs and other similar
> I think that a long-ignored potential area of strength for OpenStack is
> the market of automated security research (e.g. fuzzing), particularly when
> it comes to nontraditional architectures and pieces of equipment. The
> return on investment to Amazon, Microsoft, Google, and others for making
> esoteric architectures function with the same level of fidelity and quality
> that x86 (and in some cases now, arm) function just isn't there. The good
> part is, security researchers don't care about 95% of the things that major
> public clouds do for you - they want to load up their binaries, blast them
> with data, and watch them crash. Traditionally, they do this using
> small-scale qemu emulation, with all of the labor-intensive requirements
> behind it (configuring userlands, figuring out how to get qemu networking
> to work they way they need it to, etc.) They want to spend their time
> hacking, not configuring servers, and yet that's what they spend a lot of
> their time doing.
> When I think about what cloud architectures and concepts have done in
> terms of revolutionizing how applications are written, deployed, and
> delivered to customers, I envision a world where those same principles
> allow security researchers to do more with their limited time. Someone who
> knows enough about CRIS to reverse engineer firmware on microcontrollers
> made 20 years ago should not be fighting with server configurations, but
> they also should not be limited to small-scale research due to a lack of
> orchestration options.
> Proprietary solutions for these problems exist, but they are
> extraordinarily expensive and generally target a very specific thing.
> I see the future of security research as a time where researchers can
> upload a binary and a fuzzing test plan into horizon, have their binary
> loaded into already-configured glance images in the appropriate
> architecture (to include adding in GPUs for parallel processing, or FPGAs
> if needed), distribute the fuzzing job to the appropriate number of hosts
> automatically, and have the results published back to the researcher. I
> see opportunities for using nova, magnum, sahara, murano, heat, barbican,
> mistral, cinder, and other projects for being a part of this solution.
> But.. in order for any of that to be possible, the scope of OpenStack
> needs to be expanded to support integration and emulation of these weird
> devices that exist in the world around us. Multi-arch support in nova is
> the first step in that direction (and it would appear some changes in
> libvirt are needed too).
> I'm getting out of the Army and changing jobs soon soon, but my area of
> focus and passion won't be changing. This stuff matters, and I think that
> OpenStack could be *the* standard for large-scale security research, if the
> community wants it to be.
> My .02...
> Chris Apsey
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, November 20, 2019 5:03 AM, Rico Lin <
> rico.lin.guanyu at gmail.com> wrote:
> Dear all
> In summit, there's a forum for ARM support  in Summit which many people
> show they're interested in ARM support for OpenStack.
> And since also we have Linaro shows interest in donating servers to
> OpenStack infra. It's time for community to think about what we should deal
> with those ARM servers once we have them in community infrastructure.
> One thing we should do as a community is to gather people for this topic.
> So I propose we create a Multi-arch SIG and aim to support ARM architecture
> as very first step.
> I had the idea to call it ARM SIG before, but since there might be high
> overlap knowledge between support ARM 64 and other architectures. I propose
> we go for Multi-arch instead.
> This SIG will be a nice place to collect all the documents, gate jobs, and
> to trace tasks.
> If you're also interested in that group, please reply to this email,
> introduce yourself and tell us what you would like the group scope and
> objectives to be, and what you can contribute to the group.
> May The Force of OpenStack Be With You,
> *Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss