RP Name service tree metadata in ADO is often incorrect (Committed for dilithium-2H)

[ladonnaq]

Requirement: The logic that ingest the service tree metadata for ARM RP Namespace needs to be redesigned because there are inaccurate RP names for around 20% of the products in ADO. Also, ARM will start allowing service partners to have sub-RPs, which will be the RP name + resource type. Today this information is entered into service tree. There needs to be a redesign of the logic so that the RP name and resource types metadata is retrieved, and the user selects the RP name and resource type from a drop-down menu during onboarding.

Background:
The ARM Namespace metadata contains information on all ARM namespaces, including Private and Test. Services can have multiple ARM namespace so there can be metadata for one or more ARM namespace in service team. The current logic seems to be returning the most current RP Namespace (most recent date). However, this is not always the RP namespace the namespace we want in dataverse or ADO. The RP Namespace field should be the value of the RP that enables the product and that value can change from Private Preview to Public Preview/GA. Also, ARM is going to allow sub-RPs, so we need to also retrieve the resource types.

Initial thoughts on possible approach (need design/requirement work session to refine requirements and discuss approach)

• Retrieve ARM namespace metadata during onboarding and display to user in a drop-down box. Let user select the most relevant namespace and resource type from the drop-down box. Ensure value is in dataverse and synced to RP Name field in the epic-product. Here is the query used by ARM to create the Service Tree Onboarding (ARM RP Namespace metadata) - https://dataexplorer.azure.com/clusters/datastudiostreaming/databases/Shared.
• Change the RP Name ADO Field in the epic-service to be a multi-text field. The following data should be in the field "ARM Namespace" ARMRPReadiness", "ResourceTypeName" and "ResourceTypeReadiness" for Service.
• The RP Name ADO Field in the epic-product should be the "ARM Namespace" + "ResourceTypeName" that enable the product. Users will select the appropriate "ARM Namespace" + "ResourceTypeName" when they onboard a product. These values should be confirmed when creating a release plan and allow user to update if needed.

RP/ARM Namespace Metadata in Service Tree

• For reference here is the ARM RP/Namespace Service Tree Onboarding PowerBI - https://msit.powerbi.com/groups/85d0bde6-230a-4d8d-98f9-43777d9750b2/reports/fa177a28-da49-4838-b9dc-55e6ec56423a/ReportSection?experience=power-bi
• Here is the Kustos Query that the ARM/RP Namespace Service Tree Onboarding PowerBI report/dashboard is using for the dataset - https://dataexplorer.azure.com/clusters/datastudiostreaming/databases/Shared
• Screenshot of service tree metadata for ARM/RP Namespace. In the epic-service RP Name ADO field list the ARM namespace, ARM Namespace Readiness, Resource Type Name, and Resource Type Readiness. All of these fields have useful information in understanding what products are enabled by the service.

[maririos]

@ladonnaq I lack the context here, Who uses the RP Name and for what? we don't have any dependency on it in our apps or in the specs repo logic

[ladonnaq]

@ladonnaq I lack the context here, Who uses the RP Name and for what? we don't have any dependency on it in our apps or in the specs repo logic

1. The RP name is related to the namespace for the ARM REST API Spec. In service tree, a product often maps to many services.
2. The service that owns the RP is the one that also owns the ARM REST API.
3. In our specs repo the folder name is the RP Namespace. The API Specs in that folder will be used to generate the SDK package (which you know).
4. From a release plan perspective, we want the release plans to be associated with the service and the ARM REST APIs that enable it. If we don't capture the RP mapping to products, then our data will not be accurate.
5. For example, Migrate has 2 RP namespaces. Sometimes a product will only be enabled by one, other times by both.
   
6. Another example is when a new product is enabled by data plane and management REST APIs. I have seen several scenarios where the product is enabled by the REST APIs for Service xyz and the data plane REST APIs of a different service (which typically owns the new product).

[maririos]

From a release plan perspective, we want the release plans to be associated with the service and the ARM REST APIs that enable it. If we don't capture the RP mapping to products, then our data will not be accurate.

We have the PR, so we know the directory. why do we need to RP? like again. nothing in here suggest there is automation or a process that needs the name of the RP

[maririos]

I understand the RP is important. I don't understand why it is important for the Release Planner or the dashboard. If this is just a copy of the data in Service Tree, why can't the person who needs it (who?) goes and looks there?