bcfg-server/Packages should be more verbose

[m4z <[email protected]…>]

...especially in verbose mode.

When I restarted my not-daemonized 1.0.1 server after the weekend, I assumed it would have to update the packages list and that that would take a moment, but that is because I already know this procedure.

If I didn't know the software, behavior like this:

chaos:~ # bcfg2-server -dv
(...45 minutes of nothing but high memory and cpu usage...)
Packages: File read failed; falling back to file download
Packages: Updating http://firstrepo[...]
(...60 minutes more waiting...)
Packages: Updating http://secondrepo[...]
Loading experimental plugin(s): Packages
[...]

...would make me assume something is wrong and I would have (p)kill -9'ed the process after two minutes.

This would most likely be much faster on "normal" machines since this is a VM with few resources (2GHz CPU, 256MB RAM), but adding and informal message before updating the package lists shouldn't hurt at all. (Make the server a bit less of a black box (; ...)

What's probably worse, client connections during this time aren't possible:

client:~ # bcfg2 -enqv
Server failure: [Errno 8] _ssl.c:482: EOF occurred in violation of protocol
Failed to download probes from bcfg2
[Errno 8] _ssl.c:482: EOF occurred in violation of protocol
client:~ #

Wouldn't it be possible to "cache" the old version of the repodata and fetch the updates in the background, allowing clients to contact the server during this time?

[desai]

We used to serve configurations before we had the repo fully loaded, which led to all sorts of problems. Due to the way that we update the data structures, i don't think it would be robust. Also, at this point in the server, the startup is synchronous, so changing that would be dicey.

As a workaround, this operation can be performed out of line with a server restart by using bcfg2-info instead. (basically, remove the cache, start up bcfg2-info, wait however long it takes, then once that process is complete, restart bcfg2-server)