This will be a long-winded response, so bare with me...
I brought up a semi-related topic on the mailing list last year [1], 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 devices.
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...
r
Chris Apsey
[[1] http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653....) ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, November 20, 2019 5:03 AM, Rico Lin rico.lin.guanyu@gmail.com wrote:
Dear all In summit, there's a forum for ARM support [1] 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.
[1] https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24355/...
--
May The Force of OpenStack Be With You, Rico Linirc: ricolin