cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: deployVm with data disk
Date Fri, 10 Jan 2014 19:19:03 GMT
OK, thanks for logging it!


On Fri, Jan 10, 2014 at 11:51 AM, Marcus Sorensen <shadowsor@gmail.com>wrote:

> too late :-)
>
>
> On Fri, Jan 10, 2014 at 11:47 AM, Mike Tutkowski
> <mike.tutkowski@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 <shadowsor@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 <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>
> >> >>> *™*
> >>
> >
> >
> >
> > --
> > *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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message