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