** Changed in: maas
Assignee: (unassigned) = Andres Rodriguez (andreserl)
** Also affects: maas/1.2
Importance: Undecided
Status: New
** Changed in: maas/1.2
Milestone: None = 12.10-stabilization
** Changed in: maas/1.2
Assignee: (unassigned) = Andres Rodriguez
I'm reverting the fix for this and re-opening the bugs because the fix
broke our integration test suite in the QALab; it made MAAS unable to
power up the machines. If we need support for both IPMI 1.5 and IPMI
2.0 at the same time, I suggest we do something along the lines of:
@Scott. This bug appears everytime the DNS config is wrong and the
query issued an enlisting node times out.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas-enlist in Ubuntu.
https://bugs.launchpad.net/bugs/1081660
Title:
If
issued by* an enlisting node
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas-enlist in Ubuntu.
https://bugs.launchpad.net/bugs/1081660
Title:
If maas-enlist fails to reach a DNS server, the node will be named ;;
connection
We've generating the omapi_key when the nodegroup objects are generated.
For the master nodegroup (corresponding to the main cluster controller),
this happens when the application starts up. If the maas-dns package is
not installed, the tool to generate the key might not be installed (it's
a
** 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/1103195
Actually, as suggested by Andres, adding bind9utils as a dependency to
the region controller package is a much simpler way to fix this. Since
bind9utils is a tiny collection of utilities, it's really harmless.
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Doing what I suggest above would indeed fix the immediate problem but
this leads to bigger problems:
The code assumes in two places (see bellow) that the first cluster to connect
is the cluster controller installed on the same machine as the region
controller. This is based on the assumption
The fix you're talking about did not touch the code used when a cluster
connects for the first time.
--
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/1103195
Title:
MAAS WebUI crashes
** Branch linked: lp:~rvb/maas/packaging-1103195
** Branch linked: lp:~rvb/maas/packaging.quantal-1103195
** Branch linked: lp:~rvb/maas/packaging.precise.sru-1103195
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
I guess this is in fact a bug distinct from this one, I've filed bug
1104215.
--
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/1103195
Title:
MAAS WebUI crashes when installing
To ensure that we accept as master only the cluster controller on
the local machine, can the region compare the UUID it's given against
the UUID it can see on the filesystem?
A simpler way (which we already use to know if we need to update
nodegroup.maas_url or not when a cluster connects) is
** Changed in: maas
Assignee: Raphaël Badin (rvb) = (unassigned)
--
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/1130232
Title:
Implement GenericIpAddressField in MAAS rather than
I'm not sure fixing this in the packaging is the right solution here.
If we have a patch to add the new classes (plural, there is the field
model and the form model), then we will have to update the upstream code
to match that (everywhere where it's imported plus in all the migration
files where
Julian suggested another way to do this: carry a packaging patch with
the field and the changes required to the source to use it. My main
concern is that this field (as a string
'django.db.models.fields.GenericIPAddressField') is used by South in the
migration code and, although this solution is
On 02/20/2013 03:54 PM, Dave Walker wrote:
Does it make sense to monkey patch if django required version?
It's also a possibility, but given the way Django plays with imports,
this could be a dangerous game.
Either way, this shouldn't be solved in packaging.. it's core support
needed in
On 02/20/2013 08:32 PM, Andres Rodriguez wrote:
Oh btw... we need to make sure that this doesn't provide any regression
or upgrade failures from those who have been using MAAS from ppa:maas-
maintainers/stable.
Good point, that's another argument in favor of the monkey patch
solution.
--
You
On 02/20/2013 04:11 PM, Raphaël Badin wrote:
On 02/20/2013 03:54 PM, Dave Walker wrote:
Does it make sense to monkey patch if django required version?
It's also a possibility, but given the way Django plays with imports,
this could be a dangerous game.
That being said, the monkey patch
Either way, this shouldn't be solved in packaging.. it's core support
needed in MAAS for backwards compatibility.
More importantly, fixing this upsteam is better because it means that
the monkey patching code and the code stolen from django 14 gets
exercised when we run the test suite on a
** Also affects: maas/1.2
Importance: Undecided
Status: New
** No longer affects: maas
** Changed in: maas/1.2
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas/1.2
Importance: Undecided = Critical
** Changed in: maas/1.2
Status: New = In Progress
** Branch linked: lp:~rvb/maas/generic-field-1.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/1130232
Title:
Implement GenericIpAddressField in MAAS rather than django.
To manage
Public bug reported:
This is the apache log when nodes are enlisting:
http://paste.ubuntu.com/1700172/
The url used is wrong: /MAAS/api/1.0/nodes//MAAS/api/1.0/nodes/ instead of
/MAAS/api/1.0/nodes/.
Now this is working because of a bug in how MAAS itself parses the urls but
that bug is about
** Changed in: maas/1.2
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/1130232
Title:
Implement GenericIpAddressField in MAAS rather than
Can you tell us with which package you're getting this?
I installed successfully the daily packages on quantal and raring
canonistack instances (http://paste.ubuntu.com/5570250/ /
http://paste.ubuntu.com/5570252/).
--
You received this bug notification because you are a member of Ubuntu
Server
No it's not, see the two links I pasted.
--
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/1134036
Title:
Package install hangs if LC_ALL is not set
To manage notifications about this
The links aren't that useful because it's showing the post-facto state. If
you could deliberately unset LC_ALL and then install the
packages from scratch it would be closer to my own experience.
That's what I did and it seems fine (easy to recreate on a canonistack
instance):
This also affects the precise and quantal packaging branches so it's
probably worth fixing it there too.
--
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/1167660
Title:
** 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:
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
** 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
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
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
** 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
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
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
You can delete a node like this:
$ sudo maas
from maasserver.models import Node
node = Node.objects.get(hostname='myhostname')
node.delete()
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
I think what you're describing is bug 1003460.
--
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/1005298
Title:
warning: kernel option length exceeds 255 during maas-import-isos
To
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
--
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/1021382
Title:
The COMMISSIONING_SCRIPT setting uses a relative
fwiw, I'm with Gavin on this one, that's a *minor* problem with the
*dev* environment so that definitely seems like low priority to me.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bind9 in Ubuntu.
I see two possible solutions to that problem:
a) we could add a lookup method to the API. The method would return a list
of system IDs from a set of criteria (mac adress would be one of the possible
criteria).
b) or, if we want to promote the mac address as an identifier, we could allow
the
** Changed in: maas
Status: Incomplete = Triaged
--
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/1027154
Title:
Unable to look up a node based on mac address
To manage
** Branch linked: lp:~rvb/maas/bug-1027154
--
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/1027154
Title:
Unable to look up a node based on mac address
To manage notifications about
I've added a filter to the 'list' API method:
/api/1.0/nodes/?op=listmac_address=MAC1mac_address=MAC2.
** Changed in: maas
Status: Triaged = Fix Released
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
--
You received this bug notification because you are a member
Public bug reported:
To enable DNS we need to:
- make sure that bind9utils dnsutils bind9 python-netaddr are installed (new
dependencies)
- make sure that the directory /etc/bind/maas
(etc/celeryconfig.py:DNS_CONFIG_DIR) is created
- call `sudo maas set_up_dns` (this will create an empty [i.e.
** Description changed:
To enable DNS we need to:
- make sure that bind9utils dnsutils bind9 python-netaddr are installed (new
dependencies)
- make sure that the directory /etc/bind/maas
(etc/celeryconfig.py:DNS_CONFIG_DIR) is created
- call `sudo maas set_up_dns` (this will create an
Public bug reported:
We've changed how MAAS treats the setting DEFAULT_MAAS_URL: now the
FORCE_SCRIPT_NAME is not appended by the code if DEFAULT_MAAS_URL is
defined in maas_local_settings.py. The packaging should be changed so
that DEFAULT_MAAS_URL will be http://server.ip/MAAS; (as opposed to
** Also affects: maas (Ubuntu)
Importance: Undecided
Status: New
** 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
** 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/1037400
Title:
python-lockfile missing from list of required dependencies
** Branch linked: lp:~rvb/maas/maas-package-bug-1037400
--
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/1037400
Title:
python-lockfile missing from list of required dependencies
To
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas (Ubuntu)
Status: Triaged = In Progress
** Changed in: maas (Ubuntu)
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
When masternodegroup.set_up_dhcp() is called, the script /usr/sbin/maas-
provision is used to write the DHCP configuration. That script is run
using sudo in order to be able to write the config into
/etc/dhcp/dhcpd.conf.
The sudo rule to allow that sudo command to be run is
Julian suggested putting the sudoers file which is currently in the
packaging branch into the upstream branch (in contrib). The main
advantage would be that it would be more easy for someone running maas
directly from the tree to copy the required sudo rules from
contrib/sudoers.
--
You
** Description changed:
None of the BROKER_* settings are defined in celeryconfig; that means
- that the 'guest' account is used by MAAS to send messages trough
+ that the 'guest' account is used by MAAS to send messages through
RabbitMQ. That might have been OK while everything was local
The packaging needs to be fixed only when we will have a separate
package for the cluster controller. If we land the branch
lp:~rvb/maas/packaging.set-rabbitmq-creds now, it will break the
communication between the master cluster controller and the region
controller since the master cluster
Turns out that the cluster controller and the region controller both use
the same config file at the moment so even with the package we have
right now, this can be fixed.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
Public bug reported:
The celery cluster is started in
upstream:src/provisioningserver/start_cluster_controller.py, called from
the upstart script packaging:debian/maas-cluster-controller.maas-
cluster-celery.upstart. When all the MAAS' services are stopped (for
instance when all the MAAS
** 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/1059485
Title:
maas_local_celeryconfig.py is world readable
To manage notifications about this
** Changed in: maas (Ubuntu)
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/1059485
Title:
maas_local_celeryconfig.py is world readable
To
Public bug reported:
Testing the package in the daily ppa
(0.1+bzr1170+dfsg-0+1215+119~ppa0~quantal1), the cluster controller is
unable to start:
$ sudo tail -f /var/log/upstart/maas-cluster-celery.log
usage: __main__.py start-cluster-controller [-h] [--user USER] [--group GROUP]
At Andres' request, here is the output of sudo dpkg-reconfigure -phigh
maas-cluster-controller :
$ sudo dpkg-reconfigure -phigh maas-cluster-controller
maas-cluster-celery stop/waiting
/var/lib/dpkg/info/maas-cluster-controller.config: 26:
/var/lib/dpkg/info/maas-cluster-controller.config:
** Branch linked: lp:~andreserl/maas/packaging_update_cluster
--
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/1063857
Title:
Cluster controller fails to start because MAAS_URL is not
I've tested the most recent package (0.1+bzr1223+dfsg-0ubuntu1~ppa1) and
the problem is fixed.
** Changed in: maas (Ubuntu)
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.
Public bug reported:
The cluster controller package uses /var/log/maas/ to store the log file
of the pserv service. That directory is not created by the cluster
controller package and thus the pserv service fails to start:
http://paste.ubuntu.com/1269596/
** Affects: maas (Ubuntu)
** Project changed: maas = maas (Ubuntu)
** Changed in: maas (Ubuntu)
Assignee: Raphaël Badin (rvb) = (unassigned)
--
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/1064960
Title
** Branch linked: lp:~rvb/maas/packaging.fix-longpoll
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Raphaël Badin (rvb)
--
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
Public bug reported:
When the cluster controller is installed on a separate machine (i.e. not
next to the region controller), the celery DB file can't be created in
/var/lib/maas/celerybeat-cluster-schedule (because the directory
/var/lib/maas/ is not created).
** Affects: maas (Ubuntu)
Public bug reported:
In debian/maas-region-controller.postinst:
[...]
configure_maas_workers_rabbitmq_user() {
local workers_user=maas_workers
local workers_pass=$(pwgen -s 20)
local workers_vhost=/maas_workers
local amqp_host=localhost
local
** Also affects: maas
Importance: Undecided
Status: New
** Changed in: maas
Assignee: (unassigned) = Raphaël Badin (rvb)
** Changed in: maas
Importance: Undecided = Critical
** Changed in: maas
Status: New = In Progress
** Summary changed:
- The host in BROKER_URL
After a discussion with Julian, we decided that this should be fixed in
the packaging: instead of using 'localhost' (in debian/maas-region-
controller.postinst), the packaging script should use the IP address of
the default route (just like what it does to populate DEFAULT_MAAS_URL).
** No longer
Can't be done in the packaging because the 'maas' package (which
contains Django settings) is not on the path (standard Django
application packaging policy). For now, let's copy over the 2 methods
in the celeryconfig_cluster.py and file a tech-debt bug.
--
You received this bug notification
** Package changed: maas (Ubuntu) = maas
** 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/1065055
Title:
celeryconfig_cluster.py
setup_rndc() (in src/provisioningserver/dns/config.py) should be fixed
to write the file with the appropriate permissions.
** Package changed: maas (Ubuntu) = maas
** Changed in: maas
Importance: Undecided = High
** Changed in: maas
Status: New = Triaged
--
You received this bug
I would suggest that maas explicitly provide the key that it wishes to use
whenever it interacts with bind9 so that defaults don't
have to change
Looks like a very good idea to me.
** Package changed: maas (Ubuntu) = maas
** Changed in: maas
Importance: Undecided = Critical
** Changed
I see two ways to fix this:
- we can fix this in the packaging and avoid adding the entry in
/etc/bind/named.conf.local if it's already there
or
- we can fix the 'get_named_conf' command so that it won't include the snippet
if it's already there. Maybe we could use write_custom_config_section
** 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/1067332
Title:
'dkpg-reconfigure' conflates user existing for vhost existing
To manage notifications about
Public bug reported:
maas-region-celeryd connects to 2 queues: ' celery' and 'master'. The
problem is obviously the space in front of 'celery'
start_celery() should use something like that instead:
command = [
'celeryd',
'--logfile=%s' % args.logfile,
'--schedule=%s'
Andres says it was a missing =. It used to say:
--queues celery,master
and he's fixing it to say:
--queues=celery,master
More precisely, the script was using os.execv('celeryd',… , '-Q
celery,master',…) and the space before 'celery' got escaped. I
suggested using the alternative syntax
** 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/1066958
Title:
DNS config is invalid after a node gets enlisted.
** 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/1066938
Title:
maas-dns changes default bind rndc key and breaks
** Changed in: maas (Ubuntu)
Status: Fix Committed = 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/1066929
Title:
duplicate entry added to named.conf.local on
A workaround is to edit the maas-region-celeryd script (sudo vim
/usr/sbin/maas-region-celeryd) and change: '-Q celery,master' into '
--queues=celery,master'.
Then restart the service:
$ sudo service maas-region-celery restart
--
You received this bug notification because you are a member of
The file permissions are actually handled in the package. Reassigning
this bug.
** Branch linked: lp:~rvb/maas/packaging.bug-1066935
** Project changed: maas = maas (Ubuntu)
** Changed in: maas (Ubuntu)
Milestone: 12.10-stabilization = None
--
You received this bug notification because
*** This bug is a duplicate of bug 1066958 ***
https://bugs.launchpad.net/bugs/1066958
This is a duplicate of bug 1066958 which is fixed in the current trunk.
This will be part of the upcoming SRU package.
** This bug has been marked a duplicate of bug 1066958
DNS config is invalid after
MAAS supports managing DHCP but not DNS. The problem is that the task
'write_full_dns_config' (connected via signals) is always triggered
(when a nodegroup is changed or a node updated). We simply need to skip
actually trying to write the configuration if none of the cluster has
been configured
Actually, I think you're seeing two distinct problems here:
- The first one is that the default hostname picked up during enlistment
is IP-based and thus it assumes that the IP lease will stay the same.
If the lease changes, this change is not reflected in the DNS config
because this is resolved
Hi Thiago,
There is a background task that should be responsible for cleaning up
the message if no new images are detected, can you please have a look in
/var/log/maas/celery-region.log and confirm that you're seeing the task
being processed all right?
If it is the case, the log file will
The apparmor error(s) would be in /var/log/syslog. For instance, if I
manually change the apparmor maas dhcp.d profile so that the lease file
can't be read I get this in /var/log/syslog :
http://paste.ubuntu.com/1297221/
--
You received this bug notification because you are a member of Ubuntu
Ok, let me clarify the situation here: this bug needed to be fixed in
order for the message to disappear and the fix has landed a few days
ago. But there is another bug (bug 1070318) which *also* prevents the
message from being properly removed.
Bug 1068843 is currently being worked on and it
: Undecided
Assignee: Andres Rodriguez (andreserl)
Status: New
** Affects: maas (Ubuntu Raring)
Importance: Low
Assignee: Andres Rodriguez (andreserl)
Status: Triaged
** Project changed: maas = maas (Ubuntu)
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Raphaël
Public bug reported:
When upgrading from precise to quantal, the maas_workers rabbitmq user
got its password changed (in rabbitMQ) but the configuration file
/etc/maas/maas_local_celeryconfig.py was not upgraded accordingly.
** Affects: maas (Ubuntu)
Importance: Critical
Assignee:
** Changed in: maas/1.2
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/1070765
Title:
DNS forward zone ends up with nonsensical entries
To
** Changed in: maas
Status: Fix Committed = In Progress
** Changed in: maas/1.2
Status: Fix Committed = 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/1070522
** 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/1070522
Title:
maas-cli nodes new incomplete documentation
To manage
** Changed in: maas/1.2
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/1070522
Title:
maas-cli nodes new incomplete documentation
To manage
1 - 100 of 469 matches
Mail list logo
