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> *™*
