Re: [Nbd] nbd-server: about adding new exports dynamically

[Wouter Verhelst <w@...112...>]

On Sat, Dec 22, 2012 at 09:34:21PM +0200, Tuomas Jorma Juhani Räsänen wrote:
> Hi
> 
> We are using NBD server in a LTSP-environment to serve terminal
> images. However, we'd like to add new images/exports dynamically, but
> currently NBD server does not support it without full restart and
> breaking all existing connections.
> 
> I've written a patch which simply re-reads all configuration files on
> SIGHUP and if there was a export which was not previously in the
> export/server array, it appends it and starts serving.

Cool!

> It does not alter any of the existing exports, it only adds new ones.
> In our environment, this is to make it safe (non-destructive) to use.
> In our environment, it is non-destructive operation, because we make
> sure that we only add new configuration fragments to
> /etc/nbd-server/conf.d and make no other configuration changes.
> However, in its current form, it is not non-destructive in general,
> because it calls parse_cfile() which in turn modifies global
> variables. In my opinion, parse_cfile() should be refactored to make
> it side-effect free.

Yes, I agree. In fact, I removed almost all global variables from
nbd-server a few years back (originally everything was stored in a
global variable, and you couldn't even serve more than one export from a
single nbd-server process), but apparently I forgot about that since and
put some back. That's a bit silly, of course.

> Do you think the SIGHUP-based reconfiguration method is viable?

It is exactly what has been on my low-priority TODO list to support. I
agree that not being able to reload configuration is a bug, but it's not
something I've had time to work on so far. However, if there were a
patch, that'd change my priorities ;-)

> If not, what would be the better alternative?
>
> Is it reasonable and acceptable to keep the reconfiguration procsess
> non-destructive?

Yes, definitely.

> I'd like to see some kind of dynamic reconfiguration feature
> implemented in NBD server. I am ready to make the effort to get this
> feature implemented correctly and to get it upstream.

As said, I've been thinking about doing this myself off and on, but it
just hasn't happened yet. The way I see it, such a reconfiguration would
need to do something like the following:

- Read the config file, make sure it is error free (if not, produce an
  error message, but continue serving as usual). This should also
  involve things that can't be changed anymore by a simple SIGHUP (e.g.,
  changing the value of the "user" or "group" global options)
- Verify all currently-existing exports, and remove the ones that are no
  longer present.
- Check all currently-existing exports, and update the settings for
  those what's in the config file isn't the same anymore compared to
  what's currently being served
- Kill any client connections which are using now-illegal options (e.g.,
  clients which are writing to an export that has just been turned into
  a read-only connection), or which are using exports that are no longer
  being exported
- Alternatively, when a client is using an export, we can refuse
  (verbosely, i.e., log something) to update the configuration for that
  export (which would probably be somewhat easier to implement).
- If we're now no longer exporting anything, log something and exit.

However, if it's somewhat more limited than that, I suppose I'll accept
it too, provided it's properly documented what the limitations are.

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.