[storage::netapp::ontap::restapi::plugin] bay and fru go away

[monsieurpouet]

Hi all !

Quick description

When i use the storage::netapp::ontap::restapi::plugin plugin with hardware mode, I get a invalid key from equipment.

How to reproduce

Please provide below the initial conditions to reproduce the bug

Environment: Debian 11.11.
Version of the plugin: 20250114-1+deb11u1
Command line: /usr/lib/centreon/plugins//centreon_netapp_ontap_restapi.pl --plugin=storage::netapp::ontap::restapi::plugin --mode=hardware --hostname='ip.ip.ip.ip' --port='443' --proto='https' --api-username='***' --api-password='***' --insecure --component='fru' --verbose

Expected result

checking frufru 'module:0' shelf '1.0' state is 'ok' [shelf: SHJHU2412000471, instance: 952342000784]fru 'module:1' shelf '1.0' state is 'ok' [shelf: SHJHU2412000471, instance: 021840000997]fru 'psu:1' shelf '1.0' state is 'ok' [shelf: SHJHU2412000471, instance: PSQ094231503982]fru 'psu:2' shelf '1.0' state is 'ok' [shelf: SHJHU2412000471, instance: PSQ094231503990]

Actual result

{
  "error": {
    "message": "The value \"fru\" is invalid for field \"fields\" (<field,...>)",
    "code": "262197",
    "target": "fields"
  }
}

Closing words

Same problme with the bay component.

[vmpr]

I got the same problem, Do you have any ideas on how to fix that and what we can do as a workaround?

[lucie-dubrunfaut]

Hello :)

Can you please provides us with the output using the --debug option (check to anonymize datas that need it)?

[vmpr]

sure no worries:

/usr/lib/nagios/plugins/centreon-plugins/centreon_plugins.pl --plugin storage::netapp::ontap::restapi::plugin --hostname 10.13.37.10 --api-username fnu-netapp-mon --api-password "XXX" --insecure --mode hardware --debug
UNKNOWN: 400 Bad Request 
checking bays
======> request send
GET https://10.13.37.10:443/api/storage/shelves?fields=name,state,serial_number,bay,frus
Accept: application/json
Authorization: Basic XXX
User-Agent: centreon::plugins::backend::http::useragent
Content-Type: application/json

======> response done
HTTP/1.1 400 Bad Request
Cache-Control: no-cache,no-store,must-revalidate
Connection: close
Date: Fri, 07 Feb 2025 13:20:33 GMT
Server: libzapid-httpd
Content-Length: 147
Content-Type: application/json
Client-Date: Fri, 07 Feb 2025 13:20:33 GMT
Client-Peer: 10.13.37.10:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: 
Client-SSL-Cert-Subject: 
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_2
X-Content-Type-Options: nosniff

{
  "error": {
    "message": "The value \"bay\" is invalid for field \"fields\" (<field,...>)",
    "code": "262197",
    "target": "fields"
  }
}

It seems like the netapp API doesn't like the "bay" value in the fields parameter

must be somewhere here in the code:

sub get_disks {
    my ($self, %options) = @_;

    return $self->{custom}->request_api(endpoint => '/api/storage/disks?fields=name,state,serial_number,bay');
}

sub get_shelves {
    my ($self, %options) = @_;

    return if (defined($self->{shelves}));

    $self->{shelves} = $self->{custom}->request_api(endpoint => '/api/storage/shelves?fields=name,state,serial_number,bay,frus');
}

hope that helps! have a great day!
cheers Ringo

[monsieurpouet]

@lucie-dubrunfaut : My debug is the same than @vmpr

[lucie-dubrunfaut]

Hello :)

Was this mode working for you before January release or were you unable to test it before?
We have automated tests implemented in January that do not indicate any problems with the fru and bay components. Do you think you would be able to send us the API JSON output (take care to anonymise the fields that are required) to compare with the one on which our tests are based?

[monsieurpouet]

Hi Lucie,

I didn't have any problems before.
The only json output I have is in my first message.

There is a problem with the API output.

[joschi99]

We have the same issue. The problem is since version 20250114 and is related to this lines

sub get_disks {
    my ($self, %options) = @_;

    return $self->{custom}->request_api(endpoint => '/api/storage/disks?fields=name,state,serial_number,bay');
}

sub get_shelves {
    my ($self, %options) = @_;

    return if (defined($self->{shelves}));

    $self->{shelves} = $self->{custom}->request_api(endpoint => '/api/storage/shelves?fields=name,state,serial_number,bay,frus');
}

If you switch back to the old version it will work

sub get_disks {
    my ($self, %options) = @_;

    return $self->{custom}->request_api(endpoint => '/api/storage/disks?fields=*');
}

sub get_shelves {
    my ($self, %options) = @_;

    return if (defined($self->{shelves}));

    $self->{shelves} = $self->{custom}->request_api(endpoint => '/api/storage/shelves?fields=*');
}

This should be fixed as soon as possible

[lucie-dubrunfaut]

Hello :)

Thanks for the clarification. I opened a dev ticket and create the branch with the code reverse suggested above here #5451. I'm going to discuss it with the dev team and we'll see what solution we can come up with as quickly as possible.

[lucie-dubrunfaut]

Another solution was already proposed, can you check if it works?
#5395