Hi, Wednesday (23 September 2009)
For review at our next WIMS WG teleconference on Monday (28 September).
Below are some simplifications for my next draft of Power Management
Model - please read and reply ASAP - thanks.
New conformance packages are TBD, after further discussion.
FAIR WARNING - In the absence of any protests, I will make ALL of these
changes in my next draft of Power Management Model (except perhaps the
PowerPolicy breakdown into 3 new simpler policy groups).
PowerMonitor (REQUIRED)
- keep PowerState (single-access read of state is a base requirement)
- keep PowerStateMessage (only localized state message - see below)
- delete MonitorID (only one instance allowed per System/Subunit object)
- delete PowerStateTimestamp (redundant w/ PowerLog)
- delete LastLogID (not useful, per Mike Fenelon)
PowerLog (OPTIONAL)
- keep LogID (key)
- keep PowerState and PowerStateTimestamp (machine-readable)
- delete PowerStateMessage (redundant w/ PowerMonitor)
- delete LogPolicyID (not useful, per Ira)
PowerMode (OPTIONAL)
- keep PowerState (key)
- keep PowerUsageWatts (per Power Mgmt Project charter)
- keep IsAcceptingJobs, IsProcessingJobs, IsValidRequestPowerState
(per Power Mgmt Project charter - but rename for clarity)
- delete PowerStateMessage (redundant w/ PowerLog)
PowerTransition (OPTIONAL)
- keep StatePowerState and EndPowerState (keys)
- keep StateChangeSeconds (per Power Mgmt Project charter)
PowerPolicy (OPTIONAL)
- maybe divide up into 3 simpler policy groups (see below)
- delete PolicyTotalTriggers (overkill, though CIM supported)
- delete PolicyLastTriggerTimestamp (overkill, though CIM supported)
PowerRequest (OPTIONAL)
- keep RequestPowerState (read-write)
- keep RequestStatus (machine-readable)
- keep RequestStatusMessage (human-readable status message)
- delete RequestID (only one instance allowed per System/Subunit object)
- delete StartRequestTimestamp, EndRequestTimestamp (see PowerLog)
NEW - possible breakdown of PowerPolicy for simpler implementations
PowerTimeout (OPTIONAL)
- TimeoutID (key)
- TimeoutRequestPowerState (requested new state on timeout trigger)
- TimeoutStartPowerState (optional starting state, e.g., 'On')
- TimeoutPredicate (for activity versus inactivity)
- TimeoutSeconds (actual interval)
PowerCalendar (OPTIONAL)
- CalendarID (key)
- CalendarRequestPowerState (requested new state on calendar trigger)
- CalendarIsOnetime (recurring versus one-time calendar triggers)
- CalendarWeekday
- CalendarMonth
- CalendarDay
- CalendarHour
- CalendarMinute
PowerEvent (OPTIONAL)
- EventID (key)
- EventRequestPowerState (requested new state on event trigger)
- EventName (trigger event name)
NOTE - DMTF CIM and OASIS standards both depend on IETF Schedule MIB
(along with all IETF System Policy standards), so I'm very strongly
opposed to changing Calendar elements to be incompatible.
Comments?
Cheers,
- Ira (Power Management editor)
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.