cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: CloudStack.next
Date Sun, 17 Nov 2013 17:57:10 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message