this is my story:
I am currently setting up a UCP / DTR Cluster for a customer. Requests are externally load balanced by some netscaler setup (managed by closed admin team - no further insights on that so far for me).
UCP / DTR requests are forwarded based on hostname (ducp.x.y and dtr.x.y) as outlined further down.
UCP works fine - DTR setup went smooth after fixing some CA issues and just accessing the UI and clicking around works nice and flawless.
When accessing DTR use cases like “new repository” the Chrome dev-console reveals that under the hood DTR UI gets errors when accessing /enzi/… URLs. Thus (almost) no UCP interaction seems possible … as far as I know the enzi backend resides “in” UCP (?) so the calls should somehow be routed to UCP - but console shows https://dtr.x.y/enzi/… calls.
There is a three node UCP cluster and on each manager node there is a DTR instance deployed on ports 8080/8443 (we do not yet have workers available for that - but that should not be of interest for my issue).
UCP access is possible without trouble (Port 443 default).
DTR can also be accessed without trouble on first glance.
But - if you access say “combined” use cases like “new repository” I get the before mentioned problems accessing https://dtr.x.y/enzi/v0/accounts … URLs.
As far as I can tell all calls to this URL fail.
Looking at dtr-nginx logs doesn’t bring up any more info.
ucp-api logs show loads of calls to API SegmentIo to fail but these shouldn’t be an issue either. btw - why do these take place if metrics are opted out in UCP ?
Any hints ? Where else to look ?