*Request For Feedback*: TimeOwner in phosphor-timemanager

* *Request For Feedback*: TimeOwner in phosphor-timemanager
@ 2019-12-09  9:30 vishwa
  2019-12-10 18:47 ` Pine, Kathryn ElaineX
  0 siblings, 1 reply; 8+ messages in thread
From: vishwa @ 2019-12-09  9:30 UTC (permalink / raw)
  To: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 3071 bytes --]

Hi All,

Sending this email requesting the feedback on the usage/need of 
"TimeOwner" that is part of phosphor-timemanager.

phosphor-timemanager is a time keeping daemon on the BMC that uses BMC's 
RTC to hold the time. It uses systemd-timesyncd and systemd-timedated.

There are 2 D-Bus objects that implement 
"phosphor-dbus-interfaces/xyz/openbmc_project/Time/EpochTime.interface.yaml" 
and is managed by a common manager.

/xyz/openbmc_projects/time/bmc  : Used when the request is coming in via 
Redfish
/xyz/openbmc_projects/time/host : Used when the request is inband with 
IPMI_SET_SEL_TIME and IPMI_GET_SEL_TIME + PLDM ones.

timemanager consumes 2 settings, namely, TimeSyncMethod and TimeOwner 
defined in phosphor-dbus-interfaces/xyz/openbmc_project/Time/.

TimeSyncMethod: Indicates whether the NTP must be used or should it be 
settable by the user.
                 For example: If the time set request comes and the 
Method was set to NTP, then the write request would be ignored.

TimeOwner: This is where we have seen the community telling why do we 
even have such a thing. Talking to the UX team, looks like, the 
customers have had difficulty understanding this.

There are 4 values for TimeOwners: ( Works irrespective of acting on 
time/bmc or time/host D-Bus objects )

/BMC : BMC is the owner of the time. So, Host *can not *set the time on 
BMC. Inband SET_SEL_TIME would result in error.//
//
//HOST: Host is the owner of the time. So, only the host *can set* the 
time on BMC. Any external Redfish SET requests would result in error/

/SPLIT: This is where we could achieve independent times for BMC and 
Host. This is a combination of BMC + HOST. Both BMC and HOST can set
        the time. Host time is maintained as an offset into BMC's time. 
So, whenever the Host sends the time request, the offset is
        factored into//BMC's time and then the response would be returned.//
//
//BOTH : BMC and/or HOST can SET the time. Whoever did SET it last, will 
be maintained.
/

Personally, I have worked on github issue from Redhat when there were 
failures setting the time from OS using "hwclock" since the Owner was 
set to [BMC]. The solution was to [poweroff] the system, change the 
Owner to [HOST/SPLIT] and boot back.

Note: Since these policies are user settable, they can be changed at 
anytime. However, they will not be taken into account until the system 
is booted again.

*Why did we even have this ?*: During the initial development of 
timemanager, the thought was that, Host would not trust the BMC and 
hence we want a way where BMC and Host can maintain their own time

*Do we need this going forward ?*: I am being asked by UX team about the 
need of this and I mentioned I would get the community feedback on this. 
Although, I feel this level of granularity gives control over how we can 
manage time, it would not justify the complexity if the customers don't 
appreciate it. Removing the TimeOwner would make the code a lot simpler.

Please help with your votes.

Thank you,

!! Vishwa !!

[-- Attachment #2: Type: text/html, Size: 3987 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread