On 11/12/12 11:29 AM, "Chip Childers" <[email protected]> wrote:
>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? The Time constraint is the easy one. There are similar more complex processes that include: - getting approvals, - updating change tickets, - temporary increases in limits - security policy (which ports can be opened) - authorizing policy exceptions, etc. > >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? True, but my worry is it an overreach? Can we architect it so that it is an integration layer? > >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 <[email protected]> wrote: >> Agreed >> >> On Fri, Nov 9, 2012 at 1:58 PM, Alex Huang <[email protected]> >>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:[email protected]] >>>> Sent: Friday, November 09, 2012 10:48 AM >>>> To: [email protected] >>>> 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 <[email protected]> >>>> 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 >>
