Skip to main content

Hi =) 

I just upgraded from 24.10.2 to 24.10.3 last week, and I just found a change of behavior of the CLAPI.

 

I think I’m “stretching” the use of the CLAPI and maybe I’m not following best practices, so feel free to give me feedback on how you would do those tasks 


When I create a new project / new VMs in an existing project, I like to check if the host already exists via this CLAPI, to only apply my “auto_checks_conf” to newcommers and not get an error message like “This host already exists”
I used to check with commands like this one : 

centreon -u admin -p '*****' -o HOST -a show -v "{{ Hostname }}"

What I used to get as a return when there were no existing hosts : 

id;name;alias;address;activate

What I have now :

id;name;alias;address;activate
Return code end :

Here is a more complete show of what I try to do in the end (ansible, I’d understand to not have help on this part as this is not directly related to centreon) : 

 - name: check si host existe
   shell: centreon -u admin -p '*****' -o HOST -a show -v "{{ Hostname }}"
   delegate_to: centreon
   register: command_output

 - name: creation du host (si résultat précédent vide)
   shell: centreon -u admin -p '*****' -o HOST -a add -v "{{ Hostname }};;{{ ipHost }};{{ templateHost }};Central;"
   delegate_to: centreon
   when: command_output.stdout == "id;name;alias;address;activate"

I check mainly if hosts and hostgroups exists, and i try to compare the stdout with a defined string that is returned, because the return wasn’t empty.

Is there a more elegant way to do so, that would be future proof as we can see the output can change ? 

Thanks in advance, and if anyone is automating the deployment of supervision, feel free to respond here or talk about it further in dm =) 

Just a note, i found a “workaround ”, not a solution : 


I now have a variable called “nbLignes”, at the beginning of my scripts, and I assign it the exact number of lines expected for an empty return of the commands “show”

Instead of comparing the output of the command to a defined string, i now count the number of lines of this output, and only make my actions when this number of lines equals my variable.

This way, even if the behavior changes back, I just have to edit the value of this variable and the scripts will work =) 

Still, i feel like this is a “fraud”, maybe there are more or different options if I try to use the API v2 instead of the CLAPI ? 
If anyone is currently using some similar scripts / jobs, feel free to DM me or post here your solutions / workaround on this kind of issue =) 

Thanks for your time, see you

EDIT : I also noted that this new line, “Return code end :” , is always present, not only on empty returns. Maybe the title isn’t a perfect match, since the behavior changed on every returns and not juste empty ones, but i didn’t find how to edit the title

> I also noted that this new line, “Return code end :” , is always present, not only on empty returns. Maybe the title isn’t a perfect match, since the behavior changed on every returns and not juste empty ones, but i didn’t find how to edit the title

I have a script silently failing since June because of this (an upgrade from 23.10 to 24.10 brought the bug). Those kind of breakage are more than tiring. It’s like there zero test done for any release (how can such a bug not being seen else?). Centreon is becoming more and more buggy year after year. This is sad.   

And yes, I call this a bug, because it’s not only an un-notified API breakage (that is, on its own, a real bad issue), but because it outputs something that has no justification being on the standard output, plus, even if it has been produced on the standard error output, it’s obviously incomplete. What misery.

I won’t point out the fact “Return code end” is grammatically wrong and in English there must be no space before a colon. Oops, I did finally…

@baskmobile 

About a workaround. In my case I will probably grep out the faulty line, because assuming it will always be there by counting this line in the line count is the best way to see your script to break again if CLAPI is fixed (or worst: having an erratic behaviour).

Is there a more elegant way to do so, that would be future proof as we can see the output can change ? 

 

I would say to be future proof is to try to target the REST api of centreron, the v1 is pretty much compliant with the CLAPI, i’m not sure for the v2 as it’s still in progress.

Is there a more elegant way to do so, that would be future proof as we can see the output can change ? 

 

I would say to be future proof is to try to target the REST api of centreron, the v1 is pretty much compliant with the CLAPI, i’m not sure for the v2 as it’s still in progress.

Thanks for the insight, yes we started the transition to the REST API in some cases (we have multiple centreon instances and one of them is our “POC” for this REST API, we do everything with it)

But I didn’t see any news about the EOL of the CLAPI, did I miss it ? My understanding was that both would be available at any time, and I went with the one that seemed to be the easiest to deploy for me

And for ​@Stéphane , I guess you’re right, I’ll change my scripts to grep out this line and then compare to what I expect, because I’m not certain I will remember to change this tiny variable in some month / years, when this will be fixed

Thanks to both of you for the reply on this thread =) 

I don’t believe it’s decomissioned yet or is planned to do so. After all the AWIE (import/import) module is still based on the CLAPI itself.

>I would say to be future proof is to try to target the REST api of centreron,

I agree about the v2 API, it is more what one can expect from a modern API. But not v1. Although the “dumb” action/object/value(s) and CSV format is often far more straightforward for handling a lot of thing than dealing with JSON (especially when for I don’t know what reason the said API which was accepting a very high limit for the number of records returned suddenly impose dealing with pagination in your script/app at a nearly ridiculous number moreover).

>the v1 is pretty much compliant with the CLAPI, i’m not sure for the v2 as it’s still in progress. Add as many details as possible, by providing details you’ll make it easier for others to reply

I may be wrong but I think the HTTP REST API v1 is a wrapper for CLAPI, it doesn’t call the CLAPI script it self I guess, but use the same underlying PHP code. I thought about verify this but not only I have rather a deficit of  “free” time but the Centreon codebase kind of afraid me. Think I’ll ask CoPilot to assist me for this adventure ! ^^

Also, HTTP/JSON being kind of de facto standard, rely on SSH (when it is not done locally even) and a shell is very handy, more effective. I’d rather deal with SSH keys than token, PHP sessions, or even ACLs when it is assumed the agent/script has full power and is plainly trustable (the most plainly trustable a thing can be! ^^) (lil’ digression there: I discovered recently that having an account tagged “admin” in the Centreon interface gives it no more a full unconditional access to everything, and so, it has probably no more reason to be I’d say).
I have absolutely no problem admitting this is a matter of taste or I could be proven wrong on the technical aspect of the subject. What I find upsetting here is the breaking of functionalities. And this is obviously right to think “future proof”, but it is even more being “present proof”. From my own point of  view, at least.

Best regards.

Reply


Terms & ConditionsCookie settings