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