OMI - Documents - OMI Source

OMI 1.0.8 Release Notes

=======================

The sections below describe a new feature or a bug that was fixed in OMI 1.0.8 (Beta and Final).

Important Notes:

==================================

Providers should not perform blocking operations using the OMI Server thread, when processing a call from OMI Server. Infinite waits, or sleeps, will block the omiserver thread indefinitely.
Indications should only be posted from a separate thread within the provider (a "background thread"), and should not be posted using the OMI Server thread during a call into a provider. See "Support for CIM Indications" below for more information.
A breaking change was made in OMI 1.0.8 in the return value for method invocation. See "'MIReturn' is now 'ReturnValue'", below.
A potentially breaking change was required in OMI 1.0.8 to resolve security issues for users accessing in-proc providers as ROOT. See "InProc providers require ROOT requestor".
A potentially breaking change was required in OMI 1.0.8 to avoid leaking instances if delete/destroy is not called explicitly. See "Memory Leak during delete / destroy of instances".

'MIReturn' is now 'ReturnValue'

===================================

This affects all clients (including providers) which invoke a method and read the return value from the invocation result instance. In OMI 1.0.7 and before, a client may invoke a method using the libmicxx.so library, and read the return value in the MIReturn property of the result instance. In OMI 1.0.8 and future releases, the client must read the return value in the ReturnValue property instead.

Inproc Providers Require ROOT requestor

=========================================

OMI model relies on the provider developer to manage their security, For providers run in-process with the OMI service, though, it needed a security check to ensure that users with limited access to the machine could not get access as ROOT by compromising the provider. The change made in 1.0.8 is for the server to only allow access to in-process providers by the root clients (clients who have authenticated as root). When running in-process, the provider manager will check whether a request has the UID=0 and GID=0 (i.e., root). If not, the provider manager will send 'access denied' error to the client. This behavior should be relaxed if the server is not actually running as root (e.g. during testing). It may do this by calling getuid() and seeing if 0 is returned (indicating that the UID is root).

Memory Leak during delete / destroy of instances:

=================================================

To ensure a consistent contract across all implementations of the MI APIs, the behavior for getting/constructing instances from the MI_Context in providers requires the provider writer to delete/destroy their instances. OMI provider writers could delete/destroy the instance (recommended) themselves, but they would generally get deleted once the _PostResult is called, but that is no longer true. What this means is that existing OMI providers that do not call delete/destroy will leak memory by default.

The provider writer can either update their code to delete/destroy the instances, or the provider can use the new option on omireg during registration:

-i, --instancelifetime LT

Changes default lifetime of instances created fromn the MI_Context.

Default is until destroyed by then provider by calling MI_Instance_Delete or

MI_Instance_Destruct, but overridable by setting LT ton CONTEXT such that it will automatically get deleted when

the MI_Context gets destroyed after the operation.

To get the OMI 1.0.7 behvior, when the provider is registered add the following command line option to omireg:

--instancelifetime CONTEXT

Support for CIM Indications:

==================================

OMI 1.0.8 enables providers to expose events using CIM Indications, and has added support for the Subscribe operation initiated by OMI clients. See section 8.3.8 of the OMI documentation for detailed information. Note that this implementation does not include support for the full CIM Indication Profile (DSP1054), or for subscription persistence across service restarts.

IMPORTANT: Indications should only be posted from a separate thread within the provider (a "background thread"), and should not be posted using the omiserver thread during a call into a provider.

Providers may now provide the industry-standard events by posting instances of CIM_Indication. A CIM Indication is a representation of an event in the managed system. Events may be related to objects accessible in a CIM server, such as the creation, modification, deletion of or access to an object, or execution of a method on the object. Such events are referred to as "Lifecycle Indications". Events may also be related to the managed system, such as alerts or errors coming from the hardware. These events are referred to as "Alert Indications". A CIM client can subscribe for receiving indications by providing the indication type and the filtering expression, which selects events that will be delivered to the client. See section 4.7 of the documentation for information on how to subscribe to both Alert and Lifecycle indications.

OMI enables provider-to-provider interaction using the MI API:

==================================

The MI API now supports the full range of standard CIM operations for a provider to use enabling them consume data exposed by another MI provider. The basic flow starts by using MI_Application_NewSession to create a session for a set of operations, then using the various operation-specific interfaces. The operations supported using the MI_ APIs include: GetInstance - MI_Session_GetInstance. EnumerateInstances - MI_Session_EnumerateInstances. CreateInstance - MI_Session_CreateInstance. DeleteInstance - MI_Session_DeleteInstance. ModifyInstance - MI_Session_ModifyInstance. Associators - MI_Session_AssociatorInstances. Invoke (method) - MI_Session_Invoke. Subscribe - MI_Session_Subscribe.

OMI now includes the NITS integrated testing system

===============================

This is a new unit test framework written in C, and provided with the OMI package. The NITS framework enables complex tests to be crafted, and enables simulating fault injection in the code. NITS replaces the existing unit test infrastructure, and makes debugging, maintenance, and code coverage testing significantly easier. The unit tests that ship with OMI 1.0.8 (Beta) use NITS. There are detailed instructions in Appendix D of the OMI documentation that describe how NITS may be used.

Bug: Invoke method fails on a Method with Embedded Instance parameter that lacked key values

=============================================================

Fixed the issue that, when calling icim on a method which takes in embedded instance as a parameter, an error is thrown if the Key values were not supplied for the embedded instance.

Bug: Cross Namespace traversal for an association

=============================================================

OMI will now properly support an association query which traverses from one namespace to the other. Previously, instances returned would be from the originating namespace, not the namespace identified in the association query.