vmware_object_role_permission: Parameter object_name also accepts paths#2315
vmware_object_role_permission: Parameter object_name also accepts paths#2315Fleege wants to merge 8 commits intoansible-collections:mainfrom
Conversation
|
Build failed. ❌ ansible-tox-linters FAILURE in 4m 19s |
|
Build failed. ❌ ansible-tox-linters FAILURE in 4m 26s |
|
Build failed. ✔️ ansible-tox-linters SUCCESS in 4m 26s |
|
Build succeeded. ✔️ ansible-tox-linters SUCCESS in 4m 27s |
|
@Fleege Do you think you could come up with a good test case and add it to |
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
…re seems to be related to something outside the code
|
Build failed. ✔️ ansible-tox-linters SUCCESS in 4m 59s |
|
Hi @mariolenz, The ansible/check workflow seems to fail because of an error outside of my code (Something about an already existing portgroup). |
|
@mariolenz Sorry for this stupid mistake. This should be fixed now, but the check pipeline still fails |
|
Build failed. ✔️ ansible-tox-linters SUCCESS in 4m 55s |
|
Any update on this ? Really useful feature |
|
Build failed. ✔️ ansible-tox-linters SUCCESS in 5m 40s |
Sorry for the late reply, I was on vacation. I have not been looking at this PR for a while as we have a local copy of the affected module in our own collection. I Updated my Fork the new main branch of this project, but the zuul-build still fails (now with a license error). I think we have to wait for ansible/ansible-zuul-jobs#1916 in the zuul jobs to get the check running and afterwards this PR hopefully can get merged (@mariolenz: correct me if I am wrong). |
…re seems to be related to something outside the code
|
Build succeeded. ✔️ ansible-tox-linters SUCCESS in 5m 21s |
|
Is there any reason why this can't get merged? |
5 participants
SUMMARY
You can now pass a path as object_name to identify an object where the name is not unique
Fixes #1217 #2421
ISSUE TYPE
COMPONENT NAME
vmware_object_role_permission
ADDITIONAL INFORMATION
This is required if you want to use this module for objects where the name is not unique. This happened to me in a folder structure where we first had the environment type (prod/test/dev) and below this structure the service type (web/database etc.).
In this structure we had multiple folders with eg. the name database (/dev/database and /prod/database) and those folders could not be identified by their name.