[
https://issues.apache.org/jira/browse/CLOUDSTACK-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Damle reopened CLOUDSTACK-5853:
--------------------------------------
Hi Marcus,
I see that as a fix, in ClusterScopeStoragePoolAllocator we remove the storage
pools from avoid set if they happen to match the tag but are found in avoid set.
However this fix is not correct since it breaks the design of avoid set. A
storage pool might be put in the 'avoid' set by the calling logic for a valid
reason like capacity exceeded or creation of disks failed on previous try etc.
In such cases the fix will override the avoid set and keep on trying the same
pool.
The correct way to fix this is handling of the avoid set in the caller of the
StoragePoolAllocator - in most of the VM operations the caller is the
DeploymentPlanningManager.
I had already added the necessary fix in DeploymentPlanningManager through
this ticket https://issues.apache.org/jira/browse/CLOUDSTACK-5426
Please can you revert this ticket
https://issues.apache.org/jira/browse/CLOUDSTACK-5853?
> cannot deploy vm with differing service storage tag and data disk storage tag
> -----------------------------------------------------------------------------
>
> Key: CLOUDSTACK-5853
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5853
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.2.0, 4.3.0, 4.4.0
> Reporter: Marcus Sorensen
> Assignee: Marcus Sorensen
>
> Create two storage pools, one with storage tag X, one with storage tag Y.
> Create a service offering with storage tag X.
> Create a disk offering with storage tag Y.
> Attempt to deploy a virtual machine with a datadisk, using given offerings,
> it fails.
> Deployment planner keeps a global object 'avoid'. It loops through each
> volume to be created, asking storage allocators for matching pools, passing
> this avoid object.
> First disk matches a pool or pools, adds ALL other pools to avoid object,
> then deployment planner attaches matching pools to a list for that disk.
> Second disk matches a pool, adds all other pools to avoid object, then
> deployment planner says "wait, matching pool is in avoid, can't use it".
> Oops. In fact, at this point ALL pools are in avoid (unless there are other
> pools that have both tags).
> Need to remove matching pool from the avoid set during each select phase.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
