Added fact for reporting PSP version #1
Conversation
ghost
assigned 
|
Nice! What happens when the PSP fact does not match up with the "releases" we see in the SDR? $ ls ./PSP/{rhel,oracle,centos}/?/{i386,x86_64}/8.7*/hp-snmp-agents*
./PSP/centos/5/i386/8.70/hp-snmp-agents-8.7.0.23-17.rhel5.i386.rpm
./PSP/centos/5/i386/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.i386.rpm
./PSP/centos/5/x86_64/8.70/hp-snmp-agents-8.7.0.23-17.rhel5.x86_64.rpm
./PSP/centos/5/x86_64/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.x86_64.rpm
./PSP/centos/6/i386/8.72/hp-snmp-agents-8.7.0.23-16.rhel6.i386.rpm
./PSP/centos/6/x86_64/8.72/hp-snmp-agents-8.7.0.23-17.rhel6.x86_64.rpm
./PSP/oracle/5/i386/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.i386.rpm
./PSP/oracle/5/x86_64/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.x86_64.rpm
./PSP/oracle/6/i386/8.72/hp-snmp-agents-8.7.0.23-16.rhel6.i386.rpm
./PSP/oracle/6/x86_64/8.72/hp-snmp-agents-8.7.0.23-17.rhel6.x86_64.rpm
./PSP/rhel/5/i386/8.70/hp-snmp-agents-8.7.0.23-17.rhel5.i386.rpm
./PSP/rhel/5/i386/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.i386.rpm
./PSP/rhel/5/x86_64/8.70/hp-snmp-agents-8.7.0.23-17.rhel5.x86_64.rpm
./PSP/rhel/5/x86_64/8.73/hp-snmp-agents-8.7.0.23-17.rhel5.x86_64.rpm
./PSP/rhel/6/i386/8.70/hp-snmp-agents-8.7.0.23-16.rhel6.i386.rpm
./PSP/rhel/6/i386/8.72/hp-snmp-agents-8.7.0.23-16.rhel6.i386.rpm
./PSP/rhel/6/x86_64/8.70/hp-snmp-agents-8.7.0.23-17.rhel6.x86_64.rpm
./PSP/rhel/6/x86_64/8.72/hp-snmp-agents-8.7.0.23-17.rhel6.x86_64.rpm |
|
Shit, We don't have a ton of 8.7 deployed but ya, you caught me .. After taking a [root@xxx:psp]# pwd The "patched" package is the same package you get w/the HP website except It seems you have the same issue that I do, finding out what version of the You have any suggestions? On Sun, Sep 2, 2012 at 8:28 PM, Mike Arnold [email protected]:
I've seen things you people wouldn't believe. Attack ships on fire off |
|
Ah yes. I've done the modified XML/tarball thing before. :) I'm thinking that the concept of a PSP bundle might be more geared toward the old "deploy from taball" method. In that case I would either use your RPM version = PSP version method or possibly even drop a file in /etc/facts.d (see the puppetlabs/stdlib module) during tarball install to match the PSP tarball version. In the case of this psp module, where we control which yumrepo URL we point at (http://.../packages/ and not any particular version) and also whether or not to upgrade (autoupgrade => true), I am wondering if the PSP "version" even matters? |
|
We've always done it that way, I just noticed HP started putting up YUM To be honest we really only install the PSP for monitoring purposes, failed Did they fold the facts.d module into the standard Puppet libs? I've seen On Mon, Sep 3, 2012 at 1:43 PM, Mike Arnold [email protected]:
I've seen things you people wouldn't believe. Attack ships on fire off |
|
Yes, facts.d support is now in puppetlabs-stdlib. Stdlib has a bunch of useful functions for manifest writers and also a few new facts. |
|
Finally went through the lists this morning and tracked that down. :-/ On Wed, Sep 5, 2012 at 10:18 AM, Mike Arnold [email protected]:
I've seen things you people wouldn't believe. Attack ships on fire off |
Not sure if ya need this or not, but I needed it in my environment at the request of some other engineers. Pushed it out and it reported on the 280 nodes we have deployed on HP hardware. Just ran this query after directly on the Puppet DB:
select hosts.name, fact_values.value
from hosts, fact_values
where fact_values.fact_name_id = (select id from fact_names where name = 'psp_version')
and hosts.id = fact_values.host_id
order by name
I've only tested on 7.x, 8.x, and 9.x. For 8.x and 9.x it should report the actual PSP version based on the hp-snmp-agents rpm, but for 7.x it can only get the x.x version instead of the x.x.x version based off the hpasm rpm.