Made possible by an internal innovation fund, project Sputnik is a 6 month effort to explore the possibility of creating an open source laptop targeted directly at developers.  It is based on Ubuntu 12.04 and Dell’s XPS13 laptop.

To put it in context, Sputnik is part of an effort by Dell to better understand and serve the needs of developers in Web companies.  We want to finds ways to make the developer experience as powerful and simple as possible.  And what better way to do that than beginning with a laptop that is both highly mobile and extremely stylish, running the 12.04 LTS release of Ubuntu Linux.

Why a developer laptop

When we first started setting up the web vertical to focus on companies who use the internet as their platform, we brought in Stephen O’Grady of Redmonk to learn as much as we could about the needs of developers.  One of the ideas that Stephen tossed out was a Dell laptop running Ubuntu, targeting developers.  We thought the idea was pretty cool and filed it away.

As we continued talking to customers and developers the topic of Ubuntu kept coming up and we came across a fair number of devs who were asking for a Dell laptop specifically based on it.  To my knowledge, no other OEM has yet made a system specifically targeted at devs and figured it was time to see what that might mean.  When the XPS13 launched we realized that we found the perfect platform to start with and when Dell’s incubation program was announced we knew I had the vehicle to get the effort kick started.

I should also add that Ubuntu was a natural choice not only because of its popularity in the Web world but Dell has quite a bit of experience with it.  In fact Dell has enabled and pre-installed out-of-the-factory Ubuntu on more computer models than any other OEM.

What’s Sputnik actually running?

The install image available for Sputnik contains

1. drivers/patches for Hardware enablement
2. a basic offering of key tools and utilities (see the complete list at the end of this entry)
3. coming soon, a software management tool to go out to a github repository to pull down various developer profiles.

Hardware enablement

In putting together the project, the area that we focused on first was hardware enablement.  As Linux users are all too painfully aware, Linux drivers are not always available for various platforms.  We have been working hand in hand with Canonical, the commercial sponsor behind Ubuntu and identified three main areas on the XPS13:

1. An issue with brightness
2. The Wifi hotkey
3. The touchpad and multi touch support

The first two have been resolved but the last one re the touchpad is still at large.  The issue is a bit of a pain particularly the lack of palm rejection support which can cause your cursor to jump by mistake.  We have contacted the vendor who makes the touchpad and they are sizing the effort to fix this and at the same time we are working with Canonical to find an interim solution.

Developer profile management

Hardware enablement is table stakes but where Sputnik starts to get interesting is when we talk about profiles.  No two developers are alike so instead of stuffing the system with every possible tool or app a developer could possibly want, we are trying a different approach.  As mentioned above, the actual “stuff” on the install image is pretty basic, instead we are working with a few developers to put together a tool that can go out to a github repository and pull down various developer profiles.  The first profiles we are targeting are Android, Ruby and JavaScript.

As a one of our alpha cosmonauts, Charles Lowell, explained (we have been working with three local developers in Austin, Charles, Mike Pav and Dustin Kirkland to put together our initial offering together.   And yes I know Sputnik was unmanned but its our project and we wanted to call the testers “cosmonauts.” )

What I’d like to see is not only a gold-standard configuration, but also a meta-system to manage your developer configuration… The devops revolution is about configuration as code. How cool would it be if my laptop configuration were code that I could store in a source repo somewhere?

After we build the management tool and some basic profiles to get the effort started, we are hoping that the community will take over and began creating profiles of their own.

Getting Feedback and UDS activities

The idea is to conduct project Sputnik out in the open.  There is a Storm Session that went live this morning on Dell Idea Storm for people to discuss the project and submit feedback, comments and ideas.  Later today here at the Ubuntu Developer Summit, Dustin, Mario Limonciello of Dell and I will be hosting a UDS session to discuss Sputnik.  Additionally at UDS there is a coding contest that has been kicked off.  The three people who write the best Juju charms will each get an XPS13.

The Vision: a Launchpad to the cloud

As mentioned at the start, Sputnik is currently a 6month project to investigate an Ubuntu laptop.  If successful, we have big plans for the effort.

When we initially pitched Sputnik to Ubuntu’s founder Mark Shuttleworth a couple months ago he really liked the idea.  In his eyes however, he saw something bigger.  Where it got really interesting for him was when this laptop was optimized for DevOps.  In this scenario we would have a common set of tools from client, to test, to production, thereby tying Sputnik via a common tool chain to a cloud backend powered by OpenStack.  Developers could create “micro clouds” locally and then push them to the cloud writ large.

We see a lot of potential in Sputnik to provide developers with a simple and powerful tool.  Only time will tell however so stay tuned to this blog, check out the Sputnik Storm session and weigh in on the project, what you’d like to see and how you think it can be made better.

Pau for now…

Extra-credit reading

• Ubuntu 12.04 LTS (Precise Pangolin) Review | Desktop OS | ZDNet
• Ferreting out Innovation

Links and notes

•  Sputnik Storm session on idea storm

• Sputnik install image

Touchpad issue

Current behavior is that the touchpad functions as a basic pointing device, but lacks some desirable functionality:

1. Pinch, zoom, & flick
2. Palm negation (esp. important on larger touchpads where it’s easy for your hand to inadvertently touch the surface)
3. Side/edge scrolling
4. Two finger scrolling

We have contacted the vendor who makes the touchpad and they are sizing the effort to fix this and at the same time we are working with Canonical to find an interim solution.

Basic Install

== standard meta packages ==

ubuntu-desktop^

standard^

== scm ==

git

git-core

bzr

bzr-gtk

bzr-git

python-launchpadlib

== utilities ==

screen

byobu

tmux

meld

juju

charm-tools

charm-helper-sh

euca2ools

puppet

chef (available post install)

== editors ==

emacs

vim

vim-gnome

== browsers ==

chromium-browser

firefox

== common build tools/utilities & dependencies == fakeroot build-essential crash kexec-tools kvm makedumpfile kernel-wedge fwts devscripts

libncurses5

libncurses5-dev

libelf-dev

asciidoc

binutils-dev

So how can you win yourself one of these? Well, with 66 services already ready to be deployed on the cloud we’re always looking for more, so have a look at what you think is missing from the Juju Charm Store and submit your charm as an entry.

We’ve got the step-by-step instructions on how to write your own charm, we’re looking for things DevOps deploy to the cloud, so be creative! You have from now until May 09 to submit your charm. At that point we’ll judge the entries, and then give out the Dell XPS 13′s during the last day of the Ubuntu  Developer Summit, so if you’re missing your favorite service from the Charm Store, submit an entry and you’ll automatically be entered in the contest.

Full contest rules here, including the judging criteria, so you’ll want to read that before you get started. Happy Charming!

Pull Requests or filing Issue’s are more than Welcome’d from anyone.

Need help getting started with juju? Check out our Getting Started documentation and then browse through the Charm Store to see what you can start deploying today!

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

The folks over at Google released a new snapshot of mod_spdy for use with Apache.

Thinking this would be a cool way to show off juju’s subordinate feature, Clint Byrum got to work and hacked together a mod_spdy subordinate charm; which means (assuming it works), that we can just tack it onto things serving via Apache and get mod_spdy relatively easy for all the charms that would use it in the store. Neat huh?

Here it is:

http://jujucharms.com/~clint-fewbar/precise/mod-spdy

And here’s how you’d test it:

juju deploy wordpress
juju deploy mysql
juju add-relation mysql wordpress
juju expose wordpress
juju deploy cs:~clint-fewbar/precise/mod-spdy
juju add-relation mod-spdy wordpress

Clint realized that juju does not allow subordinates to open ports for their primaries, so you have to use the open-port script in juju-jitsu.

To do that, after you’ve done the steps above:

bzr branch lp:juju-jitsu
juju-jitsu/sub-commands/open-port your-primary-service 443

https://your-public-ip/ should be SSL, and should be using SPDY if you try it in Chrome/Chromium/Firefox.

This is a rough cut, and not in the charm store yet for obvious reasons, and when I tested it it didn’t even serve the right page, but, at least the error was served over SPDY, heh. But you can immediately see that by using a subordinate charm you can add on a feature to an existing charm, making it a nice way to test something new and shiny.

We’re in #juju on freenode if you want to start whacking on this and making it more deployable, find bugs, and finish the implementation, we can then make this a nice option for Ubuntu Server users. Happy spdying!

This week, William “I code more than you will ever be able to” Reade announced that Juju has a new feature called ‘Constraints’.

This is really, really cool and brings juju into a new area of capability for deploying big and little sites.

To be clear, this allows you to abstract things pretty effectively.

Consider this:

juju deploy mysql --constraints mem=10G
juju deploy statusnet --constraints cpu=1

This will result in your mysql service being on an extra large instance since it has 15GB of RAM. Your statusnet instances will be m1.small’s since that will have just 1 ECU.

Even cooler than this is now if you want a mysql slave in a different availability zone:

juju deploy mysql --constraints ec2-zone=a mysql-a
juju deploy mysql --constraints ec2-zone=b mysql-b
juju add-relation mysql-a:master mysql-b:slave
juju add-relation statusnet mysql-a

Now if mysql-a goes down

juju remove-relation statusnet mysql-a
juju add-relation statusnet mysql-b

Much and more is possible, but this really does make juju even more compelling as a tool for simple, easy deployment. Edit: fixed ec2-zone to be the single character, per William’s feedback.

The event takes place on Tuesday 8th May, at the The Oakland Marriott City Center Hotel, and runs in conjunction with UDS.

The agenda is still being defined, but the sessions will cover some interesting ideas, challenges and trends around cloud computing and how attendees can deploy an open cloud in their organisation.

Topics will include:

• The Open Cloud - The role of open source in cloud computing—particularly how an open cloud enables a more flexible, vendor-neutral approach.
• Lessons from cloud deployments - Open cloud deployments are real and growing. We’ll discuss and illustrate through case studies the best approaches to deploying and maximising an open cloud.
• Open-source cloud technologies - With Ubuntu including technologies such as OpenStack, MAAS and Juju, we’ll examine how they come together to form an open cloud.

For more information, visit: http://uds.ubuntu.com/cloud-summit/

The cost of a ticket for attending this event is $100 which includes lunch and refreshments.

The Grand Prize ($300 Amazon Gift Card) goes to Jimmi Andersen for his charm that deploys Appflower, a Rapid Application Development (RAD) tool for building web applications. You can check out the charm in the store for deployment instructions. The judges were impressed by how complete the charm is and how it brings software to Ubuntu that was previously only available by installing it by hand.

The 2 runners up (in no particular order) are Kees Cook for sbuild, and Ben Kerensa for Subway. sbuild provides a build environment for developers to test packages against and has been used for portable “hackathons” where having the packages build on the cloud is quicker and more convenient than building on your local machines. The Subway charm deploys the Subway IRC client, a sexy web based IRC client that uses Node.js and MongoDB. Thanks Ben and Kees, you’ll each receive a $100 Amazon gift card.

The charm store continues to grow as we now have over 73 total charms. The following people contributed charms to the contest and will each receive a Juju tshirt and Ubuntu travel mug: Patrick Hetu (znc and OpenERP), Atul Jha (OwnCloud), Nathan Osman (StackMobile), shazzner (Gitolite), and Brandon Holtsclaw (Drupal). Honorable mention goes to Ryan Kather, who attempted Moodle but was not able to complete it in time. Maybe next time! We’ll go deeper into these charms and show off their examples throughout the coming weeks.

Not finding what you need in the Charm Store? Well you can always contribute your own charms, here’s how you can get started.

The authenticity of host 'ec2-...' can't be established. ECDSA key fingerprint is ca:79:72:ea:23:94:5e:f5:f0:b8:c0:5a:17:8c:6f:a8. Are you sure you want to continue connecting (yes/no)? 

I don’t need this ssh session encrypted. It’s fine for any man-in-the-middle to intercept the communication.

# DON'T DO THIS! StrictHostKeyChecking false 

Care about security

Passing ssh host key to new EC2 instance

tmpdir=$(mktemp -d /tmp/ssh-host-key.XXXXXX) keyfile=$tmpdir/ssh_host_ecdsa_key ssh-keygen -q -t ecdsa -N "" -C "" -f $keyfile 

userdatafile=$tmpdir/set-ssh-host-key.user-data cat <<EOF >$userdatafile #!/bin/bash -xeu cat <<EOKEY >/etc/ssh/ssh_host_ecdsa_key $(cat $keyfile) EOKEY cat <<EOKEY >/etc/ssh/ssh_host_ecdsa_key.pub $(cat $keyfile.pub) EOKEY EOF 

ec2-run-instances --key $USER --user-data-file $userdatafile ami-4dad7424 instanceid=i-... 

ec2-describe-instances $instanceid host=ec2-...compute-1.amazonaws.com 

knownhosts=$HOME/.ssh/known_hosts ssh-keygen -R $host -f $knownhosts ssh-keygen -R $(dig +short $host) -f $knownhosts ( echo -n "$host "; cat $keyfile.pub echo -n "$(dig +short $host) "; cat $keyfile.pub ) >> $knownhosts 

ssh ubuntu@$host 

rm -rf $tmpdir ec2-terminate-instances $instanceid 

Caveat

1. Upload the new ssh host key to S3 in a private object.
2. Generate an authenticated URL to the S3 object and have that URL expire in, say, 10 minutes.
3. In the user-data script, download the ssh host key with the authenticated, expiring S3 URL.

UK cloud provider Brightbox would like to announce that they now have daily images of Ubuntu 12.04 available for testing. Brightbox has an EC2 compatible metadata service that works with Ubuntu’s cloud-init, you can find more about that in the documentation.

As a thank you to the Ubuntu community Brightbox is running a special through to September. A 10% discount to casual testers, and a 50% discount to anyone registering using their @ubuntu.com address.

Testers can sign up at http://brightbox.com/, and to claim the discount you just need to email support@brightbox.com with your account id and let them know how you’re testing out Ubuntu.

Here’s their Getting Started guide. Happy testing!