RFC: Blivet & mounting
by Jan Safranek
Hello,
OpenLMI project uses Blivet, former Anaconda storage library, to manage
storage. Management of storage also means management of mounts, i.e.
ability to mount/unmount/remount stuff, list existing mounts and
add/delete/modify/list entries in /etc/fstab.
The installer somehow manipulates fstab and mounts stuff and there is
some code in Blivet for that, but I am not sure it can be easily
extended for generic use case.
Is generic mounting/unmounting capability that something Blivet should
do, so it would be integrated there, or there should be separate library
for this? In both cases, we (=OpenLMI) would /probably/ provide the code.
Is there any other potential Blivet user who needs mounting? Can the
installer benefit from more generic mounting?
What OpenLMI needs:
- parse /proc/mounts and provide list of mounts with their options
- parse /etc/fstab and provide list of persistent mounts with their
options (which can be different to /proc/mounts, someone might re-mount
something with different options!)
- re-mount a mount with different options
- create new mount, both permanent (with fstab entry) and 'temporary'
- unmount anything (incl. removing entry from fstab).
BTW, for fstab manipulation I am thinking about augeas-python. It does
not pull any big dependency except libxml2, still it's yet another
package needed in installer ramdisk if generic mounting is in Blivet.
Jan
11 years, 1 month
Fwd: Proposed F19 Feature: systemd features
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun 27 Jan 2013 08:54:49 AM EST, Jaroslav Reznik wrote:
> Announcing various systemd features in one announcement, see
> bellow:
>
<snip>
> = Features/SystemdHardwareDatabase =
> https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase
>
> Feature owner(s): Kay Sievers <kay at redhat dot com>
>
> The udevd service has a long history of managing kernel devices.
> Besides generating events when devices are discovered or removed it
> maintains a dynamic, stateless database of all available devices
> including meta data about them. With Fedora 19 we want to
> substantially enhance the metadata that udev keeps for each device,
> by augmenting it from a userspace database of non- essential
> information, that is indexed by device identification data such as
> PCI/USB vendor/product IDs.
>
This to me looks like it would be an excellent data source for our
hardware inventory provider. We should sync up with the systemd folks
to identify the available D-BUS interfaces to query for this information.
<snip>
> = Features/SystemdResourceControl =
> https://fedoraproject.org/wiki/Features/SystemdResourceControl
>
> Feature owner(s): Lennart Poettering <lennart at poettering dot
> net>
>
> systemd already has support for assigning specific resources to
> system services using various configuration settings. With Fedora
> 19 we'd like to build on that, and add the ability for the admin to
> dynamically query the resource control parameters and change them
> at runtime.
>
This is definitely another thing to keep an eye on. This is exactly
the sort of performance tweaking we will want to be able to accomplish
from a central location, so we should very seriously consider how best
we can control this via OpenLMI.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlEGcgIACgkQeiVVYja6o6NBNwCeLeyQ4iP/KjcbTyMfLK5ebWQu
MfUAmwb0YtgpGkS4slQxBvGllpHGTWLi
=YRhB
-----END PGP SIGNATURE-----
11 years, 2 months
ANNOUNCE: openlmi-storage 0.5.0 released
by Jan Safranek
I am pleased to write that OpenLMI Storage provider ver. 0.5.0 has just
been released.
Grab it at
https://fedorahosted.org/releases/o/p/openlmi-storage/openlmi-storage-0.5...
openlmi-storage has been rewritten from scratch. It is not backward
compatible with older releases.
It includes extensive documentation full of examples included, both for
SMI-S gurus and for common Linux administrators without any SMI-S
knowledge. Snapshot of the documentation is available at
http://jsafrane.fedorapeople.org/openlmi-storage/api/0.5.0/
While we cannot guarantee that the API won't change in future, we are
pretty confident its concept is stable and it should be only _extended_
and not _rewritten_. Still, the software is still considered for
pre-production testing and not for production use.
As part of the release, new test suite is introduced. See test/README
for details.
Jan Safranek
11 years, 2 months