- **status**: review --> fixed
- **Comment**:
default 5.0
changeset: 7329:0f7b563c5405 [0f7b56]
tag: tip
user: Hung Nguyen <hung.d.ngu...@dektech.com.au>
date: Wed Mar 16 18:05:41 2016 +0700
summary: imm: Send all writable attributes to applier in
OiCcbObjectModifyCallback [#1651]
---
** [tickets:#1651] imm: OiCcbObjectModifyCallback for appliers should include
attributes that is not modified**
**Status:** fixed
**Milestone:** 5.0.FC
**Created:** Mon Dec 28, 2015 09:06 AM UTC by Hung Nguyen
**Last Updated:** Fri Feb 05, 2016 10:01 AM UTC
**Owner:** Hung Nguyen
First, the reason for sending all values is to solve the initialization
problem.
Ideally you would only have to send all values in the first callback for any
given object and for any given attachement.
Once the OI/appplier has the current values for an object it would only need to
get the replacement values for later callbacks.
The problem is that this is difficult to implement in the server.
So the practical solution is to always send all values.
This is how the special applier works.
It is also now suggested for regular appliers.
Second, one difference between appliers and OIs is that OIs do have some chance
of almost dooing safe-read.
Since only one or zzero OIs can be attached for any given class/object, if zero
is attached then ideally no CCB should
modify the object or insrances of the class. The problem is of course the
idiotic default option specified by SAF
that allows the OM user to say IGNORE IF THERE IS NO OI ATTACHED.
If you use immcfg then this wil not happen because immcfg by default does not
allow this.
Most OM applications I hope also do not use that option. It is visible in the
syslogs if it is used as
a message saying that the oepration is unsafe.
Another difference between OIs and appliers is that OIs are supposed to
VALIDATE the CCB.
This means that a "new" value for an attribute that is not "writable" causes a
problem.
The OI must write code to check that the "new" proposed value is the same as
the "old" value.
It is really a silly problem.
So the suggestion is to only send the after values for attributes that have
actually changed value, for regaular OIs.
The main simpplification of #801 is still there for regular OIs, i.e. to only
have to deal with replace.
You could argue that appliers should get the same protocol.
But for appliers the initialization problem is much more dificult.
Appliers have no way to perform a safe read and the detachmenet of an applier
does not stop CCB processing.
In theory an appplier could itself set admin-owner over a set of objects or
classes, but as you know the admin-owner concept is
not secure itself and the applier can only set admin-owner for objects that
exist so it does noot cover object creates.
So appliers desperately need a safe way to initialize, even more so than
regular OIs.
This ticket is separated from [#801]
---
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.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
