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 !
August was very busy for OpenStack Nova and Glance developers, and the
culmination of those efforts is the delivery of the final feature
milestone of the Diablo development cycle: diablo-4.
Glance gained final
integration with the Keystone common authentication
system,
support for sharing images between groups of
tenants, a
new notification
system
and i18n.
Twelve feature
blueprints were completed in Nova, including final Keystone
integration,
the long-awaited capacity to boot from
volumes,
a configuration
drive
to pass information to instances,
integration
points
for Quantum, KVM block migration
support,
as well as
several
improvements
to
the OpenStack API.
Diablo-4 is mostly feature-complete: a few blueprints for standalone
features were granted an exception and will land post-diablo-4, like
volume types or virtual storage arrays in
Nova, or like SSL
support in Glance.
Now we race towards the release branch point (September 8th) which is
when the Diablo release branch will start to diverge from a newly-open
Essex development branch. The focus is on testing, bug fixing and
consistency... up until September 22, the Diablo release day.
How to control what gets into your open source project code ? The
classic model, inherited from pre-DVCS days, is to have a set of
"committers" that are trusted with direct access while the vast majority
of project "contributors" must kindly ask them to sponsor their patches.
You can find that model in a lot of projects, including most Linux
distributions. This model doesn't scale that well -- even trusted
individuals are error-prone, nobody should escape peer review. But the
main issue is the binary nature of the committer power: it divides your
community (us vs. them) and does not really encourage contribution.
Gated trunk
The solution to this is to implement a gated trunk with a code review
system like GitHub pull requests or Launchpad branch merge proposals.
Your "committers" become "core developers" that have a casting vote on
whether the proposal should be merged. Everyone goes through the peer
review process, and the peer review process is open for everyone: your
"contributors" become "developers" that can comment too. You reduce the
risk of human error and the community is much healthier, but some issues
remain: your core developers can still (wittingly or unwittingly) evade
peer review, and the final merge process is human and error-prone.
Automation ftw
The solution is to add more automation, and not trust humans with direct
repository access anymore. An "automated gated trunk" bot can watch for
reviews and when a set of pre-defined rules are met (human approvals,
testsuites passed, etc.), trigger the trunk merge automatically. This
removes human error from the process, and effectively turns your "core
developers" into "reviewers". This last aspect makes for a very healthy
development community: there is no elite group anymore, just a developer
subgroup with additional review duties.
Gerrit
In OpenStack, we used Tarmac in conjunction with Launchpad/bzr code
review in our first attempt to implement this. As we considered
migration to git, the lack of support for tracking formal approvals in
GitHub code review prevented the implementation of a complex automated
gated trunk on top of GitHub, so we deployed Gerrit. I was a bit
resisting the addition of a new tool to our toolset mix, but the
incredible Monty Taylor and Jim Blair did a great integration job, and I
realize now that this gives us a lot more flexibility and room for
future evolution. For example I like that some tests can be run when the
change is proposed, rather than only after the change is approved (which
results in superfluous review roundtrips).
At the end of the day, gated trunk automation helps in having a
welcoming, non-elitist (and lazy) developer community. I wish more
projects, especially distributions, would adopt it.
No rest for the OpenStack developers, today saw the release of the July
development efforts for Nova and Glance: the Diablo-3 milestone.
Glance gained two performance options: API servers can now cache image
data on the local
filesystem,
and a delayed
delete
feature allows image deletion to happen asynchronously.
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.
