> + 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;
> + }
Hi, My old comment from our slack below. IMHO it is good to have it
jCloudsGroup as default and let users to config that if they want. If we use
jClouds groups as resource groups, some of the jClouds-features are not working
as we can work in one resource group per time.
Example: if we create 10 VMs and we name them "machine", there will be jClouds
group called "machine" and VMs will be named like machine-e3e, machine-e3f,
machine-e3g etc
[9:28]
if we then create another 10 VMs and name them machine2, there will be new
group machine2 etc
[9:29]
if we use this machine2 as azure resource group name, the jClouds API will be
working incorrectly
[9:29]
Because, there is function that we can use to run script in all machines
matching some regex
[9:30]
if we say "runScriptInAllMachinesMatching("machine")", we should run that
script in machine-group and machine2-group.
[9:31]
and basically jClouds will then call our getAllNodes once
[9:31]
and we have implemented getAllNodes so that it will return nodes only from one
resourceGroup
---
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#r64004959
