Will 'openlmi-storage' follow the SNIA SMI-S standard?

Gris Ge fge at redhat.com
Mon Oct 28 00:58:21 UTC 2013


On Fri, Oct 25, 2013 at 05:05:46PM +0530, Devchandra L Meetei wrote:
> >>>>>
> If so, these two could be a good start:
>  * DMTF DSP1033 Profile Registration
> >>>>>
> pegasus also has already implemented this so as stop repeat work from
> different groups writing provider, so you can start using right away.
>

I was expecting DSP1033 could help me jump 'root/interop' or 'interop'
to OpenLMI 'root/cimv2' and provide me the tree-root 'CIM_ComputerSystem' for
SNIA SIM-S 'Block Services' Profile.

I has not CIM provider experience or pegasus, but from a SMIS client view, this
is how I understand the DSP1033.

Expected Way: [1]
 * EnumerateInstances('CIM_RegisteredProfile') in 'interop' namespace.
   # As DSP1033 state, 'root/interop' is OK while 'interop' is preferred.
 * Find a profile with RegisteredName == 'Block Services'
 * Associators(cim_chose_rp.path,
               AssocClass='CIM_ElementConformsToProfile',
               ResultRole='ManagedElement')
 * Then we get a CIM_ComputerSystem which is defined by SNIA SMI-S rev4

OpenLMI Curent status:
 * EnumerateInstances('CIM_RegisteredProfile') in 'root/interop'
   namespace
 * Find a profile with RegisteredName == 'Block Services'
   which turn out to be pegasus default one. So we should use
   'OpenLMI-Storage'
 * Previous Associators query got NULL.

OpenLMI version I am using:
====
openlmi-networking-0.2.0-1.elx.x86_64
openlmi-storage-0.6.0-2.elx.noarch
openlmi-indicationmanager-libs-0.3.0-3.elx.x86_64
openlmi-powermanagement-0.3.0-3.elx.x86_64
openlmi-python-providers-0.3.0-3.elx.noarch
openlmi-logicalfile-0.3.0-3.elx.x86_64
openlmi-service-0.3.0-3.elx.x86_64
openlmi-account-0.3.0-3.elx.x86_64
openlmi-python-base-0.3.0-3.elx.noarch
openlmi-providers-0.3.0-3.elx.x86_64
====

Please kindly correct me if I misunderstand the any standard spec
which happen a lot.

Thanks for the reply and correction on open-pegasus interop.

Best regards.

[1] I verified that procedure on EMC VNX SMI-S provider and IBM VNX
    SMI-S provider.

-- 
Gris Ge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20131028/54d4c472/attachment.sig>


More information about the openlmi-devel mailing list