That was a fun bug to track down, as it wasn't actually a bug at all but rather an issue with dirty data.
A number of systems had a empty display name (in the database), although this wasn't exposed through the certification interface (which is as it should be).
However for performance we use additional tables which are populated by SQL, which did expose the empty display name. As it grouped systems, they were getting grouped under the empty name (in addition to their correct name), and when we tried to access the machine via it's canonical ID, the system actually served up the grouped record (with the amalgamated hardware).
What I've done is to remove the empty display_name from all affected systems (77 in total), and re-populated the display tables, and things are now displaying as they should.
I'll close this bug accordingly, but raise additional bugs for the issues that caused this situation.
That was a fun bug to track down, as it wasn't actually a bug at all but rather an issue with dirty data.
A number of systems had a empty display name (in the database), although this wasn't exposed through the certification interface (which is as it should be).
However for performance we use additional tables which are populated by SQL, which did expose the empty display name. As it grouped systems, they were getting grouped under the empty name (in addition to their correct name), and when we tried to access the machine via it's canonical ID, the system actually served up the grouped record (with the amalgamated hardware).
What I've done is to remove the empty display_name from all affected systems (77 in total), and re-populated the display tables, and things are now displaying as they should.
I'll close this bug accordingly, but raise additional bugs for the issues that caused this situation.