[meta-sig][multi-arch] propose forming a Multi-arch SIG
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/...
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin wrote:
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.
I have worked with some upstream people such as hrw to get diskimage-builder working with EFI and ARM64, and setup the infra to build ARM64 nodes on Linaro's donated resources. Although infra is all an open book in terms of configuration, etc. and anyone can contribute, I'll be happy to help with issues or mentor anyone on using the gate resources we have available.
Cheers,
-i
On 21/11/2019 00:15, Ian Wienand wrote:
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin wrote:
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.
I have worked with some upstream people such as hrw to get diskimage-builder working with EFI and ARM64, and setup the infra to build ARM64 nodes on Linaro's donated resources. Although infra is all an open book in terms of configuration, etc. and anyone can contribute, I'll be happy to help with issues or mentor anyone on using the gate resources we have available.
openstack-ansible is ready to go on arm CI but in order to make the jobs run in a reasonable time and not simply timeout a source of pre-built arm python wheels is needed. It would be a shame to let the work that got contributed to OSA for arm just rot.
WIP patch here https://review.opendev.org/#/c/618305/
On Tue, Nov 26, 2019 at 11:33:16AM +0000, Jonathan Rosser wrote:
openstack-ansible is ready to go on arm CI but in order to make the jobs run in a reasonable time and not simply timeout a source of pre-built arm python wheels is needed. It would be a shame to let the work that got contributed to OSA for arm just rot.
Yeah, for reference we started a story with this [1] and Paul even had a WIP change [2]. Another part of this is having local mirrors setup, which I've had a play with in [3].
But I've noticed that getting two nodes for testing here doesn't often work (see test history). At the moment we only have Linaro London in the rotation and my contacts there have moved on.
I think before we go too far with building jobs, etc. we need to make sure we're consistently booting test instances there. I had a quick look at the nodepool logs and it seems the requests just time out -- without access to the backend logs I can't tell much else. I can certainly extract vm id's etc if we know a way to investigate.
-i
[1] https://storyboard.openstack.org/#!/story/2005353 [2] https://review.opendev.org/552700 [3] https://review.opendev.org/690798
On Tue, Nov 26, 2019 at 11:33:16AM +0000, Jonathan Rosser wrote:
openstack-ansible is ready to go on arm CI but in order to make the jobs run in a reasonable time and not simply timeout a source of pre-built arm python wheels is needed. It would be a shame to let the work that got contributed to OSA for arm just rot.
So ARM64 wheels are still a work-in-progress, but in the mean time we have merged a change to install a separate queue for ARM64 jobs [1]. Jobs in the "check-arm64" queue will be implicitly non-voting (Zuul isn't configured to add +-1 votes for this queue) but importantly will run asynchronously to the regular queue. Thus if there's very high demand, or any intermittent instability your gates won't be held up.
[2] is an example of using this in diskimage-builder.
Of course you *can* put ARM64 jobs in your gate queues as voting jobs, but just be aware with only 8 nodes available at this time, it could easily become a bottle-neck to merging code.
The "check-arm64" queue is designed to be an automatically-running half-way point as we (hopefully) scale up support (like wheel builds and mirrors) and resources further.
Thanks,
-i
[1] https://review.opendev.org/#/c/698606/ [2] https://review.opendev.org/#/c/676111/
From this ML, and some IRC and Wechat discussions. I put most of the
information I collected in [1]. At this point, we can tell there's a lot of works already in progress in this community. So I think we can definitely get benefits from this SIG.
Here are things we need to settle at this point:
- *SIG chairs*: We need multiple SIG chairs who can help to drive SIG goals and host meetings/events. *Put your name under `SIG chairs:` if you're interested*. I will propose my name on the create SIG patch since I'm interested in helping set this SIG up and we need to fillup something there. But that won't block you from signing up. And I'm more than happy if we can have more people rush in for the chair role:). - *First meeting schedule*: I create polling for meeting time [2]. *Please pick your favorite for our first meeting time* (And potentially our long term meeting schedule, but let's discuss that in the meeting). I pick the second week of Jan. because some might be on their vacation in the following two weeks. As for the location, I do like to suggest we use #openstack-meeting, so we might be able to get more people's attention. From the experience of other SIGs, to run a meeting on your own IRC channel, make it harder for new community members to join. - *Resources*: We need to find out who or which organization is also interested in this. Right now, I believe we need more servers to run tests, and people to help on making test jobs, feedbacks, or any other tasks. So please help to forward the etherpad([1]) and add on more information that I fail to mention:) If you can find organizations that might be interested in donating servers, I can help to reach out too. *So sign up and provide any information that you think will helps:)* - *Build and trace*: We definitely need to target all the above works(from the previous replies) in this SIG, and (like Ian mentioned) to work on the test infrastructure. And these make great first step tasks for SIG. And to track all jobs, I think it will be reasonable to create a Storyboard for this SIG and document those tasks in one Storyboard.
All the above tasks IMO don't need to wait for the first meeting to happen before them, so If anyone likes to put their effort on any of them or like to suggest more initial tasks, you're the most welcome here!
[1] https://etherpad.openstack.org/p/Multi-arch [2] https://doodle.com/poll/8znyzc57skqkryv8
On Tue, Dec 17, 2019 at 12:45 PM Ian Wienand iwienand@redhat.com wrote:
On Tue, Nov 26, 2019 at 11:33:16AM +0000, Jonathan Rosser wrote:
openstack-ansible is ready to go on arm CI but in order to make the jobs
run
in a reasonable time and not simply timeout a source of pre-built arm
python
wheels is needed. It would be a shame to let the work that got
contributed
to OSA for arm just rot.
So ARM64 wheels are still a work-in-progress, but in the mean time we have merged a change to install a separate queue for ARM64 jobs [1]. Jobs in the "check-arm64" queue will be implicitly non-voting (Zuul isn't configured to add +-1 votes for this queue) but importantly will run asynchronously to the regular queue. Thus if there's very high demand, or any intermittent instability your gates won't be held up.
[2] is an example of using this in diskimage-builder.
Of course you *can* put ARM64 jobs in your gate queues as voting jobs, but just be aware with only 8 nodes available at this time, it could easily become a bottle-neck to merging code.
The "check-arm64" queue is designed to be an automatically-running half-way point as we (hopefully) scale up support (like wheel builds and mirrors) and resources further.
Thanks,
-i
[1] https://review.opendev.org/#/c/698606/ [2] https://review.opendev.org/#/c/676111/
Hi all, according to our doodle result, I propose a patch [1] to settle down our initial meeting schedules as *2020/01/07 Tuesday 0800 UTC on #openstack-meeting-alt and 1500 UTC on #openstack-meeting.* I assume we can use our initial meetings to discuss about SIG setup details (schedules, chairs, etc.), and general goals we should set and initial action we need to takes. please join us if you got time.
Also, let me know if anything is wrong with the above schedule.
[1] https://review.opendev.org/#/c/701147/
On Tue, Dec 17, 2019 at 2:11 PM Rico Lin rico.lin.guanyu@gmail.com wrote:
From this ML, and some IRC and Wechat discussions. I put most of the information I collected in [1]. At this point, we can tell there's a lot of works already in progress in this community. So I think we can definitely get benefits from this SIG.
Here are things we need to settle at this point:
- *SIG chairs*: We need multiple SIG chairs who can help to drive SIG
goals and host meetings/events. *Put your name under `SIG chairs:` if you're interested*. I will propose my name on the create SIG patch since I'm interested in helping set this SIG up and we need to fillup something there. But that won't block you from signing up. And I'm more than happy if we can have more people rush in for the chair role:).
- *First meeting schedule*: I create polling for meeting time [2]. *Please
pick your favorite for our first meeting time* (And potentially our long term meeting schedule, but let's discuss that in the meeting). I pick the second week of Jan. because some might be on their vacation in the following two weeks. As for the location, I do like to suggest we use #openstack-meeting, so we might be able to get more people's attention. From the experience of other SIGs, to run a meeting on your own IRC channel, make it harder for new community members to join.
- *Resources*: We need to find out who or which organization is also
interested in this. Right now, I believe we need more servers to run tests, and people to help on making test jobs, feedbacks, or any other tasks. So please help to forward the etherpad([1]) and add on more information that I fail to mention:) If you can find organizations that might be interested in donating servers, I can help to reach out too. *So sign up and provide any information that you think will helps:)*
- *Build and trace*: We definitely need to target all the above
works(from the previous replies) in this SIG, and (like Ian mentioned) to work on the test infrastructure. And these make great first step tasks for SIG. And to track all jobs, I think it will be reasonable to create a Storyboard for this SIG and document those tasks in one Storyboard.
All the above tasks IMO don't need to wait for the first meeting to happen before them, so If anyone likes to put their effort on any of them or like to suggest more initial tasks, you're the most welcome here!
[1] https://etherpad.openstack.org/p/Multi-arch [2] https://doodle.com/poll/8znyzc57skqkryv8
On Tue, Dec 17, 2019 at 12:45 PM Ian Wienand iwienand@redhat.com wrote:
On Tue, Nov 26, 2019 at 11:33:16AM +0000, Jonathan Rosser wrote:
openstack-ansible is ready to go on arm CI but in order to make the
jobs run
in a reasonable time and not simply timeout a source of pre-built arm
python
wheels is needed. It would be a shame to let the work that got
contributed
to OSA for arm just rot.
So ARM64 wheels are still a work-in-progress, but in the mean time we have merged a change to install a separate queue for ARM64 jobs [1]. Jobs in the "check-arm64" queue will be implicitly non-voting (Zuul isn't configured to add +-1 votes for this queue) but importantly will run asynchronously to the regular queue. Thus if there's very high demand, or any intermittent instability your gates won't be held up.
[2] is an example of using this in diskimage-builder.
Of course you *can* put ARM64 jobs in your gate queues as voting jobs, but just be aware with only 8 nodes available at this time, it could easily become a bottle-neck to merging code.
The "check-arm64" queue is designed to be an automatically-running half-way point as we (hopefully) scale up support (like wheel builds and mirrors) and resources further.
Thanks,
-i
[1] https://review.opendev.org/#/c/698606/ [2] https://review.opendev.org/#/c/676111/
-- May The Force of OpenStack Be With You,
*Rico Lin*irc: ricolin
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
Thanks Rico.
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 registration, https://www.linaro.cloud/.
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@bitskrieg.net wrote:
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.... http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653.html ‐‐‐‐‐‐‐ 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 Lin*irc: ricolin
On Thu, Nov 21, 2019 at 02:10:02AM +0000, Chris Apsey wrote:
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.
That's a fun idea and one we shoudl talk more about and try to work out what that'd look like for nova. Of course it assumes really good "TCG" support in qemu but we can probably do *something*
Yours Tony.
W dniu 20.11.2019 o 11:03, Rico Lin pisze:
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.
I work on OpenStack for a while as Red Hat assignee to Linaro.
Most of time I spent in Kolla projects (core dev for over years). Had fingers in DIB, Loci, Nova and some drive-by patching in other projects.
I work on AArch64 (arm64) since 2012. Added AArch64 and Power (ppc64le) support into Kolla and maintain AArch64 support. 1-2 times per year I also check how we are on Power.
Most of my work is around building stuff.
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin 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.
Pick me Pick me :)
I've been around OpenStack for about 5 years now, the last couple have been focused on brining multi-arch support (albeit ppc64le) into tripleo building on the enablement work that others have done.
I'm keen to work with the SIG, to build out the ARM support and at the same time ensure we don't make it hard for other architectures to do the same
Yours Tony.
Sounds interesting.. But not clear what is the goal for that SIG? Since OpenStack claims to have support for different HW.
Are there any additional reqs? Clearly CI ones.
Thanks, Arkady
-----Original Message----- From: Tony Breeds tony@bakeyournoodle.com Sent: Thursday, November 21, 2019 10:05 PM To: Rico Lin Cc: OpenStack Discuss Subject: Re: [meta-sig][multi-arch] propose forming a Multi-arch SIG
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin 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.
Pick me Pick me :)
I've been around OpenStack for about 5 years now, the last couple have been focused on brining multi-arch support (albeit ppc64le) into tripleo building on the enablement work that others have done.
I'm keen to work with the SIG, to build out the ARM support and at the same time ensure we don't make it hard for other architectures to do the same
Yours Tony.
CI building stuff (packages, containers, images) fixing deployment tooling -- some tools might barf if you have a mix of archs a bit of evangelism
probably more...
On Fri, Nov 22, 2019 at 11:16 AM Arkady.Kanevsky@dell.com wrote:
Sounds interesting.. But not clear what is the goal for that SIG? Since OpenStack claims to have support for different HW.
Are there any additional reqs? Clearly CI ones.
Thanks, Arkady
-----Original Message----- From: Tony Breeds tony@bakeyournoodle.com Sent: Thursday, November 21, 2019 10:05 PM To: Rico Lin Cc: OpenStack Discuss Subject: Re: [meta-sig][multi-arch] propose forming a Multi-arch SIG
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin 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.
Pick me Pick me :)
I've been around OpenStack for about 5 years now, the last couple have been focused on brining multi-arch support (albeit ppc64le) into tripleo building on the enablement work that others have done.
I'm keen to work with the SIG, to build out the ARM support and at the same time ensure we don't make it hard for other architectures to do the same
Yours Tony.
Glad to see that we plan to form a SIG to better support ARM64 and other architecture CPUs, I think we can do something in the SIG, functional tests, performance data share, share best practices.
BTW, we also have slides for the forum , find it at https://docs.google.com/presentation/d/1TyKYqDTnuncQQpx6DFKNAIg1buCgjeGH1RsI...
Jeremy Freudberg jeremyfreudberg@gmail.com 于2019年11月23日周六 上午12:46写道：
CI building stuff (packages, containers, images) fixing deployment tooling -- some tools might barf if you have a mix of archs a bit of evangelism
probably more...
On Fri, Nov 22, 2019 at 11:16 AM Arkady.Kanevsky@dell.com wrote:
Sounds interesting.. But not clear what is the goal for that SIG? Since OpenStack claims to have support for different HW.
Are there any additional reqs? Clearly CI ones.
Thanks, Arkady
-----Original Message----- From: Tony Breeds tony@bakeyournoodle.com Sent: Thursday, November 21, 2019 10:05 PM To: Rico Lin Cc: OpenStack Discuss Subject: Re: [meta-sig][multi-arch] propose forming a Multi-arch SIG
On Wed, Nov 20, 2019 at 06:03:03PM +0800, Rico Lin 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.
Pick me Pick me :)
I've been around OpenStack for about 5 years now, the last couple have
been focused on brining multi-arch support (albeit ppc64le) into tripleo building on the enablement work that others have done.
I'm keen to work with the SIG, to build out the ARM support and at the
same time ensure we don't make it hard for other architectures to do the same
Yours Tony.
participants (11)
-
Arkady.Kanevsky＠dell.com
-
ChangBo Guo
-
Chen CH Ji
-
Chris Apsey
-
Ian Wienand
-
Jeremy Freudberg
-
Jonathan Rosser
-
Marcin Juszkiewicz
-
Rico Lin
-
Shuai Zhao
-
Tony Breeds