1. Proposed title of this feature request

Consistent service account email domain Telemetry in ocm_subscription

2. What is the nature and description of the request?

Currently there are some ocm_subscription metrics in Telemetry where the email_domain label is empty. This RFE is requesting it be populated for all future ocm_subscription time series.

3. Why does the customer need this? (List the business requirements here)

Telemetry consumers can use email_domain as a convenient way to determine if a cluster is internal (and there's some chance of getting in contact with the cluster-owners) or external (where cluster-owner contact requires more formal channels), e.g. here. Without email_domain populated, clusters with service account credentials will fall into the external accounting box, regardless of whether they're actually internal or external. With this RFE, that accounting would become more accurate.

4. List any affected packages or components.

I'm not clear on team structure in this space, but it seems like there is an email property on the service-account structure in OCM's database. And somewhere inside OCM there is apparently logic that looks up an org-admin email when a Service Log is being sent "to that cluster". Perhaps the default-service-account-email org-admin-fallback logic could get pushed down into the endpoint that returns service accounts, and that would bubble up through to ocm_subscription labels and any other service-account consumers? Or something custom could be added to the ocm_subscription generator to call the default-service-account-email logic if the email field was not populated? Or anywhere in between those two points.

Selecting a single email from a potentially large set of org-admins as the fallback email for the service account also seems like it might be problematic. I'm not clear on how stable the fallback selection is today, or how teams make this work if the selected org-admin happens to be on vacation when the Service Log goes out, or what. It might be a good idea to revisit this whole fallback-email approach while addressing this RFE. Or maybe that opens up too many questions, and it would be better to narrowly focus on plugging the existing fallback logic into the ocm_subscription handling, and then revisiting the fallback algorithm if/when someone asks for that.