Yeah, the object 'avoid' in the deployment planner is passed along throughout the whole chain and added to, so the non-matching data disk pool ends up in avoid when searching for a root disk pool, and at that point it will never be chosen. What's kind of interesting as well is that the opposite is true too, when the data disk allocation runs, the pool for the root disk is added to avoid set, but since the pool has already been chosen and associated it never causes an issue. The end result though is that all pools are in avoid set.
On Fri, Jan 10, 2014 at 10:16 AM, Marcus Sorensen <shadow...@gmail.com> wrote: > I added some debug, and do see some weird stuff, like: > > 2014-01-10 10:04:27,335 DEBUG > [storage.allocator.ClusterScopeStoragePoolAllocator] > (Job-Executor-14:job-22034 = [ 0946b816-2a5d-433f-a90b-853a465db45a ]) > Found pools matching tags: [Pool[484|BSSAN]] > 2014-01-10 10:04:27,336 DEBUG > [storage.allocator.ClusterScopeStoragePoolAllocator] > (Job-Executor-14:job-22034 = [ 0946b816-2a5d-433f-a90b-853a465db45a ]) > Adding pool Pool[605|BSSAN] to avoid set since it did not match tags > 2014-01-10 10:04:27,338 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] > (Job-Executor-14:job-22034 = [ 0946b816-2a5d-433f-a90b-853a465db45a ]) > Checking if storage pool is suitable, name: null ,poolId: 484 > 2014-01-10 10:04:27,338 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] > (Job-Executor-14:job-22034 = [ 0946b816-2a5d-433f-a90b-853a465db45a ]) > StoragePool is in avoid set, skipping this pool > > If I had to guess at this point, I'd say it has something to do with > that avoid set. During the root volume allocation, it passes back all > storage pools that DON'T match the root volume. The target pool for > the data disk will be in that set. I'm wondering if that's triggering > the avoid, if we're mixing up/combining the avoid sets between > volumes. > > On Thu, Jan 9, 2014 at 11:40 PM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: >> Well, we can wait and see if anyone disagrees that it's a bug. Maybe if no >> one does by end of day tomorrow I can log a bug for it. >> >> >> On Thu, Jan 9, 2014 at 11:35 PM, Marcus Sorensen <shadow...@gmail.com>wrote: >> >>> Sure, I just wanted to make sure it wasn't expected first. I thought >>> perhaps the service offering was supposed to trump all in the case of >>> deploy. >>> >>> On Thu, Jan 9, 2014 at 11:33 PM, Mike Tutkowski >>> <mike.tutkow...@solidfire.com> wrote: >>> > Would you like me to open a bug, Marcus, and use your example or were you >>> > planning on doing so? >>> > >>> > Thanks >>> > >>> > >>> > On Thu, Jan 9, 2014 at 10:56 PM, Mike Tutkowski < >>> > mike.tutkow...@solidfire.com> wrote: >>> > >>> >> Now I remember why I didn't log the bug...I wanted to repro it to >>> >> understand the sequence in more detail. >>> >> >>> >> Sounds like you have it nailed down, though (you have reproduced this >>> and >>> >> understand when it doesn't work). >>> >> >>> >> >>> >> On Thu, Jan 9, 2014 at 10:53 PM, Mike Tutkowski < >>> >> mike.tutkow...@solidfire.com> wrote: >>> >> >>> >>> Now that you mention it, I think CS does get confused about this. I may >>> >>> have seen this last week. >>> >>> >>> >>> The way it works (depending on if you're using an ISO or a template), >>> CS >>> >>> acts in a non-intuitive way. In one case (I can't remember if this is >>> for >>> >>> ISOs or templates), you pick a Compute Offering and a Disk Offering, >>> but >>> >>> the Compute Offering is really only used for non-storage parameters >>> whereas >>> >>> the Disk Offering is used to determine how large to make the disk, >>> etc. If >>> >>> the storage tags are the same (for the CO and DO), it works; >>> otherwise, it >>> >>> doesn't. >>> >>> >>> >>> I believe I wrote a note to myself to log a bug for this. It appears >>> >>> you've stumbled upon it, though, already. >>> >>> >>> >>> >>> >>> On Thu, Jan 9, 2014 at 10:45 PM, Marcus Sorensen <shadow...@gmail.com >>> >wrote: >>> >>> >>> >>>> No, we have two primary storages, one tagged "foo", one tagged "bar". >>> >>>> We have two disk offerings implementing these. We can verify that data >>> >>>> disks deploy properly to both. Then we have a service offering with >>> >>>> storage tag "foo". We can deploy a VM with a data disk tagged "foo" >>> >>>> but not one named "bar". It's as if the deploy command sees a conflict >>> >>>> between storage tags. According to the logs it doesn't even find a >>> >>>> storage pool to try, but if we deploy the offering without a data disk >>> >>>> it works fine. >>> >>>> >>> >>>> I spent a little while this evening trying to unravel how the >>> >>>> allocators and deployment planner work, but really at this point all I >>> >>>> have is the behavior, and it seems to indicate that one cannot deploy >>> >>>> a service offering with a data disk that has a non-matching tag. >>> >>>> >>> >>>> On Thu, Jan 9, 2014 at 10:19 PM, Nitin Mehta <nitin.me...@citrix.com> >>> >>>> wrote: >>> >>>> > In addition, do check if there are at least 1 PS for each of the >>> tags >>> >>>> in >>> >>>> > the same cluster. >>> >>>> > Pasting the snippet of logs with failure would help. (But do paste >>> the >>> >>>> > entire snippet for vm deployment) >>> >>>> > >>> >>>> > >>> >>>> > On 09/01/14 8:14 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com >>> > >>> >>>> wrote: >>> >>>> > >>> >>>> >>Are you saying there was no primary storage tagged "bar"? >>> >>>> >> >>> >>>> >>If that is the case, I guess I would expect the deployment of the >>> VM to >>> >>>> >>fail because not all of the criteria could be met. >>> >>>> >> >>> >>>> >> >>> >>>> >>On Thu, Jan 9, 2014 at 7:08 PM, Marcus Sorensen < >>> shadow...@gmail.com> >>> >>>> >>wrote: >>> >>>> >> >>> >>>> >>> Is this a bug (perhaps fixed), or expected behavior? >>> >>>> >>> >>> >>>> >>> If I create a service offering with storage tag=foo, and a disk >>> >>>> >>> offering with storage tag=bar, I cannot provide this disk >>> offering as >>> >>>> >>> a data disk to deploy along with this service offering. The root >>> >>>> >>> volume gets allocated, and then the data disk fails. >>> >>>> >>> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >>-- >>> >>>> >>*Mike Tutkowski* >>> >>>> >>*Senior CloudStack Developer, SolidFire Inc.* >>> >>>> >>e: mike.tutkow...@solidfire.com >>> >>>> >>o: 303.746.7302 >>> >>>> >>Advancing the way the world uses the >>> >>>> >>cloud<http://solidfire.com/solution/overview/?video=play> >>> >>>> >>* * >>> >>>> > >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> *Mike Tutkowski* >>> >>> *Senior CloudStack Developer, SolidFire Inc.* >>> >>> e: mike.tutkow...@solidfire.com >>> >>> o: 303.746.7302 >>> >>> Advancing the way the world uses the cloud< >>> http://solidfire.com/solution/overview/?video=play> >>> >>> *™* >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> *Mike Tutkowski* >>> >> *Senior CloudStack Developer, SolidFire Inc.* >>> >> e: mike.tutkow...@solidfire.com >>> >> o: 303.746.7302 >>> >> Advancing the way the world uses the cloud< >>> http://solidfire.com/solution/overview/?video=play> >>> >> *™* >>> >> >>> > >>> > >>> > >>> > -- >>> > *Mike Tutkowski* >>> > *Senior CloudStack Developer, SolidFire Inc.* >>> > e: mike.tutkow...@solidfire.com >>> > o: 303.746.7302 >>> > Advancing the way the world uses the >>> > cloud<http://solidfire.com/solution/overview/?video=play> >>> > *™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *™*
