The primary idea behind the fix for 1169 is to give a special treatment to
scenarios when there is a fault involved.
i.e. If there is a fault currently being treated then we should return bad op,
otherwise return try_again thereby passing the onus on the admin to determine
what to do with this try_again.
>From there on, the admin has the flexiblity to either stop, introspect and
>continue or simply cancel 'this' operation or the bigger encapsulating
>operation(like upgrade).
I think, the general idea to say that the op is 'not allowed' (bad op) is to
indicate that the service group has reached a potentially degenerated status
A service group could be in a degenerated state in 3 scenarios
(1) Degenerated by configuration, for eg:- configuring only one SU in a 2N
(2) Degenerated by faults. And some recovery/repair or re-adjustment is in
progress.
(3) Temporary degeneration. This scenario cannot be called truly degenerated.It
is only a passing phase.
In practicality all transient situations could fall under this category and in
reality(in implementation) is difficult to determine when the transient state
ends i.e. the standbys will come into existence.
#1169 is about scenario (3) above. Therefore returning try_again to indicate
that the operation is valid but cannot be handled now because it is only a
temporary degeneration, is just fine and in line with the spec. Let us document
the reason to return try_again in this scenario (3) above.
If a test case fails in scenarios (1) and (2), then we should have a ticket
against spec deviation.
---
** [tickets:#1294] BAD_OPERATION needs to be returned for si-swap when there is
single controller**
**Status:** unassigned
**Milestone:** 4.6.RC1
**Created:** Tue Mar 31, 2015 07:51 AM UTC by Sirisha Alla
**Last Updated:** Tue Mar 31, 2015 08:31 AM UTC
**Owner:** nobody
In the scenario of https://sourceforge.net/p/opensaf/tickets/1169/, when the
standby middleware SU is in instantiating state then TRY_AGAIN needs to be
returned. Else BAD_OPERATION needs to be returned. Returning TRY_AGAIN in all
scenarios is a deviation from spec.
AMF spec in 9.4.8 says:
"If no standby assignments are available for an SI (potentially because the AMF
cluster is in a degenerated status, and reduction procedures have been engaged)
when this operation is invoked on a particular logical entity, the
SA_AIS_ERR_BAD_OPERATION error value shall be returned.
In other words, this operation shall be allowed by the Availability Management
Framework to proceed under the following circumstances.
1) The concerned SI is assigned active or quiescing to one service unit.
2) The concerned SI is assigned standby to at least another service unit.
3) The HA readiness state of the service unit currently assigned the standby HA
state for the target service instance is ready-for-assignment.
4) The node capacity limits for the affected AMF nodes are not violated when the
HA state assignments are swapped.
The Availability Management Framework shall not proceed with this procedure when
the presence state of the constituent service units of the service group
protecting the SI is instantiating, restarting, or terminating, and should
return an SA_AIS_ERR_TRY_AGAIN error value conveying that the action is valid
but not currently possible."
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
