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