=== vladk|offline is now known as vladk === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [07:51] jam, mgz: Hi there ! We are severely affected by bug #1200267 to the point where people feel discouraged to write integration tests. The bug description perfectly capture our use case, yet, the importance is 'Low'. What's your pov on that ? [07:51] <_mup_> Bug #1200267: Expose when stable state is reached

[07:52] jam, mgz: Don't get me wrong, I realize you may have more urgent issues but I'd like to understand what can be expected from juju or amulet in the short term === isviridov|away is now known as isviridpv === isviridpv is now known as isviridov === psivaa-afk is now known as psivaa [10:08] vila: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.mqzqdofq7hgv is a spec that we worked on for having charms be able to report when they've finish what they're working on to report "ready". [10:08] also some discussion on it here: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.9euay17obra7 [10:08] I believe it falls under "Observability" which is tasked to Tanzanite (wallyworld's team) [10:08] but later in this cycle [10:08] say 3 months out or so [10:08] * wallyworld_ takes note [10:09] wallyworld_: you're on my radar now ;-D [10:09] \o/ [10:09] jam1: thanks ! /me reads [10:09] wallyworld_: is it accurate to say that "charm status" is on your work items? [10:10] I was trying to sort through all the stuff that we discussed and if it actually got scheduled [10:10] it's all a bit open ended, but it can be if it's considered important [10:11] wallyworld_: I certainly know people who want it, the main question is relative importance [10:11] "observability" got scheduled to you, but I think it covers a lot of items [10:11] yep. i've reached out to stakeholders (dan, antonio, kapil etc) to ask for input [10:12] wallyworld_: there is also https://bugs.launchpad.net/juju-core/+bug/1254766 sounds dupe-ish [10:12] <_mup_> Bug #1254766: unit "started" status is unhelpful

[10:12] jam1: so that would be the 'ready/unready' hooks in 'State, status, charm reporting' ?... Hmm, right, may be more even in that section [10:12] there was also a separate discussion about an "idle" indicator, separate from charm health [10:12] yes, we did discuss that [10:13] our todo lists is not yet fully formed [10:14] jam1: anyway, you've perfectly answered, thanks [10:14] wallyworld_: ETA please ! [10:14] :-D [10:14] wallyworld_: kidding ;) [10:14] lol [10:15] I'm trying to debug an issue with juju not bootstrapping on openstack. Running in debug mode I see it retrieving the json with the image list but then "index has no matching records". What I don't see in the debug is a statement of what key is being used to do the lookup. I'm asking for a trusty amd64 image, I see trusty amd64 images listed so I'm not sure where to go from here [10:15] vila: we're finishing up on the github migration and some other feature work eg availability zones. next we'll be looking at what customer facing issues / bugs we should target [10:16] gnuoy: what version of juju? [10:17] wallyworld_, 1.18.4-trusty-amd64 [10:17] private cloud? or do you have access to http://streams.canonical.com/? [10:18] wallyworld_, private cloud and I believe the list in our cloud is updated daily so something could have gone wrong in the simplestream update process. But from what I can see it all looks good [10:19] wallyworld_: I'm subscribed to bug #1254766 and bug #1200267 and officially nominate them to be my 3 wishes ;-D [10:19] <_mup_> Bug #1254766: unit "started" status is unhelpful

[10:19] <_mup_> Bug #1200267: Expose when stable state is reached

[10:19] sure, np, thanks for the input [10:19] wallyworld_, http://paste.ubuntu.com/7638201/ [10:20] gnuoy: what does "juju metadata validate-images" say? [10:21] wallyworld_, http://paste.ubuntu.com/7638212/ [10:22] line 54 of http://paste.ubuntu.com/7638201/ shows a "trusty 14.04 amd64" entry [10:22] gnuoy: if you look inside your index.json file, does it have data for region "serverstack" and endpoint " http://10.98.191.25:5000/v2.0" ? [10:23] wallyworld_, yes, http://paste.ubuntu.com/7638231/ [10:24] can you paste the whole file? [10:24] wallyworld_, sure [10:25] wallyworld_, http://paste.ubuntu.com/7638235/ [10:26] gnuoy: and you have daily streams configured? [10:27] wallyworld_, sorry, I don't understand. The data is updated daily, is that what you're asking ? [10:28] gnuoy: there are often 2 different streams [10:28] "released" [10:28] and "daily" [10:28] gnuoy: simestreams uses a stream type eg daily or released to distinguish images [10:28] com.ubuntu.cloud.daily:server:14.04:amd64 [10:28] you have to configure "image-stream: daily" in order to get daily streams [10:28] is the key in the index file [10:28] what jam1 said [10:28] your index file contains daily images [10:29] so juju needs to be told thst [10:29] or else it looks for released images by default [10:29] ah, so in environments.yaml ? [10:29] Yes, I have that set [10:29] yup [10:31] hmmm [10:33] gnuoy: looks like it can only find 1.18.3 tools [10:33] 2014-06-13 10:05:40 DEBUG juju.environs.simplestreams simplestreams.go:883 metadata: &{map[com.ubuntu.juju:12.04:i386:{ 1.15.0 i386 map[20140603:0xc2100f1d20]} com.ubuntu.juju:13.04:amd64:{ 1.14.1 amd64 map[20140603:0xc210106120]} com.ubuntu.juju:13.10:amd64:{ 1.14.1 amd64 map[20140603:0xc210106360]} com.ubuntu.juju:14.04:amd64:{ 1.16.2 amd64 map[20140603:0xc2101065a0]} com.ubuntu.juju:14.10:amd64:{ 1.18.2 amd64 [10:33] map[20140603:0xc210106a80]} com.ubuntu.juju:14.10:arm64:{ 1.19.2 arm64 map[20140603:0xc210106ba0]} com.ubuntu.juju:14.10:i386:{ 1.18.2 i386 map[20140603:0xc210106cc0]} com.ubuntu.juju:14.10:ppc64:{ 1.19.2 ppc64 map[20140603:0xc210106de0]} com.ubuntu.juju:12.04:amd64:{ 1.14.1 amd64 map[20140603:0xc2100f1c00]} com.ubuntu.juju:13.10:i386:{ 1.15.0 i386 map[20140603:0xc210106480]} com.ubuntu.juju:14.04:i386:{ 1.16.2 i386 [10:33] map[20140603:0xc210106840]} com.ubuntu.juju:12.10:amd64:{ 1.14.1 amd64 map[20140603:0xc2100f1ea0]} com.ubuntu.juju:12.10:i386:{ 1.15.0 i386 map[20140603:0xc210106000]} com.ubuntu.juju:13.04:i386:{ 1.15.0 i386 map[20140603:0xc210106240]} com.ubuntu.juju:14.04:arm64:{ 1.17.2 arm64 map[20140603:0xc210106720]} com.ubuntu.juju:14.04:ppc64:{ 1.19.2 ppc64 map[20140603:0xc210106960]}] map[] Tue, 03 Jun 2014 08:02:36 +0000 products:1.0 [10:33] com.ubuntu.juju:released:tools} [10:33] 2014-06-13 10:05:40 INFO juju.environs.bootstrap bootstrap.go:58 picked newest version: 1.18.3 [10:33] wallyworld_, and that would effect its ability to find the right disk image ? [10:34] yes, if you are bootstrapping with 1.18.4 [10:34] i think it needs an exact match [10:34] 1.18.4 client i mean [10:34] wallyworld_, I took " picked newest version: 1.18.3" to mean, "shrug, I'd have liked 1.18.4 but 1.18.3 will do" [10:35] wallyworld_, ok, let me have a go at fixing that and I'll report back on my result [10:35] i think it is saying that it looked in the metadata and found all these versions and it picked the latest [10:52] wallyworld_, I've added the latest tools and I can see bootstrap picking them up. The image lookup is still failing though, http://paste.ubuntu.com/7638333/ [10:58] gnuoy: can you paste the products file at streams/v1/com.canonical.serverstack.serverstack:ubuntu:daily.json [10:59] wallyworld_, that was the one I pasted before, http://paste.ubuntu.com/7638235/ [11:01] gnuoy: oh sorry, the other one then, the index file? [11:01] sure, np [11:02] wallyworld_, http://paste.ubuntu.com/7638362/ [11:16] wallyworld_, I need to nip out for about an hour [11:16] gnuoy: ok, i'm looking at thedata and see no reason for it not to match [11:16] :-( [12:10] wallyworld_, it'd be really useful if juju said what key it was looking for, or maybe the logic is more complicated than that. [12:11] gnuoy: i can't recall ottomh exactly what it logs, but yeah [12:12] i'll have to use your metadata to set up something locally and try and see why it's failing [12:12] but it's quite late here and i'm falling asleep sadly so i can only do it tomorrow or something [12:14] wallyworld_, np, I shall keep digging. [12:14] ok, email me if you want and i'll see what i can do over the weekend [12:14] wallyworld_, I can pick it up with you on monday [12:15] ok === vladk is now known as vladk|offline === psivaa is now known as psivaa-afk [14:22] marcoceppi, i haven't tried on osx.. i've resurrected my osx machine though, i can give it a whirl [14:22] marcoceppi, part of the issue on osx is that the brew setup is out of date, 1.16 style.. and that's not supported [14:22] marcoceppi, i've got an extant bug that we should be distributing/compiling osx binaries [14:31] Hello, one question, exist some chance that a Hook do a callback to the machine where was executed juju set for example? [14:40] hi lazyPower, does your name in the channel title mean you are on the hook for charm reviews? [14:40] if so I'd appreciate a look at https://code.launchpad.net/~james-w/charms/precise/haproxy/metrics/+merge/221408 [14:40] james_w: ack, i'll take a look shortly. i'm in a meeting [14:40] thanks [15:00] james_w: looking now [15:10] wallyworld_, I added some debug to my client http://paste.ubuntu.com/7639281/ which showed that the items were lacking the endpoint and region fields and hence the match was failing. I've spoken to smoser and he was doing some work on the format of the simple streams data published. It looks like this has exposed a bug in juju in that higher level config options should apply to lower level ones but juju when looking for an image match is not using the high [15:10] er level options === psivaa-afk is now known as psivaa [15:32] hazmat: brew has 1.18.3 [15:37] marcoceppi, cool good to know it got updated. [15:37] hey [15:37] marcoceppi, doesn't really change my perspective we should be distributing osx binaries the same way we do for windows [15:38] can someone read juju core code for me (as i'm to lazy) [15:38] hazmat: fwiw, juju-docean didn't quite work on osx [15:38] smoser, what do you need? [15:38] and tell me if [15:38] https://bugs.launchpad.net/simplestreams/+bug/1329805 [15:38] <_mup_> Bug #1329805: juju search for image does not find item if endpoint and region are inherited [15:38] if juju will look "up" at all for endpoint/region, or if the tags explicitly have to be on the item level. [15:38] marcoceppi, hmm.. i'll take a look, there's some extant patches for client that might resolve [15:38] i know it will not look up to sibling-of-products. [15:38] hazmat: cool, thanks [15:48] james_w: excellent tests! sorry its taken me a moment i got sidetracked, back on the review now [16:57] james_w: merged. Thanks for the contribution! [17:06] thanks lazyPower [17:33] is it possible to run juju in openstack from an instance in that same openstack region? [17:36] nuclearbob: I'm not sure I understand your question [17:36] but I think the answer is yet [17:36] yes* [17:47] marcoceppi, I'm got an instance setup in canonistack lcy 02, and I want to run juju in that instance, but whenver I run canonistack-sshuttle, I lose my ability to connect to the instance. I'm trying to set it up now without using sshuttle, but now I'm getting bootstrap failures, and I'm not sure how to reset things [17:47] nuclearbob: are you running canonistack-sshuttle from the instance? [17:47] marcoceppi, yes [17:48] nuclearbob: don't you're already in canonistack you don't need to run sshuttle [17:48] it should just work without any shuttleing [17:48] marcoceppi, okay, that makes sense [17:48] marcoceppi, now when I try to bootstrap, I get this: http://pastebin.ubuntu.com/7640009/ [17:49] nuclearbob: run with --debug see if it gives you more information [17:50] marcoceppi, it does: http://pastebin.ubuntu.com/7640012/ [17:51] nuclearbob: run juju destroy-environment --force [17:51] then try to bootstrap again [17:51] hi, i have units with failed, hooks.. resolve --rtry tells me "cannot set resolved mode for unit".. "already resolved" http://pastebin.com/msfTZSA4 [17:51] any way to get past that? [17:51] marcoceppi, http://pastebin.ubuntu.com/7640024/ [17:52] mattrae_: how long has it been since you first ran resolved? and did it first work or has it been suck always? are you in debug hooks? [17:53] marcoceppi: i tried to do debug-hooks to debug this after trying --retry.. now i'm thinking maybe the hook is still running.. just very slowly [17:54] marcoceppi: i didn't see any output for awhile from the unit log.. but looks like it moved forward [17:55] yeah the hook finally finished running === roadmr is now known as roadmr_afk [18:18] marcoceppi: will you need me to host that call? [18:25] jose: for TSII? [18:25] mhm [18:29] lazyPower: ^ [18:30] jose: Wouldn't hurt. Castro is out and marco's in a meeting. [18:30] ok [18:30] he's going to be up to the wire [18:30] I'll go and have lunch, then, bbiab === CyberJacob|Away is now known as CyberJacob [18:51] jose: ? [18:51] I can run it, if I find the password in time [18:51] marcoceppi: troubleshoothing one [18:51] I already set it up [18:51] s/one/two/ [18:51] yay [19:01] Troubleshooting II is starting everyone! [19:01] If yo have any questions, feel free to target me and i'll make sure we get them covered [19:02] what is Troubleshooting II? [19:02] The second edition of Juju Troubleshooting [19:02] ali1234: http://www.ubuntuonair.com [19:02] http://ubuntuonair.com/ [19:03] wait, i dont see it. i see the plenary on UOA [19:03] @josedid we get UOA updated? [19:03] yeah me too [19:03] ali1234: refresh :) [19:04] so..... any idea why i can't do a local bootstrap? [19:04] ali1234, We need the error, put the error on pastebin and we could help [19:04] mbruzek: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1329429 [19:04] <_mup_> Bug #1329429: local bootstrap fails

[19:07] ali1234: i've pinged in #juju-dev with your issue pending response from someone taking a look [19:08] they may have additional questions - so you might want to preemptively join #juju-dev to field those as they come in [19:08] with it being a null pointer dereference, its obv. a bug in the code somewhere and requires more intervention than I can provide as a non-developer. [19:21] any questions? [19:33] if i'm doing debug-hooks and I want to pause execution leaving a hook in an error state, by using 'exit 1'.. if i see juju move on to execute the next hook, is this normal? i though exit1 should pause execution of hooks so I can exit from tmux and run juju resolved --retry to restart execution [19:34] mattrae_: not sure if you're on the troubleshooting hangout following along [19:35] however, its a bug and known behavior - debug-hooks doesn't seem to respect the exit code you provide the shell. [19:35] lazyPower: nope i'm not on the hangout. is there info about this troubleshooting hangout? [19:35] mattrae_: ubuntuonair.com [19:35] lazyPower: oh cool, thanks.. so its a bug [19:36] lazyPower, or whoever, I've got a different problem with juju local than I did last time. it seems to just hang when it gets to "Bootstraping Juju machine agent" debug output is here: http://pastebin.ubuntu.com/7640395/ [19:38] nuclearbob: not sure if it will help.. but maybe try adding --upload-tools? [19:38] mattrae_: I'll give it a try [19:39] nuclearbob: also if it was working previously.. maybe something is corrupt in .juju.. after destroy-environment --force it should be pretty empty [19:40] mattrae_, okay, I'll give it a chance to run again and then try moving that out if I need to [19:40] mattrae_, if I move .juju somewhere else, do juju init, and then restore my .juju/environments.yaml, is that a good way to restart things? [19:43] nuclearbob: yeah that should give you a fresh start.. i've seen sometimes where containers get left around as well.. i'm not sure if you're running into that in this case [19:43] mattrae_: what container names should I look for to delete? ones starting with my username? [19:44] nuclearbob: they'll be something like 'juju-machine-1-lxc-0' if when you run sudo lxc-ls [19:45] mattrae_: okay, I don't see any containers with juju in the name [19:45] nuclearbob: cool, just something to watch out for if one ever gets left around after destroy-environment [19:48] Thanks everyone for watching. Juju Troubleshooting II charmschool is officially closed [19:49] make sure you join us next week for working with / troubleshooting the local provider === roadmr_afk is now known as roadmr [19:54] lazyPower, when is the session on troubleshooting the local provider? [19:55] let me check the calendar, i'm pretty sure its same time next friday but it may be in 2 weeks [19:56] Interestingly enough I dont have it on the calendar. I'll track this down for you an ping you back with the info nuclearbob [19:57] nuclearbob: We're going to schedule it for 3-4PM EDT next friday. [19:58] lazyPower, cool, thanks [19:59] NP. We'll send a reminder email to the list next week [20:05] is a units public IP address something that I can do a relation-get for or does it have to have a relation-set first? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [20:42] if i reboot my computer, do all my local environment get started up automatically? [20:50] ali1234: yep. there are links left behind to autostart the containers === Ursinha is now known as Ursinha-afk [20:57] hey lazyPower o/ [20:57] hey sebas i'm im nearly home. I'm going to be about 5 minutes late [20:57] what do you think if we start a hangout live [20:57] of course, no rush :) === CyberJacob is now known as CyberJacob|Away [21:03] sebas5384: you want to hangouts on air? [21:03] just for recording [21:04] there are some people here that can't join us right now [21:04] sure thats fine [21:04] but want to watch it later [21:04] i need a minute or two to get settled and i'm good 2 go [21:04] awesome :) [21:09] https://plus.google.com/hangouts/_/hoaevent/AP36tYfF6VnfsnVX5hl_jMiONm-ybp7bfiniyN2j9tR3c48Z2Vsjhg?authuser=0&hl=en sebas5384 === isviridov is now known as isviridov|away [22:19] lazyPower: https://github.com/sebas5384/juju-vagrant-plugin [22:43] Hey, I noticed that there is documentation on juju debug-log (https://juju.ubuntu.com/docs/config-LXC.html) regarding a bug that prevents it from working as expected. However the bug (https://bugs.launchpad.net/juju-core/+bug/1202682) shows that the fix has been released, so the bug at this point no longer "exists" and I think the docs should be updated to reflect that. [22:43] <_mup_> Bug #1202682: debug-log doesn't work with lxc provider

[22:58] JoshStrobl, thanks for the catch, can you send a note to dev list? [23:08] alexisb: #juju-dev ? Gotta add myself back on, but yea I'll send off the mail. === Ursinha-afk is now known as Ursinha [23:34] lazyPower: here's the link of the session I told you https://amsterdam2014.drupal.org/session/devops-where-start [23:46] gnuoy: that's great detective work. when i looked at your data i saw that the region/endpoint were defined higher up and assumed they were inherited. i'll investigate and may need to fix juju if there's been a regression [23:47] When I start a new charm, juju will choose the *first* matching/free machine and deploy the charm without trying to be clever about chosing "the best" machine, right?