facts RE uptime with virtual chassis where RE fpc number > 1

The facts output includes RE0 and RE1 which are really intended for cases when the device has dual routing engines in a single chassis. This does not play well with a virtual chassis stack when the routing engines are in fpc positions greater than either 0 or 1.

This came about because I wanted to obtain the uptime for a routing engine in the stack. The uptime is included the RE dicts when they are available in RE0 and RE1. re_info['default'] contains all the same information except for uptime. I would like to have uptime added to the RE dicts in re_info to solve this issue.

[stacywsmith]

uptime was intentionally excluded from the new re_info fact because it’s not really a “fact”. I consider “facts” to be read-only information which maintains the same value for the life of the PyEZ connection to the device. However, the value of uptime obviously changes over time. Even worse, the uptime value would always be the time at which the re_info, RE0, or RE1 fact was retrieved, rather than the current uptime.

Of course, this is true in the older RE0 and RE1 facts as well, but the decision was made to maintain the current behavior of those facts for backward compatibility.

It’s also worth noting that on-demand fact gathering makes things slightly less predictable. Previously, all facts were gathered when open() was invoked, or when facts_refresh() was invoked. Now, each fact is generally gathered the first time it’s value is accessed. However, multiple facts might be derived from the same RPC, or one fact might be dependent upon another fact. In those cases, the fact is gathered the first time a dependent fact, or a fact derived from the same RPC, is gathered.

I would certainly be supportive of adding an uptime() Device method which always executes a fresh RPC to return the current uptime for all Routing Engines.

Would an uptime() method meet your requirement?

[stacywsmith]

@lampwins Our team has already been discussing the need for a predictable patch release schedule. To date, PyEZ has not had a predictable schedule for patch releases. We have agreed internally that we will begin publishing patch releases on (at least) a monthly basis and publish new patch releases on or before the last day of the month. So, this minor enhancement will be part of 2.1.5 and will be published on or before 31 July 2017.