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.
Previously, if a username or password was bad, retry would not occur.
Correct this such that every so often or right when someone connects,
the target is checked to see if the user/password is now considered good.
Previously, it would register 2**x attribute watchers by mistake. Exponential
growth of threads trying to talk to one BMC is evidently a bad thing. Fix
this by correctly tracking and cancelling previous attribute watchers.
Additionally, mask a harmless exception brought on by the death of orphaned
pyghmi console objects by having them yell into the endless void rather
than trip on an exception.
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...
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.
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'.
For one, prevent unknown attributes from getting into configmanager from now on.
Additionally, have the attributes plugin manage to convey bad attributes when
encountered.
When doing a set, check the keynames and value types as
appropriate. raise ValueError in the configmanager case
since it could be code or human mistake. attributes plugin
then catches this error and propogates it up as an InvalidArgumentException
if it is just trying to pass in data from user.
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.
