[meta-sig][multi-arch] propose forming a Multi-arch SIG
Hi all, according to our doodle result, I propose a patch  to settle
down our initial meeting schedules as
*2020/01/07 Tuesday 0800 UTC on #openstack-meeting-alt and 1500 UTC on
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.
On Tue, Dec 17, 2019 at 2:11 PM Rico Lin <rico.lin.guanyu at gmail.com> wrote:
> From this ML, and some IRC and Wechat discussions. I put most of the
> information I collected in .
> 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 . *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() 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!
>  https://etherpad.openstack.org/p/Multi-arch
>  https://doodle.com/poll/8znyzc57skqkryv8
> On Tue, Dec 17, 2019 at 12:45 PM Ian Wienand <iwienand at 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
>> > wheels is needed. It would be a shame to let the work that got
>> > 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 .
>> 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.
>>  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.
>>  https://review.opendev.org/#/c/698606/
>>  https://review.opendev.org/#/c/676111/
> May The Force of OpenStack Be With You,
> *Rico Lin*irc: ricolin
May The Force of OpenStack Be With You,
*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...