The Fedora distro is moving fast to drop all PY2 support, so we should do the same for it.

Relates to #12

Hi there! It would be nice to have auto-generated Vagrant images to test with Kitchen Vagrant.

Some formulas are almost impossible to test with Docker (at least nfs and syslog-ng) so we should use Vagrant to test them. I've read that Vagrant don't work on Travis but works on Cirrus.

I'm working on a full Vagrant Kitchen file for syslog-ng formula

cc @myii

It seems it can be installed using packages, so we should try to see if either the bootstrap supports it, or we should add the repo directly.

Lint all Dockerfile files using something like:

• https://hadolint.github.io/hadolint/

Eventually could add as a lint stage in Travis, if it works out well.

I don't know if these images are automatically rebuilt on a schedule but there is a showstopper bug in 2019.2.1 which will cause formula tests to fail when running against the latest version of Salt, (see saltstack/salt#54765) and I feel it may be best not to roll out that version.

This issue shouldn't be allowed, explaining that this repo has moved to GitLab.

https://travis-ci.org/myii/django-formula/jobs/616733137#L788-L794

       [DEBUG   ] Failed to import module pip:
       Traceback (most recent call last):
         File "/usr/lib/python2.7/site-packages/salt/loader.py", line 1440, in _load_module
           mod = imp.load_module(mod_namespace, fn_, fpath, desc)
         File "/usr/lib/python2.7/site-packages/salt/modules/pip.py", line 86, in <module>
           import pkg_resources
       ImportError: No module named pkg_resources

https://travis-ci.org/myii/django-formula/jobs/616733137#L950-L958

       local:
       ----------
                 ID: django_pip
           Function: pip.installed
               Name: Django
             Result: False
            Comment: State 'pip.installed' was not found in SLS 'django.pip'
              Reason: 'pip.installed' is not available.
            Changes: 

https://stackoverflow.com/questions/7446187/no-module-named-pkg-resources

• Tried out some of the answers here but didn't make any progress

Stating with PR saltstack-formulas/postgres-formula#262 and then in the https://github.com/saltstack-formulas/template-formula/, @myii found that the opensuse instances were failing and/or timing out in travis runs but not when run locally.

Running them in debug mode, it seems that there's an issue with the GEO-repositories download.opensuse.org chooses for the US.

This is what I see:

1. When travis runs the install command, bundle exec kitchen verify default-opensuse-leap-15-2019-2-py3, it triggers a kitchen run. Which then begins the provision of the VM via kitchen-docker
2. kitchen-docker has a 'hardcoded' provisioning stage, which in our case is running a zypper install command before even getting to any of our kitchen-salt commands. So we cannot tweak the repos at the beginning of the provisioning because kitchen-docker does not provide any pre-provision commands
3. When doing this initial provisioning, download.opensuse.org is trying to use some US geo-repos, which are failing (ie, us.opensuse.org was used in one case and it can't even be found with a dig command).

To verify it, I did this:

1. Launched a debug run on job on the postgresql-formula
2. SSH'ed to the instance
3. Run

travis_run_before_install

4. Edited the suspect file

cd
vi ./.rvm/gems/ruby-2.4.1/gems/kitchen-docker-2.9.0/lib/kitchen/driver/docker.rb

and added, before the RUN zypper install -y sudo openssh which curl command, the following lines:

  WORKDIR /etc/zypp/repos.d
  RUN for f in *; do sed -i "s#download.opensuse.org#mirror.23media.com/opensuse#g" $f; done

5. Then went back to the formula dir and run the kitchen test

  cd -
  bundle exec kitchen verify default-opensuse-leap-15-2019-2-py3

6. The test finished successfully in <2 minutes

-----> Kitchen is finished. (1m54.71s)

As we can't modify these parameters at run time, we should try to modify the opensuse/leap instances to forcedfully use another repo (ie, a .de one)

As discussed on Slack, also logged here.

• https://travis-ci.com/saltstack-formulas/postgres-formula/jobs/196624895#L1022
• saltstack/salt#50531

I would like to test ubuntu,16.04,2019.2,stable,3

is it possible to bring this to upstream's images ?

Thanks and Regards

Gave most of the matrix a pretty solid test:

• https://travis-ci.org/myii/varnish-formula/builds/615198256

While I got the other two working in a subsequent run, the error for default-fedora-30-2017-7-py2 is a bit deeper:

• https://travis-ci.org/myii/varnish-formula/jobs/615223826#L1402-L1403

            Comment: State 'pkgrepo.managed' was not found in SLS 'varnish.ng.repo'
             Reason: 'pkgrepo' __virtual__ returned False

Not specific to fedora-30, since default-fedora-30-2018-3-py3 is working fine.

So in terms of:

Perhaps building with stable instead?

To keep up to date the description of the images pushed to dockerhub, we should either push from the travis build the descriptions for each repo, or pull it from there.

Some ideas can be found here

Follow on from #27 to do this for all of the rest of the platforms (Debian and Ubuntu have been done).

As discussed with @myii , travis is currently using a VM per build so, even if we're running 3 builds at a time, we're not reusing docker layers and caches.

We should try to split the matrix either by OS or OS/SALT_VERSION/PY_VERSION to see if reusing layers improve building.

Following on from #2, tried opensuse-leap-42-2018-3-py2 instead. Ended up with a different error, even after retrying.

https://travis-ci.com/myii/postgres-formula/builds/110123552#L1135

       [ERROR   ] Failed to import states pip_state, this is due most likely to a syntax error:
       Traceback (most recent call last):
         File "/usr/lib/python2.7/site-packages/salt/loader.py", line 1534, in _load_module
           mod = imp.load_module(mod_namespace, fn_, fpath, desc)
         File "/usr/lib/python2.7/site-packages/salt/states/pip_state.py", line 63, in <module>
           del pip
       NameError: name 'pip' is not defined

Strange, because 2017.7 is working fine:

• https://travis-ci.com/saltstack-formulas/postgres-formula/jobs/196624899

Was looking at:

• saltstack-formulas/php-formula#205

Which itself was based on:

• saltstack-formulas/php-formula#156 (merged by @javierbertoli!)

Tried to get a Gentoo docker image running but it is a very difficult proposition. Unless I'm missing something, there's no way this is going to be achieved as part of the Travis matrix, the build takes forever.

However, if we can prepare a pre-salted image manually, could we just maintain and upload this separately?