upgrade-charm fails because of git

[Kapil Thangavelu]

upgrade fails.. due to git config.. hoping we can exorcise git..

2014-03-26 00:37:52 DEBUG juju.worker.uniter modes.go:420 ModeHookError exiting
2014-03-26 00:37:52 INFO juju.worker.uniter modes.go:418 ModeUpgrading local:trusty/cf-nats-45 starting
2014-03-26 00:37:52 INFO juju.worker.uniter uniter.go:266 fetching charm "local:trusty/cf-nats-45"
2014-03-26 00:37:52 DEBUG juju.worker.uniter.filter filter.go:362 sent upgrade event
2014-03-26 00:37:52 ERROR juju git.go:216 worker/uniter/charm: git command failed: exit status 128
path: /var/lib/juju/agents/unit-nats-0/state/deployer/update-20140325-203752667704006
args: []string{"commit", "--allow-empty", "-m", "Imported charm \"local:trusty/cf-nats-45\" from \"/var/lib/juju/agents/unit-nats-0/state/bundles/local_3a_trusty_2f_cf-nats-45\"."}

*** Please tell me who you are.

Run

  git config --global user.email "<email address hidden>"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@foundry-m3.(none)')

2014-03-26 00:37:52 DEBUG juju.worker.uniter modes.go:420 ModeUpgrading local:trusty/cf-nats-45 exiting
2014-03-26 00:37:52 INFO juju.worker.uniter uniter.go:140 unit "nats/0" shutting down: ModeUpgrading local:trusty/cf-nats-45: git commit failed: exit status 128
2014-03-26 00:37:52 ERROR juju.worker.uniter.filter filter.go:116 tomb: dying
2014-03-26 00:37:52 DEBUG juju.worker.uniter runlistener.go:97 juju-run listener stopping
2014-03-26 00:37:52 DEBUG juju.worker.uniter runlistener.go:117 juju-run listener stopped
2014-03-26 00:37:52 ERROR juju runner.go:220 worker: exited "uniter": ModeUpgrading local:trusty/cf-nats-45: git commit failed: exit status 128
2014-03-26 00:37:52 INFO juju runner.go:254 worker: restarting "uniter" in 3s
2014-03-26 00:37:55 INFO juju runner.go:262 worker: start "uniter"
~

[William Reade (fwereade)]

This is resolved (as far as I plan to resolve it) by the fix for lp:1232304 -- new deployments will no longer use git. (Pre-existing git deployments will also be converted, but if they pre-exist they didn't suffer from this bug.)

[Ryan Finnie (fo0bar)]

I'm seeing this on juju-core 1.18.2 using a new deployed environment with trusty series, then doing upgrade-charm. The agents go into an infinite upgrade-charm loop.

I'm not sure what the problem actually is. Doing what it says and setting --global user.email and user.name for the root user doesn't work, so it can't be manually worked around. And yet, I cannot reproduce the behavior manually by:

git init
git config user.email "juju@localhost"
git config user.name "juju"
git commit --allow-empty -m "test"

This works manually on a new repo, so my theory that git on trusty doesn't like "juju@localhost" and proceeded to autodetect is apparently wrong.

[Ryan Finnie (fo0bar)]

Got it. git (at least in trusty) does not copy over the repo configs when doing a clone, so user.email and user.name do not get copied from the source repository. And since $HOME is not set, --global is not referenced. And in environments where the hosts domain name is not set e.g. trusty (cloud-init change between precise and trusty?), git tries and fails to set a default email address, and we go into this loop.

The referenced branch fixes this by setting user.name and user.email directly when cloning a git repo. Please consider applying this to the 1.18 line, as the problem severely breaks 1.18+trusty+(openstack, possibly others).

[Kapil Thangavelu (hazmat)]

also fixed in 1.19 by ditching git.

On Fri, May 9, 2014 at 3:43 PM, Ryan Finnie <email address hidden>wrote:

> Got it. git (at least in trusty) does not copy over the repo configs
> when doing a clone, so user.email and user.name do not get copied from
> the source repository. And since $HOME is not set, --global is not
> referenced. And in environments where the hosts domain name is not set
> e.g. trusty (cloud-init change between precise and trusty?), git tries
> and fails to set a default email address, and we go into this loop.
>
> The referenced branch fixes this by setting user.name and user.email
> directly when cloning a git repo. Please consider applying this to the
> 1.18 line, as the problem severely breaks 1.18+trusty+(openstack,
> possibly others).
>
> ** Branch linked: lp:~fo0bar/juju-core/1.18-lp1297559
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1297559
>
> Title:
> upgrade-charm fails because of git
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1297559/+subscriptions
>

[Martijn Evers (mevers)]

For those running into problems, with 1.18. This is a work-around:

On the machine producing the error, execute this (copy-paste safe):

sudo mv /usr/bin/git /usr/bin/git.unpatched
echo -e '#!/bin/bash\nGIT_BIN=/usr/bin/git.unpatched\nif [ "clone" == "$1" ]; then\n'\
'\t"$GIT_BIN" clone --config user.email=juju@localhost --config user.name=juju "${@:2}"\n'\
'else\n\t"$GIT_BIN" "$@"\nfi'\
| sudo tee /usr/bin/git > /dev/null
sudo chmod +x /usr/bin/git

[David Lawson (deej)]

What version has this fix applied? I've just encountered this error on a fresh unit running 1.18.4-precise-amd64.

[Paul Collins (pjdc)]

Similarly, I have also encountered this problem following upgrade-charm in a 1.18.4 environment.

$ juju status | grep agent-version | cut -f2 -d: | sort -u
 1.18.4.1
$ juju --version
1.18.4-precise-amd64

[Stuart Bishop (stub)]

Setting the 1.18 to high, to match the original bug report. 'juju upgrade-charm' is currently broken in the 1.18 series, at least on our production OpenStack environment.

[Anastasia (anastasia-macmood)]

targeted against old milestone