[02:36] <jose> QUESTION: Why am I seeing [Review Queue] emails now?
[02:44] <sarnold> jose: oops, did you do enough good work to earn more work? :)
[02:44] <jose> sarnold: hehe nope, they're on the juju mailing list
[02:44] <sarnold> oh :)
[02:44] <jose> I was just wondering if it had something to do with the new revq that's on the works!
[03:03] <tvansteenburgh> jose: no that's just a new thing we're doing. we're taking 2-hr time blocks on the review queue and reporting our progress to the list
[03:03] <jose> tvansteenburgh: oh, it's good to know :)
[11:48] <jam> I have a question about the appropriate way to write a charm configuration.
[11:48] <jam> I have in mind a very simple charm that I give my account credentials to, and it issues "juju destroy-environment" after a given timeout.
[11:49] <jam> So that I can deploy the charm when I have just a testing env, and make sure it dies even if I forget about it.
[11:50] <jam> But I'd like to have it allow a syntax like "destroy after 45 minutes" or something along those lines
[11:50] <jam> but it seems odd to have a config setting that would "reset" the state every time config-changed runs.
[12:32] <marcoceppi> stokachu: what do you mean it breaks it?
[12:40] <jam> marcoceppi: there you are. I ran into https://bugs.launchpad.net/charm-tools/+bug/1359170 trying to use charm-tools with trunk juju
[12:40] <mup> Bug #1359170: juju charm create fails in an unhelpful fashion with juju-1.21 in PATH <Juju Charm Tools:New> <https://launchpad.net/bugs/1359170>
[12:40] <jam> I'm not sure that you're the maintainer, but I thought I'd start with you
[12:41] <marcoceppi> jam: I am one of them, this is concerning, I'm not sure what I can do to fix it
[12:41] <marcoceppi> seems like juju-core is not being so nice
[12:41] <marcoceppi> ?
[12:41] <jam> marcoceppi: so something is failing in the subprocess starting other things, but its unclear what
[12:42] <marcoceppi> jam: I'll compile from trunk and punch on it a bit
[12:42] <marcoceppi> jam: any idea when 1.21 is expected?
[12:42] <jam> marcoceppi: so I think we set "command.Env"
[12:43] <jam> and probably juju-create expects PATH to be in there, but we aren't putting it in?
[12:43] <jam> no, we are appending to os.Environ() so that should be ok.
[12:43] <jam> ...
[12:43] <marcoceppi> i mean, we're just using argparse in python
[12:43] <jam> though the way we are doing that makes me wonder if we are actually mutating os.Environ() in-procses (not that it really matters)
[12:43] <marcoceppi> nothing too crazy
[12:43] <jam> marcoceppi: you're looking for /usr/bin/charm-create and invoking that
[12:43] <jam> from juju-chram
[12:44] <jam> juju-charm
[12:44] <jam> which then uses setuptools to again look up where main is, etc.
[12:44] <marcoceppi> oh, right, for "plugin mapping"
[12:44] <marcoceppi> let me compile, throw in some debug statements, see what I can find
[12:50] <jam> marcoceppi: doing "print sys.argv" in juju-charm shows me:
[12:50] <jam> $ juju charm create -h
[12:50] <jam> args ['/usr/bin/juju-charm']
[12:50] <jam> marcoceppi: vs 1.18 does:
[12:50] <jam> $ /usr/bin/juju charm create -h
[12:50] <jam> args ['/usr/bin/juju-charm', 'create', '-h']
[12:50] <marcoceppi> ah, so that's what is different
[12:51] <marcoceppi> bug in core I guess?
[12:52] <jam> marcoceppi: yeah
[12:52] <marcoceppi> \o/ less work for me
[12:52] <marcoceppi> jam: thanks for catching that though
[12:58] <rm4> could anyone help possibly with charm debug
[12:58] <rm4> juju debug-hooks wordpress/3 loadbalancer-relation-joined
[12:59] <rm4> I was hoping to see a special prompt with %
[12:59] <rm4> but I just get:
[12:59] <rm4> root@vagrant-local-machine-34:~#
[12:59] <jrwren_> rm4: did you resolved --retry yet ?
[13:00] <rm4> don't quite follow sorry
[13:01] <jrwren_> rm4: something needs to trigger the hook executing again, assuming it is in a failed state. juju resolved --retry <unit> will trigger this.
[13:02] <jrwren_> rm4: do that in a different terminal and your debug-hook tmux will open a new tmux window with the special prompt
[13:02] <rm4> vagrant@vagrant-ubuntu-trusty-64:~$ juju resolved --retry wordpress/3 ERROR unit "wordpress/3" is not in an error state
[13:03] <rm4> it all works but I would like to see what is happening
[13:03] <rm4> so I can make a charm
[13:04] <jrwren_> rm4: In that case, you could remove the unit and add it again and immediately after running add run the debug-hook and hope you were fast enough to catch the hooks (you likely will be).
[13:05] <jrwren_> rm4: or if you are only interested in that relation, remove and add that relation
[13:07] <aisrael> In cloud-images, what's the functional difference supposed to be between the vagrant boxes in http://cloud-images.ubuntu.com/vagrant/trusty/ vs. http://cloud-images.ubuntu.com/vagrant/trusty/current/?
[13:08] <rm4> thanks jrwren
[13:08] <rick_h__> aisrael: might be good to pin utlemming on that. He's in CO so might not be on for a bit.
[13:08] <rm4> I'll try and come back
[13:08] <rick_h__> adeuring: do you know the answer to aisrael's question ^ ?
[13:09] <jcastro> aisrael, the first one has all the boxes
[13:09] <jcastro> the 2nd one only has the latest builds
[13:09] <jcastro> the boxes get published every few weeks, so we keep those around too
[13:09] <jcastro> what is in /current will always be the latest one
[13:10] <aisrael> The reason I'm asking: the image in current/ only sets up one adapter (nat) and doesn't provision juju.
[13:10] <aisrael> The larger image bootstraps, but sets up two adapters (nat and hostonly)
[13:10] <jcastro> ok, the ones without juju in the filename
[13:10] <jcastro> are just the normal vanilla vagrant boxes
[13:11] <jcastro> the ones with juju in them are supposed to bootstrap/gui, etc. with juju
[13:11] <adeuring> aisrael: the smaller files are "plain" ubuntu cloud images, while the larger files have juju preinstalled, and the Juju GUI is installed during Vagrant's provisioning
[13:11] <aisrael> jcastro: Oh, duh.
[13:11] <aisrael> ok, so that's one doc I should look at getting updated
[13:11] <jcastro> which one?
[13:11] <aisrael> https://juju.ubuntu.com/docs/howto-vagrant-workflow.html
[13:12] <aisrael> points to a non-existent box, in current/
[13:12] <jcastro> ah yes
[13:12] <jcastro> damn, I fixed the config-vagrant page
[13:12] <jcastro> but totally forgot about this one, yeah, fix it in the docs please.
[13:12] <aisrael> and I'm still troubleshooting why the networking problem
[13:13] <jcastro> https://github.com/juju/docs has the instructions
[13:13] <jcastro> they're in markdown, very easy to fix
[13:13] <aisrael> excellent, I'll add to my list today
[13:13] <jcastro> mbruzek, coreycb: did you guys not review yesterday?
[13:14] <mbruzek> jcastro What makes you say that?
[13:14] <coreycb> jcastro, review what?
[13:14] <jcastro> the review queue, you guys were on the calendar yesterday
[13:15] <coreycb> jcastro, hmm not familiar with the calendar.. sorry.  I do need to start doing more reviews though.
[13:15] <jcastro> we each were  supposed to pick 2 hours a week to review, then send the results to the list.
[13:15] <mbruzek> Yes I reviewed the ufw changes for elasticsearch and I DID email the group about it.
[13:16] <mbruzek> jcastro, I think you have coreycb mixed up with cory_fu
[13:17] <jcastro> hah yes I do! sorry about that coreycb
[13:17] <jcastro> I meant cory_fu
[13:17] <coreycb> jcastro, ahh, np
[13:18] <jcastro> oh excellent!
[13:18] <jcastro> mbruzek, I now see both of your [Review Queue] posts, that is quite excellent!
[13:19] <mbruzek> thanks for the positive reinforcement jcastro
[13:19] <mbruzek> and for checking up on me
[13:19] <jcastro> hah
[13:19] <jcastro> it is unclear to me if you merged his changes though
[13:29] <jam> marcoceppi: turns out it only happens if you don't have an environment set
[13:29] <jam> I *might* be rare in not having a default env
[13:29] <marcoceppi> jam: that's fun!
[13:29] <jam> or using juju switch
[13:29] <jam> marcoceppi: I always run "juju command -e env"
[13:29] <jam> so that I know what environment it is running in
[13:32] <ctlaugh> jamespag`: Hi, mwhudson sent me... I'm having a problem with the cinder charm on a system with only 1 drive.  I am trying to have it use a loopback file for storage.  The file is created, the loop device (/dev/loop0) is created, but the volume group is never created.
[14:03] <rm4> I managed to get charm debug working
[14:03] <rm4> thanks for that
[14:04] <rm4> bit of a different prompt to documentation though
[14:04] <rm4> https://juju.ubuntu.com/docs/authors-hook-debug.html shows ~
[14:05] <marcoceppi> rm4: ah, yes, debug-hooks shows unit/hook-context now
[14:06] <rm4> root@vagrant-local-machine-34:/var/lib/juju/agents/unit-wordpress-3/charm/hooks# relation-get
[14:06] <rm4> private-address: 10.0.3.181
[14:06] <rm4> yes I think so
[14:07] <marcoceppi> rm4: that's the prompt you get for debug-hooks?
[14:07] <marcoceppi> it should look like wordpress/3@<hook-name>
[14:35] <rm4> that was the prompt for debug-hooks yes
[14:38] <jrwren_> rm4: is that window 0 of tmux or window 1 ?
[14:39] <rm4> 12.04.5  0:- 1:website-relation-departed*
[14:39] <rm4> I think that is 1
[14:49] <rm4> I was in /home/ubuntu
[19:01] <natefinch> marcoceppi: are you and the other charmers on the juju-dev mailing list?
[19:02] <marcoceppi> natefinch: I am
[19:02] <natefinch> marcoceppi: ahh, right, I remember you responding to the default-hook thread.
[19:03] <natefinch> marcoceppi: you offered to survey the current charms and see which ones used the all-symlink model... do you know when you might get that done?  I know it's a big job.
[19:16] <marcoceppi> natefinch: I can do that now, should take about 15 mins
[19:18] <natefinch> marcoceppi: that would be fantastic, thank you
[19:32] <marcoceppi> natefinch: here are precise charms in the store, slightly curated: http://paste.ubuntu.com/8100495/
[19:32] <marcoceppi> natefinch: and the command used to get that, by running it in a directory which `charm getall` was fetched
[19:32] <marcoceppi> for f in `find */hooks/ -maxdepth 1`; do if [ -L $f ]; then echo "$(echo $f | awk -F/ '{print $1}') `readlink $f`"; fi; done | sort | uniq
[19:33] <marcoceppi> charm common file
[19:34] <marcoceppi> well, "charm" "common file" is the output
[19:41] <natefinch> marcoceppi: nice
[19:44] <natefinch> marcoceppi: so, are there any that symlink only some of the hooks?
[19:44] <marcoceppi> natefinch: yes
[19:44] <marcoceppi> natefinch: most all hooks that say relation_common
[19:44] <marcoceppi> indicates that only some of the hooks of that are symlinked
[19:45] <marcoceppi> I also removed entries that were just sylinks between relation-joined and relation-changed
[19:45] <marcoceppi> since that's a stupid pattern and easy enough to clean up
[19:45] <natefinch> marcoceppi: heh
[19:46] <natefinch> marcoceppi: so how many charms are there total?  I'd like to know what this is 62 out of :)
[19:47] <marcoceppi> 162
[19:47] <marcoceppi> also, there are some dupliates in there
[19:47] <marcoceppi> as some are inconsistently symlinked (./hooks.py vs hooks.py)
[19:47] <marcoceppi> that list needs to be curated a bit more
[19:48] <marcoceppi> also does not include trusty charms
[19:59] <natefinch> marcoceppi: thanks, I got rid of dupes, easy enough
[20:54] <mwhudson> ctlaugh: :(