Merge ~rjschwei/cloud-init:chrony into cloud-init:master
| Status: | Needs review | ||||
|---|---|---|---|---|---|
| Proposed branch: | ~rjschwei/cloud-init:chrony | ||||
| Merge into: | cloud-init:master | ||||
| Diff against target: |
812 lines (+439/-40) (has conflicts) 14 files modified
cloudinit/config/cc_ntp.py (+51/-18) cloudinit/distros/__init__.py (+40/-0) cloudinit/distros/arch.py (+4/-0) cloudinit/distros/debian.py (+4/-0) cloudinit/distros/freebsd.py (+4/-0) cloudinit/distros/gentoo.py (+4/-0) cloudinit/distros/opensuse.py (+45/-0) cloudinit/distros/rhel.py (+4/-0) templates/chrony.conf.opensuse.tmpl (+25/-0) templates/chrony.conf.sles.tmpl (+25/-0) tests/unittests/test_distros/test_generic.py (+96/-5) tests/unittests/test_distros/test_opensuse.py (+43/-1) tests/unittests/test_distros/test_sles.py (+29/-1) tests/unittests/test_handler/test_handler_ntp.py (+65/-15) Conflict in cloudinit/config/cc_ntp.py |
||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Server Team CI bot | continuous-integration | Needs Fixing on 2017-12-18 | |
| Ryan Harper | 2017-12-08 | Needs Fixing on 2017-12-18 | |
|
Review via email:
|
|||
Description of the Change
Support chrony configuration (lp#1731619)
+ Add a template for chrony configuration
+ Add new set_timesync_client to distros base class
- Set the timesync client provided in the config by the user with
system_info: ntp_client
- If no user config set the timesync client to one of the supported
clients if the executable is installed
- Fall back to the distribution default
+ Handle the new settings in cc_ntp while retaining current behavior
as the fallback until all distro implementations have switched to the
new implementation
+ Use new way of ntp client configuration for openSUSE and SLES
+ Unit tests
Follows along the ideas discussed here: https:/
- d94392b... by Robert Schweikert on 2017-12-08
PASSED: Continuous integration, rev:d94392bb6e5
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Ryan Harper (raharper) wrote : | # |
Thanks for getting this started. For reference more of these changes were
discussed here: https:/
I'd like to drop the bulk of the logic in cc_ntp and push those into either the base distro class or specific distro classes as needed. cc_ntp would look much simpler, basically, checking the configuration dictionary/
def handle(name, cfg, cloud, log, _args)
# check for 'ntp' in config and bail if not present
valid_
distro.
We won't need to check for attributes, introduce the configure_ntp as part of the base
class were we handle any cross-distro actions and then call into per-distro methods
DistroBase
def configure_ntp(cfg)
The _select_
ntp_cfg, systemcfg and state to determine the correct client.
The rest I think can be common given the client selection and configuration
since we're rendering configs with templates (or the config format is common
like in systemd-timesyncd).
The schema/example configuration needs an update, specifically we need to reference that
we not have:
ntp:
enabled: true
To allow users to explicitly enable/disable, specifically for the case of using the
distro default ntp configuration.
| Robert Schweikert (rjschwei) wrote : | # |
> Thanks for getting this started. For reference more of these changes were
> discussed here: https:/
>
> I'd like to drop the bulk of the logic in cc_ntp and push those into either
> the base distro class or specific distro classes as needed. cc_ntp would look
> much simpler, basically, checking the configuration dictionary/
> and call into the distro with the config.
>
> def handle(name, cfg, cloud, log, _args)
> # check for 'ntp' in config and bail if not present
> valid_cloudconf
> distro.
>
> We won't need to check for attributes, introduce the configure_ntp as part of
> the base
> class were we handle any cross-distro actions and then call into per-distro
> methods
>
> DistroBase
>
> def configure_ntp(cfg)
> client_name = _select_
> _write_
> _restart_
>
> The _select_
> ntp_cfg, systemcfg and state to determine the correct client.
>
> The rest I think can be common given the client selection and configuration
> since we're rendering configs with templates (or the config format is common
> like in systemd-timesyncd).
>
>
> The schema/example configuration needs an update, specifically we need to
> reference that
> we not have:
> ntp:
> enabled: true
>
> To allow users to explicitly enable/disable, specifically for the case of
> using the
> distro default ntp configuration.
Two concerns here with doing all of this at once, although I do have to agree that we'll probably end up with cleaner code earlier.
1.) Doing all of this at once potentially causes lots of upheaval as the core logic of cc_ntp would change. Unless there is some other mechanism, other than checking attributes to split the code path between old behavior and new behavior.
2.) Config compatibility, if we enforce
ntp:
enabled: true
which I think that is being suggested then basically we are making an incompatible config file change, meaning any one who has
ntp:
.....
in their config at this point needs to add "enabled: true"
That's fair enough, just want to make sure everyone is on the same page.
| Ryan Harper (raharper) wrote : | # |
On Mon, Dec 18, 2017 at 12:50 PM, Robert Schweikert <email address hidden>
wrote:
> > Thanks for getting this started. For reference more of these changes
> were
> > discussed here: https:/
> >
> > I'd like to drop the bulk of the logic in cc_ntp and push those into
> either
> > the base distro class or specific distro classes as needed. cc_ntp
> would look
> > much simpler, basically, checking the configuration
> dictionary/
> > and call into the distro with the config.
> >
> > def handle(name, cfg, cloud, log, _args)
> > # check for 'ntp' in config and bail if not present
> > valid_cloudconf
> > distro.
> >
> > We won't need to check for attributes, introduce the configure_ntp as
> part of
> > the base
> > class were we handle any cross-distro actions and then call into
> per-distro
> > methods
> >
> > DistroBase
> >
> > def configure_ntp(cfg)
> > client_name = _select_
> > _write_
> > _restart_
> >
> > The _select_
> > ntp_cfg, systemcfg and state to determine the correct client.
> >
> > The rest I think can be common given the client selection and
> configuration
> > since we're rendering configs with templates (or the config format is
> common
> > like in systemd-timesyncd).
> >
> >
> > The schema/example configuration needs an update, specifically we need to
> > reference that
> > we not have:
> > ntp:
> > enabled: true
> >
> > To allow users to explicitly enable/disable, specifically for the case of
> > using the
> > distro default ntp configuration.
>
> Two concerns here with doing all of this at once, although I do have to
> agree that we'll probably end up with cleaner code earlier.
>
> 1.) Doing all of this at once potentially causes lots of upheaval as the
> core logic of cc_ntp would change. Unless there is some other mechanism,
> other than checking attributes to split the code path between old behavior
> and new behavior.
>
The "old" path is maintained by including a patch to configure the "legacy"
client name during packaging. Even if the code moves from cc_ntp into
distro; the input/output remains the same, and can be exercised with
a system config that specifies the legacy ntp_client value.
That is, the existing unittests which take the config dictionary of
servers/pools would also need a system_config which sets ntp_client =
'isc-ntp' and validates the 'old behavior'.
We'd also add new tests which leave system_config unset (using code
defaults, or set system config to other values) and will validate the new
behavior.
> 2.) Config compatibility, if we enforce
>
> ntp:
> enabled: true
>
> which I think that is being suggested then basically we are making an
> incompatible config file change, meaning any one who has
>
> ntp:
> .....
>
> in their config at this point needs to add "enabled: true"
>
This will need compat patches included in previous release updates to
maintain behavior (and likely emitting a warning).
On master, such a...
- 42cb184... by Robert Schweikert on 2017-12-18
FAILED: Continuous integration, rev:42cb1841035
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
Unmerged commits
- 42cb184... by Robert Schweikert on 2017-12-18
- d94392b... by Robert Schweikert on 2017-12-08
- 23f976b... by Robert Schweikert on 2017-11-14


FAILED: Continuous integration, rev:23f976be51b a9ad6e1e173f23c 7220144beb942a /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 603/
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild: /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 603/rebuild
https:/