The CloudStack community is moving fast, and once we get through the ASF requirements to release 4.0, we'll be digging into some significant changes to the core architecture of the system.
These conversations are just getting started, but here are some interesting tidbits from the development mailing list:
CloudStack 3.x has quite a bit of baggage after years of development. This makes it difficult for new committers to join the project. Even for existing committers, it is easy to make mistakes. We're looking to make some fundamental changes to CloudStack to overcome these problems. Please feel free to comment.
- No clear separation between orchestration and the subsystems being orchestrated. We've done a lot of work in this area in networking. However, storage and hypervisor are still missing.
- No clear separation between orchestration and the ACL system.
- No clear separation between orchestration and the extra services (read SSVM, console proxy VM)
- CloudStack believes it is the master of all physical resources when it is not.
- Form a core orchestration engine that is free of unnecessary artifacts such as ACL.
- Clear definition of functionalities and how to contribute to different parts of CloudStack.
- Allow developers to write and deploy services on the CloudStack orchestration server.
Moving forward, it makes a lot of sense to reshape CloudStack from a module container to be a component oriented distributed platform.
Sheng Liang, CTO Cloud Platforms at Citrix (and cloud.com founder) also recently shared his vision for the CloudStack architecural future:
Interested in getting involved? Join us on the email@example.com mailing list. Instructions for how to subscribe are here: http://cloudstack.org/discuss/mailing-lists.html