=== CyberJacob is now known as CyberJacob|Away
[00:53] <marcoceppi> ekristen: not at this time
[00:53] <marcoceppi> ekristen: juju strives to remain cloud/provider agnostic
[01:05] <ekristen> marcoceppi: alright, thats a bit of a bummer, but understandable
[04:39] <lazypower> marcoceppi: I just wrapped my cut of the papertrail demo for the support guys over at papertrailapp.com
=== axw_ is now known as axw
=== CyberJacob|Away is now known as CyberJacob
[08:59] <ashipika> Hello.. a question about apache2 charm, which may be a question about juju underlying logic: is it possible to have multiple vhosts? for example, if i want to provide web interface to two different services?
[09:56] <yolanda> hi, suddenly i started receiving this errors when bootstrapping juju: ERROR failed to GET object provider-state from container juju-4d005531aa4dcd1ff5c9ab94a3711a29
[09:56] <yolanda> it was working fine until this morning
[09:58] <mgz_> yolanda: what happens if you manually try and get that using the swift client?
[10:00] <yolanda> mgz, sorry,how can i do it? however, i enabled debug on the call and i see: caused by: Authentication response not received in 1m0s.
[10:08] <mgz_> yolanda: have you got python-swiftclient installed?
[10:09] <yolanda> mgz_, yes
[10:09] <mgz_> yolanda: then just do something like `swift list juju-4d005531aa4dcd1ff5c9ab94a3711a29` and see if it has a provider-state
[10:10] <yolanda> http://paste.ubuntu.com/6593417/
[10:15] <mgz_> yolanda: and does swift stat say that read acl is .r:*?
[10:17] <yolanda>  Read ACL: .r:*,.rlistings
[10:19] <mgz_> yolanda: okay, do `swift --debug stat juju-4d005531aa4dcd1ff5c9ab94a3711a29 provider-state`, then pick out the url for that object, and try just curling it
[10:20] <mgz_> (without the auth token, is the relevent bit)
[10:23] <noodles775> InformatiQ: Did you create a bug the other day for the charm caching on local provider? I'm seeing the same thing... (ie. new bootstrap, deploy, and get the old version of the charm, as if the machine-0 lxc container is re-used, although that sounds unlikely given that it should have been lx-destroy'd)
[10:23]  * noodles775 searches
[10:24] <InformatiQ> noodles775: no i didn't i was not sure it is my fault or no but  the --upgrade help avoid it
[10:24] <noodles775> OK, I'll create one so it gets tracked.
[10:24] <InformatiQ> noodles775: I actually found out that destroy-env does not clean lxc containers well
[10:25] <noodles775> Ah - interesting, let me know if you'd prefer to create th ebug with those details...
[10:25] <InformatiQ> that one i need to create today as it gets annoying when you want to scrap and recreate
[10:25] <InformatiQ> noodles775: please do create a bug for the caching issue and I will add my notes as i verify them
[10:25] <noodles775> Cool.
[10:33] <noodles775> InformatiQ: https://bugs.launchpad.net/juju-core/+bug/1262144
[10:33] <_mup_> Bug #1262144: Charm cached and re-used after re-bootstrap on local provider <juju-core:New> <https://launchpad.net/bugs/1262144>
[10:54] <yolanda> mgz, ERROR:swiftclient:Container HEAD failed: https://swift.canonistack.canonical.com:443/v1/AUTH_24d5fd18826047c68f73e4faaba87b42/juju-4d005531aa4dcd1ff5c9ab94a3711a29 404 Not Found
[10:54] <mgz_> yolanda: after swift list succeeded for the same container?
[10:55] <yolanda> mgz_, mm, not found now
[10:56] <yolanda> i think that previous test was incorrect because i also had some deployments in zone 1
=== gary_poster|away is now known as gary_poster
=== freeflying is now known as freeflying_away
[15:00] <X-warrior> marcoceppi: yesterday I did an update from 1.16.3 to 1.16.5. It worked. but now checking a config file, I see that my db user has been changed. Could it be the update process? Other thing is the RSA fingerprint, does the update change anything like this?
[15:19] <dpb1> marcoceppi, would you mind looking at the storage and swap charms that I have out there?  I submitted bugs for them and MPs, is there something else I should do?
[15:19] <marcoceppi> dpb1: links?
[15:19] <marcoceppi> dpb1: If they're not in https://manage.jujucharms.com/tools/review-queue I don't know about them
[15:20] <dpb1> https://bugs.launchpad.net/charms/+bug/1260100
[15:20] <_mup_> Bug #1260100: Create a simple subordinate swap charm <landscape> <swap> <Juju Charms Collection:New> <https://launchpad.net/bugs/1260100>
[15:20] <dpb1> https://bugs.launchpad.net/charms/+bug/1259630
[15:20] <_mup_> Bug #1259630: add storage subordinate charm <landscape> <Juju Charms Collection:New> <https://launchpad.net/bugs/1259630>
[15:23] <dpb1> marcoceppi: they can't show up in that queue I guess since they are new charms
[15:23] <marcoceppi> dpb1: they totally can, you just need to make sure charmers is assigned to the bug
[15:23] <marcoceppi> err
[15:23] <marcoceppi> dpb1: make sure charmers is subscribed to the bug
[15:23] <dpb1> ok
[15:24] <marcoceppi> dpb1: you also need to be assigned to the bug
[15:24] <dpb1> I subscribed them to both
[15:24] <dpb1> assigned myself to both
[15:24] <marcoceppi> dpb1: https://juju.ubuntu.com/docs/authors-charm-store.html#submitting
[15:24] <marcoceppi> dpb1: check back in about 6 mins, they should show in the queue
[15:25] <marcoceppi> dpb1: I'll be doing review most of today to get the queue cleaned out by the end of the week
[15:25] <rawang> HI, one quick question, is that possible to only sync tools against precise when I run "juju sync-tools --show-log"
[15:25] <dpb1> marcoceppi: thx... missed that part on the docs
[15:25] <rawang> sync the juju with all distro and all arches is so time-consuming
[15:26] <marcoceppi> rawang: it looks like you can only sync specific versions, sync will always move all available tools series over
[15:26] <marcoceppi> rawang: you could do --version 1.16 to speed it up
[15:27] <rawang> marcoceppi, i think by default  it will sync the latest version
[15:27] <rawang> marcoceppi, but i use precise amd64 , I don't want raring, saucy tools, neither i386 tools
[15:28] <marcoceppi> rawang: there doesn't seem to be a way to filter past that constraint at this time. If you open a bug against juju-core on lp, it'll be evaluated as a feature
[15:29] <rawang> marcoceppi, ok, i will find a time to do it, meeting atm :)
[15:40] <mgz_> marcoceppi: are you free to answer some amulet questions?
[15:40] <marcoceppi> mgz_: yeah
=== mgz_ is now known as mgz
[15:42] <mgz> so, vila and I are trying to use amulet as part of some test setups
[15:42] <mgz> and have hit various issue
[15:43] <mgz> we've got a couple of changes that seemed to help, but amulet is still trying to create a sentry for a subordinate unit, which breaks
[15:44] <mgz> are the sentry parts meant to be usable currently?
[15:46] <marcoceppi> mgz: they are, but I can see how a sentry for a subordinate would be a bad idea
[15:47] <marcoceppi> mgz: I'll add a clause to not create a sentry per subordinate, and to have the subordinate's sentry entry use that of the parent unit
[15:55] <marcoceppi> mgz: are you using the packaged version or trunk?
[15:55] <mgz> marcoceppi: trunk
[15:56] <marcoceppi> mgz: from github, correct?
[15:56] <mgz> no....
[15:56] <marcoceppi> mgz: the trunk on lp is pretty far behind
[15:56] <mgz> you leave a stale launchpad branch around? :)
[15:56] <mgz> what's the actual trunk then?
[15:56] <marcoceppi> mgz: I was syncing them, but it became too tedious
[15:56] <marcoceppi> mgz: here, for the time being, https://github.com/marcoceppi/amulet
[15:57] <marcoceppi> that still doesn't fix your problem but I can have it patched relatively soon
[16:00] <mgz> marcoceppi: I'll also port across the stuff we noticed
[16:00] <marcoceppi> mgz: please!
=== BradCrittenden is now known as bac
[16:51] <lazypower> marcoceppi: couldn't you set up a githook to call bzr and publish your changes into launchpad?
=== alexlist` is now known as alexlist
=== hatch_ is now known as hatch
=== gary_poster is now known as gary_poster|away