We got several issues regarding absence of some cloud service in manually maintained list of supported endpoints, although there are exist in public api.
Here i tried approach where we try to guess endpoint id based on stub module name if not found in list.
For now we have list of endpoints which are have match with module name
also some new services will be available after this PR
datasphere
datatransfer
serverless-containers
Default behaviour are left as is: if we cant find endpoint in list in sources or in real endpoints list — we raise error.
So it should be backward compatible and in future we will less often have to put endpoints in hardcoded list.
On other hand it is half-measure because there are still many cloud services with non-guessable endpoint naming, so i guess better approaches:
1) to generate full mapping grpc-service to endpoint_id (if we have it somewhere already)
2) use endpoint_ids in user api and find stubs for them (still need reverse mapping)
We got several issues regarding absence of some cloud service in manually maintained list of supported endpoints, although there are exist in public api. Here i tried approach where we try to guess endpoint id based on stub module name if not found in list. For now we have list of endpoints which are have match with module name
also some new services will be available after this PR
Default behaviour are left as is: if we cant find endpoint in list in sources or in real endpoints list — we raise error.
So it should be backward compatible and in future we will less often have to put endpoints in hardcoded list.
On other hand it is half-measure because there are still many cloud services with non-guessable endpoint naming, so i guess better approaches: 1) to generate full mapping grpc-service to endpoint_id (if we have it somewhere already) 2) use endpoint_ids in user api and find stubs for them (still need reverse mapping)