[blivet][master/rhel7-branch][PATCH] Allow user code provide callbacks for various actions/events

David Lehman dlehman at redhat.com
Mon Sep 15 16:42:21 UTC 2014

On 09/12/2014 01:38 AM, Vratislav Podzimek wrote:
> On Thu, 2014-09-11 at 19:48 -0500, David Lehman wrote:
>> On 08/29/2014 02:30 AM, Vratislav Podzimek wrote:
>>> On Thu, 2014-08-28 at 10:09 -0400, Anne Mulhern wrote:
>>>> Getting rid of another of blivet's dependencies on anaconda is good, but..
>>>> The device here of the callbacks simply replacing the progress
>>>> report context manager seems questionable. It seems
>>>> like what is needed here is some kind of message queue which
>>>> clients can listen to if they want to.
>>>> That blivet should have a callback mechanism seems quite correct.
>>>> But I'm dubious about the idea of passing the _CallbacksRegister
>>>> object around among a lot of different methods instead of actually
>>>> registering the callback somehow on an appropriate object.
>>> I think the big question is what next we plan to do with callbacks. If
>>> they are only going to be used for things related to actions, I think
>>> it's not an issue to pass them through two methods to those actions
>>> (where are the "lot of different methods" you are refering to?). It's
>>> not at all complicated, it's very clean and without any overhead.
>>> On the other hand, if we want to use such callbacks for something else
>>> in the future (udev events translated into something sane?), we should
>>> probably have a message bus as a blivet.Blivet's attribute so that the
>>> user code can listen on that bus and react on events. However, that
>>> would require adding bottom-up references to our objects
>>> (action->devicetree->blivet.messageQ), adding a messageQ with some
>>> mechanism of processing unconsumed messages or some other event
>>> mechanism, adding a thread on the user code's side for listening on the
>>> queue and many other things.
>> Some sort of uevent callback is in our near future. What I have in my
>> working tree is very simple and explicit, so it could probably benefit
>> from a general mechanism like this. I haven't thought about how this
>> would relate to your patches, but I wanted to put it out there.
> I think that uevent should/could use a different mechanism, because
> those events are real asynchronous events whereas the callback mechanism
> proposed here is for callbacks/hooks invoked in a known place, defined
> order and they are guaranteed to be invoked given the list of actions.
> So my opinion is that we should go for now with these callbacks and come
> with a message bus for uevents later.

I'm okay with that. This set looks good to me for the intended purpose.


More information about the anaconda-patches mailing list