I would like the team to review the realmd provider I wrote. I tried to use ReviewBoard to post the review request but I ran into number of problems since the code is not yet in one of the repos known to the ReivewBorad instance. Also a diff in the context of new code doesn't make much sense, there is nothing to diff against and with such a large body of code diff format would be difficult to read. Instead I'm going to suggest cloning the below git repo to review the code.
git://fedorapeople.org/~jdennis/realmd-cim.git
In other projects we review prior to import anyway.
Some notes:
* We recognize this is not the best example of CIM modeling, To fully integrate into the existing CIM schema requires the existence of other providers which do not exist (i.e. credentials, KDC, etc.). We had a meeting about this a couple of weeks ago and decided at this juncture it was best to just expose what realmd provides and not attempt full model integration. We expect scriptons to hide much of this anyway.
* Two mof's have been proposed. The original LMI_realmd.mof exposed many of the features of realmd but there was concern about needing to support this API in the future when things change or whether people really needed access to the additional functionality. An alternate mof was proposed with a greatly simplified API that really only exposes a DomainName property and the JoinDomain & LeaveDomain methods. It was easy to just add the DomainName property and methods to the existing LMI_RealmdService class, this is marked in the mof with the comment "Proof of concept simplfied API starts here". At this early stage this seemed preferable to needing to produce two different providers, two different git branches, the potential to lose the source code for the full functionality if only the simplified version is imported etc. However, what is exposed via the mof is a question which must be resolved.
* There is a Python client script, doc/examples/realmd-cim which illustrates potential scripton snippets. It was written in a manner whereby the main script handles command line arg parsing and CIMOM connection handling, but then passes off operations to commands which implement individual actions, each has the same function prototype, a connection object, the parsed command line options, and any extra command line arguments.
* There are some files in the repo which exist only for development purposes, e.g. the scripts under tools/ and a barebones spec file used only for testing, you can ignore these during review.
John
Hi John, Radek Novacek and I have reviewed the realmd-cim code and we would like to merge it into the OpenLMI sources -- there is nothing that we would consider to be a blocker. The openlmi-providers tree would suit realmd-cim the best I think.
Radek might add his notes if he feels like I've forgotten something important but the review was quite easy -- we don't know realmd too well and formally the code looks
On Fri, 12 Apr 2013 08:51:27 -0400 John Dennis jdennis@redhat.com wrote:
I would like the team to review the realmd provider I wrote. I tried to use ReviewBoard to post the review request but I ran into number of problems since the code is not yet in one of the repos known to the ReivewBorad instance. Also a diff in the context of new code doesn't make much sense, there is nothing to diff against and with such a large body of code diff format would be difficult to read. Instead I'm going to suggest cloning the below git repo to review the code.
git://fedorapeople.org/~jdennis/realmd-cim.git
In other projects we review prior to import anyway.
Some notes:
- We recognize this is not the best example of CIM modeling, To fully
integrate into the existing CIM schema requires the existence of other providers which do not exist (i.e. credentials, KDC, etc.). We had a meeting about this a couple of weeks ago and decided at this juncture it was best to just expose what realmd provides and not attempt full model integration. We expect scriptons to hide much of this anyway.
The model doesn't look much like the DMTF standards however if it's functional (which I assume so) and convenient enough to use there is no reason no to accept it.
We will let you know when we're finished with the code merge.
Thanks a lot and regards,
openlmi-devel@lists.fedorahosted.org