+1 especially to CI process improvement. IMO, we need to improve the patch review process. Sometimes we encounter that the master branch is broken. Low quality commit slows down our developing and testing on the master branch. I think we should change the patch review process to check that a patch pass unit test before it is merged to the master.
There are Jenkins plugins that help pre-commit testing. They observe a patch submission, create a test branch that merges the master branch and the patch, run tests on the branch, and write back the result on the ReviewBoard or the Github PullRequest. https://wiki.jenkins-ci.org/display/JENKINS/Jenkins-Reviewbot (for ReviewBoard) https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin (for Github PullRequest) we need to consider these kind pre-commit auto testing tool adoption. > -our testing infra needs to get much better, continuous testing for all > branches, 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 > release at any instant with confidence. - Noji 2013/11/15 Sebastien Goasguen <run...@gmail.com>: > 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, > committing code, documentation and user support. Some of these have already > been 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 > official volunteer support team ? With a 24/7 twilio number on the site that > rings up someone out there :) ? > -we should catch up on bug fixing (and great job on 4.2.1 btw) > -when we commit 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 stable, 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 > branches, 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 > release at any instant with confidence. > -no feature should be un-documented and/or un-tested. for instance: there was > 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 > integration > 2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, > Mesos, 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 super > 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 > install on XP is a pain), without xapi we could easily have ARM / Ceph > support… > Overall I would like to see a strong core emerge with clean code separation > 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/add any > other component, plug and play) > Biggest item is probably a software architecture blueprint, right now we > don't have that. No UML diagram, no sequence 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.vit...@citrix.com> > wrote: > >> +1 to IAM. >> >> An Autoscale service independent of Netscaler. >> I'd like to see the built-in GRE controller fully fleshed out as a >> distributed/cross-AZ virtual network provider. Make it the out-of-the-box >> virtual network provider instead of VLAN. >> Easier service vm insertion into virtual networks. >> Better fidelity with AWS VPC APIs >> >> >> >> >> On 11/12/13 6:09 PM, "Simon Murphy" <simon.mur...@vifx.co.nz> wrote: >> >>> As a CloudStack user, here are the ares that I feel need attention: >>> >>> - improved IAM and implementation of a full RBAC security model. This is >>> hurting us right now. >>> - improved VM import functionality (ie bulk import of VM's and import of >>> running VM's from existing vSphere clusters) >>> - improved backup functionality and integration with 3rd party tools >>> - HA for VPC routers >>> >>> Cheers, >>> Simon Murphy >>> Solutions Architect >>> >>> ViFX | Cloud Infrastructure >>> Level 7, 57 Fort Street, Auckland, New Zealand 1010 >>> PO Box 106700, Auckland, New Zealand 1143 >>> M +64 21 285 4519 | S simon_a_murphy >>> www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter >>> <https://twitter.com/ViFX> >>> Auckland | Wellington | Christchurch >>> >>> >>> >>> experience. expertise. execution. >>> >>> This email and any files transmitted with it are confidential, without >>> prejudice and may contain information that is subject to legal privilege. >>> It is intended solely for the use of the individual/s to whom it is >>> addressed in accordance with the provisions of the Privacy Act (1993). The >>> content contained in this email does not, necessarily, reflect the >>> official policy position of ViFX nor does ViFX have any responsibility for >>> any alterations to the contents of this email that may occur following >>> transmission. If you are not the addressee it may be unlawful for you to >>> read, copy, distribute, disclose or otherwise use the information >>> contained within this email. If you are not the intended recipient, please >>> notify the sender prior to deleting this email message from your system. >>> Please note ViFX reserves the right to monitor, from time to time, the >>> communications sent to and from its email network. >>> >>> >>> >>> >>> >>> >>> On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote: >>> >>>> On Tue, Nov 12, 2013 at 6:41 PM, 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 what would you like to see there? What >>>>> would you change? What would you enhance? Are there big bets we should >>>>> be placing as a community? >>>>> >>>>> 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? >>>>> >>>> >>>> >>>> Hi Steve, >>>> >>>> I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes) >>>> coming in at least the next 12-18 months. Breaking API compatibility >>>> is a BIG DEAL IMO and should be done very deliberately and with a lot >>>> of consideration, and a plan around how we help folks adapt. >>>> >>>> Think about the tons of integrations that we have now: Chef, Puppet, >>>> Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly >>>> disrupts our users who stand a good chance of using one of those >>>> integrations or consume CloudStack via one of those tools. >>>> >>>> --David >>> >> >
