[
https://issues.apache.org/jira/browse/CLOUDSTACK-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293068#comment-15293068
]
ASF GitHub Bot commented on CLOUDSTACK-9180:
--------------------------------------------
Github user koushik-das commented on the pull request:
https://github.com/apache/cloudstack/pull/1251#issuecomment-220558485
@swill The failures are not related to this PR.
The failure in test_internal_lb.py is due to some cleanup issue. The
network deletion failed most probably due to some leftover VMs.
The remaining failures seems to be some environment issue due to which
templates are not downloaded and also some test code issue in base.py. In the
below snippet, the execution is going to elif and that is resulting in failure
due to 'in' check on template.status which doesn't seem to be iterable.
if template.status == 'Download Complete':
break
elif 'Downloaded' in template.status:
time.sleep(interval)
elif 'Installing' not in template.status:
raise Exception(
"Error in downloading template: status - %s" %
template.status)
> Optimize concurrent VM deployment operation on same network
> -----------------------------------------------------------
>
> Key: CLOUDSTACK-9180
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9180
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.6.0
> Reporter: Koushik Das
> Assignee: Koushik Das
> Fix For: Future
>
>
> During VM deployment a check is performed to see if VR exists or not. If not
> it is created - first an entry is allocated in DB for VR and then it is
> deployed. The allocation logic is placed in a lock (based on network id) so
> that only one thread does the allocation. But the locking is implemented in a
> way such that all threads wait on that lock even when VR is already
> allocated. The correct approach would be to check if VR is allocated or not
> and acquire lock only when needed.
> This issue is more frequently seen when concurrently deploying VMs in basic
> zone as all threads try to acquire lock using the same network id. In
> advanced zone operations are spread across multiple networks and so less
> frequent.
> Refer to findOrDeployVirtualRouter() in RouterDeploymentDefinition.java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
