Karl Schopmeyer | 28 Mar 16:46 2015
Picon

The CVS Head of tree Open For Commits

The CVS head of tree (OpenPegasus 2.15) is now open for new commits.  It 
has been updated to include the new version and marked as
development.

The same procedure as previous releases will be followed for new commits:

1. Documented in bugs
2. Bugs voted and marked approved if votes are positive
3. Only bugs with + votes to be committed.

The planning for this next version can be followed, commented on, etc. at

https://wiki.opengroup.org/pegasus-wiki/doku.php?id=dev:release:2.15_x#openpegasus_2150_release_status

Karl Schopmeyer
Project Lead

Karl Schopmeyer | 28 Mar 16:40 2015
Picon

OpenPegasus Version 2.14.0 Released

OpenPegasus 2.14.0 has been formally released and is available for use.

This release includes a number of extensions, the primary of which is 
the inclusion of the
CIM/XML pull operations defined by the DMTF for the CIM/XML protocol.  
The full list of changes for this release are documented in the 
ReleaseNotes and the OpenPegasus bugzilla

For more details on the release, please use the Release Notes that are:

1. In the root directory of the source code
2. In the Release Table at 
https://collaboration.opengroup.org/pegasus/pp/documents/32512/ReleaseNotes.htm
3. On the OpenPegasus Wiki at 
https://wiki.opengroup.org/pegasus-wiki/lib/exe/fetch.php?media=dev:release:releasenotes2_14_0.pdf
4. Documented as OpenPegasus PEP 368.

The source code is available at on the OpenPegasus web page at:

1. 
https://collaboration.opengroup.org/pegasus/protected/pages.php?action=show&ggid=392
2 Through the OpenPegasus WIKI on the ReleaseStatus Page 
https://wiki.opengroup.org/pegasus-wiki/doku.php?id=dev:openpegasusreleasestatus
3. Through the OpenPegasus CVS using the CVS tag RELEASE_2_14_0

The source RPM will also be made available shortly and will be announced 
separately

Karl Schopmeyer
Project Lead
(Continue reading)

Karl Schopmeyer | 24 Mar 17:06 2015
Picon

OpenPegasus 2.14 branch created.

Effective immediatly, in preperation for the release of OpenPegasus 
2.14.0, the RELEASE_2_14 pegasus branch has been created.

This means that any future patches for OpenPegasus 2.14 must be put into 
this branch and, further, no patches will be inserted into
the branch without a prior patch for 2.15 (the CVS head of tree).

Karl

Karl Schopmeyer | 14 Mar 15:04 2015
Picon

Pegasus 2.14 Source Freeze (Release Canidate 1) tag RELEASE_2_14_0-RC1 has been set

The RC1 tag (RELEASE_2_14_0-RC1) has been set in the head of tree for 
OpenPegasus indicating that the source code is frozen.

 From this point to the release:

1. Only critical bugs will be committed and those must have at least 2 
votes (not that documentation bugs are excepted)

The remaining steps are:

1. Complete cho test
2. Complete release notes review
3. Create the 2.14 branch
4. Set release tag

Karl Schopmeyer
Project Lean

abhishek gupta | 12 Mar 11:16 2015
Picon

Error "invalid hostname" for Invoke method call when we use IPv6 address.

Hello All,

We are using 2.12.0 version of Tog-Pegasus in Rhel6.

tog-pegasus-2.12.0-2.el6.x86_64

tog-pegasus-libs-2.12.0-2.el6.x86_64

 

When we query from Java client, enumerations works well with the IPv6 address.  But for invoke method call we receive "invalid hostname" from the tog-pegasus. This invoke method works well with the IPv4 address.

We did specify zone id for link local address.


failed with CIM_ERR_INVALID_PARAMETER: malformed object name: [fe80:0:0:0:224:e8ff:fe4d:d169%11], reason:"invalid hostname"

 

Please let us know if we missed anything?

Regards,

Prashanth

Harshitkumar Jain | 23 Jan 09:34 2015

CIMPLE tool Key properties comparison issue

Hi Team,

 

We are using CIMPLE tool version 2.0.24 on CentOS7 linux platform. We are facing below issue related to key properties uniqueness amongst instances of a class.

 

The implementation of the "insert" function in case of and "Instance_MAP" is giving us issues.

 

inline size_t Instance_Map<CLASS>::insert(CLASS* instance)

 

It returns -1 "Duplicate instance" whenever we create and insert 2 or more instances into the map with different key properties.

 

The string check seems to be verifying only the first few characters of the key string.

 

For instance, the insert function returns (-1), if value used for a key property is "Setting:1 and "Setting:2". However the same implementation works if we use keys like "1:Setting" "2:Setting"

 

Has anybody faced this issue earlier or is this a known issue?

 

 

thanks in advance,

Harshit

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

Harshitkumar Jain | 24 Nov 14:42 2014

CIMPLE website down

Hi team,

 

An advance apology if this mail gets listed at  wrong forum.

 

The CIMPLE website http://www.simplewbem.org/ is down for some time now.

Is there any change in the project, i.e is it being depreciated or is it just a networking issue?

 

Thanks,

Harshit

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

Arunkumar S | 19 Nov 10:05 2014
Picon

Re: Event delivery issue after Provider Crash

Thanks a lot.

The issue got fixed with OP 2.13.0 

Thanks,
Arun

On Tue, Nov 18, 2014 at 9:08 AM, Arunkumar S <arunkumar.krishnan <at> gmail.com> wrote:
Hi Dev,

My intention is not to debug the crash, since it is induced crash.

I am using Pegasus 2.11.1.   I will try 2.13.0 and check if the issue is still reproducible. 

Thanks,
Arun




On Tue, Nov 18, 2014 at 12:31 AM, Devchandra L Meetei <dlmeetei <at> gmail.com> wrote:

Have you tried running the provider in process. If it crashes while running as in process. Getting a BT might help.
Which version of pegasus u r using. There was a related fix in pegasus 2.13

On Nov 18, 2014 7:35 AM, "Arunkumar S" <arunkumar.krishnan <at> gmail.com> wrote:
Hi Karl et al.,

Thanks for your inputs.

Actually, I am trying to unit test my provider against provider crash. 

The test objective is to ensure that Events are delivered properly, once provider is restarted by cimserver after its first crash, as per PEP#: 360

The steps:
1. Induce the provider to have NULL pointer Crash for a specific invokeMethod operation and get message "Lost connection with cimprovagt ..."
2. Generate a hardware event
3. Check whether the CIM Client - Event listener is able to receive that event or not. 

Having looked at the Pegasus and my provider log,   I have confirmed that the provider is getting crashed and then restarted by cimserver, but subsequently the event delivery is failing. 
The CMPI method - CBDeliverIndication for Event delivery is failing.  

My provider has all capabilities combined - Instance, Association, Method and Indication. 
maxFailedProviderModuleRestarts is set to default value =3

Do I need to enable any specific CIM attribute or cimconfig parameter. ?

Thanks,
Arun

On Mon, Nov 17, 2014 at 5:54 AM, Karl Schopmeyer <k.schopmeyer <at> swbell.net> wrote:
Here is an example of a script that would allow running just some oop providers under valgrind

#!/bin/sh
## Original Author: Tim Potter
# move cimprovagt to cimprovagt.real
# move this file to cimprovagt
#
# mv /usr/sbin/cimprovagt /usr/sbin/cimprovagt.real
# cp cimprovagt.wrapper /usr/sbin/cimprovagt

## By default the script doesn't call valgrind - enable it by
## creating a semaphore file of the form /tmp/$MODULE.valgrind where module
## is the module name in the output of "cimprovider -l".

## Or create a file /tmp/LogAll.valgrind which valgrinds all providers.

module=$5

VALGRIND_ARGS="--leak-check=yes --trace-children=yes --log-file=/tmp/$module.valgrind"

if [ -e /tmp/$module.valgrind -o -e /tmp/LogAll.valgrind ]; then
        exec /usr/bin/valgrind $VALGRIND_ARGS \
        /usr/sbin/cimprovagt.real "$ <at> "
else
        exec /usr/sbin/cimprovagt.real "$ <at> "
fi

On 11/16/2014 10:52 PM, Arunkumar S wrote:
Hi,

My provider is encountering a crash occasionally.  The CIM server automatically restarts the provider process. But the events are not delivered after the provider restart.

I have confirmed using cimsub that the event subscription is active. But even then, the events are not delivered to the target system.

But, If I restart the entire cimserver altogether, I can get the event delivered.

Thanks,
Arun







Arunkumar S | 19 Nov 10:02 2014
Picon

(unknown)

Hi All,

My provider has got degraded status. So I have reloaded it using using cimprovider cmd. 
But I could see both "Degraded" and "OK" messages , instead of just only "OK" message in the status column for my provider.

# cimprovider -l -s
MODULE                          STATUS
OperatingSystemModule        OK
ComputerSystemModule        OK
ProcessModule                     OK
ProcessorProviderModule      OK
IPProviderModule                 OK
xxxxxxProvider                    Degraded OK

Cross verified with PG_ProviderModule instance:
# cimcli -n root/PG_InterOp gi PG_ProviderModule.Name=\"xxxxxxProvider\" | grep  OperationalStatus
    OperationalStatus = {3, 2};

Is this expected behavior ?
My OP is 2.13.0

Thanks,
Arun

Arunkumar S | 18 Nov 03:05 2014
Picon

Re: Event delivery issue after Provider Crash

Hi Karl et al.,

Thanks for your inputs.

Actually, I am trying to unit test my provider against provider crash. 

The test objective is to ensure that Events are delivered properly, once provider is restarted by cimserver after its first crash, as per PEP#: 360

The steps:
1. Induce the provider to have NULL pointer Crash for a specific invokeMethod operation and get message "Lost connection with cimprovagt ..."
2. Generate a hardware event
3. Check whether the CIM Client - Event listener is able to receive that event or not. 

Having looked at the Pegasus and my provider log,   I have confirmed that the provider is getting crashed and then restarted by cimserver, but subsequently the event delivery is failing. 
The CMPI method - CBDeliverIndication for Event delivery is failing.  

My provider has all capabilities combined - Instance, Association, Method and Indication. 
maxFailedProviderModuleRestarts is set to default value =3

Do I need to enable any specific CIM attribute or cimconfig parameter. ?

Thanks,
Arun

On Mon, Nov 17, 2014 at 5:54 AM, Karl Schopmeyer <k.schopmeyer <at> swbell.net> wrote:
Here is an example of a script that would allow running just some oop providers under valgrind

#!/bin/sh
## Original Author: Tim Potter
# move cimprovagt to cimprovagt.real
# move this file to cimprovagt
#
# mv /usr/sbin/cimprovagt /usr/sbin/cimprovagt.real
# cp cimprovagt.wrapper /usr/sbin/cimprovagt

## By default the script doesn't call valgrind - enable it by
## creating a semaphore file of the form /tmp/$MODULE.valgrind where module
## is the module name in the output of "cimprovider -l".

## Or create a file /tmp/LogAll.valgrind which valgrinds all providers.

module=$5

VALGRIND_ARGS="--leak-check=yes --trace-children=yes --log-file=/tmp/$module.valgrind"

if [ -e /tmp/$module.valgrind -o -e /tmp/LogAll.valgrind ]; then
        exec /usr/bin/valgrind $VALGRIND_ARGS \
        /usr/sbin/cimprovagt.real "$ <at> "
else
        exec /usr/sbin/cimprovagt.real "$ <at> "
fi

On 11/16/2014 10:52 PM, Arunkumar S wrote:
Hi,

My provider is encountering a crash occasionally.  The CIM server automatically restarts the provider process. But the events are not delivered after the provider restart.

I have confirmed using cimsub that the event subscription is active. But even then, the events are not delivered to the target system.

But, If I restart the entire cimserver altogether, I can get the event delivered.

Thanks,
Arun





Khushboo Sancheti | 17 Nov 19:12 2014

Compiling Open Pegasus 2.13 with CIM 2.41 experimental

Hi,

Has anyone tried to compile Open Pegasus using 2.41 experimental CIM Schema? The latest schema that Open Pegasus 2.13 ships with seems to be CIM 2.36 per the pegasus/Schemas directory.

We are seeing the following issue:

Open Pegasus is compiled using CIM 2.36 schema (that is the default in the 2.13 source RPM).  We then try to register the 2.41 experimental CIM schema using cimmofl.  Cimmofl throws an error in the qualifiers.mof at line 154 complaining about the "Reference" field in qualifiers.mof of CIM 2.41 experimental.

Note: We have not seen this issue with Open Pegasus 2.12-2.



Gmane