The ipmi plugin, at least, is not yet quite right. Need to
continue debugging having a console session open, then changing
the bmc to a bad address, then changing it back. I fixed some of
the easier exceptions, but it is clearly still getting quite confused
to the point where 3 or 4 cycles guarantees the console can not easily heal.
The strategy was going to allow for a distinct IPMI account for automation
from other protocols. However, this is pretty complicated to explain to
people. The thought before was that the HTTPS/SSH type access could use
a passphrase that is easy to remember whilst ipmi accounts would tend
to be randomized. Instead, have the software managed authentication
info be used across all protocols and avail endpoint of user management
to add human-friendly accounts if needed (disabling IPMI/SNMP by default
in such cases).
Previously, the state would be seen as 'connected' and then 'disconnected' in event of
connection failing. Rework things such that the console session stays in 'connecting' state
until timeout or success occurs and don't send disconnect, instead raising an exception.
This makes the connection action a bit more intuitive to the user, who would assume a 'connected'
console means the endpoint was reachable. This may not always be possible in a console plugin,
but it's a nice pattern when possible. If a console plugin cannot tell when 'connected' happens, then
the previous behavior of this plugin makes sense as a 'best effort': return 'connected', send
disconnect event when the console turns out to be bad. For example, executable consoles are most
likely going to follow this pattern. An option could be for an executable to have a certain
signature to print to show 'connected' though...
Also, remove a required function from console interface. Now a plugin
is only responsible for their thread behavior and never responsible
for the consoleserver mechanism requirement for helping user session
do polling IO. This is additionally great because it means the
coordination is contained to each session object and many client connections
are not causing multiple calls to iterate the wait loop.
When data was coming in during logon, it was possible for
the handler to be called before rcpts member was initialized.
Correct by initializing rcpts prior to taking any other action.
If circumstances inside pyghmi cause it to be looping in
an event loop, confluent was getting work done, but
the code to wake up the eventlet greenthreads wouldn't get tickled.
Address this by also waking up waiters in the function that is
invited to the pyghmi event loop party.
Previously, one ipmi failure would tank all consoles and commands.
Now, at least console failures are isolated.
Next stop is to isolate command failures, then fix up session recovery.
