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

Add repo state and possibility to specify package name #151

Merged
merged 3 commits into from
Jul 23, 2018

Conversation

javierbertoli
Copy link
Member

@javierbertoli javierbertoli commented Jun 25, 2018

This PR tried to address #150, adding a separate state to manage repos repo.sls.

When testing, found many issues due to old/deprecated versions/repos, so I tried to refactor the formula to be more up-to-date:

  • Added support for testing on:

    • ubuntu-1804
    • debian-stretch
    • debian-jessie
  • Added osfamilymap.yaml

  • Updated repo info

This probably can fix/close #109, #150, #131, #136 and #95

I'm not using this formula heavily, so if you can check this PR and make suggestions, any comment will be welcome.

It seems that a lot of refactoring is needed to clean old stuff and perhaps this PR helps to start doing it 😄

@@ -2,9 +2,9 @@


def test_package_is_installed(Package):
docker = Package('docker-engine')
docker = Package('docker-ce')
Copy link
Member

@noelmcloughlin noelmcloughlin Jun 28, 2018

Choose a reason for hiding this comment

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

Could the package name be referenced as variable?

Copy link
Member

@noelmcloughlin noelmcloughlin Jun 28, 2018

Choose a reason for hiding this comment

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

See #153 could you use docker:pkg:name here (and elsewhere) please?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can't use a saltstack pillar var in test python code without non-trivial work

assert docker.is_installed
assert docker.version.startswith('1.12.2')
assert docker.version.startswith('18.03.1')
Copy link
Member

Choose a reason for hiding this comment

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

Could the package version be configurable?

Copy link
Member

Choose a reason for hiding this comment

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

See #153 could you use docker:pkg:version here (and elsewhere) please?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can't use a saltstack pillar var in test python code without non-trivial work

Copy link
Member Author

Choose a reason for hiding this comment

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

Adding to what @blbradley says:

I'm particularly reluctanct to use pillar data directly in testing code: I write testing to make sure that the whole formula (states + default pillar data) is correct and does what I expect from it.

To put an example, if I set a "wrong", installable, docker:pkg:version in the formula, like "17.03.1", and test it, It will work OK, tests will pass.

The "states" are right, but the formula will install "17.03.1" and will not be doing what I want.

I don't know if I'm clear in what I mean...

Again, that's me, and I'm OK doing it the way @noelmcloughlin suggest if you prefer that way.

Copy link
Member

Choose a reason for hiding this comment

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

Hi @javierbertoli @blbradley I'm okay with not complicating things so leave this as is!! thx

@@ -9,4 +9,17 @@ services:
before_install:
- bundle install

script: bundle exec kitchen verify

env:
Copy link
Contributor

Choose a reason for hiding this comment

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

Are you sure you need this? I think the matrix is controlled by suiteXplatform in Test Kitchen.

@blbradley
Copy link
Contributor

I don't really use this formula anymore but will give some suggestions.

@blbradley
Copy link
Contributor

What version of Docker does the default suite test these days?

.travis.yml Outdated
- INSTANCE: default-debian-stretch
- INSTANCE: default-debian-jessie
- INSTANCE: default-centos-7
- INSTANCE: version-1122-ubuntu-1804
Copy link
Contributor

Choose a reason for hiding this comment

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

Hey I think these names need to start version-18031 now. Right? If you all choose to keep this. This is one reason I let Test Kitchen just control the test matrix.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep! See the errors in Travis:

No instances for regex version-1122-ubuntu-1804', try running kitchen list'

@blbradley
Copy link
Contributor

Thanks for the quality updates, @javierbertoli. I won't give a 👍 or 👎 on this because I'm not a user of this formula anymore. But I'm happy to answer any questions about the test suite if you hit any trouble.

@noelmcloughlin
Copy link
Member

Hi @javierbertoli Do you need me to work with you on this?

@javierbertoli
Copy link
Member Author

Hey, sorry. I'm having some unrelated, Real Life (TM) issues that left me litte time to advance on this 😋

I have some commits that failed local tests, that I need to review and push. I'll see if I can push them today/tomorrow. Is it ok? Or do you prefer I push them as they are, so we can review them?

@noelmcloughlin
Copy link
Member

@javierbertoli No worries, in your own time!!! Good luck

@javierbertoli
Copy link
Member Author

javierbertoli commented Jul 21, 2018

@noelmcloughlin, @blbradley, updated the PR. Had to remove testing on CentOS, as docker-in-docker fails. Updated to test Debian 8/9 & Ubuntu 18.04.

To keep things backward-ish compatible, kept the use_old_repo parameter & repo, but kept it somewhat 'hardcoded', as the new format is capable of managing all the parameters (repo & package) to install any package from any repo. I think in a future iteration we can remove the old parameters.

I think the formula needs a some cleanup and refactoring (ie, I think that kernels.sls can probably be removed now), but that can be done in future PRs.

Please let me know if you have any suggestions or want anything else done in the PR.

@@ -1,10 +1,11 @@
{% from "docker/map.jinja" import docker with context %}

{%- if docker.kernel is defined and grains['os_family']|lower == 'debian' %}
pkgrepo dependencies:
pkg.installed:
- name: python-apt
Copy link
Member

Choose a reason for hiding this comment

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

Good fix. There is no python-apt package on non-Debian distros so state fails.

@noelmcloughlin
Copy link
Member

Should we just dump the use_old_repo support in this PR - because nobody needs this?

@javierbertoli
Copy link
Member Author

Don't know. If you ask me, I'd dump it, same with the kernel.sls state file, as those things are not needed anymore. But didn't want to add too much refactoring in this PR (as it already is, is quite big), so I'm OK with adding a few follow ups to clean the formula. Wdyt?

@noelmcloughlin
Copy link
Member

Yes - followup would be appreciated if someone can make time. This LGTM as is, and future PR can progress things. Thanks @javierbertoli

@aboe76 aboe76 merged commit 0827056 into saltstack-formulas:master Jul 23, 2018
@aboe76
Copy link
Member

aboe76 commented Jul 23, 2018

@javierbertoli and @noelmcloughlin merged it.

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

Successfully merging this pull request may close these issues.

Recent docker and CentOS 7 support
4 participants