Hello all, I've talked to David Lehman (Blivet devel) how OpenLMI can report various storage events to applications. Currently, Blivet does not consume any events from udev and it would be rather difficult to implement it - Blivet is a library and receiving events means it must have some sort of listening thread with a main loop. 1: http://pyudev.readthedocs.org/en/latest/ So, what events OpenLMI wants to report to applications (and what info it wants) [source of the event]: - device appeared/disappeared [udev] - device was changed (*what* changed - e.g. size, fs on it, RAID level, ...) [udev] - mount appeared/disappeared [/proc/mounts] - mount changed (list of changed options) [/proc/mounts] - RAID events - man mdamd, look for "MONITOR MODE". There might be netlink/inotify/dbus events for that. - LVM events (snapshot/thin LV/VG is running out of space; with configurable threshold) [none at the moment] As written on [2], select or poll on /proc/mounts or /proc/self/mountinfo can be used to get mounting events. 2: http://karelzak.blogspot.cz/2011/12/monitor-list-of-currently-mounted.html Question is, how Blivet and OpenLMI cooperate to generate these events. Option 1: OpenLMI listens for udev and mount and mdadm events (in C, not in Python). When an event occurs, it re-creates Blivet's device tree and compares old and new trees manually on its own. Benefit of this solution is that Blivet (Python) does not need to be in memory for the whole time. This would require some wrapping between CIMOM and OpenLMI, but I think that's doable. Option 2: OpenLMI tells Blivet to wait for events. When event occurs, Blivet calls OpenLMI callback. Add/remove events are simple, just tell OpenLMI what appeared/disappeared. Changes are more complex, but IMHO it might be enough to call the callback with old StorageDevice and new StorageDevice and we'll check what's changed. This solution can be used by more applications on top of Blivet, but it requires Blivet to run a main loop in a thread and be in memory for the whole time. Option 1.5: OpenLMI listens for the udev, mount and mdadm events (in C, not in Python), but passes them in some 'raw' form to Blivet. Blivet then check what's going on and calls OpenLMI callback as in Option 2. We don't need to have Blivet in memory for the whole time, but we need it to be possible to store Blivet state to a file and reload it when requested. Of course, we expect incremental development, let's start with udev first and gradually integrate all other sources of events. I personally vote for option 2, not because it's more work for Blivet and less for OpenLMI, but if Blivet is going to be generic storage library, this is one of core functionality. If option 2 show too resource-heavy, we might try to go for 1.5. Jan _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
