Note that in a customer site with HA=3 and ~100 machines we are seeing syslog
grow to around 3.6GB before it gets rotated (presumably daily?). Which means
that we end up consuming 7.2GB just before the second rotation, and most of it
is going to be these fairly useless logging output.
I believe
I wonder if this is just saturating the transaction log. The txn log is
a capped collection, so it only allows N entries before it starts
overwriting earlier ones. I can imagine there are other issues going on,
but we might want a knob that lets you say I'm going to be running
1000s things, make
I actually don't think using mongo is the correct fix here. We already
have all the code we need inside of juju-core, we shouldn't depend on a
separate client library in order to write stuff to the database.
We *definitely* don't want mongodb-clients as a dependency for juju-core
(juju-core is
** Changed in: juju-core/1.18
Assignee: John A Meinel (jameinel) = Ian Booth (wallyworld)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-quickstart in Ubuntu.
https://bugs.launchpad.net/bugs/1306537
Title:
LXC local
That sounds like a regression, we certainly need to be able to fall back to
the old method of connecting if the server doesn't support proxying the
request.
John
=:-
On Tue, May 6, 2014 at 5:12 PM, Curtis Hovey cur...@canonical.com
wrote:
This issue might be that the 1.19.1 client cannot ssh
I believe this is more about the local provider, which doesn't actually
look for tools on streams.canonical.com
I don't quite understand why we don't recognize 'utopic', though, as we
*should* be reading /usr/share/distro-info/ubuntu.csv to find what series
are available.
Certainly you can see
James, this may be a special case for juju-mongodb, but if you uninstall a
package, doesn't it usually stop the service that was running?
(uninstalling postgres should stop the postgres process, right?)
I guess in the case of juju-mongodb we have the problem that the packaging
itself isn't
So this sounds like we are putting all the machine IDs into a single URL
and we end up running out of URL space (quick google says that the default
max length is 2000 characters).
It sounds like we either need to send the request in batches, or POST the
IDs rather than put them in the URL itself.
** Changed in: juju-core
Status: New = Triaged
** Changed in: juju-core
Importance: Undecided = High
** Changed in: juju-core
Milestone: None = 1.19.2
** Changed in: juju-core
Importance: High = Critical
--
You received this bug notification because you are a member of Ubuntu
** Changed in: juju-core/1.18
Status: Triaged = In Progress
** Changed in: juju-core/1.18
Assignee: (unassigned) = Nate Finch (natefinch)
** Changed in: juju-core
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server
** Also affects: juju-mongodb (Ubuntu)
Importance: Undecided
Status: New
** Changed in: juju-core
Status: Triaged = Invalid
** Changed in: juju-core
Milestone: 1.19.1 = None
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Summary changed:
- juju scp no longer allows multiple extra arguments to pass throug
+ juju scp no longer allows multiple extra arguments to pass through
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
** Changed in: juju-core/1.18
Importance: High = Critical
** Changed in: juju-core
Importance: High = Critical
--
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/1304407
Title:
I would target this to a 1.18.2 if it existed.
This is a change in behavior from 1.16 to 1.18. If you just do:
juju-1.18 bootstrap -e amazon
I end up getting a i386 target. I have to do:
juju-1.18 bootstrap -e amazon --constraints=arch=amd64
for it to pick a amd64 (which was always the default
** Changed in: juju-core
Milestone: 1.19.0 = None
** Changed in: juju-core
Assignee: Nate Finch (natefinch) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
...
On Mon, Mar 31, 2014 at 01:30:45PM -, Mark Ramm wrote:
I think a key point here is that the juju package does not generally
install or pull down binaries from anywhere to your machine. It does
instruct the cloud installation of a server to use a specific ubuntu
image from
Actually, because juju-local only supports one architecture (your local
machine), it does *not* download the jujud tools from a remote site, but
uses the one on your local machine. (It should be put into the juju-
local package, rather than being in the 'juju-core' package, but that is
just
Public bug reported:
When installing the juju-local package you should also get the cpu-checker
package so that we can probe for KVM support.
We could make it a Recommends instead of a Depends (because if it isn't there,
we just assume no KVM support), but it seems useful to have around.
This
** Changed in: juju-core
Milestone: 1.18.0 = 1.17.6
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1273769
Title:
ppc64el enablement for juju/lxc
To manage notifications about
** Summary changed:
- juju deploy fails against juju-core 1.17.3 environment with 1.17.2 client
+ juju 1.17.2 client doesn't like juju 1.17.3 .jenv files
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
The specific bug doesn't have to do with streams or any such thing. As
Andrew mentioned, it is just that we changed the default values for an
item in the environment configuration, and 1.17.2 didn't like the
content being the empty string.
The way to fix that is to not use 1.17.2. So I think
Marked Won't Fix because it is technically a bug in 1.17.2's
interpretation of a newer config, 1.16 didn't have that field so it
isn't a stable release compatibility problem.
** Changed in: juju-core
Status: Triaged = Won't Fix
--
You received this bug notification because you are a
I'm pretty sure the arch changes haven't landed yet, right? (mapping the
values of uname -m to the names we'll be using for the juju
packages/tarballs)
On Mon, Feb 17, 2014 at 10:02 PM, James Page james.p...@ubuntu.com
wrote:
** Changed in: juju-core (Ubuntu)
Status: Confirmed =
1.16 needs to be merged into trunk, which Martin P is working on today
John
=:-
On Feb 19, 2014 6:41 PM, Curtis Hovey cur...@canonical.com wrote:
Hi John. Is the status of this bug fix committed in trunk? Does the
branch need to merge into trunk?
--
You received this bug notification
offhand, I would think we'd want to use the term arm64 for this (to
match arm), but I don't have a strong stake in what we call it.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
I don't have direct ways to test the patch, but it seems sane to me. Is
there something we can get into some form of testing to make sure that
we don't break this in the future? (CI testing for aarch64?)
** Changed in: juju-core
Importance: Undecided = High
** Changed in: juju-core
Given the statements in bug #1276909 this seems to be a small patch so
that we have a regex to recognize the architecture.
It seems the new patch would be something like:
--- juju-core-1.17.2.orig/src/launchpad.net/juju-core/environs/manual/init.go
+++
So I tried this patch:
=== modified file 'testing/mgo.go'
--- testing/mgo.go 2013-11-06 13:38:01 +
+++ testing/mgo.go 2013-12-18 06:23:25 +
@@ -99,6 +99,7 @@
--noprealloc,
--smallfiles,
--nojournal,
+ --noscripting,
We only have builds of juju-core on Arm for Saucy (1.14.0 and 1.14.1
both have official juju tools builds for saucy-1.14.1-armhf.tgz)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
I don't think this is strictly a bug in 'juju-core', more of a bug in
the packaging. (Namely saucy has a package named juju which is a meta
package that installs juju-core, while IIRC python-juju is no longer
available on Saucy.)
If this was just 'apt-get upgrade' I would probably agree it
juju-core the package is the client tools (juju), so it should *not*
depend on having mongodb locally installed.
To use the local provider, you can install juju-local on saucy (and from
ppa:juju/stable).
That will bring in both lxc and mongodb.
** Changed in: juju-core (Ubuntu)
Status:
Note that once we avoid direct access to the state db from agents and
clients, we will have the mongo port blocked off by the cloud firewall.
Which does limit the effectiveness of this.
We also run jujud itself as root, but generally we have to because we do
things like creating LXC containers
have a great fix, so I'm rolling back my
change (otherwise upgrade-juju is broken) and re-opening this bug.
** Changed in: juju-core
Status: Fix Committed = Triaged
** Changed in: juju-core
Assignee: John A Meinel (jameinel) = (unassigned)
** Changed in: juju-core
Milestone: 1.11.2
** Branch linked: lp:~jameinel/maas/1.2-kernel-option-tags
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1044503
Title:
kernel command line is not easily customizable
To manage
Public bug reported:
We have an atomically created lockfile (create a temp file, 'ln tempfile
maas.startup.lock'. However, if something happens during startup, the
lock file can be left held, blocking other processes from accessing it.
The workaround is to manually delete the file, and then
Public bug reported:
If something happens and you delete the rabbitmq user 'maas_workers' or
the vhost '/mass_workers' and then run 'dpkg-reconfigure' to fix things.
However, the test in postinst is 'if user exists: change_user_password()
else: create user, create vhost, set permissions on
** Changed in: maas (Ubuntu)
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1067333
Title:
If maas-region-controller dies during startup, it leaves
37 matches
Mail list logo
