-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traverse folders in vmlist #507
Traverse folders in vmlist #507
Conversation
Merge pull request vmware#506 from austinlparker/add-snapshot-delete
Actually, turns out my filter is just garbage - it only took around 40s to traverse all the folders and build the VirtualMachineList |
@austinlparker thanks, I keep meaning to revisit this. It should be possible to compose the PropertyCollector query such that recursion happens on the server (VC) side. When this code was originally written we were only hitting ESX directly. I've been spending some time with the PropertyCollector recently, so I'll try to get this sorted out soon. |
@dougm Do you have any sort of ETA? I can use my fork in the meantime - I tested this out again today when the app was sitting behind the firewall and it ran much quicker. When I was testing last week, I was running over VPN through a spotty cell connection. It's certainly not much slower than what I'm using in pyvmomi. |
@austinlparker hopefully later this week or early next |
+1 |
@dougm Any update here? |
@austinlparker apologies for the long delay. This is very high on my list, but other things keep getting in the way. I still want to look at supporting recursion for types other than VirtualMachine, have an option to enable/disable, tests, etc. |
Thanks for letting me know! If there's anything I can specifically do to help, mention me and I can take a crack at implementing some stuff to help out. |
Still haven't gotten to this yet, but getting closer. |
@dougm I could also use this. Have you made any progress? |
Prior to this change, the Finder behaved like the 'ls' command and as such required a Folder name or wildcard in the path argument to find resources within folders. The original "list" mode of the Finder is maintained, but will now switch to "find" mode if the path argument does not contain a "/". See find/doc.go for details. The public Finder method signatures remain the same, with the exception of ManagedObjectListChildren which now takes an optional (variadic) list of types. No new public methods or types have been added. The 'list.Recurser' type is no longer exported and has moved to an unexported type within the find package. This part of the change assumes that 'list.Recurser' was not used directly outside of the govmomi repo. The tests depend on the Go based vCenter simulator, which currently lives in the vmware/vic repo, but will be moving to the govmomi repo at some point. Fixes vmware#190 Fixes vmware#519 Fixes vmware#540 Closes vmware#507 Closes vmware#593
Apologies again for the long delay. Please review #663 - the change applies the same behavior to all resource types, rather than just the VirtualMachine type in this PR. |
Prior to this change, the Finder behaved like the 'ls' command and as such required a Folder name or wildcard in the path argument to find resources within folders. The original "list" mode of the Finder is maintained, but will now switch to "find" mode if the path argument does not contain a "/". See find/doc.go for details. The public Finder method signatures remain the same, with the exception of ManagedObjectListChildren which now takes an optional (variadic) list of types. No new public methods or types have been added. The 'list.Recurser' type is no longer exported and has moved to an unexported type within the find package. This part of the change assumes that 'list.Recurser' was not used directly outside of the govmomi repo. The tests depend on the Go based vCenter simulator, which currently lives in the vmware/vic repo, but will be moving to the govmomi repo at some point. Fixes vmware#190 Fixes vmware#519 Fixes vmware#540 Closes vmware#507 Closes vmware#593
Prior to this change, the Finder behaved like the 'ls' command and as such required a Folder name or wildcard in the path argument to find resources within folders. The original "list" mode of the Finder is maintained, but will now switch to "find" mode if the path argument does not contain a "/". See find/doc.go for details. The public Finder method signatures remain the same, with the exception of ManagedObjectListChildren which now takes an optional (variadic) list of types. No new public methods or types have been added. The 'list.Recurser' type is no longer exported and has moved to an unexported type within the find package. This part of the change assumes that 'list.Recurser' was not used directly outside of the govmomi repo. The tests depend on the Go based vCenter simulator, which currently lives in the vmware/vic repo, but will be moving to the govmomi repo at some point. Fixes vmware#190 Fixes vmware#519 Fixes vmware#540 Closes vmware#507 Closes vmware#593
Prior to this change, the Finder behaved like the 'ls' command and as such required a Folder name or wildcard in the path argument to find resources within folders. The original "list" mode of the Finder is maintained, but will now switch to "find" mode if the path argument does not contain a "/". See find/doc.go for details. The public Finder method signatures remain the same, with the exception of ManagedObjectListChildren which now takes an optional (variadic) list of types. No new public methods or types have been added. The 'list.Recurser' type is no longer exported and has moved to an unexported type within the find package. This part of the change assumes that 'list.Recurser' was not used directly outside of the govmomi repo. The tests depend on the Go based vCenter simulator, which currently lives in the vmware/vic repo, but will be moving to the govmomi repo at some point. Fixes #190 Fixes #519 Fixes #540 Closes #507 Closes #593
This is a resubmit of #328 as I could really use that functionality in master and the original contributor seems to not be around any more. I was able to test locally that it did indeed work, although it takes some time to to traverse the folders (for instance, on a vCenter instance with about 600 VMs and quite a few folders, it took 3 minutes to traverse the folder structure and then inspect 3 VMs snapshot status)