upgrade of maas from 1.9.1 to 2.0 'str' object has no attribute 'version'

[David Britton]

I get the following upon loading the 2.0 gui after an upgrade from 1.9.1 to 2.0:

'str' object has no attribute 'version'

It loads all the nodes, but after a second or two, falls back to this message. I have tried reloading the gui with shift-f5, logging out, logging in, new browser.

[David Britton (dpb)]

2016-04-27 17:22:51 [-] Error on request (39) subnet.list: 'str' object has no attribute 'version'
        Traceback (most recent call last):
          File "/usr/lib/python3.5/threading.py", line 862, in run
            self._target(*self._args, **self._kwargs)
          File "/usr/lib/python3/dist-packages/provisioningserver/utils/twisted.py", line 841, in worker
            return target()
          File "/usr/lib/python3/dist-packages/twisted/_threads/_threadworker.py", line 46, in work
            task()
          File "/usr/lib/python3/dist-packages/twisted/_threads/_team.py", line 190, in doWork
            task()
        --- <exception caught here> ---
          File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 246, in inContext
            result = inContext.theWork()
          File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 262, in <lambda>
            inContext.theWork = lambda: context.call(ctx, func, *args, **kw)
          File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 118, in callWithContext
            return self.currentContext().callWithContext(ctx, func, *args, **kw)
          File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 81, in callWithContext
            return func(*args,**kw)
          File "/usr/lib/python3/dist-packages/provisioningserver/utils/twisted.py", line 874, in callInContext
            return func(*args, **kwargs)
          File "/usr/lib/python3/dist-packages/maasserver/utils/orm.py", line 516, in call_within_transaction
            return func_outside_txn(*args, **kwargs)
          File "/usr/lib/python3/dist-packages/maasserver/utils/orm.py", line 343, in retrier
            return func(*args, **kwargs)
          File "/usr/lib/python3.5/contextlib.py", line 30, in inner
            return func(*args, **kwds)
          File "/usr/lib/python3/dist-packages/maasserver/websockets/base.py", line 343, in list
            for obj in objs
          File "/usr/lib/python3/dist-packages/maasserver/websockets/base.py", line 343, in <listcomp>
            for obj in objs
          File "/usr/lib/python3/dist-packages/maasserver/websockets/base.py", line 195, in full_dehydrate
            return self.dehydrate(obj, data, for_list=for_list)
          File "/usr/lib/python3/dist-packages/maasserver/websockets/handlers/subnet.py", line 42, in dehydrate
            full_range = subnet.get_iprange_usage()
          File "/usr/lib/python3/dist-packages/maasserver/models/subnet.py", line 488, in get_iprange_usage
            reserved_ranges = self.get_ipranges_in_use()
          File "/usr/lib/python3/dist-packages/maasserver/models/subnet.py", line 442, in get_ipranges_in_use
            self.gateway_ip in ipnetwork):
          File "/usr/lib/python3/dist-packages/netaddr/ip/__init__.py", line 720, in __contains__
            item = IPAddress(self.last + index + 1, self._module.version)
        builtins.AttributeError: 'str' object has no attribute 'version'

[Mike Pontillo (mpontillo)]

This traceback is really strange. It looks like it could be a bug in the python3-netaddr package.

What version do you have installed? For comparison, I have:

$ apt-cache policy python3-netaddr
python3-netaddr:
  Installed: 0.7.18-1
  Candidate: 0.7.18-1
  Version table:
 *** 0.7.18-1 500
        500 http://172.16.42.88/ubuntu xenial/main amd64 Packages
        500 http://172.16.42.88/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status

In order to triage this, I'll need to know the CIDR of each subnet you have defined, and the gateway IP defined for each subnet. You could easily retrieve this by executing the following:

$ sudo maas-region dbshell
psql (9.5.2)
Type "help" for help.

maasdb=# select cidr, gateway_ip from maasserver_subnet;
       cidr | gateway_ip
------------------+----------------
 192.168.122.0/24 |
 172.16.100.0/24 | 172.16.100.254
 172.16.42.0/24 | 172.16.42.1
(3 rows)

maasdb=# \q

[David Britton (dpb)]

maasdb=# select cidr, gateway_ip from maasserver_subnet;
           cidr | gateway_ip
--------------------------+------------
 169.254.0.0/24 |
 169.254.1.0/24 |
 10.2.0.0/16 | 10.2.0.1
 10.1.0.0/16 | 10.1.0.1
 10.0.7.0/24 | 10.0.7.1
 10.3.0.0/16 |
 10.0.3.0/24 |
 10.47.46.0/24 |
 fd20:23d2:e863:db34::/64 |
 192.168.122.0/24 |
(10 rows)

[David Britton (dpb)]

postgres@virtue:~$ apt-cache policy python3-netaddr
python3-netaddr:
  Installed: 0.7.18-1
  Candidate: 0.7.18-1
  Version table:
 *** 0.7.18-1 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status

[Mike Pontillo (mpontillo)]

Hmm, I tried out all those combinations of CIDRs and gateways, and I don't see a problem with the code yet:

https://paste.ubuntu.com/16091312/

Can you run the script in that pastebin on the machine where it's failing and let me know the result?

Another thing you might try:

sudo aptitude reinstall python3-netaddr

[David Britton (dpb)]

10.2.0.1 in 169.254.0.0/24: False
10.1.0.1 in 169.254.0.0/24: False
10.0.7.1 in 169.254.0.0/24: False
10.2.0.1 in 169.254.1.0/24: False
10.1.0.1 in 169.254.1.0/24: False
10.0.7.1 in 169.254.1.0/24: False
10.2.0.1 in 10.2.0.0/16: True
10.1.0.1 in 10.2.0.0/16: False
10.0.7.1 in 10.2.0.0/16: False
10.2.0.1 in 10.1.0.0/16: False
10.1.0.1 in 10.1.0.0/16: True
10.0.7.1 in 10.1.0.0/16: False
10.2.0.1 in 10.0.7.0/24: False
10.1.0.1 in 10.0.7.0/24: False
10.0.7.1 in 10.0.7.0/24: True
10.2.0.1 in 10.3.0.0/16: False
10.1.0.1 in 10.3.0.0/16: False
10.0.7.1 in 10.3.0.0/16: False
10.2.0.1 in 10.0.3.0/24: False
10.1.0.1 in 10.0.3.0/24: False
10.0.7.1 in 10.0.3.0/24: False
10.2.0.1 in 10.47.46.0/24: False
10.1.0.1 in 10.47.46.0/24: False
10.0.7.1 in 10.47.46.0/24: False
10.2.0.1 in fd20:23d2:e863:db34::/64: False
10.1.0.1 in fd20:23d2:e863:db34::/64: False
10.0.7.1 in fd20:23d2:e863:db34::/64: False
10.2.0.1 in 192.168.122.0/24: False
10.1.0.1 in 192.168.122.0/24: False
10.0.7.1 in 192.168.122.0/24: False

[Mike Pontillo (mpontillo)]

Marking Incomplete for now since I couldn't get anywhere with just the database, and I couldn't reproduce after attempting an upgrade from trusty -> xenial.

If I can take a look while this is actively happening, that would be greatly appreciated.

[Andres Rodriguez (andreserl)]

We believe this is no longer an issue. Please re-open this bug report or file a new one if you believe this issue is still valid.