Lots of interesting ideas there. Thanks for sharing! BTW, I really share your interest in making CloudStack and Docker work really well together.
On Nov 17, 2013, at 9:57 AM, Rohit Yadav <bhais...@apache.org> wrote: > 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 >>
