[00:17] <wgrant> Using juju-core 1.23.2 with the local provider on a vivid host with trusty containers, I'm not seeing config-changed fire.
[00:18] <wgrant> debug-hooks never shows anything, despite no errors being visible in juju status.
[00:18] <wgrant> machine-0: 2015-05-06 00:18:04 ERROR juju.worker runner.go:219 exited "machiner": cannot set machine addresses of machine 0: cannot set machineaddresses for machine 0: state changing too quickly; try again soon
[00:18] <wgrant> is filling my logs, but that's about the only interesting thing.
[00:20] <lazyPower_> wgrant: meaning it just skips? or you only get the install hook executed - and the rest of the hook queue is silently dropped?
[00:21] <wgrant> lazyPower_: I assume the install hook fired, as my services started. But even after a container reboot I still get nothing showing up in debug-hooks after I change config on any of my services.
[00:21] <lazyPower_> wgrant: install wouldnt necessarily equate to started - that means it thinks it reached the start hook. :|
[00:21] <lazyPower_> but, no config-changed after updating config is troubling
[00:22] <lazyPower_> are you certain there's nothing attached to a unit blocking hook context? eg: debug-hooks on a unit in a dependent container?
[00:22] <wgrant> lazyPower_: Well, I know install or config-changed fired at some point, as code that's only run in those cases has run at least once.
[00:23] <wgrant> Er, install or upgrade-charm, rather.
[00:27] <lazyPower_> right, i'm thinking what else could block a config-changed event
[00:27] <lazyPower_> but if no service is in error, no subordinates attached that are quietly in error, and no debug-hooks action on the unit... it seems like you've uncovered a bug :(
[03:38] <bdx> Hows it going everyone?
[03:39] <bdx> Can anyone give a few examples for possible values for the flat-network-providers config
[03:39] <bdx> for quantum-gateway?
[03:49] <thumper> bdx: https://jujucharms.com/quantum-gateway/trusty/16 says "Space-delimited list of Neutron flat network providers."
[03:50] <thumper> bdx: I'm not sure what an individual Neutron flat network provider looks like
[03:50] <thumper> but a wild stab in the dark would ip addresses
[03:51] <lazyPower_> thumper: you and I need to learn more about our big buddy openstack.
[03:51] <thumper> lazyPower_: almost certainly
[03:51] <thumper> lazyPower_: I'll put it up there with paxos and raft
[03:51] <thumper> :)
[03:51] <lazyPower_> I kinda sorta understand raft
[03:51] <lazyPower_> paxos however - pfffffffffffffffffft
[03:51]  * thumper goes back to implementing 'juju system login'
[03:51] <lazyPower_> aint nobody got time for that
[05:21] <bdx> thumper: Thanks
[05:22] <bdx> Does anyone know where a good example of deploying a dvr stack using juju might be located at?
[10:44] <lazyPower_> bdx: are you referring to like deploying mythbuntu? (dvr = digital video recorder?)
[10:51] <lazyPower_> gsamfira: o/
[11:24] <bdx> lazyPower: no....openstack with dvr
[11:27] <lazyPower_> bdx: ah, looking into neutron stuff. i had to google it
[11:27] <lazyPower_> sorry :( i'm not going to be much help in this effort.
[12:16] <lazyPower_> hazmat: ping
[13:31] <hazmat> lazyPower_: pong
[13:31] <lazyPower_> hazmat: I found a solution to my problem during the break :)
[13:32] <hazmat> lazyPower_: cool
[13:47] <jcastro> lazyPower_, https://plus.google.com/hangouts/_/hoaevent/AP36tYfpg6vIOgpBcl3zoASu8vfjOaJViFvk6yT4g7z7CfU8B6QnCw?authuser=0&hl=en
[14:03] <mgz_> lazyPower_: when you have a mo, can you give some feedback on what output you actually want in the error cases for bug 1444861?
[14:03] <mup> Bug #1444861: Juju 1.23-beta4 introduces ssh key bug when used w/ DHX <dhx> <ssh> <juju-core:Triaged> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1444861>
[14:03] <mgz_> perrito666 has a branch up, and it's pretty simple to make the output less vile at the same time
[14:04] <mgz_> (I'm thinking duplicate notices should just give fingerprint not whole line, and maybe we want to be more careful about what we call invalid?)
[15:15] <lazyPower_> mgz_: thanks for the follow up - I think thats a fine solution - i've also referred cory_fu the author of DHX to this error for his feedback if any.
[15:16] <mgz_> lazyPower_: ta
[16:54] <ennoble> Anyone know if it's possible to get the juju action id from within the action environment?
[16:55] <aisrael> ennoble: Yes, it should be there. I can check the key
[16:55] <aisrael> charmers: This MP needs you: https://code.launchpad.net/~hatch/charms/precise/ghost/trunk/+merge/255168
[16:56] <ennoble> aisrael: I can't seem to find it in any environment variables, action-get, ...
[16:57] <aisrael> ennoble: JUJU_ACTION_UUID
[16:57] <ennoble> - id: e23d3f13-15d6-4b82-8af5-1e151537892a   status: pending unit: test/0
[16:58] <ennoble> aisrael: interesting, I don't see that environment variable in my action environment. I'm running 1.23.2-trusty-amd64 There is a JUJU_CONTEXT_ID and a JUJU_ENV_UUID=
[16:59] <aisrael> When you say 'action environment', are you testing this from machine you're running juju from, or inside an action when it's being executed (the action context)
[17:00] <ennoble> aisrael: inside the action when it's being executed. So I'm running juju debug-hooks <unit name>  and then running juju action do ... on another terminal. the action environment starts in debug-hooks tmux session and I'm looking at the environment variables
[17:00] <hatch> aisrael: hey that was merged
[17:01] <hatch> ohh nm
[17:01] <hatch> it was reviewed but never merged :)
[17:01] <aisrael> hatch: Yeah, oops!
[17:01] <hatch> YEAH! get on it :P
[17:01] <tvansteenburgh> aisrael, hatch: i'll merge it now
[17:01] <hatch> :) thanks tvansteenburgh
[17:02] <hatch> that reminds me I should get back working on that
[17:02] <hatch> I'm torn on how to do backups though...
[17:02] <hatch> and upgrades
[17:03] <aisrael> ennoble: action's can't be caught via juju debug-hooks, afaik. It's something we've asked to put on the roadmap for actions 2.0
[17:05] <ennoble> aisrael: Are you sure? it's happening for me
[17:06] <ennoble> aisrael: the JUJU_HOOK_NAME is set to the action name and the parameters I passed to the action are available via action-get, so I'm fairly certain it's working
[17:07] <aisrael> ennoble: confirming
[17:07] <jw4> aisrael, ennoble  yeah, I discovered recently that debug-hooks works with actions
[17:08] <aisrael> jw4: Excellent. Do we know if it's 100% working, i.e., the issue ennoble is seeing?
[17:08] <aisrael> sounds like he's getting a hook context env rather than the action's context
[17:08] <jw4> aisrael: no, it's accidentally working so I can easily imagine issues like ennoble is reporting
[17:09] <jw4> we can file a bug and get that fixed
[17:12] <aisrael> charmers: This one needs some attention. I just +1'd it, based on the testing I did pre-Malta to fix an amulet bug (since released): https://bugs.launchpad.net/charms/+bug/1366834
[17:12] <mup> Bug #1366834: [New charm] Ubuntu repository cache for cloud partners <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1366834>
[17:17] <aisrael> jw4: Will you file, or would you like me to do it?
[17:21] <ennoble> aisrael: sorry I dropped off; is the JUJU_ACTION_ID available in a newer version of juju?
[17:22] <aisrael> ennoble: The action working in the debug-hook is kind of accidental, and doesn't appear to be working the same as your running action would see it.
[17:23] <ennoble> aisrael: ok, so if I don't use the debug-hooks I should see the JUJU_ACTION_ID variable?
[17:24] <aisrael> ennoble: correct. We'll get a bug filed for that so the behavior works as expected in a future release
[17:25] <ennoble> aisrael: thx! one more actions question: are the actions guaranteed to execute in the order that they were submitted by a single user? I found a discussion about this about 6 months ago on the mailing list and it looks like the conclusion was they should.
[17:26] <aisrael> ennoble: Yes, they work like charm hooks in that they're queued and run in the order submitted
[17:27] <ennoble> aisrael: and charm hooks are ordered with actions as well? e.g. juju set ... juju action ... juju set ... juju action would respect that order?
[17:27] <rick_h_> https://wiki.ubuntu.com/MOTU/GettingStarted
[17:27] <aisrael> ennoble: I believe it should, yes.
[17:27] <rick_h_> whoops, wrong channel ignore me
[17:28] <ennoble> aisrael: thx again
[17:32] <jw4> aisrael: sorry, OTP
[17:44] <aisrael> stub: you around?
[17:47] <lazyPower_> hatch: i lied, ping.
[17:47] <lazyPower_> er
[17:47] <lazyPower_> hazmat: i lied, re:ping.
[17:47] <hatch> what
[17:48] <ennoble> aisrael: I don't think JUJU_ACTION_ID is being set, even outside of the debug-hooks. i just logged all the environment variables and it's not there
[17:48] <hatch> oh :)
[17:48] <hazmat> lazyPower_: what's up?
[17:48] <lazyPower_> hazmat: any chance we can co-maintain the pypi project for juju-deployer?
[17:48] <hazmat> lazyPower_: sure
[17:48] <hazmat> lazyPower_: what's your pypi id?
[17:49] <lazyPower_> tvansteenburgh :D
[17:49] <lazyPower_> hehe, hang on, lemme fish that up
[17:49] <lazyPower_> pretty sure its lazypower - but i need to double check
[17:49] <tvansteenburgh> yeah add me too
[17:49] <hazmat> lazyPower_: :-) that works.. i'll have to do it when i get home. don't have my credentials on my current computer
[17:52] <aisrael> ennoble: it should be JUJU_ACTION_UUID
[17:54] <ennoble> aisrael: maybe I'm doing something wrong, but I'm not seeing it
[17:55] <aisrael> ennoble: Can you pastebin what you're seeing? I'll get an environment w/actions spun up shortly and verify
[17:58] <jw4> aisrael: just got off the phone, but I'm out for a bit now.. if you'd like to file the bug that would be great.  Thanks!
[17:59] <aisrael> jw4: you got it
[18:07] <lazyPower_> duuuuude
[18:07] <lazyPower_> testing windows charms? use pester! https://github.com/pester/Pester
[18:07] <lazyPower_> #TIL
[18:08] <rick_h_> lazyPower_: ah yea cloudbase showed that off in nuremberg
[18:10] <lazyPower_> i just learned about this, i'm really impressed at the level of tooling they've written around charming for windows
[18:42] <lazyPower_> ahhh they didnt write pester, they just consumed it with great success.
[18:42] <lazyPower_> nifty all the same
[18:48] <jcastro> office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en
[18:55] <jcastro> office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en
[18:55] <jcastro> for those of you on the other side of the netsplit
[19:00] <jcastro> we'll be taking questions here and in #ubuntu-uos-cloud
[19:39] <hazmat> lazyPower_: added tvan for it, i don't see a pypi user for you
[19:40] <lazyPower_> bueno, i'll bug tim for gating :)
[19:40] <lazyPower_> thanks hazmat
[19:40] <hazmat> rick_h_: is there anyone on your team you want to have pypi uploads for deployer ?
[19:40] <rick_h_> hazmat: francesco and/or brad would be cool, but if we've got the others with access I'm happy to work through them
[19:41] <hazmat> rick_h_: added frankban
[19:41] <rick_h_> hazmat: ty
[22:02] <ennoble> aisrael: are you still around? here is the environment that I see http://pastebin.com/CdsuN7Sd I printed it from a python action so it's a dict (os.environ)
[22:16] <ennoble> aisrael: I see in the code where it's supposed to have JUJU_ACTION_(NAME|UUID|TAG) but it doesn't appear to be happening in my environment
[22:17] <aisrael> ennoble: what version of juju are you running?
[22:19] <ennoble> aisrael: 1.23.2
[22:20] <aisrael> ennoble: Huh. Definitely a little strange. What's the command line you're invoking the action with?
[22:21] <ennoble> aisrael: juju action do test/0 bench
[22:30] <aisrael> ennoble: here's what my env looks like: http://pastebin.ubuntu.com/11000481/
[22:31] <aisrael> ennoble: Did you upgrade an environment from a previous version of juju?
[22:34] <ennoble> aisrael: possibly. I certainly was using 1.22 previously but I'm fairly certain I destroyed it and started over, however I'll do that now just in case
[22:35] <aisrael> ennoble: if you run a juju status, you could see if the unit agents are on the newer version of juju
[22:35] <aisrael> The only difference I see is the provider. I'm using local, but you're on maas. I wouldn't think that would make a difference, though.
[22:40] <ennoble> aisrael: yes, the agent version is 1.22,1
[22:50] <aisrael> ennoble: Ahh, that would probably do it. Either a fresh environment, or `juju upgrade-juju --upload-tools` should take care of it
[22:50] <ennoble> aisrael: thanks for all your help and sorry about the wild goose chase
[22:50] <aisrael> ennoble: No worries! I'm glad we figured it out.
[22:57] <aisrael> ennoble: Also, you should also see the JUJU_ACTION_ variables when you run debug-hooks
[22:59] <aisrael> jw4: fwiw, I am able to use debug-hooks against actions and everything appears to work.
[23:03] <jw4> aisrael: nice, thanks for verifying and letting me know too
[23:30] <ennoble> is there a floating point type that works with actions?
[23:33] <aisrael> `float` should work, I think
[23:45] <ennoble> aisrael: it seems like 1.23 is much more strict on action types.. int doesn't work but integer seems to, however float doesn't: invalid action "bench": float is not a valid type
[23:56] <lazyPower_> i thought actions only supported the same var types we have implemented for config - int, bool, and string