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