# 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.
>