[DISCUSS] Tags

[David Nalley <da...@gnsa.us>]

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

Screen-resize support and console across reboot

[Kelven Yang <ke...@citrix.com>]

We replaced VNC engine in 3.0.1 release to work with Apache license policy, the replacement caused us to lose some features, screen-resize and console access across reboot are not supported in 3.0.1.

I checked in a fix today to add these two features back, it will be available in the coming release.

Kelven

RE: [DISCUSS] Tags

[Kevin Kluge <Ke...@citrix.com>]

> 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)

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.

Re: [DISCUSS] Tags

[Brett Adam <bp...@rpath.com>]

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

Re: [DISCUSS] Tags

[John Kinsella <jl...@stratosec.co>]

On May 4, 2012, at 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?


I think it'd help a lot if some verification of the tags happened the UI - currently (at least my exp) any value can be entered for a tag, and it's not really clear if it's used or not. Seems like something that should fail up front, not after an attempt to provision. Or maybe not verification, but autocomplete? Something so it doesn't feel like one's typing in the dark...

John

RE: [DISCUSS] Tags

[Frank Zhang <Fr...@citrix.com>]

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.patel@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

Re: [DISCUSS] Tags

[jayesh patel <ja...@oracle.com>]

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