-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Customer Usage Attribution for partners #265
Comments
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 IdeaMake the telemetry module a loop that merges the 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? |
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. |
Update: Myself and @richeney are syncing internally on this |
@richeney did we need to pick this one backup? |
Yep, I think support for Customer Usage Attribution needs to be added. I understand that CUA is being used to track impact, but it is there as a partner attach ACR mechanism and partners should be able to use it here. That is analogous to the azurerm Terraform provider where Hashicorp use it by default to get some visibility on usage, but it is always available to partner (or to be switched off) even if that has an impact on what Hashicorp can see. Note that there is a new partner program and partner score for this FY which has added focus on partner ACR attach, so we have an opportunity here to add support and avoid any unnecessary friction. I suggest CUA in Bicep need to support both of the following formats:
For reference, I had a recent PR in the Terraform azurerm provider which was pulled into the v3.21.0 release. Issue 17403 / Pull 17441. Adding @mormond, who's the Marketplace guru in the team! |
Ado sync |
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.The text was updated successfully, but these errors were encountered: