Allow to choose ntpq rather than chrony on Bionic

[Pedro Guimarães]

According to lib/ntp_implementation.py:

def get_implementation(implementation_name=None):
    """Select the appropriate NTP implementation for this platform."""
    if implementation_name is not None and implementation_name.lower() == 'chrony':
        return Chronyd()
    if implementation_name is not None and implementation_name.lower() == 'ntpd':
        return NTPd()

    # anything else: auto mode
    platform = charmhelpers.osplatform.get_platform()
    version = float(charmhelpers.core.host.lsb_release()['DISTRIB_RELEASE'])

    if platform == 'ubuntu':
        if version > 18:
            # Ubuntu 18.04 or later: use chronyd
            return Chronyd()
        else:
            # Ubuntu 17.10 or earlier: use ntpd
            return NTPd()

I can only choose NTPd service rather than Chronyd if I am running Xenial or older. However, for integration reasons (e.g. Contrail 5: https://github.com/Juniper/contrail-charms/issues/45) I may need to use Bionic with ntpq enabled.

Therefore, we need to have a config option that allows to manually override this selection.

[Paul Gear (paulgear)]

@pguimaraes - Could you please provide some further information about how contrail uses ntpq? I couldn't find any reference to it in the issue you linked to or the documentation it referenced.

The decision to only support chronyd on bionic in the ntp charm was made because ntpd is no longer receiving security support, and thus it's not recommended to use it on bionic and later releases.

[Pedro Guimarães (pguimaraes)]

@paulgear, you can find references on this thread at Juniper's site: https://kb.juniper.net/InfoCenter/index?page=content&id=KB30672

Thats also what Juniper states in order for Contrail to run correctly. I am currently deploying contrail at a customer and I need that to be set up. I wrote a charm for that but I think it should be an option on NTP's official charm rather than sth separated.

[Pedro Guimarães (pguimaraes)]

Subscribing field-critical as this is a potential blocker to customer handover

[Dean Henrichsmeyer (dean)]

A feature request cannot be ~field-critical. I'm OK with medium but this doesn't fit the definition of the SLA.

[Pedro Guimarães (pguimaraes)]

Hi, Contrail runs the following command, internally, to sync itself:

ntpq -n -c pe
(reference: https://kb.juniper.net/InfoCenter/index?page=content&id=KB30672).

In order for contrail 5.0.2 to work correctly, it needs to have ntpq available. I understand and agree that Chrony should be the solution of choice by default for Bionic. However, we need a way to manually override that to provide compatibility with third-party solutions our tools are supposed to integrate with.

[Paul Gear (paulgear)]

There's an easy interim solution for this until Contrail chronyd support is available: pin the NTP charm to the last pre-chrony version (cs:ntp-28). It supports bionic and always installs ntpd. This would be far preferable than adding code back into the charm to support a toggle that we really don't want people using.

[Pedro Guimarães (pguimaraes)]

A good, I prefer that solution rather than adding code as well.

[Przemyslaw Hausman (phausman)]

I can confirm that cs:ntp-28 installs ntpd.

See my testing log: https://pastebin.ubuntu.com/p/3BvTGmzfKj/

[Paul Gear (paulgear)]

Good to hear that's a suitable solution. @phausman, for the record, the `ntpd -gq`in your pastebin shouldn't have been necessary - it does exactly what ntpd would have done when started normally, and then exits. How long did you wait between deployment of the charm and your `ntpq -np`?

[Tom Haddon (mthaddon)]

How long do you expect to need to run this version of the charm? Pinning is fine as a workaround but means you're now on a version that's not getting updates (as you can't update past it), so you'd end up having to backport any fixes to a custom charm version if any were needed in the future. Does that seem possible?

[Tom Haddon (mthaddon)]

Paul mentioned to me that in https://github.com/Juniper/contrail-charms/issues/45 it's mentioned that the latest version supports chrony, so this would only have to last until that fix is released. Given that, I agree pinning is a good option.

[Chris Sanders (chris.sanders)]

It appears that the contrail charm, independent of the contrail version in use, has a fix for this. If this is the case it would seem to me a charm update (not a contrail version update) will work fine to make this a won't fix.

[Nicolas Pochet (npochet)]

We can go with 5.0.2 version, which works fine but does only accepts NTPq.
We can also go with 5.0.3, which accepts Chrony BUT introduces issues with Contrail RBAC + Keystone.
At the moment, our only real choice is to go with 5.0.2 as the customer wants to use RBAC. It is then needed to have NTPq installed on the hosts/KVM/LXDs where the Contrail elements are deployed.

[Chris Sanders (chris.sanders)]

Due to issues with Contrail 5.0.3 only version 5.0.2 is viable today and the decision if/when to upgrade to 5.0.4+ is dependent on bug fixes and customer timelines at this point. Due to this we can not commit to any specific timeline to remove the ntpq requirement and we should move forward with updating the charm rather than pinning. We can not use an out of support charm for the official support with no timeline to move back to the supported charm version.