cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: deployVm with data disk
Date Fri, 10 Jan 2014 17:33:24 GMT
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 <shadowsor@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 <shadowsor@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.tutkowski@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 <shadowsor@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.tutkowski@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.tutkowski@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.tutkowski@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 <shadowsor@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.Mehta@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.tutkowski@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
<
>>>> shadowsor@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>> *™*

Mime
View raw message