[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, Dec 23, 2012 at 03:30:36PM -0500, Michael Richardson wrote:
> >>>>> "nen" == nen  <Tuomas> writes:
>     nen> We are using NBD server in a LTSP-environment to serve terminal
>     nen> images. However, we'd like to add new images/exports dynamically, but
>     nen> currently NBD server does not support it without full restart and
>     nen> breaking all existing connections.
> 
> Yes, we had that problem too.
> 
>     nen> I've written a patch which simply re-reads all configuration files on
>     nen> SIGHUP and if there was a export which was not previously in the
>     nen> export/server array, it appends it and starts serving. It does not
>     nen> alter any of the existing exports, it only adds new ones. In our
>     nen> environment, this is to make it safe (non-destructive) to use. In our
>     nen> environment, it is non-destructive operation, because we make sure
>     nen> that we only add new configuration fragments to /etc/nbd-server/conf.d
>     nen> and make no other configuration changes. However, in its current form,
>     nen> it is not non-destructive in general, because it calls parse_cfile()
>     nen> which in turn modifies global variables. In my opinion, parse_cfile()
>     nen> should be refactored to make it side-effect free.
> 
> What I did was have our incremental script just start another nbd-server
> instance with a specific config file from the conf.d itself...
> 
>     nen> Do you think the SIGHUP-based reconfiguration method is viable? If
>     nen> not, what would be the better alternative?
> 
> I would like to have this kind of thing, but also think that perhaps the
> parent server should/could be replaced with:
>        for cfg in /etc/nbd-server/conf.d/*
>        do
> 		nbd-server ..options..
>        done

That only works for old-style exports (i.e., not the name-based ones),
since you can't have multiple processes listen on the same port (at
least not without significant effort, which would be much more difficult
than just writing proper SIGHUP handling).

Since I wish to deprecate old-style exports (and eventually, some years
into the future, remove support for them altogether), that's not
something I want to see as a long-term solution ;-)

-- 
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.



Reply to: