At work, I'm taking over primary administration of a puppet deployment
that had previously been maintained by a contractor. Shortly before he
left, it upgraded from PE 3.X to 2016.2.0, and moved from r10k to Code
Manager.
This has been running well, but "something happened" yesterday where
code deploy started failing with:
ERROR -> Unable to determine current branches for Git source 'puppet'
(/etc/puppetlabs/code-staging/environments)
Original exception:
Git remote "ssh://g...@stash.example.com/puppet/puppetcode.git" uses
the SSH protocol but no private key was given at
/opt/puppetlabs/server/data/code-manager/worker-caches/deploy-pool-1/ssh---...@stash.example.com-ro-puppetcode.git
Going through the PE documentation, I discovered that a SSH private key
wasn't set up (suggesting that shell git had been being used instead of
rugged?), so I set puppet_enterprise::profile::master::r10_private_key
and forced a puppet run.
After that, deploys could fetch our control repository, but failed for
all our own modules in separate git repositories with a "Invalid
credential type"..
016-09-20 14:13:48,587 ERROR [deploy-pool-1] [p.c.core] Errors while
deploying environment 'dev' (exit code: 1):
INFO -> Deploying environment
/etc/puppetlabs/code-staging/environments/dev
INFO -> Environment dev is now at
f39d43d8e029c3208c98a76bf019387fa5cfa848
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/ntp
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/apt
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/concat
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/stdlib
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/sysctl
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/java
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/autofs
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/puppet_agent
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/transition
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/inifile
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/acpica_tools
ERROR -> Invalid credential type
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/apache
ERROR -> Invalid credential type
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/appfirst
ERROR -> Invalid credential type
INFO -> Deploying module
/etc/puppetlabs/code-staging/environments/dev/modules/aspell
ERROR -> Invalid credential type
One difference from the PE documentation (which I didn't think could
possibly be the problem, but fortunately tried anyway) was that our
Puppetfile git urls were of the form:
ssh://g...@stash.example.com/puppet/puppet-foo
instead of
g...@stash.example.com:puppet/puppet-foo
Once I changed Puppetfile to use the second form, I was again able to
use puppet-code to deploy changes. While I still need to find out the
"something" that happened to break things, I wanted to send a message to
the list while the details are still fresh in my mind in case this might
be useful to someone sometime down the road, especially as this behavior
(IMHO) violates the principle of least astonishment.
--jtc
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/87intpi3uh.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.
