Add OpenShift AI integration specifications

[Jan-Kazlouski-elastic]

This PR adds changes to specification caused by elastic/elasticsearch#136624

Corresponding PR for elasticsearch repo that has to be merged first:
elastic/elasticsearch#138025

Additional actions

• Signed the CLA
• Executed make contrib

[github-actions]

Following you can find the validation changes against the target branch for the API.

API	Status	Request	Response
inference.put_openshift_ai	➕ ⚪	Missing test	Missing test

You can validate this API yourself by using the make validate target.

[JoshMock]

This URL does not exist yet, which will cause some clients' docs builds to fail. Will this page be available soon?

[Jan-Kazlouski-elastic]

I believe this will be added by merging of elastic/elasticsearch#138025 PR.
And in order to merge - overall changes to specification must be reviewed. Any change to mentioned PR - will result in changes to this PR.

Please correct me if my understanding is not valid.

[JoshMock]

You're correct! Just making sure any broken URLs are temporary.

[Jan-Kazlouski-elastic]

You're correct! Just making sure any broken URLs are temporary.

Sure thing! Thank you for your vigilance.

[DonalEvans]

There are 5 different request examples given for creating different OpenShift AI endpoints, but only one response example, which doesn't seem to match any of the requests, since it uses "string" for both the service and the inference_id. Would it be possible for the example response to match at least one of the given requests?

If the response is significantly different for each of the task types, then an example response for each would be good, but not mandatory.

[Jan-Kazlouski-elastic]

Hi @DonalEvans
I'd like to know more about what is meant by one response example in your comment. It is common practice for the integrations not to provide any response examples for operations. And none was added. So I'm a bit confused by what response example you're referring to.

But still - I have added XML response for OpenShift AI for every request example. That might be good practice to establish for our next integrations if you see that suitable.
Type string is replaced enum as well as in other PR

[DonalEvans]

It is common practice for the integrations not to provide any response examples for operations.

Thanks for this context, I wasn't aware that that was the common practice in the past. Thank you also for adding response examples for each of the task types, I think it improves the usefulness of the docs for users.