I would rather strive for more portable solution. This is imho too much
Pegasus-oriented.
What I'm missing here is the storage for API version of our providers.
Either we'd
have to encode it into some String variable like InstanceID, ElementName
or Caption or use a RegisteredVersion property, which should contain
DMTF version of implemented
profile - another deviation from standard.
Otherwise I like its simplicity.
Michal
On 15.7.2013 10:56, Jan Safranek wrote:
Hi,
I have alternative proposal how to do profile registration using Pegasus
native classes.
Advantages:
- no new provider needed
- automatic SLP
Disadvantages:
- Pegasus only
As I reported in another email in this thread, it's enough to:
1. extend our openlmi-register-pegasus to add version into
PG_ProviderModule instances. E.g.:
$ openlmi-register-pegasus -v 0.5.2 < *.mof
2. extend openlmi-mof-register:
2.1 to accept version on command line and pass it to
openlmi-register-pegasus
2.2 to create instances of PG_ProviderProfileCapabilities, e.g. by using:
$ openlmi-mof-register register-profile myprofile.mof
Question is, if the profile registration should be directly Pegasus mof
file or some other file and openlmi-mof-register would create a Pegasus
mof file from it.
3. update our rpm packages to register/deregister profiles
Jan
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel