No rest for the OpenStack developers, today saw the release of the July development efforts for Nova and Glance: the Diablo-3 milestone.
With a bit more than 100 trunk commits over the month, Nova gained support for multiple NICs, FlatDHCP network mode now support a high-availability option (read more about it here), instances can be migrated and system usage notifications were added to the notification framework. Network code was also refactored in order to facilitate integration with the new networking projects, and countless fixes were made in OpenStack API 1.1 support.
We have one more milestone left (diablo-4) before the final 2011.3 release… still a lot to do !
About a month ago I commented on the features delivered in the diablo-1 milestone. Last week we released the diablo-2 milestone for your testing and feature evaluation pleasure.
Most of the changes to Glance were made under the hood. In particular the new WSGI code from Nova was ported to Glance, and images collections can now be sorted by a subset of the image model attributes. Most of the groundwork to support Keystone authentication was done, but that should only be available in diablo-3 !
Those same initial Keystone integration steps were also done for Nova, along with plenty of other features. We now support distributed scheduling for complex deployments, together with a new instance referencing model. Was also added during this timeframe: support for floating IPs (in OpenStack API), a basic mechanism for pushing notifications out to interested parties, global firewall rules, and an instance type extra specs table that can be used in a capabilities-aware scheduler. More invisible to the user, we completed efforts to standardize error codes and refactored the OpenStack API serialization mechanism.
And there is plenty more coming up in diablo-3… scheduled for release on July 28th.
There are multiple available delivery channels available to install OpenStack packages on Ubuntu.
First of all, starting with 11.04 (Natty), packages for OpenStack Nova, Swift and Glance are available directly in Ubuntu’s official universe repository. This contains the latest release available at the time of Ubuntu release: 2011.2 “Cactus” in 11.04. If you don’t use Ubuntu 11.04, or if you want a more recent version, you’ll need to enable one of our specific PPAs, please read on.
OpenStack release PPA
If you want to run 2011.2 on 10.04 LTS (Lucid) or 10.10 (Maverick) you can use the ppa:openstack-release/2011.2 PPA. Enabling it is as simple as running:
$ sudo apt-get install python-software-properties $ sudo add-apt-repository ppa:openstack-release/2011.2 $ sudo apt-get update
Starting with the Diablo cycle, we do a coordinated OpenStack release every 6 months. That said, Swift releases stable versions more often. You can get the latest Swift release through the ppa:swift-core/release PPA. Just replace the PPA name in the above example.
Also starting with the Diablo cycle, Nova and Glance deliver a development milestone every 4 weeks. If you want to test the latest features, you can enable those PPAs: ppa:nova-core/milestone or ppa:glance-core/milestone.
PPAs for testers and developers
Just before we deliver one of these intermediary releases or milestones, we use a specific “milestone-proposed” PPA to do final QA on release candidates. Enabling this one and reporting issues will help us in delivering high-quality milestones. Just enable ppa:nova-core/milestone-proposed, ppa:glance-core/milestone-proposed or ppa:swift-core/milestone-proposed.
Finally, for all projects and for every code commit, we generate a package in the trunk PPA. If you’re a developer, or like living on the bleeding edge, you should enable those: ppa:nova-core/trunk, ppa:glance-core/trunk or ppa:swift-core/trunk.
I hope this will help you select the best delivery channel for your use case, depending on whether you’re deploying, evaluating, helping in QA or actively developing. For future reference, the list of PPAs is maintained on the wiki.
Back at the OpenStack Design Summit in Santa Clara, we decided to switch from a 3-month cycle to a 6-month coordinated release cycle, with more frequent milestones delivery in the middle.
Lately we have been busy adapting the release processes to match the delivery of the first milestones. Swift 1.4.0 was released last Tuesday, and today sees the release of the diablo-1 milestone for Nova and Glance.
What should you expect from diablo-1, just 4 weeks after the design summit ? In this short timeframe lots of features have been worked on, and the developers managed to land quite a few of them in time for diablo-1.
Glance’s API was improved to support filtering of /images and /images/detail results and limiting and paging of results. This made support of API versioning necessary. It also grew a new disk format (“iso”) that should ultimately allow to boot ISOs directly in Nova.
On Nova’s side, the most notable addition is support for snapshotting and cloning volumes with the EC2 API. The XenServer plugin now supports Open vSwitch, and pause and suspend capabilities have been added to the KVM hypervisor.
Now keep your seatbelt fastened, because diablo-2 is set to release on June 30th.
A few weeks after the OpenStack Design Summit in Santa Clara, we are starting to get a better picture of what should be in the next version of OpenStack Nova, codenamed Diablo, scheduled for release on September 22.
One big priority of this release is to separate code for the network and volume services, and refactor nova-network code to add a clear internal API. This will allow to plug separate network and volume service providers, and pave the way for integration with future OpenStack projects like Quantum/Melange/Donabe and LunR. In preparation for this, we’ll push changes to rely more on the queue (and less on the database) to pass information between components. In the same area, we need some more changes to support multiple NICs and should also provide a client OpenStack API for directly interacting with volumes.
A second theme of the Diablo release is the new distributed scheduler, which should be able to schedule across zones and taking capabilities into account. This will need changes in the way we reference instances, as well as some changes for EC2 API compatibility.
On the API side, we should finalize OpenStack API 1.1 support, including work on floating IPs and shared IP groups. For administrators, instance migration and account administration actions should be added. We’ll also ensure good AWS API compatibility and validation.
Support for snapshotting, cloning and booting from volumes should land early in this cycle, as well as new ways of communicating configuration data between host and guest. We also need to integrate with AuthN/AuthZ with the new common Keystone authentication system. Lots of other features are planned (and others might be added before the end), you can check out the blueprints plan for more detail.
Last but not least, on the QA side, we should have continuous automated testing across a range of reference architectures and increase our unittest and smoketest coverage among other efforts to build-in quality.
The first milestone for this cycle, diablo-1, should be released on June 2nd.
Last week I attended the Ubuntu Developer Summit for Oneiric in Budapest. This was the first time I attended UDS as an upstream representative rather than as a Canonical employee. I very much enjoyed it: not being a track lead or a busy technical lead actually gives you desirable flexibility in your agenda
First of all, a quick comment on the big announcement of the week, which the Twittersphere is not done retweeting yet: “Ubuntu switching from Eucalyptus to OpenStack”. I think it would be more accurate to say that Ubuntu chose to use OpenStack as its default cloud stack for future versions. Comparing Eucalyptus and OpenStack is like comparing apples to apple trees: OpenStack provides several cloud infrastructure pieces (of which only OpenStack Compute -Nova- covers the same space as Eucalyptus). I suspect the wide scope of the project played a role in OpenStack being selected as the default stack for the future. Eucalyptus and OpenStack Nova should both be present as deployment options from 11.10 on.
On the UDS format itself, I’d say that the “one blueprint = one hour” format does not scale that well. The numbers of hours in the week is fixed, so when the project grows you end up having too many sessions going on at the same time. Lots of blueprints do not require one hour of discussion, but rather a quick presentation of plan, feedback from interested parties and Q&A. That’s what we do for our own Design Summits, but I’d admit it makes scheduling a bit more complex. On the good side, having the floor plan inside our UDS badges was a really good idea, especially with confusing room names
The Launchpad and bzr guys were very present during the week, attentive and reactive to the wishes of upstream projects. They have great improvements and features coming up, including finer-grained bugmail and dramatic speed improvements in bzr handling of large repos.
Last week also saw the rise of creampiesourcing: motivation of groups of developers over bets (“if the number of critical bugs for Launchpad goes to 0 by June 27, I’ll take a creampie in the face”). Seems to work better than karma points.
Finally, Rackspace Hosting was co-sponsoring the “meet and greet” event on the Monday night, promoting OpenStack. I think offering cool T-shirts, like we did at the previous UDS in Orlando, was more efficient in spreading the word and making the project “visible” over time: in Budapest you could see a lot of people wearing the OpenStack T-shirts we offered back then !
In a bit more than a week, we will hit FeatureFreeze for OpenStack “Cactus” cycle, so we start to have a good idea of what new features will make it. The Cactus cycle focus was on stability, so there are fewer new features compared to Bexar, but the developers still achieved a lot in a couple of months…
Swift (OpenStack object storage)
The Swift team really focused and stability and performance improvements this cycle. I will just single out the refactoring of the proxy to make backend requests concurrent, and improvements on sqlite3 indexing as good examples of this effort.
Glance (OpenStack image registry and delivery service)
Bexar saw the first release of Glance, and in Cactus it was vastly improved to match standards we have for the rest of OpenStack: logging, configuration and options parsing, use of paste.deploy and non-static versioning, database migrations… New features include a CLI tool and a new method for client to verify images. Glance developers might also sneak in an authentication middleware and support for HTTPS connections !
Nova (OpenStack compute)
A lot of the feature work in Nova for Cactus revolved around the OpenStack API 1.1 and exposing features through XenServer (migration, resize, rescue mode, IPv6, file and network injection…). We should also have the long-awaited live migration feature (for KVM), support for LXC containers, VHD images, multiple NICs, dynamically-configured instance flavors or volume storage on HP/Lefthand SANs. XenAPI should get support for Vlan network manager and network injection. We hope support for VMWare/vSphere hypervisor will make it.
The rest of the Nova team concentrated on testing, bugfixing (already 115 bugfixes committed to Cactus !) and producing a coherent release, as evidenced by the work on adding the missing Ipv6 support for FlatManager network model. I should also mention that the groundwork for multi-tenant accounting and multiple clusters in a region also landed in Cactus.
Over the three projects branches, last month we had more than 2500 commits by more than 75 developers. Not too bad for a project less than one-year-old… We’ll see the result of this work on Cactus release day, scheduled April 14.
OpenStack is busy with so much development activity it’s hard to keep up. 42 (!) specs were targeted for the 3-month long Bexar development cycle… and there are more than 150 active branches. Over the last month alone, we saw 750 commits by 50 different people. Taking a step back, what new features should you expect to land on February 3rd, in the Bexar release ?
Swift (OpenStack object storage)
The big news in Swift is support for unlimited object size, through the implementation of client-side chunking. The only size limit for your objects is now the available size in your Swift cluster ! You can read more about that exciting feature in John Dickinson’s blog post. We also hope to ship Swauth, DevAuth highly scalable replacement, directly into Swift codebase. Exposure of most of the S3 API in Swift may or may not make it.
Glance (OpenStack image registry and delivery service)
The Glance image service will expose a unified REST API (no more distinction between the image registry and the image delivery services). We will also have the possibility to upload image data and metadata over one single call. Unified client classes will be shipped directly in Glance. We also hope to have a S3 backend…
Nova (OpenStack compute)
There is so much coming up in Nova it’s hard to summarize. Nova will make use of those new Glance client classes, obviously. We will support booting VMs from raw disk images (rather than a kernel/ramdisk/image combination) and have a rescue mode to mount your faulty disks under a sane environment. We plan to have instance snapshots ready. API servers can now expose optional admin features (through the –allow_admin_api flag), like a specific XenServer instance pause or suspend feature.
Lots of improvements might go unnoticed, like the internationalization of messages, the standardization on services using eventlet, more robust logging, or the move of the IP allocation down the stack. We’ll also finalize some incomplete features, like access to your project VLAN through a VPN, security groups that work in all network modes, and Hyper-V support.
We hope to have much more: a web-based serial console to access your VMs, ipv6 support, the possibility to deploy hardware in a staging area of your cloud, support for highly available block volumes through Sheepdog, instance diagnostics allowing to retrieve a history of actions on instances, the possibility to do live migration in nova-manage, iSCSI support for XenAPI… But let’s be realistic, not everything will land in time. What doesn’t make it will certainly be in the next release, Cactus, which will be released in April !
Congrats to our awesome development team for making all this possible. Those last two months have been a very fun ride for me
Want to test the latest cloud goodness ? Thanks to the new Nova trunk PPA, it’s really easy to run the freshest code from OpenStack Compute (Nova) on Ubuntu 10.10. Here is how.
We will install everything on the same machine, one that has VT extensions enabled and therefore can run KVM. My test laptop with 2Gb of RAM has been a bit struggling, but it worked. You should have Ubuntu 10.10 installed on that box.
Dec 9, 2010 UPDATE: rabbitmq-server should be installed before the nova packages, and we should use images with ramdisks at this point.
Feb 25, 2011 UPDATE: Ubuntu cloud images are supported, switch tutorial to using those.
First you should enable the PPA:
$ sudo apt-get install python-software-properties $ sudo add-apt-repository ppa:nova-core/trunk $ sudo apt-get update
Install RabbitMQ first:
$ sudo apt-get install rabbitmq-server
Then install Nova and dependencies :
$ sudo apt-get install nova-api nova-objectstore nova-compute nova-scheduler nova-network euca2ools unzip
Congratulations, you just created a cloud.
You should restart libvirt, especially if you had it installed before, to make sure it realizes that ebtables is now installed:
$ sudo service libvirt-bin restart
Create a specific network for your VMs, here I used my unused 10.0.0.0/8:
$ sudo nova-manage network create 10.0.0.0/8 1 64
Create a user, a project, download credentials and source them:
$ sudo nova-manage user admin ttx $ sudo nova-manage project create myproject ttx $ sudo nova-manage project zipfile myproject ttx $ unzip nova.zip $ . novarc
Register an Ubuntu cloud image
Download an Ubuntu cloud image, then use uec-publish-tarball to register it:
$ r="maverick" $ wget http://uec-images.ubuntu.com/$r/current/$r-server-uec-amd64.tar.gz $ uec-publish-tarball $image mybucket
It should output 3 references : emi, eri and eki. You need to use the emi value in the next section (I got “ami-lvdliy0″).
Running an instance
First, create a keypair if you haven’t already one:
$ euca-add-keypair mykey > mykey.priv $ chmod 0600 mykey.priv
Allow the connection to port 22 of the instance (SSH), using the following command:
$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0
Then start the instance (replace $emi with the value from uec-publish-tarball above):
$ euca-run-instances $emi -k mykey -t m1.tiny
This will return an instance ID (I got “i-1objiev”), an IP address (I got “10.0.0.3″), and the instance will be scheduled and launched. You should check the status with:
The instance should quickly go from “launching” to “running”, and you should be able to connect to the ubuntu user through SSH (replace $ipaddress with the one you got from euca-describe-instances):
$ ssh -i mykey.priv ubuntu@$ipaddress
When you are done playing, you can tear the instance down using the following command (replace $instanceid with the instance ID from above):
$ euca-terminate-instances $instanceid
- For this simple tutorial I left nova-volume out, since it requires more configuration setup (like setting up LVM volume groups) before it can be used.
- All references are “ami-”: it should be ami, ari and aki. This is a bug that will be fixed (bug 658234)
Last week I started a new job, working for Rackspace Hosting as the Release Manager for the Openstack project. I’m still very much working from home on open source software, so that part doesn’t change. However, there are some subtle differences.
First of all, Openstack is what we call an upstream project. Most of my open source work so far involves distribution work: packaging and delivering various open source software components into a well-integrated, tested and security-maintained distribution. This is hard work, one that is never completely finished or perfect. It is also a necessary part of the open source ecosystem: without distributions, most software would not be easily available for use.
Upstream work, on the other hand, is about developing the software in the first place. It’s a more creative work, in a much more controlled environment. The Openstack project is the new kid on the block of cloud computing software, one that strives to become the open source standard for building cloud infrastructures everywhere. It was announced in July, so it’s relatively young. There are lots of procedures and processes to put in place, an already-large developer group, and an ever-growing community of users and partners. The software itself is positioned to run in high-demand environments: The storage component is in production use at Rackspace, the compute component is in production use at NASA. Openstack is planned to fully replace the current Rackspace Cloud software next year, and a number of governments plan to use it to power their local cloud infrastructure. Those are exciting times.
What does an open source project Release Manager do ? Well first, as it says on the tin, it manages the release process. Every 3 or 6 months, Openstack will release a new version of its components, and someone has to make sure that that happens. That’s OK, but what do I do the other 50 weeks of the year ? Well, release managers also manage the release cycle. A cycle goes through four stages: Design, Development, QA and Release. It is the job of the release manager to drive and help the developer community through those stages, follow work in progress, making sure everyone knows about the steps and freezes, and granting exceptions when necessary. At the very end, he must balance between the importance of a bug and the risk of regression the bugfix introduces: it’s better to release with a known bug than with an unknown regression. He is ultimately responsible for the delivery, on time, of the complete release cycle. And yes, if you condense everything to 3 or 6 months, this is a full-time job
My duties also include ensuring that the developers have everything they need to work at their full potential and that the project is transparent. I also have to make sure the developer community is a welcoming environment for prospective new contributors, and present the project as a technical envangelist in conferences. And if I still have free time, I may even write some code where I need to scratch an itch. All in all, it’s a pretty exciting job, and I’m very happy to meet everyone this week at the Openstack design summit in
Orlando San Antonio.