You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Huang <Al...@citrix.com> on 2012/11/09 19:12:01 UTC
[RFC] Refactoring CloudStack
I sent out an email a couple of months ago about the need to refactor CloudStack into small pieces. At the time, the overall sentiment was the community is heavily invested in releasing 4.0 and this should be brought up post 4.0. Now that 4.0 has been released, I like to bring this up again. I created a powerpoint to illustrate that need. Please take a look at [1]
This work is related to Edison's Storage subsystem, Kelven's Spring, Murali's notification system proposals. The work is to be done in the javelin branch.
Please comment.
--Alex
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Refactoring
RE: [RFC] Refactoring CloudStack
Posted by Alex Huang <Al...@citrix.com>.
> This is a fantastic, multi-leveled proposal with lots of implications. I
> think that I'm going to keep my comments to the high-level intent of the
> document, and ask that we re-initiate discussions on the implementation
> details individually. In general, I'm highly supportive of this!
>
> Some specific questions from the slides:
>
> Slide 2 (Design Goals) - to me, the idea of "Allowing cloudstack components
> to be written in any language" has some significant implications on choice
> of framework and implementation design decisions for the refactoring work.
> Do you agree?
Absolutely. I do believe we will keep the core orchestration together in Java. There's several reasons for that. I believe orchestration is the key to provide a consistent platform for people to add services ontop of IaaS so we have to keep tight control of that. However, when orchestration requires provisioning of the actual hardware, it should be able to accommodate that provisioning being written in a separate language.
Even in the current version of CloudStack, that was the intent but it got muddled. All provisioning is expected to be carried out in ServerResource. The communication to those ServerResource is JSON but for various reasons none of the resources were written in a different language. I believe it has to do with
- We didn't specify the JSON specifically. It's just implied in the Java class serilization and deserialization.
- JSON is carried over a TCP connection which made other language have a difficult time maintaining that TCP connection and session.
- We didn't write KVM in python as an example of how it should work.
So the proposal to this is that each resource will be setup to accept RPC calls that are JSON based. There's no need to maintain the TCP connection.
This has multiple benefits. One of which is that the resource can be tested individually.
>
> Slide 10 - there is a mention of a Policy Monitoring Service - what is that?
Ignore it. I mean to say others can write these services as additions but it won't affect orchestration.
>
> Slide 10 - Is the box labeled CloudStack Orchestration Platform more
> correctly labeled Cloud Engine? If not, I think I'm not understanding the
> diagram. If so, then it makes sense to me.
That's correct. The diagram was from when I first proposed this. The names kept changing. I will change it.
>
> Slide 21 - The "Account database" is shown. Any thoughts in how would
> multi-region users be synced?
I've answered that in the other answer to Sebastian. Please see there.
--Alex
Re: [RFC] Refactoring CloudStack
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Nov 9, 2012 at 1:12 PM, Alex Huang <Al...@citrix.com> wrote:
> I sent out an email a couple of months ago about the need to refactor
> CloudStack into small pieces. At the time, the overall sentiment was the
> community is heavily invested in releasing 4.0 and this should be brought
> up post 4.0. Now that 4.0 has been released, I like to bring this up
> again. I created a powerpoint to illustrate that need. Please take a look
> at [1]
>
> This work is related to Edison's Storage subsystem, Kelven's Spring,
> Murali's notification system proposals. The work is to be done in the
> javelin branch.
>
> Please comment.
>
> --Alex
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Refactoring
>
>
>
Alex,
This is a fantastic, multi-leveled proposal with lots of implications. I
think that I'm going to keep my comments to the high-level intent of the
document, and ask that we re-initiate discussions on the implementation
details individually. In general, I'm highly supportive of this!
Some specific questions from the slides:
Slide 2 (Design Goals) - to me, the idea of "Allowing cloudstack components
to be written in any language" has some significant implications on choice
of framework and implementation design decisions for the refactoring work.
Do you agree?
Slide 10 - there is a mention of a Policy Monitoring Service - what is that?
Slide 10 - Is the box labeled CloudStack Orchestration Platform more
correctly labeled Cloud Engine? If not, I think I'm not understanding the
diagram. If so, then it makes sense to me.
Slide 21 - The "Account database" is shown. Any thoughts in how would
multi-region users be synced?
-chip
RE: [RFC] Refactoring CloudStack
Posted by Alex Huang <Al...@citrix.com>.
> 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
Re: [RFC] Refactoring CloudStack
Posted by Sebastien Goasguen <ru...@gmail.com>.
Alex,
I looked at the powerpoint.
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.
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.
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.
thanks,
-Sebastien
On Nov 12, 2012, at 9:32 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> Hi Alex,
>
> Just wanted to let you know that I'm going to take a good look at this.
>
> Wido
>
> On 11/09/2012 07:12 PM, Alex Huang wrote:
>> I sent out an email a couple of months ago about the need to refactor CloudStack into small pieces. At the time, the overall sentiment was the community is heavily invested in releasing 4.0 and this should be brought up post 4.0. Now that 4.0 has been released, I like to bring this up again. I created a powerpoint to illustrate that need. Please take a look at [1]
>>
>> This work is related to Edison's Storage subsystem, Kelven's Spring, Murali's notification system proposals. The work is to be done in the javelin branch.
>>
>> Please comment.
>>
>> --Alex
>>
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Refactoring
>>
Re: [RFC] Refactoring CloudStack
Posted by Wido den Hollander <wi...@widodh.nl>.
Hi Alex,
Just wanted to let you know that I'm going to take a good look at this.
Wido
On 11/09/2012 07:12 PM, Alex Huang wrote:
> I sent out an email a couple of months ago about the need to refactor CloudStack into small pieces. At the time, the overall sentiment was the community is heavily invested in releasing 4.0 and this should be brought up post 4.0. Now that 4.0 has been released, I like to bring this up again. I created a powerpoint to illustrate that need. Please take a look at [1]
>
> This work is related to Edison's Storage subsystem, Kelven's Spring, Murali's notification system proposals. The work is to be done in the javelin branch.
>
> Please comment.
>
> --Alex
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Refactoring
>
RE: [RFC] Refactoring CloudStack
Posted by Alex Huang <Al...@citrix.com>.
I have updated the page to include a pdf for those who don't have power point.
--Alex
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, November 09, 2012 10:12 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [RFC] Refactoring CloudStack
>
> I sent out an email a couple of months ago about the need to refactor
> CloudStack into small pieces. At the time, the overall sentiment was the
> community is heavily invested in releasing 4.0 and this should be brought up
> post 4.0. Now that 4.0 has been released, I like to bring this up again. I
> created a powerpoint to illustrate that need. Please take a look at [1]
>
> This work is related to Edison's Storage subsystem, Kelven's Spring, Murali's
> notification system proposals. The work is to be done in the javelin branch.
>
> Please comment.
>
> --Alex
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Refa
> ctoring