[00:00] cory_fu: do you save off the dir that you found the bundle in anywhere in the code that you wrote related to finding bundles? [00:01] petevg: What? [00:01] I didn't write any code related to finding bundles [00:01] cory_fu: I mean, when you fall back to running in the bundle in the current dir ... [00:02] cory_fu: I can just read the code. [00:02] petevg: I'm not sure what you mean. That's just the default value of the argparse option [00:03] cory_fu: by which you mean, you do save it into the path config value. It's just late, and I'm not typing clearly :-) [00:04] ... or thinking clearly, obv === blahdeblah is now known as dreamin === dreamin is now known as blahdeblah [07:58] Good morning Juju world! [10:44] is it possible to run xenial services on xenial machines but with trusty bootstrap node? [10:53] jacekn: completely [10:53] jacekn: just deploy those using the trusty series and you'll be peachy [10:53] jacekn: we even do where the controller is ubuntu but then you run applications on machines in centos/windows [10:56] rick_h: ack, thanks [10:57] rick_h: I'm assuming that series within one service need to match correct? (so it's impossible to upgrade units one by one)? [10:57] jacekn: so upgrading a charm isn't upgrading the series [10:57] jacekn: so that's a bit different [10:57] jacekn: but yes, each application needs to match [10:58] jacekn: so you can deploy a charm twice, with a different application name, and they can be of different series [10:58] ok thanks, that's what I thought [11:01] rick_h: it's not possible to rename servcies right? [11:01] jacekn: no, cannot currently [11:02] alright === zz_CyberJacob is now known as CyberJacob [12:21] hmm I put https://review.jujucharms.com/reviews/49 up - but then think I might have actually pushed that to edge instead [12:33] Is it still supported to change the advertised IP address on a relation to some other IP address? IIRC it was blessed as a way of implementing proxies. [12:34] I'll test soon, but even if it works I'm not sure if it is something I should be doing. [14:16] bcsaller, cory_fu: would either of you mind if I just merged https://github.com/juju-solutions/matrix/pull/34 Having my work on other stuff depend on that branch is making my life complicated :-/ [14:16] i mind [14:16] petevg: :) I was just now giving it a last look and was going to merge it before sync [14:17] cory_fu: cool. Thx. [14:17] I guess I don't need to encourage magicaltrout to rebel against the tyranny of his own mind by dropping a +1 on my PR ... [14:18] i do like this matrix stuff I piss the guys off at JPL buy just randomly shutting down docker containers on some of our stuff occasionally [14:19] ... and my PR allows you do to that on services that you couldn't do that to before :- [14:19] :-) [14:22] petevg: Merged. Sorry that took so long. Thanks for putting up with my nit picking, but I am quite happy with the result. :) [14:22] cory_fu: thx for merging. Nit picking is okay -- we want this to be code that we're all proud of :-) [14:22] haha [14:23] at least you're entertained :-p [14:24] okay enough trolling petevg for now, I should probably do some.... work [14:24] as such, i'll delay that by fetching coffee [14:33] mthaddon: how long until this hits? https://code.launchpad.net/~mthaddon/mojo/additional-ready-states/+merge/312791 [14:35] skay_: hard to say - depends on the review [14:37] mthaddon: my new charm is in review, and I have feedback to change blocked to maintenance or waiting due to how mojo handles things currently. but, this looks like it will go in soon [14:38] skay_: I would imagine this would be merged/released within a week or so if that helps [14:38] mthaddon: ok [14:39] I'll mention it. we're not close to ready for production, so I am pretty sure the mojo change will be out first [14:40] (though, I think I could change it to waiting. if a human is around, they'll see the message about what it is waiting for. (the bug mentions it is debatable)) [15:16] Question about service/application config. I have a charm and I have defined some config options and can set and change them. What I haven't been able to find an example of, or understandable documentation on, is how to write a config-changed hook that will take the contents of each option and turn them into an environmnet variable on the machine. [15:17] so example, if I do juju set servicename target-ip="192.168.100.100", I want the config-changed hook to recognize that and do something like "export TARGET_IP=$target-ip" [15:28] bladernr: I responded on your bug [15:28] (unrelated to anything) [15:32] bladernr: to your question here, just export probably doesn't do what you want, you'd need to restart any services in the new context, or set globally in an rc file or something [16:30] Ankammarao_: i understand you're having trouble with sshuttle? there are a few of us here that have used sshuttle to tunnel traffic to a remote network. what's the issue? [16:33] i tried to login s390x machine on x86_64 machine (firefox working fine) [16:33] could you tell me how to exactly use the sshuttle === hml_ is now known as hml [16:37] Ankammarao_: sshuttle -r @

[16:37] Ankammarao_: sshuttle -r root@z10lnx04 10.0.3.0/24 [16:37] ^ as an example [16:39] kwmonroe, Z10LNX06.in.ibm.com this is the machine we are using [16:39] here i have instaled the sshuttle [16:39] ok, you need to install sshuttle on your local machine. is z10lnx06 local, or is that the remote server? [16:40] local machine only [16:41] ok, what's the name of your remote machine? [16:42] we have deployed the charm here only [16:42] so we are using the this server to run firefox [16:43] how we can now the juju-lxd-subnet [16:44] Ankammarao_: if you're local on the machine, you don't probably don't need sshuttle. just browse to the ip address of the lxd machine. [16:49] Ankammarao_: you can test that you have access to the lxd subnet from you local machine by trying to ping one of the lxd machines. if that works, then try 'curl ', if that works, then any browser should work too. [16:54] kwmonroe, is there any other browsers which supports the ubuntu [16:55] kwmonroe, i am able to accessing the lxd machine and pinging but unable to browsing [16:55] Ankammarao_: let's back up a minute. are you typing on a laptop or desktop right now? [16:56] typing on laptop [16:56] Ankammarao_: what OS is your laptop running? [16:56] windows 7 [16:57] ok.. so. Ankammarao_. here's where the confusion started. your *local* machine is your windows7 laptop. your remote machine is Z10LNX06. [16:58] and when you attempt to run a browser like firefox on your remote machine, it will likely fail because there is no window manager to handle firefox's gui from within a terminal. [16:59] kwmonroe, i am running the firefox on vnc server [16:59] kwmonroe, its working fine for x86_64 machine [17:00] but we are facing issue with s390x machine [17:02] Ankammarao_: so you're running vnc on your laptop and connecting to the destop of Z10LNX06. running firefox from there is what is crashing. is that right? [17:02] kwmonroe, yes exactly [17:04] Ankammarao_: ok. sshuttle won't work for you because i do not believe there is a windows client available. Ankammarao_ what version of ubuntu is running on Z10LNX06? [17:05] kwmonroe, Ubuntu 16.04.1 LTS [17:08] Ankammarao_: you should be able to 'sudo apt-get install chromium-browser' on Z10LNX06 and try that browser. if that crashes as well, you'll need to follow up on #ubuntu or perhaps #ubuntu-server. we're way outside of juju's world at this point.. [17:09] kwmonroe, we have tried with chromium-browser too its not getting installed [17:10] kwmonroe, can you suggest me the steps to try with sshuttle [17:10] Ankammarao_: sshuttle is not an option for you. there is no sshuttle for windows 7. [17:11] kwmonroe, okay [17:14] kwmonroe, so what could be the solution for browser issue on s390x ubuntu, can you redirect to some conatcts or channels [17:16] Ankammarao_: join #ubuntu-s390x and tell them you're having trouble launching firefox on your s390x machine when connecting through vnc. [17:16] kwmonroe, thanks [17:17] np - good luck Ankammarao_! [19:15] getting this error after creating a new vpc http://paste.ubuntu.com/23599855/ [19:15] I've ensured it has been provisioned identically to the other vpc's I'm using [19:15] my controller never seems to finish bootstraping .... [19:16] going to let the bootstrap timeout and see what gives there [19:31] ahhh, had to add a route to my igw in my routing table [20:05] i deployed openstack novalxd using conjure-up. it sets lxdbr0 as 10.4.57.1 and conjureup0 as 10.99.0.1, where the new instance on ext-net interface is assigned 10.99.0.14 [20:06] i cannot ping to this ip or ssh to it. it gives a destination unreachable error. [20:09] is this expected behaviour and what am i missing? [20:36] vargarwal: did you assign a floating-ip to the instance? [21:01] Hey, does anyone know if there's a problem with running a maas-region-controller and a maas-rack-controller each in LXDs on the same host? [21:13] derekcat: You might want to check in #maas [21:20] Ok, wasn't sure where to ask first since I'm deploying maas to the LXDs with juju [21:41] cory_fu: thinking aloud about matrix issue#39 ... I think that the problem is that glitch can run a select after a remove_unit command has been issued, but before that unit has been removed from the model. Glitch can then go and try to run an action on that unit as it is disappearing, or after it has disappeared. I guess the question is, is it glitch's [21:41] responsibility to make sure that I don't try to reboot a nonexistent unit? Or is it the api's responsibility to fail sensibly when I act on outdated info that I've gotten from the model? [21:42] cory_fu: on the one hand, I kind of want to reign in glitch. On the other hand, we agreed earlier that I probably shouldn't -- that we were trying to unearth exactly these sorts of broken situations, and make sure that our APIs and tools dealt with them appropriately. [21:43] cory_fu: did you happen to keep any of the glitch_plan files that caused your crash? [21:48] petevg: I didn't keep any, no, sorry. I don't feel like this is a problem with the API, though. I think it is reasonable for glitch to block until the unit is actually gone when it removes the unit, and I think it's also reasonable to ensure the plan doesn't include more remove_units than can possibly succeed. [21:49] The API can't do anything other than throw an error if you attempt to remove a non-existant unit. [21:52] is something going on with amazon? all my units i deploy are in the down state and never seem to boot [22:16] cory_fu: right. The API should throw an error. And then glitch should catch it and decide to either fail the test or ignore it and continue. The behavior that you saw, where it stalls out and gets stuck, isn't correct. [22:18] petevg: Yep, fair enough [22:18] cory_fu: I thought that I had thrown a try: except around the glitch actions, though. It looks like I haven't. That's maybe the best thing to do (if I add in the sleep, then glitch will never test things like attempting to reboot a unit as you're removing it, which is the sort of edge case that we want to test.) [22:21] petevg: Fair enough. As long as it doesn't get in to an unstable state, I'm happy. Though I do think that at some point we're going to have *some* smarts to the plan generation. Having a plan with a bunch of steps that are essentially no-ops seems counter-productive [22:21] But one or two, which would be the most common case, should be fine for now, as long as it doesn't go unstable because of it [22:23] cory_fu: maybe we do something like make it less likely that glitch will act on a single unit more than twice. (Just thinking aloud.) [23:03] cory_fu, bcsaller: PR to help fix some of cory_fu's headaches: https://github.com/juju-solutions/matrix/pull/42 [23:04] cory_fu, bcsaller: the weird thing is that I distinctly remember adding something like this earlier. Maybe I backed off of it because I didn't like the generic catch. I think that it's something we actually want to do here, though. [23:05] petevg: I still don't like the generic catch. What's wrong with catching JujuAPIError? [23:08] cory_fu: I believe the error that we're seeing for the reboot is not a JujuAPIError. (Running against to double check.) [23:09] cory_fu: I mean AttributeError. Regardless, it's not a neat JujuAPIError. [23:10] petevg: Regardless, we should definitely be specific about which exceptions we're catching. Otherwise, you'll catch the control-flow exceptions that are used to shut down the UI [23:10] Among other things [23:11] cory_fu: except Exception doesn't catch control flow exceptions. That's why I used it rather than just "except:" [23:13] cory_fu: "except Exception" only catches stuff that inherits from the Exception class. Unless I missed a change between Python 2 and 3, the control flow commands don't inherit from that class. [23:13] It's the "safe" way of catching a generic exception. [23:13] petevg: Yes, I'm aware. But we might have application-defined control-flow exceptions which do inherit from Exception raised, since we're async. [23:14] petevg: Specifically, bcsaller's branch adds some [23:14] cory_fu: that's bad. That probably isn't the solution, then. [23:15] Maybe I'm being paranoid and asyncio wouldn't cause the exception to come up through that code path. [23:16] petevg: ^ [23:16] cory_fu: I don't know. For now, I'm on deck to make dinner (I'm solo parenting for the next few days), and I'll be out tomorrow. I'm not attached to that code, and won't be offended if anyone rewrites it. [23:16] I'm not familiar enough with async to say for sure [23:16] cory_fu: but I have to sign off for now. [23:16] kk [23:16] petevg: Have a good evening! [23:16] cory_fu: you, too :-) === petevg is now known as petevg_afk [23:17] have a good weekend, too :-) [23:17] nooo petevg_afk don't leave! [23:17] magicaltrout: but I must. If I don't, then we will have burned shrimp tempura for dinner, and the kidlet and the cats may join in revolt. [23:18] argh not burned shrimp! [23:18] goooooo [23:18] be at one with the fish [23:19] * petevg_afk nom nom noms