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

Vratislav Podzimek vpodzime at redhat.com
Fri Sep 12 06:38:28 UTC 2014


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.

-- 
Vratislav Podzimek

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



More information about the anaconda-patches mailing list