Every year, free and open source developers from all over Europe and beyond converge in cold Brussels for a week-end of talks, hacking and beer. OpenStack will be present !
We have a number of devroom and lightning talks already scheduled:
Saturday 12:20 in Chavanne (Virtualization and IaaS devroom)
Autoscaling best practices
Marc Cluet will look into autoscaling using Heat and Ceilometer as examples.
Saturday 13:00 in Chavanne (Virtualization and IaaS devroom)
Network Function Virtualization and Network Service Insertion and Chaining
Balaji Padnala will present NFV and how to deploy it using OpenStack and OpenFlow Controller.
Saturday 13:40 in Chavanne (Virtualization and IaaS devroom)
oVirt and OpenStack Storage (present and future)
Federico Simoncelli will cover integration between oVirt and Glance/Cinder for storage needs.
Saturday 15:00 in Chavanne (Virtualization and IaaS devroom)
Why, Where, What and How to contribute to OpenStack
I will go through a practical introduction to OpenStack development and explain why you should contribute if you haven’t already.
Saturday 16:20 in Chavanne (Virtualization and IaaS devroom)
Hypervisor Breakouts – Virtualization Vulnerabilities and OpenStack Exploitation
Rob Clark will explore this class of interesting vulnerabilities from an OpenStack perspective.
Saturday 17:40 in Chavanne (Virtualization and IaaS devroom)
oVirt applying Nova scheduler concepts for data center virtualization
Gilad Chaplik will present how oVirt could reuse OpenStack Nova scheduling concepts.
Sunday 10:00 in U.218A (Testing and automation devroom)
Preventing craziness: a deep dive into OpenStack testing automation
Me again, in a technical exploration on the OpenStack gating system and its unique challenges.
Sunday 13:40 in Chavanne (Virtualization and IaaS devroom)
Tunnels as a Connectivity and Segregation Solution for Virtualized Networks
Join Assaf Muller for an architectural, developer oriented overview of (GRE and VXLAN) tunnels in OpenStack Networking.
Sunday 16:20 in Chavanne (Virtualization and IaaS devroom)
Bring your virtualized networking stack to the next level
Mike Kolesnik will look into integration opportunities between oVirt and OpenStack Neutron.
Sunday 17:00 in Ferrer (Lightning talks room)
Putting the PaaS in OpenStack
Dirk Diane Mueller will give us an update on cross-community collaboration between OpenStack, Solum, Docker and OpenShift.
Sunday 17:20 in Ferrer (Lightning talks room)
Your Complete Open Source Cloud
Dave Neary should explain how to mix OpenStack with oVirt, OpenShift and Gluster to build a complete private cloud.
We’ll also have a booth manned by OpenStack community volunteers ! I hope to see you all there.
The beginning of a new release cycle is as good as any moment to question why we actually go through the hassle of producing OpenStack releases. Twice per year, on a precise date we announce 6 months in advance, we bless and publish source code tarballs of the various integrated projects in OpenStack. Every week we have a meeting that tracks our progress toward this common goal. Why ?
Releases vs. Continuous deployment
The question is particularly valid if you take into account the type of software that we produce. We don’t really expect cloud infrastructure providers to religiously download our source code tarballs every 6 months and run from that. For the largest installations, running much closer to the master branch and continuously deploy the latest changes is a really sound strategy. We invested a lot of effort in our gating systems and QA automated testing to make sure the master branch is always runnable. We’ll discuss at the OpenStack Summit next week how to improve CD support in OpenStack. We backport bugfixes to the stable branches post-release. So why do we continue to single out a few commits and publish them as “the release” ?
The need for cycles
The value is not really in releases. It is in release cycles.
Producing OpenStack involves the work of a large number of people. While most of those people are paid to participate in OpenStack development, as far as the OpenStack project goes, we don’t manage them. We can’t ask them to work on a specific area, or to respect a given deadline, or to spend that extra hour to finalize something. The main trick we use to align everyone and make us all part of the same community is to have a cycle. We have regular milestones that we ask contributors to target their features to. We have a feature freeze to encourage people to switch their mindset to bugfixing. We have weekly meetings to track progress, communicate where we are and motivate us to go that extra mile. The common rhythm is what makes us all play in the same team. The “release” itself is just the natural conclusion of that common effort.
A reference point in time
Singling out a point in time has a number of other benefits. It’s easier to work on documentation if you group your features into a coherent set (we actually considered shortening our cycles in the past, and the main blocker was our capacity to produce good documentation often enough). It’s easier to communicate about OpenStack progress and new features if you do it periodically rather than continuously. It’s easier to have Design Summits every 6 months if you create a common brainstorm / implementation / integration cycle. The releases also serve as reference points for API deprecation rules, for stable release maintenance, for security backports.
If you’re purely focused on the software consumption part, it’s easy to underestimate the value of release cycles. They actually are one of the main reasons for the pace of development and success of OpenStack so far.
The path forward
We need release cycles… do we need release deliverables ? Do we actually need to bless and publish a set of source code tarballs ? My personal view on that is: if there is no additional cost in producing releases, why not continue to do them ? With the release tooling we have today, blessing and publishing a few tarballs is as simple as pushing a tag, running a script and sending an email. And I like how this formally concludes the development cycle to start the stable maintenance period.
But what about Continuous Deployment ? Well, the fact that we produce releases shouldn’t at all affect our ability to continuously deploy OpenStack. The master branch should always be in good shape, and we definitely should have the necessary features in place to fully support CD. We can have both. So we should have both.
In 3 weeks, free and open source software developers will converge to Brussels for 2+ days of talks, discussions and beer. FOSDEM is still the largest gathering for our community in Europe, and it will be a pleasure to meet again with longtime friends. Note that FOSDEM attendance is free as in beer, and requires no registration.
OpenStack will be present with a number of talks in the Cloud devroom in the Chavanne auditorium on Sunday, February 3rd:
- At 9:30, I’ll open the devroom with State of the OpenStack Union, 2013. A talk about what happened in the OpenStack development community since last year presentation at FOSDEM.
- At 10:00, don’t miss Mark McLoughlin’s talk: OpenStack: 21st Century App Architecture and Cloud Operations. He will expose how OpenStack is built with the same resilience and automation principles as highly-scalable cloud applications.
- At 15:00, Rob Clark will detail his Security Priorities for Cloud Developers: the main security challenges OpenStack faces and what we should do about them.
- At 15:30, Tomas Sedovic will introduce Orchestrating complex deployments on OpenStack using Heat. The Heat project is in OpenStack incubation currently so this is a great opportunity to learn more about it.
- Finally to close the day at 16:30, Nick Barcet, Eoghan Glynn and Julien Danjou will storm the stage and introduce the other OpenStack project currently in incubation: Measuring OpenStack: the Ceilometer Project.
There will also be OpenStack mentions in various other talks during the day: Martyn Taylor should demonstrate OpenStack Horizon in conjunction with Aeolus Image Factory at 13:30, and Vangelis Koukis will present Synnefo, which provides OpenStack APIs, at 14:00.
Finally, I’ll also be giving a talk, directed to Python developers, about the OpenStack job market sometimes Sunday in the Python devroom (room K.3.401): Get a Python job, work on OpenStack.
I hope you will join us in the hopefully-not-dead-frozen-this-time and beautiful Brussels !
Over the last months I’ve seen more and more tweets and news articles using the formulation “OpenStack should”, as in “OpenStack should support Amazon APIs since it’s the de-facto standard”. I think there is a fundamental misconception there and I’d like to address it.
As a quick aside (and contrary to what the twittersphere sometimes report), it should be noted that OpenStack Nova always supported the Amazon EC2 API, and that OpenStack Swift grew an Amazon S3 compatibility layer last year. That said, I’ll be the first to admit that one could rightfully claim that the AWS API support in OpenStack is in less better shape than the OpenStack API support. But the reason behind it is not some “OpenStack strategy”, it’s a reflection of the participating companies focus.
OpenStack is a true Open Innovation project. It’s a collaboration ground where multiple companies are free to invest development resources to care about the stuff that is important to them. It’s an influence game where you need to donate developers to play: OpenStack is the playing field, not the players that push the ball.
Red Hat cared about QPID support, they fielded developers to make it happen in OpenStack. EC2 API support is originally in Nova because NASA cared about it. Then with the increase of Rackspace’s influence on the project, the OpenStack API grew faster. Now with Canonical (and others) interest, Amazon’s API support is getting better. Ultimately, code talks, and you can make things happen. That’s what makes OpenStack so appealing but also so confusing to the industry.
As “OpenStack”, we need to make sure the playing field is level (and hopefully the Foundation will be set up soon enough to address that) and that the code is modular and welcoming. But it’s up to the participating companies, which throw development resources at the project, to invest in what’s important for them or their customers. And maintain it over the long run.
So whenever you say “OpenStack should”, ask yourself if you shouldn’t really be saying… [Rackspace, Cisco, HP, IBM, Red Hat...] should. Ask not what OpenStack can do for you. Ask what you can do for OpenStack.
Since the beginning of March, OpenStack developers are focusing on testing and bugfixes, with the objective of producing a release candidate for each project.
Regular readers of my blog know I’m not the last one to complain when I feel developers don’t care about the release and don’t participate to that critical sequence of the cycle. I’m happy to report that the engagement of developers around making Essex good is overwhelming. Driven by technical leads that understand the challenges, significant groups of old and new developers are participating, testing, assigning themselves to bugs reported by others and fixing them in record time. As project-focused groups, I think we are quickly maturing.
So, how far are we from Essex today ? The final release is set to April 5th, which means each core project needs to produce its final release candidate before then. As of today no project did produce a release candidate yet.
Swift is expected to release its final Essex version (1.4.8) on March 22. This version will be included in OpenStack Essex release, unless a critical regression is detected in it.
Keystone (which every other project depends on) is still struggling with 9 RC bugs, including some key decisions to be made on configuration handling. This is the hot spot right now: if you have free cycles, please consider asking Joe Heck (heckj on IRC) how you can best help the Keystone crew. I’d really like to have an RC1 for that project by Thursday next week.
Glance also looks still a bit far away, with 5 RC bugs listed and slow progress on them. I still hope Glance can be ready by Tuesday next week though.
Nova is looking quite good, with 2 RC bugs left on the list. The trick with Nova is that regressions and critical issues can hide in dark corners of its 120k lines of code, so the focus is really on finding the remaining issues, filing and targeting them. I expect we’ll be able to publish RC1 on Monday or Tuesday next week.
Horizon is almost ready (3 RC bugs left), waiting for a few fixes to land in other projects before it can issue its RC1. It should be out early next week.
Once all projects release their RC1, the hunt for the overlooked release-critical issue will be on. It will be time to put the proposed release to the test. In order to limit potential last-minute regressions, only showstoppers will warrant a respin of the release candidate, other bugs will be listed in the Known Bugs section of the release notes. You can use the “essex-rc-potential” tag to mark bugs that you think should be fixed before we release Essex.
Let’s all make it rock !
Next week, the European free and open source software developers will converge to Brussels for FOSDEM. We took this opportunity to apply for an OpenStack developers gathering in the Virtualization and Cloud devroom.
At 6pm on Saturday (last session of the day), in the Chavanne room, we will have a one-hour town hall meeting. If you’re an existing OpenStack contributor, a developer considering to join us, an upstream project developer, a downstream distribution packager, or just curious about OpenStack, you’re welcome to join us ! I’ll be there, Stefano Maffulli (our community manager) will be there, and several OpenStack core developers will be there.
We’ll openly discuss issues and solutions about integration with upstream projects, packaging, governance, development processes, community or release cycles. In particular, we’ll have a distribution panel where every OpenStack distribution will be able to explain how they support OpenStack and discuss what we can improve to make things better for them.
And at the end of the session we can informally continue the discussion around fine Belgian beers or their famous Carbonade !
The Free and Open source Software Developers’ European Meeting, or FOSDEM, is an institution that happens every year in Brussels. A busy, free and open event that gets a lot of developers together for two days of presentations and cross-pollination. There are typically the FOSDEM main tracks (a set of presentations chosen by the FOSDEM organization) and a set of devrooms, which are topic-oriented or project-oriented and can organize their own schedule freely.
This year, FOSDEM will host an unusual devroom, the Virtualization and Cloud devroom. It will happen in the Chavanne room, a 550-seat auditorium that was traditionally used for main tracks. And it will last for two whole days, while other devrooms typically last for a day or a half-day.
The Virtualization and Cloud devroom is the result of the merging of three separate devroom requests: Virtualization, Xen and OpenStack devrooms. It gives us a larger space and a lot of potential for cross-pollination across projects ! We had a lot of talks proposed, and here is an overview of what you’ll be able to see there.
Saturday, February 4
Saturday will be the “cloud” day. We will start with a set of talks about OpenStack, past, present and future. I will do an introduction and retrospective of what happened last year in the project, Soren Hansen will guide new developers to Nova, and Debo Dutta will look into future work on application scheduling and Donabe. Next we’ll have a session on various cloud-related technologies: libguestfs, pacemaker-cloud and OpenNebula. The afternoon will start with a nice session on cloud interoperability, including presentations on the Aeolus, CompatibleOne and Deltacloud efforts. We’ll continue with a session on cloud deployment, with a strong OpenStack focus: Ryan Lane will talk about how Wikimedia maintains infrastructure like an open source project, Mike McClurg will look into Ubuntu+XCP+OpenStack deployments, and Dave Walker will introduce the Orchestra project. The day will end with a town hall meeting for all OpenStack developers, including a panel of distribution packagers: I will blog more about that one in the next weeks.
Sunday, February 5
Sunday is more “virtualization” day ! The day will start early with two presentations by Hans de Goede about Spice and USB redirection over the network. Then we’ll have a session on virtualization management, with Guido Trotter giving more Ganeti news and three talks about oVirt. In the afternoon we’ll have a more technical session around virtualization in development: Antti Kantee will introduce ultralightweight kernel service virtualization with rump kernels, Renzo Davoli will lead a workshop on tracing and virtualization, and Dan Berrange will show how to build application sandboxes on top of LXC and KVM with libvirt. The day will end with another developers meeting, this time the Xen developers will meet around Ian Campbell and his Xen deployment troubleshooting workshop.
All in all, that’s two days packed with very interesting presentations, in a devroom large enough to accomodate a good crowd, so we hope to see you there !
2011 is almost finished, and what a year it has been. We started it with two core projects and one release behind us. During 2011, we got three releases out of the door, grew from 60 code contributors to about 200, added three new core projects, and met for two design summits.
The Essex-2 milestone was released last week. Here is our now-regular overview of the work that made it to OpenStack core projects since the previous milestone.
Nova was the busiest project. Apart from my work on a new secure root wrapper (detailed on previous articles of this blog), we added a pair of OpenStack API extensions to support the creation of snapshots and backups of volumes, the metadata service can now run separately from the API node, network limits can now be set using a per-network base and a per-flavor multiplier, and a small usability feature lets you retrieve the last error that occurred using nova-manage. But Essex is not about new features, it’s more about consistency and stability. On the consistency front, the HA network mode was extended to support XenServer, KVM compute nodes now report capabilities to zones like Xen ones, and the Quantum network manager now supports NAT. Under the hood, VM state transitions have been strengthened, the network data model has been overhauled, internal interfaces now support UUID instance references, and unused callbacks have been removed from the virt driver.
The other projects were all busy starting larger transitions (Keystone’s RBAC, Horizon new user experience, and Glance 2.0 API), leaving less room for essex-2 features. Glance still saw the addition of a custom directory for data buffering. Keystone introduced global endpoints templates and swauth-like ACL enforcement. Horizon added UI support for downloading RC files, while migrating under the hood from jquery-ui to bootstrap, and adding a versioning scheme for environment/dependencies.
The next milestone is in a bit more than a month: January 26th, 2012. Happy new year and holidays to all !
Last week saw the delivery of the first milestone of the Essex development cycle for Keystone, Glance, Horizon and Nova. This early milestone collected about two months of post-Diablo work… but it’s not as busy in new features as most would think, since a big part of those last two months was spent releasing OpenStack 2011.3 and brainstorming Essex features.
Keystone delivered their first milestone as a core project, with a few new features like support for additional credentials, service registration and using certificate-based SSL client authentication to authenticate services. It should be easier to upgrade from now on, with support for database migrations.
Glance developers were busy preparing significant changes that will land in the next milestone. Several bugfixes and a few features made it to essex-1 though, including the long-awaited SSL client connections. It also moved to UUID image identifiers.
The Nova essex-1 effort was mostly spent on bugfixing, with 129 bugs fixed. New features include a new XenAPI SM volume driver, DHCP support in the Quantum network manager, and optional deferred deletion of instances. Under the hood, the volume code was significantly cleaned up and XML templates were added to simplify serialization in extensions.
Essex-1 was also the first official OpenStack milestone for Horizon, also known as the Dashboard. New features include a instance details page, support for managing Nova volumes and a new extensible modular architecture. The rest of the effort was spent on catching up with the best of core projects in internationalization, developer documentation, and QA (frontend testing and JS unit tests).
Now, keep your seatbelt fastened, as we are one month away from essex-2, where lots of new development work is expected to land !
The 200 open seats for the Essex Design Summit were all registered in less than 9 days ! If you missed the boat, you can still register on the waiting list at http://summit.openstack.org.
For the last seats we need to give priority to existing OpenStack developers and upstream/downstream community members, so the waiting list will be reviewed manually. You will receive an email if you get cleared and get one of the very last seats for the summit.
Sometime next week, the website should allow registered attendees (as well as attendees on the waiting list) to propose sessions for the summit, so stay tuned !