All of lore.kernel.org
 help / color / mirror / Atom feed
* Document on : Time Manager in OpenBMC --> Need your review.
@ 2016-08-18 11:08 vishwa
  2016-08-22 23:44 ` Rick Altherr
  0 siblings, 1 reply; 5+ messages in thread
From: vishwa @ 2016-08-18 11:08 UTC (permalink / raw)
  To: openbmc

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

Team,

Please help look into this document that describes what I think the 
TimeManager on openBMC systems should look like.

Please weigh in your thoughts.

Thanks.

Vishwanath.

[-- Attachment #2: TimeManager.txt --]
[-- Type: text/plain, Size: 4652 bytes --]

BMC Settings  in /org/openbmc/settings/Host/host0
--------------------------------------------------

1/. New property "TimeMode" and the default would be set to "NTP"

--> This means, BMC will use timesyncd to sync the time with NTP servers. Any attempt to set the time manually is rejected by the time daemon.

1.1) The only other valid value for that would be "Manual".

--> This means, BMC will disable 'ntp' so that only manually setting the time would be allowed.

-------------------------------------------------------

2/. New property called "TimeOwner" and the default would be set to "BMC"

2.1) The other possible values would be "Host" / "Split" / "Both".

Owner *BMC*: BMC can have NTP / Non-NTP as BMC's source of time.
 --> This also means that, when host sends SET_SEL, BMC just responds with success and when host asks GET_SEL, BMC's time is returned.

**

Owner *Host*: BMC can *not* set the time on its own and need to wait for host's IPMI message to set and this is why this is not default.

**

Owner *Split*: BMC is free to choose either Manual -or- NTP to set BMC time, however, when host sends the time down, the difference between host's time and BMC's time is calculated and is stored in a persistent area. This offset is kept up-to-date whenever the time changes on the BMC ( Using timerfd_settime with TFD_TIMER_CANCEL_ON_SET ).

--> When host asks time, the BMC's time is read and then factors in the offset and returns it.

**

Owner *Both* : Same as BMC owns the clock but just that when Host sends SET_SEL time, the time on BMC is set to value given by host.

==========================================================

API's defined that is exported by BMC and accessible by REST ( Modified only if policy allows it ).
---------------------------------------------------------------------------------------------------

1/. /org/openbmc/TimeManager/SetTime (time_string_in_%Y-%m-%d %H:%M:%S ). --> Set BMC Time per the user input.

    --> This format is then used by strptime and uses mktime to convert it to num_seconds and calls /org/freedesktop/timedate1/SetTime converted to usec

    --> Although strptime support whole lot of other formats, I think this one way is enough.

**

2/. /org/openbmc/TimeManager/GetTime (returns ctime ) -> Get BMC Time.

    --> If caller is IPMI_GET_SEL and the mode is "split", then the host-offset is added to this and returned, else return what is read on BMC.

**

3/. /org/openbmc/TimeManager/SetNTP (string 'yes_or_no') --> Enable / Disable NTP @ BMC.

    --> Calls /org/freedesktop/timedate1/SetNTP with '1' or '0' and that would handle pausing timesyncd.

**

NOTE :: The easiet thing would be to do a "systemd(timedatectl <user request>)" so mostly all is handled by systemd but the only draw back I see is the new fork and I believe this may not be a correct approach.

**

4/. TimeManager watches for PropertyChanged events from /org/openbmc/settings/Host/host0 and would read the changed settings and take appropriate actions :

Actions could be :
-----------------

4.1/. If the TimeMode is changed between BMC<-->Manual, then whatever asked for is enabled / disabled is honored at anytime.

4.2/.  If the TimerMode asked is to change to "host owns the clock" -OR- "split clock", then the value of [pgood] is read. If that is [on], then the request is  

       ignored since it would not be safe to change to these modes when things are running.

       --> On a successful policy change, the host_offset is nullified.

4.3/  if the TimerMode asked is to change to "BMC owns the clock" -OR- "Both", then the "host_offset" would be invalidated and the request is honored.

**

5/. TimeManager watches for time changes in BMC due to any source by watching for TFD_TIMER_CANCEL_ON_SET and then updates the host_offset if the Owner is set to split.

===========================================================

Changes to Existing /org/openbmc/NetworkManager/
------------------------------------------------

1/. SetAddress4 now takes in another field called "NTP" and user need to give "" if they do not want to supply NTP at the time of netconf.
2/. SetDHCP now takes in another field called "UseNTP" and the user needs to give "yes"/"no"/"" and the "" the same would be put as UseNTP= under DHCP section.
3/. A new API that will take in "interface name" and "list of NTP" and would go ahead update the static .network file or in DHCP section.

=====================

Notes:

1/. sd_event loop is used so that the requests are serialized by SD_BUS.
2/. timerfd_settime is used with TFD_TIMER_CANCEL_ON_SET so that we get woken up only when there is a time is set.



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

* Re: Document on : Time Manager in OpenBMC --> Need your review.
  2016-08-18 11:08 Document on : Time Manager in OpenBMC --> Need your review vishwa
@ 2016-08-22 23:44 ` Rick Altherr
  2016-08-25 11:59   ` vishwa
  0 siblings, 1 reply; 5+ messages in thread
From: Rick Altherr @ 2016-08-22 23:44 UTC (permalink / raw)
  To: vishwa; +Cc: OpenBMC Maillist

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

In the future, please just send the text inline instead of as an attachment.

I don't understand the setting hierarchy.  To me,
/org/openbmc/settings/Host/host0 implies I am modifying something related
to the host CPU, not the BMC.  TimeMode only applies to the BMC so having
it under host0 feels weird.

1. I like the clear separation of NTP vs manual.

2.1. "Both" seems like what we have today which doesn't really work at
all.  I suggest omitting it.  "Split" feels like it should work for all
cases.  If TimeMode is NTP, an offset is recorded.  If TimeMode is Manual,
the BMC time is set.

APIs:
1. What time zone does SetTime assume?  If UTC, make sure to add tests for
a valid leap second and leap year.
2. I really dislike APIs that change behavior.  Provide separate GetBmcTime
and GetHostTime APIs if you must.
3. SetNTP is a very limiting name.  if this really changes TimeMode, call
it SetTimeMode.  That way we can support things like 1588, GPS, etc later.

Changes to NetworkManager:
- I don't see the point of UseNTP for SetDHCP.  Configuring an NTP address
is different from using NTP as a time source.  It's up to the DHCP server
to provide NTP options.  Whether the BMC uses them is controlled by
TimeMode.
- Add a SetNtpServer API instead of adding to SetAddress4.  NTP is entirely
separate from IPv4 address configuration.

On Thu, Aug 18, 2016 at 4:08 AM, vishwa <vishwa@linux.vnet.ibm.com> wrote:

> Team,
>
> Please help look into this document that describes what I think the
> TimeManager on openBMC systems should look like.
>
> Please weigh in your thoughts.
>
> Thanks.
>
> Vishwanath.
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>

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

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

* Re: Document on : Time Manager in OpenBMC --> Need your review.
  2016-08-22 23:44 ` Rick Altherr
@ 2016-08-25 11:59   ` vishwa
  2016-08-25 17:19     ` Rick Altherr
  0 siblings, 1 reply; 5+ messages in thread
From: vishwa @ 2016-08-25 11:59 UTC (permalink / raw)
  To: Rick Altherr; +Cc: OpenBMC Maillist

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

Rick,

Thanks for the thoughts. I have put my response in-line. Please let me 
know if you have any feedback on this.


On 08/23/2016 05:14 AM, Rick Altherr wrote:
> In the future, please just send the text inline instead of as an 
> attachment.
>
> I don't understand the setting hierarchy.  To me, 
> /org/openbmc/settings/Host/host0 implies I am modifying something 
> related to the host CPU, not the BMC.  TimeMode only applies to the 
> BMC so having it under host0 feels weird.
>
Agree. Doing this in 'host0' is not appropriate. However, the current 
'settingsd' framework does not allow multiple levels since the need 
until now was only for 'host'. Now that we have a requirement to get 
something new, I have suggested a change to have another entry called 
'bmc' and that work will be taken in future sprints. So when that change 
is made, I will make a corresponding change to clock as well.
> 1. I like the clear separation of NTP vs manual.
>
> 2.1. "Both" seems like what we have today which doesn't really work at 
> all.  I suggest omitting it.  "Split" feels like it should work for 
> all cases.  If TimeMode is NTP, an offset is recorded.  If TimeMode is 
> Manual, the BMC time is set.
>
We had one of the customers ask for "Both" and that is why we are 
putting this in there.
For the *split* mode, whether it is NTP / Manual, it still demands an 
update to offset.
> APIs:
> 1. What time zone does SetTime assume?  If UTC, make sure to add tests 
> for a valid leap second and leap year.

It does not handle Time Zones. Its a mere seconds since epoch. Okay.. I 
will add the tests.
> 2. I really dislike APIs that change behavior.  Provide separate 
> GetBmcTime and GetHostTime APIs if you must.
I like this idea. Implemented it.
> 3. SetNTP is a very limiting name.  if this really changes TimeMode, 
> call it SetTimeMode.  That way we can support things like 1588, GPS, 
> etc later.

I have changed the way NTP setting gets set completely. There will not 
be an exposed API to change NTP setting. The changes that are done to 
'time_mode' will be picked up automatically by the daemon and then 
appropriate services are started / stopped.
>
> Changes to NetworkManager:
> - I don't see the point of UseNTP for SetDHCP.  Configuring an NTP 
> address is different from using NTP as a time source. It's up to the 
> DHCP server to provide NTP options.  Whether the BMC uses them is 
> controlled by TimeMode.
The only reason I wanted this in there is if someone wants to take a 
call to put NTP choice in there while changing the BMC networking to 
DHCP, they can do it right then and there than having to make another call.

In addition to this, there are 2 parts to having NTP as TimeMode.
(1) We can let timesyncd choose NTP settings that have been given by DHCP
(2) Let timesyncd choose NTP settings that were manually entered using 
"SetNtpAddress"
> - Add a SetNtpServer API instead of adding to SetAddress4. NTP is 
> entirely separate from IPv4 address configuration.
I do have SetNtpServer and the reason I also chose to make it a part of 
SetAddress4 was the exact same reason I mentioned for the UseNTP= for DHCP.
>
> On Thu, Aug 18, 2016 at 4:08 AM, vishwa <vishwa@linux.vnet.ibm.com 
> <mailto:vishwa@linux.vnet.ibm.com>> wrote:
>
>     Team,
>
>     Please help look into this document that describes what I think
>     the TimeManager on openBMC systems should look like.
>
>     Please weigh in your thoughts.
>
>     Thanks.
>
>     Vishwanath.
>
>     _______________________________________________
>     openbmc mailing list
>     openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
>     https://lists.ozlabs.org/listinfo/openbmc
>     <https://lists.ozlabs.org/listinfo/openbmc>
>
>


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

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

* Re: Document on : Time Manager in OpenBMC --> Need your review.
  2016-08-25 11:59   ` vishwa
@ 2016-08-25 17:19     ` Rick Altherr
  2016-09-06  9:01       ` vishwa
  0 siblings, 1 reply; 5+ messages in thread
From: Rick Altherr @ 2016-08-25 17:19 UTC (permalink / raw)
  To: vishwa; +Cc: OpenBMC Maillist

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

On Thu, Aug 25, 2016 at 4:59 AM, vishwa <vishwa@linux.vnet.ibm.com> wrote:

> Rick,
>
> Thanks for the thoughts. I have put my response in-line. Please let me
> know if you have any feedback on this.
>
> On 08/23/2016 05:14 AM, Rick Altherr wrote:
>
> In the future, please just send the text inline instead of as an
> attachment.
>
> I don't understand the setting hierarchy.  To me,
> /org/openbmc/settings/Host/host0 implies I am modifying something related
> to the host CPU, not the BMC.  TimeMode only applies to the BMC so having
> it under host0 feels weird.
>
> Agree. Doing this in 'host0' is not appropriate. However, the current
> 'settingsd' framework does not allow multiple levels since the need until
> now was only for 'host'. Now that we have a requirement to get something
> new, I have suggested a change to have another entry called 'bmc' and that
> work will be taken in future sprints. So when that change is made, I will
> make a corresponding change to clock as well.
>
> 1. I like the clear separation of NTP vs manual.
>
> 2.1. "Both" seems like what we have today which doesn't really work at
> all.  I suggest omitting it.  "Split" feels like it should work for all
> cases.  If TimeMode is NTP, an offset is recorded.  If TimeMode is Manual,
> the BMC time is set.
>
> We had one of the customers ask for "Both" and that is why we are putting
> this in there.
>

What are they expecting in terms of behavior?  "Both" has the host and BMC
fighting for ownership of the BMC system time which has quirky behavior.


> For the *split* mode, whether it is NTP / Manual, it still demands an
> update to offset.
>

In "Split" with Manual, the BMC time is meant to be set from the host.  In
that case, the offset can be assumed to be zero and the BMC clock set to
the provided time.


>
> APIs:
> 1. What time zone does SetTime assume?  If UTC, make sure to add tests for
> a valid leap second and leap year.
>
>
> It does not handle Time Zones. Its a mere seconds since epoch. Okay.. I
> will add the tests.
>

Seconds since epoch != UTC.  Specifically for a leap second event, a single
POSIX time point is used for both 23:59:60 and the following 00:00:00.  If
the API is supposed to be UTC, specifically state that in the API.  If it's
supposed to be a POSIX time, have them provide a 64-bit integer.


>
> 2. I really dislike APIs that change behavior.  Provide separate
> GetBmcTime and GetHostTime APIs if you must.
>
> I like this idea. Implemented it.
>
> 3. SetNTP is a very limiting name.  if this really changes TimeMode, call
> it SetTimeMode.  That way we can support things like 1588, GPS, etc later.
>
>
> I have changed the way NTP setting gets set completely. There will not be
> an exposed API to change NTP setting. The changes that are done to
> 'time_mode' will be picked up automatically by the daemon and then
> appropriate services are started / stopped.
>
>
> Changes to NetworkManager:
> - I don't see the point of UseNTP for SetDHCP.  Configuring an NTP address
> is different from using NTP as a time source.  It's up to the DHCP server
> to provide NTP options.  Whether the BMC uses them is controlled by
> TimeMode.
>
> The only reason I wanted this in there is if someone wants to take a call
> to put NTP choice in there while changing the BMC networking to DHCP, they
> can do it right then and there than having to make another call.
>

I'm hearing that you are optimizing for a case that we don't know is
important to optimize for.  BMC networking settings are conceptually
unrelated to time settings.  Combining them in the API adds a lot more
complexity as all the places the NTP settings can be modified needs to be
considered.

>
> In addition to this, there are 2 parts to having NTP as TimeMode.
> (1) We can let timesyncd choose NTP settings that have been given by DHCP
> (2) Let timesyncd choose NTP settings that were manually entered using
> "SetNtpAddress"
>

Both of those cases can be handled with a single SetNtpAddress API.


>
> - Add a SetNtpServer API instead of adding to SetAddress4.  NTP is
> entirely separate from IPv4 address configuration.
>
> I do have SetNtpServer and the reason I also chose to make it a part of
> SetAddress4 was the exact same reason I mentioned for the UseNTP= for DHCP.
>
>
> On Thu, Aug 18, 2016 at 4:08 AM, vishwa <vishwa@linux.vnet.ibm.com> wrote:
>
>> Team,
>>
>> Please help look into this document that describes what I think the
>> TimeManager on openBMC systems should look like.
>>
>> Please weigh in your thoughts.
>>
>> Thanks.
>>
>> Vishwanath.
>>
>> _______________________________________________
>> openbmc mailing list
>> openbmc@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
>>
>>
>
>

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

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

* Re: Document on : Time Manager in OpenBMC --> Need your review.
  2016-08-25 17:19     ` Rick Altherr
@ 2016-09-06  9:01       ` vishwa
  0 siblings, 0 replies; 5+ messages in thread
From: vishwa @ 2016-09-06  9:01 UTC (permalink / raw)
  To: Rick Altherr; +Cc: OpenBMC Maillist

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

hello Rick,

Sorry on the delay. Please find my comments.


On 08/25/2016 10:49 PM, Rick Altherr wrote:
>
>
> On Thu, Aug 25, 2016 at 4:59 AM, vishwa <vishwa@linux.vnet.ibm.com 
> <mailto:vishwa@linux.vnet.ibm.com>> wrote:
>
>     Rick,
>
>     Thanks for the thoughts. I have put my response in-line. Please
>     let me know if you have any feedback on this.
>
>
>     On 08/23/2016 05:14 AM, Rick Altherr wrote:
>>     In the future, please just send the text inline instead of as an
>>     attachment.
>>
>>     I don't understand the setting hierarchy.  To me,
>>     /org/openbmc/settings/Host/host0 implies I am modifying something
>>     related to the host CPU, not the BMC.  TimeMode only applies to
>>     the BMC so having it under host0 feels weird.
>>
>     Agree. Doing this in 'host0' is not appropriate. However, the
>     current 'settingsd' framework does not allow multiple levels since
>     the need until now was only for 'host'. Now that we have a
>     requirement to get something new, I have suggested a change to
>     have another entry called 'bmc' and that work will be taken in
>     future sprints. So when that change is made, I will make a
>     corresponding change to clock as well.
>>     1. I like the clear separation of NTP vs manual.
>>
>>     2.1. "Both" seems like what we have today which doesn't really
>>     work at all.  I suggest omitting it.  "Split" feels like it
>>     should work for all cases.  If TimeMode is NTP, an offset is
>>     recorded.  If TimeMode is Manual, the BMC time is set.
>>
>     We had one of the customers ask for "Both" and that is why we are
>     putting this in there.
>
>
> What are they expecting in terms of behavior?  "Both" has the host and 
> BMC fighting for ownership of the BMC system time which has quirky 
> behavior.
One of the OpenPower customers had specifically requested for this. I 
will dig into what the expectation from them was and let you know.
>
>     For the *split* mode, whether it is NTP / Manual, it still demands
>     an update to offset.
>
>
> In "Split" with Manual, the BMC time is meant to be set from the 
> host.  In that case, the offset can be assumed to be zero and the BMC 
> clock set to the provided time.
In my view, Only when the time mode is set to "HOST", the BMC time is 
meant to be set from the host. In the case of split, BMC can choose to 
maintain its own time. The host time requests are handled as offsets 
into BMC's time.
>
>
>>     APIs:
>>     1. What time zone does SetTime assume?  If UTC, make sure to add
>>     tests for a valid leap second and leap year.
>
>     It does not handle Time Zones. Its a mere seconds since epoch.
>     Okay.. I will add the tests.
>
>
> Seconds since epoch != UTC.  Specifically for a leap second event, a 
> single POSIX time point is used for both 23:59:60 and the following 
> 00:00:00.  If the API is supposed to be UTC, specifically state that 
> in the API. If it's supposed to be a POSIX time, have them provide a 
> 64-bit integer.
>
>
>>     2. I really dislike APIs that change behavior.  Provide separate
>>     GetBmcTime and GetHostTime APIs if you must.
>     I like this idea. Implemented it.
>>     3. SetNTP is a very limiting name.  if this really changes
>>     TimeMode, call it SetTimeMode. That way we can support things
>>     like 1588, GPS, etc later.
>
>     I have changed the way NTP setting gets set completely. There will
>     not be an exposed API to change NTP setting. The changes that are
>     done to 'time_mode' will be picked up automatically by the daemon
>     and then appropriate services are started / stopped.
>>
>>     Changes to NetworkManager:
>>     - I don't see the point of UseNTP for SetDHCP.  Configuring an
>>     NTP address is different from using NTP as a time source.  It's
>>     up to the DHCP server to provide NTP options. Whether the BMC
>>     uses them is controlled by TimeMode.
>     The only reason I wanted this in there is if someone wants to take
>     a call to put NTP choice in there while changing the BMC
>     networking to DHCP, they can do it right then and there than
>     having to make another call.
>
>
> I'm hearing that you are optimizing for a case that we don't know is 
> important to optimize for.  BMC networking settings are conceptually 
> unrelated to time settings. Combining them in the API adds a lot more 
> complexity as all the places the NTP settings can be modified needs to 
> be considered.
I kind of agree with your thoughts. In my patch-set, I have removed 
these options from SetAddress4 and SetDHCP.
>
>
>     In addition to this, there are 2 parts to having NTP as TimeMode.
>     (1) We can let timesyncd choose NTP settings that have been given
>     by DHCP
>     (2) Let timesyncd choose NTP settings that were manually entered
>     using "SetNtpAddress"
>
>
> Both of those cases can be handled with a single SetNtpAddress API.
#1 is actually a setting that the user can manipulate and the time 
daemon reacts to that change and hence the need of 2 API.
>
>
>>     - Add a SetNtpServer API instead of adding to SetAddress4.  NTP
>>     is entirely separate from IPv4 address configuration.
>     I do have SetNtpServer and the reason I also chose to make it a
>     part of SetAddress4 was the exact same reason I mentioned for the
>     UseNTP= for DHCP.
>>
>>     On Thu, Aug 18, 2016 at 4:08 AM, vishwa
>>     <vishwa@linux.vnet.ibm.com <mailto:vishwa@linux.vnet.ibm.com>> wrote:
>>
>>         Team,
>>
>>         Please help look into this document that describes what I
>>         think the TimeManager on openBMC systems should look like.
>>
>>         Please weigh in your thoughts.
>>
>>         Thanks.
>>
>>         Vishwanath.
>>
>>         _______________________________________________
>>         openbmc mailing list
>>         openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
>>         https://lists.ozlabs.org/listinfo/openbmc
>>         <https://lists.ozlabs.org/listinfo/openbmc>
>>
>>
>
>


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

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

end of thread, other threads:[~2016-09-06  9:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-18 11:08 Document on : Time Manager in OpenBMC --> Need your review vishwa
2016-08-22 23:44 ` Rick Altherr
2016-08-25 11:59   ` vishwa
2016-08-25 17:19     ` Rick Altherr
2016-09-06  9:01       ` vishwa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.