Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test(pillar): use static test/salt/pillar/top.sls #238

Merged
merged 2 commits into from
Nov 16, 2021

Conversation

baby-gnu
Copy link
Contributor

@baby-gnu baby-gnu commented Aug 18, 2021

The kitchen-salt provisionner have the pillars_from_directories option to recusively copy directories under target pillar root.

This has 3 advantages:

  • simplify kitchen.yml

  • manage pillar assignment with standard salt targetting mechanism, this avoid the dedicated gentoo suite (it could have been done from kitchen.yml itself by the way)

  • ease the test outside kitchen by running salt-call directly with --pillar-root like:

    salt-call --local --id test-minion.example.net --file-root=template-formula/ --pillar-root=template-formula/test/salt/pillar/ state.show_sls TEMPLATE
    
  • test/salt/pillar/top.sls: limit gentoo pillars based on os_family grain.

  • kitchen.yml (suites): remove the now useless gentoo suite.
    Define an empty required pillars to not override static top.sls
    Define pillars_from_directories to copy them under pillar_root.

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

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.).
  • Updated the relevant test pillar.

Additional context

@baby-gnu baby-gnu requested review from a team as code owners August 18, 2021 09:49
@baby-gnu baby-gnu force-pushed the test/pillar-top-from-file branch 3 times, most recently from f1b657b to 7fc9982 Compare August 18, 2021 09:59
@myii
Copy link
Member

myii commented Aug 19, 2021

Thanks, @baby-gnu. This looks like a nice idea.

This will also necessitate some changes in how the ssf-formula works, so I'm going to need a little while to get around to this. Currently got a bit of a backlog due to the 3003.2 release, etc.

@baby-gnu
Copy link
Contributor Author

This will also necessitate some changes in how the ssf-formula works, so I'm going to need a little while to get around to this. Currently got a bit of a backlog due to the 3003.2 release, etc.

Thanks, it was an idea inspired by a user in SaltStack matrix room, it's not urgent.

Copy link
Member

@myii myii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@baby-gnu I like the idea of this PR and I reckon we could benefit from using pillars_from_directories in various formulas. However, we've got a few situations to consider, which I've mentioned inline.

NOTE: I haven't had a chance to actually test any of the ideas suggested, yet.

kitchen.yml Outdated Show resolved Hide resolved
Comment on lines -479 to -425
pillars:
top.sls:
base:
'*':
- TEMPLATE
- gentoo
- define_roles
Copy link
Member

@myii myii Aug 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably can avoid a dedicated test/salt/pillar/top.sls and just adapt the same method used in other formulas under state_top.

Some examples:

Suggested change
pillars:
top.sls:
base:
'*':
- TEMPLATE
- gentoo
- define_roles
pillars:
top.sls:
base:
'*':
- TEMPLATE
- define_roles
'G@os_family:Gentoo':
- gentoo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, It could be done from kitchen.yml directly but the main point of having a dedicated top.sls is to be able to run it outside kitchen.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@baby-gnu I haven't come across this idea before -- could you give me an example of this being run outside of Kitchen? Does this also apply to the using the state_top's top.sls as a separate file as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea came from user colttt on SaltStack matrix room to better validate formula since salt-lint does not cover all possible errors.

colttt uses the following command to compile the states:

salt-call --id=test-minion.example.de --local --file-root=/srv/salt/states --pillar-root=/srv/salt/pillars --retcode-passthrough state.show_sls

But it can't be done easily when the formula requires pillars.

Then, my idea is to provide all the necessary to try out a formula in two steps:

  1. clone the formula:
    git clone https://github.com/saltstack-formulas/template-formula.git && cd template-formula
    
    
  2. execute the formula locally with our test pillar values:
    salt-call --local --id test-minion.example.net --file-root=./ --pillar-root=./test/salt/pillar/ state.show_sls TEMPLATE
    

There is no point in having state_top's top.sls in a dedicated file too since there is no salt-call option to select that file and I think we should avoid having one in the formula directory referenced by the --file-root option above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@baby-gnu The example you've shared doesn't appear to work, because the TEMPLATE pillar (i.e. pillar.example) is not in that directory:

[ERROR   ] Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master
[ERROR   ] Template was specified incorrectly: False
[CRITICAL] Pillar render error: Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master
Error running 'state.show_sls': Pillar failed to render. Additional info follows:

- Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master

If I comment out the TEMPLATE line in the newly provided top.sls, then the state runs -- but obviously missing everything from pillar.example (the TEMPLATE pillar).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's an issue.

To be completely functional, the test/salt/pillar/ should contains all the required files, in which case:

  • the pillars_from_files is no more used
  • the pillar.example is just an example and not a seed for tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I push a second commit to move testing values from pillar.example to test/salt/pillar/TEMPLATE.sls and remove pillars_from_files from kitchen.yml.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@baby-gnu If we're going to attempt to use these ideas across existing formulas then that's not going to be fun to refactor. There are more formulas using pillar.example in the CI than any other file. Due to that, it's the default value used from the ssf-formula as well.

We can discuss the relative merits of this idea in the upcoming meeting. I'm still not quite sure what the use cases are so it would great if you could demonstrate it.

test/salt/pillar/top.sls Outdated Show resolved Hide resolved
@myii
Copy link
Member

myii commented Aug 25, 2021

@baby-gnu I thought I'd familiarise myself with these changes by adapting it for the salt-formula. This is the commit I used, which is passing in the CI:

A couple of things I came across so far, which are valid for this PR as well:

  1. There's no need to use pillars: {} since that's the default provided by kitchen-salt.
  2. (I haven't done this in the commit there but) We probably need to remove the following line as well, since it prevents the top.sls from being git added except using -f:

top.sls


Tested it out with:

$ salt-call --local \
            --id test-minion.example.net \
            --file-root=./ \
            --pillar-root=./test/salt/pillar/ \
            --out=yaml \
            state.show_sls salt

@baby-gnu
Copy link
Contributor Author

You are right, I'll remove it on the final rework of this PR

  • (I haven't done this in the commit there but) We probably need to remove the following line as well, since it prevents the top.sls from being git added expect using -f:

I'm really not sure, I think we should keep it to avoid having a top.sls in the states tree, so I propose to use:

top.sls
!test/salt/pillar/top.sls

This way, all top.sls will be ignored except the test/salt/pillar/top.sls one.

@baby-gnu baby-gnu force-pushed the test/pillar-top-from-file branch 3 times, most recently from eba74d7 to c63f4d5 Compare August 30, 2021 13:01
test/salt/pillar/top.sls Outdated Show resolved Hide resolved
The kitchen-salt provisionner have the `pillars_from_directories`
option to recusively copy directories under target pillar root.

This has 3 advantages:

- simplify `kitchen.yml`

- manage pillar assignment with standard salt targetting mechanism,
  this avoid the dedicated `gentoo` suite (it could have been done
  from `kitchen.yml` itself by the way)

- ease the test outside kitchen by running `salt-call` directly with
  `--pillar-root` like:
  ```
  salt-call --local --id test-minion.example.net \
    --file-root=template-formula/ \
    --pillar-root=template-formula/test/salt/pillar/ \
    state.show_sls TEMPLATE
  ```

* pillar.example: remove settings for testing purpose.

* test/salt/pillar/top.sls: limit `gentoo` pillars based on `os_family`
  grain.

* test/salt/pillar/defaults.sls: base pillar dedicated to tests.

* kitchen.yml (suites): remove the now useless `gentoo` suite.
  Define `pillars_from_directories` to copy them under `pillar_root`.
  Remove useless `pillars_from_files`.

* .gitlab-ci.yml: fix gentoo suite name

* .gitignore: do not ignore test pillar `top.sls`
@myii myii merged commit 939e422 into saltstack-formulas:master Nov 16, 2021
@myii
Copy link
Member

myii commented Nov 16, 2021

Thanks for the patience, @baby-gnu -- merged.

Rebased your changes on the latest version of this formula (the CI instances had changed).

The main notes regarding the additional commit:

  1. Moved pillars_from_directories under provisioner instead of under suites, as discussed in the working group meetings.
  2. Used test/salt/pillar/default.sls instead of test/salt/pillar/defaults.sls, to maintain consistency with the large number of formulas out there (default suite has a default.sls pillar).
  3. Other minor consistency fixes, such as updating .travis.yml and CODEOWNERS.

@saltstack-formulas-travis

🎉 This PR is included in version 5.0.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants