Hi, On Wed, Nov 13, 2013 at 5:11 AM, Steve Wilson <steve.wil...@citrix.com>wrote:
> Hi All, > > As we ramp towards freeze on 4.3 and start talking about 4.4, I thought it > would be fun to queue up a discussion here on the list before Collab next > week. > > What do you envision in the next MAJOR release of CloudStack? Call it 5.0 > or whatever you like, but If we're not changing/breaking APIs and since we had adopted semantic versioning, we should not change the major version. > what would you like to see there? What would you change? Few things I'm personally looking forward to is to have CloudStack have better abilities and ease for controlling containers (lxc using docker or what have you) and a being able to act as a container coordinator between baremetal/virtual machines. I guess this is not a new request and we know ACS already supports LXC but I would like to use ACS as a tool that works for me to configure, deploy and manage containers using docker. In essence, we can have something like a recipe, a DSL or infra-management-as-code to automate infrastructure at a higher level just like we use Puppet or Chef, we could have something for our infrastructure that just works. What would you enhance? Probably next iteration of cloudmonkey and add tests (in my free time). > Are there big bets we should be placing as a community? > There is a lot of architectural debt that CloudStack is paying for, maybe we could introduce and implement cloud engine, new api services and the other next gen stuff that we had discussed in that past; I would like to contribute if that happens. The cluster management service and the way agents and ACS mgmt server communicate can be improved, things like Raft could be implemented as our consensus problem is not solved (in case of network/io issue, the agents and ACS mgmt server may have different view of the world, for example). The codebase is monstrous, we can maybe bet of splitting every part as a plugin and maybe move some code to other languages that are interoperable and run on JVM like Scala. One motivation for this is the fact that a lot of infrastructure code in the last one year has been written in Scala which works perfectly with existing Java based ecosystem. Since I've some experience of Scala and ACS's API layer, web services, plugin system, ACS's ORM and build system I can think refactoring and rewriting stuff in Scala would greatly reduce a lot of code while it would be still interoperable with the rest of the components. If you think about ACS from a top level bird's eye view, ACS is a big resource consuming poorly written web app that takes in some request, spits answers for read queries (sync commands) or enqueues in its job queue (async jobs) and stores information what it knows about (from MySQL) and/or cache (in/via DAOs). There are a lot of moving parts and SPOFs. If all these components could be a ran as a separate service which could run on different or same server, they could be cleanly separated and they can become more testable, easier to understand, enhance and develop. Just my views :) Regards. > > Feel free to post any thoughts here and I'll look forward to talking to > many of you in person at Collab next week. You are coming to Collab, right? > > -Steve > > Steve Wilson > VP, Cloud Engineering > Citrix > twitter: @virtualsteve >
