Review Request 187: JobManager sync: [1/5] Synchronize JobManager with storage.
by Stephen Gallagher
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/187/
-----------------------------------------------------------
Review request for OpenLMI Developers.
Repository: openlmi-providers
Description
-------
Synchronize JobManager with storage.
JobManager here is older version of the one in openlmi-storage.
Let's sync it with the storage so I can use it from there.
The patch includes:
Fixed job expiration under SFCB.
Added LMI_StorageJob.JobInParameters and .JobOutParameters properties.
Allow python to exit the provider even if there are threads running.
Fixed job returning an error
Added possibility to set AffectedElements when a job finishes.
Added workaround for rhbz#920763
Diffs
-----
src/python/openlmi/common/JobManager.py a923f296d3eba40f1997a267b68525a44f50ffc7
Diff: http://reviewboard-openlmi.rhcloud.com/r/187/diff/
Testing
-------
Thanks,
Jan Safranek
11 years, 2 months
Review Request 134: [6/10] Use blivet everytime.
by Stephen Gallagher
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/134/
-----------------------------------------------------------
Review request for OpenLMI Developers.
Repository: openlmi-storage
Description
-------
Use blivet everytime.
Don't precache blivet state in the MountProvider constructor and don't use the
cached data. Instead, call blivet everytime the state of mounted filesystems has
to be checked.
Diffs
-----
src/openlmi/storage/LMI_HostedMount.py PRE-CREATION
src/openlmi/storage/LMI_MountedFileSystem.py PRE-CREATION
src/openlmi/storage/MountingProvider.py PRE-CREATION
Diff: http://reviewboard-openlmi.rhcloud.com/r/134/diff/
Testing
-------
Thanks,
Jan Synacek
11 years, 2 months
Network provider modeling
by Radek Novacek
During recent patch review [1] we've found out major issues in networking
provider model (thanks goes to Jan Safranek). I've misunderstood the concept
of network connection settings and tried to map them to NetworkManager's
Connections as tight as possible. It seems that authors of the DMTF standard
had a different vision.
How the model should look according to DMTF (DSP1116 [2]):
All of the following SettingDatas should exist for each network interface:
1) Static IPv4 (arbitrary number of static IPv4 addresses)
2) DHCP IPv4 only
3) DHCP IPv4 then static IPv4 (use DHCP and if available, if not use static
addresses)
4) DHCPv6
5) Static IPv6
6) Stateless IPv6
More of these SettingDatas could be active simultaneously.
How NetworkManager model looks:
Each network interface can have multiple Connections, each have separate IPv4
and IPv6 configuration. Connections don't have to be assigned to one
particular interface.
How to mix it together:
1) Exactly according to DSP1116:
Use one "special" NN Connection for each port that represents connection
created by OpenLMI network provider.
+ DMTF DSP1666 compliance
- IMHO not intuitive (I couldn't comprehend it from the profile on my own)
- doesn't handle NM Connections -- this means that current NM
configuration can't be displayed
- must somehow solve conflicts between changes by CIM and changes by
NetworkManager (and tools using it).
2) Follow NetworkManager model (that how it's done now)
Above mentioned SettingDatas don't exists, but there is SettingData for
each Connection in NM. Creating and modifying is done by custom methods.
+ More aligned to NM model
+ IMHO easier to understand and use then 1)
- doesn't follow (some parts of) DSP1116, but has the same classes
3) Combine both approaches
Have the 6 SettingData mentioned above still present but add additional
SettingData per existing NM Connections and have the custom methods
available.
+ DMTF DSP1666 compliance
+ more possibilities than solution 1)
+ can be added later on
- a lot of work, potentially complicated
I suggest continuing with 2) because it's already almost ready, (from my POV)
it's easier to use and it's more powerful then 1). Solution 3) might be doable
but now it would slow down the progress and it might turn out that this
approach is no-go.
Any suggestions how to approach this issue are very welcomed.
Thanks,
Radek Novacek
[1] https://reviewboard-openlmi.rhcloud.com/r/148/
[2] http://dmtf.org/sites/default/files/standards/documents/DSP1116_1.0.0.pdf
11 years, 2 months
ANNOUNCE: openlmi-storage 0.5.1.pre1 released
by Jan Safranek
We've just released openlmi-storage-0.5.1.pre1 release.
This is testing release, before final 0.5.1.
Grab it at
https://fedorahosted.org/releases/o/p/openlmi-storage/openlmi-storage-0.5...
Generated documentation can be found at:
http://jsafrane.fedorapeople.org/openlmi-storage/api/0.5.1.pre1/
Major changes from 0.5.0:
Reorganized the sources to use fully qualified import names.
Use Blivet instead of Anaconda as storage backend.
Use CMPILogger from openlmi-providers for logging.
All CreateOrModify* and Delete* methods are now asynchronous.
Block devices can be formatted with ext2/3/4, xfs and btrfs filesystems.
Indications are now supported for LMI_StorageJobs.
And as usual, fixed lot of bugs, improved test coverage and documentation.
All changes should be backward-compatible.
New SMI-S profiles:
Jobs Storage Subprofile
File Storage Profile
Filesystem Profile
Filesystem Manipulation Profile
New classes:
LMI_AffectedStorageJobElement
LMI_AssociatedStorageJobMethodResult
LMI_DataFormat
LMI_FileSystemConfigurationCapabilities
LMI_FileSystemConfigurationElementCapabilities
LMI_FileSystemConfigurationService
LMI_FileSystemElementSettingData
LMI_FileSystemSetting
LMI_HostedFileSystem
LMI_LocalFileSystem
LMI_MDRAIDDataFormat
LMI_OwningStorageJobElement
LMI_PVDataFormat
LMI_ResidesOnExtent
LMI_StorageInstCreation
LMI_StorageInstModification
LMI_StorageJob
LMI_StorageJob
LMI_StorageMethodResult
Please report any issues with this release either at openlmi-devel
mailing list or at our Trac at openlmi.org.
11 years, 2 months
Re: Review Request 185: openlmi-providers: Support for using libopenlmicommon by external providers
by Stephen Gallagher
> On April 11, 2013, 11:06 p.m., John Dennis wrote:
> > It's nice you added FindOpenLMI.cmake, that's one of solving the problem and it much more consistent with CMake.
> >
> > I don't see where openlmi.pc.in gets converted from a .in to the final file with substitutions nor where it gets installed.
> >
> > I'm not sure I see the value in the variable substitutions in openlmi.pc.in.
> >
> > openlmi.pc.in does not follow the conventions for pc files, please review the existing pc files in /usr/lib/pkgconfig, This document gives an overview: http://people.freedesktop.org/~dbn/pkg-config-guide.html
> >
> > Off the top of my head I think the OpenLMI.pc file might look like this:
> > ------------------------------------------------------
> > prefix=/usr
> > exec_prefix=${prefix}
> > includedir=${prefix}/include/openlmi
> > libdir=${exec_prefix}/lib
> >
> > Name: OpenLMI
> > Description: OpenLMI provider support
> > Version: 1.0.0
> > Libs: -lopenlmicommon
> > Cflags: -I${includedir}
> > ------------------------------------------------------
> >
> > I think I might keep the changes necessary for building (e.g. the .cmake and .pc) file independent of the header file name change, the two are unrelated.
> I don't see where openlmi.pc.in gets converted from a .in to the final file with substitutions nor where it gets installed.
see src/CMakeLists.txt:
17 configure_file(openlmi.pc.in openlmi.pc)
18 install(FILES openlmi.pc DESTINATION lib${LIB_SUFFIX}/pkgconfig)
> I'm not sure I see the value in the variable substitutions in openlmi.pc.in.
The variable substitution is there mainly because of substitution of version with actual version of OpenLMI-providers.
> openlmi.pc.in does not follow the conventions for pc files, please review the existing pc files in /usr/lib/pkgconfig
I based the .pc file on some random out of /usr/lib/pkgconfig, but it seems I picked a wrong one, will fix.
- Radek
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/185/#review201
-----------------------------------------------------------
On April 11, 2013, 4:02 p.m., Radek Novacek wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard-openlmi.rhcloud.com/r/185/
> -----------------------------------------------------------
>
> (Updated April 11, 2013, 4:02 p.m.)
>
>
> Review request for OpenLMI Developers.
>
>
> Repository: openlmi-providers
>
>
> Description
> -------
>
> Support for using libopenlmicommon by external providers
>
> * add FindOpenLMI.cmake module
> * add pkgconfig for OpenLMI
> * rename globals.c/h to openlmi.c/h
> * add symlink with major version to openlmicommon library
>
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=948948
>
>
> Diffs
> -----
>
> CMakeLists.txt 230ed263388a62fe4a293479ca7bb9744e3fcfd9
> cmake/modules/FindOpenLMI.cmake PRE-CREATION
> src/CMakeLists.txt 73189110171562bdcbaf56faff7d2d07b325a076
> src/account/LMI_AccountCapabilitiesProvider.c 1636ab7ad7b894bd9800f4fd8a20d22e9533fab2
> src/account/LMI_AccountManagementCapabilitiesProvider.c a4499be4d318495be6519d42b040e7da966835b9
> src/account/LMI_AccountManagementServiceCapabilitiesProvider.c febc4f31de52049b1c12049fbd3d687c0bf508b3
> src/account/LMI_AccountManagementServiceProvider.c 1af6cf4f55f574d3bf665202ff7b55224a8d9009
> src/account/LMI_AccountOnSystemProvider.c ab84097648ec2cbd883276f8e981d7c596a9ca5e
> src/account/LMI_AccountProvider.c c4a68f7c71d0f77821bdf95aec7ae60ffae0b455
> src/account/LMI_AccountSettingDataProvider.c 92d3b28a23bb04e625f65deb7573ab7baacea372
> src/account/LMI_AssignedAccountIdentityProvider.c 323a582217cd1c101863cc489b3e4ee94aa3a4ff
> src/account/LMI_AssignedGroupIdentityProvider.c a9037f1bd86a39ef21869796a692a0ec85affb08
> src/account/LMI_EnabledAccountCapabilitiesProvider.c 7cda823209f2d94ddc4f1fd8f7de3c210495d033
> src/account/LMI_GroupProvider.c a9c547724ecf8e66f92efb1677ee3b6f348f6051
> src/account/LMI_HostedAccountManagementServiceProvider.c dd03a5fc144bc8f4927fe9ebe7d598c05d771265
> src/account/LMI_IdentityProvider.c 92c2b0119a3dd81ca62be99c6e09f894f46841cd
> src/account/LMI_MemberOfGroupProvider.c dddd2e80952d7a1bedc0a0291ada56b5d7a1aea9
> src/account/LMI_OwningGroupProvider.c 317b7b4a4ec002acda6aa2b6a933a76ca41369a9
> src/account/LMI_ServiceAffectsIdentityProvider.c 64e218b4068c696dbb5479d7e73c2f38b4fc0cb5
> src/fan/LMI_FanAssociatedSensorProvider.c d75bf5cc39b8a28d17980ab763d48831d762387c
> src/fan/LMI_FanProvider.c 26af16ea3c119c4ea9fd8812e5b8cf9ed5007347
> src/fan/LMI_FanSensorProvider.c 47bd9d529931adc4ac6a1b15d759067bb63f324a
> src/fan/fan.c 30385034233c7abe4eb76939e8abc38f9819cf4c
> src/globals.h
> src/globals.c 7e58817fbaf87d25d4ec343d8589ec74f1224a8b
> src/hardware/LMI_AssociatedProcessorCacheMemoryProvider.c 3d06a65f7d24423400384f6bbfb70ecd8280319b
> src/hardware/LMI_PCIDeviceProvider.c e879484a53bc29aa6109ad31a25a9616f03ca3e0
> src/hardware/LMI_ProcessorCacheMemoryProvider.c afc5d7f0488c506dddabd438f7af56578f464856
> src/hardware/LMI_ProcessorCapabilitiesProvider.c c7711242aa14d6ea585eed2f4337f772a2d6a176
> src/hardware/LMI_ProcessorChipProvider.c 47ba488995976313c1def5a4269e55b1bbf051c3
> src/hardware/LMI_ProcessorChipRealizesProvider.c 6dfd4bfb91bd25b1a4c13d816766ae7b56e5286d
> src/hardware/LMI_ProcessorElementCapabilitiesProvider.c 322e966103f6e4acc6b69ec7269505bd3c6cff5f
> src/hardware/LMI_ProcessorProvider.c 99b0fad7d1e36efbb1e823d20cda74bf9b577235
> src/hardware/cpuinfo.h 5ec5dd5083fe73548a434a3312c0a371c0c0d961
> src/hardware/dmidecode.h 9190ea4ac26e82889b24184fc40072f007f9c836
> src/hardware/lscpu.h 5dc5bd5cbf01471ce8a6e98ba8f93386336a3898
> src/hardware/sysfs.h 0e0b523ec6918b028ae0b17b9c756b76e2e686e8
> src/hardware/utils.h 933c0427b127c8658b98b4b07ca06a2c9125c48a
> src/logicalfile/file.h b1b3358f0f48811a1b255d8e842ebcfaf38c2f2e
> src/openlmi.pc.in PRE-CREATION
> src/power/LMI_AssociatedPowerManagementServiceProvider.c fd6ffdbe5826d6e14503c4377301e37e67a3fe81
> src/power/LMI_ConcreteJobProvider.c 4841852f63cd9398f65c83866562c214f70b625c
> src/power/LMI_ElementCapabilitiesProvider.c 3a49518a26e2c3b523bac8289dcdf6f720ae7267
> src/power/LMI_HostedPowerManagementServiceProvider.c 889dd2cf211935da0d75d9af0064e38ea81cea3e
> src/power/LMI_PowerManagementServiceProvider.c 655d5948faa672a82b2c659f4a716e423ba5b3a7
> src/service/LMI_ServiceProvider.c 7c8ffdb242913dbe997f0ad802a9128f5f864c67
>
> Diff: http://reviewboard-openlmi.rhcloud.com/r/185/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Radek Novacek
>
>
11 years, 2 months
Review Request 123: openlmi-software [7/7] logging improvements
by Stephen Gallagher
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-openlmi.rhcloud.com/r/123/
-----------------------------------------------------------
Review request for OpenLMI Developers.
Repository: openlmi-providers
Description
-------
logging improvements
This relates mostly to YumWorker separated process that does not use
cmpi_logging.
Diffs
-----
src/software/openlmi/software/cimom_entry.py 4aa1d44b24b811197f8e316084ea7fdf3774857a
src/software/openlmi/software/yumdb/__init__.py d64c0f43a6d1aeabd31eca193becff76f6d6e4de
src/software/openlmi/software/yumdb/util.py f2af151945854d0c14f608f1f8f6124676876ed8
Diff: http://reviewboard-openlmi.rhcloud.com/r/123/diff/
Testing
-------
Thanks,
Michal Minar
11 years, 2 months