October 30th, 2013 — 7:47pm
OpenStack Compute Tech Lead Russell Bryant has triggered an important discussion on the OpenStack Development mailing list about the process to review blueprints. The Blueprints wiki page currently assigns to Project Tech Leads the task of assigning priority to the blueprints and Russell is suggesting that a wider group of people in the community shares such responsibility..
Blueprints are used by project leaders to track development of significant features in all OpenStack programs: a blueprint is made of a title and a brief description, plus a URL to a wider description of architecture and specifications (usually a wiki or etherpad page). Given the growing size of OpenStack code base, scaling development operations is increasingly hard and one person cannot handle reviewing all the proposed blueprints and set priorities in a way that guarantees finalization.
This brings us to the second issue that needs to be addressed: managing expectations of new contributors. With so many blueprints being proposed it’s hard for a PTL to be accountable for developers to deliver the code based on blueprint’s priorities. Since the PTL used to set the priority for the blueprint, it is hard to held him/her accountable when the code is not delivered accordingly. There is clearly a separation of powers between the person evaluating the blueprints, the developers that will implement them and the reviewers that will review the code submitted.
Russell’s proposal is to assign the responsibility to review the blueprints to the same team of people that will be responsible for reviewing and approving the code during the implementation phase, the core reviewers. The role of the PTL will still be to set the deadlines for the blueprints and to make sure that the roadmap for the program is sound. The core reviewers will then be sharing with the PTL the responsibility and accountability for the deliverables at each release milestone
In the discussion that’s following on the mailing list there are also proposals to include user input while setting the priorities for blueprints. There are risks also associated with this setup. So far, the process has been discussed only taking into account the needs of OpenStack Compute. The project is the largest OpenStack project by number of blueprints, making it the first to need reviewing the existing process. However, the expectation is that several other OpenStack projects may evolve to this point in the future and this is an important test for that time. As such, we welcome holistic feedback: join the discussion on the development mailing list and in Hong Kong.
Comment » | Development, Governance, Measurement
May 13th, 2012 — 8:01pm
The first formal meetup of the Indian OpenStack User Group was held in Bangalore last weekend on the 5th of May. The event was attended by 25 enthusiastic InStackers.
We were hoping to see a few more people but there were a couple of other tech events on the same day. The venue for the meetup was the terrace of the Jacaranda Block on Brigade Millennium Rd. The venue was provided by Ahimanikya Satapathy from Fresco Informatics. On the agenda were talks by Govind Tatachari, Deepak Garg from Citrix and Kavit Munshi from Aptira.
Govind did a presentation on Cloud and IaaS and emerging technologies. The presentation was informative and the users started a discussion about what the cloud was and where to employ it. This set up the ground for the next presentation by Deepak.
Deepak discussed the architecture of OpenStack with particular attention to Nova. The users showed a lot of interest and asked a lot of questions with regards to understanding the underlying architecture of OpenStack.
Kavit discussed OpenStack Swift’s architecture and the various options available to monitor a Swift installation. The talk was very open with most of the time spent with user questions and scenarios they raised. The users also discussed the possibility of doing a live demo or setup of OpenStack at the next meet up. The meetup lasted around 3 hours.
It was great to see the enthusiasm of all the participants and we look forward to our next meeting.
Photos of the event are here. There is also a Linked In group here.
(thanks to Kavit for this blog post)
2 comments » | community, Event, Meetup
December 6th, 2011 — 7:49pm
We had an informal OpenStack meetup after the Opscode Summit in Seattle.
This turned out to be a major open cloud gab fest! In addition to Dell OpenStack leads (Greg Althaus and Rob Hirschfeld), we had the Nova Project Technical Lead (PTL, Vish Ishaya from Rackspace, @vish), HP’s Cloud Architect (Alex Howells, @nixgeek), Opscode OpenStack cookbook master (Matt Ray, @mattray). We were joined by several other Chef Summit attendees with OpenStack interest including a pair of engineers from Spain.
We’d planned to demo using Knife-OpenStack against the Crowbar Diablo build. Unfortunately, the knife-openstack is out of date (August 15th?!). We need Keystone support. Anyone up for that?
There’s no way I can recapture everything that was said, but here are some highlights I jotted down the on the way home.
- After the miss with Keystone and the Diablo release, solving the project dependency problem is an important problem. Vish talked at length about the ambiguity challenge of Keystone being required and also incubated. He said we were not formal enough around new projects even though we had dependencies on them. Future releases, new projects (specifically, Quantum) will not be allowed to be dependencies.
- The focus for Essex is on quality and stability. The plan is for Essex to be a long-term supported (LTS) release tied to the Ubuntu LTS. That’s putting pressure on all the projects to ensure quality, lock features early, and avoid unproven dependencies.
- There is a lot of activity around storage and companies are creating volume plug-ins for Nova. Vish said he knew of at least four.
- Networking has a lot of activity. Quantum has a lot of activity, but may not emerge as a core project in time for Essex. There was general agreement that Quantum is “the killer app” for OpenStack and will take cloud to the next level. The Quantual Open vSwitch implementaiton is completely open source and free. Some other plugins may require proprietary hardware and/or software, but there is definitely a (very) viable and completely open source option for Quantum networking.
- HP has some serious cloud mojo going on. Alex talked about defects they have found and submitted fixes back to core. He also hinted about some interesting storage and networking IP that’s going into their OpenStack deployment. Based on his comments, I don’t expect those to become public so I’m going to limit my observations about them here.
- We talked about hypervisors for a while. KVM and XenServer (via XAPI) were the primary topics. We did talk about LXE & OpenVZ as popular approaches too. Vish said that some of the XenServer work is using Xen Storage Manager to manage SAN images.
- Vish is seeing a constant rise in committers. It’s hard to judge because some committers appear to be individuals acting on behalf of teams (10 to 20 people).
Reminder: 12/8 Meetup @ Austin!
Missed this us in Seattle? Join us at the 12/8 OpenStack meetup in Austin co-hosted by Dell and Rackspace. Based on our last meetup, it appears deployment is a hot topic, so we’ll kick off with that – bring your experiences, opinions, and thoughts!
1 comment » | Meetup
July 1st, 2011 — 9:12am
Joseph Heck has written an excellent blog post on the Nova high level architecture for flags and services. Here is the intro:
I’ve been doing a lot of spelunking into the nova codebase, digging around and trying to learn some of the under pinnings. Some of these pieces were a bit confusing to me, so I’m stashing them up here for Google to find and share with others in the future.
Before I dive into the gritty details, it’s worth getting a high level overview so that some of this (hopefully) makes sense. OpenStack’s service architecture is made up of services that all talk with each other to get things done. nova-network, nova-scheduler, etc. There’s a lot of underpinning in the nova codebase to make those services relatively easy to write and work together – I was mostly curious about how they passed messages back and forth. As I dove in, the two pieces that stood out as needing to be understood first were the unified service framework in nova and configuration using flags (which it heavily depends upon).
Rest of Post
1 comment » | Development, Documentation