After the recent discussion, I think we could add some final changes to leave things consistent and easier to use for end users:
* Previous versions of jclouds used the internal jclouds executor and fetched the nodes concurrently by default. * With this change nodes will be by default obtained in sequence, but users may want to keep the old behavior and keep getting them in parallel. So given that client changes will be required for those users that still want to get benefit of concurrency, I think it is OK to apply the options change in the interfaces, at least to remove the "async" stuff from them. I'd suggesto to: * [ ] Rename all methods prefixed with `concurrently` to overload the normal methods. * [ ] Create a `ListOptions` object, as suggested by @demobox that has a `concurrently` option that accepts an `ExecutorService`. * [ ] Refactor the stategy interfaces too to accept that options object, and implement them accordingly. Existing methods will still work, but without concurrency, but getting things done concurrently would require client changes anyway, so I think it is worth the change and it will leave the interfaces in a cleaner status (and allow us to easily improve them when needed). @demobox @luciano-sabenca-movile WDYT? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-chef/pull/47#issuecomment-49445725
