too late :-)
On Fri, Jan 10, 2014 at 11:47 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Yeah, I agree. I can log a bug for this later and include the contents of > this e-mail. > > > On Fri, Jan 10, 2014 at 10:33 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > >> This should be simple enough to fix by making sure the avoid object >> references pools matching the current tag, and only the current tag, >> every time. This means removing a matching pool from the avoid set if >> it exists in the current avoid set, after the state where all pools >> are set to avoid. >> >> On Fri, Jan 10, 2014 at 10:25 AM, Marcus Sorensen <shadow...@gmail.com> >> wrote: >> > 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> >> >>> *™* >> > > > > -- > *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> > *™*
