So far we've used Linux_ComputerSystem as our CIM_ComputerSystem we associate our instances to.
Since our primary CIMOM is Pegasus, we could get rid of our dependency on SBLIM's base providers and use PG_ComputerSystem instead. The CIM_ComputerSystem would still be configurable in /etc/openlmi/openlmi.conf, our providers would still be usable with SFCB. This change is just about the default.
Benefits: - one less dependency (sblim-cpmi-base.rpm)
Negatives: - we must rewrite our providers to default to PG_ComputerSystem (it's probably just one find+replace sed) - PG_ComputerSystem looks weird, EnumInstances returns CreationClassName=PG_ComputerSystem, while EnumInstanceNames returns CreationClassName=CIM_ComputerSystem. I'll investigate it.
Jan
Going through your mail, Just went back and check the pegasus code
and did few adjustment to to reflect the name properly(Though the particluar provider serves CIM_computerSystem, PG_ComputerSystem and CIM_UnitaryComputerSysteM).
[root@localhost pegasus]# cimcli gi PG_computersystem 1: PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost" Select an Instance (1..1)? ^C [root@localhost pegasus]# cimcli ei PG_computersystem
// path= PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost"
instance of PG_ComputerSystem { Caption = "Computer System"; Description = "Linux version 2.6.32-358.el6.x86_64 ( mockbuild@x86-022.build.eng.bos.redhat.com) " "(gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP " "Tue Jan 29 11:47:41 EST 2013"; ElementName = "Computer System"; OperationalStatus = {2}; Status = "OK"; CreationClassName = "PG_ComputerSystem"; Name = "localhost"; NameFormat = "Other"; PowerManagementCapabilities = {1}; PowerManagementSupported = FALSE; PowerState = 1; }; [root@localhost pegasus]# cimcli ni PG_computersystem PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost" [root@localhost pegasus]#
Will fix as a bug in 2.14(Will update the bug number later, Do openlmi need this to be backported?
On Fri, Oct 4, 2013 at 1:35 PM, Jan Safranek jsafrane@redhat.com wrote:
So far we've used Linux_ComputerSystem as our CIM_ComputerSystem we associate our instances to.
Since our primary CIMOM is Pegasus, we could get rid of our dependency on SBLIM's base providers and use PG_ComputerSystem instead. The CIM_ComputerSystem would still be configurable in /etc/openlmi/openlmi.conf, our providers would still be usable with SFCB. This change is just about the default.
Benefits:
- one less dependency (sblim-cpmi-base.rpm)
Negatives:
- we must rewrite our providers to default to PG_ComputerSystem (it's probably just one find+replace sed)
- PG_ComputerSystem looks weird, EnumInstances returns
CreationClassName=PG_ComputerSystem, while EnumInstanceNames returns CreationClassName=CIM_ComputerSystem. I'll investigate it.
Jan _______________________________________________ openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
On 10/04/2013 10:56 AM, Devchandra L Meetei wrote:
Going through your mail, Just went back and check the pegasus code
and did few adjustment to to reflect the name properly(Though the particluar provider serves CIM_computerSystem, PG_ComputerSystem and CIM_UnitaryComputerSysteM).
[root@localhost pegasus]# cimcli gi PG_computersystem 1: PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost" Select an Instance (1..1)? ^C [root@localhost pegasus]# cimcli ei PG_computersystem
// path= PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost"
instance of PG_ComputerSystem { Caption = "Computer System"; Description = "Linux version 2.6.32-358.el6.x86_64 (mockbuild@x86-022.build.eng.bos.redhat.com mailto:mockbuild@x86-022.build.eng.bos.redhat.com) " "(gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP " "Tue Jan 29 11:47:41 EST 2013"; ElementName = "Computer System"; OperationalStatus = {2}; Status = "OK"; CreationClassName = "PG_ComputerSystem"; Name = "localhost"; NameFormat = "Other"; PowerManagementCapabilities = {1}; PowerManagementSupported = FALSE; PowerState = 1; }; [root@localhost pegasus]# cimcli ni PG_computersystem PG_ComputerSystem.CreationClassName="PG_ComputerSystem",Name="localhost" [root@localhost pegasus]#
Will fix as a bug in 2.14(Will update the bug number later, Do openlmi need this to be backported?
No, we don't need it backported. Thanks for the quick fix!
Bug is http://bugzilla.openpegasus.org/show_bug.cgi?id=9795
Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/04/2013 04:05 AM, Jan Safranek wrote:
So far we've used Linux_ComputerSystem as our CIM_ComputerSystem we associate our instances to.
Since our primary CIMOM is Pegasus, we could get rid of our dependency on SBLIM's base providers and use PG_ComputerSystem instead. The CIM_ComputerSystem would still be configurable in /etc/openlmi/openlmi.conf, our providers would still be usable with SFCB. This change is just about the default.
Benefits: - one less dependency (sblim-cpmi-base.rpm)
Negatives: - we must rewrite our providers to default to PG_ComputerSystem (it's probably just one find+replace sed) - PG_ComputerSystem looks weird, EnumInstances returns CreationClassName=PG_ComputerSystem, while EnumInstanceNames returns CreationClassName=CIM_ComputerSystem. I'll investigate it.
sblim's license has always been a bit of a sticking point. We have LGPL code depending on EPL code, which is currently categorized as "We won't be sued", rather than "We're sure this is okay".
So for that piece of mind alone, I'm in favor of this change. Additionally, it will cement our stance that Pegasus is the official CIMOM.
Do I understand correctly that this will be effectively an internal-only change (from the perspective of people consuming only OpenLMI interfaces)? i.e. tests written against openlmi-storage or openlmi-account wouldn't need to be updated?
On 10/04/2013 05:49 PM, Stephen Gallagher wrote:
Do I understand correctly that this will be effectively an internal-only change (from the perspective of people consuming only OpenLMI interfaces)? i.e. tests written against openlmi-storage or openlmi-account wouldn't need to be updated?
Good question. All SMI-S use cases start with 'Find CIM_ComputerSystem representing the storage system' and 'find services XYZ using UVW association'. In reality, I doubt anyone finds services and other useful objects this way - at least in our scripts we just directly enumerate LMI_XYZService instances, there is no need to traverse through CIM_ComputerSystem.
If we take our scripts as example usage, the change to PG_ComputerSystem won't break anything.
Jan
As general Anybody changing from CIM_ComputerSystem to PG_ComputerSystem will not have any issue.
On Mon, Oct 7, 2013 at 2:24 PM, Jan Safranek jsafrane@redhat.com wrote:
On 10/04/2013 05:49 PM, Stephen Gallagher wrote:
Do I understand correctly that this will be effectively an internal-only change (from the perspective of people consuming only OpenLMI interfaces)? i.e. tests written against openlmi-storage or openlmi-account wouldn't need to be updated?
Good question. All SMI-S use cases start with 'Find CIM_ComputerSystem representing the storage system' and 'find services XYZ using UVW association'. In reality, I doubt anyone finds services and other useful objects this way - at least in our scripts we just directly enumerate LMI_XYZService instances, there is no need to traverse through CIM_ComputerSystem.
If we take our scripts as example usage, the change to PG_ComputerSystem won't break anything.
Jan _______________________________________________ openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
Hi,
On Mon, 2013-10-07 at 10:54 +0200, Jan Safranek wrote:
On 10/04/2013 05:49 PM, Stephen Gallagher wrote:
Do I understand correctly that this will be effectively an internal-only change (from the perspective of people consuming only OpenLMI interfaces)? i.e. tests written against openlmi-storage or openlmi-account wouldn't need to be updated?
Good question. All SMI-S use cases start with 'Find CIM_ComputerSystem representing the storage system' and 'find services XYZ using UVW association'. In reality, I doubt anyone finds services and other useful objects this way - at least in our scripts we just directly enumerate LMI_XYZService instances, there is no need to traverse through CIM_ComputerSystem.
If we take our scripts as example usage, the change to PG_ComputerSystem won't break anything.
It should not break any existing functionality, but I think it *will* break tests which compare the exact class name; I had a quick search in the storage tests and came up with
# cfg must return default values self.assertEqual(cfg.namespace, "root/cimv2") self.assertEqual(cfg.system_class_name, "Linux_ComputerSystem") self.assertEqual(cfg.system_name, socket.getfqdn())
in test/unit/config/test_unit_config.py.
I can imagine there may be other places too, so let's make sure we update these all at the same time.
Thanks, Stephen
On 10/04/2013 10:05 AM, Jan Safranek wrote:
So far we've used Linux_ComputerSystem as our CIM_ComputerSystem we associate our instances to.
Since our primary CIMOM is Pegasus, we could get rid of our dependency on SBLIM's base providers and use PG_ComputerSystem instead. The CIM_ComputerSystem would still be configurable in /etc/openlmi/openlmi.conf, our providers would still be usable with SFCB. This change is just about the default.
Benefits:
- one less dependency (sblim-cpmi-base.rpm)
Negatives:
- we must rewrite our providers to default to PG_ComputerSystem (it's probably just one find+replace sed)
Done, our providers read /etc/openlmi/openlmi.conf
- PG_ComputerSystem looks weird, EnumInstances returns
CreationClassName=PG_ComputerSystem, while EnumInstanceNames returns CreationClassName=CIM_ComputerSystem. I'll investigate it.
Upstream bug reported, patch available.
I also checked our providers and they generally work with PG_ComputerSystem, so I will send patches to change the default.
Jan
openlmi-devel@lists.fedorahosted.org