Closed passw0rd123 closed 6 years ago
@passw0rd123 Could you post the output from the ansible -m setup for 2.3 and 2.4?
@passw0rd123 also, the output of:
python -c 'import platform; print(platform.system())'
$ python -c 'import platform; print(platform.system())'
SunOS
It seems that older Solaris patchlevels are not affected.
The Solaris evaluation vm from oracle.com has a patchlevel from mid 2015 and can not be upgraded...
0.175.3.1.0.3.0
While 2017 patchlevel lacks some facts if you use Ansible 2.4.0.0
0.175.3.22.0.3.0
I'll try to post some setup outputs if I find the time to sanitize them...
- ansible_devices
- ansible_memtotal_mb
- ansible_mounts
- ansible_processor
- ansible_processor_cores
- ansible_processor_count
- ansible_swap_allocated_mb
- ansible_swap_reserved_mb
- ansible_swapfree_mb
- ansible_swaptotal_mb
- ansible_uptime_seconds
Those are all from lib/ansible/module_utils/facts/hardware/sunos.py, so if something is causing that module to either fail or get skipped that could cause that.
There isnt a good way to narrow it down to which part, so may need to test a view things.
If possible, could you include output from some of the commands hardware.py runs to collect sunos facts?
That includes:
# memory
/usr/sbin/prtconf
/usr/sbin/swap -s
# dmi
prtdiag
# devices
/usr/bin/kstat -p
# uptime
/usr/bin/kstat -p unix:0:system_misc:snaptime
# cpu info
/usr/bin/kstat cpu_info
# mounts needs the contents of /etc/mtab
On Mon, Oct 16, 2017 at 8:19 AM, passw0rd123 notifications@github.com wrote:
It seems that older Solaris patchlevels are not affected.
The Solaris evaluation vm from oracle.com has a patchlevel from mid 2015 and can not be upgraded...
0.175.3.1.0.3.0
While 2017 patchlevel lacks some facts if you use Ansible 2.4.0.0
0.175.3.22.0.3.0
I'll try to post some setup outputs if I find the time to sanitize them...
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ansible/ansible/issues/31049#issuecomment-336869501, or mute the thread https://github.com/notifications/unsubscribe-auth/AAA7OmlMrLyvRndnK47y-XHyn6LWgHUHks5ss0nFgaJpZM4PnZ-q .
If possible, could you include output from some of the commands hardware.py runs to collect sunos facts?
Sure
/usr/sbin/prtconf
System Configuration: Oracle Corporation i86pc
Memory size: 524279 Megabytes
System Peripherals (Software Nodes):
prtconf: devinfo facility not available
/usr/sbin/swap -s
total: 1734796k bytes allocated + 0k reserved = 1734796k used, 65374068k available
prtdiag
prtdiag can only be run in the global zone
/usr/bin/kstat -p
/usr/bin/kstat -p | grep sderr:0:sd0
sderr:0:sd0,err:class device_error
sderr:0:sd0,err:crtime 3061998,31354509
sderr:0:sd0,err:Device Not Ready 0
sderr:0:sd0,err:Hard Errors 0
sderr:0:sd0,err:Illegal Request 0
sderr:0:sd0,err:Media Error 0
sderr:0:sd0,err:No Device 0
sderr:0:sd0,err:Non-Aligned Writes 0
sderr:0:sd0,err:Predictive Failure Analysis 0
sderr:0:sd0,err:Product SAMSUNG 0000000000
sderr:0:sd0,err:Recoverable 0
sderr:0:sd0,err:Revision 003Q
sderr:0:sd0,err:Serial No 00000000000000
sderr:0:sd0,err:Size 960197124096
sderr:0:sd0,err:snaptime 8831505,71770339
sderr:0:sd0,err:Soft Errors 0
sderr:0:sd0,err:Transport Errors 0
sderr:0:sd0,err:Vendor ATA
/usr/bin/kstat -p unix:0:system_misc:snaptime
unix:0:system_misc:snaptime 8829613,08456415
/usr/bin/kstat cpu_info
module: cpu_info instance: 0
name: cpu_info0 class: misc
brand Intel(r) Xeon(r) CPU X7560 @ 2.27GHz
cache_id 0
chip_id 0
clock_MHz 1067
clog_id 0
core_id 0
cpu_type i386
crtime 3061999,48840801
cstates_count 1175292894:53639373:942177828
cstates_nsec 5487277795197740:106145173266995:6375238769968485
current_clock_Hz 1067000000
current_cstate 3
current_pstate 10
family 6
fpu_type i387 compatible
implementation x86 (chipid 0x0 GenuineIntel 206E6 family 6 model 46 step 6 clock 2267 MHz)
max_ncpu_per_chip 32
max_ncpu_per_core 2
max_pwrcap 0
model 46
ncore_per_chip 8
ncpu_per_chip 16
pg_id 4
pkg_core_id 0
pstates_count 12685179:0:0:0:0:0:0:0:0:0:12685179
pstates_nsec 5662742871431624:0:0:0:0:0:0:0:0:0:3166905738835199
snaptime 8829648,60739034
socket_type Unknown
state on-line
state_begin 1502477963
stepping 6
supported_frequencies_Hz 1067000000:1200000000:1333000000:1467000000:1600000000:1733000000:1867000000:2000000000:2133000000:2267000000:2268000000
supported_max_cstates 2
supported_max_pstates 10
vendor_id GenuineIntel
module: cpu_info instance: 1
... (next cpu same as above)
Needs the contents of /etc/mtab
The correct file is /etc/mnttab
(but the module references the right file I think)
Is Tab separated and schould work with https://github.com/ansible/ansible/blob/d14467b0294296b9a2b85e0ad150315c2d5a2491/lib/ansible/module_utils/facts/hardware/sunos.py#L156
rpool/ROOT/solaris-24 / zfs rw,nodevices,setuid,nonbmand,exec,rstchown,xattr,noatime,mountpoint=/zones/zonename/root/,zone=zonename,nozonemod,sharezone=14,dev=44900c7 1504299109
rpool/ROOT/solaris-24/var /var zfs rw,nodevices,setuid,nonbmand,exec,rstchown,xattr,noatime,mountpoint=/zones/zonename/root/var,zone=zonename,nozonemod,sharezone=14,dev=44900c8 1504299109
/dev /dev dev zone=zonename,nozonemod,sharezone=14,dev=8b4000e 1504299109
proc /proc proc nodevices,zone=zonename,sharezone=14,dev=8b8000e 1504299111
ctfs /system/contract ctfs nodevices,zone=zonename,sharezone=14,dev=8c0000f 1504299111
mnttab /etc/mnttab mntfs nodevices,zone=zonename,sharezone=14,dev=8c4000f 1504299111
...
This bug also affects triton/smartos.
Affects Solaris 10 as well.
If I follow the instructions for the remote debugging of an ansible module, the execution of the setup module on the remote host raises the following error:
KeyError('devices',)
I guess this comes from line 240 in module_utils/facts/hardware/sunos.py
.
I hope this helps narrowing down the problem.
Hitting this too. Showstopper. Going back to ansible 2.3.2 for now :-(. Running SmartOS.
@bcoca @alikins this should be included in the next release as jcea's PR fixes the problem.
ISSUE TYPE
COMPONENT NAME
setup / gather_facts
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
SUMMARY
Since Ansible 2.4.0.0 the setup module drops many facts on Solaris 11.3 (x86) systems which were available in Ansible 2.3. CentOS 7.4 seems not to be affected by this issue.
In a quick diff the following facts are missing:
In my case it was
ansible_mounts
which broke my plays...STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS