Update Workflow System Vision

Overwiev

Main task of system is upgrade "update workflow" process. System reqiurements are here UpdateWorkflowSystemRequirements.

What is done now ?

There exists bunch of scripts (https://twiki.cern.ch/twiki/bin/view/LinuxSupport/SoftwareUpdatesOnSLCOld) which mainly do following things :

• do mirror of RH ftp with updates on disk
• copy almost all SRPMs to builder, build them
• copy some binary RPMs
• if build is succesful, then sign (both build and copied binaries) them and copy to repo

There are some special cases, like building kernel, which need some preparation (patching, additional arguments). Some packages (like openssh) are replaced by CERN ones. To build sth root access is needed on builder machines.

What has to be done ?

New piece of software should appear, which should have all features of existing scripts. In addition:

• there is need of notification and raports - some web tool
• it should read RHSA advisory information - needed to send our own, generate reports
• authorisation/user management is needed - who is allowed to do what

Concept of system parts

TO BE CHANGED !!

Data model

(more...)

Processing scheme

To each SRPM package there will be some policy applied.

Flow of files will be like that:

1. Update local mirror of RH repo
2. Test if we have proper packages (md5, gpg, some tags)
3. Copy new updates to builders
4. Build RPMs from SRPMs
5. Report to user what was done / if build was succesful or not
6. Ask for signature on package
7. Move signed packages to testing repository, mark them as pending
8. User can mark some packages as good
9. Good packages will be moved to production repository
10. Advisory will be prepared and users will be notified about update of production repository (Prepare announcement to users.)

Asking for user approval in following cases:

1. To start building process ?
2. To build a package or not ?
3. To sign package or not ?
4. To move it to production repo or not ?
5. Ask how to serve ,,special cases'' - some parameters (kernel)

Notification:

1. md5 or pgp key was corrupted
2. Builder report (package was build or not).
3. Security update is waiting for moving to production repository.
4. Security announcement to CERN users.

Package policy and metadata

Many packages - many policies.

Metadata

• detailed info about package:
  • name
  • type (SRPM / RPM)
  • architecture/platform (i386 / i686 / ia64 )
  • comments
• configuration of build process
  • from where does it come (RH , CERN, Fermi)
  • some parameters
  • priority during build process
  • where should it go
• link to security adv of package

Policy

• to which package(s) does it apply
• priority of policy
• notification configuration
  • to whom send
  • what send
  • how often send
• action configuration
  • what and who can do sth with package/s

Package states

• ? character means user notification (waiting for user action)
• ! character means sending report to user

• ready - package is waiting in local repository, it is not checked (md5 & pgp)
• mirroring - repository is locked, mirroring in progress
• waiting - md5 & pgp check ok, ready for building
• test failed - md5 or pgp corrupted, notification sent to user
• being build - building process in progress
• build failed - sth went wrong, notification sent to user
• unsigned/pending - build was successful, package is not signed, notification for signature was sent to user
• signed/untested - package was signed by user, it was moved to testing repository, but is is untested, it is waiting until user will mark flag "tested", some packages (like securite updates) periodically notify user about their current state
• tested - package is tested, it is waiting for moving to production repository
• good - package is finally in production repository

-- LeszekGrzanka - 06 Mar 2007