[full build] Allow users to specify which host to use

[rbren]

No description provided.

[kaltura-hooks]

Hi @rbren,
Thank you for contributing this pull request!
Please sign the Kaltura CLA so we can review and merge your contribution.
Learn more at http://bit.ly/KalturaContrib

[zoharbabin]

Adding @jessp01 ; this is supposed to allow users to specify the host of the service to use (so one could direct the API to regional clouds or on prem envs).

Of course, there is something we need to potentially deal with; on-prem and also regional clouds, don't have the same set of capabilities enabled, or not be on the same version as the main public cloud... which means these may need to deal with a different schema altogether, or at the very least specify in clear warning message when setting a custom host, that not all APIs might work due to compatibility and config of the environment being used in that custom host.

any thoughts?

[jessp01]

Hi @zoharbabin , @rbren ,

There are several issues here. One is indeed the different versions. Here are two others:
0. In the code generator, we support a setup function and that one includes setting the API endpoint (aka the serviceUrl if to use Kaltura Jargon), that varies between ENVs and is not something users, even developers, are aware of, nor is it properly documented anywhere

1. The aforementioned endpoint is referenced throughout the docs, for example, see https://developer.kaltura.com/api-docs/service/baseEntry/action/list

POST https://www.kaltura.com/api_v3/service/baseentry/action/list

@zoharbabin - the best solution is to deploy an instance of developer.$REGION.kaltura.com per ENV (to wit: developer.eu.kaltura.com, developer.sg.kaltura.com, etc). It takes me under 10 minutes end to end and it doesn't require a very strong machine so I see no problem with it. The deployment process is well documented in the README as well so PS can also do it.

[zoharbabin]

We want to move to a multi-region approach eventually, so I'd rather avoid keeping the structure of dedicated API console per region/cloud env. Instead we should have a single dev console, with an option for the person to chose/set their serviceUrl when they want to test against a different region.

[jessp01]

Hi @zoharbabin ,

See my note above.

optionalizeHost is an LB option; it is documented here http://docs.lucybot.com/LucyBot_yml:

uiOptions.optionalizeHost - Set to true to allow users to set an alternative host, e.g. localhost:3000

This is not enough. Because:
a. There's no Kaltura doc I am aware of that specifies the different endpoints (per ENV)
b. The API documentation is pre-generated and includes references to the endpoint, so, even if the end user is told to input a specific/alternative one when making the request (for example: api.eu.kaltura.com), they will still see POST https://www.kaltura.com/api_v3/service/$SERVICE/action/$ACTION in all the docs