Here is a summary of what I have said already:
1) This problem could be solved in the AMF, it is a resource handling
problem in the AMF, not really a validation problem. Solving it in the
AMF may be complex, but it is possible and really the "right" place
to solve it.
2) The AMF has the option of bailing out on the CCB because of the current
implementation can not guarantee the ability to apply a seconds csi-set when
there is a current csi-set apply still on going. Note here that the real
problem is the queuing of the apply. The validation is not really the
problem. This is the current solution. It is also the current limitation
addressed by this ticket. This ticket could reasonably be converted to an
AMF enhancement.
3) I have repeatedly asked the question if it is possible for a user that
really wishes to do more than one csi-set, to do so in ONE ccb.
I have still not seen any reply on that. In this case there would be only
one ccb-apply covering several csi-set. This could possibly be simpler to
handle in the AMF and it would resolve this ticket.
4) The IMM could implement a retry handling of the completed callback
at some point. This would be a retry handling between the local IMMND
and the OI (or OI's) that reside at that node. Remember that there may
be several OIs involved in a CCB.
5) The IMM will never implement a retry handling that recoils all the way
back to the OM user. Remember again that there may be several OIs, some
of which reply ok and some of which reply ERR_BUSY. The distributed
state handing would become horrendously complex to keep track of a partially
validated CCB, bouncing back and forth between the om-user and the set
of OIs. The case where there is only one OI could possibly be handled in
that way. But why? It is both simpler and more robust to handle in locally
at the IMMND where the blocked OI resides.
6) Either a solution in the AMF (1) or a solution in the IMM (4) implies
a need or a configurable OI timeout (#16) since it is likely that the
current hard-coded limit of 6 seconds may be exceeded.
Finally, solution (3) is really the correct solution. What we have here
is a set/sequence of config changes which "must" be possible to apply
as one "package". If not, then this ticket would not exist. All these
*related* CSI sets should really be placed in one CCB.
The apply may then take more time, possibly even time-out towards the
OM user, but the om-library catches this and really has an extended
logic to probe the outcome of the CCB (in the current implementation).
---
** [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 25, 2014 01:34 PM 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 opensaf-tickets@lists.sourceforge.net 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.
------------------------------------------------------------------------------
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
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
