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
 radhika.puthiyetath@citrix.com designates 103.14.252.240 as permitted sender)
From: Radhika Puthiyetath <radhika.puthiyetath@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: CloudStack.next
Thread-Topic: CloudStack.next
Thread-Index: AQHO4ACu8YNUoPWt7UmR1V2e4zOyEpohxb8AgAAe+gCAAzfdAIAAtXmAgASbzxA=
Date: Mon, 18 Nov 2013 04:32:47 +0000
Message-ID: 
 <FBC4853C6AD64943857DB9EDF30AF8E106558FD5@SINPEX01CL01.citrite.net>
References: <CEAAD193.32C1B%chiradeep.vittal@citrix.com>
 <18929333-25F7-4256-A919-2C14E7BA85E4@gmail.com>
In-Reply-To: <18929333-25F7-4256-A919-2C14E7BA85E4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+ 1 to process improvements and ecosystems (advertising CloudStack, reachin=
g out to the student community, which I always stand for)

-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]=20
Sent: Friday, November 15, 2013 7:38 PM
To: dev@cloudstack.apache.org
Subject: Re: CloudStack.next

Hi, this is a bit of a brain dump:

I tend to see different types of buckets:

1-Processes
Involves getting better as a community in terms of release, bug fixing, com=
mitting code, documentation and user support. Some of these have already be=
en discussed partially but we need to come to consensus and act.
For example:
-we should have no unanswered questions on the lists. Anyway to have an off=
icial volunteer support team ? With a 24/7 twilio number on the site that r=
ings up someone out there :) ?
-we should catch up on bug fixing (and great job on 4.2.1 btw) -when we com=
mit we cannot break master, and I also would argue for committing docs when=
 it's a new feature, right now master is a catch all, instead of a super st=
able, high quality branch.
-we need much better docs
-we need to define standards for releases: RN, changes file, upgrade paths,=
 testing etc.
-our testing infra needs to get much better, continuous testing for all bra=
nches, testing on commits etc...maybe we should find a way to get help from=
 cloudbees to get us on the right tracks. Overall we need to be able to rel=
ease at any instant with confidence.
-no feature should be un-documented and/or un-tested. for instance: there w=
as a recent complaint about lack of F5 documentation, and right now I have =
no clue who is testing the F5 integration.

2-Ecosystem
We need to build up the ecosystem around cloudstack and advertize it.
We integrate with almost everything out there, yet people don't know it. I =
wish that:
2.1 we would improve on support in existing software: all configuration mgt=
 systems, main cloud libraries, PaaS etc...
2.2 work with everyone in that ecosystem to advertize and demo CloudStack i=
ntegration
2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mes=
os, Spark, OpenDaylight controller) some of it is just a matter of writing =
a tutorial, some of it there is actual coding involved.
2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we=
 need to catch with euca and integrate with netflixOSS software. Bring EMR,=
 ELB, CloudWatch etc...I have plans to work on this and hopefully propose a=
 standalone AWS-ACS bridge with extended services.

3-Code (caveat, I am not a java developer) I still would love to see a lot =
of cleanup and review. For example I believe the KVM agent uses some python=
 scripts in cloud-cli, those don't use Marvin. We should try to consolidate=
 these. There is code in the tree that is unused, we should clean it up. In=
 the UI when you add a cluster we still list 'OVM' yet it's broken, we need=
 to clean. OStypes in image creation, we need to clean up...
Packaging and mavenization, we should finish that up and really make it sup=
er strong. We need to call out to maven and package experts for a hand.
We had a small thread on KVM agent and we will have a talk at the hackathon=
, here I will pick on Xen:
We need much better support for Xen_Project without using xapi (the xapi in=
stall on XP is a pain), without xapi we could easily have ARM / Ceph suppor=
t... Overall I would like to see a strong core emerge with clean code separ=
ation with UI, DB abstraction,  backend drivers and plugins. ( A bit pie in=
 the sky, but a non java guy should be able to keep the core and replace/ad=
d any other component, plug and play) Biggest item is probably a software a=
rchitecture blueprint, right now we don't have that. No UML diagram, no seq=
uence diagram, most people don't know how cloudstack actually works.

-seb (I will invest time on the ecosystem bucket)

On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal <Chiradeep.Vittal@citrix.com=
> wrote:

> +1 to IAM.
>=20
> An Autoscale service independent of Netscaler.
> I'd like to see the built-in GRE controller fully fleshed out as a=20
> distributed/cross-AZ virtual network provider. Make it the=20
> out-of-the-box virtual network provider instead of VLAN.
> Easier service vm insertion into virtual networks.
> Better fidelity with AWS VPC APIs
>=20
>=20
>=20
>=20
> On 11/12/13 6:09 PM, "Simon Murphy" <simon.Murphy@vifx.co.nz> wrote:
>=20
>> As a CloudStack user, here are the ares that I feel need attention:
>>=20
>> - improved IAM and implementation of a full RBAC security model. This=20
>> is hurting us right now.
>> - improved VM import functionality (ie bulk import of VM's and import=20
>> of running VM's from existing vSphere clusters)
>> - improved backup functionality and integration with 3rd party tools
>> - HA for VPC routers
>>=20
>> Cheers,
>> Simon Murphy
>> Solutions Architect
>>=20
>> ViFX | Cloud Infrastructure
>> Level 7, 57 Fort Street, Auckland, New Zealand 1010 PO Box 106700,=20
>> Auckland, New Zealand 1143 M +64 21 285 4519 | S simon_a_murphy=20
>> www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter=20
>> <https://twitter.com/ViFX> Auckland | Wellington | Christchurch
>>=20
>>=20
>>=20
>> experience. expertise. execution.
>>=20
>> This email and any files transmitted with it are confidential,=20
>> without prejudice and may contain information that is subject to legal p=
rivilege.
>> It is intended solely for the use of the individual/s to whom it is=20
>> addressed in accordance with the provisions of the Privacy Act=20
>> (1993). The content contained in this email does not, necessarily,=20
>> reflect the official policy position of ViFX nor does ViFX have any=20
>> responsibility for any alterations to the contents of this email that=20
>> may occur following transmission. If you are not the addressee it may=20
>> be unlawful for you to read, copy, distribute, disclose or otherwise=20
>> use the information contained within this email. If you are not the=20
>> intended recipient, please notify the sender prior to deleting this emai=
l message from your system.
>> Please note ViFX reserves the right to monitor, from time to time,=20
>> the communications sent to and from its email network.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 13/11/13 1:18 PM, "David Nalley" <david@gnsa.us> wrote:
>>=20
>>> On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson=20
>>> <steve.wilson@citrix.com>
>>> wrote:
>>>> Hi All,
>>>>=20
>>>> As we ramp towards freeze on 4.3 and start talking about 4.4, I=20
>>>> thought it would be fun to queue up a discussion here on the list=20
>>>> before Collab next week.
>>>>=20
>>>> What do you envision in the next MAJOR release of CloudStack?  Call=20
>>>> it
>>>> 5.0 or whatever you like, but what would you like to see there? =20
>>>> What would you change?  What would you enhance?  Are there big bets=20
>>>> we should be placing as a community?
>>>>=20
>>>> Feel free to post any thoughts here and I'll look forward to=20
>>>> talking to many of you in person at Collab next week.  You are=20
>>>> coming to Collab, right?
>>>>=20
>>>=20
>>>=20
>>> Hi Steve,
>>>=20
>>> I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)=20
>>> coming in at least the next 12-18 months. Breaking API compatibility=20
>>> is a BIG DEAL IMO and should be done very deliberately and with a=20
>>> lot of consideration, and a plan around how we help folks adapt.
>>>=20
>>> Think about the tons of integrations that we have now: Chef, Puppet,=20
>>> Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that=20
>>> directly disrupts our users who stand a good chance of using one of=20
>>> those integrations or consume CloudStack via one of those tools.
>>>=20
>>> --David
>>=20
>=20