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 "GOCDB/Release4/Development/conditionalCertificationStatusRules"

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


===Overview===
===Overview===
The proposals outlined below involve conditional enforcement of site Certification Status values depending on the selected Target Infrastructure value (Production or Test). <b>Proposals 2 and 3 are questionable and may not be necessary.</b> <br/>
The proposals outlined below are relevant to the Resource Centre (Site) Registration and Certification Procedure. <b>Proposals 2 and 3 are questionable and may not be necessary.</b> <br/>
* Note: The following status transition rules do not apply to non-EGI (local) scoped sites and services.   
* Note: The following status transition rules do not apply to non-EGI (local) scoped sites and services.   
* Note: The Site Target Infrastructure field was previously referred to as the ‘Production Status’ (Production Status is a misleading term).
* Note: The Site Target Infrastructure field was previously referred to as the ‘Production Status’ (Production Status is a misleading term).

Revision as of 15:46, 24 October 2012

<< Back to GOCDB/Documentation_Index
<< Back to GOCDB/Release4/Development

Overview

The proposals outlined below are relevant to the Resource Centre (Site) Registration and Certification Procedure. Proposals 2 and 3 are questionable and may not be necessary.

  • Note: The following status transition rules do not apply to non-EGI (local) scoped sites and services.
  • Note: The Site Target Infrastructure field was previously referred to as the ‘Production Status’ (Production Status is a misleading term).

Definitions

Site Target Infrastructure

The site’s 'Target Infrastructure' specifies the infrastructure that the site delivers to. This value was previously called 'Production Status' which was misleading. Target Infrastrcuture values include:

  • Test (e.g. a test broker network)
  • Production
  • PPS (Obsolete)
  • SC (Obsolete)

Site Certification Status

The site’s Certification Status reflects the site’s progression through the SA1 site certification procedure (See GOCDB/Input_System_User_Documentation#Changing_Site_Certification_Status. This procedure only applies to the EGI ‘Production’ Target Infrastructure. Values include:

  • Candidate (temporary state, max of 2 months)
  • Uncertified
  • Certified (long-term state)
  • Suspended (temporary state, max of 4 months)
  • Closed (indefinite state)

Note, the intended lifetime of the ‘Uncertified’ state is not clearly defined. If this state is regarded as temporary, many sites defined as ‘Production/Uncertified’ should use scoping as an alternative. However, before politically enforcing this, scoping should first be fully supported by ATP/MyEGI/monitoring. Note, state lifetimes are not technically enforced by GOCDB (this could be added as a new RT requirement).

Service Endpoint Production flag (t/f)

Service Endpoints also define a 'Production' boolean flag. This flag specifies if the SE delivers a production quality service (or not) to its target infrastructure. For example:

  • A site with a ‘Production’ Target Infrastructure can provide a mix of both Production and non-Production SEs to that infrastructure.
  • Similarly, a site with a ‘Test’ Target Infrastructure can also define a mix of both Production and non-Production SEs. Importantly however, these SEs deliver to the ‘Test’ infrastructure.

Note, a site with a Certification Status of Candidate/Uncertified/Suspended/Closed can currently provide both Production and non-Production SEs, but these SEs are not included in availability/stats until the site is Certified (uncertified sites are not monitored by default by the NGI SAM).

Proposals:

Proposal 1

Update the poorly named <PRODUCTION_INFRASTRUCTURE> element to become <TARGET_INFRASTRUCTURE> in the PI output (with value of Production or Test).

Proposal 2

This proposal is questionable: A Site's 'Target Infrastructure' and 'Certification Status' settings are currently unrelated and do not affect each other; a site may change its Target Infrastructure independently of the Certification Status. For example, a site that delivers to the ‘Test’ target infrastructure could specify that it is ‘Certified’. This is questionable since a Certified site only really has a meaning to the 'Production' infrastrucutre.

Since the Certification Status values only really apply to the EGI 'Production' infrastructure, we could? impose rules to limit the allowed values of the Certification Status depending on the Target Infrastructure as follows:

  • Sites that define the 'Test' target infrastructure can only specify a 'Candidate' Certification Status.
  • Changing a Site's Target Infrastructure from 'Production' to 'Test' will cause the Site's Certification Status to be automatically relegated to ‘Candidate’.
  • For new sites, ‘Production’ will be the default Target Infrastructure and ‘Candidate’ will be the default Certification Status.

Alternatively, if the different Certification status values are deemed relevant to different Target Infrastructures other than Production (e.g. if a 'Certified Test site' is meaningful), then we should reject this proposal.

Proposal 3

This proposal is questionable: The Service Endpoints 'Production level' flag is a simple boolean which can be translated as ‘Does this SE provide a production level service (t/f) to the Site's target infrastructure?’ Therefore, we could impose the following rule as follows:

  • If the site’s target infrastructure is ‘Production,’ a child SE's Production flag can only be set to true if the site is ‘Certified’?:
This is ok: 
[SiteA: TargetInfrastructure = 'Production', CertificationStatus='Certified']
   |_ Service1 (Production = 'true')
   |_ Service2 (Production = 'false') 
   |_ Service3 (Production = 'true') 

While this COULD be made illegal: 
[SiteB: Target Infrastructure = 'Production', CertificationStatus='Candidate or Uncertified']
   |_ Service1 (Production = 'true') <- does this need to be made illegal?
   |_ Service2 (Production = 'false') 
   |_ Service3 (Production = 'false') 

(Is this really necessary? - since we don't care about the SE Production Status value of 'Candidate' or 'Uncertified' sites)
  • Regardless of above, if the site’s target infrastructure is ‘Test,’ a child SE's Production flag can be true or false.
This is ok: 
[SiteA: TargetInfrastructure = 'Test', CertificationStatus='Candidate']
   |_ Service1 (Production = 'true')
   |_ Service2 (Production = 'false') 
   |_ Service3 (Production = 'true') 

Comments

From S.Burke: "At least for the endpoint flag this seems to be aligned with the GLUE 2 EndpointQualityLevel attribute. I don't see any intrinsic reason you couldn't have a production-quality endpoint in a Test infrastructure, for example to test interoperability with new versions, or to test new versions of some other component interacting with a production SE."

Stephen