Sometimes in a likely mismatched IP situation, some SLP things will manage to reply and slow
down. For now in the case of mismatched IPv4 being likely, provide a mode fixated on link local.
Provide a different scheme that does not involve a wait(), if by chance
the flow dies without getting back to our thread. wait() has no timeout
so this is a strategy to cope by making sure we hang for no longer than
3 minutes, which is well beyond any time a login should possibly take.
While it may not have been possible in eventlet for this to happen,
strictly speaking if it were a thread, it could exit during check for
liveness and leave data on the queue.
To be careful, also drain the queue after all children dead.
Provide a more concrete measurement of
children, rather than relying upon a
sentinel value on the queue. It seems
that even using 'finally' didn't assure
that we always get that sentinel value
before a worker dies. Sentinel value
still used to avoid a long wait in the
usual case.
If something went completely off the rails, it could easily fill up lots of memory with log entries in the 2 seconds it
would buffer. For now disable the buffering on key debug logs, as the main purpose was reducing IOPs in the per-node
console logs anyway. A future behavior may be to also limit the size and/or number of outstanding log entries before
committing to disk.
Most of the time, we don't need this pool. Create when needed,
and clean up after 30 seconds of inactivity. This avoids a slow
shutdown that was due to core python hanging in help_finish_stuff,
and as a bonus means most of the time, one only sees one confluent
process, which has been a source of questions already.
A redacted dump will not have a keys.json file, which
is natural. Replace 'file not found' with a message
indicating the possibility of a redacted dump.
Wait until the object is logged in before trying to set
the key handler. It carries some prerequisite on talking
to the BMC, so it is better handled in the logged handler.
If a socket error occurred that wasn't -2, the client would get an error
about KeyError, which wouldn't be helpful. raise the unhandled exception
to provide more informative data in case of an issue.
This has no functional difference, just a cosmetic
difference that does not give the erroneous impression
a logout actually occurred. This does mean that if a browser
disables cookies and uses the api explorer, there would
be an opportunity for a CSRF.
At some expense of convenience, make it difficult
for CSRF to succeed even against the API explorer
for most people. User/Password will now only be
accepted on hitting enter in the address bar rather
than following any link.
Jarrod Johnson
Allen Lin37