Ladislav Thon created JCLOUDS-1135:
--------------------------------------
Summary: Azure: AzureComputeServiceAdapter.getNode/listNodes
perform O(N) requests
Key: JCLOUDS-1135
URL: https://issues.apache.org/jira/browse/JCLOUDS-1135
Project: jclouds
Issue Type: Bug
Components: jclouds-labs
Affects Versions: 1.9.2
Reporter: Ladislav Thon
(Note that this is about the "classic" {{azurecompute}} provider, _not_ about
{{azurecompute-arm}}.)
The {{AzureComputeServiceAdapter.getNode}} and {{listNodes}} methods perform
O(N) API requests (where N is the number of existing cloud services). This
results in abysmal performance when a significant number of cloud services
exist.
I'm not sure how {{listNodes}} could possibly be fixed, but I don't really care
much about this method. The only place where it's used is when generating a
unique name for newly created nodes, but that can be overridden from the
outside (via {{templateOptions.nodeNames}}).
On the other hand, I care a lot about the {{getNode}} method. That one should
IMHO complete really quickly. The Azure provider, when creating a node, always
creates a cloud service and a deployment, both of them with the same name (see
https://github.com/jclouds/jclouds-labs/blob/2b36a75f9f/azurecompute/src/main/java/org/jclouds/azurecompute/compute/AzureComputeServiceAdapter.java#L96).
There are other places in the Azure provider that assume that the deployment
inside the cloud service has the same name as the cloud service. With this
assumption, the {{getNode}} method could perform O(1) requests instead of O(N),
resulting in much better performance.
Relying on the assumption should be completely safe when working with nodes
created by the JClouds Azure provider itself. Maybe there are people who use
the JClouds Azure provider within some configuration made outside of JClouds --
for such situations, a configuration flag could be provided, but I honestly
think it's pretty much impossible to do that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
