Inconsistent service naming for App, Core and Support services in docker-compose

[bnevis-i]

Affected Services [REQUIRED]

All of the app services. Specifically, ones that in the docker-compose are named 'app-service-BLAH' but whose service keys are 'app-BLAH' (without -service).

Core and Support services for shour name for the service name and the long name for the service key, i.e. data and core-data

Is this a regression?

no

Description and Minimal Reproduction [REQUIRED]

The inconsistent service naming creates problems for the EdgeX delayed service start implementation. In particular, a workaround was added (edgexfoundry/edgex-go#3977) in order to accommodate the inconsistent naming.

In the failure scenario, an app service obtains its SPIFFE ID, and then fails at the edgex-spiffe-token-provider when trying to claim a secret store token. This is because the assigned SPIFFE ID, prior to the workaround, contained app-service-BLAH, but the service presented it service key as app-BLAH. Because of the mismatch, this was seen as an attempt to obtain the secret store token of another service and thus violating the security model.

After the workaround, the SPIFFE ID and the service key match. However, the correct long-term fix is for docker-compose to use 'app-BLAH', core-BLAH and support-BLAH for the service names.

There are TAF dependencies which make switching the service identifier very difficult at this time.

🌍 Your Environment

Deployment Environment: Ubuntu 21.04

EdgeX Version [REQUIRED]: Tip (Kamakura)

Anything else relevant?

[lenny-goodell]

@bnevis-i , Are we ready to address this one?

[bnevis-i]

Yes. I think we're stable enough to start on this.