Patch review for OpenLMI
by Jan Safranek
Hi,
we've talked on Friday about starting code review for all OpenLMI
patches. Fedora 19 alpha freeze is here and it could be good milestone
to start with reviews (or at least as good as any other milestone).
I would prefer as light review process as possible, we're still in
initial development where we code pretty quickly and I personally don't
want to get slowed down by reviewing each patch character-by-character.
@sgallahg, you mentioned some review tool, what was it and
where/when/how can we use it?
Jan
11 years, 1 month
ANNOUNCE: openlmi-providers 0.0.19 released
by Radek Novacek
Shiny new version of openlmi-providers has just been released.
Highlights of 0.0.19 version:
* New provider: LogicalFile
* Path to Pegasus's repository in mof registration script fixed (ticket #71)
* Improvements in cmake macros in OpenLMIMacros.cmake
* Scripts from generating documentation from mof files was ported to
KonkretCMPI mof parser (was using CIMOM) and now are installed by default (as
openlmi-doc-class2rst and openlmi-doc-class2uml).
Great feature of this release is brand new LogicalFile provider. It allows to
read files and list the contents of directories as well as to create and
remove directories. One can use this provider to browse the filesystem
hierarchically.
It doesn't read whole tree at once, so don't expect EnumerateInstances on the
classes implemented by this provider to work. Use LMI_RootDirectory
association to get instance of LMI_UnixDirectory representing root directory
associated to ComputerSystem and then instances of association
LMI_DirectoryContainsFile for content of the directory.
Kudos for this provider goes to Jan Synáček.
You can download the this release from fedorahosted [1]. It is already in
Fedora rawhide and it's coming to Fedora 18 soon.
Thanks,
Radek Novacek
[1] https://fedorahosted.org/released/openlmi-providers/openlmi-providers-0.0...
11 years, 1 month
Re: Cron Provider?
by Russell Doty
> Date: Thu, 7 Mar 2013 15:36:13 +0100
> From: Tomáš Smetana <tsmetana(a)redhat.com>
> To: openlmi-devel(a)lists.fedorahosted.org
> Subject: Re: Cron Provider?
> Message-ID: <20130307153613.14e1a0f0(a)zaphod.usersys.redhat.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, 07 Mar 2013 08:42:41 -0500
> Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>
> > >> So yes, we *could* build a scheduling provider, but I think we
> > >> want to think very hard about what level of scheduling we want to
> > >> support. systemd's scheduler is a very large superset of what
> > >> cron is capable of, so I suppose we could build that first and
> > >> then extend it later to support the advanced systemd features.
The underlying question is "do system admins using OpenLMI need to
submit jobs to run at a specific time, or to run repeatedly?" This looks
desirable, but I don't know how heavily it would be used.
> > >
> > > Starting with cron would also have the advantage of building the
> > > most portable code first; it would make sense to add the more
> > > version-specific options later.
Cron would be portable across older versions of Linux; the systemd
scheduler would only support newer versions.
> > >
> >
> > While I agree with that in principal, I need to make the point that
> > I'm not sure we can build a CIM model for cron that will extend to the
> > systemd approach at all. They may ultimately need to be two separate
> > models, at which point we'll need to figure out how to manage the
> > transition (which is what OpenLMI is trying to avoid).
It would make sense to do two separate providers. This would also
simplify the model - one model for cron, one model for systemd
scheduler. I don't see a lot of value in closely following a DMTF model
here (unless it is already based on cron).
>
> Cron might be an interesting modelling exercise... There are user crontabs,
> scripts in /etc/cron.{hourly,weekly,monthly}, package-specific crontabs
> in /etc/cron.d, system-wide /etc/crontab. And we might want to model and
> monitor the running/finished jobs as well. I admit I don't know much about
> systemd timer units. However I suppose systemd might make it easier to find
> logs of a particular job run at least (and this would be a required feature I
> assume).
>
> I'm only afraid that both the cron and systemd are config-files driven and we
> probably won't avoid parsing/editing the files. Which is ugly.
>
> Regards,
11 years, 2 months
Cron Provider?
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed 06 Mar 2013 06:59:44 PM EST, Russell Doty wrote:
> Do we need to consider a cron Provider?
>
Consider? Yes. Actually do it right now? No, not at all.
The issue is that cron's future is uncertain. It will remain in use in
the real world for many years at the least (and most likely we'll
retain legacy support for it in the future) but there is a new player
in this field. systemd recently added the ability to manage scheduled
events, and it does so with a language that is much closer to that of
a calendaring program's scheduling than it is to cron. So my major
concern here is that there may not be a way to model the scheduling
provider (let's call it that, rather than cron provider) in such a way
that it can account for both formats.
So yes, we *could* build a scheduling provider, but I think we want to
think very hard about what level of scheduling we want to support.
systemd's scheduler is a very large superset of what cron is capable
of, so I suppose we could build that first and then extend it later to
support the advanced systemd features.
I'm CCing openlmi-devel here to expand the conversation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlE4ig8ACgkQeiVVYja6o6PuEQCeN5m2oEE1QQaL8rffvaF3Nxs2
PLYAnjWSdCZje5OpkrUROQdaiHFU7+Qw
=SNRn
-----END PGP SIGNATURE-----
11 years, 2 months
New feature: LMI_ProcessorProvider
by Peter Schiffer
Hello list,
I've just pushed commit [1] to the openlmi-providers repo with new
LMI_ProcessorProvider, providing information about CPU. Main source of
information is dmidecode program, with additional information from
lscpu program and /proc/cpuinfo file. In case when output from
dmidecode program is not available (e.g. in some virtual machines)
fallback mode based only on lscpu and /proc/cpuinfo is used.
Since this is my first contribution to the OpenLMI project, I would
highly appreciate your review of my changes.
Thanks!
peter
[1] commit 7a0b251bcd55a26679bb99480f02948105947d05
11 years, 2 months
CIM_SettingData, usage patterns, etc.
by John Dennis
Several related questions here:
As a CIM newbie I've been able to find the specs, the schemas, the
tutorials, existing implementations, etc. Many of these resources have
tremendous detail but usually it's on entities in isolation (e.g. the
classes) or discussions at a very abstract level with no practical
examples. What I've had a heck of a time finding is "patterns of usage".
In other words given the existing model and it's available classes how
do you assemble the disparate pieces according to best practice to
arrive at a solution that is consistent with how CIM experts expect CIM
to be used? I'm wondering if there are resources that discuss the
"practical how-to of CIM modeling", if so could someone point me that
information?
Here is a good example of where I have a hole in my understanding.
I need to model a service. That service has configuration parameters. My
understanding is I need to do the following:
* Derive a class from CIM_Service (or one if it's subclasses)
* Derive a class from CIM_SettingData that encapsulates the
configuration parameters for the service.
* Derive a class from CIM_Capabilities that enumerates what can be set
in the matching SettingData class.
The service will instantiate a SettingData instance and set an
association between the service and SettingData, this represents the
current configuration parameters. Is this correct?
Now lets say someone wants to modify the configuration parameters for
the service. How do they do it? It seems as if one needs to instantiate
a SettingData instance with the desired parameters and pass that to the
service. Is that correct?
If so it would seem there are two ways to accomplish that.
1) Define a method on the service which accepts a reference to a
SettingData instance.
a. Does the provider examine the SettingData and only update
the non-null parameters?
b. Does the provider replace the existing association between
the service and it's SettingData with the new reference?
2) Define an association class that binds the SettingData to the service
(but how would the service provider know this association was formed?)
Summary:
How does one set the configuration parameters for a service? Is it via
an instance of a SettingData class and if so how?
Addendum:
I found numerous SettingData classes and a number of Capability classes
in various schemas but what I couldn't find was any mention of these
classes get used in practice. It also seems as if SettingData can be
used in a variety of different ways (e.g. patterns) but I wasn't able to
figure out what those patterns were. Can somebody elucidate those
patterns or point me to resources that explain them?
Thanks so much for your help,
John
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
11 years, 2 months
Design of mounting in OpenLMI-Storage
by Jan Safranek
Hi,
we should do some mounting in OpenLMI storage provider and I want to
discuss its design.
(sorry for HTML, is there any better way how to send such proposals?)
* SMASH and DASH do not cover mounting of filesystems.
* SMI-S has Filesystem Manipulation Profile, but it's closely tight to
filesystem management, for example:
o Filesystems are mounted using SNIA_CreateFileSystem method, i.e.
it's possible to create & mount a FS in one call, but it's weird
to call SNIA_CreateFileSystem to mount existing FS (but it's
possible).
o Filesystems can be mounted only once.
o Only local filesystems can be mounted.
CIM provides lot of classes to manage mounts:
* CIM_Mount - association between a FS and a directory, where it's
mounted.
* CIM_FileImportService - service, which mounts remote filesystems
(NFS, CIFS) + usual Setting & Capabilities classes
There is no service which mounts local filesystems!
So, looking at the CIM_FileImportService, we might get inspired by it
and create following classes:
* LMI_MountService
o CreateMount(FS, type, mountpoint, goal, permanent)
+ FS: reference to either Local or RemoteFileSystem or NULL.
+ type: uint16, enum (nfs, cifs, xfs, ext2/3/4, vfat, ...).
+ mountpoint: string (or reference to LMI_Directory?).
+ goal: reference to LMI_MountSettings or NULL to use default.
+ permanent: boolean, whether to store in fstab.
+ if FS is NULL, type can be used to create tmpfs, sysfs,
procfs, cgroups, ...
+ LMI_Mount is created with attached LMI_MountSetting.
o Remote file systems are represented by RemoteFileSystem, but how
to enumerate them when they are not mounted? We probably don't
want to scan the network for available NFS/CIFS shares. We might
add a method to create such RemoteFileSystem and mount it using
CreateMount(), but I propose following function:
o CreateRemoteMount(specifier, type, mountpoint, permanent)
+ specifier: string like 'foo:/home/jsafrane' for NFS or
'//foo/home/jsafrane' for CIFS.
+ type, mountpoint, goal, permanent: same as above.
+ Appropriate CIM_RemoteFileSystem gets created.
+ LMI_Mount is created with attached LMI_MountSetting.
o ModifyMount(mount, goal, permanent)
+ mount: reference to existing LMI_Mount.
+ goal: reference to new LMI_MountSettings of the mount.
+ permanent: whether to store this mount in fstab.
# if the mount was permanent and is not anymore, it gets
removed from fstab.
# if the mount was not permanent and is now, it gets added
to fstab.
# if the mount was permanent and still is, fstab is edited.
o DeleteMount(mount)
+ mount: reference to existing LMI_Mount.
o All these methods return Job (mounting can take some time, right?)
* LMI_Mount: inherited from CIM_Mount
o Association between a CIM_FileSystem (local or remote) and
CIM_Directory where it's mounted.
o Has property if this mount is permanent (in fstab).
o Has property if this mount is active (i.e. currently mounted).
o There can be LMI_Mount, which does not exist on the system, but
has entry in fstab!
+ e.g. when admin remounts a mount which is in fstab with
different options, there will be two LMI_Mount instances.
# One for the fstab mount (inactive, permanent).
# One for the actual mount (active, not permanent).
# OpenLMI can edit both.
# One of the mount instances disappears when fstab and
running system gets in sync.
+ /We must add new key to the association to //distinguish
multiple mounts of one fs to the same directory, just with
different options and permanent/non permanent flag./
+ /There can be only one fstab entry for (device, directory)
pair./
o If there is an entry in fstab but the filesystem (or block
device) is not available, no LMI_Mount is created!
+ /How to edit/delete such leftovers? Maybe the device was
just renamed./
* LMI_MountSetting
o Configuration of a mount.
o Has properties for selected mount options
+ ro
+ rw
+ Anything else? We may gradually extend this class and even
make subclasses for each FS, e.g. have LMI_Ext2MountSetting,
LMI_XFSMountSetting, LMI_NFSMountSetting, ...
o Has generic array of strings of 'additional options' for all
mount options, which are not covered by specific properties.
o Is associated with LMI_Mount to shows its configuration.
+ /LMI_Mount is association, i.e. we have association between
association and MountSetting, which is slightly confusing./
* LMI_MountCapabilities
o Capabilities of the MountService, as usual in SMI-S and LMI
storage model.
UML class diagram
This CIM API does not follow any DMTF or SMI-S standard, but follows the
idea of it - have a Service, Setting and Capabilities classes and can be
extended in the future.
Later we still may implement CIM_FileImportService if someone wants, but
it would be just a wrapper around our MountService.
In Fedora19 I think we can do only 'transient' mounts, no fstab editing,
Blivet doesn't support non-destructive fstab manipulation now. In
addition, Blivet does support mounting of local filesystems on block
devices for now (no cgroups, sysfs, procfs, tmpfs, ...), but even this
limited functionality is IMHO quite lot of work on OpenLMI side.
Any comments are welcome, especially the parts in /italics/ are quite
disturbing to me. And links to any model which already covers mounting
would be greatly appreciated.
Jan
11 years, 2 months
