[14:29] <atluri> what are the prerequisites for this talk?
[14:37] <xnox> atluri: not much, just fleshing out things that need to be done for mongodb package. It's more of a discussion & coordination, than a talk.
[14:47] <atluri> Ok. Thank xnox
[14:47] <atluri> Thank you xnox
[15:07]  * med_ waits for jamespage_uds or Daviey to open the youtube
[15:07]  * med_ waits for jamespage_uds2 or Daviey to open the youtube
[15:08]  * jamespage_uds2 pokes smoser
[15:11] <jamespage> hi all
[15:11] <jamespage> smoser is just spinning up the youtube channel
[15:11] <zul> howdy ho
[15:11]  * jamespage twiddles his thumbs
[15:12] <jamespage> hey \sh
[15:12] <\sh> hey james :)
[15:12]  * med_ twiddles his twid
[15:12]  * \sh is fighting with the summit registration ;)
[15:12] <jamespage> \sh, nice
[15:13] <jamespage> we'll get started as soon as smoser has got the channel up and running
[15:14]  * med_ sings "Anticipation...."
[15:14] <med_> and watches jorge and marco in the other window
[15:14] <jamespage> I've got my best orange t-shirt on and everything
[15:15] <\sh> ok here we go I am registered after 10 mins ;)
[15:17] <jamespage> anyone else want to join the hangout?
[15:18]  * \sh will be lurking and sent my rants via irc , /me is not a good look on the cam today ;)
[15:18] <zul> technology is hard
[15:18] <\sh> na...i'm on pto and not even showered ;)
[15:18] <med_> I'm not on PTO and not even showered.... and have a face for radio
[15:19] <jamespage> OK folks - so we are struggling a bit to get the hangout going
[15:19] <jamespage> so I'm going to start on IRC until we do
[15:19] <med_> +1
[15:19]  * jamespage goes all old fashioned
[15:20] <jamespage> http://pad.ubuntu.com/uds-1308-servercloud-s-mongodb
[15:20] <med_> s/vUDS/retro-UDS/
[15:20] <jamespage> OK - so we set out with the objective of getting MongoDB into main for 13.10
[15:20] <jamespage> two primary drivers
[15:20] <jamespage> 1) juju-core  - mongodb is key in the central state servers
[15:20] <jamespage> 2) ceilometer (openstack metering) - mongodb is the primary backend database target
[15:21] <jamespage> MIR process has started
[15:22] <jamespage> one second - might be about to go on air
[15:22] <smoser> http://www.youtube.com/embed/3JKbpMP_zOE
[15:22] <mgz> blast, was enjoying the irc version
[15:22] <jamespage> sorry mgz
[15:22] <smoser> can anyone verify ?
[15:22] <smoser> http://www.youtube.com/embed/3JKbpMP_zOE
[15:22] <med_> you are live
[15:22] <jamespage> \o/
[15:22] <med_> oh wait, starting soon
[15:23] <rbasak> I see you.
[15:23] <rbasak> o/
[15:23] <med_> live
[15:23] <rbasak> Yes
[15:23] <kentb-rr5> hola
[15:23] <\sh> go ahead :)
[15:23] <med_> in both the direct link and the embedded.
[15:23] <kentb-rr5> yes
[15:23] <rbasak> Not sure what the lag is. Say ping?
[15:23] <yolanda_uds> see you now
[15:23] <med_> very working
[15:23] <rbasak> Around a minute for me it seems.
[15:24] <med_> very laggy
[15:24] <mgz> hm, no audio-only version with youtube
[15:31] <\sh> so, mongodb is (like nodejs) a very moving target, so are we easily able to push (eventually) newer (major) versions into ubuntu (like the 14.04 LTS etc.)?  Regarding the use case in a fast paced development environment  many devs want to have a latest greatest stable releases
[15:31] <med_> cloud-tools? new pocket.  Where is that being discussed (which session)
[15:31] <mgz> chuck dead
[15:31] <zul> <-- yay for rural internet
[15:31] <med_> He's only mostly dead.
[15:31] <mgz> zombie chuck
[15:32] <med_> \sh I'm not sure where nodejs is being disussed, but this is a pretty big issue for any cloud stuff.
[15:33] <med_> ie, we need a much much newer version
[15:33] <jamespage> med_, nodejs is not  - that moves way to fast
[15:33] <med_> jamespage, well, other folks (other teams) are talking about an MRE for it too
[15:33] <jamespage> med_, which teams?
[15:33] <med_> public cloud
[15:33] <jamespage> med_, hmm
[15:34] <mgz> jamespage: what was the second issue with the MIR update, still the license thing?
[15:34] <\sh> thanks :)
[15:34] <med_> just heard you ask the voice question
[15:34] <med_> very laggy
[15:34] <\sh> please, don't talk about nodejs it's a mess ;)
[15:35] <med_> nod.
[15:37] <rbasak> I'm not sure I'll be able to get the ARM upstreaming work done this cycle.
[15:37] <rbasak> It's pretty low priority for me, because nothing is broken.
[15:38] <jamespage> any more questions?
[15:38] <rbasak> It's also extremely time consuming, because running a test build/test suite takes hours.
[15:38] <rbasak> I think it might be better to fix things the next time the ARM patches need touching.
[15:38] <jamespage> rbasak, ok - I postponed all the workitems in that area
[15:38] <rbasak> Thanks
[15:39] <med_> thanks
[15:39] <jamespage> ttfn
[15:39] <\sh> oh I have still one question ;)
[15:40] <\sh> jamespage, eventually could you read through the comments in isotopps post regarding some issues in mongodb which are more architectural? https://plus.google.com/117024231055768477646/posts/CBHoxCkLH2C
[15:43] <\sh> jamespage, especially the one comment from isotopp starting with 'it begins with mmap()'
[15:43] <jamespage> \sh, nice
[15:44] <\sh> this guy is using DBs quite a lot :) and he knows what he's talking about :) (working for booking.com and formerly for mysql AB))
[15:45] <med_> quite  a rant.
[15:50] <\sh> actually very interesting, but my question is more, how far can we go to address some issues which our user base is experiencing regarding large scale infras (which actually comes down to the point: how can we support our user base with fresh releases without breaking our enterprise commitment)
[15:54] <rbasak> Which issues? I don't think it's appropriate for Ubuntu to address fundamental issues about an upstream project (whether they are valid or not). Surely this is a discussion better had with upstream?
[15:57] <\sh> rbasak, what ever issues are coming up, while using ubuntu as foundation to a business
[15:57] <rbasak> \sh: can you enumerate these issues please?
[15:59] <frost12345> is it over?
[15:59] <\sh> Right now I can't ... but I could write up usage issues with so called 'enterprise' distros for large scaled enterprises :) (dev and ops related) any let's go over to virtualization stack work
[16:00] <frost12345> When will the next start?
[16:01] <smoser> frost12345, 4 minutes
[16:03] <\sh> smoser, any reason why nobody mentions 'cloudstack'  in this blueprint (upcoming meeting)?
[16:04] <stgraber> hallyn_: can you send me the hangout URL?
[16:05] <hallyn_> yu
[16:05] <hallyn_> p
[16:06] <utlemming> has the session not started yet?
[16:07] <hallyn_> it just did.  arewe not live?
[16:07] <arges> you are live
[16:07] <arges> somebody should mute, i hear an echo
[16:07] <arges> n/m
[16:08] <atluri> how to join hangout?
[16:08] <hazmat> user namespaces, awesome
[16:12] <atluri> Is there virtualization for GPUs?
[16:20] <smoser> atluri, what do you mean ?
[16:21] <smoser> there is pass through of gpus to a guest.
[16:22] <hazmat> hallyn_, could you elaborate on the upstream cgroup changes
[16:22] <hazmat> stgraber, thanks
[16:25] <hallyn_> hazmat: your q was answered?
[16:25] <hallyn_> (sorry was on a different screen)
[16:26] <atluri> Virtualisation of GPUs
[16:27] <hallyn_> i don't know of any work being done on that
[16:27] <hallyn_> you mean virtual GPUs that can be programmed ?
[16:31] <hazmat> hallyn_, i think so.. the nutshell sounds like systemd managing the cgroup hierarchy and lxc integrating with cgroups
[16:31] <hazmat> er.. integrating with systemd
[16:36] <hallyn_> hazmat: yeah so historically cgroups were managed and used using the vs interface.  The guidance du jour is that that's not scalable or manageable,
[16:36] <hallyn_> so one manager (systemd, whatever) should use the vfs interface, and everythign else should make abstracted requests of that manager
[16:36] <hallyn_> for systemd, requests are in the form of "slices" that something wants to have allocated
[16:37] <hallyn_> so libvirt, lxc, etc would all allocate slices for vms/contaienrs they spawn - they wouldn't look under /sys/fs/cgroup themselves at all any more
[16:38] <hallyn_> my main requirement, then, is that this be somehow nestable - so that init running inside a container can serve as a manager for itself, but be making requests through a proxy to the manager on the host
[16:40] <hazmat> hallyn_, gotcha, thanks
[18:03] <jamespage> o/
[18:05] <smoser> hey.
[18:05] <smoser> 1308 vUDS: Delivering Juju 2.0 into Ubuntu
[18:06] <smoser> is about to start.
[18:06] <smoser> anyone interested in joining hangout.
[18:12] <smoser> any questions ?
[18:12] <yolanda_uds> how far has juju-core been testing? currently using that on canonistack, detected some failures
[18:13] <smoser> have you opened bugs ?
[18:13] <jamespage> yolanda_uds, bugs raised?
[18:13] <smoser>  (please do)
[18:13] <zul> booo breakage!
[18:13] <yolanda_uds> jamespage, smoer, jus commented on juju_devel channel
[18:13] <yolanda_uds> mostly problems with logs, or terminating instances
[18:14] <danwest> please open bugs on any juju-core issues
[18:14] <yolanda_uds> ok
[19:06] <rbasak> Live now
[19:06] <jamespage> jibel_uds - want to join the hangout?
[19:07] <jibel_uds> jamespage: sure
[19:07] <rbasak> http://blog.sourcecode.de/blog/2013/08/27/how-do-we-do-installation-tests-after-package-uploads/ is relevant here. Sounds like we need a mongodb dep8 test!
[19:14] <rbasak> I've been looking at mysql
[19:14] <rbasak> I should have tracked progress better though, sorry.
[19:15] <rbasak> o/
[19:20] <danjared> which list is that?
[19:20] <jamespage> danjared, list of workitems or list of packages?
[19:20] <danjared> current package issues in seeded server packages
[19:21] <danjared> (speaking as an OEM trying to better track such issues)
[19:21] <rbasak> jibel_uds: https://bugs.launchpad.net/~ubuntu-server/+packagebugs. The merge report scrapes it (sorry, not my code!): http://bazaar.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk/view/head:/server/merges.py#L78
[19:21] <danjared> thanks, wasn't aware of that before
[19:21] <roaksoax> o/
[19:22] <roaksoax> jamespage: here!
[19:28] <xnox> jamespage: =))) o/
[19:28] <jamespage> hey xnox
[19:29] <xnox> jamespage: I like a lot of DEP-8 tests, but I got bitten by "never passed dep-8" test, which then blocked my package for (_no reason_ well from my point of view)
[19:29] <xnox> e.g. stuff like: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-squid3/
[19:29] <xnox> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-mailman/
[19:29] <xnox> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-mysql-5.5/
[19:30] <xnox> particularly mysql-5.5
[19:30] <jamespage> xnox, well that is broken - rbasak is going to revert the last upload
[19:31] <xnox> jamespage: i've been nudging release team to apply the rule "no regressions", as if the the dep-8 test has never yet passed for a package, it's failure should be ignored for reverse-depends.
[19:32] <xnox> jamespage: the interesting bit is how mysql-5.5 managed to land into -release, and then later block reverse-deps with failed adt =))))
[19:32] <jamespage> xnox, the mysql-5.5 in the release pocket is fine
[19:32] <jamespage> its just broken in proposed
[19:33] <xnox> jamespage: ah, ok. =) it was blocking upstart migrating, so that was all I cared about at the time =)))))
[19:33] <rbasak> jamespage, xnox: I tried a revert in a PPA, and I got an FTBFS. Test suite failure.
[19:33] <rbasak> (both stokachu and I were getting that locally; hence the delay)
[19:33] <rbasak> I'll probably upload the failure anyway, because then at least it's a clear FTBFS as opposed to being muddled with the regression.
[19:33] <xnox>  /o\
[19:34] <xnox> jibel++ ^^
[19:35]  * xnox giggles at renames ++ =)
[19:35] <rbasak> I'm trying a rebuild to see if it's persistent
[19:36] <xnox> jibel: yeah, I also noticed that adt are first run on second upload.
[19:37] <xnox> rbasak: one can setup a custom report / view on jenkins & look up that.
[19:38] <xnox> jibel: and bdmurray extracts that for errors.ubuntu.com
[19:38] <xnox> jibel: so one can look it up somehow.