Comment 10 for bug 1590144

I tested with the latest lshw and I still have this issue.

I looked at the code and added some debugging. Here's what's happening.

lshw is is showing 1.0 as the core count - it doesn't accurately represent the core count, obviously, and the code is setup so that the higher core count takes precedence, so when the node was first commissioned, the cpuinfo value is used and the core count is set to 20.

The next time I commissioned the node, with HT turned off, the same code paths are hit - lshw says 1.0 and cpuinfo says 10 now. The same code paths are hit, but the code is setup to take the highest value, including the preexisting value of 20, and so the core count isn't being updated.

Here's the code with the issue (from parse_cpuinfo) (with my log message in it):
    logger.error("current cpu count: %s\tnew cpu count: %s" % (node.cpu_count, cpu_count))
    if node.cpu_count is None or cpu_count > node.cpu_count:
        node.cpu_count = cpu_count
        node.save()

Example log message:
2016-06-09 15:15:32 [metadataserver.models.commissioningscript] ERROR: current cpu count: 20 new cpu count: 10

It's interesting that if I enabled HT on the nodes that never had them, cpuinfo would reflect that and the cpu core count would properly go up in MAAS. They would just be stuck there - if I turned HT off again the core count wouldn't go back down.

So, if the approach of using the highest value out of lshw or cpuinfo is used, the code has to be changed to not also consider the preexisting cpu_count value for Node, which may be based on an old hardware configuration.

But I'm also curious why lshw and cpuinfo are used, instead of lscpu, which seems to do a superior job here.