Reload configuration without restarting fabio by SIGHUP or by flag.

[ketchoop]

Very common and useful feature. And it allows, for example, use docker kill -s SIGHUP fabio instead of restart the container. I know, that fabio starts very fast, but, I think, zero downtime is the main goal of fabio:)

[magiconair]

This isn't a simple change since the configuration that is served via the config file is usually the static configuration like headers and listener config. However, I'm curious why you would want to do this in the first place? fabio is zero-conf in respect of the services. All service changes are handled without restart and loss of existing connections. We ran fabio for months without restarting it.

What is it that you want to change on a regular basis that requires a fabio restart?

[ketchoop]

If it's hard to implement this then I think it's not really important. But a couple of times I needed to change certificate stores and pathes to certs in vault and had a little downtime.

[magiconair]

This isn't impossible but not a trivial change and I'd like to see more concrete examples of where this is really a recurring production issue. For the case of cert stores I might be able to handle this in a different way.

I'm going to close this one but I'm open for additional suggestions and may re-open at a later point.

[TheMerinoWolf]

@magiconair I'd definitely be in favor of this functionality. I'm currently working towards securing my entire infrastructure with end to end TLS. I use Vault's PKI backend to generate an x509 server certificate for Fabio itself.

The server certificate is used for:

• Fabio routing to itself (UI)
• Consul health checks against Fabio

This certificate has a short TTL of 30 days, so it gets rotated at the mid-way point (15 days). When this certificate does rotate, we need Fabio to start using it. The typical pattern here would be to send a SIGHUP (Vault itself follows this pattern). Currently, we're sending a full restart to Fabio on a rotation (and doing this restart in a highly-available manner introduces additional complexities).

[magiconair]

@SoMuchToGrok so in essence you want to refresh a cert after 50% of its TTL, right? Cert stores already provide a mechanism to reload certs on the fly. I could make that logic more flexible. What I'd like to avoid is to provide the sense of reloadable config in general since so far I'd like to see some more examples of where this is necessary.

[TheMerinoWolf]

Yeah, precisely. I definitely understand your rationale around general config reloading.

I can open another issue to get discussion going around this specific use-case. Any objections?

[magiconair]

@SoMuchToGrok please :)