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.
Since wsgi function returns iterable, it turns out to be easy to do it this way.
For now, hardcode json dumps, two things:
1: call out to module supporting HTML and JSON interpretation
2: in both cases, a header and footer must sandwich the responses in http
In socketapi, responses will come back without a container, but http
does not afford us such luxury. Create a containing json structure.
On first iteration, do not prepend with ,. prepend with , all other times.
Since pyghmi now handles this automatically and in fact removes
the facility used to manually track this and it is much more
robust than this strategy.
