[01:33] thumper: waigini: can you give me a review on https://github.com/juju/juju/pull/1516 [01:33] ta [01:37] anastasiamac: I don't think I told you before, I'm on leave today [01:37] axw_: yes i saw :D have fun! [01:37] thanks, cya tomorrow [01:38] axw_: sure thing! === rvba` is now known as rvba [06:38] morning folks :) === mup_ is now known as mup [08:39] axw_, ping === rogpeppe1 is now known as rogpeppe === mthaddon` is now known as mthaddon [09:47] fwereade: axw is off today :D [09:48] anastasiamac, thanks [09:48] and axw_, don't worry about it, resolved :) [10:23] voidspace, o/ === ahasenac` is now known as ahasenack [11:13] ericsnow: you there? [11:59] hey dimitern i can confirm thta the version of windows juju is bugged as mac with 1.21 works fine for deployment manually [12:00] dimitern: im managed just fine to bootstrap manually on mac [12:00] dimitern: ah, you're back [12:00] dimitern: I got your messages earlier, thanks [12:00] eagles0513875, hmm that sounds like a bug, please report it [12:00] voidspace, ah, great [12:00] dimitern: so there *is* some code in proxyupdateworker that is supposed to change the environment variables [12:00] dimitern: any chance at getting a 1.21 windows build? [12:01] dimitern: I'm changing it to be called unconditionally (it currently tries to only run on first call) and see if that helps [12:01] dimitern: and I'm updating the bug as I go... [12:01] mgz, ping [12:01] dimitern: hey! [12:01] voidspace, sgtm, thank you! [12:02] mgz, any idea about when we'll have a windows release for 1.21 to fix the issues eagles0513875 is having? [12:03] mgz: basically on windows using manual provider it was complaining about an ssh key and user and in the environments.yaml there was no ssh keys or user variables to provide credentials for [12:04] wat's the bug #? [12:04] mgz: havent filed one yet [12:04] will do it once im home from work [12:04] cuz i then tried on mac and 1.21 doesnt seem to have this issue [12:04] is that because it's a mac or because it's 1.21 though? :) [12:04] dunno tbh [12:04] ssh is much simpler on unix-like environs [12:05] mgz: agreed, but there are also windows solutions available but im wondering if its an issue with 1.20 on windows or if there is something in 1.21 which fixes said issue. [12:06] I can link you a 1.21.1 windows binary [12:06] want to do a bit more testing before i file a bug to ensure that its actually the version of juju or not [12:06] eagles0513875: https://launchpad.net/juju-core/+milestone/1.21.1 [12:08] mgz: there is no mention of windows [12:08] also how do i view juju status on a machine which is already bootstrapped from another laptop do i need to rebootstrap it or there is another way [12:08] nm i know whats happening [12:08] that page, under downloads, has a juju-setup-1.21.1.exe [12:09] use that [12:09] oh ok [12:09] mgz: how can i run juju status on a machine which is already bootstrapped [12:10] eagles0513875: you need the .jenv file from when you did the bootstrap [12:11] otherwise your client on the other machine doesn't know the keys to talk to the juju state server [12:11] damn ok. [12:11] so, you need to copy the ~/.juju/environments/{ENVNAME}.jenv from the laptop [12:12] that would be useful to have it check if the system has already been bootstrapped [12:12] if you want to access that environ from another machine [12:12] wil have to do that later. [12:12] mgz: if the system is already bootstrapped cant it recreate it when for example one tries to run juju status it sees if the system has been bootstrapped and creates teh jenv file on the other system which one tries to run juju on? [12:15] mgz: how can i start contributing code wise? [12:15] eagles0513875: that would not be secure - you need the credentials, otherwise anyone with the ip address of your machine could take over your juju environment [12:15] the manual provider is a bit special - with that you can probably just ssh in, clean up the juju bits, then rebootstrap [12:15] mgz: agreed i provided the ip of the remote machine but manually there are no options for anything else besides user no ssh key etc [12:15] humm ok [12:16] on contributing, start by reading some of the docs in tree - github.com/juju/juju - get it building locally, and then maybe look for an easy bug or nit you want to fix [12:18] ok probably should do the golang tutorial too no mgz? [12:18] yeah, if you've not done any go yet, that's a good way to get started on that [12:19] mgz: is golang linux only or can it be run on any platform? [12:20] it's reasonably cross platform [12:20] kool :) [12:24] fwereade: good time to learn golang can use the linux instance I have on ec2 [12:31] morning [12:34] perrito666: morning [12:34] * perrito666 has a food hangover [13:41] hi tvansteenburgh1 [13:45] jcastro: we need to get a bundle promulgated. who in eco can do that and is most available? === tvansteenburgh1 is now known as tvansteenburgh [13:45] bac: hi [13:47] tvansteenburgh: can you do promulgation of bundles? [13:48] bac: technically yes, although i never have. where's the bundle? [13:49] tvansteenburgh: https://code.launchpad.net/~openstack-charmers/charms/bundles/openstack/bundle [13:54] bac, we're at a sprint, but if you can find mbruzek, dpb, or tvansteenburgh they could help you out. [13:54] bac, jose can help as well [13:54] jcastro: thanks [14:13] Is it possible to execute juju-run from within a hook context? [14:16] aisrael: yes, you can specifiy --relation (r) and --remote-unit .. you can also use --force-remote-unit if you have a scenario where a remote unit might have gone away [14:17] aisrael: the help output from your juju-run should give you the details as well [14:19] wwitzel3: Thanks, I'll give that a try! [14:19] dimitern, I an struggling to understand bug 1416928. Is this issue just about apiaddress ? is this a regression that needs to be fixed in 1.21.2? [14:19] Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents

[14:20] sinzui, I'll have a look [14:28] aisrael: cool, let me know how it works out, I implemented it and it hasn't had much use yet [14:33] wwitzel3: -r and --remote-unit are not in trunk for cmd [14:33] wwitzel3: at least not in help output [14:33] marcoceppi: for juju-run? or juju run? [14:33] juju run [14:34] marcoceppi: right, not there yet [14:34] marcoceppi: fwereade wasn't sure we wanted to expose those specifics via juju run, so for now, we expose them to charms, but only via juju-run [14:36] wwitzel3: The error I keep coming around to is error: juju-run cannot be called from within a hook, have context "collectd/3-upgrade-charm-1414101190250335867" [14:38] aisrael: interesting, ok, so JUJU_CONTEXT_ID might be set? [14:40] aisrael: the way the command works right now is you would run it outside of a context, passing in relation / remote-unit and then it would step in to that context [14:40] wwitzel3: Yes, it is. I don't know if I've ever seen it not set === mwenning is now known as mwenning-wfh [15:00] ericsnow: ping === kwmonroe_ is now known as kwmonroe [15:11] aznashwan: OTP [15:33] dimitern, natefinch : I think I will release https://launchpad.net/juju-core/+milestone/1.22-beta2 today. The licensing issues don't block our beta, just the final releases. [15:34] sinzui, great! [15:35] sinzui, re bug [15:35] sinzui, sorry; re bug 1416928 [15:35] Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents

[15:36] aznashwan: what's up? [15:37] sinzui, aiui it's about a very specific scenario where a manually provisioned node with 2 nics can initially connect to the apiserver, but after reboot the IP addresses are reassigned(?) or something, so it can't reconnect to the apiserver [15:37] pretty weird setup, but needs more investigating [15:38] dimitern, fab. that sounds familiar, but I couldn't find a bug that described the issue as the reporter [15:38] * sinzui looks for other bug again [15:41] dimitern, I see bug 1414710 as related or the master issue [15:41] Bug #1414710: Manually provisioned machines with multiple networks cannot connect to API server after reboot

[15:54] ericsnow: hey, sorry, did I miss you? D: === tasdomas` is now known as tasdomas [16:01] aznashwan: I'm here [16:04] ericsnow: hey [16:04] ericsnow: so, i've just re-vamped the PR [16:05] ericsnow: still waiting for an OK to get to the tests [16:05] ericsnow: and also, I still hadn't sadly figured out a way to get the enabled/disabled status of a service through the dbus api [16:06] ericsnow: if you really want to avoid exec calls (which is a good choice considering how wonky systemctl ststus seems to be), I suggest we simply look for the symlink in default.target [16:07] aznashwan: thanks for the update [16:07] ericsnow: i'll be awaiting your blessing and get to the tests later today then :D === seelaman` is now known as seelaman [16:30] natefinch, di you have time to review http://reviews.vapour.ws/r/842/ === kadams54 is now known as kadams54-away [16:59] sinzui: ship it [17:00] yay, 5pm and *finally* I have juju bootstrapping [17:00] hopefully with diagnostic code in place... [17:10] oh, and the way we're creating apt-proxy settings (from http-proxy) is incorrect. [17:10] or at least, it *can be* incorrect [17:11] dimitern: hey, hi [17:11] dimitern: so you got enough for a demo working? awesome. [17:11] voidspace, hey, yeah! [17:12] dimitern: I just sent you an email a minute ago [17:12] dimitern: I've made progress [17:12] voidspace, most of the things already done worked, just a few tweaks needed [17:12] voidspace, yep, thanks - just got it [17:12] dimitern: slightly hampered along the way by the fact that we can set the apt-proxy settings incorrectly [17:12] dimitern: that's great news [17:13] voidspace, it certainly is! :) I was just talking to ian how his storage update seems to me a lot cooler than my networking status update, but I'll work on this this evening, to make it as great :) [17:14] dimitern: no rest for the wicked [17:16] dimitern: anyway, good stuff. I'm really pleased. I hope the demo goes well. [17:17] voidspace, me too :) [17:17] voidspace, btw just confirmed - with ian about unconditionally setting the proxy env vars - let's do it [17:17] voidspace, I'll reply to your mail as well [17:18] dimitern: cool [17:18] voidspace, can you just clarify a bit the part about the charm revision updater? [17:18] dimitern: I'm watching debug-log. After the deploy I see: [17:18] machine-0: 2015-02-02 17:02:52 ERROR juju.worker.charmrevisionworker revisionupdater.go:75 cannot process charms: finding charm revision info: Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info: dial tcp 91.189.95.66:443: connection timed out [17:19] dimitern: so the charm deploy worked, "juju status" shows the charm "started" [17:19] voidspace, right, that's exactly the same problem [17:19] right [17:19] but in a different place [17:19] voidspace, so the revision updater works "retroactively" i.e. downloads and caches revisions for already deployed charms [17:19] dimitern: I'm looking into it [17:20] voidspace, you rock! :) [17:20] heh, thanks [17:21] dimitern: so if I change the place we set the environment variables no tests fail (at least not for proxyupdater...) [17:22] voidspace, great, it will be even better if you manage to add a test that confirms the proxy settings are set in the env after they change [17:22] dimitern: I'll look at it [17:22] dimitern: I'll see if I can find this other bug *first* though [17:23] voidspace, cheers, sounds good [17:29] voidspace, what was the other bug you've discovered around setting apt-proxy settings btw? [17:30] dimitern: so http-proxy or https-proxy can be in the form 192.168.178.103:3128 [17:30] for example [17:30] dimitern: however, a valid apt-proxy setting *must* be in the form [17:30] http://192.168.178.103:3128/ [17:30] dimitern: and we use http-proxy as a fallback for apt-proxy, so if you specify http-proxy in a way that doesn't work with apt then it just gets set "as is" [17:31] dimitern: and redeploying to a machine that you've already deployed to will see the existing config file for apt-proxy and not write a new one [17:31] dimitern: even if you've changed the settings [17:31] dimitern: so apt-proxy didn't work - once I'd worked out why changing the http-proxy to the correct format didn't help as the new values weren't written out [17:31] blowing away the juju apt-proxy conf file caused it to be rewritten (correctly) on bootstrap though [17:31] but that cost me some time [17:37] and as far as I can tell both the unit agent and the machine agent are starting a proxyupdaterworker and (now) setting the environment variables [17:37] so either the charmrevisionworker runs before this happens (possible) or there's some other interaction [17:37] I'll put the proxyupdater first in the list to start [17:44] dimitern: that appears to work (starting the proxyupdater before other workers) [17:44] voidspace, sorry, was afk for a bit - catching up on what you've said so far [17:45] np [17:45] dimitern: I think I have a fix, not very easily testable though [17:46] voidspace, sounds like you're already onto the correct path [17:46] dimitern: basically proxy settings need to be in place before we start workers that need access to the internet... [17:46] voidspace, please, file a bug about the apt-proxy not using the expected format though [17:46] dimitern: moving the proxyupdater to be the first worker will probably "mostly" fix the problem [17:46] dimitern: yep [17:47] voidspace, that's sounds sensible, yeah [18:38] axw_: let me know when you get online, I have some questions about ssh keys for juju === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [19:19] right, g'night all [19:20] EOD === kadams54 is now known as kadams54-away [19:50] thumper: hey, when you get a chance, I'd like to talk about that joyent ssh key bug [19:50] hi natefinch [19:51] natefinch: sprinting this week, but I'm here early [19:51] whazzup? [19:52] thumper: not sure what the right fix is... do we default to something like $JUJU_HOME/ssh/joyent_id and generate that if it doesn't exist? Or default to generating a key that gets directly embedded in the config file? [19:57] hmm... [19:58] I think the first [19:58] if I have multiple joyent environments, I think it is fine to have just one key [19:59] Yeah that was going to be my next question. [20:00] thumper: any idea what happens if we were using the user's id_rsa key and then this code is deployed and we switch to a generated key? Would it break their environment? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [21:29] perrito666, natefinch, thumper juju-ci3 is in upgrade hell to 1.21.1 state server upgraded in a few minutes, after an hour it fell over. I restarted the agents and can see it, but all the other machines are down. They are trying to contact 10.0.3.1...which is not where the state server is [21:30] perrito666, natefinch, thumper, I think I can fix the apiaddress by editing each agent.conf. Is there something more graceful than editing 36 agents? [21:31] Can I trigger juju to reset the apiaddress [21:32] sinzui: afaik no [21:33] perrito666, sinzui: juju run maybe? [21:33] natefinch: will that work with the agents down? [21:34] natefinch, indeed I was thinking of just a trunk to sed the apiaddress [21:35] as long as the addresses of the remote machines haven't changed [21:35] perrito666: I think if you use --all it just basically does an ssh [21:35] juju run asks the state server for the remote address [21:36] and then just ssh'es to it [21:36] unless you have the "ssh through api server" flag set [21:36] which I think is the default on azure [21:36] which is where I think your machines are... [21:36] however, that should still work [21:37] sinzui: would love to grab the logs from the failed upgrades [21:38] * perrito666 hears a few shots in the distance and wonders if he should perhaps postpone hist afternoon walk [21:38] perrito666: seems wise [21:39] thumper, I have plenty of those. I am just trying to get the juju-reports agent back by manual intervention. I can then collect logs and explore automated fixes [21:39] hopefully we can figure out what went wrong... that's a pretty nasty bug [21:42] perrito666: literal shots? what's going on over there? [21:42] jw4: police exchanging opinions with certain fellows [21:42] lol [21:43] perrito666: heh [21:45] thumper, natefinch : I confirmed I can edit the agent files to restore contact. I will start gathering logs [21:45] awesome [21:46] cool [21:51] k going for a walk, if you dont see me here tomorrow google for local newspapers :p [21:51] perrito666: :-( === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1417178 [22:51] thumper, I reported https://bugs.launchpad.net/juju-core/+bug/1417308 [22:51] Bug #1417308: Juju-ci3 cannot upgrade to 1.21.1

[23:22] I am alive [23:31] perrito666: yay! [23:31] perrito666: any extra holes?