Trying to upgrade to 3.14.15926
mcc.py fails somwhere in the middle of moving switch-ports to ports with
File "/usr/local/nav/bin/mcc.py", line 29, in <module> start_config_creation(modules, config) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 65, in start_config_creation result = mod.make_config(config) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/nav/lib/python/nav/mcc/interfaces.py", line 52, in make_config results.append(start_config_creation(module, configroot)) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/nav/lib/python/nav/mcc/interfaces.py", line 111, in start_config_creation dbutils.updatedb(rrddatadir, containers) File "/usr/local/nav/lib/python/nav/mcc/utils.py", line 49, in wrapper result = f(*args, **kwds) File "/usr/local/lib/python2.7/site-packages/django/db/transaction.py", line 217, in inner res = func(*args, **kwargs) File "/usr/local/nav/lib/python/nav/mcc/dbutils.py", line 62, in updatedb category=category) File "/usr/local/lib/python2.7/site-packages/django/db/models/manager.py", line 132, in get return self.get_query_set().get(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py", line 351, in get % (self.model._meta.object_name, num, kwargs)) nav.models.rrd.MultipleObjectsReturned: get() returned more than one RrdFile -- it returned 2! Lookup parameters were {'category': 'port-counters', 'key': 'interface', 'value': '2001418'}
I guess there is some inconsistency in database, but where and after what shall I look?
--Ingeborg
ingeborg.hellemo@uit.no said:
% (self.model._meta.object_name, num, kwargs)) nav.models.rrd.MultipleObje
ctsReturned: get() returned more than one RrdFile -- it returned 2! Lookup parameters were {'category': 'port-counters', 'key': 'interface', 'value': '2001418'}
I guess there is some inconsistency in database, but where and after what shall I look?
Sorry about the noice. When I read the error message one more time the answer was almost there:
nav=> select * from rrd_file where value='2001418';
Then, of course, one can wonder why a port is detected as both a switch-port and a router-interface.
--Ingeborg
On Tue, 25 Jun 2013 10:55:25 +0200 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
ingeborg.hellemo@uit.no said:
% (self.model._meta.object_name, num, kwargs)) nav.models.rrd.MultipleObje
ctsReturned: get() returned more than one RrdFile -- it returned 2! Lookup parameters were {'category': 'port-counters', 'key': 'interface', 'value': '2001418'}
I guess there is some inconsistency in database, but where and after what shall I look?
Sorry about the noice. When I read the error message one more time the answer was almost there:
It's not noise, not every NAV user has your hacking skills :)
nav=> select * from rrd_file where value='2001418';
You nailed it!
Then, of course, one can wonder why a port is detected as both a switch-port and a router-interface.
Easily: A device reports an IP address on one of its switch ports. We hadn't thought of this when testing migrations, though (we had no such instances in our test data) :(
The solution is to kill the duplicates - it doesn't matter which one, since the Cricket would have been configured to collect statistics for each instance in the rrd_file database table.
We can whip up an SQL statement to fix the problem for user's who are SQL-challenged, but I should probably confer with John-Magne first.
morten.brekkevold@uninett.no said:
We can whip up an SQL statement to fix the problem for user's who are SQL-challenged, but I should probably confer with John-Magne first.
It would be useful with a script that identifies all duplicates. I didn't bother and decided to remove them one by one. It turned out that we had several, and everytime I thought I found the last duplicate, mcc.py found another one.
(I could probably have taught myself a new scripting language in all the time I ended up spending on this cr*p)
--Ingeborg
On Tue, 25 Jun 2013 14:41:04 +0200 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
morten.brekkevold@uninett.no said:
We can whip up an SQL statement to fix the problem for user's who are SQL-challenged, but I should probably confer with John-Magne first.
It would be useful with a script that identifies all duplicates. I didn't bother and decided to remove them one by one. It turned out that we had several, and everytime I thought I found the last duplicate, mcc.py found another one.
Try this on for size:
DELETE FROM rrd_file WHERE rrd_fileid IN (SELECT r1.rrd_fileid FROM rrd_file r1 JOIN rrd_file r2 USING (key, value, category) WHERE key='interface' AND category='port-counters' AND r1.rrd_fileid>r2.rrd_fileid);
This will discard NAV's metadata on any but the first of each duplicate instance. It's for application after an upgrade to NAV >= 3.14.1592; then one would run `mcc.py` over again.
(I could probably have taught myself a new scripting language in all the time I ended up spending on this cr*p)
I recommend learning Brainf*ck then ;)