[psu_base] get_status_led() returns current state of the status LED

[jleveque]

• Also add the same function to fan_base.py.

[kannankvs]

get_status_led in fan.py - Comment says "PSU"; pls change to FAN.

[kannankvs]

In psu.py, please add AMBER in the color list.
Also, is it better to rename those variables " STATUS_LED_COLOR_GREEN" as "PSU_STATUS_LED_COLOR_GREEN". This way,we can keep separate variables for FAN LEDs and separate variables for front panel LEDs. For example, in case of front panel LEDs, blue color is also valid, which is invalid in case of power LEDs.

[kannankvs]

psu.py: In addition to returning color, shall we return the "flashing" status also? We think that most of the vendors support "flashing" status also which can hold "Solid" or "Blinking" values. If yes, lets change the return value as tuple instead of simple string.

[jleveque]

In psu.py, please add AMBER in the color list.

Added STATUS_LED_COLOR_AMBER to both psu_base and fan_base.

Also, is it better to rename those variables " STATUS_LED_COLOR_GREEN" as "PSU_STATUS_LED_COLOR_GREEN". This way,we can keep separate variables for FAN LEDs and separate variables for front panel LEDs. For example, in case of front panel LEDs, blue color is also valid, which is invalid in case of power LEDs.

I feel this is unnecessary since these are class members. They need to be accessed by referencing the class (e.g., this.STATUS_LED_COLOR_GREEN, my_fan.STATUS_LED_COLOR_GREEN, etc.). I feel it is better to cover all bases, so each list should contain all possibilities. We may also want to just make one list and share it among all device classes which can control LEDs.

psu.py: In addition to returning color, shall we return the "flashing" status also? We think that most of the vendors support "flashing" status also which can hold "Solid" or "Blinking" values. If yes, lets change the return value as tuple instead of simple string.

We could go the tuple route, or we could simply add new "colors," e.g., STATUS_LED_COLOR_GREEN_SOLID, STATUS_LED_COLOR_GREEN_FLASHING. If we decide it's better to go the tuple route, I would ask if it makes sense to add a flashing rate parameter to specify the frequency with which it should flash?

[kannankvs]

'''Joe:I would ask if it makes sense to add a flashing rate parameter to specify the frequency with which it should flash?'''
Flashing rate may not be important for the caller.

[jleveque]

@kannankvs: Do you have an opinion on the tuple vs. new "colors" approach I proposed above?

[kannankvs]

Joe: @kannankvs: Do you have an opinion on the tuple vs. new "colors" approach I proposed above?
Tuple is better. Even there is a need to add one or two new colors to the colors_list or if there is a need to add one other flashing status in future, it will be easier if we use "tuple". In general, we always prefer two different information in two different variables instead of combining them in a single variable.

[jleveque]

@kannankvs: Understood. Then I must ask, do you think it's better to denote "off" as a "color" as it is now, or as a state (e.g., STATUS_LED_STATE_OFF, STATUS_LED_STATE_ON_SOLID, STATUS_LED_STATE_ON_FLASHING)?

[kannankvs]

@jleveque OFF is a state like "Solid", "Blinking". I missed to see that OFF in the list.

[jleveque]

@kannankvs: I think the change to a tuple that you've requested should be dealt with in a separate PR. Would you be willing to make that change? If so, let's get this PR approved and merged first.

[kannankvs]

@jleveque : OK, we will do it. Once if this PR is merged, we will raise PR for the tuple.

[jleveque]

@kannankvs: Sounds good. Pleas approve this PR if you are OK with it.

[kannankvs]

@jleveque : Approvals done. Thank you.