User1: (>'')>
User2: hi
 * stgraber waves
User3: #startmeeting
User4: Meeting started Wed Sep 11 15:04:18 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
User4: Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
User3: [TOPIC] lightning round
* meetingology changed the topic of #ubuntu-meeting to: lightning round
User3: $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek cjwatson xnox stokachu)
User3: ev xnox bdmurray doko slangasek cjwatson stgraber barry jodh stokachu
User3: User5 still in other meetings?
User5: ja
User6: me?
User5: (upstream merger training)
User3: User5 do you have a report to dump us, or should we skip you for now?
User5: please skip
User3: ok
User3: User6
User6: - cross-compile qml extensions using cmake, turned out to be much
User6: easier than qmake. Posted to ubuntu-phone mailing list and a wiki
User6: page https://wiki.ubuntu.com/Touch/CrossCompile
User6: - uploaded ubiquity with a few merge proposals merged & a split of
User6: ubuntuone plugin. Thus it should be possible to seed/unseed
User6: ubuntuone plugin page on per-image basis.
User6: - ongoing work to fix bug #1216043
User6: - updating kernel-config of linux-goldfish, at the moment it's not
User6: sufficient to neither boot ubuntu nor stock android images. Tracking
User7: bug 1216043 in hw-detect (Ubuntu Saucy) "driver-inject-disk: in target debs are installed before kernel has been" [High,Confirmed] https://launchpad.net/bugs/1216043
User6: bug #1222772
User7: bug 1222772 in linux-goldfish (Ubuntu) "Config changes request to support Ubuntu Touch & stock Android" [Undecided,New] https://launchpad.net/bugs/1222772
User6: - prepare/review/submit upstart slides for linuxcon/plumbers
User6: - short week: piloting on the 5th, vacation on the 10th (submitted
User6: application to naturalise as British)
User6: ..
User8: SRU verification of bug 1211511
User8: SRU verification of Q, R ubuntu-release-upgrader bugs
User8: updated ubuntu-release-upgrader DevelReleaseAnnouncement to say BETA
User8: tested and uploaded cjwatson's apt-clone fix for bug 1212025
User7: bug 1211511 in update-manager (Ubuntu Raring) "update-manager hides but wants to install ignored phased updates" [High,Fix released] https://launchpad.net/bugs/1211511
User7: bug 1212025 in ubuntu-release-upgrader (Ubuntu) "Upgrading to Saucy crashes with a unicode error" [Undecided,Confirmed] https://launchpad.net/bugs/1212025
User9: ta
User8: uploaded fix for ubuntu-release-upgrader bug 1221307
User8: research into verification of the fix for bug 1122596 and bug 1058884
User8: research into bug 1220898 and irc discussion regarding it
User7: bug 1221307 in ubuntu-release-upgrader (Ubuntu) "SystemError message is unhelpful and causes a crash for non-English languages" [Medium,Fix released] https://launchpad.net/bugs/1221307
User7: bug 1122596 in libappindicator (Ubuntu Precise) "Race condition in app_indicator_init() causes application crash" [High,Fix committed] https://launchpad.net/bugs/1122596
User7: bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
User7: bug 1220898 in ubuntu-release-upgrader (Ubuntu) "generic kernel gets installed in ubuntustudio upgrade." [High,Triaged] https://launchpad.net/bugs/1220898
User8: code review of slangasek's ubuntu-release-upgrader cruft removal merge proposal
User8: fixed an issue with arsenal reports regarding multiple teams
User8: tested multiple kernels for bug 1218004
User7: bug 1218004 in linux (Ubuntu) "Apple Wireless Trackpad causes kernel oops" [High,Confirmed] https://launchpad.net/bugs/1218004
User8: â done
User2: - had vacation days Friday and this week, done some tax stuff, nothing work related
User2: (done)
User3: * SecureBoot:
User3: * fixed sbsigntool to be able to actually reproduce Microsoft-signed binaries byte-for byte, letting us automatically validate the results of SysDev signing
User3: * uploaded shim-signed, which fixes various bugs and brings in fun new features like netboot support
User3: * worked with cjwatson to get a pregenerated UEFI netboot image for grub2 - so now we have full SecureBoot netboot support in saucy
User3: * now need to look at getting this all backported to precise
User3: * updated mountall for various bugfixes (bug #503003, bug #731800); also makes mountall debuggable without having to edit the upstart job; now dealing with a regression, bug #1223745.
User7: bug 503003 in mountall (Ubuntu) "multiple entries in fstab with same mount-point" [Medium,Fix released] https://launchpad.net/bugs/503003
User3: * TODO:
User7: bug 731800 in mountall (Ubuntu) "mountall assert failure: mountall.c:1411: Assertion failed in skip_mount: (! mnt->mounted) || needs_remount (mnt)" [Medium,Fix released] https://launchpad.net/bugs/731800
User3: * parted still not done
User7: bug 1223745 in mountall (Ubuntu) "Dependency resolver causes hang on boot" [Undecided,New] https://launchpad.net/bugs/1223745
User3: * plumbers next week
User3: * booking travel for the client sprint at the end of October (you guys don't have to go, except cjwatson :)
User3: * get air conditioning, since August has come again
User3: (done)
User9: Click:
User9: Finished deploying preinstalled app handling, although there's a glitch involving needing to re-run system hooks.
User9: Wrote a click(1) manual page.
User9: Implemented removal support.  (Harder than it looked due to the necessary garbage collection semantics.)
User9: Implemented search by name/details in the PackageKit plugin.
User9: "click list --manifest" tweak to speed up the system settings UI (bug 1221760).
User7: bug 1221760 in click (Ubuntu) "Having "pkgdir" in the manifest info would be useful" [High,Fix released] https://launchpad.net/bugs/1221760
User9: Various bug fixes (bug 1197047, bug 1215480, bug 1218483).
User9: OEM bugs:
User7: bug 1197047 in upstart-app-launch (Ubuntu Saucy) "SDK applications create /tmp/*.sci files" [High,In progress] https://launchpad.net/bugs/1197047
User9: Fixed bug 1097570, pending testing that I haven't broken ordinary booting from hard disk before releasing to saucy.
User7: bug 1215480 in click (Ubuntu) "wrong permissions of click packages due to adb shell umask of 0000" [High,Fix released] https://launchpad.net/bugs/1215480
User7: bug 1218483 in click (Ubuntu) "Installation errors are not reported" [High,Fix released] https://launchpad.net/bugs/1218483
User9: Attempted to track down bug 1215458, but stymied by parted's debug symbols being unavailable.  Fixed the Debian packaging for that and just received the results of another test run.
User7: bug 1097570 in grub2 (Ubuntu Raring) "grub2-signed can not find the right device when there are two filesystems containing the file '.disk/info'." [High,Triaged] https://launchpad.net/bugs/1097570
User7: bug 1215458 in partman-basicfilesystems (Ubuntu) "Auto-partitioning with LVM on Advanced Format Disks causes parted_server segfault" [High,In progress] https://launchpad.net/bugs/1215458
User9: Investigated bug 1197766 and posted a candidate patch.
User7: bug 1197766 in OEM Priority Project "Different partition layout after recovery with keep home partition" [Critical,Confirmed] https://launchpad.net/bugs/1197766
User9: Misc:
User9: Rebootstrapped gradle.
User9: Various minor transitions, merges, etc.; mostly trying to reduce the list of outstanding changes in -proposed.
User9: To do:
User9: Continue to analyse crash data from 1215458.
User9: Organise travel for next client sprint.
User9: Start on chroot-management code in click to improve architecture-specific handling.
User9: ..
User10: Blueprint-related work:
User10: - Image based updates (BLUEPRINT: foundations-1305-image-based-updates)
User10: - Made system-images the default
User10: - Worked with QA to tweak the channel setup and help fix some tests
User10: - Re-designed channels.json to support channel aliases and hidden channels
User10: - Did some refactoring in the server code, moved a bunch of stuff from independent scripts to the library and now covered by tests (fixed a few bugs in the process)
User10: - Implemented and tested support for channel aliases (daily => saucy, stable => saucy)
User10: - Started working on the import-cdimage rewrite to be much more flexible, drive as many channels as needed, do image expiry, auto-cleanup, shared image pool, support watching http urls (for customization tarballs).
User10:
User10: Other work:
User10: - LXC
User10: - Linux Plumbers mini-conference preparation
User10: - Some code review
User10: - Started working on a new website and new domain name for the project
User10: - Spent a couple of hours updating debian/copyright after the upstream licensing changes (it used to be completely wrong...)
User10: - Trying to get LXC to behave on an old 2.6.32 based Android phone so I can give my talk next week...
User10: - Generate the 1.0~alpha1 tarballs, getting a couple of fixes cherry-picked to fix regressions on Ubuntu Touch for an upload tonight or tomorrow morning.
User10: - Other
User10: - Various additions to writable-paths in Ubuntu Touch
User10: - Some rework of the initrd hook to fix file/directory ownership for writable paths.
User10: - Code reviews and tests for the guys working on Ubuntu Touch customizations
User10: - Debugged sssd 1.11 breaking with samba4, now fixed in upstream git and cherry-picked to saucy.
User10:
User10: TODO (hopefully this week):
User10: - Upload LXC 1.0~alpha1 (waiting for a fix from Dwight)
User10: - Finish the import-cdimage rewrite (now scheduled to land on Monday)
User10: - Implement the boot-time hooks for Ubuntu touch
User10: - Plumbers 2013 prep
User10: (DONE)
User11: system-image: LP: #1215959; LP: #1221841; LP: #1196991 (ongoing).  1.5 and 1.5.1 uploaded.  weekly meeting.
User7: Launchpad bug 1215959 in Ubuntu system image "Report image versions" [High,Fix committed] https://launchpad.net/bugs/1215959
User7: Launchpad bug 1221841 in Ubuntu system image "Support the new channels.json format in a backward compatible way" [Critical,Fix committed] https://launchpad.net/bugs/1221841
User7: Launchpad bug 1196991 in Ubuntu system image "Support the new download dbus service" [High,In progress] https://launchpad.net/bugs/1196991
User11: other: tox issue #122 (affected system-image local testing).  virtualenv, pip, tox, nose2 packaging work.  dmb meeting.  awaiting FFes.  LP: #1223004.  LP: #1223001.  LP: #1223483. Debian bug #722295.  pip 1.4.1-2.  Debugging kernel regressions LP: #1223352 and LP: #1223408.
User7: Launchpad bug 1223004 in python-oauthlib (Ubuntu) "[FFe] sync with debian which has 0.5.1" [Wishlist,Fix released] https://launchpad.net/bugs/1223004
User7: Launchpad bug 1223001 in python-pip (Ubuntu) "[FFe] sync python-pip 1.4.1 from debian" [Undecided,New] https://launchpad.net/bugs/1223001
User7: Launchpad bug 1223483 in python-virtualenv (Ubuntu) "[FFe] sync 1.10.1 from Debian" [Undecided,New] https://launchpad.net/bugs/1223483
User7: Debian bug 722295 in python-pip "python-pip: ca-certificates needs to be Depends rather than Recommends" [Normal,Fixed] http://bugs.debian.org/722295
User11: âº
User12: * upstart:
User12: - Fixed bug in Upstart apport hook.
User12: - Fixed bug 1221466 and bug 1222702. Awaiting feedback on MP with new
User12: tests:
User7: bug 1221466 in upstart (Ubuntu) "upstart-file-bridge 'EVENT=create' not working for directories" [Undecided,In progress] https://launchpad.net/bugs/1221466
User12: https://code.launchpad.net/~jamesodhunt/upstart/bug-1221466+1222702/+merge/184829
User7: bug 1222702 in upstart (Ubuntu) "upstart-file-bridge assert failure: upstart-file-bridge.c:1162: Assertion failed in delete_handler: strstr (path, dir->path) == path" [Medium,In progress] https://launchpad.net/bugs/1222702
User12: - Fixed failing quiesce tests. Awaiting feedback on updated MP:
User12: https://code.launchpad.net/~jamesodhunt/upstart/test-quiesce-cleanup/+merge/182698
User12: - Investigating bug 1222705.
User7: bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [Medium,New] https://launchpad.net/bugs/1222705
User12: - Investigating suspected race in system init re-exec test causing
User12: occasional failure.
User12:
User12: - Updated Technical Overview for Upstart:
User12: https://wiki.ubuntu.com/SaucySalamander/TechnicalOverview#Upstart_1.10
User12: * misc:
User12: - Linux Plumbers preparation.
User12: å¥
User6: User12 re upstart-file-bridge MP: looks good, but didn't run the tests yet, want to run them before merging.
User1: bug 1160490 - i think slangasek tasked himself to upload? and having a really tough time getting traction on bug 1157943
User12: User6 great, thanks.
User7: bug 1160490 in ifupdown (Ubuntu Raring) "race condition updating statefile" [Medium,In progress] https://launchpad.net/bugs/1160490
User7: bug 1157943 in apt (Ubuntu Precise) "apt-get update fails hash checks on https repositories when file size changes" [Undecided,New] https://launchpad.net/bugs/1157943
User1: done
User6: User3 i guess the test-quiesce-cleanup branch is for you to further comment on =)
User3: User11 do you have an eta for bug #1196991?  that seems to be the critical piece we're still missing
User7: bug 1196991 in Ubuntu system image "Support the new download dbus service" [High,In progress] https://launchpad.net/bugs/1196991
User3: User1 yeah, 1160490 still on my radar
User1: User3 thanks man, arges ^
User13: User3 thanks
User11: User3 if nothing else intrudes, from a few days to eow.
User11: (some refactoring is required, but this will also close a few other bugs)
User3: xnox, User12 test-quiesce-cleanup> right, I need to circle around on that one; I still have my doubts that these changes are correct, but need to actually review the code to be sure
User3: User11 ok, perfect!  do you need any help keeping out intruders?  I can post sentries ;)
User11: User3 i might! ;)
User10: User3 I think I've been the biggest source of delays to barry's work so far but that's because of other bits that were higher priority. I don't think I've got anything else to get in before the D/L service work now, so hopefully barry can focus on that :)
User3: User1 1157943> if you want a response from David, you're going to need to reach out to him more directly than a "ping" on the bug log
User11: yay! :)
User1: User3 so just start emailing him directly then?
User1: User3 didnt want to piss him off
User3: stgraber, User11 right, sounds good
User3: User1 by "more directly", I mean you might want to at least make it clear in your email to the bug that you're addressing him :)
User1: User3 ok
User3: User1 I always think it's best to keep the discussion on the public bug tracker, but use his name / make it clear you're looking for his input.  Remember he's a non-Canonical upstream, so he also doesn't have any obligation to help us on your time line
User3: any other questions / discussion over status?
User1: gotcha
User3: User1 oh, and if you want to get him on IRC, he's DonKult and hangs around in some ubuntu channels
User3: (sometimes)
User1: User3 ok ill keep an eye out for him, looks like he's not on any channels atm
User3: [TOPIC] AOB
* meetingology changed the topic of #ubuntu-meeting to: AOB
User3: anything else on people's minds?
User3: [TOPIC] LXC
* meetingology changed the topic of #ubuntu-meeting to: LXC
User3: new topic, then :)
User3: you are now a captive audience for stgraber to practice his LXC material for Plumbers next week ;)
User10: Alright, so LXC.
User10: I guess everyone knows what LXC is and that most of you already use it voluntarily or not.
User10: The LXC project is about writing convenient tools, libraries and bindings to the various containment APIs available in the kernel.
User10: As it's today, that's: namespaces (ipc, pid, utc, mount, network and user), cgroups (all the controllers are supported), capabilities, apparmor (custom profiles per container) and seccomp (custom profile per container).
User10:
User10: The current stable version of LXC is 0.9, released back in April after a 5 months development cycle.
User10: The next release is going to be 1.0, for that one we've agreed on a much longer development cycle which started back in April with the release planned in early February (10 months).
User10: (I've got a bunch of stuff ready to paste but will do so in batches, so don't hesitate to ask questions at any time and I'll stop)
User10: The longer development cycle is explained by a lot of work needing to happen and some high expectations for a 1.0 release.
User10: By the time we release 1.0, we're planning on doing:
User10: - rewrite all our tools to use our public library instead of internal functions
User10: - release a stable version of the liblxc API
User10: - release a stable API for all supported bindings (python3, lua and go)
User10: - version our internal management protocol and have limited backward compatibility there
User10: - get fully functional user namespace support
User10: - support kernels from 2.6.32 kernel to whatever is latest at the time of release
User10: - support for building under the Android NDK
User10: - support for container cloning, snapshotting and backing store plugins
User10: - and a LOT of refactoring, bug fixes and templates improvement
User10: - actively maintain the 1.0 branch for a minimum of 2 years
User10: LXC is also in a transitional phase at the moment where Daniel Lezcano is still the only commiter to our master branch and Serge Hallyn and I are the only commiters for the staging branch.
User10: It's planned that during Plumbers 2013 next week, Daniel will hand over maintenance of the LXC project to Serge and I.
User10: This should make it a lot easier for Serge and I to release new snapshots and try to move the project to a single place (likely github), reducing the amount of infrastructure we need to maintain for the project and hopefully making it easier for our contributors.
User10: Some quick stats for the 1.0 release, we've had so far 343 commits from 27 different authors. We're doing around 25-30 code reviews a week which results in around 20 commits to the staging branch.
User10: Canonical (through Serge, Scott and I) represent around 55% of the changes to LXC, Oracle is next with Dwight Engen contributing almost 20% of the changes, then we have a set of recuring contributors contributing around 15% of the changes and the remaining 10% are drive-by contributions.
User3: User10 so why draw the lramsey@example.net?
User3: that seems old :)
User10: that's lucid and older RHEL6
User1: i read that post from smoser on the overlayfs and user-data, can't wait for that in a supported release
User10: (well, all RHEL6 is 2.6.32 but they cherry-picked a lot of stuff from later releases)
User3: yeah - is it necessary to support lucid from lxc 1.0?  I assume we aren't going to SRU it
User10: also the device I use to test LXC on Android only runs 2.6.32 :)
User3: hah, ok
User10: LXC uses good old mailing-list posts for code reviews and we don't run any Jenkins or similar CI infrastructure. We however have a build and test environment which we use to generate our PPA builds and that runs test builds on amd64, i386 and armhf, as well as cross-compile to current Android and uploads to coverity. The result can be found at: http://lxc.dev.stgraber.org with successful builds ending up on ppa:ubuntu-lxc/daily (built for
User10: Serge also maintains a few test kernels with user namespaces enabled in ppa:ubuntu-lxc/kernel
User10: hmm, that first line almost certainly got cut, can someone tell me where it did?
User1: (built for
User3: yeah, ^^
User10: "(built for precise, quantal, raring and saucy)."
User10: So as I said earlier, we're planning on releasing LXC 1.0 in early February 2014 just in time for the 14.04 FeatureFreeze.
User10: From that point on, our plan is to push any fix that should get into Ubuntu to the upstream 1.0.x stable branch and get an MRE to land those directly as SRU.
User10: That should be a huge improvement over our current SRU workflow where we're cherry-picking fixes one by one then SRU to 3 releases (we're pretty good at getting test results so it's not been a huge problem, but cherry-picking the fixes is time consuming).
User10: LXC got promoted to main earlier in the saucy cycle and is now a supported server technology.
User10: It's also heavily used by Ubuntu Touch to run the Android system on the phones and tablets where we simply boot an image of an Android system partition as the rootfs for an LXC container while sharing the network namespace with the host.
User10: This gives the impression to Android that it's the only operating system running, letting it do all the hardware initialization that we need while also letting the Ubuntu system outside the container access any file or socket that we need from Android.
User10: The reverse also exists with the Android/bionic port of LXC which allows running LXC natively on Android, provided the device has a kernel supporting all the features we need. This is used as the base for Ubuntu for Android.
User10: Oh, and as for LXC in saucy, we're currently on a patched version of 0.9.0 but with LXC 1.0 alpha1 released yesterday, we're actively working on landing that in the archive as soon as we fix a small regression preventing LXC from running on read-only systems (a bit of a problem for Ubuntu Touch apparently).
User10: So I think that's about it. I hope not too many of you felt asleep due to my rather long paste ;)
User10: Any questions?
User1: cant wait!
User1: with the userspace stuff will be effectively replacing other virtualization technologies?
User9: User10 Do you have plans for further arkose work?
User9: Oh, and what's the state of LXC in Debian?
User10: User9 yes, I plan on reworking arkose quite a bit once we get full user namespace support in our kernel and in LXC
User10: User9 with the goal of having arkose run entirely as a user
User11: User10 would it make sense to get the py3 bindings up on pypi?  i don't think any of these are official upstream: https://pypi.python.org/pypi?%3Aaction=search&term=lxc&submit=search
User6: User1 e.g. user namespace support would it be something one would want to support natively in upstart - e.g. start this job under modified usernamespaces? (similar how we already support chroot, uid, gid stanzas)
User6: User10 e.g. user namespace support would it be something one would want to support natively in upstart - e.g. start this job under modified usernamespaces? (similar how we already support chroot, uid, gid stanzas)
User10: User1 the user namespace work will allow users to run containers without requiring sudo rights and still get uid 0 in the container. So that should make lxc even more popular than it's today by reducing the rights an administrator has to grant.
User6: ... or one should simply start lxc container and go from there.
User11: User10 that will be very cool
User1: User10 awesome that was a huge feature i was hoping would make it
User10: User6 I had that discussion with jodh the other day and I think it may be interesting to allow upstart to clone a job in a new namespace, so that someone could decide that a job should get its own pid namespace or network namespace or user namespace ... as a way to reduce the attack surface
User3: User10 and the user namespace still requires some privileged helper to give you mapped uids from a certain range, right?  The kernel doesn't have a concept of "nested" uids?
User10: User11 I'd have to check how pypi works but yeah, none of those are official upstream bindings and I suspect they're all wrappers around our binaries rather than binding against our library
User6: User3 that's done in passwd (define allowed mappings) and that has landed in saucy now.
User11: User10 happy to help with any of that
User3: User6 yes, my point is that user namespaces work slightly differently than how one might expect
User10: User3 right, a user needs a UID and GID range assigned in /etc/subuid and /etc/subgid. Those then get set in the user's session parent PID so that any sub process can then switch to any of those uids/gids
User3: because they use up "real" uids from the root system
User6: User3 right, so it is indeed unlike pid ns.
User10: then each container has a map of real uids => fake uids and real gids => fake gids and we've got tools to "switch uids/gids"
User6: User3 which does use "real" and "fake" pids at the same time.... but I see your point.
User10: the containers then get their own range (subset of the parent's) so we can still do nested containers, it just requires a fair amount of configuration and enough uids/gids to begin with
 * slangasek nods
User10: the current blocker for having user namespace by default in our kernel is a conflict with the xfs module
User10: but apparently Oracle has been working on that, so this may have been fixed already or is about to be
 * stgraber checks on kernel.org
User3: interesting
User10: doesn't appear to be there yet, so hopefully will be in the next one
User3: architecturally, the idea of using ranges of real uids still seems sketchy to me
User3: I understand why it might not be realistic to have nested uids added to the kernel, since uids are everywhere :)
User3: but it just feels mismatched compared with the net/fs namespaces
User10: yes, it's not ideal and is pretty confusing but we had no realistic chances of getting nested uids in the kernel
 * slangasek nods
User10: it was already hard enough to get the rest of userns in which required changes to all the filesystem drivers and a bunch of other core changes
User10: hopefully we can make our tools good enough that most users won't even have to care about it
User3: so I imagine next week we're going to be talking a lot about cgroups
User3: feel like explaining the mismatch between systemd and lxc cgroup heirarchies? :)
User3: (if not, ok, - we're almost at time anyway)
User10: sure
User10: so cgroups (control groups) were designed as a way to assign resource limits and get statistics to/from processes
User10: there are a variety of controllers available that let you restrict resources, get statistics or both. The current list is:
User10: blkio  cpu  cpuacct  cpuset  devices  freezer  hugetlbmemoryperf_event
User3: right - so each "controller" controls a different type of resource?
User10: hmm, the last ones got messed up, those are hugetlb, memory and perf_event
User10: correct
User10: they work by showing a standard fs hierarchy
User10: you can create directories that inherit resource allocation from their parent
User10: and usually (but not necessarily) can't set allocations higher than their parent
User10: most controllers also support chowning the directories to give control to non-root processes
User10: using those hierarchies comes at a cost since every time the process requires access to the resource, the whole tree has to be resolved to figure out what's the actual allocation
User10: so having a tree of say /systemd/user/<uid>/cgroup/... is usually seen as a bad idea (for LXC we use either /<container-name> or /lxc/<container-name> which tends to be reasonable)
User10: now, logind uses cgroups but in a pretty weird way
User10: it uses a fake hierarchy called "systemd" which isn't tied to any controller
User10: so it's essentially cgroups without the "c" part
User10: they then use the hierarchy feature to match the user and user sessions and use the notify.on_release feature of cgroups to get a notification when the cgroup is empty or they iter through /tasks to call all the pids in the cgroup
User10: it's actually not so bad from a performance issue since they don't have any resource alocation applied though it's a bit of an abuse of cgroups to use a cgroup without resource controler :)
User10: then there's the problem that any process running under logind will appear as part of a cgroup but only that systemd one, not any of the other. Which causes a few issues for tools expecting consistent use of cgroups (with the same hierarchy existing for all the controllers)
User3: so these cgroups are actually being used exclusively for process tracking, and *not* for resource allocation?
User10: for an example, look at "cat /proc/self/cgroup" on a >= raring system
User10: you'll notice that the process is in an controller-less name=systemd cgroup and in / for all the others
User10: now that's apparently about to change since Lennart has worked on a proposal (and I believe implementation) of a new systemd/logind API to control all the controllers
User10: I don't know whether the plan is to use all of them by default on systemd systems (which would lead to a performance regression) but he's certainly pushing for libvirt and any software using cgroups to use that API for cgroup management
 * slangasek nods
User3: so there should be good discussions next week :)
User3: User10 thanks for the talk
User3: any questions?
 * barry can't wait for the video
User10: I guess so, we don't have too many (if any) talks about cgroups in the containers track as we've got more important stuff to discuss like usernamespaces but I'm sure we'll have some discussions outside the track
User10: especially as Serge has been working on a similar cgroup manager before Lennart announced his plan
User3: heh, alrighty :)
User10: (having a privileged daemon on the host machine that containers and sub-containers can talk to to get changes applied to cgroups, doing all of the policy checks in one central place)
User3: right, that was the point Lennart was making at DebConf
User3: that cgroup change management needs to have a single owner
User10: (that's important as containers running in a different userns won't be able to change cgroup options, so we need a privileged daemon they can talk to to do that, but I doubt logind/systemd is the answer there)
User3: should be fun :)
User3: #endmeeting
* meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
User4: Meeting ended Wed Sep 11 16:10:57 2013 UTC.
User4: Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.+1-551-882-7314.04.moin.txt
User4: Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.+1-551-882-7314.04.html
User3: thanks everyone!
User12: thanks!
User10: yep
User11: thanks!
ubuntu-meeting
Ubuntu IRC