URI in API description wrong when accessing machine via alternative interface
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| MAAS |
High
|
Gavin Panella | ||
| 1.2 |
High
|
Gavin Panella | ||
| maas (Ubuntu) |
High
|
Unassigned | ||
| Quantal |
High
|
Unassigned | ||
| Raring |
High
|
Unassigned |
Bug Description
The API description obtained from my location, via the VPN into the test lab, contains URIs like http://
Possible solutions:
* maas-cli should override the netloc,
* The API description should not contain netloc.
* The server should describe itself according to the address by which is was accessed.
Related branches
- Raphaël Badin (community): Approve on 2012-11-01
-
Diff: 332 lines (+163/-16)6 files modifiedsrc/maasserver/api.py (+20/-4)
src/maasserver/apidoc.py (+3/-8)
src/maasserver/tests/test_api.py (+55/-0)
src/maasserver/tests/test_apidoc.py (+4/-4)
src/maasserver/utils/__init__.py (+18/-0)
src/maasserver/utils/tests/test_utils.py (+63/-0)
- Gavin Panella (community): Approve on 2012-11-02
-
Diff: 332 lines (+163/-16)6 files modifiedsrc/maasserver/api.py (+20/-4)
src/maasserver/apidoc.py (+3/-8)
src/maasserver/tests/test_api.py (+55/-0)
src/maasserver/tests/test_apidoc.py (+4/-4)
src/maasserver/utils/__init__.py (+18/-0)
src/maasserver/utils/tests/test_utils.py (+63/-0)
- Andres Rodriguez (community): Approve on 2012-11-19
-
Diff: 31 lines (+23/-1)1 file modifieddebian/changelog (+23/-1)
Changed in maas: | |
importance: | Critical → High |
milestone: | none → 12.10 |
Changed in maas: | |
milestone: | 12.10 → 12.10-stabilization |
Changed in maas: | |
milestone: | 12.10-stabilization → none |
Changed in maas: | |
assignee: | nobody → Gavin Panella (allenap) |
status: | Triaged → In Progress |
Changed in maas: | |
status: | In Progress → Fix Released |
status: | Fix Released → Fix Committed |
Changed in maas (Ubuntu Quantal): | |
importance: | Undecided → High |
Changed in maas (Ubuntu Raring): | |
importance: | Undecided → High |
Changed in maas (Ubuntu Quantal): | |
status: | New → Triaged |
Changed in maas (Ubuntu Raring): | |
status: | New → Triaged |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #3 |
This bug was fixed in the package maas - 1.2+bzr1349+
---------------
maas (1.2+bzr1349+
* New upstream bugfix release. Fixes:
- The DNS configuration is not created if maas-dns is installed after
the DNS config has been set up (LP: #1085865).
- IPMI detection ends up with power_address of 0.0.0.0 (LP: #1064224)
- Main page slow to load with many nodes (LP: #1066775)
- maas-cluster-
provisioning (LP: #1068843)
- Filestorage is unique to each appserver instance (LP: #1069734)
- import_pxe_files does not include quantal (LP: #1069850)
- maas-cli nodes new incomplete documentation (LP: #1070522)
- DNS forward zone ends up with nonsensical entries (LP: #1070765)
- The hostname of a node can still be changed once the node is in
use. (LP: #1070774)
- The zone name (attached to a cluster controller) can still be changed
when it contains in-use nodes and DNS is managed. (LP: #1070775)
- Duplicated prefix in the url used by the CLI (LP: #1075597)
- Not importing Quantal boot images (LP: #1077180)
- Nodes are deployed with wrong domain name. (LP: #1078744)
- src/maasserver/
parameter. That parameter is not supported by Django 1.3. (LP: #1080673)
- API calls that return a node leak private data (LP: #1034318)
- MAAS hostnames should be 5 easily disambiguated characters (LP: #1058998)
- URI in API description wrong when accessing machine via alternative
interface. (LP: #1059645)
- Oops when renaming nodegroup w/o interface (LP: #1077075)
- Error in log when using 'Start node' button: MAASAPINotFound: No user
data available for this node. (LP: #1069603)
[ Raphaël Badin ]
* debian/
* debian/
file /etc/bind/
[ Julian Edwards ]
* debian/
is no longer required as upstream no longer stores files in the filesystem.
(LP: #1069734)
* debian/
is updated when reconfiguring. (LP: #1081212)
[ Andres Rodriguez ]
* debian/control:
- maas-cluster-
- maas-dns: Conflicts with dnsmasq
- Drop Dependency on rabbitmq-server for maas-cluster-
(LP: #1072744)
- Add conflicts/replaces for maas-region-
maas-
* debian/
/MAAS if it doesn't contain it. This helps upgrades from versions where
DEFAULT_
* Install maas-import-
maas-
maas-
Vermuelen.
[ Gavin Panella ]
* debian/
* debian/maas-clu...
Changed in maas (Ubuntu Raring): | |
status: | Triaged → Fix Released |
Launchpad Janitor (janitor) wrote : | #4 |
This bug was fixed in the package maas - 1.2+bzr1373+
---------------
maas (1.2+bzr1373+
* MAAS Stable Release Update (LP: #1109283):
This SRU brings a new upstream release of MAAS that removes
the usage of a cobbler code copy, 'maas-provision' as well as
several bug fixes. Exception has been granted by the Technical
Board to proceed. More information can be found in:
https:/
[ Andres Rodriguez ]
* debian/control:
- Change Conflicts/Replaces for Breaks/Replaces.
- Conflicts on tftpd-hpa and dnsmasq.
- Do not pre-depends, but Depends on ${misc:Depends} for 'maas'.
[ Steve Langasek ]
* postinst scripts are never called with 'reconfigure' as the script
argument. Remove references to this (mythical) invocation.
* always call 'set -e' from maintainer scripts instead of passing 'sh -e'
as the interpreter, so that scripts will behave correctly when run via
'sh -x'.
* invoke-rc.d is never allowed to not exist - simplify scripts (and make
them better policy-compliant) by invoking unconditionally. (The only
possible exception is in the postrm, where it's *theoretically* possible
for invoke-rc.d to be missing if the user has completely stripped
down their system; that's a fairly unreasonable corner case, but we
might as well be correct if it ever happens.)
* db_get+db_set is a no-op; don't call db_set to push back a value we just
got from db_get.
* Omit superfluous calls to 'exit 0' at the end of each script.
* Remove maas-cluster-
reason.
* Don't invoke debconf in the postrm script either, debhelper already does
this for us.
* Other miscellaneous maintainer script fixes
* debian/
the tools are already designed to DTRT, we don't need to check for the
user/group existence before calling them nor should we worry about
calling them only once on first install.
* debian/
as the comment in the code implies we should do.
-- Andres Rodriguez <email address hidden> Thu, 07 Mar 2013 14:22:35 -0500
Changed in maas (Ubuntu Quantal): | |
status: | Triaged → Fix Released |
Was this fixed?