On 06/12/2015 08:00 PM, Gris Ge wrote:
On Fri, Jun 12, 2015 at 02:59:34PM -0500, Tony Asleson wrote:
On 06/12/2015 12:20 AM, Gris Ge wrote:
It seems (19)Relocating is not RAID reconstructing. Do you see any vendor use that value to indicate reconstructing?
No, but we have gotten very little from vendors on health status, especially with regards to SMI-S.
In DMTF definition, "Dormant" indicates that the element is inactive or quiesced. I think it means STATUS_STOPPED. I'd better remove that one, and add it back until I see real implementation.
We can add, but we cannot remove constants.
So your suggest: pros): 1. Leave enough space for future expansion. cros): 1. No plugin implemented multi-bits status.
We could easily add multi-bit to our existing plug-ins, there is nothing special required from the array except a mechanism to indicate something we can interpret as a status and for us to interpret and set as documented.
2. All multi-bits status could be use single bit status like I mentioned in 'Summery' section of previous email.
Yes, I'm not disagreeing with that.
3. User have to check multiple bits to make sure everything is OK. Every time we add an additional bit, user code has to add one more check.
Please elaborate on how adding a new enumerated error type doesn't require the client to be modified to interpret the value?
For some user, data accessible is not enough to be OK.
You advocate that adding a bit is more problematic than adding an enumerated value. To me this isn't an error code where the operations was successful, else it is in error with the error reason, it's a status. If we add a new enumerated status code, lets call it STATUS_CONFRAZZLED, is that bad or good? What does an existing client do if a newer plug-in returns it? I could see a client written with a switch statement and this falling into the default which would likely be report at highest error level.
I was thinking that if we used the STATUS_OK or STATUS_ERROR bit and sub qualified it with other bits, it would at least convey to any client that things are generally OK or NOT.
Ultimately in this case we can go either way. If others don't see the benefit of having the multiple bits we can document them as being unique error values while retaining the existing numerical values. Current plug-ins aren't using mult-bit. If we do this we should also change the documentation on all the other status fields too, to make it consistent.
Regards, Tony