Some things on update are active immediately, others are pending reboot.
Documentation needs to use this to let users know what they need to do
or not need to do after the firmware update.
Lay groundwork for pulling this sort of data in on discovery. The plan is that *if* serial numbers will
be used as a cue for discovery, it would be in the context of a nodediscover command.
Often times, a pyghmi update carries the substance of
a patch. Instead of a person having to remember to
manually restart, try to trigger an update to restart
confluent automatically.
If a node is deleted, act similar to if it were defined with no console.method, to avoid
superfluous trace output. In the future, it may make sense to filter out nodes with no
console.method earlier, since a fair amount of startup work is done that is ultimately ignored
for situations where console is not enabled.
The data length of a log entry must not exceed 65k. If an attempt is
made to log that much, break it up and duplicate the records. It may make
sense to indicate a continuation explicitly, but for now just extend.
str will tend to present a more normal looking error string. Use
that so that a user does not have the impression there is a code
issue on expected errors.
The bay number can be opportunisticly grabbed, provide
that info in the discovery api. In future, should add 'by-bay'
once we have enclosure data as well.
The data length of a log entry must not exceed 65k. If an attempt is
made to log that much, break it up and duplicate the records. It may make
sense to indicate a continuation explicitly, but for now just extend.
If an administrator clears the cert fingerprint, they will
likely set it to ''. In such a case, go down the 'no fingerprint'
path rather than reject it.
enclosure.bay is integer rather than string now. Fix the filter
to use format, which is more robust in numeric versus string anyway.
Also, consistently make the underlying data integer rather than
sometimes string.
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.
Jarrod Johnson