Nagendra Kumar wrote:
> Thanks Anders for your comments.
> I can explain in detail about cb apply for csi addition.
> 1. ccb_1 apply comes and amfd adds csi in its data base. After that Amfd
> sends csi assignment message to Amfnd. Amfnd sends CSI assignment to
> application.
> 2. Amfd responds comes back from apply and is ready for processing any other
> ccbs.
>
Ok at this stage ccb_1 was validatet ok which means the AMF has commited
itself to apply ccb_1 if it receives the apply.
And since it also received the apply_1 it is committed to apply. But
apply_1 is still being processed by application and amfnd.
It is troublesome that the apply can take such a long time. I assume
the application can not "reject" the CSI assignment here!
But the application can of course crash or the AMFND could crash during
this CSI assignment.
Ccb_1 is already applied in the imm so I assume that there is some
runtime state reflecting the "service group stability" that you
mention below. And that reaching "service group stability" I hope is not
something that can be blocked indefinitely.
If that is the case then that service group would be blocked forever.
The real problem here is then this relation between "service group
stability" and validation of a ccb related to a service group.
it sounds to me that the config data expresses a "desired service group
state". The only thing committed by the AMF with ccb_1 is
the agreement/contract that this is a desired state. Actually getting
the CSI set done may take any amount of time and indeed may
never happen with some stubborn or slow or faulty application.
> 3. Imm sends completed callback to Amfd for ccb_2. Amfd validates whether the
> Service Group is stable and can ccb_2 be applied.
Should really "service group stability" be part of validation ?
You could allow the "desired CSI assignments" to just accumulate as
committed CCBs and commited desires and regard any discrepancy between
desired
CSI state and the runtime reality be a runtime problem (application
problem).
If that is unrealistic, then we are talking some kind of resource
allocation being part of the validation.
The resource being "stability of the service group". I assume here that
once a service group is "stable" in this sense,
it never spontaneously becomes "unstable", i.e. stability is persistent
until perturbed by the next CSI set for that service group.
I would then suggest that the AMF for now return ERR_NO_RESOURCES onthe
validation of ccb_2
(one of the allowed return codes for CCB callbacks).
This will today cause ccb_2 to get aborted and thus not solve this
ticket, but this ticket appears impossible to
solve 100%.
To reduce the problem you could implement some kind of delay of
responding to the validation and wait for the
CSI to stabilize. But that delay has to be limited in time. The current
OI callback timeout in the server is 6 seconds and
currenty not configurable in the imm (ticket #16).
You would park the validate callback in a queue and be prepared to get
an abort callback (due to timeout) from
the IMM and then remove it from the queue.
For the IMM to implement TRY_AGAIN logic on the completed callback is
quite complex and it adds complexity
for what seems to be an exotic case. So for now this exotic resource
problem interfering with validate would need
to be managed by the application (AMF here).
> Amfd finds that CSI assignment is undergoing as application is yet to
> respond(application has time to respond till configured csi timeout, it may
> be 1 seconds or 1 hour or more).
The IMM would never do TRY_AGAINs on completed for 1hour+ anyway.
> Amfd can't allow ccb_2 because the SG is not stable and can't commit this ccb
> as when Amfd adds csi in its data base, it need to send csi assignment to
> Amfnd and Amfnd will send Csi assignment to application(same stuff done in
> ccb_1 apply).
>
Well you could argue that you could accept (validate ok on logical
grounds) ccb_2. The subsequent apply of ccb_2 would of course be queued and
just add that much more to the "service group in stability". As long as
the request was logically sound and there was not some kind of static
resource depletion, the CSI set would eventually get done. For this to
be acceptable you would need a runtime state reflecting the instabiltiy
in a way that is comprehensible for an operator probing it.
> As Amfd follows principle of serializing the admin operations, it serialize
> the ccb operations also as doing multiple operations on SG at the same time
> will result in unrecoverable conditions and unhandled error cases.
>
Fair enough.
We are talking a tradeof here between complexity in implementation
(possibly in several services) and practical service availability
of the multiple CSI set on the same service group use case.
> We can't store apply because Act controller will store it and standby
> controller will add it in its data as applier. We don't want asymetric
> configurations, which leads to unrecoverable conditions during
> failovers/switchovers.
>
Or more complexity.
So basically we are just saying that the use case of multiple CSI sets
to the same service group is not something that we can guarantee.
> Anyway, if we return NO_RESOURCE, then imm will return TRY_AGAIN to SMF and
> SMF can TRY again, is that correct ?
No it is not correct.
The IMM will abort the CCB.
IF the IMM ever implemented TRY_AGAIN on completed callbacks (unlikely)
it would only be a TRY_AGAIN between
the OI and the local IMMND. The Imm would not recoil back all the way to
the OM interface doing the saImmOmCdbApply.
A CCB may in general involve several OIs. It would significantly
complicate the distributed commit of a CCB and only for what
I understand is an exotic use case or a use case that could be remodeled
in some way.
What about allowing multiple CSI to the same service group in one CCB.
In principle it should be up to the user to decide how much to group
into one CCB.
Is this not possible with the current AMF ? I.e. will the AMF reject in
validation
a CCB that contains more than one CSI set change ?
> If yes, then we can return NO_RESOURCE in the above cases mentioned.
>
You can return NO_RESORCES, but it will currently cause the IMM to abort
the CCB.
/AndersBj
> Thanks
> -Nagu
>
>
>
> ---
>
> ** [tickets:#750] AMF: creating multiple CSIs are rejected**
>
> **Status:** accepted
> **Milestone:** future
> **Created:** Mon Jan 27, 2014 10:24 AM UTC by Hans Feldt
> **Last Updated:** Tue Mar 18, 2014 10:03 AM UTC
> **Owner:** Nagendra Kumar
>
> AMF supports adding one CSI per CCB to an unlocked SI. This means if several
> CSIs are to be added, many CCBs will be performed by SMF (from a campaign).
> However since the first CSI create is still "pending" when the second CSI one
> comes to AMF, the second one is can be rejected (by AMF). All depending in
> timing.
>
> One problem is that the OI completed callback does not give the OI any chance
> to say TRYAGAIN. It is either accept or reject.
>
> Adding a delay to the campaign between each CSI create is not a plausible
> solution thus AMF needs to support this case.
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in
> <https://sourceforge.net/p/opensaf/tickets/750/>
>
> To unsubscribe from further messages, please visit
> <https://sourceforge.net/auth/subscriptions/>
>
---
** [tickets:#750] AMF: creating multiple CSIs are rejected**
**Status:** accepted
**Milestone:** future
**Created:** Mon Jan 27, 2014 10:24 AM UTC by Hans Feldt
**Last Updated:** Tue Mar 18, 2014 10:03 AM UTC
**Owner:** Nagendra Kumar
AMF supports adding one CSI per CCB to an unlocked SI. This means if several
CSIs are to be added, many CCBs will be performed by SMF (from a campaign).
However since the first CSI create is still "pending" when the second CSI one
comes to AMF, the second one is can be rejected (by AMF). All depending in
timing.
One problem is that the OI completed callback does not give the OI any chance
to say TRYAGAIN. It is either accept or reject.
Adding a delay to the campaign between each CSI create is not a plausible
solution thus AMF needs to support this case.
---
Sent from sourceforge.net because [email protected] is
subscribed to http://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
http://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
