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