square-cloudmonkey.pngThe community is busy working on 4.2.0, and there's much to be done before the release is ready. This week, we're taking a look at some of the interesting discussions going on in the the community about the next generation of Apache CloudStack, and functionality we can provide, as well as procedural changes that everyone should be aware of.

News Moving to Wednesdays

To help get information out a little more timely to key discussions and information that is going on in the community we are going to move the publishing of the weekly news to Wednesdays, starting with this issue on July 10th! If you'd like to help put the news together, please sign up for the marketing@cloudstack.apache.org mailing list and ask how you can get involved!

Major Discussions

In this section we look at major discussions that have happened on the CloudStack mailing lists. This is by no means a full summary of all discussions on the lists, but we try to hit the highlights that are relevant to the larger CloudStack community.

4.2 Status Update

Animesh Chaturvedi is tracking the current status of the release. Testing, bug fix work, and documentation should be targeted to complete by code freeze on 7/28. Release is still on schedule to release by 8/19.

We are now just 3 weeks from ACS 4.2 code freeze on 7/29. We have around 400 open defects with 100+ blockers and critical and I expect another 200 new defects to come in. As a community we have been fixing roughly 100 defects per week, in order to clear up our backlog I request you to help out on aggressively fixing the issues. The unassigned issue list is available at http://s.apache.org/BlH/. When you fix a bug in 4.2 please make sure it is also fixed in master.

Given the debate on system template changes in last few days of 4.1 requiring big testing effort and potential regression, I would like to see that as community we lock down system templates for 4.2 pretty soon. If any changes are needed we should call it out now and get them resolved.

As for bugs here is a summary for this week:

Bugs This Week       Last Week      
  Blocker Critical Major Total Blocker Critical Major Total
Incoming 8 10 28 50 11 34 24 72
Outgoing 26 23 34 86 26 30 40 100
Open Unassigned 7 49 129 222 6 49 119 184
Open Total 25 84 232 403 25 80 218 385

The status for features or improvement is depicted in table below

New Features / Improvements Today Last Week
Closed 10 10
Resolved 59 57
In Progress 11 13
Reopened 1 1
Ready To Review 1 1
Open 20 20
Total 102 102
Swift Support in 4.2

On July 3rd, Edison Su reported that support for Swift is broken due to the object store refactor. There's been a fair amount of discussion on how an extant feature could be broken without being exposed via testing, and what should be done about it at this stage.

David Nalley says that "unplanned/unannounced deprecation of a feature is a blocker IMO. It engenders a bad relationship with our users, and strands them on previous versions with no good migration/upgrade path." Chip Childers says that "I believe that this was an honest mistake, but we need to figure out what to do. I'm -1 on us saying 'we'll drop Swift support'. If necessary, I'd say that we need to roll back the object-store branch merge... I don't want to see that happen, though. That's why I'm asking about the effort to fix it."

Chip opened CLOUDSTACK-3400 as a blocker against 4.2 until Swift support is fixed. Discussion about the bug continues.

Closing 4.2 Resolved Defects

Sudha Ponnaganti posted a list of 543 defects that are in resolved state that need to re-validated, reopened or closed. Please look through this list and check to see if you're assigned to any of these defects.

There are 543 defects in Resolved state and not closed. Please make sure that you validate and close the defect if you are satisfied with the fix. If there are issues with the fix, pl reopen the defect. Pl note that these need to be validated in 4.2 branch as all are fixed in 4.2 ( should be applicable for master as well). You can prioritize these based on the blocker, critical, major etc. As team is already done with the features, this is good time to close these...

Coding Convention Reminder

As open source projects mature and add new participants, it's occasionally necessary to send a gentle reminder of accepted conventions in the community. For example, Alex Huang opened a discussion about the CloudStack coding conventions on July 2nd, saying "Our coding conventions have been going all over the place recently. Please take a look."

He also proposed extending the 120 column limit to 180 columns.

I recently was reading the following code. If it followed even our current coding conventions, this would have been 11 lines but it ends up to be 23 lines,

more than doubled. The whole file was like this. Just thinking about all the extra scrolling I have to do makes my cts act up. We are in the 21st century

and using wide screen lcd monitors. Let's not format our code to fit 80 column amber text screens please!

What's worse is I've found that some people are actively breaking existing source code to 80 columns, causing a bunch of unnecessary merge activities.

For those folks who use Eclipse Alex has checked in his Eclipse profile to tools/eclipse/eclipse.epf. It will help with a number of issues, such as removing trailing white space, reformats edited portions of the file using the current formatting rules, and more.

Changing Bug Severity

Prasanna Santhanam noted that some bugs have changed severity without any reason given. Any time a change of this sort of significance is made in Jira, some reason should be given so that other users can have some idea why the change was made without having to track down the person responsible and ask.

Prasanna asks:

Can the bug reporters please mention the

reason as to how something :

a) blocks movement on the feature/installation/cloudstack in general

b) affects deployment and does not have workarounds via the API

c) troubleshooting done with respect to a and b.

Here's some light reading on how to have bugs resolved faster:

Chip replied:

+1 with an added "d)":

d) needs to be considered a release blocker for a legal, security or

trademark reason

Name space

Dharmesh Kakadia one of our Google Summer of Code participants has started a discussion on changing the future namespace convention for Apache CloudStack. The current namespace has been in place since the original Cloud.com implementation. As Dharmesh states, this is a big change, please join the discussion on how we can make this a successful switchover.

Since the cloudstack project has moved to ASF, the suggestion is to move from com.cloud packages to org.apache java packages.(https://issues.apache.org/jira/browse/CLOUDSTACK-212)

As you might be realize, this is pretty big change. And merging this changes with a continuously updating master is non-trivial. So, here is the planned strategy after discussion over IRC. I am starting this thread to inform and know everyone's opinions.

1. I will be pushing code with new packages on branch "namespacechanges" and will notify on this thread as each refactored module is pushed.

2. There will be a freeze on master branch commits for some time in which "namespacechanges" will be applied to master. I suggest the date to be 20th July.

3. All the branch-owner updates their branch for reflect new packages. It was suggested that branch owners can look into the "namespacechanges" branch as it grows and start doing the package changes early, although it depends on branch-owners.

In-Development Release Naming

While we are still hard at work at getting 4.2 out the ready and out to the world, John Burwell has proposed moving to release naming until a release has gotten to feature freeze and it can be judged on what the semantic version number change should be. There's been a lot of discussion on this topic. We would probably look to start this in the next release if it can come to a vote.

Since we have adopted Semantic Versioning [1], it seems odd that we designate a release version before the final set of enhancements/fixes has been identified. For example, the release proceeding 4.2 may contain no backwards compatible API changes to be 4.3. Conversely, we may decide during the development cycle, as a community, to accept a non-backwards compatible change which would bump the version to 5.0.0. As such, it is difficult to know in advance what the proper semantic version number will be at when the work is released. We run the risk of confusing our users if we start calling a pending release say 4.3.0, and accept a change mid-cycle that will bump it to 5.0.0. To address this potential issue, I proposed that we refer to releases by a codename until feature freeze when we understand the complete scope of change and can apply the correct semantic version number. I further propose we codename the release directly proceeding 4.2 "Gamma Rays" or "Gamma Rays Gonna Get Ya".

CloudStack Planet

What's going on in the CloudStack community? While all the discussion happens on the mailing lists, we also encourage members of the CloudStack community to share what they're working on their blogs. In this section, you'll find posts by Apache CloudStack community members and interesting news that's relevant to Apache CloudStack.

CloudStack European User Group Summary

The ShapeBlue blog has a summary of the most recent meeting, by Giles Sirett.

Apache Whirr and CloudStack for Big Data in the Clouds

Sebastien Goasguen has a tutorial on his blog about using Apache Whirr with CloudStack. "In this tutorial we introduce Apache Whirr, an application that can be used to define, provision and configure big data solutions on CloudStack based clouds. Whirr automatically starts instances in the cloud and boostrapps hadoop on them. It can also add packages such as Hive, Hbase and Yarn for map-reduce jobs."

In Case You're Not Already Sold on DevOps

Joe Brockmeier talks a bit about Gene Kim's keynote at the CloudStack Collaboration Conference, "Why Every Company Needs DevOps Now."

Hackathon Storage Group Puts Out Discussion and Proposal

John Burwell who led the storage discussion group during the CloudStack Collaboration Conference Hackathon put out the first group discussion on the future needs and a proposal on how to better define storage for future versions of CloudStack. Read the and participate in the discussion and weigh-in on the proposal.

Interview with The Cloudcast (.net)

Chip Childers and David Nalley sit down with Aaron Delp for the Cloudcast podcast. Be sure to give it a listen!

New Videos Coming Soon From Our Summer Video Project

Gregg Witkin and Jessica Tomechak are working together on videos this summer. Gregg hit the ground running by bringing his cameras to the Collab Conference June 24-25 in Santa Clara. He is editing that footage into short clips to help promote the November CloudStack Collaboration Conference in Amsterdam.

These short videos will be posted as soon as the conference organizers approve them. Meanwhile, check out these videos Gregg did with CloudStack just last year. Link 1, Link 2


New Committers and PMC Members

No new committers or PMC members have been announced in the last newsletter period.