vRA ContentSharingPolicy not pulled/pushed correctly with v2.39.0 and v2.40.0

[igormicev]

Description

Toolchain versions v2.39.0 and v2.40.0 don't handle well the push/pull of the vRA ContentSharingPolicy. On code pulling the names of the items objects are dismissed.

On pushing, the policy is duplicated in vRA/Service Broker.

Steps to Reproduce

1. Switch to one of the mentioned toolchain versions: 2.39.0 or 2.40.0
2. Push/Pull to VRA

Preconditions: [What are the preconditions to reproduce the issue] Ensure there is a ContenSharingPolicy.json file in path ..vra/src/main/resources/policies, as well as the other supporting files under VRA, like content.yaml is properly updated, etc.

Expected behavior: [What you expect to happen] Expected to pull correctly the new/updated catalog items into the ContentSharingPolicy.json file. Expected to push the updated content of ContentSharingPolicy.json into the respective file on vRA/ServiceBroker.

Actual behavior: [What actually happens] On pulling from vRA, the current items got broken. On pushing to vRA the correct ContentSharingPolicy.json file, the already existing policy ContentSharingPolicy was duplicated.

Reproduces how often: [What percentage of the time does it reproduce] 100%

Component/s: [What are the Build Tools for VMware Aria components affected by the issue (e.g. "common/artifact-manager", "maven/plugins/vra-ng", "typescript/vrotest", etc)]

maven/plugins/vra-ng

Affects Build/s: [Which are the Build Tools for VMware Aria releases / builds affected by the issue] 2.39.0 and 2.40.0 as of now.

Environment

Client

• Build Tools for VMware Aria Version: 2.39.0
• Visual Studio Code Version: 1.91.1
• OS Version: Windows Server 2019 Standard, Version 1809, OS Build 17763.5936

Server

• vRealize Automation Version: 8.16.0.33697
• vRealize Orchestrator Version:
• vRealize Operations Version:
• vRealize Log Insight Version:

Failure Logs

Related issues and PRs

Additional Context

node -v v20.12.2

java --version openjdk 17.0.10 2024-01-16 LTS OpenJDK Runtime Environment SapMachine (build 17.0.10+7-LTS) OpenJDK 64-Bit Server VM SapMachine (build 17.0.10+7-LTS, mixed mode, sharing)

[akantchev]

Hi I did some tests with the vRBT 2.40.0 and was not able to reproduce the issue you had. I am using the following environment:

1. vRA - 8.16.0
2. OpenJDK - java 17.0.6 2023-01-17 LTS
3. Node - 22.4.1

Export:

Screenshot with the exported content sharing policies:

Import:

Screenshot with the imported content sharing policies:

[igormicev]

Let me continue with some of the next versions of the toolchain and see how it behaves...

[VenelinBakalov]

I will also involve @Tchoui and @joroaf for future discussions since they are also familiar with the topic

[igormicev]

Info: the same problem exists for version 2.41.0

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[igormicev]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

I'll checkout the issue with the latest version and update.

[Michaelpalacce]

Without trying this I am almost certain there is a bug. It makes no sense for us to export it and NOT save the Name.

Furthermore, not to mention that there is a clear contradiction in the code:

I believe that the logic ABOVE resolveSingleItem is correct.

This is what we have tho:

The naming on the argument and lack of meaningful documentation makes this kind of hard to fully understand to be fair.

I don't have an actual environment to test this tho, but I believe it's as simple as flipping those 2 variables and adding some tests + documentation + rename that argument and we are golden

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[VenelinBakalov]

The source of the issue is that get /policy/api/policies/{id} does not return the name of content source:

"entitledUsers": [
      {
        "items": [
          {
            "id": "555c8279-0f88-4d85-b6c9-228cf0d2165d",
            "type": "CATALOG_SOURCE_IDENTIFIER"
          }
        ],
so, storeContentSharingPolicyOnFilesystem has to be fixed to get the item by id and set name right before it deletes the id from policy data

[Michaelpalacce]

@VenelinBakalov is there an expand query

[VenelinBakalov]

@Michaelpalacce I haven't checked, I was just forwarding the info from the internal chat :D

[igormicev]

Hello,

This remark is gone, i.e. there are no issues on pushing the content-sharing policy with the newer versions. On pushing to vRA the correct ContentSharingPolicy.json file, the already existing policy ContentSharingPolicy was duplicated.