Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
devel:documentation:roles:adm:role_assignment [2019/07/23 09:06]
svandav [Failed state]
devel:documentation:roles:adm:role_assignment [2019/07/23 11:37]
svandav [Running state]
Line 104: Line 104:
  
 {{ :devel:documentation:roles:adm:request-inprogress.png?800 |}} {{ :devel:documentation:roles:adm:request-inprogress.png?800 |}}
 +
 +**Second** situation when could be request in running state is if role assign **the virtula system**.
 +
 +If the request assign or changes an account on the virtual system, then the virtual system creates a request by default, pending implementation by the appropriate implementer. Our request to change roles will be in a running state until all possible requests on virtual systems are resolved. The purpose of this wait is to ensure that the final notification of the completion of the request is sent after the real implementation of the requirements on the systems representing the virtual systems.
 +
 +In this situation has system state **RUNNING** orange color and show message: **Some requests on this vritual systems [Name of vritual systems] are not resloved!**.
 +
 +{{ :devel:documentation:roles:adm:request-inprogress-on-vs.png?800 |}}
  
 ==== Failed state ==== ==== Failed state ====
  
-Some of the provisioning operations failed.+Some of the **provisioning operations failed**.
  
 This is typically a situation where the connector throw an exception. If you click on the status, you will see information on **which systems have failed**. This is typically a situation where the connector throw an exception. If you click on the status, you will see information on **which systems have failed**.
 +
 +If the request contains an error, the status on the systems will be set to executed only if all errors are resolved. This means that they will either be successfully executed (for example by retry mechanism) or will be canceled. If the operation is canceled, the status on the request item will also be set to **CANCELED**.
  
 {{ :devel:documentation:roles:adm:request-failed.png?800 |}} {{ :devel:documentation:roles:adm:request-failed.png?800 |}}
Line 123: Line 133:
 {{ :devel:documentation:roles:adm:request-failed-detail.png?800 |}} {{ :devel:documentation:roles:adm:request-failed-detail.png?800 |}}
  
 +==== Blocked state ====
 +
 +Some of the **provisioning operations were blocked**.
 +
 +This is typically a situation where some system has blocked write operations. The behavior in this case is very similar to the case when the provisioning operation is in the error. If you click on the status, you will see information **which systems are blocked**.
 +
 +If the request contains a blocked operations, the status on the systems will be set to executed only if all blocked operations will be resolved. This means that they will either be successfully executed or will be canceled. If the operation is canceled, the status on the request item will also be set to **CANCELED**.
 +
 +{{ :devel:documentation:roles:adm:request-blocked.png?800 |}}
 +
 +==== Not executed state ====
 +This state is **very similar to the case when the provisioning operation is blocked**. Occures where system is seta to **read only** mode.
 ===== Link to request from a provisioning operations ===== ===== Link to request from a provisioning operations =====
  
  • by husniko