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
 
(37 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}
{{Template:GOCDB_menubar}}
{{TOC_right}}
[[Category:GOCDB]]
[[Category:GOCDB]]
<< Back to [[GOCDB/Documentation_Index]] <br/>
<< Back to [[GOCDB/Release4/Development]] <br/>
<< Back to [[GOCDB/Release4/Development]] <br/>


==Extend Scoping to Support Multiple Projects/Target Infrastructures==
===Overview===
===Overview===
This involves conditional enforcement of site certification status transition rules depending on the currently selected Target Infrastructure value (Production or Test).<br/>
The scoping extensions outlined below are relevant to how SEs are monitored in GOCDB and support for hosting multiple projects within a single GOCDB instance.  
* 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).


===Extensions===
* Sites, Services, and NGIs will each be able to define multiple 'scope' tags to associate each with different project/infrastructure scopes.
* 'Site.scope' will be used to identify a site's Target Infrastructure (i.e. Grid/Project) rather than 'Site.Production_Status' value. 
* 'Service.scope'will be used to identify an SE's target infrastructure.
* The scope value will become multi-selection, allowing a site and service to be associated with more than one project.
* The PI '&scope' parameter will allow a comma-separated list of scope values rather than a single scope value.
<!--* 4) The available options for the 'SE.Scope' value will be limited to the parent 'Site.Scope' values. This way, an SE can't define a scope that is not already defined by its parent site.-->
* The 'Site.Production_Status' value is EGI specific and should be used to represent site's overall quality (Production, Test etc) and *not* to identify the Target Infrastructure.
* Once we move the GIIS URL from site to SE, it will be possible to define a GIIS Url per target infrastructure using duplicate SEs defined under different scopes.
* The present certification statuses will remain.
<b><font color="red">Comment (Tiziana)</font></b>: shall we reconsider the semantics of the Target Infrastructure, and use it to define the target production infrastructure a site (or better: an end-point) belongs to? Examples of Target infrastructures could be: EGI, EUDAT, PRACE, TEST. This would mean replacement of what today is "Production" into "EGI".
* Advantages. This would allow a single GOCDB site to host services that are part of different infrastructures.
* Disadvantages. This requires a reconsideration of scoping. Scoping was defined to be a on off (either in EGI or out of it). By having N target infrastructures, not part of EGI would mean being part of another Target Infrastructure).
The impact of this change in production would be small as usage of scoping is still limited in GOCDB.
<b><font color="red">Comment (DM)</font></b>: Yes I agree with your comments, proposals updated to reflect these.
<br/>
<br/>
===Example===
<br/>
[[File:ScopeCertStatusProdStatusRules.jpg|650px|x]]
<br/>
<br/>
<br/>
===Definitions===
===Definitions===
====Site Target Infrastructure====
<b>Site.Production_Status</b>
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:
* Values = Production|Test (<strike>PPS, SC</strike> obsolete)
* Test  (e.g. a test broker network)
* EGI specific flag which is used as a mechanism to stop all of a site’s endpoints from being monitored. 
* Production 
* The GOCDB ‘Site.Production_Status’ field is *currently* labelled in the portal as ‘Infrastructure.’  However, the Scope value should be used to identify the TargInfr as described above.  We could consider deprecating the ‘Site.Production_Status’ field, but this field is currently used in EGI as a shortcut mechanism to indicate that all of a site’s services should be monitored or not.
* <strike>PPS</strike> (Obsolete)
<br/>
* <strike>SC</strike> (Obsolete)
<b>Site.Scope</b>
* Values = EGI|Test|EUDAT|...
* Lists the names of any Grids or Projects to which the Site belongs (an open enum list).
* For GOCDB, ‘Local’ means the site is not part of EGI or any other named Project/Grid. This is equivalent to the ‘AdminDomain.OtherInfo.GRID=INFO’ value in the EGI_GLUE2 profile (p16) which means the Grid is unknown and is present for information purposes.
<br/>
<b>Site.Certification_Status</b>
* Values = Candidate(temporary, max of 2 months)|Uncertified|Certified(long-term state)|Suspended(temporary state, max of 4 months)|Closed(indefinite state)
* EGI specific flag which is used to identify the site’s SA1 site certification status.
* Only Certified sites services are monitored.
<br/>
<b>SE.Scope</b>
* Values = EGI|Test|EUDAT|...
* Allows a Site to define a mix of services for different projects.
* An extra business rule is necessary: An SE can only select a Scope from its parent Site Scope list.
* In the EGI_GLUE2 profile there is no corresponding ‘Service.OtherInfo.GRID’ attribute defined for Service (section 2.8)
<br/>
<b>SE.Production</b>
* Values = True|False
* Quality level/maturity level of the service - does the service deliver a production quality service (or not) to its Target Infrastructure/Project.
* Maps to GLUE2 Service.QualityLevel = development|production|pre-production|testing (open enum)
 
<!--
===Notes===


====Site Certification Status====
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.  
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 <b>procedure should only apply to the ‘Production’ Target Infrastructure</b> (details below). 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) ====
This is questionable: Since the Certification Status values only really apply to the 'EGI' infrastructure/scope, we <b>could?</b> impose rules to limit the allowed values of the Certification Status depending on the Target Infrastructure/Scope as follows:
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:
* Sites that define the 'Test' target infrastructure can only specify a 'Candidate' Certification Status.  
* A site with a ‘Production’ Target Infrastructure can provide a mix of both Production and non-Production SEs to that infrastructure.  
* Changing a Site's Target Infrastructure from 'Production' to 'Test' will cause the Site's Certification Status to be automatically relegated to ‘Candidate’.
* 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.
* For new sites, ‘Production’ will be the default Target Infrastructure and ‘Candidate’ will be the default Certification Status.
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:===
Alternatively, if the <b>different Certification status values are deemed relevant to different Target Infrastructures</b> other than Production (e.g. if a 'Certified Test site' is meaningful), then we should <b>reject</b> this proposal.
The 'Target Infrastructure' and 'Certification Status' are currently unrelated and do not affect each other. At present, a site may change its Target Infrastructure at will regardless of the certification status. For example, the following combinations are allowed but are questionable:
* A ‘Certified’ site that delivers to the ‘Test’ target infrastructure
====Proposal 1.1====
Update the poorly named <PRODUCTION_INFRASTRUCTURE> element to become <TARGET_INFRASTRUCTURE> in the PI output (with value of Production or Test).


====Proposal 1.2====
====Proposal 3====
The Certification Status value should depend on the Target Infrastructure (rather than being unrelated).  This will be enforced using the following Target Infrastructure transitions:
This 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 <b>could</b> impose the following rule as follows:
* For new sites, ‘Production’ will be the default Target Infrastructure and ‘Candidate’ will be the default Certification Status.
* Changing the Site Target Infrastructure from Production to Test: will cause the Site's Certification Status to be automatically relegated to ‘Candidate’ (the site will have to undergo certification again if they swap back to Production).


====Proposal 1.3====
* 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 proposal is questionable: The value of the Production boolean flag (t/f) defined on SEs should dependent on the parent Site's Target Infrastructure:
* 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.’ 
<pre>
<pre>
This is ok:  
This is ok:  
Line 52: Line 87:
   |_ Service3 (Production = 'true')  
   |_ Service3 (Production = 'true')  


This will be made illegal:  
While this COULD be made illegal:  
[SiteB: Target Infrastructure = 'Production', CertificationStatus='Candidate|Uncertified']
[SiteB: Target Infrastructure = 'Production', CertificationStatus='Candidate or Uncertified']
   |_ Service1 (Production = 'true') <- does this need to be made illegal?
   |_ Service1 (Production = 'true') <- does this need to be made illegal?
   |_ Service2 (Production = 'false')  
   |_ Service2 (Production = 'false')  
   |_ Service3 (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)
</pre>
</pre>


* If the site’s target infrastructure is ‘Test’ (meaning the CertificationStatus is relegated to 'Candidate') a child SE's Production flag can be true or false.
* Regardless of above, if the site’s target infrastructure is ‘Test,’ a child SE's Production flag can be true or false.
<pre>
<pre>
This is ok:  
This is ok:  
Line 69: Line 105:
</pre>
</pre>


===Summary===
===Comments===
Target Infrastructure / Certification Status Combinations:
 
* Illegal: Test / *Any* certification status except 'Candidate' (prevented by ruels described above)
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."
* Legal: Production / *Any* Certification Status (following the certification procedure)
 
* Legal: Test / Candidate
Stephen
-->

Latest revision as of 16:20, 5 August 2013

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


GOC DB menu: Home Documentation Index


<< Back to GOCDB/Release4/Development

Extend Scoping to Support Multiple Projects/Target Infrastructures

Overview

The scoping extensions outlined below are relevant to how SEs are monitored in GOCDB and support for hosting multiple projects within a single GOCDB instance.

Extensions

  • Sites, Services, and NGIs will each be able to define multiple 'scope' tags to associate each with different project/infrastructure scopes.
  • 'Site.scope' will be used to identify a site's Target Infrastructure (i.e. Grid/Project) rather than 'Site.Production_Status' value.
  • 'Service.scope'will be used to identify an SE's target infrastructure.
  • The scope value will become multi-selection, allowing a site and service to be associated with more than one project.
  • The PI '&scope' parameter will allow a comma-separated list of scope values rather than a single scope value.
  • The 'Site.Production_Status' value is EGI specific and should be used to represent site's overall quality (Production, Test etc) and *not* to identify the Target Infrastructure.
  • Once we move the GIIS URL from site to SE, it will be possible to define a GIIS Url per target infrastructure using duplicate SEs defined under different scopes.
  • The present certification statuses will remain.


Comment (Tiziana): shall we reconsider the semantics of the Target Infrastructure, and use it to define the target production infrastructure a site (or better: an end-point) belongs to? Examples of Target infrastructures could be: EGI, EUDAT, PRACE, TEST. This would mean replacement of what today is "Production" into "EGI".

  • Advantages. This would allow a single GOCDB site to host services that are part of different infrastructures.
  • Disadvantages. This requires a reconsideration of scoping. Scoping was defined to be a on off (either in EGI or out of it). By having N target infrastructures, not part of EGI would mean being part of another Target Infrastructure).

The impact of this change in production would be small as usage of scoping is still limited in GOCDB.

Comment (DM): Yes I agree with your comments, proposals updated to reflect these.

Example


x


Definitions

Site.Production_Status

  • Values = Production|Test (PPS, SC obsolete)
  • EGI specific flag which is used as a mechanism to stop all of a site’s endpoints from being monitored.
  • The GOCDB ‘Site.Production_Status’ field is *currently* labelled in the portal as ‘Infrastructure.’ However, the Scope value should be used to identify the TargInfr as described above. We could consider deprecating the ‘Site.Production_Status’ field, but this field is currently used in EGI as a shortcut mechanism to indicate that all of a site’s services should be monitored or not.


Site.Scope

  • Values = EGI|Test|EUDAT|...
  • Lists the names of any Grids or Projects to which the Site belongs (an open enum list).
  • For GOCDB, ‘Local’ means the site is not part of EGI or any other named Project/Grid. This is equivalent to the ‘AdminDomain.OtherInfo.GRID=INFO’ value in the EGI_GLUE2 profile (p16) which means the Grid is unknown and is present for information purposes.


Site.Certification_Status

  • Values = Candidate(temporary, max of 2 months)|Uncertified|Certified(long-term state)|Suspended(temporary state, max of 4 months)|Closed(indefinite state)
  • EGI specific flag which is used to identify the site’s SA1 site certification status.
  • Only Certified sites services are monitored.


SE.Scope

  • Values = EGI|Test|EUDAT|...
  • Allows a Site to define a mix of services for different projects.
  • An extra business rule is necessary: An SE can only select a Scope from its parent Site Scope list.
  • In the EGI_GLUE2 profile there is no corresponding ‘Service.OtherInfo.GRID’ attribute defined for Service (section 2.8).


SE.Production

  • Values = True|False
  • Quality level/maturity level of the service - does the service deliver a production quality service (or not) to its Target Infrastructure/Project.
  • Maps to GLUE2 Service.QualityLevel = development|production|pre-production|testing (open enum)