Natty UDS Package Selection And System Defaults Proceedings

This page is here to collect together proceedings from sessions as part of the 'Package Selection And System Defaults' track at the Natty UDS in Orlando, Florida.

Please add proceedings by doing the following:

• Add a new section with the name of the session.
• Add the outcomes of the session as a collection of bullet points. The goal of the proceedings is to really focus on decided outcomes, so please try to keep them crisp.

Thanks!

Proceedings

Kubuntu Natty Kontact

packageselection-kubuntu-n-kontact

• make sure kontact works from live image, currently akonadi shows error due to no running nepomuk startup, ask with upstream how to fix
• make sure lionmail gets packaged and works
• kolabsys can do testing, we will set dates, probably a week before beta and before RC to do that, takes two days to do their full testing, test can provide

Kubuntu Packaging

packageselection-kubuntu-n-packaging

• ship with KDE SC 4.6
• ensure we have latest koffice, kdevelop, amarok etc
• inform debian of delta in packaging, highlighting parts they're interested in
• schedule session for wishlist for rekonq
• We don't want to ship a non-KDE browser, but Rekonq is not ready (and is horribly named)
• kwin Mobile will not be ready for Natty
• Go big with announce! Dot News, blogs, fridge
• still need to add KDM xsession
• Fix Cache issues using patches for kde4libs
• integrate automatic building with KDE dashboard
• make sure PPA packaging is based on current release as much as possible
• (re-)propose to tech board to include updates in -updates, QA'd in PPA first
• we need to test ourselves, since we cannot rely on upstream for that (or good change documentation
• get 4.4.5 into lucid (kontact 4.4.7)
• turn on raster for plasma for an alpha
• try likeback in alphas
• implement likeback in kdelibs and turn on for all apps for alpha/beta
• switch from qtcurve to gtk-oxygen-engine, ensure settings update properly

Arm Server Optimized Lamp Stack

packageselection-arm-server-optimized-lamp-stack

Problem

• No solid benchmarks for server apps on ARM or collected data can't be shared
  • So what does it mean to have a high performance LAMP stack on ARM?

Questions

• What kind of utilities and tools can we use to benchmark a system?
• What type of packages do we need to provide a high performing LAMP stack on ARM?

Goals

• Figure out the benchmark numbers as they are for ARM, compare to Intel/AMD, then improve.

Benchmark Candidates

• Pulled from the Linux Test Project test tool table (http://ltp.sourceforge.net/tooltable.php)

  • Hammerhead is a web server stress tool that can simulate multiple connections and users.

    • http://sourceforge.net/projects/hammerhead/

  • httperf is a popular web server benchmark tool for measuring web server performance

    • http://www.hpl.hp.com/research/linux/httperf/

  • Siege is an http regression testing and benchmarking utility.

    • http://www.joedog.org/index/siege-home

  • PagePoker for loadtesting and benchmarking web servers

    • http://node.to/hacks/src/

• Java

  • VolanoMark lets you determine the performance and connection limitations of your hardware, operating system, and Java platform when running the VOLANO chat server.

    • http://www.volano.com/benchmarks.html

• Phoronix - http://www.phoronix-test-suite.com/ provides an extensible framework for which new tests can be easily added. It's designed to effectively carry out both qualitative and quantitative benchmarks in a clean, reproducible, and easy-to-use manner.

• Others - Webstone, Bonnie (want to test CPU not AHCI cards etc...), LMBench, Sysstat

Other ARM Server workloads

• Squid
• MariaDB/Drizzle

• Redis - http://code.google.com/p/redis/

• Memcached

• HipHop for PHP

• PHP workloads (with benchmarks?) Drupal (http://drupal.org/node/79237), Wordpress (has benchmark)

• Samba (?)
• Cluster file systems (?) GFS / Gluster
• Shark JIT on ARM
• Python, Twisted (used by Launchpad), Ruby on rails (new kid on block but growing)
• DNS - bind (Memcached a good proxy for DNS performance - essentially a look up)
• HAProxy - user space - interesting

Testing

• Look at adding hooks into checkbox for benchmark testing on ARM
• Martin B, Dave Rusling (Linaro), Chuck, Leo (ARM) - willing to help with testing with hardware and appropriate information that makes things easy to run
  • Scripts? Apt install on top of Linaro testing?
• Results to be hosted on UDS wiki for now
• Recomended kernel config

  • + perf / oprofile
    - debug
    + large block handling
    

Profiling

• Dave Martin / Will Deacon (ARM) will post pointers to info about using the Linux perf tools to collect profiling data.
• Important to collect profiling information during benchmark runs

Server root fs

• How to grab server root fs - grab right ARM image - no server ISO right now
• Martin Bogomolni to test root stack / media create to base file system only

  • - Exact binaries needed for testing
    - Align with Linaro methodology on this
    

Next Steps

• Distribute work
• Collect results (once testing made easy / repeatable)
• Circle back on identification of focus areas
• Identify bugs / route to owners for resolution (missing packages, broken, poor performance etc...)

Finish Upstart

packageselection-foundations-n-finish-upstart
Last UDS (recap): Stable version of Upstart in Ubuntu now for a few releases, working out reasonably well, but there are a number of things we need to fix (the fact that mountall is needed, user services, etc.). Used last UDS to get a sense of what complaints were from various people and groups, and made sure that appropriate bugs were filed.

Upstart's design is too simple. The goal of the next version is to fix problems based on deployment experience while retaining the "Upstartishness", and reach an elegant, simple design that we don't need to change again: i.e. 1.0.

https://bugs.edge.launchpad.net/upstart/+bugs
https://bugs.edge.launchpad.net/upstart/+bug/447654

Proposed Changes:

• add the concepts of states which are based on events and persist beyond the event, which jobs can depend on
• child tracking should use proc connector
• events should be queued against jobs when the job is transitioning
• overrides to local configuration of jobs without editing them
• new hook on starting * to allow tracking of job dependancies
• upstart will know about chroots and make itself available in there if it is going to start jobs automatically; and use the root directory for local start within a chroot to start the right jobs

Need to get buy in for these features

GNOME plans for the natty cycle

packageselection-desktop-n-gnome3

• Outcome
• Outcome
• Outcome

Server Application Packaging and Distribution

packageselection-server-n-packaging-and-distribution

• Outcome
• Outcome
• Outcome

Ubuntu Chinese Edition

packageselection-desktop-n-chinese-version

• Outcome
• Outcome
• Outcome

Session Name

UbuntuSpec:

• Outcome
• Outcome
• Outcome