Project plan for 64-bit version of the DICE FC5 platform (Stage 1)

Description

Develop a 64-bit version of the DICE FC5 platform.

Customer

In the first instance a number of research groups from CSTR,HCRC/ICCS,ANC and LFCS.

Case

The current 32-bit version of DICE has an architectural limit of 3Gb addressable memory space per process. This limitation is having an impact on an increasing number of research groups within the School.

Most current PCs are now capable of running in 64-bit mode, but to do this requires a 64-bit version of the base operating system. FC5 and FC3 are both available in 64-bit form. This project would involve porting LCFG (and DICE) to the 64-bit version of FC5.

At some point in the medium(?) future it is likely that 64-bit will be the norm with 32-bit being considered legacy.

Deliverables

This project will be delivered in several stages :-

  1. An LCFG managed version of 64-bit FC5 running against DICE authentication and name services (anonymously), and ideally AFS file services. Probably for servers only.
  2. A 64-bit DICE desktop, suitable for research use only.
  3. A full 64-bit DICE desktop, suitable for commodity and research use.

The plan below describes stage 1 only.

Risks

  • 64-bit FC5 might not be sufficiently stable, despite favourable reports. A fallback would be to use RHEL.
  • We uncover some issues with 32-bit to 64-bit porting of LCFG/DICE code. The risk here is that the work will take longer than estimated.
  • Not doing this work would probably result in us being obliged to hand-manage a number of 64 bit machines.

Dependencies

No known dependencies on other projects.

Management

It is proposed that stage 1 of the project would be performed solely within and managed by the Managed Platform Unit.

Stages 2 and 3 would involve multiple units (RAT, Infrastructure and Services) so would be managed as cross unit projects.

Resources

For stage1, experience of porting LCFG to a new platform would dramatically cut the effort required. Strong C and Perl skills are potentially required to deal with any 32-bit to 64-bit porting issues.

For stage2 and stage3, various skills would be required - needs to be expanded....

Plan

  1. port and test LCFG core: (3 days Stephen)
    • lcfg-authorize
    • lcfg-buildtools
    • lcfg-client
    • lcfg-file
    • lcfg-ngeneric
    • lcfg-om
    • lcfg-utils
  2. port and test updaterpms (3 days Alastair)
    • port and test updaterpms code
    • until package specs mods done to server, use prefixed arch specs (ie i386/glibc-1.0-1) - need to modify updaterpms component to do simple sed translation to real new style
  3. create repository (0.5 day Alastair)
    • no space on pezenas. Simplest plan is to split off SRPMs onto a different volume. We don't want to depend on the RPM repository having moved to AFS
    • although we think we can merge i386 and x86_64 repositories, we reckon safer to leave this until developing next DICE platform. For now keep separate.
  4. create package lists (1 day Alastair)
    • adding /noarch - easily automated?
  5. create necessary LCFG level headers (2.5 days Alastair/Stephen)
    • plan to create LCFG level instantiation to simplify porting (1 day Alastair)
    • review required changes to existing headers (1 day Stephen)
    • need to create an arch macro for headers (profile resource) (Stephen)
    • *not required* add arch resource to lcfg-updaterpms component (0.5 day Alastair)
  6. port and test components required to keep a machine LCFG managed (2 days Stephen)
    • lcfg-auth
    • lcfg-boot
    • lcfg-cron
    • lcfg-init
    • lcfg-lcfginit
    • lcfg-nsswitch
    • lcfg-pam
    • lcfg-syslog (???)
    • lcfg-tcpwrappers
  7. port miscellaneous RPMs (0.5 days Stephen)
    • lcfg-defetc-fc5
    • lcfg-release-fc5
    • ?? any more ??
  8. create simple client components for: (3 days)
    • kerberos
    • openldap
    • openssh
    • ntp
    • dns
  9. port components required to install new machine via LCFG (2 - 5 days)
    • lcfg-fstab and lcfg-hackparts (hackparts may have 64 bit issues hence 5 days)
    • lcfg-grub
    • lcfg-hardware
    • lcfg-kernel
    • lcfg-network
  10. port installroot (2 days)
    • creating installroot and installbase package lists and profiles
    • buildinstallroot
  11. build AFS kernel module (1 day)
    • lcfg-afs component
  12. author documentation to aid COs building 64 bit packages (1 day)

  • Things to be done later
    • modify to deal with multiarch package specs
      • rpmcache
      • mkxprof
    • add arch resource to rpmcache component

Time

For stage 1, assuming appropriate experience as listed in Resources section above, an estimate of 23 to 26 man days for delivery. This assumes minimal 32-bit to 64-bit porting problems.

Status

01/08/06
Initial 64 bit work has been undertaken by Stephen who has found few issues. Updaterpms and the LCFG compiler require some modifications; Alastair is currently working on the changes to updaterpms. Next stage is to refine plan re deliverables and work required.

05/09/06
Adding support for multiple archs to updaterpms has proved very hacky due to the need to continue support for wildcard archs. Alastair has shipped this hacky version as the lack of updaterpms was blocking progress. Now that it has been agreed that we can deprecate the wildcard arch support, Alastair will reimplement; this should lead to cleaner code.

12/09/06
plan for stage 1 firmed up with time estimates

Timescales

  • Steps 1-5 (10 days (5 Alastair + 5 Stephen)) of Stage1 plan to be completed by 4/10/06
  • Steps 6-12 (13 days) of Stage1 plan to be completed by 1/11/06

Priority

This project does not yet have an explicit delivery deadline. However, there is growing pressure from an increasing number of institutes for this provision.

-- AlastairScobie - 12 Sep 2006

Topic revision: r15 - 16 Oct 2006 - 12:10:24 - StephenQuinney
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies