Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Ahmad.Emneina@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Ahmad Emneina <Ahmad.Emneina@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 4 May 2012 21:31:13 -0700
Subject: RE: [DISCUSS] Tags
Thread-Topic: [DISCUSS] Tags
Thread-Index: Ac0qNtimBJVvvsKVSdS2kUpoVnp/KgAOhECAAAG/br0=
Message-ID: <g7n37lrq2ieybuuj2t8pwcwc.1336192120649@email.android.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_g7n37lrq2ieybuuj2t8pwcwc1336192120649emailandroidcom_"
MIME-Version: 1.0

--_000_g7n37lrq2ieybuuj2t8pwcwc1336192120649emailandroidcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

i'd love having a per compute/storage resource 'behavior' toggle would, tha=
t'd be cool and flexible. say i add storage to a cluster i can mark it 'tag=
 required', to not allow tagless offerings to deploy there.


Kevin Kluge wrote:
> The particular behavior in question is how we handle provisioning instanc=
es
> 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)

Did you discuss the case where a resource offers A,B but the requirement is=
 for only A?   Would that fail to match?

The current design is just that the offering tags are requirements (and an =
offering with no tags has no requirements).   That does force everything to=
 be tagged to get "negative" control, but it seems relatively easy to think=
 about.


--_000_g7n37lrq2ieybuuj2t8pwcwc1336192120649emailandroidcom_--