Open shashank-6777 opened 9 months ago
At the moment crucible isn't compatible with RHEL9 yet. We are currently in the planning stages of this work.
At the moment crucible isn't compatible with RHEL9 yet. We are currently in the planning stages of this work.
@arjuhe thanks for the information, In the README file it says RHEL9.1 based bastion node i thought crucible supports RHEL9. Anyway thanks for your support
As this is happening on the nodes I don't think this is a issue with the bastion. Have you tried this against inventory with a RHEL 8 bastion?
Perhaps its an issue with the rootfs version. What are the versions you have used for your 4.13 os_image
and release_image
.
Hi Thanks for your reponse,
No @nocturnalastro i did'nt try this with RHEL 8 based bastion. Actually i wanted to tested this framwork with RHEL 9.x based bastion. I have tried with different combination i mean with 4.13.0 & 4.13.10 both
HI @nocturnalastro ,
I have tried with multiple combination but this framwork have some issue with 4.13.10. Because we are using this framwork from last more than a year with 4.8.x to 4.11.x but we never face such issue.
I have performed below combination. combination 1: VMhost :- 9.1 bastion :- 9.1 OCP : 4.13.10 Arch:- x86_64 rhcos images:- live :- rhcos-4.13.10-x86_64-live.x86_64.iso, rhcos-4.13.5-x86_64-live.x86_64.iso, rhcos-4.13.0-x86_64-live.x86_64.iso rootfs:- rhcos-4.13.10-x86_64-live-rootfs.x86_64.img, rhcos-4.13.5-x86_64-live-rootfs.x86_64.img, rhcos-4.13.0-x86_64-live-rootfs.x86_64.img
combination 2: VMhost :- 8.6 bastion :- 9.1 OCP : 4.13.10 Arch:- x86_64 rhcos images:- live :- rhcos-4.13.10-x86_64-live.x86_64.iso, rhcos-4.13.5-x86_64-live.x86_64.iso, rhcos-4.13.0-x86_64-live.x86_64.iso rootfs:- rhcos-4.13.10-x86_64-live-rootfs.x86_64.img, rhcos-4.13.5-x86_64-live-rootfs.x86_64.img, rhcos-4.13.0-x86_64-live-rootfs.x86_64.img
combination 3: VMhost :- 8.6 bastion :- 8.6 OCP : 4.13.10 Arch:- x86_64 rhcos images:- live :- rhcos-4.13.10-x86_64-live.x86_64.iso, rhcos-4.13.5-x86_64-live.x86_64.iso, rhcos-4.13.0-x86_64-live.x86_64.iso rootfs:- rhcos-4.13.10-x86_64-live-rootfs.x86_64.img, rhcos-4.13.5-x86_64-live-rootfs.x86_64.img, rhcos-4.13.0-x86_64-live-rootfs.x86_64.img
Every time i got the similar issue. Requesting you to please check once if you have time. Attaching error snippit for your reference.
However my chrony server working fine also my vm_host have 3.2T disk space for vm's.
Hi @nocturnalastro
Good morning, Today when i tried to reinstall i checked my hosts details on assisted installer and i found that assisted installer displayed that my disk (ODD) is small however my installation disk is VDA(HDD)with 250G of size.
Its fine as sr0 is not the installation disk. That is probably a virtual CD or something like that
@nocturnalastro thanks for your response, Do you have any idea that why it is failing then ?? Thanks in advance
@shashank-6777 Try bumping the ai_version
to a new version looks like the latest is v2.26.0
@nocturnalastro thanks for the suggestion. I tried the same and now i can see installation triggered sucessfully.
So it means with 4.13.x this ai_version are supported ? Also if i tried with Bastion node based on RHEL9 will it work also ?
Thanks in advance
So it means with 4.13.x this ai_version are supported ?
Looks like there was a bug which has been fixed in the newer versions of assisted isntaller.
Also if i tried with Bastion node based on RHEL9 will it work also ?
If you got to the point of booting then it would probably.
We've had issues with missing packages in RHEL9 which meant we couldn't get to booting.
@nocturnalastro I got your point. Thanks for your support.
@shashank-6777 were you using VirtIO based disks on your Bastion? I have seen terrible write induced latencies at times not using disks backed by VirtIO. This also includes older firmware on the SAS/SCSI based controllers that may be used.
In general, we recommend SAS or NVMe class drives on the VM host for this. Mechanical spinners (HDD) offer much lower IOPS both read and write, and are oftentimes insufficient for low latency requirements for etcd (control plane supervisor nodes) in OpenShift. I personally use SAS based SSD drives by default, otherwise NVMe class block devices.
@novacain1 thanks for your response.
were you using VirtIO based disks on your Bastion? I have seen terrible write induced latencies at times not using disks backed by VirtIO. This also includes older firmware on the SAS/SCSI based controllers that may be used.
Yes I am using VirtIO based disks Physical disks are SAS based HDD.
In general, we recommend SAS or NVMe class drives on the VM host for this. Mechanical spinners (HDD) offer much lower IOPS both read and write, and are oftentimes insufficient for low latency requirements for etcd (control plane supervisor nodes) in OpenShift. I personally use SAS based SSD drives by default, otherwise NVMe class block devices.
I understand and totally agree with you, but its just a internal test setup.
@nocturnalastro, yes installation failed/stuck after "installation step successfull" with RHEL 9.1 based bastion.
Just wanted to check if you guys have any planned date to release this framwork with 9.x support.
@shashank-6777 We're currently working on it shouldn't be to much longer.
@nocturnalastro thanks for the update. Please let me know when can i test the same in my lab.
@shashank-6777 PR #293 has the changes that got crucible working for us on RHEL 9, note there is some changes in the README as some packages have changed location in the RHEL9 repos.
@nocturnalastro i hope you are doing good.
is 9.1 officially supported by crucible now or still have to wait ?
@shashank-6777 I have gotten success with the PR mentioned and using a KVM host based on RHEL 9.3 recently. My use case was that server was also the place I launched the playbooks from.
@novacain1 thanks for the update and your support as always. Let me try it in my lab. I will try to host my Master's on different machine.
@novacain1 i tried to install cluster with RHEL 9.2. but getting below error, however expected packages are already installed on the bastion node.
[root@sh-lab-sc5f-bastion-4 crucible]# rpm -qa |grep ansible ansible-core-2.14.2-5.el9_2.x86_64 [root@sh-lab-sc5f-bastion-4 crucible]# [root@sh-lab-sc5f-bastion-4 crucible]# cat /etc/redhat-release Red Hat Enterprise Linux release 9.2 (Plow) [root@sh-lab-sc5f-bastion-4 crucible]# [root@sh-lab-sc5f-bastion-4 crucible]# uname -r 5.14.0-284.48.1.el9_2.x86_64 [root@sh-lab-sc5f-bastion-4 crucible]# uname -a Linux sh-lab-sc5f-bastion-4.14-nec.nfvi.localdomain 5.14.0-284.48.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jan 4 03:49:47 EST 2024 x86_64 x86_64 x86_64 GNU/Linux [root@sh-lab-sc5f-bastion-4 crucible]# [root@sh-lab-sc5f-bastion-4 crucible]# ll /usr/bin/python python python3 python3.11 python3.9
ERROR:-
TASK [validate_inventory : Assert required vars are correctly typed] *****************************************************************************************************************************************
fatal: [localhost -> {{ validation_host | default('bastion') }}]: FAILED! =>
msg: 'The conditional check ''(hostvars[item][''mac''] | ansible.utils.hwaddr(''bool'')) == true'' failed. The error was: Failed to import the required Python library (netaddr) on sh-lab-sc5f-bastion-4.14-nec.nfvi.localdomain''s Python /usr/bin/python3.11. Please read the module documentation and install it in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter'
PLAY RECAP ***************************************************************************************************************************************************************************************************
localhost : ok=8 changed=0 unreachable=0 failed=1 skipped=4 rescued=0 ignored=0
It can be confusing with multiple python versions around. It is likely using python3.9
. Try python3.9 -c "import netaddr"
if that gives you an import try using pip if it that doesn't clean it up try the same with python3.11
. Its likely that the rpm package for netaddr and the version that ansible is using have a mismatch.
Bug description
Hi Team,
I am trying to install OCP 4.13.10 with 9.1 by using latest crucible framwork but my installation failed everytime, I found below two error on OCP failed nodes.
Can you please let me know how can i solve these issues. ?
OpenShift version
other (provide in the description)
Assisted Installer version
v2.12.1
Relevant log output
Inventory file
Required statements