New system for update workflow - Requirements

Simplest case of system usage:

• took SRPM package, build it, put into repo, give a report

Building process

1. Concerning input - there should be several input repositories (most important - local mirror of RH SRPMs). For each distribution there will be separate repository. It should be possibile to extend input for:
   • providing SRPMs manualy
   • fetching spec file from CVS
2. It should be possible to check something before sending packages to builder:
   • if repository is not "half-mirrored"
   • if MD5 sums are ok
   • if packackes are signed properly
   • if newer versions were already build
   • if package is provided as RPM, then it will be moved immediately to outcoming/unsigned (or signed ?)
3. Package together with policy should be put to incoming queue
   • (what to do in case of downgrade ?) if in testing repository exists package with the same name and newer version, then SRPM will be moved to incoming/waiting queue and users who are specified in policy will be notified
4. Packages from incoming queue will be distributed to builders (according to policy) and build.
   • (if policy allow to do that) package will be moved to outcoming/unsigned queue
   • when build process end appriopriate user will be notified about result
   • if build failed, SRPM will be moved to incoming/failed queue
5. Some packages may need to successful build some other packages installed in builder machine. If those requirements are not satisfied, user will be notified and (if present) those required packages will be proposed as new job, and current job will be paused.
6. Packages that were already build will be moved to experimental repo
7. All packages that are present in experimental repo can be installed on builder machines.
8. User have to sign packages waiting in outcoming/unsigned queue. Signed packages will be moved automatically to testing repository
9. User have to test packages that are in testing repository. If package is OK, it will be marked as tested.
10. Tested packages will be moved to production repository. System will prepare and send announce to users.

Reporting and metadata:

1. Reporting - providing read-only access to data (on demand / static)
   • log report from builder (build was successful or not)
   • state of package (where is it now, what is it state)
   • info about package update taken from RHN advisories (classification, link to adv)
   • history of package durign its journey through system
   • state of each part of system (how many packages of queues)
   • builder summary (dead/alive, some OS statistics)
   • announce that there was update of production repository
2. Notification - asking question to user, providing read-write access to data (on demand / static)
   • asking for decision what to do with package
   • asking for some manual action in case of problem
   • changing status of package
   • asking for approval / signature
   • changing some package metadata
   • perioding information about pending task to do - security updates

Policies, metadata and security advisories:

1. Policy will give some hints what to do with package. There should be one general policy (fetch/check/build/test/sign).
   • who is allowed to run this policy
   • with which packages it is connected (one, many, all).
   • there should be some priority system, so one policy can be overriden by another
   • it should be specified who should be notified, and about what
   • where to move package after successful build (default - testing repository)

1. Package metadata - one metadata record per each package
   • if there are some parameters needed in build phase, there should be specified here
   • information on which platform package should be build
   • information extracted from RPM
   • where to put package after successful build
   • from where does this package come
   • current state of package

1. Security advisories - they will be mainly fetched from RHN (https://rhn.redhat.com/errata), but options to provide them manually is concerned. What should be extracted from these adv :
   • package affected (name of SRPM)
   • OS affected (RHEL4AS,RH9,...)
   • version number
   • classification: security update (incl. severity), bugfix, new addition
   • security updates: CAN/CVE/bid (s) addressed by the update

User management:

1. Should be possible to manage user accounts (not so much, ~10)
2. User authorisation should be done with some existing mechanism (Kerberos, CERN certificates (https://ca.cern.ch/))