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.

Difference between revisions of "Release Provisioning Descriptor Editor"

From EGIWiki
Jump to navigation Jump to search
Line 95: Line 95:


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

Revision as of 09:16, 11 May 2012

Technology Software Component Delivery Software Provisioning UMD Middleware Cloud Middleware Distribution Containers Distribution Technology Glossary


UMD Provisioning | Software Provisioning Process | UMD Release Process | Software Provisioning Release descriptor tool | Glossary



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

for tomorrow

Documentation

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