LTTng (Linux Trace Toolkit - next generation) is a highly efficient system tracer that allows tracing of the kernel and userspace. It also provides tools to view and analyse the gathered trace data.  So let's see how to install and use LTTng kernel tracing in Ubuntu. First, one has to install the LTTng userspace tools:

 sudo apt-get update  
 sudo apt-get install lttng-tools babeltrace

 sudo apt-get install lttng-modules-dkms  

 sudo lttng list -k  

 Kernel events:  
 -------------  
    mm_vmscan_kswapd_sleep (loglevel: TRACE_EMERG (0)) (type: tracepoint)  
    mm_vmscan_kswapd_wake (loglevel: TRACE_EMERG (0)) (type: tracepoint)  
    mm_vmscan_wakeup_kswapd (loglevel: TRACE_EMERG (0)) (type: tracepoint)  
    mm_vmscan_direct_reclaim_begin (loglevel: TRACE_EMERG (0)) (type: tracepoint)  
    mm_vmscan_memcg_reclaim_begin (loglevel: TRACE_EMERG (0)) (type: tracepoint)  
 ..  

 sudo lttng create examplesession  

 sudo lttng enable-event sched_process_exec -k  

 sudo lttng start  

 sudo lttng stop  
 sudo lttng destroy  

 sudo babeltrace ~/lttng-traces/examplesession-20130517-125533  

 [12:56:04.490960303] (+?.?????????) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/bin/firefox", tid = 4892, old_tid = 4892 }  
 [12:56:04.493116594] (+0.002156291) x220i sched_process_exec: { cpu_id = 0 }, { filename = "/usr/bin/which", tid = 4895, old_tid = 4895 }  
 [12:56:04.496291224] (+0.003174630) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/lib/firefox/firefox", tid = 4892, old_tid = 4892 }  
 [12:56:05.472770438] (+0.976479214) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/lib/libunity-webapps/unity-webapps-service", tid = 4910, old_tid = 4910 }  
 [12:56:05.478117340] (+0.005346902) x220i sched_process_exec: { cpu_id = 2 }, { filename = "/usr/bin/ubuntu-webapps-update-index", tid = 4912, old_tid = 4912 }  
 [12:56:10.834043409] (+5.355926069) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/top", tid = 4937, old_tid = 4937 }  
 [12:56:13.668306764] (+2.834263355) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/bin/ps", tid = 4938, old_tid = 4938 }  
 [12:56:16.047191671] (+2.378884907) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/sudo", tid = 4939, old_tid = 4939 }  
 [12:56:16.059363974] (+0.012172303) x220i sched_process_exec: { cpu_id = 3 }, { filename = "/usr/bin/lttng", tid = 4940, old_tid = 4940 }  

Cambridge is nice city. I was there at least once every year since 2009: OEDEM 2009, Emdebian sprint in 2010, during Linaro Connect q3.11, ARMv8 sprint in 2012. But this time it was not work related visit.

Saturday

It was evening when I reached Cambridge. Pawe? took me from the train station and I had occasion to see their new house and how they plan to restructure it. We discussed some things, spoke a bit (mostly I) about ARMology (history of ARM cores) and day ended.

Sunday

Lazy day spent on wandering around in the centre of Cambridge. I could go to Ely or Norwich instead but decided to just take a long walk and see places which I already saw before and find something new as well.

One of new places was Market Square Street Market where many local products could be bought and/or tried. Ostrich burgers, cakes, cookies, cheese, different things made from wood, metal or screws, jewellery made from misc materials like buttons. There were books, movies, music on CDs and vinyls, paintings, different kind of food to buy/taste… And many other things. I spent probably an hour there just walking and checking what do they have on offer.

But as it was yet another quite windy day I decided to buy some wind proof jacket. Visited few shops but did not find anything (finally bought one day later). My cold was already at advanced phase ;(

But it was well spent day. I saw many new places, reminded already visited ones but (mostly due to cold) did not took any pictures.

Monday

I had an appointment with Andrew Wafaa so we met for lunch at the Oak Bistro. Discussed about misc things (like end of my job at Linaro) and at the end I gave him MicroSD adapter which does not stick out from Chromebook. He told me few hours later that it was a problem to get it back from people later during day ;)

After lunch I went to the Whipple Museum. Interesting exhibition. Models of human body, lot of scientific equipment from few centuries. Really worth visiting.

Day ended with visit at 40th Cambridge Beer Festival. I like how event was organized. “No glass, no service” means you can bring your own glass or pay 2.5GBP deposit for event one. There was wide choice of beers, ciders, perries (cider like make from pears), meads and wines. You could buy whole, half or third of pint (meads and wines were sold in 175ml portions) which made tasting easier.

Tuesday

I reserved that day for beer festival only. Leif took day off so we could spend it together there. The only problem was when on Monday’s evening I realized that we forgot to share any usable contact information but we managed to find each other at one of social networking websites.

So beer… I bought several ones and tried even more from local friends. In the official application I marked (random order):

• Curious (bitter)
• Summer Virgin (golden ale)
• Nero (stout)
• “Ruby… don’t take your beer to town” (dark mild)
• Krasny Red (bitter, IPA style)
• Pegasus (bitter)
• Honeypot (speciality which I got rid to urinal after few sips)
• Golden Kiwi (golden ale)
• Bohemium Lager (lager)
• Zulu (porter)

But there were also other ones and “Dark Mead” for the end of day. With thanks of Leif and Steve I found out what is a source of that strange taste I call “English beer taste” which I am not a fan of. ?According to Steve it is due to hops.

It was great day due to beer and people I met: Andy, Neil, Steve, Leif, Maria and others.

Wednesday

The last day in Cambridge. Went to Fitzwilliam museum to take a look at the art. And I have to admit that I prefer art from 18-19th centuries rather than modern one.

Eat lunch, packed bags and then went to Stansted airport. Funny moment at security gate where officer asked me about amount of cellphones in my bag. There were just two of them: Nexus 4 and Chinese E6 one (plus Kindle and Nexus 7 tablet). Probably it was just routine control ;D

And after around 9 hours I finally arrived at home…

Conclusion

It was good trip, I enjoyed every day of it (even with cold), managed to visit most of the places I planned to, met friends and spent time in other way than usually.

All rights reserved © Marcin Juszkiewicz
My UK trip — Cambridge was originally posted on Marcin Juszkiewicz website

Algunas versiones de Encuentro (si no recuerdo mal la 0.5 y 0.6) estaban empaquetadas para Windows (con instalador y todo).

Pero hacer ese trabajo era un perno. En este caso lo hacía un muchacho que se llama Javier Andalia, pero después no lo continuó. El drama es básicamente que GTK, la biblioteca que se usaba para la interfaz gráfica es muy poco amigable para hacerla andar en Windows. Siempre fue un dolor de muelas, lo sigue siendo, y no creo que cambie.

Todo empeoró cuando del lado del server cambiaron todo obligándome a cambiar un montón de cosas de mi lado. Ahí salió la versión 0.7, que funcionaba correctamente con el estado actual de situación, pero dejaba a los usuarios de Windows sin tener algo que les funcione.

Y la verdad es que el contenido de Encuentro, Conectate, BACUA, etc, está buenísimo y da para que lo disfruten todos, aunque el usuario tenga un sistema operativo de mierda.

Entonces, encaré el laburo de migrar de GTK a Qt. Y una vez estuvo eso, empaqueté nuevamente para Windows y armé el instalador.

Luego de un par de semanas de "beta", tengo el orgullo de presentarles Encuentro 1.0, :D

Es una release rara porque a nivel funcionalidad real no hay mucho impacto, pero internamente cambió todo.  Igual, lo importante acá es el nuevo público al que puede llegar.

Ah, y mañana jueves con Diego Mascialino (el otro gran desarrollador de Encuentro) hacemos la release party de esta versión... o sea, nos juntamos a tomar algo y jugar unos pooles en Wrangler's... el que quiere venir que venga, están todos invitados! (pero cada uno se paga lo suyo :p).

10gen, the company behind the MongoDB database, recently announced the availability of the MongoDB Backup Service. This is not a traditional backup service, though. Rather than simply sending scheduled snapshots of the data over to a remote system, the backup service has an agent sitting next to the database that monitors its operation log, and streams the individual operations over to the remote backup servers. This model enables the service to offer some non-conventional features, such as restoring the state of the database at any point in the last 24h, in addition to more traditional snapshots over longer periods.

There’s another interesting fact about how the system was developed: the backup agent is also the first software 10gen releases that is written in the Go language. Reportedly, the agent started as a Java project but, as the project matured, the team wanted to move to a language that compiled to native machine code to make it easier to install. After considering a few options, the team decided that Go was the best fit for its C-like syntax, strong standard library, first-class concurrency, and painless multi-platform support.

I’ve invited Daniel Gottlieb, the main 10gen engineer behind the service agent, to provide some high-level feedback about the use of Go and mgo, the MongoDB driver, and he kindly replied:

Programming the backup agent in Go and the mgo driver has been extremely satisfying. Between the lightweight syntax, the first-class concurrency and the well documented, idiomatic libraries such as mgo, Go has become my language of choice for writing small scripts up to large distributed applications.

The mgo driver is a real pleasure to use. The code is of high quality, the documentation is thorough, clear and detailed, and the API is a thoughtful, natural blend of idiomatic Go and Mongo.

Those are encouraging words, Daniel. It’s great to see not only 10gen making good use of the Go language for first-class services, but contributing to that community of developers by providing its support for the development of the Go driver in multiple ways. Good chance to say thanks!

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130528 Meeting Agenda

ARM Status

Q/master: lp1176977 (“XFS instability on armhf under load”) – cherry picked two
more patches that address the free space fragmentation: the resulting kernel
passes all tests so far, i’m waiting for user feedback and one last batch of
tests.
*/highbank: lp1182637(“cpu_offlining fails to run on ARM”) – all the highbanks kernel that
we released so far are affected by this – basically, you can offline a cpu but
when you try to put it back, reinsetion fails and the only way to get the cpu back
is to reboot. Debugged till the point the cpu is plugged back, but it never really
starts and pick up the idle thread – i’ll probably need to do a comparison
between the boot environment (when the cpu are added to the system via the same
mechanism) and this scenario.

Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

• http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

I’m still working on cleaning up our team’s set of work items and
getting monthly goals properly refelcted in the blueprints.

Status: Saucy Development Kernel

Our Saucy unstable branch has been rebased to the latest v3.10-rc3
upstream kernel. Saucy master-next is currently at v3.9.3. I
anticipate we’ll cut over to v3.10 around the -rc4 time frame.
On the phablet side, we now have Ubuntu kernels in the archive for the
Nexus 4, 7, 10, and Galaxy Nexus devices. We also anticipate an
AppArmor pull request next week from the security team to get the latest
AppArmor patches into these kernels.
Important upcoming dates:
Thurs June 20 – Alpha 1 (opt in)

Status: CVE’s

== 2013-05-28 (7 days) ==
Currently we have 63 CVEs on our radar, with 0 CVEs added and 0 CVEs retired in the last week.
See the CVE matrix for the current list:

• http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html

  Overall the backlog has decreased slightly this week:

• http://people.canonical.com/~kernel/status/cve-metrics.txt

• http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt

Status: Stable, Security, and Bugfix Kernel Updates – Raring/Quantal/Precise/Lucid/Hardy

Status for the main kernels, until today (May. 28):

• Lucid – In Prep;
• Precise – In Prep;
• Quantal – In Prep;
• Raring – In Prep;
  Current opened tracking bugs details:

• http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

  For SRUs, SRU report is a good source of information:

• http://people.canonical.com/~kernel/reports/sru-report.html

  Future stable cadence cycles:

• https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock

Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Today ubuntufinder.com was updated with the latest image data for Ubuntu 13.04 and all the previous releases as well. Rather than simply hardcoding the values again, though, the JavaScript code was changed so that it imports the new JSON-based feeds that Canonical has been publishing for the official Ubuntu images that are available in EC2, thanks to recent work by Scott Moser. This means the site is always up-to-date, with no manual actions.

Although the new feeds made that quite straightforward, there was a small detail to sort out: the Ubuntu Finder is visually dynamic, but it is actually a fully static web site served from S3, and the JSON feeds are served from the Canonical servers. This means the same-origin policy won’t allow that kind of cross-domain import to be easily done without further action.

The typical workaround for this kind of situation is to put a tiny proxy within the site server to load the JSON and dispatch to the browser from the same origin. Unfortunately, this isn’t an option in this case because there’s no custom server backing the data. There’s a similar option that actually works, though: deploying that tiny proxy server in some other corner and forward the JSON payload as JSONP or with cross-origin resource sharing enabled, so that browsers can bypass the same-origin restriction, and that’s what was done.

Rather than once again doing a special tiny server for that one service, though, this time around a slightly more general tool has emerged, and as an experiment it has been put live so anyone can use it. The server logic is pretty simple, and the idea is even simpler. Using the services from jsontest.com as an example, the following URL will serve a JSON document that can only be loaded from a page that is in a location allowed by the same-origin policy:

• http://echo.jsontest.com/key/value

If one wanted to load that page from a different location, it might be transformed into a JSONP document by loading it from:

• http://jsonpeer.appspot.com/http/echo.jsontest.com/key/value?jsonpeercb=callback

Alternatively, modern browsers that support the cross-origin resource sharing can simply load pure JSON by omitting the jsonpeercb parameter. The jsonpeer server will emit the proper header to allow the browser to load it:

• http://jsonpeer.appspot.com/http/echo.jsontest.com/key/value

This service is backed by a tiny Go server that lives in App Engine so it’s fast, secure (hopefully), and maintenance-less.

Some further details about the service:

• Results are JSON with cross-origin resource sharing by default
• With a query parameter jsonpeercb=<callback name>, results are JSONP
• The callback name must consist of characters in the set [_.a-zA-Z0-9]
• Query parameters provided to jsonpeer are used when doing the upstream request
• HTTP headers are discarded in both directions
• Results are cached for 5 minutes on memcache before being re-fetched
• Upstream results must be valid JSON
• Upstream results must have Content-Type application/json or text/plain
• Upstream results must be under 500kb
• Both http and https work; just tweak the URL and the path accordingly

Have fun if you need it, and please get in touch before abusing it.

UPDATE: The service and blog post were tweaked so that it defaults to returning plain JSON with CORS enabled, thanks to a suggestion by James Henstridge.

• Import my contacts
• Make and receive SMSs
• Make and receive phone calls
• Use the internet via a wireless connection

I did a 0.2.2 maintenance release for umockdev to fix building with Vala 0.16.1, gcc 4.8 (the changed sizeof behaviour caused segfaults), and current udev releases (umockdev-record stumbled over the new “link priority” fields of udevadm). There are also a couple of bug fixes, but no new features.

This is a presentation of our ‘Paper’ Motion theme for Ubuntu Mobile.

The theme is informed by the ‘paper’ graphic style of the mobile OS and we have sought to accentuate it wherever possible. Rather than using more overt effects like page curling and folding, we have hinted at the theme by using multiple layers, ‘stacking’ and suggestive effects. Multiple layers of sliding paper can be observed in the animation of the switch button, stacking can be seen occurring on the icons in the launcher and an example of a suggestive page-turning effect can be seen during the ‘App Stacking’ example.

If you read discussions on the Internet about memory allocation (and who doesn’t, really), one surprising tidbit that always comes up is that in Linux, malloc never returns null because the kernel does a thing called memory overcommit. This is easy to verify with a simple test application.

#include<stdio.h>
#include<malloc.h>

int main(int argc, char **argv) {
  while(1) {
    char *x = malloc(1);
    if(!x) {
      printf("Malloc returned null.\n");
      return 0;
    }
    *x = 0;
  }
  return 1;
}

This app tries to malloc memory one byte at a time and writes to it. It keeps doing this until either malloc returns null or the process is killed by the OOM killer. When run, the latter happens. Thus we have now proved conclusively that malloc never returns null.

Or have we?

Let’s change the code a bit.

#include<stdio.h>
#include<malloc.h>

int main(int argc, char **argv) {
  long size=1;
  while(1) {
    char *x = malloc(size*1024);
    if(!x) {
      printf("Malloc returned null.\n");
      printf("Tried to alloc: %ldk.\n", size);
      return 0;
    }
    *x = 0;
    free(x);
    size++;
  }
  return 1;
}

In this application we try to allocate a block of ever increasing size. If the allocation is successful, we release the block before trying to allocate a bigger one. This program does receive a null pointer from malloc.

When run on a machine with 16 GB of memory, the program will fail once the allocation grows to roughly 14 GB. I don’t know the exact reason for this, but it may be that the kernel reserves some part of the address space for itself and trying to allocate a chunk bigger than all remaining memory fails.

Summarizing: malloc under Linux can either return null or not and the non-null pointer you get back is either valid or invalid and there is no way to tell which one it is.

Happy coding.

Un tema que se ha visto varias veces, tanto en la lista de PyAr como en la vida real, es que los desarrolladores que no estuvieron involucrados en proyectos grandes, o que sólo estuvieron metidos en uno o dos sistemas (más allá el tamaño), no saben muy bien qué estructura, o qué forma, darle a un proyecto nuevo.

Es totalmente comprensible. La estructura a tener depende de muchos factores: de la complejidad del proyecto, de cuan listo lo deja uno para empaquetarlo, de la prolijidad del desarrollador, etc.

Lo notable es que (en mi experiencia) el proyecto aunque nazca pequeño, siempre conviene que esté ordenado. Y que la forma de ordenarlo, qué estructura darle, cambia en función de las necesidades (como decía arriba) pero que siempre es bueno tener alguna.

En función de todo esto es que paso a contarles qué estructura tiene hoy Encuentro. No es la mejor del mundo, pero es la que a mí me funciona en este y otros proyectos. Y es una buena base como para que alguien que no tiene idea sepa para qué lado ir ordenando los tantos.

El código en sí lo pueden ver acá o si tienen instalado bazaar pueden hacer bzr branch lp:encuentro y exploran el código de forma local.

Bueno, a los bifes.


El código "útil" en sí

Tenemos dos archivos y varios directorios...

- test: Este es un script que básicamente ejecuta todas las comprobaciones que necesitamos para asegurarnos que el proyecto está "verde". En el caso de encuentro, corre las pruebas de unidad (las que están en el directorio tests, ver abajo), luego corre un verificador estático de código genérico (pylint) y finalmente otro verificador puntual para pep 8.

- version.txt: La versión del programa. La tengo separada sólo por consistencia: me gusta que esté en un sólo lado así es la misma para todos los que la necesitan (setup.py, para mostrarlo al arrancar, o cuando el usuario pide info del programa, etc).

- bin/: Aquí (normalmente) hay un sólo archivo, con el nombre del proyecto: encuentro. Este es el script de inicio, el que arranca todo el sistema ya sea cuando lo ejecutamos desde el proyecto mismo, desde un tarball descomprimido, e incluso es el que va a parar a /usr/bin cuando se instala. Este es el único que es ejecutable, el resto del sistema son sólo módulos.

- encuentro/: Es el directorio principal del proyecto (por eso el nombre). Acá tenemos todo el código "de producción" del proyecto, con su estructura interna. Por lo pronto, en este mismo directorio están todos los módulos que tienen que ver con el funcionamiento interno de Encuentro.

- encuentro/ui/: Aquí tenemos todo el código que necesitamos para armar la Interfaz del Usuario del programa. También tiene que ver con el funcionamiento interno de Encuentro, pero es sólo el manejo de la interfaz. La separación de qué va aquí o qué va directamente en encuentro/ a veces es complicada.

- encuentro/ui/media/: Todas las imágenes, audios, etc, que necesitamos para que funcione la UI en sí.

- encuentro/logos/: También imágenes, pero que se usan como identificación del programa en sí. Aunque algunas se usan en la parte de UI, están todas acá porque también se usan en otros contextos (por ejemplo, en la instalación del paquete).

- tests/: Los tests de unidad del proyecto, normalmente un montón de archivos cuyo nombre arranca con "test_" pero también pueden haber otros (módulos o no) para dar soporte a las pruebas.


Otros directorios

Estos son directorios puntuales que tengo para Encuentro. Algunos se repiten con otros proyectos, otros no.

- qtreactor: El módulo de integración entre Qt (el framework de interfaz gráfica que estoy usando) y Twisted (una biblioteca asincrónica que uso para trabajar con la red).

- server: Cuando le decimos al programa "local" de Encuentro que actualice los episodios, se baja algunos archivos comprimidos de mi server, con toda la metadata. Estos archivos comprimidos se generan una vez al día a partir de los sitios webs de Encuentro, Conectate, BACUA, etc. El código para realizar todo esto está en este directorio.

- web: Todos los archivos necesarios para montar el sitio web del proyecto.

- windows: Imágenes, configuraciones, y explicaciones necesarias para armar el .exe en Windows y luego armar con eso el instalador final que se distribuye.


Otros archivos

Estos son otros archivos que no tienen demasiada relación entre sí, pero que son importantes en distintos momentos de la vida del proyecto:

- AUTHORS, COPYING: Info legal: cuales son las personas que participaron del proyecto, y la licencia del mismo.

- LEEME.txt, README.txt, AYUDA.txt: Textos de ayuda para la persona que llega por primera vez al proyecto (viéndolo desde los archivos fuente). Está en dos idiomas, pero como Encuentro es inherentemente para personas que hablan castellano, el LEEME es el que tiene la info posta.

- anuncio.txt, pasos_release.txt: Recordatorios y textos preparados para mí (o para el que haga la release del proyecto... que vengo siendo siempre yo, :p).

- pylintrc: Un archivo de configuración para el verificador estático de código que mencionaba arriba.

- setup.py, MANIFEST.in: Script principal de empaquetamiento e instalación, más un archivo que podríamos decir de configuración del mismo.

- encuentro.desktop, source_encuentro.py: Dos archivitos necesarios en sistemas Debian/Ubuntu (al menos). El primero le pasa al sistema info para poner el programa en el menú del usuario, y el otro es usado en caso de que el programa crashee, para informar automáticamente del problema.

Let’s talk about revision control for a while. It’s great. Everyone uses it. People love the power and flexibility it provides.

However, if you read about happenings from over ten years ago or so, we find that the situation was quite different. Seasoned developers were against revision control. They would flat out refuse to use it and instead just put everything on a shared network drive or used something crazier, such as the revision control shingle.

Thankfully we as a society have gone forwards. Not using revision control is a firing offense. Most people would flat out refuse to accept a job that does not use revision control regardless of anything short of a few million euros in cash up front. Everyone accepts that revision control is the building block of quality. This is good.

It is unfortunate that this view is severely lacking in other aspects of software development. Let’s take as an example tests. There are actually people, in visible places, that publicly and vocally speak against writing tests. And for some reason we as a whole sort of accept that rather and not immediately flag that out as ridiculous nonsense.

A first example was told to me by a friend working on a quite complex piece of mathematical code. When he discovered that there were no tests at all measuring that it worked he was replied this: “If you are smart enough to be hired to work on this code, you are smart enough not to need tests.” I really wish this were an isolated incident, but in my heart I know that is not the case.

The second example is a posting made a while back by a well known open source developer. It had a blanket statement saying that test driven development is bad and harmful. The main point seemed to be a false dichotomy between good software with no tests and poor software with tests.

Even if testing is done, the implementation may be just a massive bucketful of fail. As an example, here you can read how people thought audio codecs should be tested.

As long as this kind of thinking is tolerated, no matter how esteemed a person says it, we are in the same place as medicine was during the age of bloodletting and leeches. This is why software is considered to be unreliable, buggy piece of garbage that costs hundreds of millions. And the only way out of it is a change of collective attitude. Unfortunately those often take quite a long time to happen, but a man can dream, can he not?

I was few times in London but always on business without time for sightseeing so decided to change it.

Day one

After few hours trip landed at London Gatwick airport. Some say that’s worst one of five but was not so bad. Why there? Because I could and I was on Stansted, Luton and Heathrow already (plan to use City one next time). Short trip to the city and hello Victoria station — long time no see…

Bought Oyster card to use public transport in easiest way and took a metro train to hotel. Nothing fancy — just cheap (65£ per night) hotel without any extras (but with working free WiFi).

Unpacked only needed things and went to city centre. Victoria monument, Buckingham Palace, the Mall etc. More or less followed the most popular trip from the “Trip Advisor” application.

Went to Thames, crossed with one bridge, looked at London Eye (and decided to skip it) and then Big Ben and Westminster Abbey were next. I considered returning to the Abbey next day but later decided against it.

Grabbed some food and went to sleep early as it was 3rd day when I woke up around 5:00.

Day two

Thursday… Skipped Westminster Abbey and went by foot to the British Museum. Met Mark Brown on a way and we had good time looking at all those things which British Empire had stolen from all around the world. We didn’t managed to find Britain sections.

After lunch I went to the Forbidden Planet store. And sunk there for quite long time. Then got back to buy two more books. This place was amazing…

They had stuff related to movies, games, tv series – figurines, key chains, t-shirts, toys, rings/jewellery, helmets, weapons and other… Some from limited editions. But when I wondered “is that’s all?” I went to the basement. And sank.

Comics, books, movies, tv series, manga, anime, photo albums and more. Books about movies, books which movies were based on (and vice versa). “Darth Vader’s princess” and “Darth Vader and his son” were there (9£ each), “Simon’s cat” books which my daughter would love (so I bought one), lot of SF and fantasy books in nice editions (Asimov for example).

“Big book of butts” looked funny. Next one was “Big book of legs” next to “pin-up girls” and other photo/erotic ones.

Nice place to go to but I warn you – you can leave a lot of cash there and have problem packing…

Lack of Britain sections in museum made me go to their website to check floor plan. And back to the building to see few more exhibitions. When I finally found what was searching for they told us to leave :-(

But no need to be sad I thought cause I was going to meet long time no see friends at a pub not so far away. Went there, ordered some “organic lager” and sat down to wait for them. Few minutes later I had a chat with some guys around 60 years old about some random stuff. Good part were their recommendations which beer to try next. As you probably guess it was not lager but rather ale or something more English.

YaaL and Pornel arrived and we had nice chat about life, work etc. Time passed too fast :-( But it was good to meet after so many years.

Day three

This had to be no museums day. First I went to visit Canonical’s office as I have never been there…

Finding building was quite easy, then discussion with security took a bit more before they finally realised that I am on a visitors list already. Got tour of the office, looked at wall full of Ubuntu Touch interface mockups, discussed few of them with someone, made some coffee and left the building.

Next step was Tete Modern Art gallery. I spent few hours there watching all those sculptures, paintings and installations which were counted as art in previous century. Did not even tried to understand those…

Due to cold I got during previous days I went back to the hotel. But why stay there when there are so many places to visit and so little time?

So I decided to make use of longer opening hours at the British Museum and went there. This time managed to see Britain sections and European Medieval times ones. It was good evening.

Day four

As this was my last day in London I decided to not go far from the hotel. Checked out, left luggage and went on foot to the Science Museum.

Lovely place. Went quickly though Space exhibition (cause most of it I saw at Cape Canaveral already) but other ones were worth seeing. Age of Steam with all those engines and descriptions, vehicles like bikes (starting with “safety bicycle” by Rover), motorcycles, cars (including JET 1 powered by gas turbine) but also planes (with replica of Wright brothers one) and helicopters.

I enjoyed the “Materials” exhibition — especially body model with some artificial addons and long list next to it informing which materials can be used for which implants and other inserted parts.

There was also special exhibition about Alan Turing and his work.

After visit I went for food, took luggage from hotel and then the Underground to King’s Cross train station and went to Cambridge. But this will be next post.

All rights reserved © Marcin Juszkiewicz
My UK trip — London was originally posted on Marcin Juszkiewicz website

I am the one and only nobody I’d rather be

I am the one and only you can’t take that away from me

– Chesney Hawkes, The One and Only

Just a short note: I have missed the exact date in the release madness for Ubuntu 13.04 Raring, but a few days ago something important silently happened: All supported Ubuntu releases are now shipping with LibreOffice by default, as trusty old Ubuntu 10.04 LTS (Lucid Lynx) reached its end of support for the desktop. So we now have these supported releases:

• Ubuntu 12.04 LTS (Precise Pangolin) with LibreOffice 3.5
• Ubuntu 12.10 (Quantal Quetzal) with LibreOffice 3.6
• Ubuntu 13.04 (Raring Ringtail) with LibreOffice 4.0
• and upcoming: Ubuntu 13.10 (Saucy Salamander) with LibreOffice 4.1

Also the following releases (which are not supported anymore) have been done in addition:

• Ubuntu 11.04 (Natty Narwhal) with LibreOffice 3.3
• Ubuntu 11.10 (Oneiric Ocelot) with LibreOffice 3.4

Looking back in time at the angstridden, not-acting-but-reacting excitement of the early days and comparing it with the way we are really pushing the envelope now, we have really come a long way, improving with every step on the way. Well worth a celebration with one of the most cheesy 1990ies hits ever – Thanks to everyone, who was and is part of this!

Recently we had our online Ubuntu Developer Summit where we discussed a range of topics, defined next steps, and documented work items. The very last session at the event was an overall summary of the tracks (you can watch the video here), but I wanted to blog an overall summary too. These notes are quick and to the point, but they should give an overall idea of decisions made.

Client

• Content Handling -

  • Siloing apps.
  • Main applications will define a “main repo” and provide an API to deliver, share and access the data in the main repo.

• X.org

  • Want to update to 1.14 or even 1.15 if the video ABI doesn’t change.

• System Settings

  • Focus on the phone settings defined here.

• Scopes

  • Scopes that didn’t land in 13.04 should land within 2 weeks.
  • Several scopes will be migrated from Python to either C++ or Go for memory purposes.

• Chromium

  • Expressed interest in moving to Chromium as default for a better user experience. Gathered feedback on the possible move. Next steps are to take discussion to the mailing list.

• Unity 8/Mir Preview in 13.10

  • Want to have a preview of Ubuntu 8 (Phablet UI) running on Mir as an optional session (installable from universe or PPA, most likely).

Foundations

• Reviewed the current 13.10 release schedule found several changes made in 13.04 that mistakenly hadn’t been carried over, such as later freeze dates and one fewer alpha; Adam Conrad will be syncing all this up and sending mail to the ubuntu-release list for review.
• We discussed the positioning of the development release in light of some conversations last cycle, and put some more flesh on the design for making it easier for people to follow along with the development release all the time.
• This cycle, we’ll be bringing up a new 64-bit ARM architecture based on cross-building work done last cycle, and we’ll update developers on that once we get closer to the point of starting up builds in Launchpad.
• Moving forward with click packages. Fleshed out ideas on source package provision, integrating with existing client package management stacks, and clarifying some other things like the security model.
• For image based upgrades, the team held a demo and Q&A for the current proposed solution, which is split into client, server, and upgrader; client is going well and expected to land by the end of June, server is currently blocked on infrastructure but should be ready around the same time, and Ondrej Kubik has been making good progress at tweaking the CyanogenMod recovery environment for the upgrader.
• Firmed up the plan for packaging Android components for Ubuntu Touch images.
• Upstart will be used as the standard way of spawning desktop apps for Unity on touch devices and ideally on desktop too (Unity 7 and 8). This will let us make sure we only have one instance per app, and will make it easy to apply AppArmor, seccomp and cgroup confinement consistently to all apps.
• Defined a goal to reduce the amount of time it takes to prepare, test and make a Checkbox release, automating more of the process. This will benefit people who use the Checkbox tool as part of their daily work. It’s possible that Checkbox may move to Universe, although this needs some more discussion.
• The server certification tools are being reengineered to use the new plainbox engine as their core. This will preserve the existing UI, but we’ll have co-installable packages with the new core, and will eventually switch over to the new tools.
• The cert tools and test suite are being upgraded to work well on ARM for our hyperscale and mobile work, fixing any issues so we can get full, clean test runs on ARM servers. MaaS will be used for provisioning, and tested as a part of the ARM server solution.
• We will be basing the primary kernels for 13.10 on Linux 3.10, but will strongly consider 3.11 depending on timing. For Ubuntu Touch devices, we already have kernels available for Nexus 4 and 7, and plan to also bring up kernels for Galaxy Nexus and Nexus 10. We’ll provide a 13.04 hardware enablement kernel in the 12.04.3 point release.
• In terms of Ubuntu Touch power management, we have some preliminary baselines against Android on Nexus 4 and will replicate those on other devices, although they won’t be entirely meaningful until things like Mir land. We’ve written some new utilities such as eventstat to track down problems here. On power management policy, we agreed key requirements for the system power manager and we’ll extend powerd to serve our immediate needs.

Community

• Community Roundtable:

  • Approved LoCo teams are no more, will be verified teams.
  • Bringing back fortnightly leadership meetings.
  • Ubuntu Advocacy Kit is driving to 1.0.
  • Gathered UDS feedback.

• Ubuntu Community Website

  • Great discussion which clarified everybody’s involvement in the project.
  • Clear roadmap for completing the content and design in the next few weeks.
  • Design and web team have the templates we need to finish the work.
  • No discussion with IS yet around deployment – this will be coordinated next week.

• Ubuntu Womens Session

  • Several events planned to get more people involved and the word out (Career Days, UOW, etc.).
  • Discussion about a women in technology themed event at CLS.

• Ubuntu Status Tracker

  • The status tracker is many things to many different teams, but we managed to figure out a number of issues we can tackle, which should make everybody’s lives easier.
  • Removal of kanban view.
  • Add links from team pages to milestones pages.
  • Set up a meeting to discuss setting up an “ongoing” dev series.

• Ubuntu On Air! Discussion

  • Issues with supporting multiple hosts.
  • Discussion about building support into summit and re-using vUDS components to support more shows and multiple hosts.
  • We want to open it up to more contributors, so we get more variety into the shows.

• Development Onramp for Touch / Unity Next

  • Goals to improve docs.
  • We will track contributions to all the projects to see how we improve.
  • Increased focus on testing, coordination with the SDK team.

• Documentation Team

  • Update Getting Started Page, review current docs and previous mailing list feedback.
  • Regular doc review cadence and more health check meetings.
  • Focus on content in the UAK.

• Ubuntu Enterprise Desktop Discussions

  • Another meeting will be planned to get more input from users of enterprise desktops.
  • Some common issues were identified and discussed:
  • outdated cfengine package
  • access to Firefox/Thunderbird packages before publication (resolved)
  • support for livemeeting/linc

• More Ubuntu Touch images

  • We identified the current blockers and will simplify thingsby using an image without firmware blobs, so they can be added by a local tool afterwards.
  • After the rebase to saucy we will also update the docs accordingly.
  • Kernel images for devices will first live in PPA, afterwards probably in universe.

• Regular Ubuntu Development Updates

  • Organise regular Ubuntu on Air Hangouts to which we invite people from news sites as moderators.
  • Briefly summarise work from the last week(s).
  • Ask engineers to demo/showcase interesting developments.
  • Do Q&A sessions.
  • Also invite members of governance teams along.

Cloud and Server

• Openstack Next Steps

  • Looked at some high level areas for this cycle, avoiding digging into areas covered by other sessions. We decided that at current, moving over to Git for our packaging work doesn’t add value. We also agreed to clean up on some cruft within the packaging branches.

• Cloud Archive Status Check

  • Decided we had to support Grizzly for 12 months, which exposes a 3 month support gap from the backing Raring release. Need to discuss with the security team about how to fill this gap. Reviewed proposal for SRU cadence and tentatively rubber stamped.
  • Better co-ordination around trumping by Security dates, specifically if it covers more than one project.
  • Looked at using updates as a reason to increase our messaging.

• 12.04.x images with LTS Enablement Kernel

  • The cloud images currently only contain the Precise (3.2) kernel. Discussed adding the kernel HWE stack to cloud images. We need to document how to enable backports, clearly state the support, and possibly tool cloud-init to handle updating the kernel on boot if folks need a more recent kernel on boot.
  • We will not be creating new images with the HWE kernel for the default images. The HWE kernel will be used for Clouds that have a high velocity of change in the Hypervisor (i.e. Windows Azure). For the regular images, we will investigate tooling in cloud-init and other places to make the ingestion of the HWE kernels easier, such as enhancing the documentation, allowing for easier enablement of backports, and making it easier to enable the HWE kernel at boot time.

• Cloud-Init for Vagrant

  • We will create a good Ubuntu development workflow for Vagrant users (cross platform OSX, Windows). Ben Howard will investigate cloud-init tooling as well as the best method to enable the DKMS modules.

• Cloud Init & Cloud Image Development for Saucy

  • We will define the development work to improve cloud-init and cloud images for the saucy cycle.
  • Discussed work on pre-cloud init phase, vendor hooks, cloud init plugin, and rebuding tools.

• Juju Core Development

  • 1.10 version of juju available in backports for 13.04, and should be available in precise backports soon.
  • Look for releases in juju/dev ppa updating weekly, juju PPA monthly, and have stable release go into backports (couple of times per cycle).

• OpenStack Hypervisors

  • HyperV support is currently untested.
  • VMWare support in charms, but not primary supported charms.
  • We need a matrix to demonstrate interoperability and support of each variation.
  • Need to work out additional hardening support.

• Openstack QA

  • Building on our great history, moving away from per commit hardware testing to a more fluid multi virtualised separated environment, allowing greater interoperability testing. Hardware Cert term showed interest in getting more involved. The scope of this will be ratified when the interop matrix is created.

• Flag Bearer Charms

  • Will improve flag bearer charm integration testing.
  • Implement list of reference charms.
  • Develop Percona backup XtraBackup flag bearer charm.
  • Document flag bearer and reference charm criteria in best practices.
  • Discuss flag bearer charms on mailing list.

• Charm Policy Review

  • Add into policy for a charm to provide a config option to specify the version. The other items such as installation location (ie /srv), implementation of common subordinates, backups are to be added to best practices. The 3 ack on charm reviews is still under discussion.
  • Split Juju docs best practices and policy sections.

• Audit Charms

  • Discussed re-reviewing the current charms in the charm store to ensure accurate readmes, tests, functionality, rating, categories, and icons. The workflow was discussed for queues, and which charms to tackle first.

• Charm Development Tooling

  • Discussed gathering all the different charm development tools into one central package. These charm development tools include charm-tools, charmsupport, juju-gui,openstack-charm-helpers. Folks also discussed how the tools could be improved, and used as a singular set.

• Juju Framework Charm for Server Application Technologies

  • Discussed further building out of the Django, Rails, Node.js, and possibly Java.

• Improve Juju Documentation

  • Make a better user and charm developer experience for juju.ubuntu.com/docs. Discussed getting a permanent beta site going, methods to get documentation contributions. Hopefully a revamped docs will be in production in the next couple of weeks, and if not we’ll have a beta site very shortly (days).

• Juju Charm Testing

  • Currently jenkins.qu.u.c has graph testing showing reliable results. Marco will be landing integration soon (days), with a more formal testing framework to follow (weeks).
  • Some ideas discussed were to gate charm store commits on testing, showing testing status in the GUI, and pre-deployment testing. Test examples will be made available along with a charm testing school.

• Add User Feedback loops and Social Networking to Charm Store Charm Pages

  • Discussed making sure users have a method to give and receive feedback on a per charm basis. We currently have social networking (+1s, Likes, Tweets) in addition to downloads, quality rating, bug links, and testing status. Some ideas were to get clarification from design on showing social networking numbers, as well as a ‘leave feedback’ form.

• Juju GUI Development

  • Discussed development done, and upcoming work. Covered ideas such as design, bundles, diagnostics, user data, juju feature parity, maintenance and support.

• Improving QA for seeded server packages

  • Established three distinctive areas of testing, these are upstream test suites which typically run at build-time, integration tests via dep8 and service level testing which often requires multiple nodes and is conducted using juju.
  • We established that there is the regression test suite that can be included in many of the packages directly, with the requirement that we package some of the common ubuntu testing libraries.
  • Discussed some areas of standardisation for dep8 testing.

• Fastpath installer work for 13.10

  • Established what FPI is, and the processes which are part of it.
  • Fast Path installer will be delivered as a installable package in Ubuntu, most likely in python. The interface to it will we yaml formatted configuration.

• OpenStack Charm work for Saucy/Havana

  • Migrate all charms to be python based.
  • Consolidation into new charm-helpers nextgen library.
  • Complete SSL/HTTPS support into charms.
  • Integration of wiki and help documentation, upstream series aligned with upgrading notes.
  • Design around how proprietary+1 plugins will be integrated into core charms for Cinder and Quantum.

• Investigate alternatives to mysql

  • Agreed that the best course of action was to maintain mysql for this cycle, and try and support other flavours of mysql getting into Ubuntu via Debian.

• Ceph activities for Saucy

  • Dumpling release will be out in August (co-incides with FF for Saucy) so will be target for this release.
  • Lots of incremental improvements in efficiency and performance, full RESTful API for RADOS Gateway admin features, block device encryption for data at rest.
  • ceph-deploy (upstream cross platform deploy tooling) will be packaged.
  • Implementation of more automated testing during Saucy.

• HA Openstack charms V2

  • Reviewed the current state of HA support in Openstack charms. Percona has volunteered to charm their offering, allowing great coverage by their mysql HA variant for active/active clustering.
  • Work also on active/active and brokerless messaging options (ZeroMQ) and incremental improvements for service check monitoring in load balancers.
  • Cluster stack (Corosync/Pacemaker) to be reviewed and upgraded for Saucy in preparation for 14.04.

• MongoDB activities for Saucy

  • File Main inclusion report for Mongo to support Ceilometer and Juju use cases. Raise a Micro Release Exemption (MRE) to the techboard, as point releases are bug fix only.
  • Upstream armhf enablement patches. Re-sync with Debian. OpenSSL license exception.

• Virtualization Stack Work for Saucy

  • If debian libcgroup maintainer finds time, we’d like to merge cgroup-lite into libcgroup. For per-user configuration, first make it default-off optional, conditional on userns sysctl being enabled.
  • LXC work is going well on track to 14.04 (and lxc 1.0) roadmaps. For this cycle, we’d like to get user namespaces enabled in the saucy kernel with a new off-by-default sysctl controling unprivileged use, and complete the ability to create and start basic containers without privilege; add console, attach and snapshot to the API, complete the create API function, and convert all of the lxc-* programs to use the API; write a libvirt driver based upon the API, and a patch to enable testing it with openstack; write loopback and qcow2 block device drivers; Get the subuid (user namespace enablement) patches into the shadow package; discuss with the community the maintenance of stable trees; improve the API thread safety; and work our distro lxc tests into the upstream package (akin to how it is done in netcf).
  • In edk2, we want to contribute to the implementation of the ability to save and restore nvvars from the ovmf bios from qemu. We’ll fix the apparmor bug preventing the block device mounting in libvirt-lxc, which is blocking use of that feature by openstack.
  • We intend to merge libvirt at least at version 1.0.6, qemu at 1.5, and hopefully xen 4.3. We’ll follow up on citrix’ plans for xcp. The blueprint lists additional xen work planned. We’ll also look into default use of openvswitch bridges in libvirt.

Quality Assurance

• Core Apps

  • Autopilot testcases written for ubuntu core applications will be checked to ensure they pass before auto-landing updates in the ubuntu touch images.
  • The quality community team will help core application developers develop a suite of manual testcases for each ubuntu core application. These will be run as part of the verification process for the 1.0 stable release of each application.

• Testcases

  • Add testcases so all default desktop applications for each flavor are covered.
  • Expand and improve server testcases to allow more participation by those who might lack domain specific knowledge and/or hardware.

• Growth/Experience

  • Make available documentation more accessible by linking to it from the tools we use for testing, like the qatracker.
  • Continue holding testing ‘how-to’ and knowledge sharing sessions during UDW, UOW, as part of UGJ, and on ubuntu on air.
  • Add testing achievements to the ubuntu accomplishments project.

• Ubuntu Touch

  • Ubuntu Touch images will be smoke tested using the pending/current model already in use for other images. This ensures no image is published for general consumption that doesn’t pass a set of tests ensuring basic functionality of the image.
  • Current Ubuntu Touch autopilot tests for the core applications will be investigated for use as part of these smoke tests.
  • The concept of smoke test is going to be expanded to cover a no regression build.

• Autopilot

  • Autopilot 1.3 is now released and will be available in raring and saucy. No quantal support is planned. Precise support is being examined, but requires further investigation and backporting work.
  • Autopilot developers will now be available on #ubuntu-autopilot — no need to always ping thomi!

• Mir

  • Planned tests for stressing mir to ensure good behavior during stressed conditions for things like OOM, memory leaks and race conditions.
  • Stress tests targeted to be run as often as possible, but might be limited due to time constraints of wanting to run the tests over a longer period of time.

• UTAH

  • UTAH will be expanded to include automated upgrade testing capabilities. UTAH jobs will be created for bootstrapping base images, for performing upgrades, and running post-upgrade tests. The old auto-upgrade-testing tool can still be used by flavors if desired.

• Dashboard

  • Create high-level views of the state of quality in ubuntu by aggregating results of test runs. This will allow for ‘problem’ areas within ubuntu to be more easily identified and targetted for further testing or investigation by interested parties. You can follow this work on the QA dashboard here.

• Upstream

  • autopilot-gtk will now be maintained by the upstream QA team. Bug fixes and outstanding issues will be solved in order to allow for the autopilot desktop tests to run
  • Once running properly, the autopilot desktop tests will become a part of daily image testing
  • Continue development on umockdev to add support for more exotic networking tests (eg, 3G) and research sound testing

As ever, you can track progress on work items on status.ubuntu.com and we hope to see you at the next UDS in three months.

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130521 Meeting Agenda

ARM Status

Q/master: lp1176977 (“XFS instability on armhf under load”) – working with
upstream on this one: i already backported a fix that turn the vmalloc() exhaustion
and fs shutdown to an -ENOSPC error, and this second error seems to be triggered
by the tiny fs used in these tests (~2GB). Still working to get it
properly fixed.
R/master: lp1171582(“[highbank] hvc0 getty causes random hangs”) -
the jtag console has a 1-char producer-consumer buffer and if there’s no
real hw attached to the board, any subsequent write turn into an endless loop
waiting for a consumer. The situation is worsened by the fact
that before writing to this register a tty spinlocked is taken, and
any subsequent tentative to pick this spinlock makes the thread hang -
got a confirmation of the problem, some info about the hw, and i’m working on this.

Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

• http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

The burn down charts have not yet been reset for 13.10, so disregard the
second link posted abovefor now. I’ll be cleaning up and adding work
items for 13.10 so that the +upcomingwork link will be more accurate.
Next week I’ll have the usual nag table available.

Status: Saucy Development Kernel

For now, we’ll plan on targetting the v3.10 kernel for Saucy but will
strongly re-evaluate a move to v3.11 in the coming months. We’ve just
rebased Saucy to v3.10-rc2 and are still cleaning up some of the
carnage. I don’t anticipate we’ll upload until a later -rc which will
hopefully provide more stability.
Importand upcoming dates:
Thurs June 20 – Alpha 1 (opt in)

Status: CVE’s

== 2013-05-21 (28 days) ==
Currently we have 63 CVEs on our radar, with 8 CVEs added and 17 CVEs retired in the last 28 days.
See the CVE matrix for the current list:

• http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html

  Overall the backlog has decreased slightly this week:

• http://people.canonical.com/~kernel/status/cve-metrics.txt

• http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt

Status: Stable, Security, and Bugfix Kernel Updates – Raring/Quantal/Precise/Oneiric/Lucid/Hardy

Support for Oneiric and Hardy expired on May 9th.
Status for the main kernels, until today (May. 21):

• Lucid – In Testing;
• Precise – In Testing; 2 upstream releases;
• Quantal – In Testing; 2 upstream releases;
• Raring – In Testing; 3 upstream releases;
  Current opened tracking bugs details:

• http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

  For SRUs, SRU report is a good source of information:

• http://people.canonical.com/~kernel/reports/sru-report.html

  Future stable cadence cycles:

• https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock

Open Discussion or Questions? Raise your hand to be recognized

Thanks everyone

The past few weeks I’ve been on loan to work on Ubuntu Touch, specifically the power daemon, powerd. Seth Forshee and I have been working to enhance the power daemon so that system services can interact with it to request that the device stay active, that is, that the device not suspend. The initial round of this work is complete and is landing today. (Note: There is a lot of low-level kernel interaction stuff landing in the code today too, that is not covered here)

What’s Landing

What’s landing today allows a system service, talking on the system bus, to request the Active system power state. We currently only have two states, Active and Suspend. When there are no Active state requests, powerd will drop the state to Suspend and suspend the device. This is best illustrated by showing how we use the states internally: For example, the user activity timer holds an Active state request until it expires at which point the request is dropped. The system then scans the list of outstanding state requests and if none are left, it drops the system to Suspend and suspends the system. Pressing the power button works in the same way, except as a toggle. When the screen is on, pressing the power button drops an active request, when off, it makes an active request.

For now, this ties screen state to system power state, although we plan to change that later. There is no way currently to request a display state independently of a system state, however that is planned for the future as well. For example, a request may be made to keep the screen at a specified brightness.

The API is subject to change and has a few trouble spots, but is all available to look at in the code here. Taking a look at the testclient C code or tester.sh will best illustrate the usage, but remember this is not for apps, it is for other system services. The usage for an app will be to request from a system service via an API something like “playVideoWithScreenOn()”, and then the system service will translate that into a system state request.

Trying it Out

If you want to play with it on your phone, use gdbus to take an active state request and you can block system suspend. You will need to install libglib2.0-bin on your phone if not already installed.

# request active state from PID 99 (a made-up PID). This returns a cookie, which you need to later drop the request. The cookie here is “1″

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path\
   /com/canonical/powerd --method com.canonical.powerd.requestSysState 1 99
[sudo] password for phablet: 
(uint32 1,)

show the outstanding requests.

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([(':1.29', 99), ('internal', 36)],)

now we pass in the cookie we received earlier and clear our request

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.clearSysState 1
()

recheck the list

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([('internal', 36)],)

Logs

If you want to see everything that is going on, check the powerd log file. sudo tail -f /var/log/upstart/powerd.log. For now we have it logging in debug mode, so it will tell you everything.

But My Device Isn’t Suspending

Even though we request suspend, we may not get to suspend, because it appears that at least on some devices (Nexus4 and maybe others) Android’s sensor service is holding a wakelock. We are also working on this issue.

<6>[ 1249.183061] lm3530_backlight_off, on: 0
<6>[ 1249.185105] request_suspend_state: sleep (0->3) at 1249179158043 (2013-05-21 16:38:57.769127486 UTC)
<4>[ 1249.185441] [Touch D]touch disable
<4>[ 1250.217488] stop_drawing_early_suspend: timeout waiting for userspace to stop drawing
<3>[ 1250.244132] dtv_pipe is not configured yet
--> <6>[ 1250.248679] active wake lock sns_periodic_wakelock
<6>[ 1250.248710] PM: Syncing filesystems...
<6>[ 1250.329741] sync done.

Next Steps

We have a bunch of stuff left to do here, the first obvious one is that using a monotonically increasing int for the cookie is not a great plan, so we will switch that to something like a UUID. We also need to send out dbus signals when the system goes into suspend so that services can react. We need to clean-up some of the dbus code while we’re doing that. Finally we plan on implementing display state requests using a similar model to the power state requests. Throughout all of this we need to start integration with the rest of the system.

For a while, I have been wanting to write about MAAS and how it can easily deploy workloads (specially OpenStack) with Juju, and the time has finally come. This will be the first of a series of posts where I’ll provide an Overview of how to quickly get started with MAAS and Juju.

What is MAAS?

I think that MAAS does not require introduction, but if people really need to know, this awesome video will provide a far better explanation than the one I can give in this blog post.

http://youtu.be/J1XH0SQARgo

Components and Architecture

MAAS have been designed in such a way that it can be deployed in different architectures and network environments. MAAS can be deployed as both, a Single-Node or Multi-Node Architecture. This allows MAAS to be a scalable deployment system to meet your needs. It has two basic components, the MAAS Region Controller and the MAAS Cluster Controller.

Region Controller

The MAAS Region Controller is the component the users interface with, and is the one that controls the Cluster Controllers. It is the place of the WebUI and API. The Region Controller is also the place for the MAAS meta-data server for cloud-init, as well as the place where the DNS server runs. The region controller also configures a rsyslogd server to log the installation process, as well as a proxy (squid-deb-proxy) that is used to cache the debian packages. The preseeds used for the different stages of the process are also being stored here.

Cluster Controller

The MAAS Cluster Controller only interfaces with the Region controller and is the one in charge of provisioning in general. The Cluster Controller is the place the TFTP and DHCP server(s) are located. This is the place where both the PXE files and ephemeral images are being stored. It is also the Cluster Controller’s job to power on/off the managed nodes (if configured).

The Architecture

As you can see in the image above, MAAS can be deployed in both a single node or multi-node. The way MAAS has being designed makes MAAS highly scalable allowing to add more Cluster Controllers that will manage a different pool of machines. A single-node scenario can become in a multi-node scenario by simply adding more Cluster Controllers. Each Cluster Controller has to register with the Region Controller, and each can be configured to manage a different Network. The way has this is intended to work is that each Cluster Controller will manage a different pool of machines in different networks (for provisioning), allowing MAAS to manage hundreds of machines. This is completely transparent to users because MAAS makes the machines available to them as a single pool of machines, which can all be used for deploying/orchestrating your services with juju.

How Does It Work?

MAAS has 3 basic stages. These are Enlistment, Commissioning and Deployment which are explained below:

Enlistment

The enlistment process is the process on which a new machine is registered to MAAS. When a new machine is started, it will obtain an IP address and PXE boot from the MAAS Cluster Controller. The PXE boot process will instruct the machine to load an ephemeral image that will run and perform an initial discovery process (via a preseed fed to cloud-init). This discovery process will obtain basic information such as network interfaces, MAC addresses and the machine’s architecture. Once this information is gathered, a request to register the machine is made to the MAAS Region Controller. Once this happens, the machine will appear in MAAS with a Declared state.

Commissioning

The commissioning process is the process where MAAS collects hardware information, such as the number of CPU cores, RAM memory, disk size, etc, which can be later used as constraints. Once the machine has been enlisted (Declared State), the machine must be accepted into the MAAS in order for the commissioning processes to begin and for it to be ready for deployment. For example, in the WebUI, an “Accept & Commission” button will be present. Once the machine gets accepted into MAAS, the machine will PXE boot from the MAAS Cluster Controller and will be instructed to run the same ephemeral image (again). This time, however, the commissioning process will be instructed to gather more information about the machine, which will be sent back to the MAAS region controller (via cloud-init from MAAS meta-data server). Once this process has finished, the machine information will be updated it will change to Ready state. This status means that the machine is ready for deployment.

Deployment

Once the machines are in Ready state, they can be used for deployment. Deployment can happen with both juju or the maas-cli (or even the WebUI). The maas-cli will only allow you to install Ubuntu on the machine, while juju will not only allow you to deploy Ubuntu on them, but will allow you to orchestrate services. When a machine has been deployed, its state will change to Allocated to <user>. This state means that the machine is in use by the user who requested its deployment.

Releasing Machines

Once a user doesn’t need the machine anymore, it can be released and its status will change from Allocated to <user> back to Ready. This means that the machine will be turned off and will be made available for later use.

But… How do Machines Turn On/Off?

Now, you might be wondering how are the machines being turned on/off or who is the one in charge of that. MAAS can manage power devices, such as IPMI/iLO, Sentry Switch CDU’s, or even virsh. By default, we expect that all the machines being controlled by MAAS have IPMI/iLO cards. So if your machines do, MAAS will attempt to auto-detect and auto-configure your IPMI/iLO cards during the Enlistment and Commissioning processes. Once the machines are Accepted into MAAS (after enlistment) they will be turned on automatically and they will be Commissioned (that is if IPMI was discovered and configured correctly).. This also means that every time a machine is being deployed, they will be turned on automatically.

Note that MAAS not only handles physical machines, it can also handle Virtual Machines, hence the virsh power management type. However, you will have to manually configure the details in order for MAAS to manage these virtual machines and turn them on/off automatically.

If you're running an Android device with GNU userland Linux in a chroot and need a full network access over USB cable (so that you can use your laptop/desktop machine's network connection from the device), here's a quick primer on how it can be set up.

When doing Openmoko hacking, one always first plugged in the USB cable and forwarded network, or like I did later forwarded network over Bluetooth. It was mostly because the WiFi was quite unstable with many of the kernels.

I recently found out myself using a chroot on a Nexus 4 without working WiFi, so instead of my usual WiFi usage I needed network over USB... trivial, of course, except that there's Android on the way and I'm a Android newbie. Thanks to ZDmitry on Freenode, I got the bits for the Android part so I got it working.

On device, have eg. data/usb.sh with the following contents.

#!/system/xbin/sh
CHROOT="/data/chroot"

ip addr add 192.168.137.2/30 dev usb0
ip link set usb0 up
ip route delete default
ip route add default via 192.168.137.1;
setprop net.dns1 8.8.8.8
echo 'nameserver 8.8.8.8' >> $CHROOT/run/resolvconf/resolv.conf

adb shell setprop sys.usb.config rndis,adb
adb shell data/usb.sh
sudo ifconfig usb0 192.168.137.1
sudo iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.137.0/24
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward 
sudo iptables -P FORWARD ACCEPT

An update on my progress.  I’m now taking all of Plaquenil (hydroxychloroquine), Akamin (minocycline) and Bactrim (sulfamethoxazole and trimethoprim).  The latter one is relatively new and is to treat the Bartonella co-infection that I have.

I’m not sure if it’s the drugs, the disease or a new herx, but my pericarditis pain is now at new levels and is accompanied with extreme light-headedness to the point of almost losing consciousness.

In addition, I am getting some peeling skin as a side-effect from the Bactrim so I need to reduce its dose.

This disease sucks.