[tickets] [opensaf:tickets] #1406 pyosaf: Higher leve/pythonic bindings for the IMM OI API are missing

2015-07-10 Thread Johan Mårtensson
Here is an example of how a (working) prototype program could look like that's 
using higher level bindings. 


#!/usr/bin/env python

import argparse
import sys

from pyosaf.saImm import eSaImmClassCategoryT

from pyosaf.utils.immoi import get_available_classes_in_imm, get_class_category
from pyosaf.utils.immoi.implementer import Applier


def is_config_class(class_name):

category = get_class_category(class_name)

return category.value == eSaImmClassCategoryT.SA_IMM_CLASS_CONFIG


def parse_class_names():

return args.classes

def print_mo(mo):
print "%s (%s)" % (mo.dn, mo.SaImmAttrClassName)

# Print attributes
for name in mo.attrs.keys():
print "%s: %s" % (name, mo.attrs[name][1])

print

def handle_apply(all_instances, to_update, to_create, to_delete):

print
print '-' * 10 + " Configuration changed " + '-' * 10

# Handle creates
print "  Created objects"
for mo in to_create:
print_mo(mo)

# Handle deletes
print "  Deleted objects"
for mo in to_delete:
print_mo(mo)

# Handle updates
print "  Updated objects"
for mo in to_update:
print_mo(mo)

if __name__ == "__main__":

# Parse command line arguments
parser = argparse.ArgumentParser(
description='Listens to changes to objects of the given classes')
parser.add_argument('classes', type=str, nargs='*', 
help='space-separated list of class names')
parser.add_argument('--all', help='listens to changes to all classes',
dest='all', action='store_const', const=all, 
default=False)

args = parser.parse_args()

classes = args.classes

listen_to_all = args.all

# Exit if no classes are passed
if not listen_to_all and (not classes or classes == []):
print "ERROR: Must specify classes to listen to or '--all'"
sys.exit(1)

# Sort out which classes to listen to
all_available_classes = get_available_classes_in_imm()
classes_to_listen_to = []

if listen_to_all:
print "INFO: Listening to changes to all configuration classes"

classes_to_listen_to = [c for c in all_available_classes if 
is_config_class(c)]

else:

# Validate classes
for class_name in classes:

if not class_name in all_available_classes:
print "WARNING: Ignoring %s. It does not exist in IMM" % 
class_name

continue

elif not is_config_class(class_name):
print "WARNING: Ignoring runtime class %s" % class_name

continue

classes_to_listen_to.append(class_name)

print "INFO: Listening for changes in %s" % ", ".join(classes_to_listen_to)

echo_applier = Applier(on_apply=handle_apply, 
   class_names=classes_to_listen_to)

echo_applier.enter_dispatch_loop()




---

** [tickets:#1406] pyosaf: Higher leve/pythonic bindings for the IMM OI API are 
missing**

**Status:** assigned
**Milestone:** future
**Created:** Tue Jul 07, 2015 01:15 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 08:36 AM UTC
**Owner:** Johan Mårtensson

For the IMM OM API there are higher level python bindings that make it much 
easier to use compared with the 1-to-1 python bindings. There is for example an 
InstanceIterator   class that iterates through instances for a given class, Ccb 
class for transactions and immom.get() to retrieve a single object.

The IMM OI API only has the 1-to-1 mappings. This makes it hard to write an OI 
as all the wrapping of python types to C and back has to be done by each user. 
OpenSAF should have an abstracted OI python mapping that hides the C 
(un)marshalling and caching and re-construction of CCB operations.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1401 smf: upgrade time improvement

2015-07-10 Thread Rafael
>From bertils powerpoint

Proposed solution
-

Use existing rolling procedures but add new IMM configuration object that tells 
SMF how to execute the upgrade (one node at the time, all at once, several 
nodes at the same time). The information describing how to upgrade is given in 
IMM objects. This means we use the existing campaign schema.

Add possibility to configure a reboot upgrade (all nodes at the same time) as 
first priority. Then add rolling upgrade (one node at the time) as second 
priority.
As third priority add the possibility to configure upgrade of several nodes at 
the same time. This step requires more work to define exactly how you describe 
how many and what nodes should be upgraded at the same time.

This solution implies that applications can reuse their existing campaign files 
and does not need to adapt to this new feature (however testing is needed).

Issues to be considered during implementation
-

1) How to handle callbacks?

Callbacks is a mechanism in SMF where a campaign can specify that a certain 
callback should be sent out at a certain time during the upgrade. Any SW can 
subscribe to these callbacks and do something when they arrive. The callbacks 
is sometimes related to the steps in a procedure (first, every, halfway or last 
step). 
 
2) How will the alternatives work with parallel node lock support in AMF. (e.g. 
lock/unlock on Node group)

If the procedures specifies nodes as activation unit SMF will lock the nodes 
one by one i.e. not in parallel (AMF can today only do one lock at the time). 
So SMF has to create temporary node group and do lock etc on that object. The 
new procedure type can specify node groups directly but someone still need to 
create them.

3) How to handle single step procedures?

If a campaign also includes single step procedures, what to do? Could be 
installation procedure for new CBA component.


---

** [tickets:#1401] smf: upgrade time improvement**

**Status:** assigned
**Milestone:** future
**Created:** Mon Jul 06, 2015 08:58 AM UTC by Rafael
**Last Updated:** Thu Jul 09, 2015 09:00 AM UTC
**Owner:** Rafael

Decrease the execution time for campaigns by merging parallel procedures.

Parallel procedures are procedures that have saSmfExecLevel set to the same 
value. When procedures are merged they will be executed in one thread. Today 
procedures are executed in separate threads with possible cluster/node reboots 
in each procedure. When procedures are merged they would install multiple 
software packages on a node with one reboot at the end.

There are three use cases

* Upgrade one node at the time in the cluster
* Upgrade all nodes at once using cluster reboot
* Upgrade several nodes at once

There will be an IMM attribute that decides if procedures are to be merged to 
maintain backward compatibility.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1412 IMM: Internal abort of active but idle CCB can cause invalid OM-handle

2015-07-10 Thread Anders Bjornerstedt
- Description has changed:

Diff:



--- old
+++ new
@@ -25,7 +25,7 @@
 The result will be a imma library internal timeout but a (correct) return code
 of SA_AIS_ERR_FAILED_OPERATION. That is the CCB has been aborted. 
 So far so good, almost. The long wait for the reply (internal timeout corrected
-by ccb-apply lig in the imma library) already indicates something was abnormal.
+by ccb-apply in the imma library) already indicates something was abnormal.
 
 Now try continuing in the immcfg explicit commit mode to create new operations
 in a new (chained) CCB. This will fail. Not even "immcfg --ccb-abort" works.



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



---

** [tickets:#1412] IMM: Internal abort of active but idle CCB can cause invalid 
OM-handle**

**Status:** review
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 01:46 PM UTC by Anders Bjornerstedt
**Last Updated:** Fri Jul 10, 2015 01:46 PM UTC
**Owner:** Anders Bjornerstedt

This is easiest to reproduce using immcfg in explicit commit mode and on
4.7-tentative where enhancements #1107 and #1261 have been added.

Using immcfg allows the client to create an active open CCB that is idle.
That is a ccb with one or more operations added to it, but that is not yet
commited or aborted. 

The enhancements mentioned adds (1) an admin-operation for aborting non-critical
CCBs and (2) a restarted PBE uses that admin-operation to clear the way for a
clean attach. 

The setup consists of creating a CCB using immcfg in explicit commit mode.
An operation updating an attribute of some object is created.
The CCB is now open, active but idle. That is the CCB contains an operation
that is not yet applied and the CCB is idle waiting for the next om-client
request affecting the CCB.

Now we either use the admin-operation for aborting non-critical CCBs or we kill
the PBE so that the PBE restarts. Either way, the open and idle CCB gets 
aborted.
This is however not immediately visible to the om-client (immcfg) since there
was currently no om-request being processed.

Finally, we invoke "immcfg --ccb-apply" in the immcfg explicit commit mode 
"shell".

The result will be a imma library internal timeout but a (correct) return code
of SA_AIS_ERR_FAILED_OPERATION. That is the CCB has been aborted. 
So far so good, almost. The long wait for the reply (internal timeout corrected
by ccb-apply in the imma library) already indicates something was abnormal.

Now try continuing in the immcfg explicit commit mode to create new operations
in a new (chained) CCB. This will fail. Not even "immcfg --ccb-abort" works.
The reason is that not just the ccb-handle, but the admin-owner-handle and
om-handle have been invalidated. 

The OM-handle gets marked as invalid because the ccb-apply arriving on an
already aborted CCB is interpreted as multi-threaded use of one handle,
which is not allowed. This is however not true in this case. 

The logic in ImmModel:ccbApply() needs to be corrected for the case of an
om-apply request arriving on an aborted CCB.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1412 IMM: Internal abort of active but idle CCB can cause invalid OM-handle

2015-07-10 Thread Anders Bjornerstedt



---

** [tickets:#1412] IMM: Internal abort of active but idle CCB can cause invalid 
OM-handle**

**Status:** accepted
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 01:46 PM UTC by Anders Bjornerstedt
**Last Updated:** Fri Jul 10, 2015 01:46 PM UTC
**Owner:** Anders Bjornerstedt

This is easiest to reproduce using immcfg in explicit commit mode and on
4.7-tentative where enhancements #1107 and #1261 have been added.

Using immcfg allows the client to create an active open CCB that is idle.
That is a ccb with one or more operations added to it, but that is not yet
commited or aborted. 

The enhancements mentioned adds (1) an admin-operation for aborting non-critical
CCBs and (2) a restarted PBE uses that admin-operation to clear the way for a
clean attach. 

The setup consists of creating a CCB using immcfg in explicit commit mode.
An operation updating an attribute of some object is created.
The CCB is now open, active but idle. That is the CCB contains an operation
that is not yet applied and the CCB is idle waiting for the next om-client
request affecting the CCB.

Now we either use the admin-operation for aborting non-critical CCBs or we kill
the PBE so that the PBE restarts. Either way, the open and idle CCB gets 
aborted.
This is however not immediately visible to the om-client (immcfg) since there
was currently no om-request being processed.

Finally, we invoke "immcfg --ccb-apply" in the immcfg explicit commit mode 
"shell".

The result will be a imma library internal timeout but a (correct) return code
of SA_AIS_ERR_FAILED_OPERATION. That is the CCB has been aborted. 
So far so good, almost. The long wait for the reply (internal timeout corrected
by ccb-apply lig in the imma library) already indicates something was abnormal.

Now try continuing in the immcfg explicit commit mode to create new operations
in a new (chained) CCB. This will fail. Not even "immcfg --ccb-abort" works.
The reason is that not just the ccb-handle, but the admin-owner-handle and
om-handle have been invalidated. 

The OM-handle gets marked as invalid because the ccb-apply arriving on an
already aborted CCB is interpreted as multi-threaded use of one handle,
which is not allowed. This is however not true in this case. 

The logic in ImmModel:ccbApply() needs to be corrected for the case of an
om-apply request arriving on an aborted CCB.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1409 pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py is broken

2015-07-10 Thread Johan Mårtensson
- **Milestone**: 4.6.1 --> 4.5.2



---

** [tickets:#1409] pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py 
is broken**

**Status:** review
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 09:43 AM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 10:09 AM UTC
**Owner:** Johan Mårtensson

The marshalling code is broken in saImmOiRtObjectCreate_2. Copy-paste the code 
below (without any added line breaks) into a Python shell to reproduce:

from pyosaf.utils.immom.ccb import marshal_c_array
from pyosaf.saImm import SaImmAttrNameT, SaImmAttrValuesT_2, SaImmClassNameT, 
eSaImmValueTypeT
from pyosaf.saAis import SaNameT
from pyosaf.saImmOi import saImmOiRtObjectCreate_2
from pyosaf.utils import immoi

c_parent_name = None
c_class_name = SaImmClassNameT("AnyClass")
c_class_name = SaImmClassNameT("AnyRuntimeClass")
c_attr_values = []
values = ["a"]
c_attr_type = eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
c_attr = SaImmAttrValuesT_2()
c_attr.attrName = SaImmAttrNameT("anyAttribute")
c_attr.attrValueType = c_attr_type
c_attr.attrValuesNumber = 1
c_attr.attrValues = marshal_c_array(c_attr_type, values)
c_attr_values.append(c_attr)

err = saImmOiRtObjectCreate_2(immoi.HANDLE, c_class_name, c_parent_name, 
c_attr_values)



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1411 pyosaf: Marshalling in saImmOiRtObjectUpdate_2 in saImmOi.py is broken

2015-07-10 Thread Johan Mårtensson
- **status**: assigned --> review
- **Version**: 4.5.2 --> 4.2.x
- **Milestone**: 4.6.1 --> 4.5.2



---

** [tickets:#1411] pyosaf: Marshalling in saImmOiRtObjectUpdate_2 in saImmOi.py 
is broken**

**Status:** review
**Milestone:** 4.5.2
**Created:** Fri Jul 10, 2015 12:54 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 12:54 PM UTC
**Owner:** Johan Mårtensson

The marshalling of the attribute modifications list in saImmOiRtObjectUpdate_2 
in saImmOi.py is broken. The error looks like this:


err = saImmOiRtObjectUpdate_2(HANDLE, SaNameT(name), attr_mods)
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saImmOi.py", line 350, in 
saImmOiRtObjectUpdate_2
BYREF(attrMods))
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saAis.py", line 196, in 
BYREF
return None if data == None else byref(data)
TypeError: byref() argument must be a ctypes instance, not 'list'



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1411 pyosaf: Marshalling in saImmOiRtObjectUpdate_2 in saImmOi.py is broken

2015-07-10 Thread Johan Mårtensson



---

** [tickets:#1411] pyosaf: Marshalling in saImmOiRtObjectUpdate_2 in saImmOi.py 
is broken**

**Status:** assigned
**Milestone:** 4.6.1
**Created:** Fri Jul 10, 2015 12:54 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 12:54 PM UTC
**Owner:** Johan Mårtensson

The marshalling of the attribute modifications list in saImmOiRtObjectUpdate_2 
in saImmOi.py is broken. The error looks like this:


err = saImmOiRtObjectUpdate_2(HANDLE, SaNameT(name), attr_mods)
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saImmOi.py", line 350, in 
saImmOiRtObjectUpdate_2
BYREF(attrMods))
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saAis.py", line 196, in 
BYREF
return None if data == None else byref(data)
TypeError: byref() argument must be a ctypes instance, not 'list'



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1410 pyosaf: Invalid exception used in ImmObject (object.py)

2015-07-10 Thread Johan Mårtensson



---

** [tickets:#1410] pyosaf: Invalid exception used in ImmObject (object.py)**

**Status:** unassigned
**Milestone:** 4.6.1
**Created:** Fri Jul 10, 2015 10:11 AM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 10:11 AM UTC
**Owner:** nobody

ImmObject uses an invalid way to raise exceptions:


>>> a = ImmObject('NonExistingClass')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/utils/immom/object.py", 
line 63, in __init__
raise
TypeError: exceptions must be old-style classes or derived from BaseException, 
not NoneType



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1409 pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py is broken

2015-07-10 Thread Anders Bjornerstedt
- **status**: assigned --> review



---

** [tickets:#1409] pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py 
is broken**

**Status:** review
**Milestone:** 4.6.1
**Created:** Fri Jul 10, 2015 09:43 AM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 09:43 AM UTC
**Owner:** Johan Mårtensson

The marshalling code is broken in saImmOiRtObjectCreate_2. Copy-paste the code 
below (without any added line breaks) into a Python shell to reproduce:

from pyosaf.utils.immom.ccb import marshal_c_array
from pyosaf.saImm import SaImmAttrNameT, SaImmAttrValuesT_2, SaImmClassNameT, 
eSaImmValueTypeT
from pyosaf.saAis import SaNameT
from pyosaf.saImmOi import saImmOiRtObjectCreate_2
from pyosaf.utils import immoi

c_parent_name = None
c_class_name = SaImmClassNameT("AnyClass")
c_class_name = SaImmClassNameT("AnyRuntimeClass")
c_attr_values = []
values = ["a"]
c_attr_type = eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
c_attr = SaImmAttrValuesT_2()
c_attr.attrName = SaImmAttrNameT("anyAttribute")
c_attr.attrValueType = c_attr_type
c_attr.attrValuesNumber = 1
c_attr.attrValues = marshal_c_array(c_attr_type, values)
c_attr_values.append(c_attr)

err = saImmOiRtObjectCreate_2(immoi.HANDLE, c_class_name, c_parent_name, 
c_attr_values)



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1409 pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py is broken

2015-07-10 Thread Johan Mårtensson



---

** [tickets:#1409] pyosaf: Marshalling in saImmOiRtObjectCreate_2 in saImmOi.py 
is broken**

**Status:** assigned
**Milestone:** 4.6.1
**Created:** Fri Jul 10, 2015 09:43 AM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 09:43 AM UTC
**Owner:** Johan Mårtensson

The marshalling code is broken in saImmOiRtObjectCreate_2. Copy-paste the code 
below (without any added line breaks) into a Python shell to reproduce:

from pyosaf.utils.immom.ccb import marshal_c_array
from pyosaf.saImm import SaImmAttrNameT, SaImmAttrValuesT_2, SaImmClassNameT, 
eSaImmValueTypeT
from pyosaf.saAis import SaNameT
from pyosaf.saImmOi import saImmOiRtObjectCreate_2
from pyosaf.utils import immoi

c_parent_name = None
c_class_name = SaImmClassNameT("AnyClass")
c_class_name = SaImmClassNameT("AnyRuntimeClass")
c_attr_values = []
values = ["a"]
c_attr_type = eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
c_attr = SaImmAttrValuesT_2()
c_attr.attrName = SaImmAttrNameT("anyAttribute")
c_attr.attrValueType = c_attr_type
c_attr.attrValuesNumber = 1
c_attr.attrValues = marshal_c_array(c_attr_type, values)
c_attr_values.append(c_attr)

err = saImmOiRtObjectCreate_2(immoi.HANDLE, c_class_name, c_parent_name, 
c_attr_values)



---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1406 pyosaf: Higher leve/pythonic bindings for the IMM OI API are missing

2015-07-10 Thread Johan Mårtensson
 - There should also be a convenience method to create RT objects, similar to 
create in ccb.py.


---

** [tickets:#1406] pyosaf: Higher leve/pythonic bindings for the IMM OI API are 
missing**

**Status:** assigned
**Milestone:** future
**Created:** Tue Jul 07, 2015 01:15 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 08:00 AM UTC
**Owner:** Johan Mårtensson

For the IMM OM API there are higher level python bindings that make it much 
easier to use compared with the 1-to-1 python bindings. There is for example an 
InstanceIterator   class that iterates through instances for a given class, Ccb 
class for transactions and immom.get() to retrieve a single object.

The IMM OI API only has the 1-to-1 mappings. This makes it hard to write an OI 
as all the wrapping of python types to C and back has to be done by each user. 
OpenSAF should have an abstracted OI python mapping that hides the C 
(un)marshalling and caching and re-construction of CCB operations.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1408 pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when called with a list of attributes to retrieve

2015-07-10 Thread Johan Mårtensson
- **Milestone**: 4.6.1 --> 4.5.2



---

** [tickets:#1408] pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when 
called with a list of attributes to retrieve**

**Status:** review
**Milestone:** 4.5.2
**Created:** Thu Jul 09, 2015 02:12 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 07:51 AM UTC
**Owner:** Johan Mårtensson

The saImmOmSearchInitialize_2 method in saImmOm.py only works as long as it's 
called without specifying the list of attributes to retrieve. The marshalling 
of the list is broken. The steps to reproduce this are:


$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> # Verify that 
KeyboardInterrupt
>>> 
>>> # Handle imports
... 
>>> from pyosaf.saImm import SaImmSearchParametersT_2, eSaImmValueTypeT, 
>>> eSaImmScopeT
>>> from ctypes import cast, pointer, c_void_p, c_char_p
>>> from pyosaf import saImm, saImmOm
>>> from pyosaf.utils import immom
>>>
>>>
>>> # Set parameters
...
>>> name = c_char_p("SampleClass")
>>> search_param = SaImmSearchParametersT_2()
>>> search_param.searchOneAttr.attrName = "SaImmAttrClassName"
>>> search_param.searchOneAttr.attrValueType = 
>>> eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
>>> search_param.searchOneAttr.attrValue = cast(pointer(name), c_void_p)
>>> scope = eSaImmScopeT.SA_IMM_SUBTREE
>>> search_options = saImm.saImm.SA_IMM_SEARCH_ONE_ATTR
>>> attribute_names = None
>>> search_handle = saImmOm.SaImmSearchHandleT()
>>> attribute_names = ["attribute1"]
>>> 
>>>
>>> # Provoke the fault
...
>>> saImmOm.saImmOmSearchInitialize_2(immom.HANDLE, None, scope, 
>>> search_options, search_param, attribute_names, search_handle)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saImmOm.py", line 281, in 
saImmOmSearchInitialize_2
BYREF(attributeNames),
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saAis.py", line 196, in 
BYREF
return None if data == None else byref(data)
TypeError: byref() argument must be a ctypes instance, not 'list'
>>> 




---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1406 pyosaf: Higher leve/pythonic bindings for the IMM OI API are missing

2015-07-10 Thread Johan Mårtensson
There are a set of requirements a high-level API for OI should fulfill:
 - Caching of CCBs and re-construction of the complete transaction should be 
done by the framework, not the user code
 - Marshalling from Python code to C should be hidden and done by the framework
 - It must be possible to build a "full" OI, that gets callbacks on each 
operation, the completed transaction, and a call to apply the transaction
 - It must be possible to build an applier that can run in parallel with a full 
OI
 - There should only need to be "user code" for the functionality the user 
wants to have. E.g., if the user doesn't want to get callbacks for each 
individual CCB operation, it shouldn't need to write placeholder functions that 
do nothing
 - It should be possible flexible so the user can choose to either:
 - Let the framework code handle the full dispatch loop and select handling
 - Let the user integrate the OI with its own dispatch loop and select 
handling


---

** [tickets:#1406] pyosaf: Higher leve/pythonic bindings for the IMM OI API are 
missing**

**Status:** assigned
**Milestone:** future
**Created:** Tue Jul 07, 2015 01:15 PM UTC by Johan Mårtensson
**Last Updated:** Thu Jul 09, 2015 12:15 PM UTC
**Owner:** Johan Mårtensson

For the IMM OM API there are higher level python bindings that make it much 
easier to use compared with the 1-to-1 python bindings. There is for example an 
InstanceIterator   class that iterates through instances for a given class, Ccb 
class for transactions and immom.get() to retrieve a single object.

The IMM OI API only has the 1-to-1 mappings. This makes it hard to write an OI 
as all the wrapping of python types to C and back has to be done by each user. 
OpenSAF should have an abstracted OI python mapping that hides the C 
(un)marshalling and caching and re-construction of CCB operations.


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1408 pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when called with a list of attributes to retrieve

2015-07-10 Thread Johan Mårtensson
- **Version**: 4.6.x --> 4.2.x
- **Milestone**: future --> 4.6.1



---

** [tickets:#1408] pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when 
called with a list of attributes to retrieve**

**Status:** review
**Milestone:** 4.6.1
**Created:** Thu Jul 09, 2015 02:12 PM UTC by Johan Mårtensson
**Last Updated:** Fri Jul 10, 2015 07:48 AM UTC
**Owner:** Johan Mårtensson

The saImmOmSearchInitialize_2 method in saImmOm.py only works as long as it's 
called without specifying the list of attributes to retrieve. The marshalling 
of the list is broken. The steps to reproduce this are:


$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> # Verify that 
KeyboardInterrupt
>>> 
>>> # Handle imports
... 
>>> from pyosaf.saImm import SaImmSearchParametersT_2, eSaImmValueTypeT, 
>>> eSaImmScopeT
>>> from ctypes import cast, pointer, c_void_p, c_char_p
>>> from pyosaf import saImm, saImmOm
>>> from pyosaf.utils import immom
>>>
>>>
>>> # Set parameters
...
>>> name = c_char_p("SampleClass")
>>> search_param = SaImmSearchParametersT_2()
>>> search_param.searchOneAttr.attrName = "SaImmAttrClassName"
>>> search_param.searchOneAttr.attrValueType = 
>>> eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
>>> search_param.searchOneAttr.attrValue = cast(pointer(name), c_void_p)
>>> scope = eSaImmScopeT.SA_IMM_SUBTREE
>>> search_options = saImm.saImm.SA_IMM_SEARCH_ONE_ATTR
>>> attribute_names = None
>>> search_handle = saImmOm.SaImmSearchHandleT()
>>> attribute_names = ["attribute1"]
>>> 
>>>
>>> # Provoke the fault
...
>>> saImmOm.saImmOmSearchInitialize_2(immom.HANDLE, None, scope, 
>>> search_options, search_param, attribute_names, search_handle)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saImmOm.py", line 281, in 
saImmOmSearchInitialize_2
BYREF(attributeNames),
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saAis.py", line 196, in 
BYREF
return None if data == None else byref(data)
TypeError: byref() argument must be a ctypes instance, not 'list'
>>> 




---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1407 pyosaf: modify_value_[add|replace|delete] in pyosaf.utils.ccb.Ccb are broken

2015-07-10 Thread Johan Mårtensson
- **status**: assigned --> review



---

** [tickets:#1407] pyosaf: modify_value_[add|replace|delete] in 
pyosaf.utils.ccb.Ccb are broken**

**Status:** review
**Milestone:** 4.6.1
**Created:** Thu Jul 09, 2015 01:13 PM UTC by Johan Mårtensson
**Last Updated:** Thu Jul 09, 2015 01:18 PM UTC
**Owner:** Johan Mårtensson

The method modify_value_add, modify_value_replace and modify_value_delete in 
pyosaf.utils.immom.ccb.Ccb are broken. This can be verified with the following 
steps below.


1. Create a test class
~~
$ cat > testclass.xml

http://www.w3.org/2001/XMLSchema-instance"; 
xsi:noNamespaceSchemaLocation="SAI-AIS-IMM-XSD-A.02.13.xsd" 
xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
xmlns:imm="http://www.saforum.org/IMMSchema";>
  
SA_CONFIG

  sampleClassId
  SA_STRING_T
  SA_CONFIG
  SA_INITIALIZED
  SA_NOTIFY


  attribute1
  SA_STRING_T
  SA_CONFIG
  SA_WRITABLE
  SA_NOTIFY
  SA_MULTI_VALUE

  

~~

$ immcfg -f testclass.xml 


2. Create an instance

$ immcfg -c SampleClass sampleClassId=1


3. Use the methods in a Python prompt

~~
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyosaf.utils.immom.ccb import Ccb
>>> ccb = Ccb()
>>>
>>>
>>>
>>> # Verify that adding a value with the Ccb class doesn't work
...
>>> ccb.modify_value_add("sampleClassId=1", "attribute1", ["a", "b"])
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/utils/immom/ccb.py", 
line 213, in modify_value_add
saImmOm.eSaImmAttrModificationTypeT.SA_IMM_ATTR_VALUES_ADD
AttributeError: 'module' object has no attribute 
'eSaImmAttrModificationTypeT'
>>> 
>>>
>>> 
>>> # Verify that replacing values with the Ccb class doesn't work 
...
>>> ccb.modify_value_replace("sampleClassId=1", "attribute1", ["a", "b"])
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/utils/immom/ccb.py", 
line 271, in modify_value_replace
saImmOm.eSaImmAttrModificationTypeT.SA_IMM_ATTR_VALUES_REPLACE
AttributeError: 'module' object has no attribute 
'eSaImmAttrModificationTypeT'
>>>
>>>
>>> 
>>> # Verify that deleting values with the Ccb class doesn't work
... 
>>> ccb.modify_value_delete("sampleClassId=1", "attribute1", ["a"])
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/utils/immom/ccb.py", 
line 329, in modify_value_delete
saImmOm.eSaImmAttrModificationTypeT.SA_IMM_ATTR_VALUES_DELETE
AttributeError: 'module' object has no attribute 
'eSaImmAttrModificationTypeT'
>>> 
~~


---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #1408 pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when called with a list of attributes to retrieve

2015-07-10 Thread Johan Mårtensson
- **status**: assigned --> review



---

** [tickets:#1408] pyosaf: saImmOmSearchIinitialize_2 in saImmOm.py breaks when 
called with a list of attributes to retrieve**

**Status:** review
**Milestone:** future
**Created:** Thu Jul 09, 2015 02:12 PM UTC by Johan Mårtensson
**Last Updated:** Thu Jul 09, 2015 02:45 PM UTC
**Owner:** Johan Mårtensson

The saImmOmSearchInitialize_2 method in saImmOm.py only works as long as it's 
called without specifying the list of attributes to retrieve. The marshalling 
of the list is broken. The steps to reproduce this are:


$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> # Verify that 
KeyboardInterrupt
>>> 
>>> # Handle imports
... 
>>> from pyosaf.saImm import SaImmSearchParametersT_2, eSaImmValueTypeT, 
>>> eSaImmScopeT
>>> from ctypes import cast, pointer, c_void_p, c_char_p
>>> from pyosaf import saImm, saImmOm
>>> from pyosaf.utils import immom
>>>
>>>
>>> # Set parameters
...
>>> name = c_char_p("SampleClass")
>>> search_param = SaImmSearchParametersT_2()
>>> search_param.searchOneAttr.attrName = "SaImmAttrClassName"
>>> search_param.searchOneAttr.attrValueType = 
>>> eSaImmValueTypeT.SA_IMM_ATTR_SASTRINGT
>>> search_param.searchOneAttr.attrValue = cast(pointer(name), c_void_p)
>>> scope = eSaImmScopeT.SA_IMM_SUBTREE
>>> search_options = saImm.saImm.SA_IMM_SEARCH_ONE_ATTR
>>> attribute_names = None
>>> search_handle = saImmOm.SaImmSearchHandleT()
>>> attribute_names = ["attribute1"]
>>> 
>>>
>>> # Provoke the fault
...
>>> saImmOm.saImmOmSearchInitialize_2(immom.HANDLE, None, scope, 
>>> search_options, search_param, attribute_names, search_handle)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saImmOm.py", line 281, in 
saImmOmSearchInitialize_2
BYREF(attributeNames),
  File "/usr/local/lib/python2.7/dist-packages/pyosaf/saAis.py", line 196, in 
BYREF
return None if data == None else byref(data)
TypeError: byref() argument must be a ctypes instance, not 'list'
>>> 




---

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.--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets