[ Note: some of you may receive a duplicate of this email, sorry. This time the PDF is linked to instead of attached. ]
When I started development of the realmd CIM provider I was told I was being a guinea pig. Take a developer who knows nothing about CIM or OpenLMI and see what issues a novice might encounter when asked to write a CIM provider. Then use that experience to write up documentation to pave the way for other developers to follow.
When I first started a few months ago the material on the OpenLMI wiki was sparse. I see that it has since been enhanced.
Here is a 24 page PDF. It is what I would have liked to have started with as a developer.
http://jdennis.fedorapeople.org/cim-provider-howto.pdf
The content is written in pandoc format, a universal format that can be formatted into HTML, PDF, mediawiki, reStructuredText, and many other document formats. As such this content can be put up on the web easily. I'm distributing this initial draft as a PDF because in my opinion the PDF formatting yields the most readable presentation. The document contains many clickable links to other material.
Those of you in the OpenLMI group will no doubt have corrections and suggestions on the technical content which I welcome, I'm sure as a neophyte I've made some errors along the way. Others may want to add their own suggestions and comments.
It's been an interesting ride. I hope this serves as a good foundation to build upon.
John
Hi John, now I finished a reading of your document. I'm very impressed. It's really very good job and for potential newbie very useful. I would say, it's somewhere between the very basic information and the whole technology(ies) description. Maybe we can format it to wiki and add to wiki page. Of course, if someone go into troubles writing own provider, he is very welcome to ask on this list or can also join #openlmi channel on freenode.
I have also few comments, suggestions...
I found few typos: - DMTF - DTMF misspelled. - doubled words - is is, and and - Forground - Foreground
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
You have used `Red Hat systems'. Maybe it will be better to mention Fedora also (or mainly).
You are using many external links, what is great. But can you please add the whole list of links at the end of document?
Notes for me - what we should improve? - Improve documentation of KonkretCMPI. - Support embedded instances in KonkretCMPI - Anyone else also have any issue?
Hey, btw, I learnt new things ;) Thank you.
RR
On 04/04/2013 11:29 PM, John Dennis wrote:
[ Note: some of you may receive a duplicate of this email, sorry. This time the PDF is linked to instead of attached. ]
When I started development of the realmd CIM provider I was told I was being a guinea pig. Take a developer who knows nothing about CIM or OpenLMI and see what issues a novice might encounter when asked to write a CIM provider. Then use that experience to write up documentation to pave the way for other developers to follow.
When I first started a few months ago the material on the OpenLMI wiki was sparse. I see that it has since been enhanced.
Here is a 24 page PDF. It is what I would have liked to have started with as a developer.
http://jdennis.fedorapeople.org/cim-provider-howto.pdf
The content is written in pandoc format, a universal format that can be formatted into HTML, PDF, mediawiki, reStructuredText, and many other document formats. As such this content can be put up on the web easily. I'm distributing this initial draft as a PDF because in my opinion the PDF formatting yields the most readable presentation. The document contains many clickable links to other material.
Those of you in the OpenLMI group will no doubt have corrections and suggestions on the technical content which I welcome, I'm sure as a neophyte I've made some errors along the way. Others may want to add their own suggestions and comments.
It's been an interesting ride. I hope this serves as a good foundation to build upon.
John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/04/2013 11:29 PM, John Dennis wrote:
Here is a 24 page PDF. It is what I would have liked to have started with as a developer.
http://jdennis.fedorapeople.org/cim-provider-howto.pdf
The content is written in pandoc format, a universal format that can be formatted into HTML, PDF, mediawiki, reStructuredText, and many other document formats. As such this content can be put up on the web easily. I'm distributing this initial draft as a PDF because in my opinion the PDF formatting yields the most readable presentation. The document contains many clickable links to other material.
John, would you be so kind as to also add a copyright license specification to this document? Perhaps under CC-BY-SA[1] or FDL[2]?
Basically, I want us to be able to share this out and have others improve upon it over time, so I'd very much like for it to have a license aligned with OpenLMI's source license.
[1] http://creativecommons.org/licenses/by-sa/3.0/ [2] http://www.gnu.org/licenses/fdl.html
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
On 04/05/2013 08:47 PM, John Dennis wrote:
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
I can't find much in documentation. Just in CIM Metamodel (CIM Infrastructure Specification) [1] are few words about Embedded Objects.
Embedded object is qualifier. For example you can have parameter of method with this qualifier. Such parameter will be embedded object (instance or class). The type of parameter is string. When we talk about instances - this string is encoded (embedded) instance of some class. There are functions in CMPI to create instance from this string representation.
I have never used this. But I think it could help to encapsulate definition of parameter and passing it, but with need of such definition in model.
RR
[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_3.0.0.pd...
On 04/08/2013 04:51 AM, Roman Rakus wrote:
On 04/05/2013 08:47 PM, John Dennis wrote:
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
I can't find much in documentation. Just in CIM Metamodel (CIM Infrastructure Specification) [1] are few words about Embedded Objects.
Embedded object is qualifier. For example you can have parameter of method with this qualifier. Such parameter will be embedded object (instance or class). The type of parameter is string. When we talk about instances - this string is encoded (embedded) instance of some class. There are functions in CMPI to create instance from this string representation.
I have never used this. But I think it could help to encapsulate definition of parameter and passing it, but with need of such definition in model.
Ah, O.K. yes this now rings a bell with me and I did momentarily consider this as an option. My understanding is it amounts to formatting the data in MOF syntax and passing it as a string. One then parses the MOF formatted string.
My take on this is:
* It's very awkward to use, it's not a friendly API scheme.
* I didn't find any support for parsing MOF syntax in any of the libraries a provider links with.
Thus at the moment it doesn't seem like a viable option and even if we grow support for parsing MOF syntax I'm not sure one would want to design an API around passing MOF snippets.
[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_3.0.0.pd...
On 04/08/2013 03:59 PM, John Dennis wrote:
On 04/08/2013 04:51 AM, Roman Rakus wrote:
On 04/05/2013 08:47 PM, John Dennis wrote:
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
I can't find much in documentation. Just in CIM Metamodel (CIM Infrastructure Specification) [1] are few words about Embedded Objects.
Embedded object is qualifier. For example you can have parameter of method with this qualifier. Such parameter will be embedded object (instance or class). The type of parameter is string. When we talk about instances - this string is encoded (embedded) instance of some class. There are functions in CMPI to create instance from this string representation.
I have never used this. But I think it could help to encapsulate definition of parameter and passing it, but with need of such definition in model.
Ah, O.K. yes this now rings a bell with me and I did momentarily consider this as an option. My understanding is it amounts to formatting the data in MOF syntax and passing it as a string. One then parses the MOF formatted string.
My take on this is:
It's very awkward to use, it's not a friendly API scheme.
I didn't find any support for parsing MOF syntax in any of the
libraries a provider links with.
It's not MOF formatted string, it's CIM object instance encoded in XML as string-value of a property.
On server (CIMOM) side, this is automatically handled and translated into CMPI_instance property, on client side, pywbem handles it transparently too.
And it's quite often used when specifying 'SettingData'. Application, i.e. CIM client, creates a CIM_SettingData instance, fills its properties and passes it as EmbeddedInstance to a method, which creates something.
For example, CIM_FileSystemConfigurationService.CreateFileSystem + CIM_FileSystemSetting.
Actually, subclassing CIM_SettingData might be the magic key-value structure you were looking for. Only list of keys and possible values must be known and defined in *SettingData MOF file. Adding new keys in new version is perfectly valid, it does not need to be rock stable.
Thus at the moment it doesn't seem like a viable option and even if we grow support for parsing MOF syntax I'm not sure one would want to design an API around passing MOF snippets.
[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_3.0.0.pd...
On 04/08/2013 10:28 AM, Jan Safranek wrote:
On 04/08/2013 03:59 PM, John Dennis wrote:
On 04/08/2013 04:51 AM, Roman Rakus wrote:
On 04/05/2013 08:47 PM, John Dennis wrote:
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
I can't find much in documentation. Just in CIM Metamodel (CIM Infrastructure Specification) [1] are few words about Embedded Objects.
Embedded object is qualifier. For example you can have parameter of method with this qualifier. Such parameter will be embedded object (instance or class). The type of parameter is string. When we talk about instances - this string is encoded (embedded) instance of some class. There are functions in CMPI to create instance from this string representation.
I have never used this. But I think it could help to encapsulate definition of parameter and passing it, but with need of such definition in model.
Ah, O.K. yes this now rings a bell with me and I did momentarily consider this as an option. My understanding is it amounts to formatting the data in MOF syntax and passing it as a string. One then parses the MOF formatted string.
My take on this is:
It's very awkward to use, it's not a friendly API scheme.
I didn't find any support for parsing MOF syntax in any of the
libraries a provider links with.
It's not MOF formatted string, it's CIM object instance encoded in XML as string-value of a property.
On server (CIMOM) side, this is automatically handled and translated into CMPI_instance property, on client side, pywbem handles it transparently too.
Thank you Jan, great information!
Is this supported on all the CIMOM's we're interested in?
Is there client support for generating the XML?
And it's quite often used when specifying 'SettingData'. Application, i.e. CIM client, creates a CIM_SettingData instance, fills its properties and passes it as EmbeddedInstance to a method, which creates something.
For example, CIM_FileSystemConfigurationService.CreateFileSystem + CIM_FileSystemSetting.
Actually, subclassing CIM_SettingData might be the magic key-value structure you were looking for. Only list of keys and possible values must be known and defined in *SettingData MOF file. Adding new keys in new version is perfectly valid, it does not need to be rock stable.
Thus at the moment it doesn't seem like a viable option and even if we grow support for parsing MOF syntax I'm not sure one would want to design an API around passing MOF snippets.
[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0004_3.0.0.pd...
On 04/08/2013 04:38 PM, John Dennis wrote:
On 04/08/2013 10:28 AM, Jan Safranek wrote:
On 04/08/2013 03:59 PM, John Dennis wrote:
On 04/08/2013 04:51 AM, Roman Rakus wrote:
On 04/05/2013 08:47 PM, John Dennis wrote:
On 04/05/2013 07:35 AM, Roman Rakus wrote:
I'm confused in section where you are describing structures and array of structures. I think this is where Embedded Instances take place. However, the KonkretCMPI does not support embedded instances.
Hello Roman:
I'm not familiar with embedded instances. Can you elaborate or provide a pointer to documentation?
Thanks.
I can't find much in documentation. Just in CIM Metamodel (CIM Infrastructure Specification) [1] are few words about Embedded Objects.
Embedded object is qualifier. For example you can have parameter of method with this qualifier. Such parameter will be embedded object (instance or class). The type of parameter is string. When we talk about instances - this string is encoded (embedded) instance of some class. There are functions in CMPI to create instance from this string representation.
I have never used this. But I think it could help to encapsulate definition of parameter and passing it, but with need of such definition in model.
Ah, O.K. yes this now rings a bell with me and I did momentarily consider this as an option. My understanding is it amounts to formatting the data in MOF syntax and passing it as a string. One then parses the MOF formatted string.
My take on this is:
It's very awkward to use, it's not a friendly API scheme.
I didn't find any support for parsing MOF syntax in any of the
libraries a provider links with.
It's not MOF formatted string, it's CIM object instance encoded in XML as string-value of a property.
On server (CIMOM) side, this is automatically handled and translated into CMPI_instance property, on client side, pywbem handles it transparently too.
Thank you Jan, great information!
Is this supported on all the CIMOM's we're interested in?
Is there client support for generating the XML?
EmbeddedInstance qualifier is supported both by SFCB and Pegasus. There is also similar EmbeddedObject qualifier, which is 99% the same:
EmbeddedInstance qualifier must include a class name. Method parameter or property with this qualifier then must have instance of the specified class, encoded into XML, as its value.
class CIM_FileSystemConfigurationService : CIM_Service { //... uint32 CreateFileSystem( //... [IN, Description ( "..."), EmbeddedInstance ( "CIM_FileSystemSetting" )] string Goal, };
On the other hand, EmbeddedObject qualifier does *not* include a class name and method parameter or property can be of any class. EmbeddedObjects are problematic in Pegasus, but upstream is working on a fix.
class CIM_InstMethodCall : CIM_InstIndication { //... [Description ( "The parameters of the method, formatted as an " "EmbeddedObject (with a predefined class name of " ""__MethodParameters"." ), EmbeddedObject] string MethodParameters; };
I'm mainly working on server side, e.g. I'm implementing CIM_MethodResult, which has property PreCallIndication, which is EmbeddedInstance of CIM_InstMethodCall, which has property MethodParameters, which is EmbeddedObject and all wraps nicely.
On client side, I can access these properties transparently using pywbem - the XML string is translated from/to CIMInstance automatically. I guess that the same applies to parameters of methods, just pass CIMInstance instead of string with XML as a method argument.
Regarding other CIM client libraries, I have no idea if EmbeddedInstance is supported or not.
Jan
On 04/08/2013 04:28 PM, Jan Safranek wrote:
It's not MOF formatted string, it's CIM object instance encoded in XML as string-value of a property.
I'm not sure, but the format can be MOF and XML (maybe other?). CIMOM should have an easy mechanism to convert such string to Instance.
RR
On Thursday 04.4.2013 17:29:16 John Dennis wrote:
[ Note: some of you may receive a duplicate of this email, sorry. This time the PDF is linked to instead of attached. ]
When I started development of the realmd CIM provider I was told I was being a guinea pig. Take a developer who knows nothing about CIM or OpenLMI and see what issues a novice might encounter when asked to write a CIM provider. Then use that experience to write up documentation to pave the way for other developers to follow.
When I first started a few months ago the material on the OpenLMI wiki was sparse. I see that it has since been enhanced.
Here is a 24 page PDF. It is what I would have liked to have started with as a developer.
First of all I must say, you have done a great job, the howto is awesome.
I have a couple of comments, but they might not be valid -- it just my opinion:
* I would add more detailed associations explanation -- mainly a statement that association are basically ordinary classes.
* It might be useful to describe standard methods - EnumerateInstances, GetInstance, References/Associators...
* Typo page 19: The preferred mechanism is to use the *pegaus* user account
* PropertyPolicy on page 22 has wrong format (bullets and indentation)
* Typo page 23: Sometimes *refereed* to as a broker ...
Otherwise it looks good.
Thanks,
Radek Novacek
openlmi-devel@lists.fedorahosted.org
-
Jan Safranek -
John Dennis -
Radek Novacek -
Roman Rakus -
Stephen Gallagher