If a bg sync thread is in progress, a key could be marked dirty before the desired change is actually made.
This causes the running thread to pick up the change to 'dirty' keys and save off the as-yet unchanged key.
Reorganize things to have the keys marked dirty only after they have been assigned so that an in-progress
commit to disk only picks up a key after the relevant values have changed.
Previously, the null tenant always synced to disk on every request in pracitice.
Correct that mistake to avoid commit to disk when no changes are being made.
ssl wrap prior to accept causes accept() to be too complicated to stay in the
persistent thread and makes key changes require restart to pickup. Call
the wrap_socket within the dedicated client thread so that it gets up to date
at the right time and picks up certificate changes in a timely fashion.
Some clients have their lives made more convenient by having the
sha512 hash rather than the actual certificate. Prepend with 'sha512$'
to allow for a future where different formats could be specified.
There is no hard guarantee that all 4 bytes will come. In practice,
I've never seen this occur, but to be complete, should make sure recv gets everything it was supposed to.
It turns out that eventlet.green.threading.Event() doesn't behave very efficiently in this context for whatever reason.
Use eventlet.event.Event() instead. It was not used before due to lack of timeout and clear, but that is overcome by
disposing of it rather than reusing and using with eventlet.Timeout() to add timeout to wait that doesn't have built in timeout.
If wanting to run as non-root, mkdir -p /var/run/confluent /var/log/confluent /etc/confluent
and chown those to be owned by confluent user. That is probably path for deb and rpm packaging.
When any reconfiguration happens, break a command object (and the session that lies beneath).
This does cause needless churn in response to some changes that wouldn't matter, but it's a
small price to pay for the simplicity of not bothering to be fancier.
For now, the only live path is the one that
gets struck by exception. However, the exception
only happens on 'strip_node', meaning for
multi-node resources, things should be sane when
the time comes.
Previously, was pulling the cord on a perfectly servicable IPMI
session object. Change to just deactivating the SOL portion
of an IPMI connection if the console closes.
With this change, an instance under pressure from new or bad authentication attempts
will continue to be viable to authenticated sessions and clients with tokens (e.g. any
http client that honors cookies).
