subject:"\[tickets\] \[opensaf\:tickets\] #1553 AMF\: Send CsiSetCallback immediately when CSI attributes are modified \(loadbalancing, VM migration usecases\)"

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-09-19 Thread Praveen

Updated PR doc  in :
changeset:   190:c4d93e4c37f7
tag: tip
user:praveen.malv...@oracle.com
date:Tue Sep 20 11:10:08 2016 +0530
summary: amf: update PR doc for enhancements [#1608], [#1454] and [#1553]



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** fixed
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Mon Aug 29, 2016 12:35 PM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.

Implementation scope:
 Introduction of new resources: 
-saAmfInitialize_5() API,
-callback structure SaAmfCallbacksT_5 and
-CSI Attribute Change callback OsafCsiAttributeChangeCallbackT.
-new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI.
As a part of \#1553, minor version (SAF) of AMF will be updated to 02 because 
of introduction of  aobve mentioned resources in agent. So highest supported 
version now becomes B.04.02.

Description of new resources at agent:
A)OsafCsiAttributeChangeCallbackT
AMF will use this callback to communicate to a running component
any runtime change in the assigned CSI Attribute value.
A component can register this callback using new API 
saAmfInitialize_5().
Callback Characteristics:
-Arguments:
 typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT 
invocation,
const SaNameT *csiName, SaAmfCSIAttributeListT 
csiAttr);
-After receving this callback, a component will have to respond 
to AMFND
  using saAmfResponse_4() API with the same invocation number.
-Callback will be invoked in the context of registered process.
-Callback is meant for SA-Aware component, PROXIED PI component 
and
 PROXIED NPI component. In cases of proxied it will be given to 
proxy.
-Callback timeout will be same as 
saAmfCompCSISetCallbackTimeout or
 saAmfCtDefCallbackTimeout.
B)SaAmfCallbacksT_5 (new callback structure)
typedef struct {
SaAmfHealthcheckCallbackT   
saAmfHealthcheckCallback;
SaAmfComponentTerminateCallbackT
saAmfComponentTerminateCallback;
SaAmfCSISetCallbackTsaAmfCSISetCallback;
SaAmfCSIRemoveCallbackT 
saAmfCSIRemoveCallback;
SaAmfProtectionGroupTrackCallbackT_4
saAmfProtectionGroupTrackCallback;
SaAmfProxiedComponentInstantiateCallbackT   
saAmfProxiedComponentInstantiateCallback;
SaAmfProxiedComponentCleanupCallbackT   
saAmfProxiedComponentCleanupCallback;
SaAmfContainedComponentInstantiateCallbackT 
saAmfContainedComponentInstantiateCallback;
SaAmfContainedComponentCleanupCallbackT 
saAmfContainedComponentCleanupCallback;
OsafCsiAttributeChangeCallbackT 
osafCsiAttributeChangeCallback;
} SaAmfCallbacksT_5;
This is new callback structure consisting of all B.04.01 callbacks and 
newly
introduced OsafCsiAttributeChangeCallbackT. A component can register all
callbacks including

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-08-29 Thread Praveen

- **status**: review --> fixed
- **Comment**:

changeset:   7977:3cdd554fbbd6
tag: tip
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:51:26 2016 +0530
summary: samples/amf: update amf sa-aware demo for CSI attribute change 
callback. [#1553]

changeset:   7976:b5da43b1f1ce
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:50:27 2016 +0530
summary: amfa: add support for csi attribute change callback at amfa. 
[#1553]

changeset:   7975:ddb4db46b4c8
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:49:47 2016 +0530
summary: amfnd: add support for csi attribute change callback at amfnd. 
[#1553]

changeset:   7974:a22ce66187ff
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:48:47 2016 +0530
summary: amfd: send msg to AMFND upon modification of safCsiAttr [#1553]

changeset:   7973:2c659b57d28d
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:47:30 2016 +0530
summary: amf: add new D2ND message and new ND to Agent message. [#1553]

changeset:   7972:f2d92561c55c
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:46:10 2016 +0530
summary: amf: amf: add saAmf_B_04_02.h for new intialize API, callback and 
callback structure [#1553]

changeset:   7971:b1503f8425a2
user:praveen.malv...@oracle.com
date:Mon Aug 29 17:43:04 2016 +0530
summary: amf: add README for implementation details [#1553]

Will update PR doc.



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** fixed
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Tue Aug 23, 2016 12:00 PM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.

Implementation scope:
 Introduction of new resources: 
-saAmfInitialize_5() API,
-callback structure SaAmfCallbacksT_5 and
-CSI Attribute Change callback OsafCsiAttributeChangeCallbackT.
-new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI.
As a part of \#1553, minor version (SAF) of AMF will be updated to 02 because 
of introduction of  aobve mentioned resources in agent. So highest supported 
version now becomes B.04.02.

Description of new resources at agent:
A)OsafCsiAttributeChangeCallbackT
AMF will use this callback to communicate to a running component
any runtime change in the assigned CSI Attribute value.
A component can register this callback using new API 
saAmfInitialize_5().
Callback Characteristics:
-Arguments:
 typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT 
invocation,
const SaNameT *csiName, SaAmfCSIAttributeListT 
csiAttr);
-After receving this callback, a component will have to respond 
to AMFND
  using saAmfResponse_4() API with the same invocation number.
-Callback will be invoked in the context of registered process.
-Callback is meant for SA-Aware component, PROXIED PI component 
and
 PROXIED NPI component. In cases of proxied it will be given to 
proxy.
-Callback timeout will be same as 
saAmfCompCSISetCallbackTimeout or

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-08-23 Thread Praveen

Removed old attahcments as there were minor problem when applied. Attached are
the new ones.

Attachments:

-
[1553_longdn.tgz](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/c4ad2c3e/7d0a/attachment/1553_longdn.tgz)
(23.0 kB; application/x-compressed)
-
[1553_longdn_rebased.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/c4ad2c3e/7d0a/attachment/1553_longdn_rebased.patch)
(92.0 kB; application/octet-stream)

---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are
modified (loadbalancing, VM migration usecases)**

**Status:** review
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Tue Aug 23, 2016 06:54 AM UTC
**Owner:** Praveen

AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external
to OpenSAF that can choose to modify some attributes of an application
component's workload which is currently assigned ACTIVE (without loss of
service). In such scenarios it is possible (and necessary) for both AMF and the
external load balancers to throttle each other. The reverse throttling(from AMF
to the external load balancer) is possible based on any changes to the
NodeCapacity limitations set in AMF, but that is for later/future
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is
currently serving traffic originating from a source/target X, based on some
network criteria the load balancer can choose to re-configure/modify that
application to serve traffic from a different source/target Y. Such change in
information related to that workload could be communicated to that application
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the
attributes of a workload i.e. csiattribute name-value pair, and then the
altered name-value information is communicated to that application or
associated application components 'immediately' instead of waiting for the next
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI
to be locked. But the modified attributes are sent only after a subsequent
admin operation. This ticket is intended to evaluate and support sending
CSIsetcallback (with the same CSI state information but modified csi
attributes) immediately.

Implementation scope:
Introduction of new resources:
-saAmfInitialize_5() API,
-callback structure SaAmfCallbacksT_5 and
-CSI Attribute Change callback OsafCsiAttributeChangeCallbackT.
-new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI.
As a part of \#1553, minor version (SAF) of AMF will be updated to 02 because
of introduction of aobve mentioned resources in agent. So highest supported
version now becomes B.04.02.

Description of new resources at agent:
A)OsafCsiAttributeChangeCallbackT
AMF will use this callback to communicate to a running component
any runtime change in the assigned CSI Attribute value.
A component can register this callback using new API
saAmfInitialize_5().
Callback Characteristics:
-Arguments:
typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT
invocation,
const SaNameT *csiName, SaAmfCSIAttributeListT
csiAttr);
-After receving this callback, a component will have to respond
to AMFND
using saAmfResponse_4() API with the same invocation number.
-Callback will be invoked in the context of registered process.
-Callback is meant for SA-Aware component, PROXIED PI component
and
PROXIED NPI component. In cases of proxied it will be given to
proxy.
-Callback timeout will be same as
saAmfCompCSISetCallbackTimeout or
saAmfCtDefCallbackTimeout.
B)SaAmfCallbacksT_5 (new callback structure)
typedef struct {
SaAmfHealthcheckCallbackT
saAmfHealthcheckCallback;
SaAmfComponentTerminateCallbackT
saAmfComponentTerminateCallback;
SaAmfCSISetCallbackTsaAmfCSISetCallback;
SaAmfCSIRemoveCallbackT
saAmfCSIRemoveCallback;
SaAmfProtectionGroupTrackCallbackT_4
saAmfProtectionGroupTrackCallback;
SaAmfProxiedComponentInstantiateCallbackT
saAmfProxiedComponentInstantiateCallback;
SaAmfProxiedComponentCleanupCallbackT
saAmfProxiedComponentCleanupCallback;
SaAmfContainedComponentInstantiateCallbackT
saAmfContainedComponentInstantiateCallback;
SaAmfContainedComponentCleanupCallbackT
saAmfContainedComponentCleanupCallback;
OsafCsiAttributeChangeCallbackT
osafCsiAttributeChangeCallback;

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-08-23 Thread Praveen

Patches rebased on long dn patches 1553_longdn.tgz.
Also attached is 1553_longdn_rebased.patch (As a single patch rebased on lonng
dn changes).

Attachments:

-
[1553_longdn.tgz](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/c4ad2c3e/58dd/attachment/1553_longdn.tgz)
(23.0 kB; application/x-compressed)
-
[1553_longdn_rebased.patch](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/c4ad2c3e/58dd/attachment/1553_longdn_rebased.patch)
(92.1 kB; application/octet-stream)

---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are
modified (loadbalancing, VM migration usecases)**

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-08-15 Thread Praveen

- **status**: accepted --> review
- **Comment**:

Published intial version with some TODOs:
1)Invocation of INSTANTIATE command for a Non Proxied NPI component.
2)Introduce saAmf_B_04_02.h for new resources at agent.
3)These patches are old (work done in 5.0), so
re-base over #1642(AMF long dn) and other C++ refactoring.



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** review
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Tue Jul 26, 2016 07:24 AM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.

Implementation scope:
 Introduction of new resources: 
-saAmfInitialize_5() API,
-callback structure SaAmfCallbacksT_5 and
-CSI Attribute Change callback OsafCsiAttributeChangeCallbackT.
-new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI.
As a part of \#1553, minor version (SAF) of AMF will be updated to 02 because 
of introduction of  aobve mentioned resources in agent. So highest supported 
version now becomes B.04.02.

Description of new resources at agent:
A)OsafCsiAttributeChangeCallbackT
AMF will use this callback to communicate to a running component
any runtime change in the assigned CSI Attribute value.
A component can register this callback using new API 
saAmfInitialize_5().
Callback Characteristics:
-Arguments:
 typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT 
invocation,
const SaNameT *csiName, SaAmfCSIAttributeListT 
csiAttr);
-After receving this callback, a component will have to respond 
to AMFND
  using saAmfResponse_4() API with the same invocation number.
-Callback will be invoked in the context of registered process.
-Callback is meant for SA-Aware component, PROXIED PI component 
and
 PROXIED NPI component. In cases of proxied it will be given to 
proxy.
-Callback timeout will be same as 
saAmfCompCSISetCallbackTimeout or
 saAmfCtDefCallbackTimeout.
B)SaAmfCallbacksT_5 (new callback structure)
typedef struct {
SaAmfHealthcheckCallbackT   
saAmfHealthcheckCallback;
SaAmfComponentTerminateCallbackT
saAmfComponentTerminateCallback;
SaAmfCSISetCallbackTsaAmfCSISetCallback;
SaAmfCSIRemoveCallbackT 
saAmfCSIRemoveCallback;
SaAmfProtectionGroupTrackCallbackT_4
saAmfProtectionGroupTrackCallback;
SaAmfProxiedComponentInstantiateCallbackT   
saAmfProxiedComponentInstantiateCallback;
SaAmfProxiedComponentCleanupCallbackT   
saAmfProxiedComponentCleanupCallback;
SaAmfContainedComponentInstantiateCallbackT 
saAmfContainedComponentInstantiateCallback;
SaAmfContainedComponentCleanupCallbackT 
saAmfContainedComponentCleanupCallback;
OsafCsiAttributeChangeCallbackT 
osafCsiAttributeChangeCallback;
} SaAmfCallbacksT_5;
This is new callback structure consisting of all B.04.01 callbacks and 
newly

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-07-26 Thread Praveen

Changes at AMFD (CSI Attribute Change Callback):
1)Support for new attribute osafAmfCSICommunicateCsiAttributeChange in class 
SaAmfCSI.
  Dynamic modification of this attribute is supported. Default value will be 0.
2)New message AVSV_D2N_COMPCSI_ASSIGN_MSG from AMFD to AMFND for compcsi related
  information. As of now only CSI attribute list will be sent to AMFND.
  In future it can be used in the context of tickets like \#538 (TERM_FAILED 
state) and \#83.
3)Upon modification of CSI attribute value for a object of class 
"SaAmfCSIAttribute",
  AMFD will send a message to AMFND with new list. For a NON PROXIED NPI 
component,
  message will not be sent if osafAmfCSICommunicateCsiAttributeChange is false.
  For such a component, change will come into effect only when its SI is locked
  and unlocked or other such ways.
4)AMFD now also maintains MDS install version of all AMFNDs in
  std::map nds_mds_ver_db.
  It will be updated whenever AMFD gets MDS_UP and MDS_DOWN for AMFND.
  Using this AMFD can decide whether message is meant for particular AMFND much
  before encode callback given by MDS.

Changes at AMFND (CSI Attribute Change Callback):
1)New internal AMF callback from AMFND to AMF agent corresponding to
  OsafCsiAttributeChangeCallbackT for giving modified CSI Attribute
  Name value pairs to component (AVSV_AMF_CSI_ATTR_CHANGE_PARAM).
2)AMFND processes AVSV_D2N_COMPCSI_ASSIGN_MSG from AMFD. Upong receving
  CSI attribute list, it updates its databae with modified information.
  If compoent has registered with new callback OsafCsiAttributeChangeCallbackT,
  then it will send this modification through internal callback 
AVSV_AMF_CSI_ATTR_CHANGE_PARAM
  to AMF agent.
3)AMFND now maintains MDS install version of AMF AGENTs in
std::map agent_mds_ver_db.
  It will be updated whenever AMFND gets MDS_UP and MDS_DOWN for AMF Agent.
  Using this AMFND can decide whether message is meant for particular Agent much
  before encode callback given by MDS.
4)AMFND maintains now SAF version for each registered component.
  AMFND will get it from Agent through existing component registeration message.

Changes at AMF Agent (CSI Attribute Change Callback):
1)Because of different AMF callback struture correponding to each of B.01.01
  B.04.01, introduced an internal callback structure OsafAmfCallbacksT.
  It consists of callback from each AMF version. Since callback for each
  intialization needs to be maintained internally in AVA_HDL_REC. With this
  internal structure, same handle can used internally for any initialization
  of AMF service. Here it is:
typedef struct osaf_amf_cbk {
SaAmfHealthcheckCallbackT   
saAmfHealthcheckCallback;
SaAmfComponentTerminateCallbackT
saAmfComponentTerminateCallback;
SaAmfCSISetCallbackTsaAmfCSISetCallback;
SaAmfCSIRemoveCallbackT 
saAmfCSIRemoveCallback;
SaAmfProtectionGroupTrackCallbackT  
saAmfProtectionGroupTrackCallback;
SaAmfProtectionGroupTrackCallbackT_4
saAmfProtectionGroupTrackCallback_4; //Only in B.04.01
SaAmfProxiedComponentInstantiateCallbackT   
saAmfProxiedComponentInstantiateCallback;
SaAmfProxiedComponentCleanupCallbackT   
saAmfProxiedComponentCleanupCallback;
SaAmfContainedComponentInstantiateCallbackT 
saAmfContainedComponentInstantiateCallback;
SaAmfContainedComponentCleanupCallbackT 
saAmfContainedComponentCleanupCallback;
OsafCsiAttributeChangeCallbackT 
osafCsiAttributeChangeCallback; //OpenSAF implementation.
} OsafAmfCallbacksT;
  Also added utility function to copy callbacks from AMF callbacks structure to 
this internal one.
  AMF agent will use OsafAmfCallbacksT internally instead of 
SaAmfCallbacksT_<#x>.
2)Implementation of saAmfInitialize_5() in ava_api.cc.
3)Now saAmfRegister() also sends SAF version to AMFND.


Will update more on AMFD and AMFND MDS versioning before publishing the patches.


---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** accepted
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Mon Jul 25, 2016 06:09 AM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-07-25 Thread Praveen

- Description has changed:

Diff:



--- old
+++ new
@@ -7,9 +7,59 @@
 Today AMF supports modifying csi attribute name-value without requiring that 
SI to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.
 
 Implementation scope:
-1)Upon modification of CSI attribute, AMF will send a CSI Set callback to the 
component (to which corresponding CSI is assigned) with same HA state. Callback 
will contain list of all configured csiattribute name-value pairs (not only the 
changed one). If CSI is not assigned, then no callback will be issued.
-Note: AMF spec does not talk about reinvocation of CSI set callback in the 
context of csi-attribute modification. But reinvocation of calback with same HA 
state information is discussed in case like failure handing in N-Way model  AMF 
B.04.01 "3.6.4.5 Failure Handling " page 167.
-2)All characteristics associated with a CSI SET callback will be applicable 
with respect to invocation of callback like waiting response from component via 
saAmfResponse() API and generation of error report if component does not 
respond within the configured callbacktimeout.
-3)Feature will be configurable either through amfd.conf or via some attribute 
in CSI. It means if the feature is enabled then only AMF will invoke callback 
on component. If feature is disabled then existing behaviour will continue 
which means change will come into effect via lock/unlock of SI and other 
similar means involving reassignment of SI.
-4) Although  CLC-CLI commands are idempotents as per spec, modification of CSI 
attribture for a NPI component will not lead to re-execution of INSTANTIATE 
command for a NPI component. For such a component existing behavior will 
continue.
-5)Since all middleware components are sa-aware, this feature will be supported 
for MW services also.
+ Introduction of new resources: 
+-saAmfInitialize_5() API,
+-callback structure SaAmfCallbacksT_5 and
+-CSI Attribute Change callback OsafCsiAttributeChangeCallbackT.
+-new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI.
+As a part of \#1553, minor version (SAF) of AMF will be updated to 02 because 
of introduction of  aobve mentioned resources in agent. So highest supported 
version now becomes B.04.02.
+
+Description of new resources at agent:
+A)OsafCsiAttributeChangeCallbackT
+AMF will use this callback to communicate to a running component
+any runtime change in the assigned CSI Attribute value.
+A component can register this callback using new API 
saAmfInitialize_5().
+Callback Characteristics:
+-Arguments:
+ typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT 
invocation,
+const SaNameT *csiName, SaAmfCSIAttributeListT 
csiAttr);
+-After receving this callback, a component will have to 
respond to AMFND
+  using saAmfResponse_4() API with the same invocation number.
+-Callback will be invoked in the context of registered process.
+-Callback is meant for SA-Aware component, PROXIED PI 
component and
+ PROXIED NPI component. In cases of proxied it will be given 
to proxy.
+-Callback timeout will be same as 
saAmfCompCSISetCallbackTimeout or
+ saAmfCtDefCallbackTimeout.
+B)SaAmfCallbacksT_5 (new callback structure)
+typedef struct {
+SaAmfHealthcheckCallbackT   
saAmfHealthcheckCallback;
+SaAmfComponentTerminateCallbackT
saAmfComponentTerminateCallback;
+SaAmfCSISetCallbackT
saAmfCSISetCallback;
+SaAmfCSIRemoveCallbackT 
saAmfCSIRemoveCallback;
+SaAmfProtectionGroupTrackCallbackT_4
saAmfProtectionGroupTrackCallback;
+SaAmfProxiedComponentInstantiateCallbackT   
saAmfProxiedComponentInstantiateCallback;
+SaAmfProxiedComponentCleanupCallbackT   
saAmfProxiedComponentCleanupCallback;
+SaAmfContainedComponentInstantiateCallbackT 
saAmfContainedComponentInstantiateCallback;
+SaAmfContainedComponentCleanupCallbackT 
saAmfContainedComponentCleanupCallback;
+OsafCsiAttributeChangeCallbackT 
osafCsiAttributeChangeCallback;
+} SaAmfCallbacksT_5;
+This is new callback structure consisting of all B.04.01 callbacks and 
newly
+introduced OsafCsiAttributeChangeCallbackT. A component can register 
all
+callbacks including new one with new API saAmfInitialize_5().
+C)New API:  SaAisErrorT saAmfInitialize_5( SaAmfHandleT *amfHandle, const 
SaAmfCallbacksT_5
+*amfCallbacks, SaVersionT *version)
+

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-04-11 Thread Mathi Naickan

- **Milestone**: 5.0.FC --> 5.1.FC



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** accepted
**Milestone:** 5.1.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Mon Mar 21, 2016 09:47 AM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.

Implementation scope:
1)Upon modification of CSI attribute, AMF will send a CSI Set callback to the 
component (to which corresponding CSI is assigned) with same HA state. Callback 
will contain list of all configured csiattribute name-value pairs (not only the 
changed one). If CSI is not assigned, then no callback will be issued.
Note: AMF spec does not talk about reinvocation of CSI set callback in the 
context of csi-attribute modification. But reinvocation of calback with same HA 
state information is discussed in case like failure handing in N-Way model  AMF 
B.04.01 "3.6.4.5 Failure Handling " page 167.
2)All characteristics associated with a CSI SET callback will be applicable 
with respect to invocation of callback like waiting response from component via 
saAmfResponse() API and generation of error report if component does not 
respond within the configured callbacktimeout.
3)Feature will be configurable either through amfd.conf or via some attribute 
in CSI. It means if the feature is enabled then only AMF will invoke callback 
on component. If feature is disabled then existing behaviour will continue 
which means change will come into effect via lock/unlock of SI and other 
similar means involving reassignment of SI.
4) Although  CLC-CLI commands are idempotents as per spec, modification of CSI 
attribture for a NPI component will not lead to re-execution of INSTANTIATE 
command for a NPI component. For such a component existing behavior will 
continue.
5)Since all middleware components are sa-aware, this feature will be supported 
for MW services also.


---

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.--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-03-21 Thread Praveen

- Description has changed:

Diff:



--- old
+++ new
@@ -6,6 +6,10 @@
 
 Today AMF supports modifying csi attribute name-value without requiring that 
SI to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.
 
-
-
-Will update implementation scope soon...
+Implementation scope:
+1)Upon modification of CSI attribute, AMF will send a CSI Set callback to the 
component (to which corresponding CSI is assigned) with same HA state. Callback 
will contain list of all configured csiattribute name-value pairs (not only the 
changed one). If CSI is not assigned, then no callback will be issued.
+Note: AMF spec does not talk about reinvocation of CSI set callback in the 
context of csi-attribute modification. But reinvocation of calback with same HA 
state information is discussed in case like failure handing in N-Way model  AMF 
B.04.01 "3.6.4.5 Failure Handling " page 167.
+2)All characteristics associated with a CSI SET callback will be applicable 
with respect to invocation of callback like waiting response from component via 
saAmfResponse() API and generation of error report if component does not 
respond within the configured callbacktimeout.
+3)Feature will be configurable either through amfd.conf or via some attribute 
in CSI. It means if the feature is enabled then only AMF will invoke callback 
on component. If feature is disabled then existing behaviour will continue 
which means change will come into effect via lock/unlock of SI and other 
similar means involving reassignment of SI.
+4) Although  CLC-CLI commands are idempotents as per spec, modification of CSI 
attribture for a NPI component will not lead to re-execution of INSTANTIATE 
command for a NPI component. For such a component existing behavior will 
continue.
+5)Since all middleware components are sa-aware, this feature will be supported 
for MW services also.






---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** accepted
**Milestone:** 5.0.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Mon Jan 25, 2016 09:59 AM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.

Implementation scope:
1)Upon modification of CSI attribute, AMF will send a CSI Set callback to the 
component (to which corresponding CSI is assigned) with same HA state. Callback 
will contain list of all configured csiattribute name-value pairs (not only the 
changed one). If CSI is not assigned, then no callback will be issued.
Note: AMF spec does not talk about reinvocation of CSI set callback in the 
context of csi-attribute modification. But reinvocation of calback with same HA 
state information is discussed in case like failure handing in N-Way model  AMF 
B.04.01 "3.6.4.5 Failure Handling " page 167.
2)All characteristics associated with a CSI SET callback will be applicable 
with respect to invocation of callback like waiting response from component via 
saAmfResponse() API and generation of error report if component does not 
respond within the configured callbacktimeout.
3)Feature will be configurable either through

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2016-01-25 Thread Praveen

- Description has changed:

Diff:



--- old
+++ new
@@ -8,3 +8,4 @@
 
 
 
+Will update implementation scope soon...



- **status**: assigned --> accepted



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** accepted
**Milestone:** 5.0.FC
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Wed Jan 13, 2016 06:30 AM UTC
**Owner:** Praveen


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.



Will update implementation scope soon...


---

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.--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2015-10-23 Thread Anders Widell

Note: this change is not backwards compatible, so we will need to bump the 
minor version of the AMF API (in a similar way as we do in IMM) if we introduce 
this feature.


---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** assigned
**Milestone:** 5.0
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Wed Oct 21, 2015 11:12 AM UTC
**Owner:** Mathi Naickan


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.






---

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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

2015-10-21 Thread Mathi Naickan

- **labels**:  --> VM migration, loadbalancer-synchronization
- **summary**: AMF: Send CsiSetCallback immediately when CSI attributes are 
modified --> AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)
- **Comment**:

Praveen is pointing out that this ticket could be useful in scenarios involving 
VM migration too!
For eg:- As a part of the migration solution, before trigerring the migration, 
the CSI attributes can be modified first to let the application(VM) know about 
the coordinates(in the form of CSI attributes) of the destination VM. 
This information could then be utilized to trigger the start of migration as a 
part of a AMF shutdown operation for example!



---

** [tickets:#1553] AMF: Send CsiSetCallback immediately when CSI attributes are 
modified (loadbalancing, VM migration usecases)**

**Status:** assigned
**Milestone:** 5.0
**Labels:** VM migration loadbalancer-synchronization 
**Created:** Wed Oct 21, 2015 10:03 AM UTC by Mathi Naickan
**Last Updated:** Wed Oct 21, 2015 10:03 AM UTC
**Owner:** Mathi Naickan


AMF is the 'workload' manager in OpenSAF. There are also loadbalancers external 
to OpenSAF that can choose to modify some attributes of an application 
component's workload which is currently assigned ACTIVE (without loss of 
service). In such scenarios it is possible (and necessary) for both AMF and the 
external load balancers to throttle each other. The reverse throttling(from AMF 
to the external load balancer) is possible based on any changes to the 
NodeCapacity limitations set in AMF, but that is for later/future 
considerations.

For eg:- Suppose an application component (say modelled in n-way active) is 
currently serving traffic originating from a source/target X, based on some 
network criteria the load balancer can choose to re-configure/modify that 
application to serve traffic from a different source/target Y. Such change in 
information related to that workload could be communicated to that application 
component at runtime without loss of service.

The above scenario is achieved if the admin (or a loadbalancer) modifies the 
attributes of a workload i.e. csiattribute name-value pair, and then the 
altered name-value information is communicated to that application or 
associated application components 'immediately' instead of waiting for the next 
admin operation!

Today AMF supports modifying csi attribute name-value without requiring that SI 
to be locked. But the modified attributes are sent only after a subsequent 
admin operation. This ticket is intended to evaluate and support sending 
CSIsetcallback (with the same CSI state information but modified csi 
attributes) immediately.






---

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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

[tickets] [opensaf:tickets] #1553 AMF: Send CsiSetCallback immediately when CSI attributes are modified (loadbalancing, VM migration usecases)

12 matches

Site Navigation

Mail list logo

Footer information