Nodes listing page has incorrect Disk size displayed

Could we see the lshw output for the node which has the correct size as well? I have an idea..

attached.

also, I just deleted the node and re-added it (commissioned, etc...) same thing - '1' for disk size.

The good node has the following disk size information:

         <size units="bytes">120034123776</size>
         ...
         <size units="bytes">120033075200</size>
         <capacity>120033075200</capacity>

The bad has only:

       <size units="bytes">120034123776</size>

The important factor is that the good nodes second <size> tag was nested in:

        <node id="volume" claimed="true" class="volume" handle="">

whereas the bad node did not have this <node> tag.

The XPath expression that MAAS uses to calculate the total storage is:

    sum(//node[@class='volume']/size[@units='bytes'])
    div 1024 div 1024

I think an expression of:

    sum(//node[@class='disk']/size[@units='bytes'])
    div 1024 div 1024

would have worked for both of these nodes. However, I don't what a change like that might break.

Running this expression through the unit tests fails a couple of tests:

  metadataserver.models.tests.test_noderesults.TestUpdateHardwareDetails.test_hardware_updates_storage
  metadataserver.models.tests.test_noderesults.TestUpdateHardwareDetails.test_hardware_updates_storage_1279728

I suspect that lshw's output has evolved. I'll try to come up with an expression that can work with old and new forms.

A fix is up for review. There are unit tests that cover older lshw formats as well as these new ones but that's not really what I'm worried about.

We always use the same release for commissioning (in trunk and 1.7 that means 14.04) so I'd expect to see a consistent lshw XML structure for all nodes. The format has certainly evolved from previous releases, but it ought to be consistent within a single release.

However, what I don't know is how the XML varies for different hardware, and if this new XPath expression is going to DTRT in all cases.

It would be useful to collect lshw dumps for lots of different hardware, recorded along with the Ubuntu release and lshw version it was obtained from. We could then check our code against these as part of the landing process.

The odd thing here is that the NUCs should be identical. I can check the firmware tomorrow but the hardware is the same.

Hello Daniel, or anyone else affected,

Accepted maas into utopic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/maas/1.7.5+bzr3369-0ubuntu1~14.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This issue has been verified to work both on upgrade and fresh install, and has been QA'd. Marking verification-done.