** Changed in: juju-core (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
local provider is very slow to tranistion from
** Changed in: juju-core
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
local provider is very slow to tranistion from
** Changed in: juju-core
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
local provider is very slow to tranistion from
Thanks for the information, Robie. I am assigned to 1317680 as well, so
I'll keep your comments in mind.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
local
Oops, looks like I was mistaken. I'm not assigned. I see you cross-
linked your comment, so whomever gets assigned should have enough to go
on.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
The first half of this fix has been landed into trunk. When users
specify a stream in the image-stream config setting, Juju will use
this to determine which simple stream to sync. By specifying daily,
new machines will receive a more up-to-date image thus shortening the
time it takes to perform
Note that bug 1317680 may be a potential issue here. If you end up in
the situation that you've previously synced the same release from both a
daily and a released stream, then an attempt to create a container will
be unambiguous and thus fail. In that bug the issue was that the user
had manually
** Changed in: juju-core
Assignee: (unassigned) = Katherine Cox-Buday (cox-katherine-e)
** Changed in: juju-core
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
The ability to specify a different image stream to allow daily images to
be used query simpleastreams images was added in 1.17.2, but this was
for cloud nodes started by the provider directly in the cloud, not
images fetched by uvt-simplestreams-libvirt as is done when creating a
kvm container.
looks like part of the problem was that we were running with constraints
on cpu greater then the level1 KVM had allocated to it.
base KVM had 1 cpu, juju was asking for three:
juju add-machine --constraints mem=3G root-disk=20G cpu-cores=3
if we modify the base KVM to have 3 cpus the time drops
So it looks like this should be reclassified against juju again?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
local provider is very slow to tranistion from
using latest dailies images and/or hacking juju to not blindly issue
apt-get update/upgrade is something i often to do safe a minute per unit
(x100s). its also the only way to get kernel updates sans rebooting a
machine post deploy. a daily should get us to the same place as the last
release plus
Actually the first two suggestions in comment #23 seem perfectly valid
against juju - do not overprovision, at least, and perhaps,
conditionally, use cache=unsafe. I would assume that in a developer
situation, if power is lost during a juju deploy, all vms would get
wiped and the charms
Ok, then it sounds like the bug should be either invalid or wontfix - be
it against qemu or juju. Probably both, since it is the case for both.
As I've been repeatedly told, nested qemu (especially on intel) is a
convenience/developer feature, and all but unsupported upstream. So we
either need
cache=unsafe only helps a litte. we either need to support daily or more
frequent images by default, mainly to avoid the cost of kernel updates
or support a feature in juju to allow us to configure what images we
want to pull.
as a side note, I am happy to get ride of nested kvm if we can get all
Quoting Daniel Westervelt (daniel.westerv...@canonical.com):
cache=unsafe only helps a litte.
In comment #23 you said it brought the time from 4.5 to 3 minutes, a 33%
improvement.
we either need to support daily or more
frequent images by default, mainly to avoid the cost of kernel updates
** Package changed: qemu (Ubuntu) = juju-core (Ubuntu)
** Changed in: juju-core (Ubuntu)
Assignee: Canonical Server Team (canonical-server) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
** Also affects: juju-core
Importance: Undecided
Status: New
** Changed in: juju-core
Importance: Undecided = High
** Changed in: juju-core
Status: New = Triaged
** Changed in: juju-core
Milestone: None = next-stable
--
You received this bug notification because you
Reproducer steps:
Create a trusty virtual machine using the defaults provided with uvt tool.
ssh into that virtual machine and setup juju environments.yaml to be a local
provider with a container-type: kvm
juju bootstrap
juju add-machine
--
You received this bug notification because you are a
environments.yaml:
default: local
environments:
local:
type: local
container: kvm
lxc-use-clone: true
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1322302
Title:
It takes 164 seconds in cloud init to bring up the first machine.
What's the outer VM config (resources), likewise, what's the host
machine resource level?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
Summary
---
Add-machine: Wed May 28 14:31:56 UTC 2014 (0)
KVM Ssh'able:Wed May 28 14:33:15 UTC 2014 (+79)
Cloud-init done: Wed May 28 14:35:14 UTC 2014 (+119)
Juju status started: Wed May 28 14:35:38 UTC 2014 (+24)
Total time: 222 seconds: 3 min, 40 seconds.
One modification to the outer KVM that may help here:
adding --unsafe-cache to your first level KVM will use host ram to cache
guest writes to the qcow2 image -- this means what it means, if kill
your VMs or host machine has power failure, you'll lose data.With
that in place the same test
A note from the juju side of the fence - Juju currently just syncs the
latest released image when calling uvt-simplestreams-libvirt. It could
be configured to add a --source arg to get a daily image if required.
But configuration adds complexity so if the released kvm images were
updated more
I think investigation needs to start from a qemu performance
perspective. It may be that uvtool needs to tell libvirt to tell qemu to
do something differently, but in that case I need to know what.
** Project changed: uvtool = qemu
** Project changed: qemu = qemu (Ubuntu)
** Changed in: qemu
Can someone show the actual dpkg term log to show how much needed
upgrading?
Can you confirm that kvm is being run with acceleration?
Since you're using uvtool I assume you're also using a qcow2, which
further degrades performance...
--
You received this bug notification because you are a
26 matches
Mail list logo
