Details
-
Type:
Improvement Request
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.0.0
-
Fix Version/s: 5.0.1
-
Component/s: Installation/Deployment
-
Security Level: Public
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|
|
||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Minor [ 4 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Link |
This issue blocks |
| Description |
The JBI specification clearly specifies that if all of the SUs of an SA fail to deploy, then the SA fails to deploy, but if at least one of the SUs does not fail, then the SA is properly deployed.
The JBI specification is not clear for the other operations so we make the following choices: * We mirror the same behaviour for start and init. * We simply log errors for stop and shutdown. The idea is to be able to report enough informations to the administrators when possible while not preventing to undeploy an SA when there is problems. |
The JBI specification clearly specifies that if all of the SUs of an SA fail to deploy, then the SA fails to deploy, but if at least one of the SUs does not fail, then the SA is properly deployed.
The JBI specification is not clear for the other operations so we make the following choices: * We mirror the same behaviour for start and init. * We simply log errors for stop and shutdown. The idea is to be able to report enough informations to the administrators when possible while not preventing to undeploy an SA when there is problems. For example, a common use case such as starting an SA with only one SU that fails simply fail (while before it simply silently failed...) |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.0.1 [ 10579 ] | |
| Resolution | Fixed [ 1 ] |