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