Hardcoded proc0 processor name in resolvers/aix/architecture_resolver.rb and related files

There is a hardcoded "proc0" reference to a processor name in AIX in the following files:

lib/facter/resolvers/aix/architecture_resolver.rb
spec/facter/resolvers/aix/architecture_resolver_spec.rb
spec/facter/resolvers/aix/processors_spec.rb
spec/fixtures/processors_cuat
spec/fixtures/processors_cudv

If a processor with this name is not present on the system, executing facter produces the following errors (on facter 2.5.1 that we actually use in our environment):

lsattr: 0514-519 The following device was not found in the customized
{{ device configuration database:}}
{{ proc0}}

I understand that facter 4 does not use lsattr command anymore, but queries the ODM instead. Nevertheless the hardcoded "proc0" in the code suggests that the issue is present in newest version as well.

 

The issue

If VCPU assignment for an AIX LPAR is reduced, it can happen that proc0 is deleted or unconfigured (set to the Defined state). This would lead to the following outcomes:

• proc0 deleted:  unable to determine system architecture because the expected device "proc0" is not there
• proc0 Defined: might detect architecture incorrectly. This can happen for example if proc0 was unconfigured (set to Defined) on one architecture machine (e.g. POWER8), and then moved to different one (e.g. POWER9). The details of the Defined processor resource will still show POWER8, which is incorrect.

Example:
[root@sibwi110:/home/root(36)]# lsdev | grep proc | head -2
{{ proc0 Available 00-00 Processor}}
{{ proc2 Defined 00-02 Processor}}
{{ [root@sibwi110:/home/root(37)]# lsattr -El proc0 }}
{{ frequency 4190000000 Processor Speed False}}
{{ smt_enabled true Processor SMT enabled False}}
{{ smt_threads 8 Processor SMT threads False}}
{{ state enable Processor state False}}
{{ type PowerPC_POWER8 Processor type False}}
{{ [root@sibwi110:/home/root(38)]# }}

Proposed solution

In order to mitigate this, I suggest to replace the hardcoded "proc0" by a dynamic value, which can be queried in the ODM. All active processors (in Available state) will report the same correct architecture, therefore it's enough to query just one of them.

The active (i.e. Available) processors can be identified by "status = 1" value in CuDv ODM object class. A command line example to do this could be:

odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1

For example:

[root@sibwi110:/home/root(31)]# odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1
{{ name = "proc0"}}

 

Another example on a server where "proc0" does not exist:

{{[root@aix-lpar:/home/root(3)]# lsdev | grep proc }}
proc4 Defined 00-04 Processor
proc8 Available 00-08 Processor
[root@aix-lpar:/home/root(4)]# odmget -q "PdDvLn = processor/sys/proc_rspc and status = 1" CuDv | grep name | head -1
{{ name = "proc8"}}

 

For reference, here are the full stanzas on the latter LPAR:

[root@aix-lpar:/home/root(5)]# odmget -q "PdDvLn = processor/sys/proc_rspc" CuDv

CuDv:
    name = "proc4"
    }}{{status = 0
    }}{{chgstatus = 3
    }}{{ddins = ""
    }}{{location = "00-04"
    }}{{parent = "sysplanar0"
    }}{{connwhere = "P4"
    }}{{PdDvLn = "processor/sys/proc_rspc"

 

CuDv:
    }}{{name = "proc8"
    }}{{status = 1
    }}{{chgstatus = 2
    }}{{ddins = ""
    }}{{location = "00-08"
    }}{{parent = "sysplanar0"
    }}{{connwhere = "P8"
    }}{{ PdDvLn = "processor/sys/proc_rspc"