(FWIW somebody landed a fix recently to suppress the initialization of
NodeGroup.maas_url if the given URL had localhost as its hostname. It
seems like a better way to deal with the maas_url part of the problem.)
--
You received this bug notification because you are a member of Ubuntu
Server
(Correction: I meant to say that AIUI, that fix suppresses _any_
initialization of maas_url, regardless of whether the calling code
thinks it's dealing with the master cluster)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in
Looks like this was caused by a missing en_US entry in Julian's
/usr/share/locale.
I'm seeing another, but possibly related failure where the error is that
the database is not running; filed as bug 1171696.
--
You received this bug notification because you are a member of Ubuntu
Server Team,
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** Changed in: maas (Ubuntu)
Status: Triaged = In Progress
** Branch linked: lp:~jtv/maas/pkg-bug-1059485
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
I do believe it tries to be careful not to delete other packages' files
in the process. Did you see any files left in those locations?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
Update for the record. As we have since found out, it's much worse than
just needing an expect fork. Somewhere along the line, before it gets
around to running the start-cluster-controller code proper, maas-
provision does a whole bunch of other forks. The question is whether we
can make
** Changed in: maas
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** 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
The same patch as in the merge-proposal diff also needs to be applied in
the package. Two of those three instances of the problem have already
been fixed upstream though.
** Also affects: python-tx-tftp (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification
Stealing this bug from Julian since he's packing, not packaging right
now. :)
** Changed in: maas (Ubuntu)
Assignee: Julian Edwards (julian-edwards) = Jeroen T. Vermeulen (jtv)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
** Changed in: maas
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
--
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/1070774
Title:
The hostname of a node can still be changed
Small Q/A failure: renaming an accepted nodegroup that has no interfaces
will oops. See bug 1077075 (and don't get confused by the similarity in
bug numbers...)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
The Q/A failure has been fixed in both the trunk and 1.2 branches.
--
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/1070775
Title:
The zone name (attached to a cluster controller) can
Public bug reported:
I just created a keyfile on a new machine by running euca-add-keypair
and directing its output into a key file. The key didn't work, for no
immediately clear reason. Turns out my keyfile now contains this text:
KeyPairExists: Key pair '...' already exists.
Would have
** Changed in: maas
Milestone: None = 13.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/1236361
Title:
need new simple streams based maas-import-ephemerals
To manage
** 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/1236361
Title:
need new simple streams based maas-import-ephemerals
To
Don't know if this matters, but...
The blog article suggests WSGIProcessGroup %{GLOBAL}. We have
WSGIApplicationGroup %{GLOBAL}, but WSGIProcessGroup maas.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pymongo in Ubuntu.
** Changed in: maas
Milestone: None = 14.04
** Changed in: maas
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** Changed in: maas
Importance: Undecided = High
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas
For the historical record:
* createsuperuser is a Django built-in command, not our code.
* We have our own MAAS-tailored version, createadmin.
* The email field must be unique and non-null, but can be empty.
* MAAS already creates a system user with empty email address.
* A null email
See bug 1284964 for a possible explanation: the enlist_userdata calls
dig to look up a hostname, but does not check for errors — and dig
prints the error message to stdout, not stderr, so it ends up in the
hostname field.
--
You received this bug notification because you are a member of Ubuntu
** Project changed: maas = maas (Ubuntu)
** Changed in: maas (Ubuntu)
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/1299989
Title:
maas-dns fails to
Public bug reported:
In my MAAS test setup, nodes now fail to enlist or commission. They
used to work, I think before we changed to the new import script.
Both for enlistment and commissioning the nodes netboot properly, as far
as I can see, but they fail to do what they booted for. They never
I wasn't getting any new files from the import script. Am now re-
running the entire import from scratch.
--
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/1300026
Title:
Yay! A fresh import solved it.
** Changed in: maas
Status: Incomplete = Invalid
** Changed in: maas (Ubuntu)
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
That sounds as if it's probably just bug 1300548, which is already
fixed. Definitely not the same thing that this bug is about.
** Changed in: maas
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
** Changed in: maas/1.5
Milestone: None = 14.04
** Changed in: maas
Milestone: None = 14.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/1302772
Title:
update of
The latest build in ppa:maas-maintainers/dailybuilds should have the
fix. Could you try again, but with that package?
--
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/1302772
Title:
** 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/1302772
Title:
update of maas-cluster-controller on trusty dumps
I am attaching a fix for the part of the problem that's in
maas/preseeds/curtin_userdata, in the maas source tree. This won't be
enough to fix the whole problem, so I am not marking the branch as
“fixing” this bug.
** Branch linked: lp:~jtv/maas/use-main-archive-for-intel-arches
--
You
** Branch linked: lp:~jtv/maas/use-main-archive-for-intel-arches
--
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/1310082
Title:
d-i with precise+hwe-s stops at Architecture not
Upstream bug seems to be https://code.djangoproject.com/ticket/22486
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-django in Ubuntu.
https://bugs.launchpad.net/bugs/1311433
Title:
REGRESSION: AttributeError:
** Branch linked: lp:~jtv/maas/1.5-use-main-archive-for-intel-arches
--
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/1310082
Title:
d-i with precise+hwe-s stops at Architecture not
** Branch linked: lp:~jtv/maas/1.5-use-main-archive-for-intel-arches
--
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 connectivity to a node when using
** Changed in: maas
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** Changed in: maas/1.5
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to python-django in Ubuntu.
https
** Description changed:
+ [Test Case]
+ No test case; the code that's being patched is only a test and does not
actually appear in the package.
+
+
+ [Description of the problem]
+
This happened when trying to land a documentation-only branch:
** Branch linked: lp:~jtv/maas/revert-bug-1311433
--
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/1311433
Title:
REGRESSION: AttributeError: 'functools.partial' object has no
** Branch linked: lp:~jtv/maas/1.5-revert-bug-1311433
--
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/1311433
Title:
REGRESSION: AttributeError: 'functools.partial' object has no
It happened again. I suspect that it may be a matter of ordering of
decorators: RegionAdvertisingService.prepare is decorated as
@synchronous, and *then* as taking two locks.
Given decorators' wrapping behaviour, which reverses the order of
entrance, I understand that to mean: grab these two
No, my hypothesis doesn't look correct. We don't see anything that
would make prepare() jump into the reactor thread.
--
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/1308069
Title:
New hypothesis: the code in DatabaseLock opens, and closes, a cursor for
each locking/unlocking command. Do we actually know that these cursors
will be in the same database session? If the command failed, do we know
that we would see an error?
--
You received this bug notification because you
Could this be bug 1186662? The main packaging branch has a workaround
for that which is worth a try.
It's a matter of adding this line to /etc/apparmor.d/dhcpd.d/maas:
capability dac_override,
...and then reloading the apparmor config.
--
You received this bug notification because you
Public bug reported:
When I “make package” (with trunk r3227 and packaging r317) I get this
error:
«
patching file contrib/maas_local_settings.py
Hunk #2 FAILED at 81.
1 out of 2 hunks FAILED
dpkg-source: info: fuzz is not allowed when applying patches
dpkg-source: info: if patch
I agree: this is a clear-cut case for the request-an-address API, but we
still lack a request-a-hostname API.
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. MAAS never had much
Ah, I see that using the IP address is not an option in this case. So
we'll have to add a way to manage DNS entries.
--
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/1382190
Title:
now contains...
generator: http://10.9.9.1:caf5:2922:8b1f::1]/MAAS/api/1.0/pxeconfig/
Note how the first part of the netloc, up to the first colon, is
replaced with the new address — but the rest of the netloc is still
there.
** Changed in: maas
Assignee: Jeroen T. Vermeulen (jtv
** Description changed:
- Reconfiguring between an IPv4-based and an IPv6-based MAAS_URL broke the
- ‘generator’ setting in my pserv.yaml: it ended up being the full IPv4
- netloc, with most of the IPv6 netloc tacked onto it.
+ Reconfiguring when the existing MAAS_URL used an IPv6 host address
** Changed in: maas
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** Changed in: maas
Status: Triaged = In Progress
** Branch linked: lp:~jtv/maas/bug-1373261
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas
** Changed in: maas (Ubuntu)
Assignee: (unassigned) = Jeroen T. Vermeulen (jtv)
** Changed in: maas (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https
** Changed in: maas
Status: In Progress = Fix Committed
** 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.
48 matches
Mail list logo
