cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Wilson <steve.wil...@citrix.com>
Subject Re: CloudStack.next
Date Mon, 18 Nov 2013 00:44:28 GMT
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 <bhaisaab@apache.org> wrote:

> Hi,
> 
> On Wed, Nov 13, 2013 at 5:11 AM, Steve Wilson <steve.wilson@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
>> 


Mime
View raw message