Previously, was using counters to track the relation, also had distinct tracking of users versus
callbacks. Unify the callback and user into a single 'session' attach and then use the size
of the set of sessions and their declared users rather than trying to maintain a counter on the side.
This change simplifies the relationship, changes away the logging and clientcount counter for
a more robust strategy, and paves the way for the dependent ShellHandler to terminate connected
sessions when the shell session dies.
Unlike consoles, where the underlying concept is a real
persistent thing that needs some care to reattach to watch,
a shell session should die when it is lost, as a new one would
have to be created anyway. Modify the disconnect behavior
for a shell session to set closed and notify the receivers.
It should also reap dependent watching objects in a future
change.
This causes some additional features into core. Namely
the ability to use a fixed module rather than a string
defined plugin. This allows shellserver to implement the
'plugin' interface without living in 'plugins'. 'plugins'
implies modularity and potential eventual choice, but
this functionality is core. It would make sense for the
'attributes' plugin to be changed to match this strategy.
When a shell session is initiated, it registers
a recipient at the same time it would be trying
to establish session for not being a 'wait for
recipient'. Aggressively mark the state as connecting
to avoid the recipient erroneously thinking things have
not be set into motion yet. Additionally, have the ssh
plugin avoid a traceback when disconnecting before completing
connection.
Have httpapi recognize the difference and start a shellserver
session when appropriate. Next step will be to wire up enumeration of
current shellserver sessions, debug ssh.py traceback, delete on remote
close, and auto-delete when no client connected after some interval (e.g.
30 minutes).
UUIDs when a simple number will do are harder to use.
Change to a simple increment id. This could cause an issue
with multiple management nodes, but I think the sessions
should be contained to the instance used.
console logging assumptions are not valid for shell sessions.
Correct by modifying the buffer init code to be conditional
and adding a stub 'log' to the ShellHandler class.
Provide a common 'shellserver' capability cloned off of 'consoleserver'.
This will enable the concept of per-user shells with option for multiple
shells per. Each user will have their own set of shell sessions rather
than shared across users. Can revisit in future if sharing between
users is desired.
Create a module that does ssh and treats it like
a console. The plan is to have a cliserver.py to
behave in a manner resembling consoleserver.py, but
with option to have multiple distinct sessions per
target.
If confluent gets stuck, provide a debug facility
to sample where it is stuck. Sending confluent
SIGUSR1 will now cause /var/log/confluent/hangtraces
to get written to.
The console API had a 'wait_for_data' which will never be used.
Also change __init__() so that it can be called via super() to
allow working around IDE complaints.
While the client can handle it now, have the server
avoid needless processing of '' data from a console
provider. Address it at the deepest level (the
tlvdata implementation) and a place higher up the stack
to avoid hits to log and such.
Rather than manually curate the VERSION, use git tags
and auto-create intermediate builds with unique identifiers.
Identify both number of commits to indicate order and the git
short rev to see which rev matches.
When attribute notification is requested, node deletion was not
sent to the watchers. Address the limitation by notifying on all
attributes for a deleted node.
When a rollover event was detected, the offset
of the rollover event itself was being read
from the rolled file erroneously. Skip to
next loop iteration so that the metadata about
the rollover event is properly ignored in building
the text data buffer.
The log format for other pieces of data is JSON.
Change the rollover event to be consistent. Also
do not record the previous name of the log file,
as that isn't used, and the current filename is
likely to change when it too gets rolled over
so there's no practical use of knowing the
no longer valid name for the transaction.
Under windows, we can't use flock. However we can
get locking using msvcrt using different, but related
semantics. Imitate whole file locking by just locking
first byte. We have to make sure we seek() to the same
place when locking and unlocking, as Windows requires
the offset to be same for both operations.
Add TimedAndSizeRotatingFileHandler which mixes together
the RotatingFileHandler and TimedRotatingFileHandler from
python logging module to process the log data.
Add logrollover event to track the renamed information, so
that console session can read the log data from current log
file and last renamed file.
Global configuration is used by the log handler. The format
of the log section in '/etc/confluent/service.cfg' is like:
[log]
when = m
backup_count = 3
max_bytes = 8192
utc = False
The two files should be identical. confluentsrv.py exists
only because PyInstaller struggles unless the target is a
'py' file and does not have some namespace conflict with a
module.
