在 2023/1/11 21:15, Stephen Smoogen 写道:
主题:
Re: Porting Fedora for the LoongArch architecture.
From:
Stephen Smoogen <ssmoogen@xxxxxxxxxx>
日期:
2023/1/11 21:15
收件人:
Development discussions related to Fedora <devel@xxxxxxxxxxxxxxxxxxxxxxx>
抄送:
"siyanteng@xxxxxxxxxxx" <siyanteng@xxxxxxxxxxx>,
"chenhuacai@xxxxxxxxxxx" <chenhuacai@xxxxxxxxxxx>,
"shipujin.t@xxxxxxxxx" <shipujin.t@xxxxxxxxx>, Xiaotian Wu
<wuxiaotian@xxxxxxxxxxx>, zhangfuxin@xxxxxxxxxxx, chenfeiyang@xxxxxxxxxxx
On Tue, 10 Jan 2023 at 17:37, Richard W.M. Jones <rjones@xxxxxxxxxx>
wrote:
Hi,
... clipped as I want to focus on this part.
(4) As another reply mentioned, to get LoongArch as a primary Fedora
architecture, an essential requirement is 19" rackable server-class
hardware. It needs to be fully manageable through a BMC. Fedora will
probably need a few such servers to be donated.
This is usually the major hanging point for bringing up it as a 'main'
OS. I am going to outline in depth what it takes from an operational
side to get any new 'deliverable' into Fedora currently. I am not
doing so to say 'this can't be done' as much as to explain why it
can't usually be done at the speed most people seem to think can be done.
The complete Fedora koji build system has a lot of assumptions of
being in the same datacenter with just one set of hardware remote and
'breaking' regularly due to that (mounts are being done over NFS over
ssh and disconnect regularly.. connections between the main DC and
other places may time out etc.). The build system is generally locked
together so that if one architecture has slowness/problems it affects
all builds on the other arches. Adding more architectures to this
tends to add a non-linear complexity in places. [The opposite of
having multiple koji's adds a different level of complexity and
requires more dedicated people time which is in even shorter supply.]
The main DC is in the continental United States and in a 'lights' out
facility (aka there are no hands in the facility regularly). This
means that the hardware needs to be able to be managed remotely and be
redundant so that it can 'work' in a degraded shape for weeks until
replacements can be reached. There is no 'lab' for fixing equipment so
the parts generally need to have a dedicated tech to fix. [Practically
this means the hardware in the facility needs to be rated and
insurable for this sort of data-center. Certain hardware is rated only
for 'labs' or places where someone can unplug quickly if it smokes..
this is not that kind of place.]
The next issue is space to put more equipment into this facility.
Pretty much every build architecture takes at least 1 full sized rack
for the number of systems needed to keep up with builds. That requires
additional planning as the space used is shared between multiple
groups and may not be possible to add in quickly (or at all). Other
solutions are possible but would require additional work and time.
There are also the requirements for additional NFS storage, power, etc
etc that each deliverable requires. Those all need to be added,
budgeted for and purchased. [What has happened several times to slow
things down is that it wasn't
ordered/budgeted/purchased/put-in-place.. and well 6-12 months got
lost making it happen.]
That all sounds like a lot of 'no' wrapped up in a 'it depends', but
it can be done. In general it can be a 2-5 year process from when
someone says 'Hey wouldn't it be great to build X' to getting the
'factory' built and working with the rest of the build system. During
that time, usually a secondary external build system may be built
elsewhere using shadow-koji or some other build tools to keep up and
work out a lot of the bugs in the many parts of the build system
(bodhi, koji, pungi, odcs, osbs, git, bugzilla, messaging system, pdc,
mbs, oci, signing-infra, qa, koschei, and various things which are
containers that affected/are affected by any build). Doing that allows
for the eventual infusion of the arch into the main Fedora to take
weeks versus months/year.
This is the main reason why RISC-V isn't a primary Fedora architecture
yet, although progress is happening.
Thank you so much!
The information you provided is very useful and this information can
save us a lot of trouble.
I'm going to digest this information slowly next.
Regards,
Haiyong
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
_______________________________________________
devel mailing list --devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email todevel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
