** Branch linked: lp:~rvb/maas/lp-1313550
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1313550
Title:
ping does not work as a normal user on trusty tarball cloud images.
To manage
** Changed in: maas/1.8
Milestone: None = 1.8.1
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-tx-tftp in Ubuntu.
https://bugs.launchpad.net/bugs/1317705
Title:
Commissioning x86_64 node never completes, sitting at grub
** Branch linked: lp:~rvb/maas/tftp-bug-1317705
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-tx-tftp in Ubuntu.
https://bugs.launchpad.net/bugs/1317705
Title:
Commissioning x86_64 node never completes, sitting at grub
= next
** Changed in: maas/trunk
Status: In Progress = Fix Committed
** Changed in: maas/trunk
Assignee: Andres Rodriguez (andreserl) = (unassigned)
** Changed in: maas/trunk
Assignee: (unassigned) = Raphaël Badin (rvb)
--
You received this bug notification because you
** Changed in: maas/1.8
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas/1.8
Importance: Undecided = Critical
** Changed in: maas/1.8
Status: New = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
** Tags added: juju-net
--
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/1430025
Title:
maas uninstallable on vivid
To manage notifications about this bug go to:
Looks like this is already fixed, my bad.
** Changed in: python-django-piston (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-django-piston in Ubuntu.
Public bug reported:
Vivid contains Django 1.7 and djorm-ext-pgarray 0.8.
djorm-ext-pgarray version 0.8 is not compatible with Django 1.7
migration module. One of the symptoms is that the dbtype of an
ArrayField is ignored (and the default dbtype 'int' is used).
In other words, when declaring
Public bug reported:
In vivid, we have Django 1.7 and piston 0.2.3.
Piston 0.2.3 breaks with Django 1.7 because the module
django.utils.simplejson has been removed from Django 1.7
(https://docs.djangoproject.com/en/1.7/internals/deprecation
/#deprecation-removed-in-1-7). Note that it has been
Public bug reported:
The version currently available in Vivid for djorm-ext-pgarray (0.8)
doesn't work with Django 1.7 (the version in Vivid). See bug 1431789
for details.
I'd like to get the version 1.2 of djorm-ext-pgarray
(https://github.com/niwibe/djorm-pgarray/) into Vivid.
** Affects:
Can you please provide the full stacktrace (it should be in the logs in
/var/log/maas) and tell us which version you're using exactly?
** Changed in: maas (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Couldn't this be bug 1424509? (Because after installing `postgresql` on
vivid, the main cluster is down, see http://paste.ubuntu.com/10579015/)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
@Andres, the crash you're seeing is bug 1430324.
** Changed in: maas (Ubuntu)
Status: New = Confirmed
--
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/1430025
Title:
maas
I get the same crash (as described on the bug) when I installing 1.7 on Vivid.
It seems the DB is down:
$ sudo service postgresql status
sudo: unable to resolve host server-516c7ee2-8cb6-4c1f-b950-6b6900d74ead
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded
** Branch linked: lp:~rvb/maas/amt_wsman-1.7
--
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/1331214
Title:
MAAS (amttool) cannot control AMT version 8
To manage notifications about
** Changed in: maas/1.7
Assignee: Newell Jensen (newell-jensen) = Raphaël Badin (rvb)
** Changed in: maas/1.7
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
When we start transferring the kernel over, the machine on the other
side stops responding
This is indeed what seems to be causing the problem. Note that we're
seeing (a worrying number of) retries in some of the earlier (and
successful) transfers.
What kind of bridge is being used here?
This is how APT work. If you want to remove the dependencies that were
automatically installed by 'maas;, you need to: `sudo apt-get autoremove
--purge`
Well, I understand your point but you'll admit that it's strange to do this:
`sudo apt-get purge maas`
And after that, to still have MAAS fully
Hum, I tested again this morning (and answered yes to the two uninstall
questions, as I did before) and this time the DB got removed okay.
Maybe it's because the first time, I installed the packages differently
(with dpkg -i *.deb).
--
You received this bug notification because you are a member
Public bug reported:
One would expect `sudo apt-get purge maas` (or something simple like
that) to be enough to completely remove a MAAS installation from a
system. But this doesn't work. Because of the structure of the
different MAAS packages, one needs to remove a lot of packages to
finally
Public bug reported:
I just removed MAAS 1.7 from my system (apt-get purge maas maas...) and
the maasdb hasn't been removed although I answered 'yes' to the two
questions that I got from dpkg during the installation process (the last
one being something like : Do you want the MAAS' DB to be
** Changed in: maas (Ubuntu)
Status: New = Fix Committed
** No longer affects: maas
--
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/1411177
Title:
`make package` fails (Patch
Public bug reported:
`make package` fails with:
Applying patch 02-pserv-config.patch
patching file etc/maas/pserv.yaml
Hunk #1 succeeded at 6 with fuzz 2.
Hunk #2 FAILED at 15.
Hunk #3 succeeded at 18 (offset -20 lines).
1 out of 3 hunks FAILED -- rejects in file etc/maas/pserv.yaml
Patch
** Branch linked: lp:~rvb/maas/maas-1.7-3399
--
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/1399016
Title:
MAAS failed to respond once libapache2-mod-wsgi upgrade on trusty
To manage
Looks similar to bug 1377964, but for a different file.
--
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/1382266
Title:
maas-proxy fails to start on freshly installed MAAS
To manage
Out of curiosity, how did the existing setup(s) obtain these generated
hostnames in the first place? To my knowledge they were
neither exposed nor documented.
As Jeroen said, we need to understand this in order to suggest a
solution that fits CTS' needs. My guess is that they where deriving
** 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/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts:
I can't reproduce this so far, I've upgraded from
1.7.0~beta5+bzr3198-0ubuntu1~trusty1 to a package built from trunk; I've
seen bug 1380805 (i.e. the cluster got renamed) but I didn't see a new
cluster being created.
You said on IRC the upgrade wasn't smooth… can you describe what
happened
** Branch linked: lp:~rvb/maas/fix-etc-hosts-bug-1087183-2
--
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/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts:
As of MAAS 1.7, maas-import-ephermerals is gone.
** Changed in: maas
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/1271188
Title:
** Changed in: maas
Importance: High = 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/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'
** Changed in: python-django (Ubuntu)
Status: In Progress = Fix Committed
** 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
** Branch linked: lp:~rvb/maas/fix-region-admin-cli
** Changed in: python-django (Ubuntu)
Status: New = In Progress
** Changed in: python-django (Ubuntu)
Assignee: (unassigned) = Raphaël Badin (rvb)
--
You received this bug notification because you are a member of Ubuntu
Server
jsenum has no place in provisioning server, can't you extract that
part?
jsenum is *not* in provisioningserver, as I said above it's in
src/maasserver/utils/, where it should be. The problem is that it's
*using things* (well, one thing: map_enum) from provisioningserver
** Branch linked:
The utility in src/maasserver/utils/jsenums.py is used when building the
package. It uses the map_enum utility that recently from moved over to
src/provisioningserver/utils/__init__.py. The problem with that is that
is means that all the modules imported by
The logical place for map_enum really is
src/provisioningserver/utils/__init__.py since it's used by both
maasserver and pserv so I really don't want to put it somewhere else.
Since jsenum is special in the sense that it's used by the packaging,
I'd favor option 3: add a copy of map_enum (it's
From a packaging perspective, all that we can do here is the MIR,
right?
Yes. although now we're talking about using a different package: see bug
1331214.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
** Branch linked: lp:~rvb/maas/fix-bootloader-path
--
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/1328659
Title:
import_boot_images task fails on utopic
To manage notifications about
Looks like this is a problem with python-django-piston's packaging:
Result of `apt-cache show python-django-piston` in trusty:
http://paste.ubuntu.com/7653328/ and in utopic:
http://paste.ubuntu.com/7653329/
Note the difference in 'Depends':
Trusty:
Depends: python (= 2.7), python ( 2.8),
** Changed in: maas (Ubuntu)
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/1322151
Title:
ImportError: No module named pexpect setting up
mipf has been rewritten in Python.
** Changed in: maas
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/1182459
Title:
clean up root.tar.gz and fast
A new dependency on python-pexpect was introduced in revision 2353.
python-pexpect is in main so fixing this is as simple as adding a
dependency in the packaging.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
** Branch linked: lp:~rvb/maas/add-pexpect
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas (Ubuntu)
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
I can see that libvirt might be installed on a different machine though, so
perhaps we want virsh available but not libvirtd
installed and configured.
Raphaël, does this sound reasonable and is this what you need? If so, I guess
we'll need to split libvirt-bin in order to make
any
** Tags removed: maas-cli
** Tags added: cli
--
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/1319600
Title:
maas-cli stack trace if .maascli.db unreadable
To manage notifications
Public bug reported:
In order to manage a virsh node, MAAS needs the libvirt-bin package
(which contains `virsh`). libvirt-bin is only a suggested dependency so
the virsh power type doesn't work out of the box.
** Affects: maas (Ubuntu)
Importance: Undecided
Status: New
** Tags:
** Changed in: maas
Status: Triaged = 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/1086162
Title:
IPMI based power management default to IPMI 1.5 based
** Description changed:
- This seems to be a regression introduced in the latest security update
- which is causing the error
+ [Test case]
- AttributeError: 'functools.partial' object has no attribute
- '__module__'
+ Without the fix:
+ 1. Install MAAS
+ 2. Access the MAAS home page
** Changed in: maas/1.5
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas/1.5
Importance: Undecided = Critical
** Changed in: maas/1.5
Status: New = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
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
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1311151
** 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: 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/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
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
@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
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
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
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
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 =
@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
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
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
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
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
** 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
** 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
** 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
'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
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
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
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
** 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
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
This is pretty difficult to diagnose without access to a system that
shows the problem… If you're seeing this bug, could you please run a
couple of commands and paste the results:
sudo rabbitmqctl list_queues -p /maas_workers name messages_unacknowledged
messages memory
service
** Branch linked: lp:~rvb/maas/backport-fixes
** Also affects: maas/1.2
Importance: Undecided
Status: New
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Status: Triaged = Fix Committed
** Changed in: maas/1.2
Assignee
** Changed in: maas/1.2
Importance: Undecided = Critical
** Changed in: maas/1.2
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/1131418
Title:
1 - 100 of 206 matches
Mail list logo
