Sorry, misunderstood the bug, so we have two problems, YaST using the wrong pool and chrony missing a hint which of the three pool RPMs zypper should prefer.

OK, so issue with opensuse microos and kubic is that this proposal of ntp server does not match its products and needs to be updated:
https://github.com/yast/yast-network/blob/master/src/lib/y2network/ntp_server.rb#L54

(In reply to Josef Reidinger from comment #2)
> OK, so issue with opensuse microos and kubic is that this proposal of ntp
> server does not match its products and needs to be updated:
> https://github.com/yast/yast-network/blob/master/src/lib/y2network/
> ntp_server.rb#L54

On Leap 15.3+, the product is called just "Leap", so that's actually affected as well, which the logs from an openQA installation confirm.

And that's exactly why it's absolutely bad idea to hard-code such logic to code. It always breaks, sooner or later.

I joined this PBI and found that there are different problems.

The problem about the RPM mentioned in #1 is already fixed but we still have to fix the YaST issue (wrong servers).

But there is another bug reported about YaST and the list of servers (bsc#1188980)

In summary, the list of servers defined during the installation (see https://openqa.opensuse.org/tests/1545143#step/ntp_config_settings/3) are written as pools in /etc/chrony.conf.

localhost:~ # grep ^pool /etc/chrony.conf
pool 0.suse.pool.ntp.org iburst
pool 1.suse.pool.ntp.org iburst
pool 2.suse.pool.ntp.org iburst
pool 3.suse.pool.ntp.org iburst

It was requested to be able to define the default servers in the control file, something that Josef started to implement (see links below)

https://github.com/yast/yast-installation-control/pull/105
https://github.com/yast/skelcd-control-openSUSE/pull/223
https://github.com/yast/skelcd-control-leanos/pull/72

The point is that YaST client ignores peers and servers and only takes into consideration the defined pools.

In the past we allowed to define the type of the source:

https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-netz-xntp.html#sec-net-ntp-yast-new-sync

But that is not possible anymore.

So, for this bug I guess it is enough just finishing Josef implementation, but would be nice to also discuss about improvements in order to address (bsc#1188980)

For me, the important part is described in comment #2. We can't depend on product name and thus it should go to control file (with a safe default in code). No more unreliable built-in decision making.

Whether pools/servers should be supported, I'd keep that question for Josef. Honestly, I've already seen similar "give me my server option back" request. But it works differently in Chrony...

The bug should be fixed by the PR below:

- https://github.com/yast/yast-installation-control/pull/112 (yast2-installation-control-4.4.3)
- https://github.com/yast/yast-network/pull/1246 (yast2-network-4.4.23)
https://github.com/yast/skelcd-control-MicroOS/pull/42 (skelcd-control-MicroOS-20210907)
- https://github.com/yast/skelcd-control-Kubic/pull/55 (skelcd-control-Kubic-20210907)

The skelcd-control submit requests are:

- https://build.opensuse.org/request/show/917275 (MicroOS SR)
- https://build.opensuse.org/request/show/917274 (Kubic SRC)

Closing it as fixed.

In Factory chrony produces subpackages chrony-pool-openSUSE and chrony-pool-suse. The right one is pulled in based on branding. So there's actually no need to write anything to /etc/chrony.conf. Maybe it would make sense to consider removing the NTP config step from the default install workflow? The dialog is rather empty and sad looking anyway :-)

(In reply to Ludwig Nussel from comment #16)

> In Factory chrony produces subpackages chrony-pool-openSUSE
> and chrony-pool-suse. The right one is pulled in based on
> branding.

I would be more than happy to drop these pool packages again and write them off as a mistake.

> So there's actually no need to write anything to /etc/chrony.conf.
> Maybe it would make sense to consider removing the NTP config
> step from the default install workflow?

What about environments that don't allow access to NTP servers on the open internet?

(In reply to Ludwig Nussel from comment #16)
> In Factory chrony produces subpackages chrony-pool-openSUSE and
> chrony-pool-suse. The right one is pulled in based on branding. So there's
> actually no need to write anything to /etc/chrony.conf. Maybe it would make
> sense to consider removing the NTP config step from the default install
> workflow? The dialog is rather empty and sad looking anyway :-)

well, ntp config step also decide if it should use ntp or just set time manually of skip it and just set timezone ( useful when you install on virtualization that sets itself hardware clock ). So setting which ntp pool to use is just cherry on top. But of course we can try to remove option to set your ntp server or maybe even better has just placeholder for default and allow to overwrite it by your own ntp server like many customers do.

(In reply to Reinhard Max from comment #17)
> (In reply to Ludwig Nussel from comment #16)
> 
> > In Factory chrony produces subpackages chrony-pool-openSUSE
> > and chrony-pool-suse. The right one is pulled in based on
> > branding.
> 
> I would be more than happy to drop these pool packages again and write them
> off as a mistake.

That might also be an option. Depens on what we want to achieve.
 
> > So there's actually no need to write anything to /etc/chrony.conf.
> > Maybe it would make sense to consider removing the NTP config
> > step from the default install workflow?
> 
> What about environments that don't allow access to NTP servers on the open
> internet?

IMO DHCP should provide the NTP setting.

(In reply to Josef Reidinger from comment #18)
> (In reply to Ludwig Nussel from comment #16)
> > In Factory chrony produces subpackages chrony-pool-openSUSE and
> > chrony-pool-suse. The right one is pulled in based on branding. So there's
> > actually no need to write anything to /etc/chrony.conf. Maybe it would make
> > sense to consider removing the NTP config step from the default install
> > workflow? The dialog is rather empty and sad looking anyway :-)
> 
> well, ntp config step also decide if it should use ntp or just set time
> manually of skip it and just set timezone ( useful when you install on
> virtualization that sets itself hardware clock ). So setting which ntp pool
> to use is just cherry on top. But of course we can try to remove option to
> set your ntp server or maybe even better has just placeholder for default
> and allow to overwrite it by your own ntp server like many customers do.

You might be talking about a different dialog. I mean that one:
https://openqa.opensuse.org/tests/2074112#step/ntp_config_settings/1

(In reply to Ludwig Nussel from comment #19)
> (In reply to Reinhard Max from comment #17)

> > I would be more than happy to drop these pool packages again and write them
> > off as a mistake.
> 
> That might also be an option. Depens on what we want to achieve.

This is only an option if you install purely with YaST2.


> > What about environments that don't allow access to NTP servers on the open
> > internet?
> 
> IMO DHCP should provide the NTP setting.

DHCP is evil and forbidden in secure datacenters. Or not possible in Edge Usecases.


The question is what you want to archive starting this discussion in a resolved as fixed bug report?

(In reply to Thorsten Kukuk from comment #20)

> DHCP is evil and forbidden in secure datacenters. Or not possible in Edge
> Usecases.

But in these scenarios, accessing our preconfigured NTP pools on the public internet is most likely forbidden and/or not possible either.

I think the vast majority of our users fall into one of these two categories:

a) NTP servers are provided via DHCP (Home, SoHo, corporate networks)

b) DHCP is forbidden, Internet access is limited, NTP servers have to be set up manually or through some deployment framework.

None of these scenarios needs the preconfigured pools and for most of them it is at least inconvenient that they exist.

So, what are the deployments that actually need this preconfiguration, and what's their estimated percentage of all SUSE deployments?

BTW, chrony has a "prefer" option for the "server" and "pool" statememts which could be used in all but the preconfigured statements, so that chrony prefers the local (manual or automatic) configuration over the defaults. Ideally it would also have a "fallback" option that we could add to the preconfiguration, so that we don't need to educate users to use "prefer" when adding servers manually.

I will suggest that to upstream.