Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated ntp sources handling #173

Merged
merged 58 commits into from
Jan 25, 2023
Merged

Updated ntp sources handling #173

merged 58 commits into from
Jan 25, 2023

Conversation

mchf
Copy link
Member

@mchf mchf commented May 2, 2022

Problem

For several reasons ntp sources handling is not much user friendly.

For example in OpenSUSE installation the dialog looks this way
ntp-opensuse

There is no possibility to change listed ntp sources (add / remove).
The code doesn't distinguish between ntp server and pool.
What is less visible is that sources are written into "wrong" config file.
Behavior in SLE is not exactly the same but similar enough.

What are major caveats?

  1. the dialog shown in the screenshot is not implemented in one module but is spread in two modules (y2-country and y2-ntp-client)
  2. similarly to dialog creation, the handling is done in similar way. So, there is bunch of ui_ prefixed methods in y2-ntp-client's proposal client. Whenever is some operation done in the ntp part of dialog then it is proposed by client's api. It means that timezone dialog's loop handler checks if the event comes from ntp part of dialog, then it calls an ntp-client handler via proposal client's api and receives the response in the same way. It has some drawbacks regarding handling current dialog state.

Solution

Purpose of this PR was to keep current functionality and open possibilities to implement new behavior. Mainly support to really add / remove ntp sources and distinguish them to pool / servers.

So, as first step the dialog was redesigned to
ntp_patched_4

It allows to add / remove ntp sources and perform real configuration, not only using what installation sets for the user with no possibility to change anything.

It shows knowledge of difference between ntp server / pool.
List of ntp sources offered by default in the combobox was taken from SLE. User is allowed to write own ntp source.

Ntp sources are also read from the control file and from dhcp. Dhcp sources are not proposed by default, but available for selection in combobox. One of control file sources is randomly picked and proposed. See also previous yast2-country PR for some details.

Pools / servers are written into /etc/chrony.d/pool.conf. The pool.conf is provided by chrony-pool-* package(s) (product specific). We have to overwrite it otherwise yast's setup could be corrupted. The pool.conf is deployed by a package by design for needs of image based (no yast) installations.

Testing

  • Tested manually

Screenshots

See above

@coveralls
Copy link

coveralls commented May 2, 2022

Coverage Status

Coverage: 64.369% (+0.6%) from 63.778% when pulling 62e89d8 on mchf:removed_old_code into 99c8e0e on yast:master.

@teclator
Copy link
Contributor

Would be nice to see also how it looks like in ncurses. Therefore some screenshot would be appreciated

@mchf
Copy link
Member Author

mchf commented Oct 6, 2022

Would be nice to see also how it looks like in ncurses. Therefore some screenshot would be appreciated

As you can see in the following picture, the dialog is a bit messy in current implementation (TW installer)
ntp-tw-ncurses

This patch turns it to
ntp-tw-ncurses-patched

@teclator
Copy link
Contributor

There is a type column but there is no information about the source type at all but in general do not look bad although for UX I would ask @dgdavid ;)

@mchf
Copy link
Member Author

mchf commented Nov 14, 2022

This time this works:

  1. combo box is pre-filed with values obtained from dhcp, control file, ....
  2. some servers are picked by default - e.g. those obtained from dhcp
  3. user is allowed to pick whether the source is pool or server
  4. sources are written to the target at the end of installation

Major changes:

  1. the dialog is re-entrant. Before it behaved differently depending whether entered first time, or something was selected by user before and some other circumstances
  2. user is allowed to store the source as server or pool
  3. sources selected by default are as before

ntp_patched

@teclator
Copy link
Contributor

This time this works:

  1. combo box is pre-filed with values obtained from dhcp, control file, ....
  2. some servers are picked by default - e.g. those obtained from dhcp
  3. user is allowed to pick whether the source is pool or server
  4. sources are written to the target at the end of installation

Major changes:

  1. the dialog is re-entrant. Before it behaved differently depending whether entered first time, or something was selected by user before and some other circumstances
  2. user is allowed to store the source as server or pool
  3. sources selected by default are as before

ntp_patched

¿What about the servers defined in the rpm? I guess we should not provide default configuration based on rpms anymore in order to not collide with the configured ones or at least we should select the chrony-pool-empty package in the proposal

@mchf
Copy link
Member Author

mchf commented Nov 23, 2022

¿What about the servers defined in the rpm? I guess we should not provide default configuration based on rpms anymore in order to not collide with the configured ones or at least we should select the chrony-pool-empty package in the proposal

Proposals are currently taken only from dhcp and control file. In my POV, any "default" servers provided by an rpm package should not be used as it is somehow against what the proposal in installer does. However, this is for a discussion somewhere else. We're having a bit of chicken egg problem here, however I'd say that we need to have working installer proposal accepting user modifications and then we can ask for some more changes elsewhere.

@teclator
Copy link
Contributor

Proposals are currently taken only from dhcp and control file. In my POV, any "default" servers provided by an rpm package should not be used as it is somehow against what the proposal in installer does.

I agree, and it was part of the PBI to discuss it first before any implementation.

However, this is for a discussion somewhere else.

+1

We're having a bit of chicken egg problem here, however I'd say that we need to have working installer proposal accepting user modifications and then we can ask for some more changes elsewhere.

Not at all, we need to define behavior and implement accordingly, if we not show the user the current servers then it could be problematic and a mess which is exactly what is currently happening unless the user deselect the default rpm and selects the empty pools one, so this could be part of the current proposal until the product patterns or chrony package recommends are adapted.

BTW, checking the current implementation with a DUD ends with a long list of servers (known ones if I'm not wrong)

Screenshot_testing_2022-11-23_10:04:57

I expected the ones from the control file but that is not the case, is there some change in yast2-country needed by this PR?

module Yast
# This is used as the general interface between yast2-country
# (time,timezone) and yast2-ntp-client.
class NtpClientProposalClient < Client
include Yast::Logger

@sources_table = nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would omit this initialization and move it to a method...

Suggested change
@sources_table = nil
def sources_table
@sources_table_widget ||= Y2NtpClient::Widgets::SourcesTable.new(NtpClient.GetUsedNtpSources)
end

@mchf
Copy link
Member Author

mchf commented Nov 25, 2022

Minor fix in default initialization of ntp sources dialog
ntp_patched_2

@dgdavid
Copy link
Member

dgdavid commented Nov 30, 2022

Just a minor suggestion, slightly out of the scope of this PR: why not take the opportunity to put Current time and Current date inline?

I mean, when selecting Manually see something like

Date        Time
▒▒▒▒▒▒▒▒▒   ▒▒▒▒▒▒▒▒▒

instead of the current

   
Current Time
▒▒▒▒▒▒▒▒▒  

Current Date     
▒▒▒▒▒▒▒▒▒

@mchf
Copy link
Member Author

mchf commented Nov 30, 2022

Just a minor suggestion, slightly out of the scope of this PR: why not take the opportunity to put Current time and Current date inline?

I mean, when selecting Manually see something like

Date        Time
▒▒▒▒▒▒▒▒▒   ▒▒▒▒▒▒▒▒▒

instead of the current

   
Current Time
▒▒▒▒▒▒▒▒▒  

Current Date     
▒▒▒▒▒▒▒▒▒

it is in different module (yast2-country) see the description how it works to get into fun with this dialog ;-)

@mchf mchf force-pushed the removed_old_code branch 3 times, most recently from dd7e708 to c112f50 Compare December 5, 2022 08:55
Copy link
Contributor

@teclator teclator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mchf mchf merged commit 1e87efd into yast:master Jan 25, 2023
@mchf mchf deleted the removed_old_code branch January 25, 2023 10:23
@yast-bot
Copy link
Contributor

✔️ Public Jenkins job #49 successfully finished
✔️ Created OBS submit request #1060832

@yast-bot
Copy link
Contributor

✔️ Internal Jenkins job #31 successfully finished
✔️ Created IBS submit request #288844

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants