Open igormicev opened 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:
8.16.0
java 17.0.6 2023-01-17 LTS
22.4.1
Screenshot with the exported content sharing policies:
Screenshot with the imported content sharing policies:
Let me continue with some of the next versions of the toolchain and see how it behaves...
I will also involve @Tchoui and @joroaf for future discussions since they are also familiar with the topic
Info: the same problem exists for version 2.41.0
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.
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.
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
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.
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
@VenelinBakalov is there an expand query
@Michaelpalacce I haven't checked, I was just forwarding the info from the internal chat :D
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
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)