[01:43] axw: review done [01:45] wallyworld: thanks [02:10] thumper: could you take another look at this please? https://github.com/juju/juju/pull/6492 [02:11] yep [02:17] menn0: just one thing [02:17] thumper: ok thanks [02:18] thumper: good suggestion. I even looked for an existing file to put that func in but missed this one. [02:18] * thumper nods [05:08] Anyone able to tell me what this means? Google has no hits. [05:08] Unable to get the model status from the API: no such request - method ModelManager(2).ModelStatus is not implemented (not implemented). [05:09] Seeing this using 2.0.0 client against a 2.0 rc3 controller [05:09] wondering if it's an API incompatibility between the two [05:31] If I downgrade to the 2.0-rc3 client, I get this instead: "ERROR cannot update account information: unqualified user name "admin" not valid" === frankban|afk is now known as frankban [09:06] blahdeblah: that does indeed appear to be an API incompatibility [09:06] blahdeblah: the error means that the client is trying to call ModelStatus on the ModelManager facade but the API server doesn't have it [09:07] blahdeblah: I've done some digging and it looks like this was changed just before 2.0 final [09:09] blahdeblah: it was done as part of the fix for bug 1611111 [09:09] Bug #1611111: destroy-model is not blocking and should be

[09:09] blahdeblah: your best bet would be to use a 2.0-rc3 client to do what you're trying to do [09:09] blahdeblah: and get that controller upgraded to 2.0 final [09:26] menn0: the 2.0-rc3 client had that unqualified user name problem, so I upgraded the controller to 2.0.0 (thanks wallyworld) [09:26] blahdeblah: ok great [09:26] glad you got it sorted [09:26] sorry for the trouble [09:38] hmph hmph, bug battle === Guest21645 is now known as ahasenack === ahasenack is now known as Guest91977 [13:14] is there a way to tune the timeout of an action? [13:14] i have a long running command that can reasonably take up to 6 hours to complete. I'm noticing the action seems to be timed out after just an hour and nukes the process thread [13:15] lazyPower: probably not [13:15] natefinch this is unfortunate news indeed :/ [13:17] lazyPower: I'll double check the code to see [13:18] natefinch - for context, we built a layer to run the kubernetes e2e suite so we cna just relate itto the cluster and kick off an action to validate it conforms to what both we and google expect from a deployed k8s cluster [13:19] natefinch - the full gambit of tests can take nearly 24h in some cases, in our use-case the test runs take a few hours. So any way we configure this we're headed for a tire fire it sounds like [13:28] lazyPower: try using a numeric param called timeout and set it to the correct timeout in nanoseconds (why the hell it's nanoseconds, I don't know). I think that might work. It looks like the timeout for juju run is specified that way, and it might work for actions, which use a lot of the same code [13:28] ok [13:28] i'll give that a go and let you know if it yields diferent results in ~ 40 minutes [13:29] seems like the timeout is closer to 30 minutes than my original estimated 1 hr [13:29] lazyPower: worth trying a very short timeout on a long action first, to see if it does anything [13:29] https://bugs.launchpad.net/juju/+bug/1637191 -- i filed this to track [13:29] Bug #1637191: [Feature Req] Make action timeout values tuneable via model-config [13:29] lazyPower: like, try to get it to timeout after 30 seconds.... easier to test that it works that way, than try for a 40 minute run ;) [13:29] hokay ;) [13:31] lazyPower: try a --timeout flag to the command? [13:31] https://github.com/juju/juju/blob/6cf1bc9d917a4c56d0034fd6e0d6f394d6eddb6e/cmd/juju/commands/run_test.go#L128 has me wondering [13:31] lazyPower: but I don't see where there's a hard coded timeout in juju for this in looking [13:32] i added the timeout param to the action, building and upgrading charm [13:32] oh heh, natefinch got you the same info it looks like [13:33] :D I'm in good hands [13:34] natefinch: chat? [13:35] That doesn't appear to have changed the actual timeout. http://paste.ubuntu.com/23388262/ -- is what i have in my actions.yaml [13:35] rick_h_: yep. [13:36] i would have expected this to terminate context nearly immediately === frankban is now known as frankban|afk [13:38] lazyPower: can you file a bug for the timeout exposure on actions please? [13:38] rick_h_ i filed this: https://bugs.launchpad.net/juju/+bug/1637191 [13:38] Bug #1637191: [Feature Req] Make action timeout values tuneable via model-config [13:39] are we looking for a different bug context on having specific actions take timeout values instead of blanket config in model-config? [13:50] rick_h_: hey i just read your email, i'm double-checking [13:51] katco: k, I was looking at the github list of commits for each branch and got freaked [13:51] katco: balloons says I'm ok and to calm down :) [13:51] rick_h_: i pulled from commit 5890aa9, not HEAD... maybe that's why you're seeing a difference? [13:52] ohh katco, you are around early. I reverted wallyworld's changes in your PR that you landed. [13:52] katco: sorry, been otp and not looked at the 'why' yet. [13:52] katco, is there a reason you landed them without the bot? [13:52] balloons: you said the bot didn't watch the 2.0 branch? [13:53] katco, I hope I didn't lead you astray by saying to manually do the merge to create the branch [13:53] katco, $$merge$$ still works [13:54] balloons: oh... ok. why didn't we use that for merging the first set of commits? [13:54] balloons: sorry about that. i thought the bot didn't work on that branch [13:54] katco, I didn't want to hold out waiting for a run as that exact code had already been through a full CI run [13:55] balloons: oh i see. ok, sorry for the misunderstanding [13:55] and my expectation moving forward is we would just create the branch; not through a PR as it's already "landed" code we would be branching [13:55] balloons: well the branch was already there, i just merged code into it. moving forward all of these changes would have been done directly off the 2.0 branch [13:56] katco, no worries. I would rather have already sorted this out but we're doing a release now with this mantra before finalizing the changes Alexis brought up [13:56] katco, true. I was thinking there wasn't a brancg [13:57] balloons: we'll get it right eventually. so are wallyworld and axw's cherried commits in there? do i need to re-propose? [13:58] katco, I just reverted them. They broke the build and maybe could have been fixed and merged, but you didn't get to see that before merging last night :-( [13:59] balloons: doh... ok. so i'll repropose? or is it too late now? [13:59] I don't think you need to re-propose now as they will come naturally in the next release. [13:59] balloons: ok. sorry wallyworld, axw [14:00] I'm sorry if I led you astray. But please do use the bot to land code, and test it yourself as well before proposing :-) [14:01] natefinch: ping for standup === petevg_afk is now known as petevg [14:12] balloons: hey i think rick_h_ may have been right [14:13] balloons: the commit alexisb_ suggested was for a branch prior to the commit to merge into develop [14:13] balloons: so i think i only brought in the commits from that work, not everything up to when that work was merged [14:14] balloons: i.e. 5890aa9 not bebd627 [14:14] katco, ahh. I verfied that what you brought in and the commit mentioned where exactly the same [14:14] so if the commit you wanted wasn't the right commit, well ;-) [14:14] balloons: yep, kind of how i was operating [14:14] balloons: yep lol [14:14] balloons: so what can we do here? [14:15] katco, well it sounds like rick_h_ is going to ask for 2.0.1 to have everything in it [14:15] ? [14:15] balloons: yeah already has [14:15] you may as well re-do the cherrypick then [14:15] balloons: ok, i'm going to --force the correct merge in if that's ok? [14:16] so you are going to merge bebd627? [14:16] balloons: yes, and then cherry the two commits? [14:17] balloons: and overwrite history [14:17] ok [14:17] balloons: with --force [14:17] fun fact, Air Conditioning installers do not do the electrical wiring to the device.... [14:17] katco, can you do it so we get a pre-check run [14:18] so we know the basics are sound -- otherwise we'll end up in the same place, since this isn't a straight pull anymore [14:20] balloons: sorry, can you restate? what do you mean "do it so we get a pre-check run"? how do i do that? [14:23] katco, sorry. I was asking if you were going to propose it as a PR or not [14:23] balloons: oh, yes i am [14:23] katco, ok, fire away [14:23] :-) [14:23] balloons: do you know what sha i should begin from? d25720a? === frankban|afk is now known as frankban [14:24] katco, I don't know offhand. Let me see [14:27] katco, to be far you could just grab the additional commits since the branch is up to 5890aa9 [14:27] *fair [14:28] balloons: i'd rather not have the messy history, plus we now have changes on top of that. not sure what git will do [14:28] katco, then nuke the branch and redo it I think [14:29] katco, use the 2.0.0 tag and re-make from that, then propose what you wish [14:29] how's that? [14:29] it's at 6cf1bc9 [14:30] balloons: sounds good to me [14:35] balloons: do you prefer i merge the pre-checked commits first and then $$merge$$ the cherries, or do you want them together? [14:38] katco, I don't think I care. I don't think merging them all at once will cause issues in the future with merging to the branch. That would probably be my only concern [14:38] all at once will make it easier from a test perspective [14:39] so I guess that's my vote ;-) [14:39] balloons: ok, so all at once and then use $$merge$$ [14:39] balloons: sounds good to me [14:49] balloons: rick_h_: sanity check: https://github.com/juju/juju/pull/6510 [14:49] i am a little confused because i'm seeing commits from nov. 2015, but i'm assuming this is from some kind of long-lived branch that landed [14:50] katco, are they the CMR commits? [14:50] alexisb_: trying to figure out what they are [14:50] alexisb_: yeah, looks like that's it [14:52] katco: cool that looks more like two weeks work from the team ty [14:52] rick_h_: yep, sorry for the trouble [14:53] katco: all good, just glad we caught it before release ty for working on it [14:53] rick_h_: yeah thanks for checking for me [15:29] katco: I'm getting back to the changelog. Where did you end up with the commit line? [15:30] rick_h_: what do you mean commit line? [15:30] katco: what commit was the end of the line? [15:30] katco: if I were to look at develop and judge where to stop for the changelog notes [15:30] rick_h_: oh, one sec [15:30] rick_h_: bebd627 [15:30] katco: you've not pushed to 2.0 on upstream yet right? [15:30] katco: cool ty [15:31] rick_h_: no, i need to $$merge$$ looks like prechecks were successful [15:31] katco: cool thanks [15:31] rick_h_: https://github.com/juju/juju/pull/6510 if you're curious [15:32] cool, that might be easier to go through [15:55] balloons: rick_h_: looks like it's all merged [15:56] katco: <3 === frankban is now known as frankban|afk [17:15] Bug #1637267 opened: Juju fails to restore state-server on xenial

[17:52] rick_h_, alexisb I'm bumping develop to 2.1-beta1. We comfortable with that as the "next" version [17:52] balloons, I am [17:53] balloons: yes, wfm [17:55] natefinch, can you review? https://github.com/juju/juju/pull/6511 [18:01] natefinch, this one too :-) https://github.com/juju/juju/pull/6512 [18:03] yep [18:04] LGTM [18:42] rick_h_: too much? Just right? http://i.imgur.com/FAB5rSS.png [18:43] natefinch: yea, would drop the X [18:43] aww... I like the X. damn ascii purists ;) [18:43] :) [18:45] seriously, I think the X is nice because it gives a visual indication that doesn't rely on color support for your terminal or your eyes. But I know that's kind of pushing the envelope in the linux world [18:46] natefinch: right, but it's not something in our "visual language" to date [18:46] natefinch: so I'm hesitate to start adding new ways to indicate "error" [18:46] natefinch: without thinking/doing it thruogh the whole codebase in a clear way [18:58] well, we only have a couple interactive commands... but that's ok, it's easy enough to add and remove as needed. [20:08] redir: ping, I hear you have ipv6 on your network? [20:08] redir: e.g. you could in theory ping a public ipv6 address? [20:09] rick_h_: whois me [20:09] whois redir [20:10] Prolly says I'm connected from an ip6 addresws [20:10] redir: can you ping6 2001:4800:7818:104:be76:4eff:fe04:78a6 [20:11] yes [20:11] redir: k, ty [20:12] redir: can y6ou also try 2001:4800:7818:104:be76:4eff:fe04:c448 please? [20:12] affirmative [20:13] interesting, every node in rackspace gets a public ipv4 and ipv6 address [20:13] ty redir [20:14] np [20:14] rick_h_: I've had ip6 for ~3years [20:14] in NY and here [20:15] redir: cool [20:15] redir: yea, I think I can get my comcast setup to do dual but not bothered yet. Might be time to investigate that I guess. [20:16] for a while it broke android phones. They stopped reaching the net if they received an ip6 DNS server [20:16] heh, oops [20:16] I didn't do anything. [20:16] just got it one day in NY [20:16] and it is on here' [20:16] oic [20:17] obviously ip4 still works [20:18] and I've been on the same ip4 address for a year, but my ip6 address changes regularly. [20:18] go figure [20:18] heh, that's crazy. You'd think you'd just get one [20:18] it's probably a feature? [20:19] like he does actually have a big range, but day to day moves around so people can't find him :) [20:26] rick_h_: I have a proposed fix for ssh from windows, am going to mail juju-dev with summary [20:26] mgz: ty [20:27] food first :P [20:37] apparently there's some ipv6 privacy stuff that let's you have multiple addresses, and they change regularly. [20:38] But I've disabled that on my host, because it causes chrom[e|ium] to show network changed errors when it happens [20:41] wallyworld, if you are said, you should be happy to hear your cherrypicks came in the end [20:42] balloons: <3 [20:51] balloons: they were actually part of the correct merge commit all along [20:51] balloons: no picking of cherries required :D [20:51] lol. nice [21:00] do we already have some simplestreams parsing code somewhere? [21:01] utils or anywhere? [21:11] natefinch: or katco can you help redir please? ^ [21:12] I see somethign in environs/ [21:12] redir: i saw your question, but i don't know :( [21:12] environs/imagedata [21:12] redir: i would be surprised if we didn't [21:12] redir: wallyworld would probably know [21:12] comparing to uvtool now [21:27] do we actually sync/mirror images in juju anywhere? [21:29] redir: what are you up to? [21:29] redir: I wonder if the context of what you're up to will help with a better answer [21:29] removing dependency on uvtool [21:30] which mirrors cloud server images for creating kvm instances from [21:30] loosely is what I am looking at right now. [21:30] if we already have code to mirror/sync images I'd use it [21:31] lxd does something like that [21:31] * redir goes to look for lxd codee [21:32] layers I imaging [21:32] redir: lxd doesn't do any caching [21:32] whoops [21:32] redir: at this time, it's a feature we want to add [21:39] tx rick_h_ alexisb [21:45] perrito666, ping [21:56] alexisb: pong [21:57] heya perrito666, seems the vsphere updates are causing ci to fail [21:57] can you please take a look [21:57] sure I can [21:57] http://reports.vapour.ws/releases/4535/job/vsphere-deploy-trusty-amd64/attempt/245 [21:59] alexisb: from the rather unclear output of that test it would seem that it is just taking too long [22:00] rick_h_, alexisb, are we confident that we'll land something else for 2.0.1? [22:00] sinzui: abentley mgz care to give me a hint? [22:00] I ask only because https://github.com/juju/juju/pull/6512 landed, and will need reverted. I tried to be as quick as possible [22:01] but it would mean a little rework in this case if so :-) [22:01] balloons, I think perrito666 needs to investigate [22:01] balloons, can you help with his inquiry [22:02] ok, just please note that the version has to be revved back to 2.0.1 if you land something. ok perrito666? [22:02] perrito666: that looks like the open connection bug. Juju has exhaused the vsphere resources are repeated tests. we kas larry to restart vshere to relaim the 1000s of connections [22:02] balloons: ack [22:03] sinzui: can you confirm that using the vsphere dashboard thing? [22:03] perrito666: no, because I cannot see it [22:03] sinzui: I have seen this work without the failure [22:04] sinzui, we need larry? [22:04] we need something with access to the pannel [22:05] perrito666: indeed it does work until resoruce exhaustion. it happens about every 10 days [22:06] sinzui: let me rephrase, I have seen juju work without taking resources [22:06] sinzui, we're trying to decide if this is a blocker [22:07] sounds like cursed ;-( [22:09] perrito666, could we run the test steps manually and see if they pass [22:09] alexisb: I guess we could, that is a question for someone in CI though that has both the env setup and knowledge of the tests [22:10] alexisb: sinzui has been gracious enough to do these things for me :) [22:11] perrito666, sinzui ok, this is currently a blocker for a 2.0.1 release so we will want to make sure we are not blocking needlessly or if there is an issue we need to investigate as a top priority === akhavr1 is now known as akhavr [22:16] perrito666: Sorry, I'm EOD, but it sounds like you and Curtis have already figured out more than I knew. [22:16] abentley: sorry I included you in the initial talk to keep all of QA in the loop, apologies [22:17] perrito666: np [22:17] balloons: still about? what did you revert? I can't see any revert commits on 2.0 [22:20] alexisb: do you know? ^^ [22:34] axw, branch was remade [22:34] axw, your stuff is in there [22:34] balloons: ok, ta [22:34] good morning :-) [22:35] good evening :) [23:17] perrito666, menn0, ping [23:17] redir, ping [23:17] tx