[00:32] <netlar> Hi all
[00:41] <netlar> I want to get involved in the Ubuntu community, but not sure where to start?
=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:27] <pitti> Good morning
=== chihchun_afk is now known as chihchun
=== no_mu is now known as Nothing_Much
=== no_mu is now known as Nothing_Much
=== chihchun is now known as chihchun_afk
[08:10] <dkessel> morning pitti
[08:10] <pitti> hey dkessel
=== chihchun_afk is now known as chihchun
[08:17] <pitti> vila: trying to juju deploy swift-storage in lxc (juju-local) fails with http://paste.ubuntu.com/8221749/ here; it expects a /dev/sdb, which doesn't exist in a container; is that what you see as well?
[08:54] <vila> pitti: never tried to deploy swift in a local container, but the /dev/sdb issue rings a bell. By default containers created by juju are not able to deal with block devices (we ran into this issue when the image builder was trying to use qemu-nbd to manipulate images)
[08:54] <pitti> vila: yeah, I'm trying to figure out a solution for bug 1250965
[08:54] <ubot5> bug 1250965 in juju-core "Loopback mounts do not work with local provider" [Medium,Triaged] https://launchpad.net/bugs/1250965
[08:55] <pitti> vila: I was able to change /dev/sdb with this:
[08:55] <pitti> $ cat swift.cfg
[08:55] <pitti> swift-storage-zone1:
[08:55] <pitti>   zone: 1
[08:55] <pitti>   block-device: /etc/swift/storage.img|200M
[08:55] <vila> pitti: let me find the realted MPs
[08:55] <pitti> and use that as --cnofig
[08:55] <pitti> vila: I have swift running in a local container just fine, just not with the charm (manual setup); thus there definitively is a solution :0
[08:57] <pitti> (http://people.canonical.com/~pitti/scripts/setup-swift.sh)
=== chihchun is now known as chihchun_afk
[09:00] <pitti> vila: ./ubuntu/uci-engine/gatekeeper/setup-swift.sh -- haha!
[09:00] <pitti> vila: that's very familiar to me :)
[09:00] <vila> pitti:  https://code.launchpad.net/~vila/uci-engine/lxc-image-builder/ has some hints
[09:00] <vila> pitti: yes ;) It's not unknown ;)
[09:01] <pitti> vila: do I actually need to make the swift charm work for a local deployment, or does deploying uci-engine just take an ip/creds for an external swift (i. e. I could just point it to my existing container)?
[09:02] <vila> pitti: but the uci engine is going towards using uuids for swift containers so for our needs we'll probably end up having to copy the test results from a swift container to somewhere else
[09:02] <vila> pitti: yes, the usual setup is to use credentials for an external swift
[09:03] <pitti> vila: ah good, then I can stop fighting with the swift charm
[09:03] <vila> pitti: yup
[09:03] <pitti> I followed up on bug 1250965 to improve that
[09:03] <ubot5> bug 1250965 in juju-core "Loopback mounts do not work with local provider" [Medium,Triaged] https://launchpad.net/bugs/1250965
[09:04] <vila> pitti: and the other MP is: https://code.launchpad.net/~pwlars/uci-engine/doc-lxc-updates/+merge/226382
[09:05] <pitti> vila: yup, no problem on that side -- it's a two-command issue to set up a swift container
[09:05] <pitti> but it's eternal pain with the swift juju charm
[09:05] <pitti> still fighting with other juju bugs; I found workarounds for most, but one is impossible to work around :/
[09:06] <vila> pitti: right, just read your bug comment regarding swift. Good to know there is some way but so far it's not a blocking area for us.
[09:06] <pitti> vila: right, I just wanted to leave a note there as it'd  really be nice to make it work with local
[09:06] <pitti> while swift-setup.sh is nice, it's not really how we intend to do things :)
[09:06] <vila> agreed
[10:39] <pitti> jibel: so I added some tests to https://code.launchpad.net/~pitti/ubuntu-test-cases/desktop-systemd/
[10:39] <pitti> jibel: they work in a local VM, but now I think is a good time to exercise them in production UTAH and see whether "reboot" and everything else is working
[10:47] <pitti> jibel: do you have some minutes to show me how I can run them in the DC?
[10:48] <jibel> pitti, I never deployed UTAH jobs in the DC, only the CI team can do that.
[10:48] <pitti> jibel: ah, so I'll talk to ev/plars?
[10:50] <jibel> pitti, plars or psivaa usuaaly deploy utah jobs
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== davmor2_ is now known as davmor2
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[20:03] <balloons> ping elopio
[20:03] <elopio> balloons: pong
[20:04] <balloons> elopio, so I'm going to manually merge your mp: https://code.launchpad.net/~canonical-platform-qa/reminders-app/workaround1363604-add_sleep/+merge/232912. We can't land it with jenkins due to the fact jenkins won't run your version of the tests and will just lock up
[20:04] <balloons> I'm not sure there's another way around it
[20:09] <balloons> once merged, I'll push to the store and hopefully things will be good
[20:10] <elopio> balloons: yes, I think it would be ok to merge it even with jenkins error.
[20:10] <elopio> it's only one line. If it doesn't work as a workaround, we can revert it.
=== salem_ is now known as _salem
=== knome_ is now known as knome