On 8/15/12 9:53 PM, "Chip Childers" <chip.child...@sungard.com> wrote:
>On Thu, Aug 16, 2012 at 12:24 AM, Kelven Yang <kelven.y...@citrix.com> >wrote: >>>The only hesitation that I have is around ease of installation /> >>>configuration. CloudStack is great at this today (one of the reasons >>>that my company gravitated to it), and I don't want to lose that >>>value. I don't think this is a blocker to distributing the system at >>>all, but it will be a critical design and implementation detail to >>>consider. >> >> Yes, we should not sacrifice too much to lose the ease of installation, >> one of the most attractive property of CloudStack. the problem may be >> improved by having component-provisioning service in CloudStack core >> component that helps installation and auto configuration of other >> components > >Agreed. I just wanted to be sure we were thinking about it! > >>>How do you see this matching up with Murali's Event notification >>>framework proposal? It seems to me, that switching to a distributed >>>model requires a shift in his thinking on the actual event framework >>>itself. >> >> Murali's event notification assumes reliable event service requires by >>the >> semantics from business logic. It basically converts synchronized >>listener >> callback pattern into a disconnected implementation fashion. >> >> The messaging event I mentioned in the proposal has more semantics >>towards >> signaling process, it does not have a strong semantics to require a >> reliable event notification mechanism. >> > >I think I follow you, but my point is that I like Murali's proposal >quite a bit. Except in this context it needs to change to account for >the proposed distribution of processes that may contain potential >event sources and listeners. Isn't this an opportunity to use a >common messaging approach, expecting syntactic differences between the >use cases? I think the goals of the two proposals are complementary. >Elements of the proposed implementation approaches are what need to be >adjusted. For an event framework solution, the key question we need to answer is what matters the most for a distributed environment. As it glues all components within the environment, it auto scales components, we need it to be scalable, highly available and very lightweight so that the bindings required for a component to enroll into the distributed environment is very minimal, it should support uni-cast and multi-cast of event notification. I personally don't have a strong opinion yet, would love to hear more from the community on this. > >> >>>Over time, and depending on the implementation details, we may also >>>find a need for a distributed locking mechanism. >> >> This is why I mentioned about ZooKeeper. Yes, we need such service >> >> Kelven >> >> >> >> >> On 8/15/12 5:25 PM, "Chip Childers" <chip.child...@sungard.com> wrote: >> >>>On Wed, Aug 15, 2012 at 2:04 AM, Kelven Yang <kelven.y...@citrix.com> >>>wrote: >>>> I know everyone is recently busy and excited for the first Apache >>>>release >>>> of CloudStack, hopefully we still have some bandwidth for discussions >>>> about architecture fine-tunes, here is one for discussion. >>>> >>>> Conceptually, current CloudStack works very much like an JaveEE >>>> application server container, given the scale of all our current cloud >>>> deployments with CloudStack, I think CloudStack has done a great job. >>>> >>>> Running as an application server container, it brings us a lot of >>>>benefits >>>> like easy to deploy, efficient resource utilization, etc, but in the >>>>mean >>>> time, as modules inside a container are too easy to be involved >>>>tightly, >>>> over time, as we add more and more features, the complexity of overall >>>> system increases dramatically. Moving forward, it makes a lot of sense >>>>to >>>> reshape CloudStack from a module container to be a component oriented >>>> distributed platform. >>> >>>+1 - I completely agree with the idea of evolving to a more >>>distributed architecture for the system. >>> >>>Another plus to making it more distributed (and the devil is in the >>>details of the IPC mechanisms) is that third party developers would be >>>able to build plugins that may not be acceptable within the project >>>itself. Obviously, I'd love if we keep everything in the ASF >>>codebase... but it does open up opportunity for a larger ecosystem. >>> >>>The only hesitation that I have is around ease of installation / >>>configuration. CloudStack is great at this today (one of the reasons >>>that my company gravitated to it), and I don't want to lose that >>>value. I don't think this is a blocker to distributing the system at >>>all, but it will be a critical design and implementation detail to >>>consider. >>> >>>> Component >>>> Component is an independent deployment unit in a distributed >>>> environment(i.e., CloudStack), it usually runs as a separated process, >>>>can >>>> be independently scaled and has independent communication endpoint. It >>>> should have simple bindings to the distributed environment instead of >>>> requiring a complex container, to communicate with other components in >>>>the >>>> system, it should use bi-directional principal for loose-coupling and >>>> service-oriented, which is, using light-weight messaging event >>>> notification in one direction and service-oriented interaction at >>>>another >>>> direction. >>>> >>>> Module >>>> Module is a logic software unit that encapsulates software functions >>>>with >>>> well defined programming interface, a component contains one or more >>>> software modules >>>> >>>> Component Service >>>> Software service that is provided at component level, usually in shape >>>>of >>>> web service or REST-ful service >>>> >>>> Messaging >>>> A process for components to notify each other by exchanging messaging >>>> events >>>> >>>> Messaging event >>>> A package of information that is uni-casted or broadcasted to the >>>> destination component(s) >>> >>>How do you see this matching up with Murali's Event notification >>>framework proposal? It seems to me, that switching to a distributed >>>model requires a shift in his thinking on the actual event framework >>>itself. >>> >>>> Service discovery >>>> A process for component to discover services and endpoint bindings >>>>within >>>> the environment, it could be either through a directory service >>>>provided >>>> at infrastructure level or through auto-discovery >>>> >>>> Under component oriented principal, at high level CloudStack core can >>>>be >>>> fine-tuned to a number of (not limited to) components >>>> >>>> API component >>>> Implements CloudStack API, it also initiates logic orchestration flows >>>> (i.e., deploy a VM) which will be notified and picked up in >>>>Orchestration >>>> engine component >>>> >>>> Orchestration Engine component >>>> This components is the heart to drive all async-flows currently active >>>>in >>>> the system, it orchestrates high-level flow through messaging among >>>> networking/storage/compute components. >>>> >>>> Data service component >>>> This components provides the data service for objects within the >>>>Cloud. >>>> >>>> Networking component >>>> A component to implement networking provisioning >>>> >>>> Storage Component >>>> A component to implement storage provisioning >>>> >>>> Compute Component >>>> A component to implement hypervisor VM provisioning >>>> >>>> Fabric Monitoring Component >>>> A component dedicated for monitoring on fabric resources, for example, >>>> monitoring of hypervisor host status >>>> >>>> Fabric Admin Component >>>> A component that implements fabric resource administration. >>>> >>>> Service Framework Component (module?) >>>> A component(or a module inside Orchestration Engine?) to provide >>>>service >>>> to launch component service in a VM and auto-scale the component >>>>service. >>>> >>>> At middleware level, we will need a messaging event delivery platform >>>>and >>>> middleware level synchronization system, possible candidates could be >>>> Redis and Apache ZooKeeper. >>>> >>> >>>Over time, and depending on the implementation details, we may also >>>find a need for a distributed locking mechanism. Some resources that >>>are being orchestrated have limits to the number of concurrent >>>connections / tasks / whatever. That's a logical resource that needs >>>it's consumption / use tracked at runtime. Example: the VMware API >>>has a concurrent connection limit, and several task type are limited >>>in the total number per host or per cluster. I've learned the hard >>>way that trusting Virtual Center to deal with that contention is a >>>risky design decision. I'm sure there are plenty of other similar >>>situations. >>> >>>-chip >> >>
