vmware / build-tools-for-vmware-aria

Build Tools for VMware Aria provides development and release management tools for implementing automation solutions based on the VMware Aria Suite and VMware Cloud Director. The solution enables Virtual Infrastructure Administrators and Automation Developers to use standard DevOps practices for managing and deploying content.
Other
48 stars 24 forks source link

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

Open igormicev opened 4 months ago

igormicev commented 4 months ago

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.

image

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

image

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

Server

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 commented 4 months ago

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: screenshot_content_sharing_policy_export_vrbt_2 40 0

Import:

Screenshot with the imported content sharing policies: screenshot_content_sharing_policy_import_vrbt_2 40 0

igormicev commented 3 months ago

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

VenelinBakalov commented 3 months ago

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

igormicev commented 3 months ago

Info: the same problem exists for version 2.41.0

github-actions[bot] commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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:

image

image

I believe that the logic ABOVE resolveSingleItem is correct.

This is what we have tho:

image

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] commented 1 month ago

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 commented 1 week ago

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 commented 1 week ago

@VenelinBakalov is there an expand query

VenelinBakalov commented 1 week ago

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