cloud-init team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

Just for mailing list posterity, we discussed this in freenode irc and put
up this doc
 https://hackmd.io/s/r1qN6HNbz

Below is a paste of the doc at this point

# NTP configuration in cloud-init
In cloud-init, the top level config entry `ntp` should be seen as referring
to the network time protocol rather than a specific implementation such as
`isc-ntp`, `chrony`, `systemd-timesyncd`.

You can see the description of config in upstream [readthedocs](
http://cloudinit.readthedocs.io/en/latest/topics/modules.html#ntp).

The value config path `system_info['ntp_client']` can be set by the image
builder to provide a declaration of which ntp client should be used in this
system.  This value can be set to:

> [name=Robert Schweikert] After revisiting my branch I realized that
`system_info['ntp_client']` is not sufficient. The reason is that we cannot
assume that the service name is the same as the client name. That would
imply that the distro calss implementation needs to carry a map between the
system_info setting and the service name, that's certainly no problem, just
menioning that this is needed.

 * isc-ntp
 * chrony [note there is not current support for this]
 * systemd-timesyncd
 * auto
> [name=Robert Schweikert] My concern with the "auto" mode is how we would
decide in the code what it should be given that all ntpd, chrony, timesyncd
may be available. An is_installable() test leads us kind of into the trap I
outlined on the mailing list. If we have a distro.preferred_time_client()
then in the distro specific implementation something has to make a decision
based on the distro version, i.e. read os-release or other file.
> I think an "auto" mode kind of gets us into the predicament I described
on the mail list. One way out of this may be to have a "supplemental"
config file that  gets rendered at build time and that supplemental config
file provides distro_version. That would resolve the "auto" issue as then
distro.preferred_time_client() could return the "proper value" based on
cloud-init "internal" knowledge and thus testing becomes easy.

> [name=Scott Moser] You're certainly welcome to build images with the
system_info/ntp-client set to the correct value for your image.  Either
doing that, or having only one ntp client installed will result in simple
path.  I believe that is what you're suggesting.  You can ship that by
either shipping a different /etc/cloud/cloud.cfg or "supplemental config"
/etc/cloud/cloud.cfg.d/00-distro.cfg
>
> [name=Robert Schweikert] I am not really worried about the images I
build. Those will have the proper setting, that's easy. I am more worried
about custom image builds or users that simply use the "default" cloud.cfg
file. Of course in the "default" cloud.cfg file ntp can simple be disabled.
But for a use building their own image they would set "ntp: enabled" and
would probably rightfully expect cloud-init to use the "default" client for
that distribution. And thus we are back to decide based on the distribution
what client to use. Unless of course we come to the conclusion that a
distribution now basically needs to supply
/etc/cloud/cloud.cfg.d/00-distro.cfg in their cloud-init package as the way
to differentiate between clients.
>
> [name=Ryan Harper] Given the list of "official" clients; then do you
expect upstream cloud-init to include config templates for each of these
clients?
  >[name=Scott Moser] Yes eventually. Right now we only support
systemd-timesyncd and isc-ntp.  We don't have to carry files identical to
those installed by the distro though. Antother option that is used in ssh
is to parse the file and make changes.
>
> [name=Robert Schweikert] I would, yes. If we support the various clients
then as a pckager on the distro side I think cloud-init should do the
"right" thing, i.e. render a config for the time sync client based on the
values in cloud.cfg

The default upstream value will be `auto`.  A value of `auto` indicates
that the ntp module will select and configure an ntp client. The selection
of an ntp client will follow the following guidelines

  * Preference will be given to clients that are already installed.
  * If multiple ntp client packages are installed, the behavior is not
defined other than that one will be selected and configured.
  * If no ntp client packages are installed behavior is again undefined.

Cloud-init as an upstream will strive to be backwards compatible given
identical inputs.  That is to say that an upgrade to cloud-init in an image
with no other changes should not result in a different client being chosen.
> [name=Scott Moser] I am not making a decision here on *where* this logic
> exists just yet.  It could be in cc_ntp or as a
`distro.get_ntp_client_info()`
> function.

## Distro Changes
The package maintainers of the Ubuntu cloud-init package will carry patches
to ensure that `isc-ntp` is chosen on Ubuntu 16.04 even though
`systemd-timesyncd` is already present in the official images.

## Upstream Changes
 * make configuration of ntp inspect `system_info/ntp_client`.
 * extend the `ntp` configuration namespace to include a boolean `enabled`
   to allow for explicitly turning ntp on to whatever default settings
   come with the operating system.  For example:

       ntp:
         enabled: true

> [name=Robert Schweikert] Does this imply the "auto" mode is only
applicable if the user sets at least "enabled: true"?  That would be my
interpretation and I am in favor of that approach.
>
> Overall I think teasing the configuration appart as proposed is a
workable approach. My primary concern remains with the  "auto" setting, as
indicated in the comment above and the decision tree to make "auto" work
without "external" file
> dependency that would impose some inconcveniences on testing

> [name=Scott Moser] "auto" is the default if not set.  Currently if you
put 'ntp: True' in user-ata or system config, then cloud-init will go down
the path of configuring ntp.  That is fine, but someone convoluted.  We
want to add an obvious declarative way to enable ntp with no declaration of
pool or servers.
> You shouldn't worry too much about testing.  The tests for ntp are kind
of difficult right now, but they can and should be cleaned up.
>

On Wed, Nov 15, 2017 at 1:10 PM, Robert Schweikert <rjschwei@xxxxxxxx>
wrote:

> Well it was a long day yesterday, the subject should of course have been
> "RFC"
>
> And there should have been a link
>
> On 11/14/2017 07:17 PM, Robert Schweikert wrote:
> > Hi,
> >
> > [1] is an initial rough implementation to support chrony and I'd
> > appreciate comments/feedback before I go on and fix the failing tests
> > and clean things up.
> >
>
> Thanks to the mistakes I get to give this a bump ;)
>
> Later,
> Robert
>
> [1]
> https://git.launchpad.net/~rjschwei/cloud-init/commit/?id=
> eff741ac400db0b2a523750829fc8af91a63770e
>
>
> --
> Robert Schweikert                   MAY THE SOURCE BE WITH YOU
> Distinguished Architect                       LINUX
> Team Lead Public Cloud
> rjschwei@xxxxxxxx
> IRC: robjo
>
>
> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to     : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help   : https://help.launchpad.net/ListHelp
>
>