Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Release Provisioning Descriptor Editor

From EGIWiki
Jump to navigation Jump to search
Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary


Software Provisioning menu: Software Provisioning Process UMD Release Process Quality Assurance UMD Staged Rollout




Improvement suggestions

ID Component Short name Description
1 Product/Platform Target Metapackages vs. Updated packages Some products do not have metapackages, they are installed alongside other products or services (e.g. BLAH). So *either* one or more metapackages or one or more updated packages should be required, but not both.
2 Technology Providers Repository configuration Repositories cannot be configured per Technology Provider (or per Product?)
3 ?? Managing Product metadata When compiling a release, particularly one that contains updates of products that already exist in UMD, most informaiton about a product is static and does not change across release.xml versions. Providing a means to manage product data separate from composing a release.xml file may reduce the amount of editing and effort when actually creating a release.xml. Such a feature may include configuring capabilities, metapackages(?), target platform,, etc.
4 Release version information Flexible TP Release bundle information Currently, a major.minor.revision information is required to have a well-formed release.xml. However, not every Technology Provider uses that notation, e.g. EMI uses "EMI-x Update y", ARC uses "ARC yy-mm" (ARC 12-05) similar to Ubuntu, and there are many more variants possible. To correlate which specific product update was released with which TP Release bundle this should be turned into a free-form text.
5 Product capabilities Product capabilities drop-down Turn the allowed capabilities into a drop-down or multi-value selection list (that includes "NONE"as a valid selection) that perhaps is pre-selected with informaiton coming from suggestion 3 (see above)
6 List of products Maintain product list order between edits When editing a release.xml, adn shuffling back and forth between editing, and saving/checking validity status in the overview, the order of products in the edit mode gets shuffled, adn forces the user to search for the last edited product.
7 Product Product version must be mandatory When editing a release.xml, the product version should be made mandatory.
8 Product Product version format At times products following their major.minor.revision scheme add an "aging" part in the form "major.minor.revision-aging" which constitutes a vlid new version of a product. We should support that.
9 Platform/Architecture selection Too many options for Platform and Architecture selection The possible selection should only allow those combinations that are supported by the UMD. Perhaps the selection should reflect also the target UMD version that this release or product is intended for.

User comments

http://releasexml.afroditi.hellasgrid.gr/
http://releasexml.afroditi.hellasgrid.gr/technology_providers

Step 1: Technology Provider

  • Contact
  • Technical contact

I suppose both those are the Technology provider contacts, for instance cristina A. for EMI, etc.

Step 2: Release Information

  • Isodate - is it the date of the tech provider release, or the date when we submit to RT for SW provisioning
  • Versioning (Major,Minor,Revision) - suggest to take what is announced in the tech providers rel notes, that sometimes don+'t coincide with the package or metapackage version.

Step 3: Products & Targets

A few more comments, suggestions, proposals, examples:

  • A product is a set of packages, it may have a metapackage for the dependencies or not.
  • A given TP updates only a subset of packages, either belong to the core of the service or some internal dependency.
  • We know (somehow) at least 1 product that is affected by those subset of packages.
  • We create the release.xml bundle, where we specify at least 1 product in Step 3: Products & Targets
  • We specify the metapackage emi-storm-backend-mp, (one or more) but no version information.
  • We specify all packages that are updated, and no more then those ones. In particular we will not specify any package that are already in production repos.

Now as the bouncer works (AFAIU), plus proposal:

  • The bouncer separates the initial release.xml into products.
  • -> It produces new release.xml ppa that contain the updated package as well as all dependencies, even if they are already in the production repo.
    • Instead: the bouncer should produce a ppa.xml, and fetch ONLY the updated package PLUS the dependencies that have been updated, i.e., should not contain packages already in the production repos.
    • This assumes that for verification and staged rollout, the verifiers and EAs will configure the following repos:
      • OS
      • EPEL (or other for Debian).
      • UMD Base.
      • UMD Updates.
      • UMD Testing (the new ones)
  • I propose that we fetch everything from all Tech. Providers into Testing.
  • Anyway, the ppa.xml controls always what we release into the prod repos.

For the unknown future, when/if stuff is released into EPEL, or corresponding Debian repo:

  • We know from someone, somewhere that updates have been released and which packages, for instance into EPEL testing.
  • We produce our release.xml as we do today. Then on, everything else is the same in the Workflow.
  • We continue to fetch all updated packages as well as the dependencies that where also updated, but now from the EPEL repo (or corresponding one for Deb.).

Documentation

warning to do a dry run please make sure that <release:technologyProviderShortName>EMIDRY</release:technologyProviderShortName> or <release:technologyProviderShortName>IGEDRY</release:technologyProviderShortName>