Posts Tagged ‘canonical’

The amount of uptake seen with Ubuntu Server over the past year has been extremely rewarding and simply amazing. Infrastructure as a Service (IaaS), a.k.a. Public Cloud, providers are popping up left and right, all wanting to provide Ubuntu Server…all helping to further cement Ubuntu Server’s position as the OS for the cloud.

With that said, I’ve started to become concerned about the way in which some of these IaaS providers distribute Ubuntu. Ubuntu developers create, publish, and regularly update images on Amazon Web Services and Microsoft Azure. Canonical hosts and maintains internal archive mirrors in these clouds to provide a low-latency, low-cost update mechanism to users. Finally, Canonical engineers purposely designed in a pluggable cloud provider API approach to Ubuntu’s service orchestration application, Juju, to lower the operational barriers that often place limitations on cross-cloud workload and service migrations. We do all this to help ensure cross-platform consistency for Ubuntu Server users, i.e. workloads and applications ran on Ubuntu Server behave in the same manner on bare metal machines and across IaaS providers.

Some IaaS providers and users have decided to produce and host their own Ubuntu Server images without the involvement of the Ubuntu Project or Canonical. I won’t go into the legal aspects of this, because I’m no lawyer. However, I believe there is a real risk to users when these images are modified in some way, but still presented as “official” Ubuntu Server images. Whether the changes are minor, like redirecting fixes and security updates to internal unofficial mirrors, or major, like making changes to OS and/or applications provided in the images themselves, labeling the images as “official”Ubuntu Server is a misrepresentation of the project and the product. There is a real and legitimate risk of users losing out on the cross-platform assurance that the Ubuntu project and Canonical work so hard to provide due to the images having untested code or simply being out of sync on fixes and updates. Furthermore, there’s no guarantee that bug fixes made to these modified images will ever make it into the official distro, thus creating a further fork between expected behavior across both bare metal and cloud platforms. All of this has the potential to lead to poor user experience that’s very damaging to the reputation of Ubuntu the project and product, not to mention Canonical as it’s sponsor.

We ,within the Ubuntu Server team, work extremely hard to ensure our community can depend on having the same user experience and application execution results across all supported platforms, bare metal or cloud. So…if you are a IaaS provider, and you elect to produce and distribute modified Ubuntu Server images, please…please ensure your users are aware of this by labeling them as customized derivatives. Let them know that by using these modified images they potentially run the risk of being delayed in getting bug fixes and security updates…and that differences in OS and application behavior from your changes can lead to higher levels of complexity if/when they have a need to move workloads and services to/from other official Ubuntu Server deployments.

With the release of Ubuntu Server 12.04 LTS quickly approaching, the Ubuntu Server Team has been working extremely hard on ensuring OpenStack Essex will be of high quality and tightly integrated into Ubuntu Cloud. As with prior Long Term Support releases, Canonical commits to maintaining Ubuntu Server 12.04 LTS for five years, which means users receive five years of maintenance for the OpenStack Essex packages we provide in main. With that said, we recognize that OpenStack is still a relatively young project moving at a tremendous rate of innovation right now, with features and fixes already planned for Folsom that some users require for their production deployment. In the past, these users would have to upgrade off the LTS, in order to get maintenance for the OpenStack release they need on Ubuntu Server… thus foregoing the five year maintenance they want and need for their production deployment. We wholeheartedly believe there are situations where moving to the next release of Ubuntu (12.10, 13.04, etc) for newer OpenStack releases works just fine, especially for test/dev deployments. However, we also know there will be many situations where users cannot afford the risk and/or the cost of upgrading their entire cloud infrastructure just to get the benefits of a newer OpenStack release, and we need to have a solution that fits their needs. After thinking about what users want and where most people expect OpenStack go in terms of continued innovation and stability, we have decided to provide Ubuntu users with two options for maintenance and support in the 12.04 LTS.

The first option is that users can stay with the shipped version of OpenStack (Essex) and remain with it for the full life of the LTS. As per the Ubuntu LTS policy, we commit to maintaining and supporting the Essex release for 5 years. The point releases will also ship the Essex version of OpenStack, along with any bug fixes or security updates made available since its release.

Introducing the Ubuntu Cloud Archive

The second option involves Canonical’s Ubuntu Cloud archive, which we are officially announcing today. Users can elect to enable this archive, and install newer releases of OpenStack (and the dependencies) as they become available up through the next Ubuntu LTS release (presumably 14.04). Bug processing and patch contributions will follow standard Ubuntu practice and policy where applicable. Canonical commits to maintaining and supporting new OpenStack releases for Ubuntu Server 12.04 LTS in our Ubuntu Cloud archive for at least 18 months after they release. Canonical will stop introducing new releases of OpenStack for Ubuntu Server 12.04 LTS into the Ubuntu Cloud archive with the version shipped in the next Ubuntu Server LTS release (presumably 14.04). We will maintain and support this last updated release of OpenStack in the Ubuntu Cloud archive for 3 years, i.e. until the end of the Ubuntu 12.04 LTS lifecycle.
In order to allow for a relatively easy upgrades, and still adhere to Ubuntu processes and policy, we have elected to have archive.canonical.com be the home of the Ubuntu Cloud archive. We will enable update paths for each OpenStack release.

e.g. Enabling “precise-folsom” in the archive will provide access to all OpenStack Folsom packages built for Ubuntu Server 12.04 LTS (binary and source), any updated dependencies required, and bug/security fixes made after release.

As of now, we have no plans to build or host OpenStack packages for non-LTS releases of Ubuntu Server in the Ubuntu Cloud archive. We have created the chart below to help better explain the options.

Q&A

Why Not Use Stable Release Updates?

Ubuntu’s release policy states that once an Ubuntu release has been published, updates must follow a special procedure called a stable release update, or SRU, and are delivered via the -updates archive. These updates are restricted to a specific set of characteristics:

severe regression bugs

security vulnerabilities (via the -security archive)

bugs causing loss of user data

“safe” application layer bugs

hardware enablement

partner archive updates

Exceptions to the SRU policy are possible. However, for this to occur the Ubuntu Technical Board must approve the exception, which must meet their guidelines:

Updates to new upstream versions of packages must be forced or substantially impelled by changes in the external environment, i.e. changes must be outside anything that could reasonably be encapsulated in a stable release of Ubuntu. Changes internal to the operating system we ship (i.e. the Ubuntu archive), or simple bugs or new features, would not normally qualify.

A new upstream version must be the best way to solve the problem. For example, if a new upstream version includes a small protocol compatibility fix and a large set of user interface changes, then, without any judgement required as to the benefits of the user interface changes, we will normally prefer to backport the protocol compatibility fix to the version currently in Ubuntu.

The upstream developers must be willing to work with Ubuntu. A responsive upstream who understands Ubuntu’s requirements and is willing to work within them can make things very much easier for us.

The upstream code must be well-tested (in terms of unit and system tests). It must also be straightforward to run those tests on the actual packages proposed for deployment to Ubuntu users.

Where possible, the package must have minimal interaction with other packages in Ubuntu. Ensuring that there are no regressions in a library package that requires changes in several of its reverse-dependencies, for example, is significantly harder than ensuring that there are no regressions in a package with a straightforward standalone interface that can simply be tested in isolation. We would not normally accept the former, but might consider the latter.

Once approved by the Tech Board, the exception must have a documented update policy, e.g. http://wiki.ubuntu.com/LandscapeUpdates. Based on these guidelines and the core functionality OpenStack serves in Ubuntu Cloud, the Ubuntu Server team did not feel it was in the best interest of their users, nor Ubuntu in general, to pursue an SRU exception.

What about using Ubuntu Backports?

The Ubuntu Backports process (excludes kernel) provides us a mechanism for releasing package updates for stable releases that provide new features or functionality. Changes were recently made to `apt` in Ubuntu 11.10, whereby it now only installs packages from Backports when they are explicitly requested. Prior to 11.10, `apt` would install everything from Backports once it was enabled, which led to packages being unintentionally upgraded to newer versions. The primary drawbacks with using the Backports archive is that the Ubuntu Security team does not provide updates for the archive, it’s a bit of a hassle to enable per package updates, and Canonical doesn’t traditionally offer support services for the packages hosted there. Furthermore, with each new release of OpenStack, there are other applications that OpenStack depends on that also must be at certain levels. By having more than one version of OpenStack in the same Backports archive, we run a huge risk of having backward compatibility issues with these dependencies.

How Will You Ensure Stability and Quality?

In order for us to ensure users have a safe and reliable upgrade path, we will establish a QA policy where all new versions and updated dependencies are required to pass a specific set of regression tests with a 100% success rate. In addition:

Unit testing must cover a minimum set of functionality and APIs

System test scenarios must be executed for 24, 48 and 72 hours uninterrupted.

Package testing must cover: initial installation, upgrades from the previous OpenStack release, and upgrades from the previous LTS and non-LTS Ubuntu release.

All test failures must be documented as bugs in Launchpad, with regressions marked Fix Released before the packages are allowed to exit QA.

Test results are posted publicly and announced via a mailing list specifically created for this effort only.

Only upon successfully exiting QA will packages be pushed into the Ubuntu Cloud archive.

What Happens With OpenStack Support and Maintenance in 14.04?

Good question. The cycle could repeat itself, however at this point Canonical is not making such a commitment. If the rate of innovation and growth of the OpenStack project matures to a point where users become less likely to need the next release for its improved stability and/or quality, and instead just want it for a new feature, then we would likely return to our traditional LTS maintenance and support model.

Kicking off this May, the Ubuntu Cloud Summit is a one day event for both technology and business people interested in what cloud computing can do for their organisations.

Hosted by Canonical and Redmonk we’ll be looking at how open-source is playing a critical role in the move to cloud computing. Delegates will also hear how enterprises have made the most of the move to the cloud using open source. There will be plenty of opportunity for discussion and debate ensuring you have all the information you need to deploy an open cloud.

The day will include a keynote from Mark Shuttleworth and others, plus a panel discussion chaired by Stephen O’Grady of Redmonk, before closing with cocktails and canapes.

The Ubuntu Cloud Summit takes place on Tuesday 8th May, at the The Oakland Marriott City Center in Oakland.

The event is sure to be popular, so don’t miss your chance to be there.

Ubuntu Cloud Day is Canonical’s first Cloud event in Bangalore. With keynote speeches from various members of the Canonical team and a more focussed technical delivery, the event is aimed at engineers and developers with a professional interest in using Ubuntu Cloud as a developer tool, along with those with a keen interest in developing innovative applications for the Ubuntu user base.

The event is sponsored by Intel and the agenda includes presentations on working with Ubuntu Cloud, JuJu, Cloud infrastructure, as well as presentations from Intel and other partners. The sessions will also cover the intricacies of building your own Cloud infrastructure with Ubuntu, managing Cloud workloads on your own servers and sending identical workloads to the public Cloud when you need extra capacity.

The location for Ubuntu Cloud Day is the Grand Ballroom at the Chancery Pavilion Hotel, 135 Residency Road, Bangalore.

Starting today at 1500 UTC, we’ll be conducting a series of online classes for Ubuntu Developer Week. Whether you are interest in developing new applications for Ubuntu, or want to make an existing app take advantage of all of Ubuntu’s features, this is definitely something you should attend.

This cycle Daniel Holbach will kick things off with a overview of Ubuntu development, using Bazaar and Launchpad to collaborate both online and off with teams of developers all over the world.

After that I will be giving an overview of the unique collection of technologies and services that Ubuntu offers application developers, including Unity integration, Ubuntu One cloud storage, and the Software Center. Then I will be joined by Michał Sawicz to talk about Ubuntu TV, and how you can get a development environment setup and start hacking on it yourself

Later, David Callé and Michal Hruby will be showing you how to integrate with the Unity Dash by writing custom lenses and scopes for your content. And if you are interested in that, be sure to come back Thursday for my session on writing simple lenses and scopes in Python using the Singlet library.

Mark Mims and Dustin Kirland will both by presenting on different ways Ubuntu lets you take advantage of the latest cloud technology to improve the development, testing and deployment of your application and stack. And Stuart Langridge will be talking about the latest developments in the Ubuntu One Database (U1DB), and then showing how you can integrate our file and data syncing infrastructure into your own application.

You will also learn how to work upstream with Debian (both pulling changes in and sending them back), how to properly and easily package your application for distribution, and of course how to work on contributing changes back to Ubuntu itself.

Last week saw the third annual Ubuntu Hardware Summit (UHS) taking place in Taipei. With over two hundred attendees present, the show is fast becoming one of the must-attend events within the software, ODM and OEM environments across Taiwan.

With standing room only at the back of the room during the Keynote speech, Canonical set the scene for the next two years including the growth of Ubuntu, the multitude of device enablement and an insight into Ubuntu Cloud and Ubuntu Server. After the Keynote, UHS then went into break-out Tracks which included topics on Ubuntu Cloud, Thin Client solutions, hardware enablement and Ubuntu System Architecture.

You can find all presentations from the day at odm.ubuntu.com and clicking the link ‘Download material’.

This year’s Ubuntu Hardware Summit (UHS) will take place on December 8th at the Grand Victoria Hotel in Taipei. You can register your place at www.ubuntu.com.uhs

Building on the success of 2010 (with over 200 attendees), the 2011 Ubuntu Hardware Summit promises to deliver more. With keynote speeches from various members of the Canonical team and a more focused technical delivery, UHS is created especially for product managers and engineers at ODMs and OEMs, with interest or responsibility in deploying Ubuntu on new computers and devices.

Highlights will include presentations on Ubuntu Server, deploying Ubuntu Cloud, QA, power management, hardware enablement….and much more! Details of the event can also be found on the new Ubuntu Hardware Debugging website at http://odm.ubuntu.com/portal/

UHS is sponsored by Canonical and free of charge.

To reserve your space, visit www.ubuntu.com/uhs today as registrations will close on 29th November 2011.

I’m always interested in what’s happening at Canonical and with Ubuntu. Last week at Hadoop World I ran into a couple of folks from the company (coincidentally both named Mark but neither Mr. Shuttleworth). Mark Mims from the server team was willing to chat so I grabbed some time with him to learn about what he was doing at Hadoop World and what in the heck is this “charming” Juju?

Some of the ground Mark covers

Making the next version of Ubuntu server better for Hadoop and big data

(0:34) What are “charms” and what do they have to do with service orchestration

It’s late, I’m tired, so this is going to be brief. But if I didn’t put something up now, chances are I’d procrastinate to the point where it didn’t matter anymore, so something is better than nothing.

JuJu

So the buzz all week was about Juju and Charms. It’s a very cool technology that I think is really going to highlight the potential of cloud computing. Until now I always had people comparing the cloud to virtual machines, telling me they already automate deploying VMs, but with Juju you don’t think about machines anymore, virtual of otherwise. It’s all about services, which is really what you want, a service that is doing something for you. You don’t need to care where, or on what, or in combination with some other thing, Juju handles all that automatically. It’s really neat, and I’m looking forward to using it more.

Summit

Summit worked this week. In fact, this is the first time in my memory where there wasn’t a problem with the code during UDS. And that’s not because we left it alone either. IS actually moved the entire site to a new server the day before UDS started. We landed several fixes during the week to fix minor inconveniences experienced by IS or the admins. And that’s not even taking into consideration all the last-minute features that were added by our Linaro developers the week prior. But through it all, Summit kept working. That, more than anything else, is testament to the work the Summit developers put in over the last cycle to improve the code quality and development processes, and I am very, very proud that. But we’re not taking a break this cycle. In fact, we had two separate sessions this week about ways to improve the user experience, and will be joined by some professional designers to help us towards that goal.

Ubuntu One eBook syncing

So what started off as an casual question to Stuart Langridge turned into a full blown session about how to sync ebook data using Ubuntu One. We brainstormed several options of what we can sync, including reading position, bookmarks, highlights and notes, as well as ways to sync them in an application agnostic manner. I missed the session on the upcoming Ubuntu One Database (U1DB), but we settled on that being the ideal way of handling this project, and that this project was an ideal test case for the U1DB. For reasons I still can’t explain, I volunteered to develop this functionality, at some point during the next cycle. It’s certainly going to be a learning experience.

Friends

Friends! It sure was good to catch up with all of you. Both friends from far-away lands, and those closer to home. Even though we chat on IRC almost constantly, there’s still nothing quite like being face to face. I greatly enjoyed working in the same room with the Canonical ISD team, which has some of the smartest people I’ve ever had the pleasure of working with. It was also wonderful to catch up with all my friends from the community. I don’t know of any other product or project that brings people together the way Ubuntu does, and I’m amazed and overjoyed that I get to be a part of it.

If you’ve been doing anything with Ubuntu lately, chances are you’ve been hearing a lot of buzz about Juju. If you’re attending UDS, then there’s also a good chance that you’ve been to one or more sessions about Juju. But do you know it?

The building blocks for Juju are it’s “charms”, which detail exactly how to deploy and configure services in the Cloud. Writing charms is how you harness the awesome power of Juju. Tomorrow (Friday) there will be a 2 hour session all about writing charms, everything from what they do and how they work, to helping you get started writing your own. Questions will be answers, minds will be inspired, things will be made, so don’t miss out.