David Explicit matching sounds like the right policy to me. However, if a clear use case that requires the "promiscuous" mode can be made, is there significant cost to allowing an admin level option to make it a policy preference?
A further thought involves the "least surprise" question: multiple tags could lead to complex placement outcomes. Warning admin users when they inadvertently create undeployable configurations might make sense to offset the default mode being "strict" Brett Sent from my iPhone On May 4, 2012, at 16:45, David Nalley <da...@gnsa.us> wrote: > I had brief discussion with some folks this afternoon around tags and > wanted to open that discussion up on the mailing list: > > Quick background: > CloudStack uses the concept of tags on resources so that when an > instance is provisioned if it has matching tags it will be provisioned > on the matching tagged resources. (e.g. you'd tag your SSD storage > with a 'really_really_fast' tag and if you provisioned the an instance > with a service offering that had a matching 'really_really_fast' tag > it would be provisioned onto the SSD storage. > > The particular behavior in question is how we handle provisioning > instances that don't have a matching tag. Today, you might not have > that 'really_really_fast' tag but your machine might still end up on > the 'really_really_fast'-tagged storage. (e.g. the tagged resources > aren't exclusively reserved for instances with matching tags) > > My initial POV was that instances that possessed non-matching tags > should be lower priority for the deployment, but that deployment > shouldn't fail merely because an or matching tagged or untagged > resource wasn't available. > > Alex however may have swayed me a bit - he advocated explicit > matching. Untagged deployments could only have untagged resources, > etc. And that any failure to provide enough resources results in a > failed deployment. > > Thoughts, comments, flames? > > --David
