On 09/03/2014 11:37 AM, Joe Gordon wrote: > As you all know, there has recently been several very active discussions > around how to improve assorted aspects of our development process. One idea > that was brought up is to come up with a list of cycle goals/project > priorities for Kilo [0]. > > To that end, I would like to propose an exercise as discussed in the TC > meeting yesterday [1]: > Have anyone interested (especially TC members) come up with a list of > what they think the project wide Kilo cycle goals should be and post > them on this thread by end of day Wednesday, September 10th. After which > time we can begin discussing the results. > The goal of this exercise is to help us see if our individual world > views align with the greater community, and to get the ball rolling on a > larger discussion of where as a project we should be focusing more time.
In OpenStack, we have no shortage of interest and enthusiasm on all fronts, including development contributors, deployers, and cloud end users. When looking at project wide-priorities, we need to make sure our tools, processes, and resulting technology facilitate turning all of that interest into real value. We need to identify which areas have the most pain, and work to improve them. A lot of this is certainly about Kilo, but it's longer term, too. It's the way we should always be thinking about this. 1) Dev community We clearly have a lot of growing pains here. What's quite encouraging is that we also have a lot of hard work going into several different proposals to figure out ways to help. The largest projects (Nova and Neutron) are overwhelmed and approaching breaking points. We have to find ways to relieve this pressure. This may involve aggressively pursing project splits or other code review workflow changes. I think the problems and solutions here are project-wide issues, as solutions put in place tend to rapidly spread to the rest of OpenStack. This is an area I'm especially concerned about and eager to help look for solutions. We should evaluate all potential improvements against how well they help us scale our teams and processes to remove bottlenecks to productivity in the dev communtiy. There are several other encouraging proposals related to easing pain in the dev community: - re-working how we do functional testing by making it more project focused - discussions like this one to discuss both priorities, but also how we turn priorities into real action (like the nova projects discussions around using priorities in development) - evolving project leadership (the PTL position) so that we can provide more guidance around delegation in a way that is reasonably consistent across projects - continued discussion about the contents of the integrated release and how we can continue to foster growth without sacrificing quality We are always going to have problems like this, and I hope we continue to think about, discuss, and improve the way we run our projects every release cycle to come. 2) End Users A few others have done a very nice job describing end user experience problems. Monty's description of getting an instance with an IP was painful and embarrassing to read. We've got to figure out ways to provide better focus on these sorts of usability issues. They're obviously not getting the attention they deserve. There have also been lots of good points about improving our API consistency. I totally agree. I'd love to see a group of people step up and emerge as leaders in this area across all projects. I feel like that's something we're sorely missing right now. 3) Deployers OpenStack is still painful to deploy, and even more painful to manage. I'm still quite pleased that we have a deployment program working on this space. I'd actually really like to see how we can facilitate better integration and discussion between TripleO and the rest of the project teams. I'm also very pleased with the progress we've made in Nova towards the initial support for live upgrades. We still have more work to do in Nova, but I'd also like to see more work done in other projects towards the same goal. For both deployers and the dev community, figuring out what went wrong when OpenStack breaks sucks. Others provided some good pointers to several areas we can improve that area (better logs, tooling, ...) and I hope we can make some real progress in this area in the coming cycle. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
