** Branch linked: lp:~rvb/maas/lp-1313550
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1313550
Title:
ping does not work as a normal user on trusty tarball cloud images.
To manage notifications ab
** Changed in: maas/1.8
Milestone: None => 1.8.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317705
Title:
Commissioning x86_64 node never completes, sitting at grub prompt,
pserv py tbs
T
** 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
Bugs, which is s
=> 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 becau
** Branch linked: lp:~rvb/maas/tftp-bug-1317705
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317705
Title:
Commissioning x86_64 node never completes, sitting at grub prompt,
pserv py tbs
To man
** Tags added: juju-net
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430025
Title:
maas uninstallable on vivid
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+sou
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431716
Title:
"ImportError: canno
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: djo
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 a
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 de
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
Bugs, which is subscribed
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430025
T
@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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1430025
Title:
maas uninstallable on vivi
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 (/lib/systemd/system/postgre
Looks like a packaging problem: the migrations in question are *not*
present in the package that used to be (?) in the testing PPA
(1.7.2~rc1+bzr3350-0ubuntu1~trusty2) but they *are* present in the
upstream code (1.7 revision 3350).
** Also affects: ubuntu
Importance: Undecided
Status: N
** 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
Bugs, which is subscribed to Ubuntu.
** Branch linked: lp:~rvb/maas/amt_wsman-1.7
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331214
Title:
MAAS (amttool) cannot control AMT version > 8
To manage notifications about this bug go to:
> 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? (virb
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 o
> 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
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 remov
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 ge
** Changed in: maas (Ubuntu)
Status: New => Fix Committed
** No longer affects: maas
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1411177
Title:
`make package` fails (Patch 02-pserv-config.
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 02-pser
** Branch linked: lp:~rvb/maas/maas-1.7-3399
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1399016
Title:
MAAS failed to respond once libapache2-mod-wsgi upgrade on trusty
To manage notifications a
> 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 derivin
Looks similar to bug 1377964, but for a different file.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1382266
Title:
maas-proxy fails to start on freshly installed MAAS
To manage notifications abou
** 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/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'
To
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 exactly
** Branch linked: lp:~rvb/maas/fix-etc-hosts-bug-1087183-2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'
To mana
** Changed in: maas
Importance: High => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1087183
Title:
MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'
To manage noti
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1271188
Title:
maas-import-ephermerals provides
** 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 Ub
** 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 Ubunt
> 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: lp:~r
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 just
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
src/provisioningserver/utils/__init__.p
> 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
** Branch linked: lp:~rvb/maas/fix-bootloader-path
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1328659
Title:
import_boot_images task fails on utopic
To manage notifications about this bug go to:
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), pyth
** Changed in: maas (Ubuntu)
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/1322151
Title:
ImportError: No module named pexpect setting up maas-dns
To man
** 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
Bugs, which is subscri
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
mipf has been rewritten in Python.
** Changed in: maas
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1182459
Title:
clean up root.tar.gz and fast path installer fi
> 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 pr
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
** Tags removed: maas-cli
** Tags added: cli
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1319600
Title:
maas-cli stack trace if .maascli.db unreadable
To manage notifications about this bug go to
** Changed in: maas
Status: Triaged => 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/1086162
Title:
IPMI based power management default to IPMI 1.5 based authentication
To manag
** 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 (http:
** 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
Bugs, which is s
** 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:
*** 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 wh
> 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 beca
** 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 w
** 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 subscri
** 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
** 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
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
** 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
** 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
** 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:
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 => T
@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 the
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 bu
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
ApportV
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
00-maas-03-install
> 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 b
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 wil
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 are
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 => 1
** 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
*** 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
B
@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'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 chec
** 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 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 speed
@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
http://bazaar.launchpad.net/~smoser/s
** 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-ll
** 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 m
** 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
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 that
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 th
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 man
** 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
I
** 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)
** Chan
** 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
--
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 mana
** 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
** 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 notifica
** 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: Tr
'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
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 g
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 "Run
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 LinuxProvisioningConfigu
> 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 us
** 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 manag
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 Ubunt
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
1 - 100 of 263 matches
Mail list logo
