CTDB ipreallocated event handling

Martin Schwenke martin at meltin.net
Wed Jul 12 02:40:56 UTC 2017


Hi Björn

On Tue, 11 Jul 2017 16:29:49 +0200, Bjoern Baumbach <bb at sernet.de>
wrote:

> I would like to understand the handling and the of the ipreallocated
> event and the things connected with it. I've a few notes and questions.
> 
> According to the README in the events.d folder, the event is triggered
> after "releaseip", "takeip" and "updateip" events.
> But at the end of the file I read the following:
> 
> * The "ipreallocated" event is run on all nodes.  It is even run if no
>   "takeip", "releaseip" or "updateip" events were triggered.
> 
> This sounds for me, that one of the statements is not correct :-)
> 
> As far as I can see, the event is triggered every time, when the ip
> address allocation could have been changed - and this is nice. We should
> specify the exact behaviour in the 'ipreallocated' passage.

Right, the documentation is unclear. Patch attached to try to fix
that.  :-)

> The next issue is the usage of the service_reconfigure() function in the
> event scripts.
> According to the README, "an explicit ipreallocated event handler is
> usually not necessary", because the service_reconfigure() function "will
> be implicitly run before the ipreallocated event".
> 
> Who does call the service_reconfigure() function and why this is done
> before the ipreallocated event?
> 
> The 60.nfs event script has a ipreallocated handler which calls the
> ctdb_service_reconfigure() function explicitly. Is this fine? Wouldn't
> this call service_reconfigure() twice? The first time by the magic call
> before the ipreallocated event and the second with the ipreallocated
> event? Or is the ipreallocated event ignored, because the first magic
> call un-sets the "need reconfigure"-flag?
> 
> I would be glad if you can help me to clarify this :-)

The documentation was out of date.

When I was young and foolish (yes, last week... or perhaps last year) I
believed in having a lot of implicit magic to do things
automatically... and obfuscate the code.  So I added a lot of
features so I could write less, but more confusing, code... ;-)

We used to have a magic function service_check_reconfigure() that was
called in the boiler-plate before the case statement in each event
script. That function would check if the event was "ipreallocated" and
if ctdb_service_needs_reconfigure() was true.  If so, it would run
ctdb_service_reconfigure(), which runs service_reconfigure() - yes, 2
different functions!

Now that service_check_reconfigure() is gone, we check
ctdb_service_needs_reconfigure() explicitly in the "ipreallocated" event and run ctdb_service_reconfigure(), which we still have because
it does a bit of magic that we don't quite want to get rid of without
thinking carefully.

All of this will change quite a bit if we get through the grand
redesign/reimplementation that I outlined in my SambaXP talk this
year...

peace & happiness,
martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ctdb-docs-Update-documentation-of-ipreallocated-even.patch
Type: text/x-patch
Size: 2843 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170712/c42ec04a/0001-ctdb-docs-Update-documentation-of-ipreallocated-even.bin>


More information about the samba-technical mailing list