Enable Customer Usage Attribution for partners

[richeney]

The CUA mechanism is being used to allow tracking of the various modules and for Microsoft to provide better support.

However, Customer Usage Attribution is one of the mechanisms used to recognise partner attached ACR. It isn't the preferred mechanism - CSP and PAL are more robust - but is still valid and the repo should enable its use.

I suggest that the repo introduces a consistently named parameter, e.g. CUA_GUID, to all modules so that a partner specified GUID can filter through the modules. The parameter value would be set to the GUID generated and registered by the partner.

[jtracey93]

Hey @richeney,

Thanks for raising this. This needs some consideration as it would technically break our own telemetry if we allowed the CUA ID to be set via a parameter, today its a variable, that partners could change if they wanted to today once they've forked/cloned the repo.

I agree that CSP and PAL are the better ways for partner to attach themselves to ACR.

Are there any active requests for this from partners (feel free to ping me on Teams to keep it confidential 👍)? This will help us understand priority for this work.

Potential Idea

Make the telemetry module a loop that merges the ALZ-Bicep CUA ID with an input parameter version in a concat and then loop over the combined array.

That way both PIID deployments could occur and live together.

Would you want the opt out of telemetry option to apply to the partner one also @richeney?

[richeney]

To be clear, CUA is a mechanism intended for use by partners.

I don't think it supports multiple GUIDs as suggested by the loop idea. It just adds pid-GUID to the agent header and then uses the correlationId to determine which resources should be linked to the MPN ID via that pre-registered GUID.

[jtracey93]

Update:

Myself and @richeney are syncing internally on this

[jtracey93]

@richeney did we need to pick this one backup?