VMware Cloud Community
qc4vmware
Virtuoso
Virtuoso

vRA 8.8 issues changing owner on deployment when only using groups as members.

As of 8.8 vRA supports setting ownership on a deployment based upon a user being a member of the groups defined with roles in that project.  This seems to be working great for me if the group has been in vRA for some period of time but for a new group I'm running into some strange behavior where I wonder if there is an api call I need to hit to finalize it all.  Let me sketch out how all of this is automated.

We have a request form we've created in ServiceNow for VM deployments.  The automation is anchored on an AD group.  Each deployment is managed by the users that are members of the specified group and there is an accompanying project where the settings are set to share all deployments amongst that project with the project members.  The AD group is added to the group as the only member.  The main flow is as follows:

1. If the group is not available in vRA add to vIDM sync profile and force a sync (worked with professional services to get this working)

2. After sync completes create project with group as a member.

3. Kick off deployment.

4. After deployment completes change owner to the requesting user.

 

Step 4. is failing if this is a newly synced group.  If I login to the UI and try to change the owner they don't show as an option.  If I remove the group from the project, save, then add the group back suddenly it all seems to work.  I've tried this programmatically and it still fails.  Seems like something is happening when I'm in the UI that isn't happening when I do it all via th api.

Reply
0 Kudos
1 Reply
qc4vmware
Virtuoso
Virtuoso

I think I've solved the issue... It appears that updating the members on a project is case sensitive.  The input form and routine I run for sync'ing the groups is case insensitive.  Once I got the case to match up with the group name things are working again... the vast majority of our groups are lower case but some are a mix.  I did not realize case was being enforced.  Not sure if that is a bug or a feature but I'll have to add some logic to scrub that incoming information and make sure the case matches up.  Should be able to do this after the sync completes with a call to the identity api. Searches seem to be case insensitive from what I've tested so far.  I'll just use that information once I get it.

Reply
0 Kudos