Hi William,
On Tue, Oct 13, 2020 at 04:10:35PM +0200, William Dauchy wrote:
> Hi William, Willy,
>
> On Wed, Oct 7, 2020 at 5:02 PM William Dauchy <w.dau...@criteo.com> wrote:
> > adding some more thoughts we discussed internally with Pierre:
> > - we started to use `show servers state`, as it was the only way to
> > get the current config for the parameters we wanted to change with the
> > existing runtime API.
> > - even if it was not necessarily designed for that purpose, we need a
> > way to get the current config.
> > - we understood `show servers state` was more likely designed for
> > internal usage, especially for `load-server-state-from-file`, so that
> > my patch set has some implications.
> >
> > That being said, would it more acceptable to add a new API which which
> > reflects all the `set` commands such as:
> > - show server [<backend>/<server>]
> > would display all the config of a given server or all of them
> > - show server <backend>/<server> agent
> > - show server <backend>/<server> state
> > - show server <backend>/<server> weight
> > etc
> > and for my first proposition:
> > - show server ssl [<backend>/<server>]
> > - set server ssl [<backend>/<server>] on/off
> >
> > for our immediate usage around ssl we are also thinking about ca_file,
> > crt, crt-file.
> >
> > This also would be a good answer to simplify how it is managed through
> > the current dataplane API
> > https://www.haproxy.com/documentation/dataplaneapi/latest/#operation/createServer
> >
> > What are your thoughts about it?
>
> any thoughts about this proposition?
We've discussed about some of these points last week with William.
I think at some point it would be useful to have a discussion on
these. I'm personally in favor of being able to configure more
things dynamically, I also know that server-state files tend to be
abused to store configuration parameters instead of just pure server
states, but overall based on what is needed, we could possibly
rethink the whole thing, to have for example:
- servers fed from a dedicated, easily parsable/updatable file
- ssl optionally pre-configured to allow easy on/off at run time
- better detection of changed parameters across reloads (currently
the server-state file doesn't hold the config values, so that there
are quite a number of ambigous cases on reload).
And clearly I'd rather go back to the white board based on a clearly
defined set of requirements and use cases than add more hacks on top
of something that was not initially designed for this. For sure some
parts are still extensible (e.g. I don't see anything preventing from
preloading SSL contexts into servers at boot time), but that still
leaves us with server-state, templates etc and maybe we can do better,
simpler, with less impact for everyone.
We should probably have a live discussion between at least the 3 of us,
maybe a few more if that helps, and define how to go into that direction.
What do you think ?
Thanks,
Willy
