[00:17] 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] debug-hooks never shows anything, despite no errors being visible in juju status. [00:18] 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] is filling my logs, but that's about the only interesting thing. [00:20] 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] 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] wgrant: install wouldnt necessarily equate to started - that means it thinks it reached the start hook. :| [00:21] but, no config-changed after updating config is troubling [00:22] 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] 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] Er, install or upgrade-charm, rather. [00:27] right, i'm thinking what else could block a config-changed event [00:27] 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 :( === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [03:38] Hows it going everyone? [03:39] Can anyone give a few examples for possible values for the flat-network-providers config [03:39] for quantum-gateway? [03:49] bdx: https://jujucharms.com/quantum-gateway/trusty/16 says "Space-delimited list of Neutron flat network providers." [03:50] bdx: I'm not sure what an individual Neutron flat network provider looks like [03:50] but a wild stab in the dark would ip addresses [03:51] thumper: you and I need to learn more about our big buddy openstack. [03:51] lazyPower_: almost certainly [03:51] lazyPower_: I'll put it up there with paxos and raft [03:51] :) [03:51] I kinda sorta understand raft [03:51] paxos however - pfffffffffffffffffft [03:51] * thumper goes back to implementing 'juju system login' [03:51] aint nobody got time for that [05:21] thumper: Thanks [05:22] Does anyone know where a good example of deploying a dvr stack using juju might be located at? === urulama_ is now known as urulama === stub` is now known as stub [10:44] bdx: are you referring to like deploying mythbuntu? (dvr = digital video recorder?) [10:51] gsamfira: o/ [11:24] lazyPower: no....openstack with dvr [11:27] bdx: ah, looking into neutron stuff. i had to google it [11:27] sorry :( i'm not going to be much help in this effort. [12:16] hazmat: ping [13:31] lazyPower_: pong [13:31] hazmat: I found a solution to my problem during the break :) [13:32] lazyPower_: cool [13:47] lazyPower_, https://plus.google.com/hangouts/_/hoaevent/AP36tYfpg6vIOgpBcl3zoASu8vfjOaJViFvk6yT4g7z7CfU8B6QnCw?authuser=0&hl=en [14:03] 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] Bug #1444861: Juju 1.23-beta4 introduces ssh key bug when used w/ DHX

[14:03] perrito666 has a branch up, and it's pretty simple to make the output less vile at the same time [14:04] (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] 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] lazyPower_: ta === urulama is now known as urulama__ === wolsen_ is now known as wolsen [16:54] Anyone know if it's possible to get the juju action id from within the action environment? [16:55] ennoble: Yes, it should be there. I can check the key [16:55] charmers: This MP needs you: https://code.launchpad.net/~hatch/charms/precise/ghost/trunk/+merge/255168 [16:56] aisrael: I can't seem to find it in any environment variables, action-get, ... [16:57] ennoble: JUJU_ACTION_UUID [16:57] - id: e23d3f13-15d6-4b82-8af5-1e151537892a status: pending unit: test/0 [16:58] 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] 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] aisrael: inside the action when it's being executed. So I'm running juju debug-hooks 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] aisrael: hey that was merged [17:01] ohh nm [17:01] it was reviewed but never merged :) [17:01] hatch: Yeah, oops! [17:01] YEAH! get on it :P [17:01] aisrael, hatch: i'll merge it now [17:01] :) thanks tvansteenburgh [17:02] that reminds me I should get back working on that [17:02] I'm torn on how to do backups though... [17:02] and upgrades [17:03] 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] aisrael: Are you sure? it's happening for me [17:06] 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] ennoble: confirming [17:07] aisrael, ennoble yeah, I discovered recently that debug-hooks works with actions [17:08] jw4: Excellent. Do we know if it's 100% working, i.e., the issue ennoble is seeing? [17:08] sounds like he's getting a hook context env rather than the action's context [17:08] aisrael: no, it's accidentally working so I can easily imagine issues like ennoble is reporting [17:09] we can file a bug and get that fixed [17:12] 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] Bug #1366834: [New charm] Ubuntu repository cache for cloud partners [17:17] jw4: Will you file, or would you like me to do it? [17:21] aisrael: sorry I dropped off; is the JUJU_ACTION_ID available in a newer version of juju? [17:22] 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] aisrael: ok, so if I don't use the debug-hooks I should see the JUJU_ACTION_ID variable? [17:24] ennoble: correct. We'll get a bug filed for that so the behavior works as expected in a future release [17:25] 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] ennoble: Yes, they work like charm hooks in that they're queued and run in the order submitted [17:27] 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] https://wiki.ubuntu.com/MOTU/GettingStarted [17:27] ennoble: I believe it should, yes. [17:27] whoops, wrong channel ignore me [17:28] aisrael: thx again [17:32] aisrael: sorry, OTP [17:44] stub: you around? [17:47] hatch: i lied, ping. [17:47] er [17:47] hazmat: i lied, re:ping. [17:47] what [17:48] 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] oh :) [17:48] lazyPower_: what's up? [17:48] hazmat: any chance we can co-maintain the pypi project for juju-deployer? [17:48] lazyPower_: sure [17:48] lazyPower_: what's your pypi id? [17:49] tvansteenburgh :D [17:49] hehe, hang on, lemme fish that up [17:49] pretty sure its lazypower - but i need to double check [17:49] yeah add me too [17:49] lazyPower_: :-) that works.. i'll have to do it when i get home. don't have my credentials on my current computer [17:52] ennoble: it should be JUJU_ACTION_UUID [17:54] aisrael: maybe I'm doing something wrong, but I'm not seeing it [17:55] ennoble: Can you pastebin what you're seeing? I'll get an environment w/actions spun up shortly and verify [17:58] 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] jw4: you got it [18:07] duuuuude [18:07] testing windows charms? use pester! https://github.com/pester/Pester [18:07] #TIL [18:08] lazyPower_: ah yea cloudbase showed that off in nuremberg [18:10] i just learned about this, i'm really impressed at the level of tooling they've written around charming for windows [18:42] ahhh they didnt write pester, they just consumed it with great success. [18:42] nifty all the same [18:48] office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en [18:55] office hours here: https://plus.google.com/hangouts/_/hoaevent/AP36tYeqRbxEExDyG6Q6yjS24zxmhYScseYHDXq0S7Z59CrheB_ahg?authuser=0&hl=en [18:55] for those of you on the other side of the netsplit [19:00] we'll be taking questions here and in #ubuntu-uos-cloud [19:39] lazyPower_: added tvan for it, i don't see a pypi user for you [19:40] bueno, i'll bug tim for gating :) [19:40] thanks hazmat [19:40] rick_h_: is there anyone on your team you want to have pypi uploads for deployer ? [19:40] 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] rick_h_: added frankban [19:41] hazmat: ty [22:02] 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] 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] ennoble: what version of juju are you running? [22:19] aisrael: 1.23.2 [22:20] ennoble: Huh. Definitely a little strange. What's the command line you're invoking the action with? [22:21] aisrael: juju action do test/0 bench [22:30] ennoble: here's what my env looks like: http://pastebin.ubuntu.com/11000481/ [22:31] ennoble: Did you upgrade an environment from a previous version of juju? [22:34] 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] ennoble: if you run a juju status, you could see if the unit agents are on the newer version of juju [22:35] 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] aisrael: yes, the agent version is 1.22,1 [22:50] ennoble: Ahh, that would probably do it. Either a fresh environment, or `juju upgrade-juju --upload-tools` should take care of it [22:50] aisrael: thanks for all your help and sorry about the wild goose chase [22:50] ennoble: No worries! I'm glad we figured it out. [22:57] ennoble: Also, you should also see the JUJU_ACTION_ variables when you run debug-hooks [22:59] jw4: fwiw, I am able to use debug-hooks against actions and everything appears to work. [23:03] aisrael: nice, thanks for verifying and letting me know too [23:30] is there a floating point type that works with actions? [23:33] `float` should work, I think [23:45] 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] i thought actions only supported the same var types we have implemented for config - int, bool, and string