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. Thoughts? -chip On Fri, Nov 9, 2012 at 1:59 PM, David Nalley <da...@gnsa.us> wrote: > Agreed > > On Fri, Nov 9, 2012 at 1:58 PM, Alex Huang <alex.hu...@citrix.com> wrote: >> If you want to control this, wouldn't you orchestrate above CloudStack? Why >> put it into CloudStack? >> >> --Alex >> >>> -----Original Message----- >>> From: David Nalley [mailto:da...@gnsa.us] >>> Sent: Friday, November 09, 2012 10:48 AM >>> To: cloudstack-us...@incubator.apache.org >>> 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 <wuzhiqing1...@gmail.com> >>> 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 >
