Product ID card description

Technology Providers (TP) that release products in CMD provide, for each product:

• Name of the product
• Status in CMD, reflects the step reached in the initial Provisioning process (Unplanned, Planned, Queued, Released); when Queued, it means that the UMD team has included the product in the corresponding RT queue, and is working on it
• Description of the product
• Capabilities can be one or more among:
  
  • Authentication
  • Library
  • Client tools
  • Data access
  • Accounting
  • File access
  • VM Management
  • VM Image Management
  • Container Management
  • Scheduling
  • Information System
  • Client API
• Technology Provider name; if the product is the result of the joint effort of two or more projects, please include here all of them
• Name of the Responsible for the product; this could be even more than one person
• Contacts for technical discussions; this can be different from the responsible, namely one person (or more) to be contacted in case of issues with the ID card or the provisioning workflow for the product
• OpenStack version supported (Liberty, Mitaka...), the product will be included in the release cycle of CMD-OS (OpenStack); if the product is aligned with the OpenStack release cycle, you can just specify that
• OpenNebula versions supported, the product will be included in the release cycle of CMD-ONE (OpenNebula)
• Operating Systems all the products are supposed to be working on CentOS7 and Ubuntu 14.04
• Preferred release channels, it can be a simple repository, or AppDB or other channels
• Documentation about the installation and configuration of the product; if no automated verification procedure is provided by the TP, a step-by-step installation and configuration guide must be provided by the TP, that the verification team can use to create the verification procedure
• Verification procedure, consisting in puppet/ansible profiles or scripts or any kind of automated configuration profile available for verification, with corresponding instructions; verification is our responsibility, however providing us with these automated installation7configuration procedures usually created and used by Resource Centre administrators helps us *a lot* in speeding up the process of releasing the product
• a list of possible Early Adopters to contact to handle the Staged Rollout phase for each product; we usually make regular calls for early adopters, but if you already can suggest some, it is very welcome
• Support unit If a GGUS Support Unit is already set, please provide us with the exact name of the SU. Please have a look at https://wiki.egi.eu/wiki/Category:GGUS for more information on GGUS Support Units and/or on how to create a new one if needed. If a GGUS SU is not available, at least an email address (possibly a team mailing list) should be provided
• Quality of support If a GGUS SU is available, the QoS can be one among Base, Medium, Advanced, please have a look at https://wiki.egi.eu/wiki/FAQ_GGUS-QoS-Levels for further information. If GGUS SU exists and QoS is not provided, Base will be assumed. If you cannot provide a GGUS SU related QoS level, you can always suggest your own QoS specification ("best effort", "full support") and be more descriptive.
• Support calendar for the major releases currently supported (i.e. end of support, end of security support, release cycle description...)
• Last update of the record itself in the wiki (this is needed to check periodically how fresh the information are)

Products

Dependencies