> + System.out.println(str);
> + }
> + return Iterables.filter(listNodes(), new Predicate<VMDeployment>() {
> + @Override
> + public boolean apply(final VMDeployment input) {
> + return Iterables.contains(ids, input.deployment.name());
> + }
> + });
> + }
> +
> + private String getGroupId() {
> + String group = System.getProperty("test.azurecompute-arm.groupname");
> + if (group == null)
> + group = "jCloudsGroup";
> + return group;
> + }
Thanks for the update. That's why I'm asking. There are two direct approaches
here and we have to chose one:
1. Configure a resource group when creating the context (but provide a default
resource group in case users don't configure it), and let jclouds only consider
that resource group.
2. Assimilate a jclouds group to an Azure resource group.
**Option 1** is more straightforward *but* requires users configuring a
specific group. It would limit the users experience of the provider "out of the
box" when using it to manage existing noes in an account. What if users want to
manage nodes that already were there *before* they started using jclouds? What
if nodes are in different resource groups? (Is this something option 2 could
manage?).
**Option 2** would better align the provider with the other ones. When calling
"listNodes" users expect to be returned all the nodes in all locations.
Returning just the ones in a configured resource group is very particular to
Azure.
I tend to prefer Option 2, because the method in the compute service would be
better aligned with how jclouds behaves in the rest of providers, and would
allow users to use jclouds on existing accounts out of the box. However, this
assumes that a resource group is a good match fort a jclouds group (which I
think it is, with the little knowledge I have of the ARM API).
Thoughts? I'm happy to discuss pros, cons, or different approaches, but getting
the model right is crucial to implement the provider. Also, feel free to move
this discussion to the `dev@` mailing list if you prefer a discussion about
this there.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/267/files/bae5d6dfcdb26e31057db4551c5996836666a31b#r64006937
