[BUG] Issue with batch processing host list from the container about badfish HOT 5 CLOSED

The IDRAC is becoming unresponsive when containerized badfish is performing bulk actions, due to which I think it fails saying that "failed to communicate with host"

from badfish.

Hey @sanjaychari in your command example I don't see you mapping your --host-list target file anywhere, is that being mapped? e.g. -v /tmp/my-hosts:/tmp/my-hosts:z so you can refer to it with --host-list /tmp/myhosts for example.

On iDRAC instability, they are just fragile. It's recommended to reboot them via --racreset before doing bulk operations on them to alleviate problems, they aren't designed to take a lot of heavy API calls unfortunately and there's not a lot we can do about that.

from badfish.

Hi @sadsfae,

The hosts file dell-hosts is at /home/sanjay/jetpack/badfish on the host. I am mounting the entire directory onto the badfish container with -v /home/sanjay/jetpack/badfish:/dell and then passing the hosts list using --host-list /dell/dell-hosts.

We already perform a racreset on all systems in Jetpack before setting the boot order(https://github.com/redhat-performance/jetpack/blob/b48d6bbe632a4f774605467c449ca2f68928f7cf/set_boot_order.yml#L11-L26).

from badfish.

@sanjaychari ah ok, maybe you can show us or we can look at the hosts internally? What part of your playbook is returning the unavailable return status? cc: @grafuls

Is the behavior sporadic in that sometimes it works and sometimes it doesn't?

Have you tried also forcefully clearing the iDRAC job queue via --clear-jobs --force ? Give this a try too and then reboot any ones that don't return like you want.

If the behavior is sporadic it's probably not a badfish issue otherwise it wouldn't work at all but maybe we can isolate and remedy the behavior on the idrac side.

from badfish.

Closing this due to inactivity, we haven't received any other similar reports and there's been loads of container runs since then.

from badfish.