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

Vratislav Podzimek vpodzime at redhat.com
Fri Aug 29 07:30:16 UTC 2014


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.

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.

-- 
Vratislav Podzimek

Anaconda Rider | RHCE | Red Hat, Inc. | Brno - Czech Republic




More information about the anaconda-patches mailing list