Since the log analysis merely needs to know if a connect/disconnect is redundant,
only report 0, 1, or '2' connections to indicate 2 or greater. log analysis
then would want to seek out a connect with eventdata of '1' and disconnect with
eventdata of '0' and mostly ignore the '2' info. Desire for more data
could be done by actually counting the connects and disconnects, this is
just to provide a fast path to finding the 'first connection' and 'last disconnect'
signatures.
For a log reviewer tool to unambiguously understand whether a given user is conceivably watching,
more data is needed. It doesn't keep track of which disconnect goes with which connection, but
it at least provides a way of detecting whether user is truly disconnected or not.
Implement the bits and pieces that are at least required for conserver like logging.
This has a plaintext file and a binary metadata file. The plaintext file basically
resembles a conserver log, while the binary file facilitates faster seeking to points
of interest with the file and much more precise timestamp information.
'nodepower' is not yet 'rpower' like, but it's a quick
demonstration of using the python confluent client library. It
only supports unix socket as written
The pickling would get horrendously slow as total node count increased. This meant very long time to sync
to disk for just one change out of 65,000. This strategy changes things to more selective and only
do things for the dirty keys rather than everything. Large changes to small amounts of nodes will take
more time (because more calls to dump pickle), but small changes to a small subset of nodes will take much
less time.
There was an optimization to skip examination of groups if it was determined
that the group membership had not changed. However, this erroneously
masked the examination in the case of reordered groups. Skip the
optimization to cover that case at the expense of at least some needless churn.
This only happens when something goes to change group membership in some way, so
this shouldn't be too expensive.
Now when expressions can not be completed, the reason is presented as 'broken'.
Additionally, when unsetting a value that would affect expressions,
perform appropriate changes.
If data was coming in as unicode strings (as is the case in the json
parser), it failed to treat the data as equivalent to string. Correct
by checking both str and unicode for now
A client with certain URLs that go off the end of the valid world was
causing exceptions to be thrown not of the set of 'tame' errors.
Denote them as 404 since that is the nature of the failure.
Provide a means to clear node specific settings so that inheritance can be restored.
In JSON, send a null as a value for a parameter instead of a string or 'object'.
After set, confetty client would fail to follow protocol and
end up leaving followup commands in an off by one state. One
TODO out of this is to refactor send_request into a library function
While typing in confetty console in blind test and confetty was using a TLS socket,
the confetty console was noticably chunkier. The chunkiness could not be detected
on a UNIX socket. Setting NODELAY on both sides of the socket seems to have eliminated
chunkiness so that at least I can't tell confetty from ssh+ipmitool anymore.
For one, prevent unknown attributes from getting into configmanager from now on.
Additionally, have the attributes plugin manage to convey bad attributes when
encountered.
