[bind10-dev] data source reconfiguration with shmem

[Michal 'vorner' Vaner]

Hello

On Thu, Jun 27, 2013 at 05:59:35PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> But there has been a discussion on the basic approach.  See, e.g,
> the end of https://bind10.isc.org/ticket/2854#comment:13
> I don't necessarily insist on the idea of config generation IDs, but I
> also doubt there's an easy way out.  So we should spend some more time
> for designing it before we actually start working on it.  I don't have
> a specific suggestion beyond the initial proposal, but I'm sending
> this to trigger the discussion.

As I mentioned, I think the generations have either one major problem:
• It would be showed to user to tweak and damage, confusing and fragile.
• It would be extension to our configuration system. It would be large change
  there, a lot of work.

I think we can come up with something both simple and working. The goal is to
ensure that the config used by the manager is the same as the config used by the
auth server. So here is one proposal:

• When auth server is configured, it computes a hash of the datastore
  configuration (let's say sha1). It sends a message „I now have this SHA1“ to the
  manager. The manager then either already has the same configuration loaded,
  then it immediately sends update message to the auth with the right
  information about the segments. If not, it does nothing.
• When the manager gets new configuration, it prepares the segments, computes
  the sha1 too and sends the sha1 with the update information.
• When the auth receives the update message, it checks if the sha1 matches. If
  not, it is for a different version and either it'll get the configuration and
  ask for it (because manager was first) or manager will yet send it (because auth
  has newer configuration). If it matches, it uses it.

So, it is similar to the generations, but it is based on the content, not on the
history. We don't get the comparison what is newer and what is older, but I
don't think we need that, we need to only match if it's the corresponding
config. After all, it will be, most of the time, only at the short time around
the update.

And I also think it is harder to break the think (it has auto-cure properties if
something breaks, new update just fixes it) and simpler to implement than
hacking through the whole configuration system.

With regards

-- 
Why TODO list in haskell? It handles infinite data structures.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130628/80f42c6c/attachment.bin>