*Request For Feedback*: TimeOwner in phosphor-timemanager

[vishwa]

Alright.. This is what I am going ahead with for TimeOwner.

Phase-1 and near term goal: Make "BOTH" as default than what we 
currently have ( "BMC" )
Phase-2: Modify the code to remove support for HOST / BMC / SPLIT. Code 
will behave as if it's BOTH

If this breaks any usecase, please let me know.

Thank you,

!! Vishwa !!


On 1/6/20 2:48 PM, vishwa wrote:
> Hi,
>
> Happy New Year ...
>
> btw, looks like TimeOwner may not be of interest for the community ?. 
> Shall we go ahead remove that setting ?
>
> !! Vishwa !!
>
> On 12/19/19 1:30 PM, vishwa wrote:
>> On 12/19/19 1:29 AM, Kun Yi wrote:
>>>
>>
>>>
>>> On Wed, Dec 18, 2019 at 7:02 AM vishwa <vishwa at linux.vnet.ibm.com 
>>> <mailto:vishwa at linux.vnet.ibm.com>> wrote:
>>>
>>>     Hello community,
>>>
>>>     Would be really great if there is any feedback on this.
>>>
>>>     Have a happy holidays !!
>>>
>>>     !! Vishwa !!
>>>
>>>     On 12/11/19 3:24 PM, vishwa wrote:
>>>>     On 12/11/19 12:17 AM, Pine, Kathryn ElaineX wrote:
>>>>>
>>>>>     >*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.
>>>>>
>>>>>     Hi,
>>>>>
>>>>>     I am coming from the UX side of how we set the date time
>>>>>     settings page up for phosphor-webui downstream recently. We
>>>>>     switched our page to use Redfish, here’s how ours is set up now:
>>>>>
>>>>>     There is no longer a “time owner” and the setting is either:
>>>>>
>>>>>     NTPEnabled: true or false
>>>>>
>>>>>     If false, we are not allowing the user to set the time,
>>>>>     because the BMC is synching from the host time and therefore
>>>>>     any settings we made to the time on the BMC would be overwritten.
>>>>>
>>>>>     If true, we use the NTP server(s) the user provides.
>>>>>
>>>>>     We are testing this currently.
>>>>>
>>>>
>>>>     Hi, Thank you for the response. From what I interpreted:
>>>>
>>>>     - TimeOwner is not settable via GUI
>>>>     - Irrespective of NTP setting, the user is not allowed to set
>>>>     the time on BMC
>>>>     - BMC is syncing the time from Host.
>>>>        - This means, the current TimeOwner is "Host" and NTP is
>>>>     off. Is that being set as default ?
>>>>
>>>>     I am requesting for feedback from the community on the need of
>>>>     TimeOwner feature that we have in Settings and timemanager code.
>>>>
>>>>     !! Vishwa !!
>>>>>
>>> My 2cents here along with a few questions:
>>> - how does the current time manager interact with systemd-timesyncd?
>>
>> TimeManager interacts with systemd-timedated, which in turn engages 
>> systemd-timesync on setting *NTP *policy.
>> https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html**
>>
>>> - From my experience, BMC time can drift a lot easily and it is more 
>>> useful to have the BMC time synced externally
>>
>> This is a discussion point for using / not using NTP. It would not 
>> impact TimeOwner
>> https://github.com/openbmc/phosphor-time-manager/blob/master/README.md
>>
>>> - Whether NTP or host time is preferred should be left to the 
>>> platform designer to decide
>>
>> If the setting is NTP, then Host can not set the time on BMC unless 
>> the Owner is SPLIT.
>> I believe, you are saying more from a NTP / Non NTP as opposed to 
>> TimeOwner ?
>>
>>> - sounds like it would be more straightforward to have the 'Owner' 
>>> reflect one time source: NTP/IPMI/Redfish
>>
>> This is part of TimeSynchronization. TimeOwner is another layer on 
>> who owns the time as opposed to how the time is set.
>> Hopefully the README I pointed to before would help.
>>
>> Thank you,
>> !! Vishwa !!
>>>
>>> -- 
>>> Regards,
>>> Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200113/9761a5d3/attachment.htm>