1

I have attempted an upgrade from 1.5.4 to 1.8.0 (from the "stable" line of the PPA) on ULTS14 to go with an upgrade of Juju to 1.24.5 and I get the appended migration error.

Is there a away to get it to progress beyond that point Is it possible to revert to 1.5.4 (or to 1.7.6 for example)? What can I do at this point?

The MAAS instance manages 12 physical servers which are used by a Juju instance.

There is some previous material suggesting a reinstall of the packages, and I tried that, but that did not change the outcome, which I think depends on a data migration issue. Upgrading MAAS from 1.5.4 to 1.7.0 or latest on ubuntu 14.04

Python error during MAAS upgrade

 * Restarting PostgreSQL 9.3 database server
   ...done.
Syncing...
Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

Synced:
 > django.contrib.auth
 > django.contrib.contenttypes
 > django.contrib.sessions
 > django.contrib.sites
 > django.contrib.messages
 > django.contrib.staticfiles
 > piston
 > south

Not synced (use migrations):
 - maasserver
 - metadataserver
(use ./manage.py migrate to migrate these)
Running migrations for maasserver:
 - Migrating forwards to 0138_perf_index_on_node_events.
 > maasserver:0121_recompute_storage_size
Error in migration: maasserver:0121_recompute_storage_size
Traceback (most recent call last):
......
  File "/usr/lib/python2.7/dist-packages/django/db/backends/util.py", line 53, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "metadataserver_noderesult" does not exist
LINE 1: ..."."name", "metadataserver_noderesult"."data" FROM "metadatas...

To study the state of the MAAS database I have used this SQL query and the results look plausible and consistent, so I guess that the upgrade did not damaged it:

select
  m.mac_address                         as "Ethernet",
  w.name                                as "network",
  w.id                                  as "netid",
  w.ip                                  as "subnet",
  l.ip                                  as "lease",
  w.default_gateway                     as "gw",
  n.hostname                            as "node",
  n.storage                             as "storage",
  n.power_parameters                    as "WoL"
from
  maasserver_macaddress                 as m
    left join maasserver_macaddress_networks as m2n
    on m.id = m2n.macaddress_id
      left join maasserver_network      as w
      on m2n.network_id = w.id
  left join maasserver_dhcplease        as l
    on l.mac = m.mac_address
      inner join maasserver_node        as n
      on m.node_id = n.id
order by
  n.hostname,
  w.ip,
  m.mac_address
Community
  • 1
PeterG
  • 1,105
  • 7
  • 6
  • BTW I looked at the existing MAAS DB and it looks complete and consistent. There is a relation 'metadataserver_nodecommissionresult' rather than 'metadataserver_noderesult' so I guess that in some release between 1.5.4 and 1.8.0 it might have been renamed and this was not captured by one of the 'migrations' script. – PeterG Sep 12 '15 at 17:45
  • I have installed on a test system from scratch 1.5.4, 1.7.6 and 1.8.0 and the current database schema seems to match pretty closely 1.7.6 with the exception of 'metadataserver_noderesult' that has a fairly close equivalent. – PeterG Sep 15 '15 at 08:50
  • There is now a related issue entry about preventing this from happening 1495064 and the best guess is that this happened because of an ordering issue among the migration patches. – PeterG Sep 15 '15 at 08:51
  • It turns out that MAAS being a Django 1.6 application uses Django South to handle updates to the database schema, and that the default MAAS upgrade applies them potentially in the wrong order (first all those for the maasserver and then all those for the metadataserver). Since the updates applied are recorded recovery could be very simple. Testing it. – PeterG Sep 15 '15 at 12:35
  • The test where I install 1.5.4, load the quasi-1.7.6 database, and then upgrade to 1.7.6 succeeded, and only the missing 0015 migration was applied. The test where I installed 1.5.4, loaded the quasi-1.7.6 database, upgraded to 1.8.x (presently 1.8.2) failed as expected on migration 0121, and then downgrading to 1.7.6 succeeded with only migration 0015 installed. But this requires hand-editing some state in the DPKG database. And it left configurations in a state "to be reviewed". – PeterG Sep 15 '15 at 15:35

2 Answers2

0

It turns out that removing carefully the not-quite-installed 1.8.0 packages and installing 1.7.6 work as expected as per the tests already done. The metadataserver app 0015 "migration" gets applied and that leaves the migrations at 0120 for the maassserver app and 0015 for metadataserver which happen to be the right migration level for 1.7.6.

Important note: to remove the not-quite-installed 1.8.0 packages takes some hand-editing of /var/lib/dpkg/info/status and sometimes a related file to fake them being installed when they aren't.

PeterG
  • 1,105
  • 7
  • 6
0

This is being tracked under bug 1495064.

It will be fixed in MAAS 1.9.0 and MAAS 1.8.3.

mpontillo
  • 1,058