> Could you elaborate a bit on the new deployment plans (slides 19-21). It > seems that you are aiming for more independent zones and a more reliable > management layer, but I could not quite picture how you would actually > deploy this.
The storyboard for deployment will look like this. - Deploy CloudStack Cloud-Engine - Cloud-Engine only has API, a CLI, and a very minimalistic UI. You can registers zones, pods, clusters, hosts, etc, just like before with Cloud-Engine but Cloud-Engine expects that all setup to be done by you. You are registering these things to use by Cloud-Engine but Cloud-Engine doesn't know how to set it up. If you're doing setup this way, you are basically saying I can use something like chef to setup the physical resource. After registering all the appropriate pieces, you can launch VMs using the CLI talking to the API. - On the UI is the options to launch Cloud-Management, Cloud-API, Cloud-Access(ACL), Cloud-Console(console-proxy), and Cloud-Templates (SSVM). More can be added via the plugin mechanism. Upon launch, Cloud-Engine will detect if physical resources have been registered. If it has, then Cloud-Engine asks the admin if they want to launch this as a web app on the same server or as a webapp hosted by another VM. If no hardware resource has been registered, then the only option is to launch as a webapp on the same server. Once the service has been launched, it has to register back with Cloud-Engine in order for it to be used. - Upon launch Cloud-Management: Cloud-Management has the API, CLI, and current UI for OAMP purposes. It also supports a plugin mechanism that allows others to deploy helpful automation scripts. Once this is launched, then the user can use the normal UI approach to manage the system. Adding a host for example will be like before where Cloud-Management actually setups up the host with what's needed to run CloudStack and then registers host to Cloud-Engine for use. - Cloud-Management can probably be further dissected into three services: Service-provider management service that handles support for the service-provider functionalities such as setting up offerings and support for the end user, A system admin management service that handles true system OAMP, and finally a service that is a container for different automation. Currently the plan is to have it all in Cloud-Management. - Upon launch Cloud-Access: Cloud-Access contains the APIs for authentication, account access, and ACL. Launching this requires the admin to give it details on how to access the database. Cloud-Access database should be duplicated across zones. That can be done in various ways (for example, a single master with multiple readers deployment of mysql) but the important point here is that Cloud-Access is isolated from Cloud-Engine and its method of resilience is different. I suspect most will have it patch into their own db/ldap/ad backend which already have some other way to do resilience. Again Cloud-Access registers with Cloud-Engine for it to be used by other components. - Upon launching Cloud-API: Cloud-API contains API, CLI, and UI for the end user to use. Launching Cloud-API means providing it the Cloud-Engines it should plugin to. Cloud-API then connects to all the Cloud-Engines to gather the end user data and becomes the actual front-end. When Cloud-API says it is ready to be added into the API cluster, the admin adds it to the GSLB service. > > On the componentization: I think it's great, but will this result in separate > applications (like we AWSAPI now) ? and will these components still be > tightly integrated from a packaging installation point of view ? My concern > being that we should still aim for a "one-click" install of CloudStack versus > several recipe to integrate many different components. So it becomes several clicks rather than one click but you can see from above it should still be rather painless. I absolutely agree with you that we should not take away the ease of deployment feature of CloudStack today and we will strive to make that a better experience in fact. > > Last thing, which is really a software implementation choice, I was talking to > the Java User Group in Geneva and mentioned that the community was > looking at moving to the Spring framework, some folks were a little surprised, > suggesting that there was better frameworks that could be used. That's something being talked about in the OSGi and threads Kelven have started. Please let them know in those threads on what the suggestions are. --Alex
