PR progress checklist (to be filled in by reviewers)
[ ] Changes to documentation are appropriate (or tick if not required)
[ ] Changes to tests are appropriate (or tick if not required)
[ ] Reviews completed
What type of PR is this?
Primary type
[ ] [build] Changes related to the build system
[ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[ ] [ci] Changes to the continuous integration configuration
[ ] [feat] A new feature
[ ] [fix] A bug fix
[ ] [perf] A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert] A change used to revert a previous commit
[ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
Secondary type
[ ] [docs] Documentation changes
[ ] [test] Adding missing or correcting existing tests
Does this PR introduce a BREAKING CHANGE?
No.
Related issues and/or pull requests
Describe the changes you're proposing
currently using the ntp.ng formula on a fresh install of ubuntu 20.04
----------
ID: ntp
Function: pkg.installed
Result: True
Comment: All specified packages are already installed
Started: 15:49:48.511202
Duration: 74.385 ms
Changes:
----------
ID: ntpd_conf
Function: file.managed
Name: /etc/ntp.conf
Result: True
Comment: File /etc/ntp.conf is in the correct state
Started: 15:49:48.586885
Duration: 53.075 ms
Changes:
----------
ID: ntpd
Function: service.None
Name: ntp
Result: False
Comment: State 'service.None' was not found in SLS 'ntp.ng'
Reason: 'service.None' is not available.
Changes:
This is because right now the existing logic will always run as the mapped data supplied in ntp.ng will always trigger a potentially un-needed (depending on usecase) part of the conf. as this data is being merged with pillar data there is no way to remove the ntp:ng:settings:ntpd key. the variable can be overridden, but the key can not be removed.
due to this the current logic check is pointless as it is ALWAYS true.
also the above logic is failing due to lack of ubuntu lookup hence the service.None failure. I would have expected being able to disable this service mgmt as there is an if statement around it, however that statement is always true(see above block)
Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
[ ] Updated the README (e.g. Available states).
[ ] Updated pillar.example.
Testing checklist
[ ] Included in Kitchen (i.e. under state_top).
[ ] Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?No.
Related issues and/or pull requests
Describe the changes you're proposing
currently using the ntp.ng formula on a fresh install of ubuntu 20.04
This is because right now the existing logic will always run as the mapped data supplied in ntp.ng will always trigger a potentially un-needed (depending on usecase) part of the conf. as this data is being merged with pillar data there is no way to remove the ntp:ng:settings:ntpd key. the variable can be overridden, but the key can not be removed. due to this the current logic check is pointless as it is ALWAYS true.
also the above logic is failing due to lack of ubuntu lookup hence the service.None failure. I would have expected being able to disable this service mgmt as there is an if statement around it, however that statement is always true(see above block)
Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context