Bug #18866
closedsalt centos os name is wrong
Added by Ben de Luca almost 8 years ago. Updated almost 8 years ago.
Description
from hosts with the salt plugin running centos 7 the os is created with the wrong minor name IE 3 instead of 3.1611. Trying to re-install this os failed as there is no image to download.
Files
example.json | example.json | 5.41 KB | example json | Ben de Luca, 03/14/2017 10:39 AM |
Updated by Ben de Luca almost 8 years ago
in puppet the fact looks like
os::release::mino=3
os::release::major=7
os::release::full=7.3.1611
In salt the fact looks like.
osrelease_info::0=7
osrelease_info::1=3
osrelease_info::2=1611
Updated by Ben de Luca almost 8 years ago
I hacked on foreman_salt-8.0.0/app/services/foreman_salt/fact_parser.rb
to work around the issue, it works against all the centos os version I tested 5,6,7 but I have not tested against any other os.
def os_hash (_, major, minor, sub) = /(\d+)\.?(\d+)?\.?(\d+)?/.match(facts[:osrelease]).to_a if sub minor += "." + sub end
Updated by Anonymous almost 8 years ago
Could you attach the grains as JSON of such a system?
Updated by Ben de Luca almost 8 years ago
somehost.com:
----------
SSDs:
biosreleasedate:
10/05/2010
biosversion:
080016
cpu_flags:
- fpu
- vme
- de
- pse
- tsc
- msr
- pae
- mce
- cx8
- apic
- sep
- mtrr
- pge
- mca
- cmov
- pat
- pse36
- clflush
- dts
- acpi
- mmx
- fxsr
- sse
- sse2
- ss
- ht
- tm
- pbe
- syscall
- nx
- pdpe1gb
- rdtscp
- lm
- constant_tsc
- arch_perfmon
- pebs
- bts
- rep_good
- nopl
- xtopology
- nonstop_tsc
- aperfmperf
- pni
- dtes64
- monitor
- ds_cpl
- vmx
- smx
- est
- tm2
- ssse3
- cx16
- xtpr
- pdcm
- pcid
- dca
- sse4_1
- sse4_2
- popcnt
- lahf_lm
- ida
- arat
- epb
- dtherm
- tpr_shadow
- vnmi
- flexpriority
- ept
- vpid
cpu_model:
Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
cpuarch:
x86_64
domain:
.com
fqdn:
somehost.com
fqdn_ip4:
- 12.12.12.12
fqdn_ip6:
gpus:
|_
----------
model:
MGA G200eW WPCM450
vendor:
unknown
host:
somehost
hwaddr_interfaces:
----------
enp1s0:
00:00:00:00:00:00
enp2s0:
00:00:00:00:00:00
lo:
00:00:00:00:00:00
id:
somehost.com
ip4_interfaces:
----------
enp1s0:
enp2s0:
- 12.12.12.12
lo:
- 127.0.0.1
ip6_interfaces:
----------
enp1s0:
enp2s0:
- fe80::blah
lo:
- ::1
ip_interfaces:
----------
enp1s0:
enp2s0:
- 12.12.12.12
lo:
- 127.0.0.1
- ::1
ipv4:
- 12.12.12.12
- 127.0.0.1
ipv6:
- ::1
- fe80::blah
kernel:
Linux
kernelrelease:
3.10.0-123.8.1.el7.x86_64
locale_info:
----------
defaultencoding:
UTF-8
defaultlanguage:
en_GB
detectedencoding:
UTF-8
localhost:
somehost.com
lsb_distrib_id:
CentOS Linux
machine_id:
a2810c1414161231231231349d68fc29c3c62053788
manufacturer:
Supermicro
master:
salt
mdadm:
mem_total:
23940
nodename:
somehost.com
num_cpus:
16
num_gpus:
1
os:
CentOS
os_family:
RedHat
osarch:
x86_64
oscodename:
Core
osfinger:
CentOS Linux-7
osfullname:
CentOS Linux
osmajorrelease:
7
osrelease:
7.0.1406
osrelease_info:
- 7
- 0
- 1406
path:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
productname:
xxxxxx
ps:
ps -efH
pythonexecutable:
/usr/bin/python
pythonpath:
- /usr/bin
- /usr/lib64/python27.zip
- /usr/lib64/python2.7
- /usr/lib64/python2.7/plat-linux2
- /usr/lib64/python2.7/lib-tk
- /usr/lib64/python2.7/lib-old
- /usr/lib64/python2.7/lib-dynload
- /usr/lib64/python2.7/site-packages
- /usr/lib64/python2.7/site-packages/gtk-2.0
- /usr/lib/python2.7/site-packages
pythonversion:
- 2
- 7
- 5
- final
- 0
saltpath:
/usr/lib/python2.7/site-packages/salt
saltversion:
2015.5.0
saltversioninfo:
- 2015
- 5
- 0
- 0
selinux:
----------
enabled:
False
enforced:
Disabled
serialnumber:
1234567890
server_id:
173046215
shell:
/bin/sh
systemd:
----------
features:
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
version:
208
virtual:
physical
zmqversion:
3.2.5
Updated by Anonymous almost 8 years ago
The current behaviour is unclear to me. There's an "osrelease" grain in the JSON and if using the current code I'm getting:
irb(main):001:0> osrelease = "7.3.3212" => "7.3.3212" irb(main):002:0> (_, major, minor) = /(\d+)\.?(\d+)?\.?(\d+)?/.match(osrelease).to_a => ["7.3.3212", "7", "3", "3212"] irb(main):003:0> major => "7" irb(main):004:0> minor => "3"
Which seems perfectly fine.
Updated by Anonymous almost 8 years ago
hang on, found the special CentOS handling... :(
Updated by The Foreman Bot almost 8 years ago
- Status changed from New to Ready For Testing
- Assignee set to Anonymous
- Pull request https://github.com/theforeman/foreman_salt/pull/69 added
Updated by Anonymous almost 8 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset foreman_salt|857e38a55ba5af8204ff0dae780dde89c6e2eefb.