-
Notifications
You must be signed in to change notification settings - Fork 15
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
Conversation
Would be nice to see also how it looks like in ncurses. Therefore some screenshot would be appreciated |
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 ;) |
b7adbf6
to
d653e86
Compare
fc9db29
to
3c54095
Compare
This time this works:
Major changes:
|
¿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. |
I agree, and it was part of the PBI to discuss it first before any implementation.
+1
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) 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 |
There was a problem hiding this comment.
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...
@sources_table = nil | |
def sources_table | |
@sources_table_widget ||= Y2NtpClient::Widgets::SourcesTable.new(NtpClient.GetUsedNtpSources) | |
end |
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
instead of the current
|
d74eb01
to
f39bb06
Compare
it is in different module (yast2-country) see the description how it works to get into fun with this dialog ;-) |
dd7e708
to
c112f50
Compare
List of servers to be stored is by default initialized by dhcp provided sources only. Timezone based proposal is used for combo together with dhcp ones, to be used as hint of available sources for user.
84978c7
to
62e89d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
✔️ Public Jenkins job #49 successfully finished |
✔️ Internal Jenkins job #31 successfully finished |
Problem
For several reasons ntp sources handling is not much user friendly.
For example in OpenSUSE installation the dialog looks this way
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?
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
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
Screenshots
See above