I don¹t think this behavior changed ever. The reason for the hard check should be as follows
Imagine the tag is for premium offering and the customer is paying premium for that. Now he says deploy vm with this offering and say there is no host with premium tag left to deploy the vm. Now if we don't fail the deployment and instead accommodate it in a different host other than premium it would be breaking customer promise and he would still be paying premium which is not good. Thanks, -Nitin On 14/03/13 11:55 AM, "David Nalley" <da...@gnsa.us> wrote: >On Thu, Mar 14, 2013 at 2:20 AM, David Nalley <da...@gnsa.us> wrote: >> On Thu, Mar 14, 2013 at 2:18 AM, Koushik Das <koushik....@citrix.com> >>wrote: >>> See inline >>> >>>> -----Original Message----- >>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >>>> Sent: Thursday, March 14, 2013 11:30 AM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Local versus Shared Storage Type for Compute Offering >>>> >>>> Hi, >>>> >>>> I was a little surprised to see the Storage Type field when creating >>>>a Compute >>>> Offering recently. >>>> >>>> The options are Local or Shared. >>>> >>>> I guess I was thinking that if you had a preference for a VM running >>>>on local >>>> storage of the hypervisor or using shared storage that you would >>>>specify this >>>> using the Storage Tags field. >>>> >>> >>> Storage type in compute offering is for root disk of VM (whether needs >>>to be created on local storage or shared). Based on this validation are >>>also made as to what all operations are permitted on the VM, disks. >>> Storage tags are only used for placements when there are multiple >>>options available for either local or shared storage. >>> >>>> Can someone explain this a bit to me? What if you said Local for the >>>>Storage >>>> Type, but put in a single Storage Tag that was only associated with >>>>shared >>>> storage? >>>> >>> >>> In this case deployment should fail >>> >> >> Has something changed recently with how we treat tags? As of 3.0.x we >> would disregard the tag if we couldn't deploy to the tagged resource. >> (/me goes to try this in 4.0.x) >> >> --David > >Koushik, > >You are correct. I wonder when this changed. > >--David
