This is a series of posts on reasons to choose Ubuntu for your public or private cloud work & play.
We run an extensive program to identify issues and features that make a difference to cloud users. One result of that program is that we pioneered dynamic image customisation and wrote cloud-init. I’ll tell the story of cloud-init as an illustration of the focus the Ubuntu team has on making your devops experience fantastic on any given cloud.
Ever struggled to find the “right” image to use on your favourite cloud? Ever wondered how you can tell if an image is safe to use, what keyloggers or other nasties might be installed? We set out to solve that problem a few years ago and the resulting code, cloud-init, is one of the more visible pieces Canonical designed and built, and very widely adopted.
Traditionally, people used image snapshots to build a portfolio of useful base images. You’d start with a bare OS, add some software and configuration, then snapshot the filesystem. You could use those snapshots to power up fresh images any time you need more machines “like this one”. And that process works pretty amazingly well. There are hundreds of thousands, perhaps millions, of such image snapshots scattered around the clouds today. It’s fantastic. Images for every possible occasion! It’s a disaster. Images with every possible type of problem.
The core issue is that an image is a giant binary blob that is virtually impossible to audit. Since it’s a snapshot of an image that was running, and to which anything might have been done, you will need to look in every nook and cranny to see if there is a potential problem. Can you afford to verify that every binary is unmodified? That every configuration file and every startup script is safe? No, you can’t. And for that reason, that whole catalogue of potential is a catalogue of potential risk. If you wanted to gather useful data sneakily, all you’d have to do is put up an image that advertises itself as being good for a particular purpose and convince people to run it.
There are other issues, even if you create the images yourself. Each image slowly gets out of date with regard to security updates. When you fire it up, you need to apply all the updates since the image was created, if you want a secure machine. Eventually, you’ll want to re-snapshot for a more up-to-date image. That requires administration overhead and coordination, most people don’t do it.
That’s why we created cloud-init. When your virtual machine boots, cloud-init is run very early. It looks out for some information you send to the cloud along with the instruction to start a new machine, and it customises your machine at boot time. When you combine cloud-init with the regular fresh Ubuntu images we publish (roughly every two weeks for regular updates, and whenever a security update is published), you have a very clean and elegant way to get fresh images that do whatever you want. You design your image as a script which customises the vanilla, base image. And then you use cloud-init to run that script against a pristine, known-good standard image of Ubuntu. Et voila! You now have purpose-designed images of your own on demand, always built on a fresh, secure, trusted base image.
Auditing your cloud infrastructure is now straightforward, because you have the DNA of that image in your script. This is devops thinking, turning repetitive manual processes (hacking and snapshotting) into code that can be shared and audited and improved. Your infrastructure DNA should live in a version control system that requires signed commits, so you know everything that has been done to get you where you are today. And all of that is enabled by cloud-init. And if you want to go one level deeper, check out Juju, which provides you with off-the-shelf scripts to customise and optimise that base image for hundreds of common workloads.
I just want to say how touched I have been by the response. The comments, social media posts, emails, and calls from you have been so kind and supportive. You are all good people, and I am going to miss every single one of you.
The reason why I have devoted my life to understanding communities is that I believe communities bring out the best in people, and all of you are a perfect example of that. I cannot express just how much I appreciate it.
Over the course of the next few weeks my replacement will be sourced and announced. and in the interim my team (Daniel Holbach, Michael Hall, David Planella, Nicholas Skaggs, Alan Pope) will take over my duties. Everything has been transitioned over, and remember, the weekly Q&As will continue at 6pm UTC every Tuesday on Ubuntu On Air with my team filling in for me. As ever, any and all Ubuntu questions are welcome!
Of course, I will still be around. I am going to continue to be a member of the Ubuntu community and an avid Ubuntu user, tester, and supporter. I will continue to be on IRC, you can email me at email@example.com, I will continue to do Bad Voltage, and I have a busy schedule at the Community Leadership Summit, OSCON, and more. I am also going to continue to have my own Q&A session every week where you can ask questions about my perspectives on Ubuntu, Canonical, community management, XPRIZE, and more; I will announce this soon.
Ubuntu has a tremendous future ahead of it, built on the hard work and passion of a global community. We are only just getting started with a new era of Ubuntu convergence and cloud orchestration and while I will miss being there in an official capacity, I am just thankful that I can continue to be along for the ride in the very community I played a part in building.
I now have a few weeks off and then my new adventure begins. Stay tuned.
Last year the main Ubuntu download page was changed to include a form for users to make a donation to one or more parts of Ubuntu, including to the community itself. Those donations made for “Community projects” were made available to members of our community who knew of ways to use them that would benefit the Ubuntu project.
Every dollar given out is an investment in Ubuntu and the community that built it. This includes sponsoring community events, sending community representatives to those events with booth supplies and giveaway items, purchasing hardware to make improve development and testing, and more.
But these expenses don’t cover the time, energy, and talent that went along with them, without which the money itself would have been wasted. Those contributions, made by the recipients of these funds, can’t be adequately documented in a financial report, so thank you to everybody who received funding for their significant and sustained contributions to Ubuntu.
As part of our commitment to openness and transparency we said that we would publish a report highlighting both the amount of donations made to this category, and how and where that money was being used. Linked below is the first of those reports.
The following is a guest post by Ian Booth:
Juju has the ability to set up and change logging levels at a package level so that problems within a particular area can be better diagnosed. Recently there were some issues with containers (both kvm and lxc) started by the local provider transitioning from pending to started. We wanted to be able to inspect the sequence of commands Juju uses to start a container. Fortunately, the Juju code which starts lxc and kvm containers does log out the actual commands used to download the requisite image and start the container et al. The logging level used for this information is TRACE. By default, Juju machine agents log at the debug level, and this information can be seen when running ‘juju debug-log’. So unfortunately, this means the information we are interested in is not visible by default in the machine logs.
Luckily we can change the logging level used for particular packages so that the information is logged. This is done using the ‘logging-config’ attribute and can either be done at bootstrap:juju bootstrap --logging-config=golxc=TRACE
or on a running system:juju set-env logging-config=golxc=TRACE
As an aside, you can use:juju get-env logging-config
to see what the current logging-config value is.
The logging-config value above turns on TRACE level dubugging for the golxc package, which is responsible for starting and managing lxc containers on behalf of Juju. For kvm containers, the package name is ‘kvm’.
We can use debug-log to look at the logging we have just enabled. As of 1.19 onwards, filtering can be used to just show what we are interested in. Run this command in a separate terminal:juju debug-log --include-module=golxc
Now we can deploy a charm or use add-machine to initiate a new container. We can see the commands Juju issues to download the image and start the container. This allows us to see what parameters are passed in to the various lxc commands, and we could even manually run the commands if we wish, in order to reproduce and examine in more detail how the commands behave. An example of the logging information when adding TRACE level debugging to lxc startup looks like:machine-0: 2014-05-27 04:28:39 TRACE golxc.run.lxc-start golxc.go:439 run: lxc-start [--daemon -n ian-local-machine-1 -c /var/lib/juju/containers/ian-local-machine-1/console.log -o /var/lib/juju/containers/ian-local-machine-1/container.log -l DEBUG] machine-0: 2014-05-27 04:28:40 TRACE golxc.run.lxc-ls golxc.go:439 run: lxc-ls [-1] machine-0: 2014-05-27 04:28:41 TRACE golxc.run.lxc-ls golxc.go:451 run successful output: ian-local-machine-1 machine-0: 2014-05-27 04:28:41 TRACE golxc.run.lxc-info golxc.go:439 run: lxc-info [-n ian-local-machine-1] machine-0: 2014-05-27 04:28:41 TRACE golxc.run.lxc-info golxc.go:451 run successful output: Name: ian-local-machine-1 machine-0: 2014-05-27 04:28:45 TRACE golxc.run.lxc-start golxc.go:448 run failed output: lxc-start: command get_cgroup failed to receive response machine-0: 2014-05-27 04:29:45 TRACE golxc.run.lxc-ls golxc.go:439 run: lxc-ls [-1] machine-0: 2014-05-27 04:29:45 TRACE golxc.run.lxc-ls golxc.go:451 run successful output: ian-local-machine-1 machine-0: 2014-05-27 04:29:45 TRACE golxc.run.lxc-info golxc.go:439 run: lxc-info [-n ian-local-machine-1] machine-0: 2014-05-27 04:29:45 TRACE golxc.run.lxc-info golxc.go:451 run successful output: Name: ian-local-machine-1
You can see that when logging the various commands execute, the format is cmd [arg arg arg]. So to run these manually leave out the . You can also see that there was a problem starting the lxc container due to a cgroups issue. This error is shown in juju status, but often it’s useful to see what happens leading up to the error occurring.
In summary, Juju’s configurable logging output can be used to help diagnose issues and understand what Juju is doing under the covers. It offers the ability to turn on extra logging when required, and it can be turned off again when no longer required.
This post is part of the series ‘Making ubuntu.com responsive‘.
A big part of converting our existing fixed-width desktop site to be responsive was to make sure we had a flexible grid that would flow seamlessly from small to large screens.
From the start, we decided that we were going to approach the move as simply as possible: we wanted the content our grid holds to become easier to read and browse on any screen size, but that doesn’t necessarily mean creating anything too complex.Our existing fixed-width grid
Before the transition, our grid consisted of 12 columns with 20px gutters.
The width of each column could be variable, but we were working with 57px columns and 40px padding on each side of the main content container.
Our existing fixed-width desktop grid.
Inside that grid, content can be divided into one, two, three or four columns. In extreme cases, we can also use five columns, but we avoid this.
Our grid laid over an existing page of the site.
We also try keeping text content below eight columns, as it becomes harder to read otherwise.Adding flexibility
When we first created our web style guide, we decided that, since we were getting our hands dirty with the refactoring of the CSS, we’d go ahead and convert our grid to use percentages instead of pixels.
The idea was that it would be useful for the future, while keeping everything looking almost exactly the same, since the content would still be all held within a fixed-width container for the time being.
A fixed-width container holding percentage-based columns.
This proved one of the best decisions we made and it made the transition to responsive much smoother than we initially thought.The CSS
We used Gridinator to initially create our basic grid, removed any unnecessary rules and properties from the CSS it generated and added others we needed.
The settings we’ve input, in case you’re wondering, were:
- Number of columns: 12
- Column width: 57px
- Column margins: 20px (technically, the gutters)
- Container margin: 40px
- Body font size: 16px
- Option: percentage units
Screenshot of our Gridinator settings.
We could have created this CSS from scratch, but we found this tool saved us some precious time when creating all the variations we needed when using the grid.
You can have a peek into our current grid stylesheet now.First prototypes
The first two steps we took when creating the initial responsive prototype of ubuntu.com were:
- Remove the fixed-width container and see how the content would flow freely and fluidly
- Remove all the floats and positioning rules from the existing CSS and see how the content would flow in a linear manner, and test this on small screen devices
When we removed the fixed-width container, all the content became fluid. Obviously, there were no media queries behind this, so the content was free to grow to huge sizes, with really long line lengths, and equally the columns could shrink to unreasonably narrow sizes. But it was fluid, and we were happy!
Similarly, when checking the float-free prototype, even though there were quite a few issues with background images and custom, absolutely positioned elements, the results were promising.
Our first float-free prototype: some issues but overall a good try.
These tests showed to us that, even though the bulk of the work was still ahead of us, a lot had been accomplished by simply making the effort to convert our initial pixel-based columns into percentage based ones. This is a test that we think other teams could be able to do, before moving on to a complete revamp of their CSS.Defining breakpoints
We didn’t want to relate our breakpoints to specific devices, but it was important that we understood what kind of screen sizes people were using to visit our site on.
To give you an idea, here are the top 10 screen sizes (not window size, mind) between 4 March and 3 April 2014, in pixels, on ubuntu.com:
- 1366 x 768: 26.15%
- 1920 x 1028: 15.4%
- 1280 x 800: 7.98%
- 1280 x 1024: 7.26%
- 1440 x 900: 6.29%
- 1024 x 768: 6.26%
- 1600 x 900: 5.51%
- 1680 x 1050: 4.94%
- 1920 x 1200: 2.73%
- 1024 x 600: 2.12%
The first small screen (360×640) comes up at number 17 in the list, followed by 320×568 and 320×480 at numbers 21 and 22, respectively.
We decided to test the common approach and try breakpoints at:
- Under 768px: small screen styles
- Between 768px and under 986px: medium screen styles
- 986px and up: large screen styles
This worked well for our content and was in line with what we had seen in our analytics numbers.
At the small screen breakpoint we have:
- Reduced typographic scale
- Reduced margins and padding
- Reduced main content container padding
At this scale, following what we had done in Ubuntu Resources (now Ubuntu Insights), we reused the grid from the Ubuntu phone designs, which divides the portrait screen into 40 squares, horizontally.
The phone grid.
At the medium screen breakpoint we have:
- Increased (from small screen) typographic scale
- Increased margins and padding
- Increased main content container padding
At the large screen break point we have:
- The original typographic scale
- The original margins and padding
- The original main content container padding
Comparison between small, medium and large screen spacing.Ideas for the future
In the future, we would like to use more component-specific breakpoints. Some of our design components would work better if they reflowed or resized at different points than the rest of the site, so more granular control over specific elements would be useful. This usually depends on the type and amount of content the component holds.
What about you? We’d love to know how other people have tackled this issue, and what suggestions you have to create flexible and robust grids. Have you used any useful tools or techniques? Let us know in the comments section.Reading list
As many of you will know, I organize an event every year called the Community Leadership Summit. The event brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community.
The event pulls together these leading minds in community management, relations and online collaboration to discuss, debate and continue to refine the art of building an effective and capable community.
The event is taking place on 18 – 19 July 2014 in Portland, Oregon. I hope to see you all there, it is going to be a fantastic CLS this year!
I also have a few other things to share too…Community Leadership Forum
My goal as a community manager is to help contribute to the growth of the community management profession. I started this journey by publishing The Art of Community and ensuring it is available freely as well as in stores. I then set up the Community Leadership Summit as just discussed, and now I am keen to put together a central community for community management and leadership discussion.
As such, I am proud to launch the new Community Leadership Forum for discussing topics that relate to community management, as well as topics for discussion at the Community Leadership Summit event each year. The forum is designed to be a great place for sharing and learning tips and techniques, getting to know other community leaders, and having fun.
Be sure to go and sign up!Speaking Events and Training
I also wanted to share that I will be at OSCON this year and I will be giving a presentation called Dealing With Disrespect that is based upon my free book of the same name for managing complex communications.
This is the summary of the talk:
In this new presentation from Jono Bacon, author of The Art of Community, founder of the Community Leadership Summit, and Ubuntu Community Manager, he discusses how to process, interpret, and manage rude, disrespectful, and non-constructive feedback in communities so the constructive criticism gets through but the hate doesn’t.
The presentation covers the three different categories of communications, how we evaluate and assess different attributes in each communication, the factors that influence all of our communications, and how to put in place a set of golden rules for handling feedback and putting it in perspective.
If you personally or your community has suffered rudeness, trolling, and disrespect, this presentation is designed to help.
This presentation is on Wed 23rd July at 2.30pm in E144.
In addition to this I will also be providing a full day of community management training at OSCON on Sunday 20th July in D135.
Lots of fun things ahead and I hope to see you there!
Want to do a test boot of a powerpc machine, but don't have one handy? The qemu ppc64-softmmu emulator is currently working well with the pseries target, and it's fairly simple to get an emulated machine booting.
You'll need qemu version 1.6.0 or above. If this isn't provided by your distribution, you can build from upstream sources:git clone git://git.qemu-project.org/qemu.git cd qemu ./configure --target-list=ppc64-softmmu make
the resulting qemu binary will be at ./ppc64-softmmu/qemu-system-ppc64.
To run a pseries-like machine, we just need the -M pseries option.
The default qemu device setup is okay, but I tend to configure my qemu a little differently: no video, and console on serial ports. This is what I generally do:qemu-system-ppc64 -M pseries -m 1024 \ -nodefaults -nographic -serial pty -monitor stdio \ -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \ -kernel vmlinux -initrd initrd.img -append root=/dev/ram0
This will print out a message telling you which PTY is being used for the serial port:[jk@pablo qemu]$ qemu-system-ppc64 -M pseries -m 1024 \ -nodefaults -nographic -serial pty -monitor stdio \ -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \ -kernel vmlinux -initrd initrd.img -append root=/dev/ram0 char device redirected to /dev/pts/11 (label serial0) QEMU 1.6.0 monitor - type 'help' for more information (qemu)
You can then interact with the emulated serial device from a separate terminal, using screen:screen /dev/pts/11
In the screen session, the sequence ctrl+a, ctrl+k will exit. Typing quit at the (qemu) prompt will terminate the virtual machine.emulated network devices
The qemu environment above uses virtio-based networking, which may not work if your kernel doesn't include a virtio-net driver. In this case, just replace the -device virtio-net-pci,netdev=net0 argument with:-device spapr-vlan,netdev=net0 emulated block devices
The qemu example above doesn't define any block devices, so there's no persistent storage available. We can use either the spapr-vscsi (sPAPR virtual SCSI, the virtualised IBM hypervisor interface) or virtio-blk-pci (virtio interface) devices. This choice will depend on your kernel; if it includes drivers for virtio, I'd suggest using that.
For virtio, add something like:-device virtio-blk-pci,drive=drive0 -drive id=drive0,if=none,file=/path/to/host/storage
For sPAPR virtual SCSI, use something like:-device spapr-vscsi -device scsi-hd,drive=drive0 -drive id=drive0,if=none,file=/path/to/host/storage
Either of these will define a qemu drive with id "drive0", and attach it to backing storage at /path/to/host/storage - this can be a plain file or block device. If you'd like to define multiple guest block devices, you need to use new ids (drive1, drive2, …) for both -device and -drive arguments.
A couple of months ago Jono announced the dates for the Ubuntu Online Summit, June 10th – 12th, and those dates are almost upon us now. The schedule is opened, the track leads are on board, all we need now are sessions. And that’s where you come in.
Ubuntu Online Summit is a change for us, we’re trying to mix the previous online UDS events with our Open Week, Developer Week and User Days events, to try and bring people from every part of our community together to celebrate, educate, and improve Ubuntu. So in addition to the usual planning sessions we had at UDS, we’re also looking for presentations from our various community teams on the work they do, walk-throughs for new users learning how to use Ubuntu, as well as instructional sessions to help new distro developers, app developers, and cloud devops get the most out of it as a platform.
What we need from you are sessions. It’s open to anybody, on any topic, anyway you want to do it. The only requirement is that you can start and run a Google+ OnAir Hangout, since those are what provide the live video streaming and recording for the event. There are two ways you can propose a session: the first is to register a Blueprint in Launchpad, this is good for planning session that will result in work items, the second is to propose a session directly in Summit, which is good for any kind of session. Instructions for how to do both are available on the UDS Website.
There will be Track Leads available to help you get your session on the schedule, and provide some technical support if you have trouble getting your session’s hangout setup. When you propose your session (or create your Blueprint), try to pick the most appropriate track for it, that will help it get approved and scheduled faster.Ubuntu Development
Many of the development-oriented tracks from UDS have been rolled into the Ubuntu Development track. So anything that would previously have been in Client, Core/Foundations or Cloud and Server will be in this one track now. The track leads come from all parts of Ubuntu development, so whatever you session’s topic there will be a lead there who will be familiar with it.Track Leads:
- Łukasz Zemczak
- Steve Langasek
- Leann Ogasawara
- Antonio Rosales
- Marc Deslaurs
Introduced a few cycles back, the Application Development track will continue to have a focus on improving the Ubuntu SDK, tools and documentation we provide for app developers. We also want to introduce sessions focused on teaching app development using the SDK, the various platform services available, as well as taking a deeper dive into specifics parts of the Ubuntu UI Toolkit.Track Leads:
- Michael Hall
- David Planella
- Alan Pope
- Zsombor Egri
- Nekhelesh Ramananthan
This is the counterpart of the Application Development track for those with an interest in the cloud. This track will have a dual focus on planning improvements to the DevOps tools like Juju, as well as bringing DevOps up to speed with how to use them in their own cloud deployments. Learn how to write charms, create bundles, and manage everything in a variety of public and private clouds.Track Leads:
- Jorge Castro
- Marco Ceppi
- Patricia Gaughen
- Jose Antonio Rey
The community track has been a stable of UDS for as long as I can remember, and it’s still here in the Ubuntu Online Summit. However, just like the other tracks, we’re looking beyond just planning ways to improve the community structure and processes. This time we also want to have sessions showing users how they can get involved in the Ubuntu community, what teams are available, and what tools they can use in the process.Track Leads:
- Daniel Holbach
- Jose Antonio Rey
- Laura Czajkowski
- Svetlana Belkin
- Pablo Rubianes
This is a new track and one I’m very excited about. We are all users of Ubuntu, and whether we’ve been using it for a month or a decade, there are still things we can all learn about it. The focus of the Users track is to highlight ways to get the most out of Ubuntu, on your laptop, your phone or your server. From detailed how-to sessions, to tips and tricks, and more, this track can provide something for everybody, regardless of skill level.Track Leads:
- Elizabeth Krumbach Joseph
- Nicholas Skaggs
- Valorie Zimmerman
So once again, it’s time to get those sessions in. Visit this page to learn how, then start thinking of what you want to talk about during those three days. Help the track leads out by finding more people to propose more sessions, and let’s get that schedule filled out. I look forward to seeing you all at our first ever Ubuntu Online Summit.
[...] start using the emulator for everything you usually would do on the phone. We really want to make the emulator a class A engineering platform for everyone
While the final emulator is still work in progress, we’re continually seeing the improvements in finishing all the pieces to make it a first-class citizen for development, both for the platform itself and for app developers. However, as it stands today, the emulator is already functional, so I’ve decided to prepare a quickstart guide to highlight the great work the Foundations and Phonedations teams (along with many other contributors) are producing to make it possible.
While you should consider this as guide as a preview, you can already use it to start getting familiar with the emulator for testing, platform development and writing apps.Requirements
To install and run the Ubuntu emulator, you will need:
- Ubuntu 14.04 or later (see installation notes for older versions)
- 512MB of RAM dedicated to the emulator
- 4GB of disk space
- OpenGL-capable desktop drivers (most graphics drivers/cards are)
If you are using Ubuntu 14.04, installation is as easy as opening a terminal, pressing Ctrl+Alt+T and running these commands, followed by Enter:
sudo add-apt-repository ppa:ubuntu-sdk-team/ppa && sudo apt-get update
sudo apt-get install ubuntu-emulator
Alternatively, if you are running an older stable release such as Ubuntu 12.04, you can install the emulator by manually downloading its packages first:Show me how
- Create a folder named MARKDOWN_HASHb3eeabb8ee11c2be770b684d95219ecbMARKDOWN_HASH in your home directory
- Go to the goget-ubuntu-touch packages page in Launchpad
- Scroll down to Trusty Tahr and click on the arrow to the left to expand it
- Scroll further to the bottom of the page and click on the MARKDOWN_HASH05556613978ce6821766bb234e2ff0f2MARKDOWN_HASH package corresponding to your architecture (i386 or amd64) to download in the MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder you created
- Now go to the Android packages page in Launchpad
- Scroll down to Trusty Tahr and click on the arrow to the left to expand it
- Scroll further to the bottom of the page and click on the MARKDOWN_HASH1843750ed619186a2ce7bdabba6f8062MARKDOWN_HASH package corresponding to download it at the same MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder
- Open a terminal with Ctrl+Alt+T
- Change the directory to the location where you downloaded the package writing the following command in the terminal: MARKDOWN_HASH8844018ed0ccc8c506d6aff82c62c46fMARKDOWN_HASH
- Then run this command to install the packages: MARKDOWN_HASH0452d2d16235c62b87fd735e6496c661MARKDOWN_HASH
- Once the installation is successful you can close the terminal and remove the MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder and its contents
- Downloaded images are cached at ~/.cache/ubuntuimage –using the standard XDG_CACHE_DIR location.
- Instances are stored at ~/.local/share/ubuntu-emulator –using the standard XDG_DATA_DIR location.
- While an image upgrade feature is in the works, for now you can simply create an instance of a newer image over the previous one.
The ubuntu-emulator tool makes it again really easy to manage instances and run the emulator. Typically, you’ll be opening a terminal and running these commands the first time you create an instance (where myinstance is the name you’ve chsen for it):
sudo ubuntu-emulator create myinstance --arch=i386
ubuntu-emulator run myinstance
You can create any instances you need for different purposes. And once the instance has been created, you’ll be generally using the ubuntu-emulator run myinstance command to start an emulator session based on that instance.
Notice how in the command above the --arch parameter was specified to override the default architecture (armhf). Using the i386 arch will make the emulator run at a (much faster) native speed.
Other parameters you might want to experiment with are also: --scale=0.7 and --memory=720. In these examples, we’re scaling down the UI to be 70% of the original size (useful for smaller screens) and specifying a maximum of 720GB for the emulator to use (on systems with memory to spare).
There are 3 main elements you’ll be interacting with when running the emulator:
- The phone UI – this is the visual part of the emulator, where you can interact with the UI in the same way you’d do it with a phone. You can use your mouse to simulate taps and slides. Bonus points if you can recognize the phone model where the UI is in ;)
- The remote session on the terminal – upon starting the emulator, a terminal will also be launched alongside. Use the phablet username and the same password to log in to an interactive ADB session on the emulator. You can also launch other terminal sessions using other communication protocols –see the link at the end of this guide for more details.
- The ubuntu-emulator tool – with this CLI tool, you can manage the lifetime and runtime of Ubuntu images. Common subcommands of ubuntu-emulator include create (to create new instances), destroy (to destroy existing instances), run (as we’ve already seen, to run instances), snapshot (to create and restore snapshots of a given point in time) and more. Use ubuntu-emulator --help to learn about these commands and ubuntu-emulator command --help to learn more about a particular command and its options.
- Make sure you’ve got enough space to install the emulator and create new instances, otherwise the operation will fail (or take a long time) without warning.
- At this time, the emulator takes a while to load for the first time. During that time, you’ll see a black screen inside the phone skin. Just wait a bit until it’s finished loading and the welcome screen appears.
- By default the latest built image from the devel-proposed channel is used. This can be changed during creation with the --channel and --revision options.
- If your host has a network connection, the emulator will use that transparently, even though the network indicator might show otherwise.
- To talk to the emulator, you can use standard adb. The emulator should appear under the list of the adb devices command.
I hope this guide has whetted your appetite to start testing the emulator! You can also contribute making the emulator a first-class target for Ubuntu development. The easiest way is to install it and give it ago. If something is not working you can then file a bug.
If you want to fix a bug yourself or contribute to code, the best thing is to ask the developers about how to get started by subscribing to the Ubuntu phone mailing list.
If you want to learn more about the emulator, including how to create instance snapshots and other cool features, head out to the Ubuntu Emulator wiki page.
And next… support for the tablet form factor and SDK integration. Can’t wait for those features to land!
- Review ACTION points from previous meeting
- T Development
- Server & Cloud Bugs (caribou)
- Weekly Updates & Questions for the QA Team (psivaa)
- Weekly Updates & Questions for the Kernel Team (smb, sforshee)
- Ubuntu Server Team Events
- Open Discussion
- Announce next meeting date, time and chair
- ACTION: meeting chair (of this meeting, not the next one) to carry out post-meeting procedure (minutes, etc) documented athttps://wiki.ubuntu.com/ServerTeam/KnowledgeBase
Pretty straightforward meeting given 14.04 release is still pretty fresh in our minds, and ODS was last week. Great Demo at UDS! Utopic Unicorn is underway way (https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule) the first Alpha release scheduled for June 26th, and vUDS on June 12th. Server team blueprints are also in progress with the topic blueprint (https://blueprints.launchpad.net/ubuntu/+spec/topic-u-server_ already created and dependencies being posted to it.
The Bugs we covered were:
- Launchpad bug 1319555 in ec2-api-tools (Ubuntu Utopic) “update out-dated ec2-api-tools for 12.04″ [High,New]
- Launchpad bug 1315052 in lxc (Ubuntu Utopic) “lxc-attach from a different login session fails” [High,Triaged]
- Launchpad bug 1317587 in clamav (Ubuntu Utopic) “ClamAV 0.98.1 is Outdated” [High,In progress]
- Launchpad bug 1317811 in linux (Ubuntu) “Dropped packets on EC2, “xen_netfront: xennet: skb rides the rocket: x slots”" [Medium,In progress]
Next meeting will be on Tuesday, May 27th at 16:00 UTC in #ubuntu-meeting.
Additional logs @ https://wiki.ubuntu.com/MeetingLogs/Server/20140520