I think this deserves some priority, as it seems this completely breaks
cloud-utils/juju on utopic. The autopkgtest doesn't spot this because it
just does "bootstrap", but for juju-local bootstrapping doesn't really
do much. The autopkgtest should also actually deploy something, to cover
building the template and the service container.
Tentatively assigning to Scott, can you please assign this to someone
appropriate?
** Also affects: cloud-utils (Ubuntu Utopic)
Importance: Undecided
Status: New
** Also affects: juju-core (Ubuntu Utopic)
Importance: Undecided
Status: Invalid
** Changed in: cloud-utils (Ubuntu Utopic)
Importance: Undecided => High
** Changed in: cloud-utils (Ubuntu Utopic)
Assignee: (unassigned) => Scott Moser (smoser)
** Description changed:
+ TL;DR: Utopic's ca-certificates don't cover the cert we are using to
+ sign our cloud images and their catalogs, and utopic's wget now fails on
+ a cert which can't be validated. This completely breaks ubuntu-cloudimg-
+ query and lxc-ubuntu-cloud.
+
+ Original report below:
+ ---
+
I tried the "local" provider again on current utopic, and today it fails
on creating containers:
- Start from a clean slate: no *juju* containers (I do have some
containers for other work, though), no ~/.juju, etc. I follow
https://juju.ubuntu.com/docs/getting-started.html and
https://juju.ubuntu.com/docs/config-local.html
- sudo apt install juju-core juju-local
juju generate-config
juju switch local
- As I have $HOME on ecryptfs, I follow the documentation and use a
separate juju root:
sudo mkdir /scratch/juju
sudo chown martin:martin /scratch/juju/
Now I edit ~/.juju/environments.yaml in the local section to have
"root-dir: /scratch/juju" and "default-series: trusty".
I also apply a workaround for bug 1290920:
lrwxrwxrwx 1 root root 12 Jun 11 21:55 /var/lib/lxc -> /scratch/lxc
- Now bootstrap, this apparently works well:
$ juju bootstrap
uploading tools for series [precise trusty utopic]
[sudo] password for martin:
Logging to /scratch/juju/cloud-init-output.log on remote host
Bootstrapping Juju machine agent
Starting Juju machine agent (juju-agent-martin-local)
This took maybe 10 seconds. /scratch/juju/cloud-init-output.log contains
no "ERROR", and ends with "juju-agent-martin-local start/running,
process 3997", so this seems fine. But I'll attach the log anyway. Note
that this did *not* create any extra container; "sudo lxc-ls --fancy"
does not show me anything new.
$ juju status
environment: local
machines:
"0":
agent-state: started
agent-version: 1.20.5.1
dns-name: localhost
instance-id: localhost
series: utopic
state-server-member-status: has-vote
services: {}
- Now I try to deploy the GUI:
$ juju deploy juju-gui
Added charm "cs:trusty/juju-gui-5" to the environment.
(Returned after ~ 5 s)
$ juju status
environment: local
machines:
"0":
agent-state: started
agent-version: 1.20.5.1
dns-name: localhost
instance-id: localhost
series: utopic
state-server-member-status: has-vote
"1":
agent-state-info: container failed to start
instance-id: pending
series: trusty
services:
juju-gui:
charm: cs:trusty/juju-gui-5
exposed: false
units:
juju-gui/0:
agent-state: pending
machine: "1"
This created a new container:
juju-trusty-lxc-template STOPPED - - - NO
But it is basically empty, except for a new log dir:
$ find /scratch/lxc/juju-trusty-lxc-template/
/scratch/lxc/juju-trusty-lxc-template/
/scratch/lxc/juju-trusty-lxc-template/config
/scratch/lxc/juju-trusty-lxc-template/rootfs
/scratch/lxc/juju-trusty-lxc-template/rootfs/var
/scratch/lxc/juju-trusty-lxc-template/rootfs/var/log
/scratch/lxc/juju-trusty-lxc-template/rootfs/var/log/juju
The first error in /scratch/juju/log/machine-0.log is
2014-09-01 06:36:47 ERROR juju.worker runner.go:218 exited "api": unable
to connect to "wss://localhost:17070/"
but it seems to retry and succeed a bit later:
2014-09-01 06:36:50 INFO juju.state.api apiclient.go:176 connection
established to "wss://localhost:17070/"
then it just ends with
2014-09-01 06:39:19 ERROR juju.container.lxc clonetemplate.go:167 container
failed to start: container failed to start
2014-09-01 06:39:19 ERROR juju.provisioner provisioner_task.go:418 cannot
start instance for machine "1": container failed to start
I'll also attach the full file. So it seems it fails very early on to
create containers, this doesn't seem very charm specific. But just to
make sure, I destroyed the juju service and machine (which didn't
destroy the container, I did that manually) and service, and tried to
"juju deploy mysql", but with the exact same result.
ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: juju-local 1.20.5-0ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-11.16-generic 3.16.1
Uname: Linux 3.16.0-11-generic x86_64
ApportVersion: 2.14.7-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Sep 1 08:23:10 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-02-27 (185 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140224)
PackageArchitecture: all
SourcePackage: juju-core
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1363832
Title:
[utopic] fails to build template container -- ubuntu-cloudimg-query
fails
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1363832/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
