Re: Porting Fedora for the LoongArch architecture.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




在 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux