*** This bug is a duplicate of bug 1309593 ***
https://bugs.launchpad.net/bugs/1309593
** This bug is no longer a duplicate of bug 1311151
MAAS imports Trusty's 'rc' images by default.
** This bug has been marked a duplicate of bug 1309593
No way to specify which image should be used
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = Fix Committed
--
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/1311151
All this fix in the merge proposal will do is delay the problem until there
are 2 images named 'release' with different version
numbers on them.
The idea is to buy time to SRU a fix to let a user select which image to
use when there is a choice.
--
You received this bug notification
*** This bug is a duplicate of bug 1309593 ***
https://bugs.launchpad.net/bugs/1309593
** This bug is no longer a duplicate of bug 1311151
MAAS imports Trusty's 'rc' images by default.
** This bug has been marked a duplicate of bug 1309593
No way to specify which image should be used
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1311151
Title:
MAAS
** Changed in: maas
Status: New = Triaged
** Changed in: maas
Importance: Undecided = Critical
--
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/1310076
Title:
lost
** Changed in: maas
Status: New = Triaged
** Changed in: maas
Importance: Undecided = Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1310076
Title:
lost connectivity to a node
** Changed in: maas
Status: In Progress = Fix Committed
** Changed in: maas/1.4
Status: In Progress = Fix Committed
** Changed in: maas/1.5
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Changed in: maas
Status: In Progress = Fix Committed
** Changed in: maas/1.4
Status: In Progress = Fix Committed
** Changed in: maas/1.5
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Changed in: maas/1.5
Milestone: 14.04 = None
--
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/1301809
Title:
Report boot images no directory traceback
To manage notifications
** Changed in: maas/1.5
Milestone: None = 14.04
--
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/1301809
Title:
Report boot images no directory traceback
To manage notifications
** Changed in: maas/1.5
Milestone: 14.04 = None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1301809
Title:
Report boot images no directory traceback
To manage notifications about this bug go
** Changed in: maas/1.5
Milestone: None = 14.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1301809
Title:
Report boot images no directory traceback
To manage notifications about this bug go
Well, it's the reporting task that broke because of the absence of
'/var/lib/maas/boot-resources/current/'. The easiest way to fix this is
to change the reporting task so that it copes with that.
** Changed in: maas
Importance: Undecided = Critical
** Changed in: maas
Status: New =
** Branch linked: lp:~rvb/maas/reporting-bug-1301809
** Changed in: maas
Milestone: None = 14.10
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = In Progress
** Also affects: maas/1.5
Importance: Undecided
Status
** Changed in: maas
Assignee: (unassigned) = Andres Rodriguez (andreserl)
--
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/1240215
Title:
changing the default arches in
** Branch linked: lp:~rvb/maas/reporting-bug-1301809-1.5
** Changed in: maas/1.5
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: In Progress = Fix Committed
** Changed in: maas/1.5
Importance: Undecided = Critical
--
You received this bug notification
** Changed in: maas/1.5
Status: New = Fix Committed
--
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/1301809
Title:
Report boot images no directory traceback
To manage
Well, it's the reporting task that broke because of the absence of
'/var/lib/maas/boot-resources/current/'. The easiest way to fix this is
to change the reporting task so that it copes with that.
** Changed in: maas
Importance: Undecided = Critical
** Changed in: maas
Status: New =
** Branch linked: lp:~rvb/maas/reporting-bug-1301809
** Changed in: maas
Milestone: None = 14.10
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = In Progress
** Also affects: maas/1.5
Importance: Undecided
Status
** Branch linked: lp:~rvb/maas/reporting-bug-1301809-1.5
** Changed in: maas/1.5
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: In Progress = Fix Committed
** Changed in: maas/1.5
Importance: Undecided = Critical
--
You received this bug notification
** Changed in: maas
Assignee: (unassigned) = Andres Rodriguez (andreserl)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1240215
Title:
changing the default arches in import_pxe_files prevents
** Changed in: maas/1.5
Status: New = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1301809
Title:
Report boot images no directory traceback
To manage notifications about this
@Paul: the problem you're having is that your nodes can't access the
outside world. They are thus unable to fetch the packages needed for
commissioning (see http://paste.ubuntu.com/7195406/).
Unless you changed the http_proxy config option (on the settings page —
or you can configure it using
@Paul: the problem you're having is that your nodes can't access the
outside world. They are thus unable to fetch the packages needed for
commissioning (see http://paste.ubuntu.com/7195406/).
Unless you changed the http_proxy config option (on the settings page —
or you can configure it using
Did you, by any chance, acquire the two nodes using different API keys
(both belonging to the user 'smoser')?
--
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/1287373
Title:
cli 'nodes
Did you, by any chance, acquire the two nodes using different API keys
(both belonging to the user 'smoser')?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1287373
Title:
cli 'nodes list-allocated'
Maybe RabbitMQ or Celery have a mechanism for ignoring old jobs. If not, we
can add a timestamp check to the job
implementations themselves.
That's a good point, there is support in Celery for this:
http://celery.github.io/celery/userguide/executing.html#expiration
--
You received this bug
Maybe RabbitMQ or Celery have a mechanism for ignoring old jobs. If not, we
can add a timestamp check to the job
implementations themselves.
That's a good point, there is support in Celery for this:
http://celery.github.io/celery/userguide/executing.html#expiration
--
You received this bug
Public bug reported:
Upgrade to Trusty (from Saucy) failed with Could not calculate the
upgrade.
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: ubuntu-release-upgrader-core 1:0.205.4
ProcVersionSignature: Ubuntu 3.11.0-17.31-generic 3.11.10.3
Uname: Linux 3.11.0-17-generic x86_64
Btw, I just found (and fixed) bug 1278895. It means that the list of
the failed scripts in the failed [3/5] … message is actually wrong:
it's the list of the scripts that didn't fail (!).
Here is the list of all the scripts that maas has:
00-maas-01-lshw
00-maas-02-virtuality
Another note: to debug commissioning problems, the quickest way is to
have a look at the output of the scripts that failed. You can't do that
with the UI right now but it's all available if you use the API/CLI:
The following CLI command :
$ maas-cli maas commissioning-results list
will spit out
Another note: to debug commissioning problems, the quickest way is to
have a look at the output of the scripts that failed. You can't do that
with the UI right now but it's all available if you use the API/CLI:
The following CLI command :
$ maas-cli maas commissioning-results list
will spit out
Btw, I just found (and fixed) bug 1278895. It means that the list of
the failed scripts in the failed [3/5] … message is actually wrong:
it's the list of the scripts that didn't fail (!).
Here is the list of all the scripts that maas has:
00-maas-01-lshw
00-maas-02-virtuality
The bug is really in the simplestreams library, it does all the
downloading.
Well, simplestreams does only *part* of the downloading: it downloads
all the ephemerals all right but the installer files are still
downloaded by MAAS' script (./scripts/maas-import-pxe-files).
--
You received this
The bug is really in the simplestreams library, it does all the
downloading.
Well, simplestreams does only *part* of the downloading: it downloads
all the ephemerals all right but the installer files are still
downloaded by MAAS' script (./scripts/maas-import-pxe-files).
--
You received this
If you're using a earlier version of MAAS that doesn't contain the fix yet,
it's easy to reproduce the fix:
Save the script from http://paste.ubuntu.com/6762313/ into nonces_cleanup.py
and then run it using cron, every 5 minutes:
cat nonces_cleanup.py | sudo maas shell
Note that the cleanup
If you're using a earlier version of MAAS that doesn't contain the fix yet,
it's easy to reproduce the fix:
Save the script from http://paste.ubuntu.com/6762313/ into nonces_cleanup.py
and then run it using cron, every 5 minutes:
cat nonces_cleanup.py | sudo maas shell
Note that the cleanup
Public bug reported:
See details on the upstream issue: https://bitbucket.org/jespern/django-
piston/issue/235/attributeerror-wsgirequest-object-has-no
** Affects: python-django-piston (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you
Public bug reported:
See details on the upstream issue: https://bitbucket.org/jespern/django-
piston/issue/235/attributeerror-wsgirequest-object-has-no
** Affects: python-django-piston (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you
** Changed in: maas
Assignee: (unassigned) = Tycho Andersen (tycho-s)
--
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/1181334
Title:
i386 required to install amd64
To manage
We need to investigate the possibility of having a list of parameters
for the ipmi_si kernel module and try doing the IPMI detection for all
these parameters in sequence.
** Also affects: maas-enlist (Ubuntu)
Importance: Undecided
Status: New
** Changed in: maas
Milestone: None =
** Changed in: maas
Assignee: (unassigned) = Tycho Andersen (tycho-s)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1181334
Title:
i386 required to install amd64
To manage notifications about
We need to investigate the possibility of having a list of parameters
for the ipmi_si kernel module and try doing the IPMI detection for all
these parameters in sequence.
** Also affects: maas-enlist (Ubuntu)
Importance: Undecided
Status: New
** Changed in: maas
Milestone: None =
*** This bug is a duplicate of bug 1221059 ***
https://bugs.launchpad.net/bugs/1221059
** This bug has been marked a duplicate of bug 1221059
MAAS wsgi processes are stuck waiting for a lock which is never released
--
You received this bug notification because you are a member of Ubuntu
@tribaal: I think what you're seeing here is bug 1181334 (note the fact
that the error you see mentions i386).
Can you try changing /etc/maas/import_pxe_files to set ARCHES to
i386/generic amd64/generic, re-run the import script and try again?
--
You received this bug notification because you
@tribaal: I think what you're seeing here is bug 1181334 (note the fact
that the error you see mentions i386).
Can you try changing /etc/maas/import_pxe_files to set ARCHES to
i386/generic amd64/generic, re-run the import script and try again?
--
You received this bug notification because you
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1240652
Title:
maas-import-ephemerals crashes with unexpected checksum 'sha256'
I've tested this on canonistack and the fix worked:
http://paste.ubuntu.com/6278444/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1240652
Title:
maas-import-ephemerals crashes with unexpected
I think we should raise the priority on this bug and possibly fix it for
14.04. I expect a lot of users will want to use amd64 over i386. Being
able to not download all the i386 images cuts a third of what maas-
import-pxe-files downloads. This mean a significant gain in terms of
space and
@smoser, I just tested your most recent fix to simplestreams (revision
319) and it seems to fix the problem. I had a successful run in our
lab.
Until a package with the fix is published, this can be fixed manually:
$ sudo su
$ cd /usr/share/pyshared wget
I think we should raise the priority on this bug and possibly fix it for
14.04. I expect a lot of users will want to use amd64 over i386. Being
able to not download all the i386 images cuts a third of what maas-
import-pxe-files downloads. This mean a significant gain in terms of
space and
** Changed in: maas
Assignee: Raphaël Badin (rvb) = Gavin Panella (allenap)
--
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/1228085
Title:
The commissioning script 00-maas-03
** Changed in: maas
Assignee: Raphaël Badin (rvb) = Gavin Panella (allenap)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1228085
Title:
The commissioning script 00-maas-03-install-lldpd
** Changed in: maas
Status: In Progress = Fix Committed
--
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/1237364
Title:
Commissioning with a Saucy image sets node status to
** Changed in: maas
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1237364
Title:
Commissioning with a Saucy image sets node status to Failed tests
To
One solution to fix this problem would be this:
- when the env is bootstrapped: create a tag named after the environment UUID
- each time juju takes control of a node: associate that tag with the node
- when juju fetches the list of instances it controls, only return the nodes
associated with
** Also affects: juju
Importance: Undecided
Status: New
--
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/1229275
Title:
juju destroy-environment also destroys nodes that are
One solution to fix this problem would be this:
- when the env is bootstrapped: create a tag named after the environment UUID
- each time juju takes control of a node: associate that tag with the node
- when juju fetches the list of instances it controls, only return the nodes
associated with
** Also affects: juju
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229275
Title:
juju destroy-environment also destroys nodes that are not controlled
This might be a bug in the maas provider of juju-core… it definitely
needs investigation…
--
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/1229275
Title:
juju destroy-environment also
This might be a bug in the maas provider of juju-core… it definitely
needs investigation…
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229275
Title:
juju destroy-environment also destroys nodes
I experienced the same thing. killall unity-panel-service fixed the
problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1228360
Title:
No clock in menu bar and can't edit Clock settings
To
** Also affects: maas/1.2
Importance: Undecided
Status: New
** Also affects: maas/1.3
Importance: Undecided
Status: New
** Also affects: maas/trunk
Importance: Critical
Assignee: Raphaël Badin (rvb)
Status: In Progress
--
You received this bug notification
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10-1.3
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10-1.2
** Changed in: maas/1.3
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas/1.2
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed
** Changed in: maas/1.2
Status: In Progress = Fix Committed
** Changed in: maas/1.3
Status: In Progress = Fix Committed
** Changed in: maas/trunk
Status: In Progress = Fix Committed
** Changed in: maas/1.3
Importance: Undecided = Critical
** Changed in: maas/1.2
** Also affects: maas/1.2
Importance: Undecided
Status: New
** Also affects: maas/1.3
Importance: Undecided
Status: New
** Also affects: maas/trunk
Importance: Critical
Assignee: Raphaël Badin (rvb)
Status: In Progress
--
You received this bug notification
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10-1.3
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10-1.2
** Changed in: maas/1.3
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas/1.2
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed
** Changed in: maas/1.2
Status: In Progress = Fix Committed
** Changed in: maas/1.3
Status: In Progress = Fix Committed
** Changed in: maas/trunk
Status: In Progress = Fix Committed
** Changed in: maas/1.3
Importance: Undecided = Critical
** Changed in: maas/1.2
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10
--
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/1208497
Title:
netboot flag defaults to 'true' on upgrade, even for
** Branch linked: lp:~rvb/maas/netboot-allocated-fix-mig-10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1208497
Title:
netboot flag defaults to 'true' on upgrade, even for allocated nodes
To
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = In Progress
--
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/1208497
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1208497
Title:
netboot
** Branch linked: lp:~rvb/maas/netboot-allocated
--
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/1208497
Title:
netboot flag defaults to 'true' on upgrade, even for allocated nodes
To
** Branch linked: lp:~rvb/maas/netboot-allocated
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1208497
Title:
netboot flag defaults to 'true' on upgrade, even for allocated nodes
To manage
'createsuperuser' is a Django command ([0]) used to create an admin
user. 'createadmin' is a MAAS command, very similar to
'createsuperuser', but which lets you provide the password on the
command line (with --password). That's inherently insecure and that's
why the Django command doesn't let you
** Summary changed:
- [13.04] sudo maas createsuperuser not a valid command
+ createsuperuser fails if Python can't detect default locale
** Also affects: django via
http://code.djangoproject.com/ticket/16017
Importance: Unknown
Status: Unknown
** Changed in: maas
Status:
'createsuperuser' is a Django command ([0]) used to create an admin
user. 'createadmin' is a MAAS command, very similar to
'createsuperuser', but which lets you provide the password on the
command line (with --password). That's inherently insecure and that's
why the Django command doesn't let you
** Summary changed:
- [13.04] sudo maas createsuperuser not a valid command
+ createsuperuser fails if Python can't detect default locale
** Also affects: django via
http://code.djangoproject.com/ticket/16017
Importance: Unknown
Status: Unknown
** Changed in: maas
Status:
I did some testing and it turns out the hostname size seems to be the
problem! I started a bunch of machines with a hostname of 64 characters
and a bunch of machines with a hostname of 25 characters (with the
script I linked above): all the machines with a hostname of 25 ended up
in the state
s/Commissioning/Provisioning/ sorry about that.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to walinuxagent in Ubuntu.
https://bugs.launchpad.net/bugs/1195524
Title:
race condition / transient failure to provision
To manage
I did some testing and it turns out the hostname size seems to be the
problem! I started a bunch of machines with a hostname of 64 characters
and a bunch of machines with a hostname of 25 characters (with the
script I linked above): all the machines with a hostname of 25 ended up
in the state
s/Commissioning/Provisioning/ sorry about that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1195524
Title:
race condition / transient failure to provision
To manage notifications about this bug
2013/06/28 15:08:12 EnvMonitor: Detected host name change: ubuntu -
gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw
2013/06/28 15:08:12 Setting host name:
gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw
Is it expected?
Yes, this machine was created using
The doc (http://msdn.microsoft.com/en-
us/library/windowsazure/jj157194.aspx) explicitly says the hostname can
get 64 characters long: HostName: Required. Specifies the host name for
the VM. Host names are ASCII character strings 1 to 64 characters in
length. Used with the
2013/06/28 15:08:12 EnvMonitor: Detected host name change: ubuntu -
gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw
2013/06/28 15:08:12 Setting host name:
gwaclhostblkhljy4re3yp9swkdwp63kswkss9bqhn0zm3f3gunipzu5vwdr8qzw
Is it expected?
Yes, this machine was created using
The doc (http://msdn.microsoft.com/en-
us/library/windowsazure/jj157194.aspx) explicitly says the hostname can
get 64 characters long: HostName: Required. Specifies the host name for
the VM. Host names are ASCII character strings 1 to 64 characters in
length. Used with the
** Changed in: maas
Status: In Progress = Fix Released
--
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/1172336
Title:
MAAS server reference to AvahiBoot wiki page that does not
** Changed in: maas
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1172336
Title:
MAAS server reference to AvahiBoot wiki page that does not exist
To
Hi Chris Halse Rogers, I've just tested the package (1.3+bzr1461+dfsg-
0ubuntu2.1) in our QA lab and it fixes the bug.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Hi Chris Halse Rogers, I've just tested the package (1.3+bzr1461+dfsg-
0ubuntu2.1) in our QA lab and it fixes the bug.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
jhujhiti told me that the celery worker is eating up all the cpu and
most of the memory.
In celery.log, I see: [2013-05-29 10:41:28,386: INFO/MainProcess] Task
provisioningserver.tasks.upload_dhcp_leases[11a33416-5a33-4530-8fdf-
e0825b62d616] succeeded in *451.886018991s*: None
I thought that it
jhujhiti told me that the celery worker is eating up all the cpu and
most of the memory.
In celery.log, I see: [2013-05-29 10:41:28,386: INFO/MainProcess] Task
provisioningserver.tasks.upload_dhcp_leases[11a33416-5a33-4530-8fdf-
e0825b62d616] succeeded in *451.886018991s*: None
I thought that it
Public bug reported:
Django 1.5 (the Django version in saucy) uses python's json package instead of
simplejson. Here is the pull request on piston's upstream code to cope with
that:
https://bitbucket.org/jespern/django-piston/pull-request/25/compatibility-fix-for-json-emitter-with/diff
We
*** This bug is a duplicate of bug 1184219 ***
https://bugs.launchpad.net/bugs/1184219
** This bug has been marked a duplicate of bug 1184219
Piston Django 1.5 incompatibility with simplejson 2.2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Project changed: maas = maas (Ubuntu)
--
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/1184523
Title:
/var/log/maas/{celery-region,celery}.log are not rotated
To manage
** Project changed: maas = maas (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1184523
Title:
/var/log/maas/{celery-region,celery}.log are not rotated
To manage notifications about this
If someone can recreate this problem, it would be good to see in the
celery logs (/var/log/maas/*celery*.log) if there isn't an indication of
what's wrong with the workers.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in
Adding a TTL to the celery queues will avoid the out of memory error.
But if we want to fix the core problem we need to understand why the
tasks are pilling up without being processed by the workers.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
I suspect this is caused by task messages getting generated before a
celeryd listener is connected/registered. I saw it once myself (but only
once).
Did the tasks start piling up right from the start or did the system
work for a while, then stopped working with the tasks piling up?
--
You
101 - 200 of 469 matches
Mail list logo
