ilo2_ribcl needs to have access to signal_service_thread

[mohandev2]

ilo2_ribcl plugin uses signal_service_thread variable which is in daemon code. This code is not a library and it is not linked against ilo2_ribcl plugin library. This is not a big problem as ilo2_ribcl is a plugin. But ideally the library containing the variable needs to be linked against the ilo2_ribcl. However openhpid is the daemon application. Please take a look at how to handle it.

Reported by: mohandev2

Original Ticket: openhpi/bugs/1909

[mohandev2]

• assigned_to: Praveen

Original comment by: mohandev2

[mohandev2]

dh_shlibdeps -a -- -- warnings=1
is run at the debian packaging stage. It returns the following warning message as the libilo2_ribcl.so.* contains signal_service_thread which is not resolvable within the library.

pkg-shlibdeps: warning: debian/openhpi-plugin-ilo2-ribcl/usr/lib/openhpi/libilo2_ribcl.so.3.6.1 contains an unresolvable reference to symbol signal_service_thread: it's probably a plugin

This is not a major problem as ilo2_ribcl is a plugin and the daemon libraries are present. So we do not want to add a new dependency. Looking at the code, daemon and the plugin code are mixed up in this case as this variable is used inside the plugin thread (not a thread created by main thread). Take a deeper look at how to handle the functionality without adding this new variable. May be the main ilo2_ribcl thread could signal the other ilo2_ribcl threads? Take a deeper look at this.

Original comment by: mohandev2

[mohandev2]

mkdir /home/mohan/debian_testing_test
cd /home/mohan/debian_testing_test

Go to https://packages.debian.org/testing/libopenhpi3 and download three files manually
They are openhpi_3.6.1-2.debian.tar.xz, openhpi_3.6.1-2.dsc and openhpi_3.6.1.orig.tar.gz

dpkg-source -x openhpi_3.6.1-2.dsc 2>&1 | tee dpkg_source.log
cd openhpi-3.6.1
debuild -uc -us 2>&1 | tee ../debuild.log
vi ../debuild.log and look for signal_service_thread

Original comment by: mohandev2

[mohandev2]

Please check if OA_SOAP_CHEK_SHUTDOWN_REQ could be implemented in ilo2_ribcl also. Could this be used in blade power situations also?

Original comment by: mohandev2

[mohandev2]

I had a check with other plug-in(oa_soap plug-in) in the same area in order to find the way that how they are handling this scenario. Even in oa_soap as well they have the similar concept of polling the loop for the response when we do reset power state for the server. In oa_soap also we have wait time and this can be observed in the set_server_power_state() code.

The way we are waiting in the loop in ilo2_ribcl plug-in ilo2_ribcl_set_power_state() , similar wait is there is oa_soap as well. For the testing I tested the oa_soap plug-in with issuing the kill -15 at different time intervals and based on the time stamp, I got the scenario where even we are waiting for more time compare to the ilo2_ribcl plug-in. It was around 150 seconds wait time.

Further went through the man page and found that dpkg-shlibdeps waring are as expected in our scenario and this can be ignored. In this case symbol is provided by openhpid which loads this plugin. Hence this warning message can be ignored. Please go through the below link for the more details on this warning: http://man.he.net/man1/dpkg-shlibdeps

Now we have two options to handle this:

1. We can go ahead with the man page(http://man.he.net/man1/dpkg-shlibdeps), which suggest that warning can be ignored as this is the expected one when we are dealing with two different binaries while packaging. Hence, we are good to go with packaging by ignoring this warning.

2. We can remove the changes check-in for bug#1876, where we have introduced the check with variable bases exit from ilo2_ribcl_set_power_state() call. Here we are waiting in loop in order to get the response. This will degrade the performance at max by 100 seconds, which is expected as we are waiting for the response of the power state.

Original comment by: erpraveenk

[mohandev2]

• 3.7.0: 3.7.0 --> Future

Original comment by: mohandev2