On Wed, Mar 8, 2017 at 9:02 AM, Scheglmann, Stefan <scheglm...@strato.de> wrote: > Hey Alex, > > thx for the reply, unfortunately it doesn’t seem to work. Adding > PUPPET_MAJ_VERSION to the call seems not to have any effect. >
I just read the bottom part of the original message and it's getting a 14.04 box from puppet-ceph/spec/acceptance/nodesets/default.yml. You could try changing that to 16.04. For our CI we're using the nodepool-xenial.yml via BEAKER_set=nodepool-xenial.yml but that assumes you're running on localhost. You could try grabbing the 1604 configuration from puppet-openstack_extras[0] and putting that in your spec/acceptance/nodesets folder to see if that works for you. Then you should able to run: PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 BEAKER_set=ubuntu-server-1604-x86 bundle exec --verbose rspec spec/acceptance If you run in to more problems, you may want to try hopping on IRC and we can help you in #puppet-openstack on freenode. Thanks, -Alex [0] https://github.com/openstack/puppet-openstack_extras/blob/master/spec/acceptance/nodesets/ubuntu-server-1604-x64.yml > > Stefan >> On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan <scheglm...@strato.de> >> wrote: >>> Hi, >>> >>> currently got some problems running the beaker test for the puppet-cep >>> module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version >>> 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose >>> rspec spec/acceptance? output in http://pastebin.com/w5ifgrvd >>> >> >> Try running: >> PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec >> --verbose rspec spec/acceptance >> >> Thanks, >> -Alex >> > > Tried this, this just changes the trace a bit, now it seems like that it > worked in the first place but then failed for the same reason. > Trace here: > > >>> Trace: >>> An error occurred in a `before(:suite)` hook. >>> Failure/Error: raise CommandFailure, "Host '#{self}' exited with >>> #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]} >>> lines of output were:\n#{result.formatted_output(@options[:trace_limit])}" >>> Beaker::Host::CommandFailure: >>> Host 'first' exited with 127 running: >>> ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash >>> openstack/puppet-openstack-integration/install_modules.sh >>> Last 10 lines of output were: >>> + '[' -n 'SHELLOPTS=braceexpand:hashall:interactive-comments:xtrace >>> if [ -n "$(set | grep xtrace)" ]; then >>> local enable_xtrace='\''yes'\''; >>> if [ -n "${enable_xtrace}" ]; then' ']' >>> + set +x >>> >>> -------------------------------------------------------------------------------- >>> | Install r10k >>> | >>> >>> -------------------------------------------------------------------------------- >>> + gem install fast_gettext -v '< 1.2.0' >>> openstack/puppet-openstack-integration/install_modules.sh: line 29: >>> gem: command not found >>> >>> It seems like that the box beaker is using >>> (puppetlabs/ubuntu-14.04-64-nocm), somehow ends up with has puppet 4.x >>> installed. I could not exactly pin down how this happens, cause when i sin >>> up some VM just from that base box and install puppet, i end up with 3.4. >>> But during the beaker tests it ends up with puppet 4 and in puppet 4 some >>> paths have changed. /opt/puppetlabs/bin is just for the 'public' >>> applications and the ?private' ones like gem or ruby are in >>> /opt/puppetlabs/puppet/bin. Therefore the >>> openstack/puppet-openstack-integration/install_modules.sh script fails on >>> installation of r10k, cause it cannot find gem and later on it fails on the >>> r10k call cause it is also installed to /opt/puppetlabs/puppet/bin. >>> Symlinking gem and r10k in an provisioned machine, and rerun the tests >>> fixes the problem. Currently i am doing all this cause i added some >>> functionalities for the puppet-cep manifests to support bluestone/rocksdb >>> and some additional config params which i would like to see in upstream. >>> >>> >>> Greets Stefan >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
