Juju corrupts jenv yaml on upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Triaged
|
Critical
|
Unassigned |
Bug Description
Upgrade tests for every substrate are failing because the jenv file's yaml is overwritten without first being truncated. Many times the upgrade works, but juju destroy-environment fails:
juju --show-log destroy-environment local-upgrade-
2014-07-24 23:13:21 INFO juju.cmd supercommand.go:37 running juju [1.20.1-
2014-07-24 23:13:21 ERROR juju.cmd supercommand.go:323 cannot read environment info for "local-
error unmarshalling "/var/lib/
YAML error: line 139: could not find expected
Here is an example of a corrupted jenv https:/
the last two lines are from the prevous content of the file, probably tools-url:
tools-
tools-url: http://
type: ec2
zonaws.
type: ec2
Once a corrupted jenv is left behind, the env cannot be bootstrapped again without the wit to purge the trash left by juju.
This issue is more likely to happen in local lxc tests, but has been seen in aws, hp, canonistack, and azure.
Changed in juju-core: | |
milestone: | none → 1.21-alpha1 |
Fixed in trunk [1] for https:/ /bugs.launchpad .net/juju- core/+bug/ 1348458
1. https:/ /github. com/juju/ juju/pull/ 402
On Sat, Jul 26, 2014 at 8:12 AM, Curtis Hovey <email address hidden> wrote: trusty- amd64 --force -y trusty- amd64 gc] upgrade- trusty- amd64": jenkins/ cloud-city/ environments/ local-upgrade- trusty- amd64.jenv" : /pastebin. canonical. com/114224/ juju-dist. s3.amazonaws. com/testing/ tools juju-dist. s3.amazonaws. com/testing/ tools com/testing/ tools /bugs.launchpad .net/bugs/ 1348827 trusty- amd64 --force -y trusty- amd64 gc] upgrade- trusty- amd64": jenkins/ cloud-city/ environments/ local-upgrade- trusty- amd64.jenv" : /pastebin. canonical. com/114224/ juju-dist. s3.amazonaws. com/testing/ tools juju-dist. s3.amazonaws. com/testing/ tools com/testing/ tools
> Public bug reported:
>
> Upgrade tests for every substrate are failing because the jenv file's yaml is overwritten without first being truncated. Many times the upgrade works, but juju destroy-environment fails:
> juju --show-log destroy-environment local-upgrade-
> 2014-07-24 23:13:21 INFO juju.cmd supercommand.go:37 running juju [1.20.1-
> 2014-07-24 23:13:21 ERROR juju.cmd supercommand.go:323 cannot read environment info for "local-
> error unmarshalling "/var/lib/
> YAML error: line 139: could not find expected
>
> Here is an example of a corrupted jenv https:/
> the last two lines are from the prevous content of the file, probably tools-url:
> tools-metadata-url: http://
> tools-url: http://
> type: ec2
> zonaws.
> type: ec2
>
> Once a corrupted jenv is left behind, the env cannot be bootstrapped
> again without the wit to purge the trash left by juju.
>
> This issue is more likely to happen in local lxc tests, but has been
> seen in aws, hp, canonistack, and azure.
>
> ** Affects: juju-core
> Importance: Critical
> Status: Triaged
>
>
> ** Tags: ci config regression
>
> ** Changed in: juju-core
> Milestone: None => 1.21-alpha1
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: MOAR JUJU SPAM!
> https:/
>
> Title:
> Juju corrupts jenv yaml on upgrade
>
> Status in juju-core:
> Triaged
>
> Bug description:
> Upgrade tests for every substrate are failing because the jenv file's yaml is overwritten without first being truncated. Many times the upgrade works, but juju destroy-environment fails:
> juju --show-log destroy-environment local-upgrade-
> 2014-07-24 23:13:21 INFO juju.cmd supercommand.go:37 running juju [1.20.1-
> 2014-07-24 23:13:21 ERROR juju.cmd supercommand.go:323 cannot read environment info for "local-
> error unmarshalling "/var/lib/
> YAML error: line 139: could not find expected
>
> Here is an example of a corrupted jenv https:/
> the last two lines are from the prevous content of the file, probably tools-url:
> tools-metadata-url: http://
> tools-url: http://
> type: ec2
> zonaws.
> type: ec2
>
> Once a corrupted jenv is left behind, the env cannot be bootstrapped
> again without the wit to purge the trash left by juju.
>
> This issue is more likely to happen in local lxc tests, but has been
> seen in aws, hp, cano...