Per what David noted, this needs to be on the OC server. If you would like to upvote the following:
Since the feature to run uimapi on the primary hub, was working till 20.4 lots of our scripts and incomming webhook-Implementation use this, there is no need for a OC in that case, just pushing alarms into it, reading/pushing configs etc...How about the praised API-Feature to implement such solutions and now it only works with a running OC? Strange architecture decission, hopefully this will be turned back.Naturally I upvoted, but it is another bad example how decissionmaking at Broadcom is done.... at the end you have to raise an idea for features they are once working.... and if I remember right, there was once a time where we told that "uimapi" is designed to run the mainhub not on "ump"-Host... and now... but I will doublecheck that... hopefully I mixed things in this case...:-)cheers
Nice workaround, but no solution in my point of view.Sure putting a F5-Cluster in front of it to do my reverse proxy-Stuff should be solid. I 'll dont mention the network-design I have to honor in that case, but the whole charme of a small, minimalistic running monitoring-software is further gone with that stepPrior to 20.4 the Mainhub was enough to push alarms into the system and do automatic actions out of it...But thanks for the hint, nice IdeacheersMatthias
I can confirm that 20.42 uimapi is killing our reverse proxy separated /uimapi server setup aswell.
Need to downgrad to 20.41 to get it functional again.
What happened with 20.42 uimapi that its causing that problems?