Maybe we can leave implicit/explicit policy to planner(allocator). We can develop different types of planner and let user decide which one is he want
> -----Original Message----- > From: jayesh patel [mailto:jayesh.pa...@oracle.com] > Sent: Friday, May 04, 2012 2:29 PM > To: cloudstack-dev@incubator.apache.org > Cc: David Nalley > Subject: Re: [DISCUSS] Tags > > A configurable default tag might address the problem at hand. The default > tag can be changed by the admin to promote certain resources, if they are in > abundance. > > -- Jayesh > On 5/4/2012 1:44 PM, David Nalley 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
