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

David Lehman dlehman at redhat.com
Fri Sep 12 00:48:59 UTC 2014


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.

David

>
> A hybrid solution now is to have a CallbacksRegister instance a part of
> Blivet instance, add the bottom-up references as described above and
> pull and invoke the callbacks that way. However, that's more complicated
> than the solution proposed in this patch, it would require some locking
> mechanism for setting and getting callbacks and probably something
> more.
>
> Another hybrid solution is to have the actions' callbacks implemented
> the way they're described in this patch and then have a messageQ for
> asynchronous events that are asynchronous even from the blivet's
> perspective.
>
>>
>> I think that if the callbacks module does continue to exists in its
>> current form, methods to construct each of the *Data objects
>> should be provided, on the same principle as a method for
>> constructing the _CallbacksRegister object is already provided.
> I don't see a reason for that as the *Data objects are only constructed
> in blivet code where we control their implementation as well. Being
> namedtuple instances, they are read-only, just provide well-defined sets
> of fields and have a nice __str__ method. That's the API we would need
> to stick to, but that's what we want and need anyway.
>



More information about the anaconda-patches mailing list