Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of steve.wilson@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Steve Wilson <steve.wilson@citrix.com>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Subject: Re: CloudStack.next
Thread-Topic: CloudStack.next
Thread-Index: AQHO4ACu8YNUoPWt7UmR1V2e4zOyEpoqQvoAgABxygA=
Date: Mon, 18 Nov 2013 00:44:28 +0000
Message-ID: <2450F8F7-3F14-49C2-BE1F-B3E079FB94E1@citrix.com>
References: <CEA7FCA8.3BAB%steve.wilson@citrix.com>
 <CANLSSBXtFRiSmNVu5H+h=qhMF4Vsu-WDjAOdjtyhe1-yk=E2AA@mail.gmail.com>
In-Reply-To: 
 <CANLSSBXtFRiSmNVu5H+h=qhMF4Vsu-WDjAOdjtyhe1-yk=E2AA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <63DA1AEF5EDFD9448A374F3A6563B7EB@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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,
>=20
> On Wed, Nov 13, 2013 at 5:11 AM, Steve Wilson <steve.wilson@citrix.com>wr=
ote:
>=20
>> Hi All,
>>=20
>> 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 nex=
t
>> week.
>>=20
>> What do you envision in the next MAJOR release of CloudStack?  Call it 5=
.0
>> or whatever you like, but
>=20
>=20
> If we're not changing/breaking APIs and since we had adopted semantic
> versioning, we should not change the major version.
>=20
>=20
>> what would you like to see there?  What would you change?
>=20
>=20
> 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 essenc=
e,
> 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.
>=20
> What would you enhance?
>=20
>=20
> Probably next iteration of cloudmonkey and add tests (in my free time).
>=20
>=20
>> Are there big bets we should be placing as a community?
>>=20
>=20
> 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.
>=20
> 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).
>=20
> 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 whi=
ch
> 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.
>=20
> 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, spi=
ts
> 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.
>=20
> Just my views :)
>=20
> Regards.
>=20
>=20
>=20
>>=20
>> 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, ri=
ght?
>>=20
>> -Steve
>>=20
>> Steve Wilson
>> VP, Cloud Engineering
>> Citrix
>> twitter: @virtualsteve
>>=20