cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject [DISCUSS] Extending ACL controls to include more than just a user / account / domain / role RBAC model [WAS] Re: Mail to the administrator when a user want to create a instance
Date Mon, 12 Nov 2012 19:29:03 GMT
Moving this over to the dev list for a bit more discussion.

I'm not sure I agree with David and Alex entirely here.  Certainly, as
a user today, orchestrating above ACS is the answer.  Long term, I'm
not so sure.  There's a very valid user concern at the root of the
request:  How can you add some level of change governance into the
core IaaS layer?

Some of this is philosophical, but I like the slides that I've seen
from Kevin on this topic.  CloudStack is in a position to support two
types of workloads:  cloud-ified (that's a technical term ;-) ) and
more traditional systems.  Certainly there is a good bit of industry
hoopla around telling all of the IT shops out there that they simply
need to change all of their apps to horizontally scale, design for
failure, etc...  And I'm a proponent of those design theories.
Unfortunately, there's a hard truth in IT...  changing the fundamental
design premise of existing systems isn't easy or affordable for the
overwhelming majority of IT departments.  That *truth* is exactly why
CloudStack's ability to support both types of workloads is important
in the long run.  Most of the capabilities are there, and I believe
that both use cases can live in harmony within the same project.

Now what to do about it?  I'm not certain yet.  I've been struggling
with this question for several months now.  I have a need to be able
to provide end customers with the ease of provisioning and change, *as
well as* a certain level of policy-based control around what and when
certain resources can be modified.  For me, change governance matters.
 We're already headed down the path of more granular RBAC functions,
but could we add additional vectors to that model?  Consider
traditional "change windows":  specific times when changes are allowed
within a traditional workload's environment are the norm for many IT
shops.  They are a process-based attempt at reducing the risk and
impact of poor change execution.  I don't particularly like them, but
I know why they exist.  Does time play a part in the act of
authorizing a change to an element?  If time plays a part, is there a
place for thinking of self service as including the ability to stage a
number of changes that get executed by the orchestration system at an
*appropriate* time?

I guess I could go out and get (or build) another software package
that sits on top of cloudstack, only exposing that software to the end
users.  But doesn't that over complicate the deployment and management
of the environment?  I'd end up having to provide a completely
different API layer to the users (removing any value in having the
EC2/S3 API embedded in CloudStack).  Why shouldn't an IaaS provider
(and specifically, the cloud orchestration stack) natively provide
users with self-service change governance capabilities that control
the who / when and how of the infrastructure automation?  Why can't we
take the orchestration platform in a direction that allows users to
trust it with precious and fragile workloads, which aren't capable (at
the app level) of handling the rapid change that more modern software
architecture supports?

Sorry I don't have much of a concrete proposal here, but this thread
triggered my desire to get the discussion going on *if* we want to
consider this complexity, and *if so* what are the user scenarios that
we would want to cover.



On Fri, Nov 9, 2012 at 1:59 PM, David Nalley <> wrote:
> Agreed
> On Fri, Nov 9, 2012 at 1:58 PM, Alex Huang <> wrote:
>> If you want to control this, wouldn't you orchestrate above CloudStack?  Why put
it into CloudStack?
>> --Alex
>>> -----Original Message-----
>>> From: David Nalley []
>>> Sent: Friday, November 09, 2012 10:48 AM
>>> To:
>>> Subject: Re: Mail to the administrator when a user want to create a instance
>>> On Sun, Nov 4, 2012 at 2:20 AM, zhiqing wu <>
>>> wrote:
>>> > Hi:
>>> > Mail to the administrator when a user want to create a instance ,how to
>>> > achieve this functionality.and which parameter need to modified ?
>>> >
>>> > best regards
>>> Doesn't exist at present.
>>> You can file an RFE for this functionality, though I'd personally
>>> think it's a bad idea. One of the core tenets of cloud computing is
>>> that an end-user is empowered to get things done - not that it becomes
>>> a portal for asking for permission.
>>> If you just want to be notified when a user a creates an instance, I
>>> suppose you could poll the event log periodically and have you
>>> monitoring/logging system fire alerts when a user deploys a new vm.
>>> --David

View raw message