Created attachment 1654925 [details] screenshot showing warning Description of problem: I had hosts with only 1 CPU but upon seeing "#CPU's too low (min 2 needed)" I added another CPU to a host but it still shows the same warning. Note one time when the host had another issue (no free disks for OSD role) the CPU warning *did* go away as expected. So it seems there is some bad logic in these tests. [root@jb-ceph4-osd1 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel Core Processor (Skylake, IBRS) stepping : 3 microcode : 0x1 cpu MHz : 2712.000 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit bogomips : 5424.00 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel Core Processor (Skylake, IBRS) stepping : 3 microcode : 0x1 cpu MHz : 2712.000 cache size : 16384 KB physical id : 1 siblings : 1 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit bogomips : 5424.00 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: [root@jb-ceph4-osd1 ~]# Version-Release number of selected component (if applicable): cockpit-ceph-installer-1.0-0.el8cp.noarch How reproducible: Not 100%. Like I said, one time when there was an error on no free disks for an OSD node, the CPU warning did go away as expected. However when I resolved the no free disks error the CPU warning shows now. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please specify the severity of this bug. Severity is defined here: https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity.
the min 2 needed refers to the number of cores required for all roles and the host os. The check_role script assumes a 2 core requirement for the OS, and the ceph roles pile on top of that. In this case I think we're falling foul of rounding - it should probably say a min of 3 (the code is using int against 2.5!) Does that make sense? If so, I can update the check to round up against the cpu check value.
Yes that makes sense, but I agree, if that means the effective minimum is 3, it should say 3.
fix available in 1.1 release
Created attachment 1699459 [details] Screenshot of UI Hi Paul, When I tried with "Cluster type" as "Production" I could see the error message "You must have 3 or 5 MONs defined for a Production deployment" on "Hosts" page of UI But when I tried with "Cluster type" as "Development/POC" the error was not seen on "Hosts" page and it proceeded to the "Validate" page on UI (as seen in the screenshot).
This bug was raised based on the incorrect rounding/calculation of the cpu requirement - it has nothing to do with the comment in #9! please refer to comments 1 and 2 for any verification tests. The comment in #9 is not an issue, that's what supposed to happen. Under production deployment rules we enforce the mon count to get supported configurations, but under dev/POC - you can try and force an unsupported configuration through...this is by design. It's how the installer supports an all-in-one config too
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat Ceph Storage 4.1 Bug Fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4144