OK, thanks for logging it!
On Fri, Jan 10, 2014 at 11:51 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > 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> > > *™* > -- *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> *™*
