[00:01] redir: love your abbreviations [00:03] tyvm, perrito666 [00:03] sorry i am a lazy typist [00:03] lol [00:03] does Maas knows how to upgrade itself? [00:49] Bug # changed: 1312290, 1321212, 1339866, 1353242, 1357760, 1381340 [01:36] axw: updated pr from yesterday. It is a bit different so ptal https://github.com/juju/juju/pull/6297 [01:36] redir: ok, looking [01:41] redir: reviewed [01:45] axw: tx === natefinch-afk is now known as natefinch [02:02] ah ha [02:02] think I have found why cert updater tests fail intermittently [02:02] well, getting to the bottom of it anyway [02:16] ugh [02:16] menn0: got a minute? [02:37] thumper: now I do [02:38] quick HO? [02:38] yep [03:05] axw: would you mind taking another look at this one please: https://github.com/juju/juju/pull/6302 [03:05] axw: i've added an upgrade step now [03:05] menn0: sure, looking [03:09] menn0: LGTM with QA, which I see you're doing now [03:10] axw: cheers [03:10] pop quiz... what's wrong with this in the bootstrap output? [03:10] Launching controller instance(s) on dev... [03:10] - juju-0facb9-0 00% [03:10] menn0: https://github.com/juju/juju/pull/6303 [03:11] looking === rmcall_ is now known as rmcall [03:42] menn0: are you? [03:43] thumper: sorry, got distracted [03:46] thumper: done [03:52] menn0: quick hangout do discuss something? [03:53] thumper: ok [04:19] Bug #1626304 changed: Unit disk fills with inprogress-n files [04:25] Bug #1626304 opened: Unit disk fills with inprogress-n files [04:31] Bug #1626304 changed: Unit disk fills with inprogress-n files [05:23] hi, we have private openstack cloud and we want to use different subnetwork for deployed software. is it possible to do it with juju 2.0 ? [05:26] thumper: here's the formatting fix: https://github.com/juju/juju/pull/6304 [05:27] * thumper looks [05:28] lgtm or at least good enough [05:47] gennadiy: not yet I don't believe [05:48] gennadiy: we will have spaces and subnets for openstack soonish, but I'm not sure on the timeline [05:48] night all === frankban|afk is now known as frankban [08:16] Hi, lads. I need help in creating a password hash for the unit/machine agents that is stored in the mongodb database. On a fairly complex customer environment I lost /var/lib/juju directory. I was able to recreate everything, and jujud-s start without an issue, I just had to use passwords/hashes from some other unit - but now I ended up with same passwords for two units. [08:16] Is there a simple way generate both the password and the hash? [08:16] This is juju 1 (1.20, we are prepping the customer for upgrade to 1.25) [08:16] Erm, hi to ladies too! [08:45] voidspace: ping - can we sync regarding the MAAS bug we saw yesterday [08:47] frobware: we can [08:47] voidspace: standup HO [08:47] frobware: the ipv6 bug I'm on has turned critical as well :-/ [08:48] voidspace: in my experience that category is now quite low. :) [08:48] frobware: I'm in the HO [08:48] frobware: category? [08:49] voidspace: critical because the bug that u said is the same was critical ;) [09:00] mgz: ping [09:02] voidspace: the logs do have TRACE info [09:02] frobware: ah yes, odd [09:02] frobware: maybe they hadn't loaded that far when I searched! [09:02] frobware: I see them now, sorry [09:17] anyone fancy a review of a little addition to juju/testing? (factored out from somewhere else we've been using it for while): https://github.com/juju/testing/pull/111 === rogpeppe1 is now known as rogpeppe [09:18] axw: ^ [09:22] rogpeppe: I was a bit slow, but LGTM anyway [09:23] axw: tyvm - i always like to have someone from core sign off on juju/* PRs [10:05] Am I in the wrong place for the core team meeting? [10:08] juju core team meeting? Is it not on today? [10:08] frobware, voidspace ^ [10:09] babbageclunk: we're in a hangout on a critical issue - so we can't make it [10:09] babbageclunk: if there's no-one else there, then it probably aint happening :-( [10:10] Oh yeah, I thought you guys might still be working on that. Weird that no-one is there. === mup_ is now known as mup [11:48] voidspace: can you join the HO again? [12:04] voidspace: scrap that - heading out for a bit [12:13] kk [12:39] frobware: so it's the provisionerTask that should be creating the machines and that's using a straightforward machines watcher [12:39] frobware: interestingly the "process machines with transient errors" call is from the provisioner task loop [12:40] frobware: and only happens when there is something on the retryChanges notify channel [12:40] frobware: I can't see in the logs a *failed* attempt that would cause that though [12:40] frobware: I'm still digging through the code and the logs [12:40] taking a break [13:28] urgh [13:29] jamespage: that good eh? [13:29] rick_h_, soooo [13:29] * rick_h_ runs away [13:29] relations at the bottom of status [13:29] mmm [13:30] jamespage: yes, what's up? [13:30] the side effect of that change is that if I type juju status, I just see the list of relations [13:30] jamespage, did we break you somehow? [13:30] for an openstack env with lots of them [13:30] mgz, just feels odd [13:31] jamespage: yea, the thing was that folks doing status tend to either watch (so most improtant/changing stuff up top) or less. [13:31] jamespage: and having the things that have status/notes/etc together seemed appropriate [13:31] http://paste.ubuntu.com/23215829/ [13:31] maybe dropping them from the tabular view althogther might be better [13:32] jamespage: so that was a thought, but because it's directly part of the "topology" held that back [13:32] e.g. two status's are very different with the relations set for something vs not set [13:32] side effect is if not using watch, then a juju status cli type results in most of the useful information about 3" above the top of my monitor [13:32] so status seems "all good" as far as machines deployed/applications running but still not be useful [13:32] jamespage: right, it's a trade off one way vs the other way [13:33] We emailed the juju list, asked for feedback, and wanted to try this out. [13:33] rick_h_, yeah - sorry I did read that, but had my head in other stuff at the time [13:33] jamespage: understand, this is fine. Sometimes you don't know until you try it [13:34] rick_h_, btw that pastebin has the version stuff we just added in [13:35] jamespage: <3 ty [13:35] rick_h_, one comment is that its a bit lossy [13:35] rick_h_, as its possible to get different versions on different units during transitions [13:36] and if someone does something wonky by hand [13:36] jamespage: yea, that was something we debated about that feature [13:37] jamespage: we wanted to treat it more like resources where you get what it "should" be (by what most folks think it is) and a way to ask the units [13:37] jamespage: but that got shot down [13:50] maybe a flag for --relations or --no-releations depending on the default [13:51] maybe same for machines... machine info is fairly boring most of the time [13:52] also, we obviously need to do something about ports [13:53] wow, the relation data is just static? There's no state there at all? I agree, that shouldn't be in status at all. [13:58] You really want an ascii-art diagram of the relations. [13:58] (only half joking) [14:00] natefinch: katco macgreagoir voidspace ping for standup [14:00] mgz: ^ [14:00] ta [14:01] omw [14:26] babbageclunk, you around still? [14:35] Bug #1544796 opened: Backup restore fails: upgrade in progress <2.0-count>

[14:35] Bug #1626576 opened: credential v. credentials is confusing [14:52] babbageclunk: could you tell me what do you mean by provider/maas/maas2instance.go L68 ? [14:53] perrito666: Sure - looking at it now [14:53] tx [14:53] Bug #1544796 changed: Backup restore fails: upgrade in progress <2.0-count>

[14:59] perrito666: I don't remember writing that at all, but from comparing with the v1 api version it looks like it's right - that code should rerequest the status from the controller. [14:59] babbageclunk: heh, ok [15:00] perrito666: :( hope that's not the source of the problems voidspace and frobware have been chasing. [15:00] babbageclunk: the problem being? [15:02] perrito666: marcoceppi's problem where the controller was taking a long time to deploy machines [15:02] Bug #1544796 opened: Backup restore fails: upgrade in progress <2.0-count>

[15:03] now mup, I find that hard to believe [15:04] babbageclunk: mm, could be, I have a problem like that when the deployment fails in maas [15:05] Bug #1544796 changed: Backup restore fails: upgrade in progress <2.0-count>

[15:23] easy review anyone? https://github.com/juju/juju/pull/6306 [15:23] you are asking if the review is easy? [15:24] no [15:24] I'm asking you to go look at the code and review it :) [15:25] natefinch: i'm tal [15:25] I am not tal, its a hedious templating language but ill take a look anyway [15:26] been wanting to try a GH review :) [15:28] is there still no way to select multiple lines for a comment? [15:29] katco: no, don't think so [15:29] Bug #1544796 opened: Backup restore fails: upgrade in progress <2.0-count>

[15:33] natefinch: review up [15:33] not being able to highlight lines for context is unfortunate. one of my comments appears to be about 4 lines of code when i intended it to be about the entire function [15:34] is there some sort of best practice around that? [15:36] wow that bothers me way more than i thought. it kind of leaves the author guessing which lines are being discussed [15:36] natefinch: juju is using Go 1.6 now, right? [15:37] rogpeppe: yes [15:37] rick_h_: thanks [15:37] rick_h_: just wanted to make double sure [15:40] how do you differentiate between a suggestion and a request in a github review? [15:41] * katco thinks she better go read their tutorial [15:41] katco: if it says please? [15:41] lol [15:42] trivial (but important) review, please: https://github.com/juju/utils/pull/239 [15:44] katco: have they fixed it so you can comment on lines that aren't changed now? [15:44] rogpeppe: you are asking the wrong person [15:44] rogpeppe: i have no idea [15:44] katco: :) [15:44] katco: i'll have to try it [15:44] rogpeppe: looks like no? [15:45] katco: it always annoys me when i want to say "that code you added over there should be here", but "here" wasn't somewhere that was changed [15:45] yeah... wow that is not ideal either [15:46] oh weird, yeah, it's not whether or not it's been changed, just whether or not it's in the window that shows what's changed [15:47] natefinch: but if i expand the file that's changed i can't even comment outside the diff i don't think [15:47] right yeas [15:47] sorry, there's the initial preview with a little extra context, anything in that preview window you can comment on, changed or not. Anything outside that, even when expanded, you can't. [15:52] katco: I made the suggestion in the email thread about marking issues that need to be addressed with :x: which makes a nice big visible red X in the text. It's not perfect, but it seems sufficient. [15:53] natefinch: i agree that would be an easy convention. i am always super hesitant to add conventions to teams bc they introduce a cognitive load, and only so much of that can be maintained. [15:57] katco: I know... I wish that feature existed in the review system, but I don't think it's a huge cognitive load, especially since we should all be doing reviews all the time, and should become pretty automatic. Not really much more difficult than remembering to check "comment represents an issue" or whatever it's called. [16:09] Bug #1626626 opened: juju status outputs ERROR "" is not a valid tag [16:09] katco: trying to figure out how to properly replace the existing notfound error with my own notfound error... it's unfortunate we wrote our errors package in the way we did, just doing type assertions [16:10] katco: maybe Wrap is what I'm looking for [16:14] katco: yeah, wrap seems to have the correct behavior [16:16] natefinch: i know i always confuse them. [16:19] katco: I had to actually write a little program to make sure that wrap didn't munge the old error's text in with the new one. [16:25] oops... I'm going to have to get used to not doing commit --amend during reviews [16:26] natefinch: do you still have your PR in review? [16:26] rick_h_: yep [16:27] natefinch: can you please create a second PR for that change but from your branch to the juju/develop branch ? [16:27] natefinch: huh yeah, it's not really easy to tell what has changed in response to a review [16:27] rick_h_: for the error message change when there's no current controller? [16:27] natefinch: yes please [16:27] rick_h_: sure thing [16:28] natefinch: ty [16:28] katco: it might be easier if I didn't force push an amended commit. That's something we'll ahve to look at [16:28] brb [16:30] * rick_h_ goes for lunchables [16:43] how's it going all? [16:45] is there a doc that details what ports and protocols need be allowed for client <-> controller, and agent <-> controller communication? [16:46] I'm having to write up an application network and security spec for a client === frankban is now known as frankban|afk [17:09] what I'm seeing is client <- tcp 22/17070 -> controller, and agent <- tcp 22/17070 -> controller [17:09] so 22 and 17070 are all that need be allowed between both sets? [17:11] bdx: sounds right [17:45] Bug #1626626 changed: juju status outputs ERROR "" is not a valid tag [18:01] rick_h_: thanks [18:02] I know this is a long shot, and I think I know the answer, but may as well ask ... does juju have anyway to deploy time based instances? [18:03] on AWS [18:04] bdx: no, you have to script that [18:05] rick_h_: would it be a better practice to use the manual provider, and add machines that have been manually provisioned as time based? [18:05] bdx: maybe we're not thinking the same thing. What do you mean by time based? [18:06] rick_h_: something we currently use to save on our AWS bill - time based instances can be scheduled to turn off durring non use hours [18:07] bdx: oic, so it's an instance type? /me goes to look at aws docs [18:08] oh, not really an instance type, but a scaling type config on an instance layer [18:09] rick_h_: yea -> https://postimg.org/image/uc03ismnf/ [18:09] bdx: interesting, a manual prover type situation may work? [18:09] the fun part will be how juju handles units showing up/going away like that [18:09] bdx: especially in relations, where juju epxects there to be these units talking to those units and they disappear [18:10] the boxes I will be manually provisioning will be lxd staging silos [18:10] bdx: since nothing there will be updating the units in the relation lists in juju [18:10] so they wont even have any charm deployed to them [18:10] oic [18:12] I'm thinking I will just use juju to grant devs access to their respective instances that will each have the lxd non prod envs on them [18:13] seems to be the best option for my use case of containerizing our non-prod envs [18:14] still seems slightly shiesty [18:14] ha [18:14] I think it will work though [20:51] anastasiamac, rick, tim and I will be on another call and will not be at the bug scrub [20:52] alexisb: \o/ enjoy [20:52] oh wheeee [21:03] Bug #1587644 opened: jujud and mongo cpu/ram usage spike

[21:05] and bug scrub time? :D [21:15] Bug #1587644 changed: jujud and mongo cpu/ram usage spike

=== hml_ is now known as hml [21:18] Bug #1587644 opened: jujud and mongo cpu/ram usage spike

[21:22] menn0: hi! can I pick your brains some more please? [21:22] babbageclunk: sure [21:23] babbageclunk: hangout or IRC? [21:23] menn0: hangout might be quicker [21:23] https://hangouts.google.com/hangouts/_/canonical.com/mongo-stuff?hl=en&authuser=1 [21:24] menn0: ^ [22:11] thumper: would you know why when attempting a juju upgrade, this message states "juju.environs.sync sync.go:333 using agent binary 2.0-rc2-xenial-amd64 aliased to 2.0-rc2.2-xenial-amd64" why is it using patch version .2, I expected it to use .1. Any insight? [22:12] nope, sorry [22:12] well [22:12] the existing one probably uses .1 right? [22:14] thumper: the existing was rc1 binary, model version stated rc1.1, but this is using rc2 binary (and using lxd so I was expecting rc2.1) [22:14] hmm [22:14] not sure sorry [22:15] thumper: any idea who might be able to shed some light? [22:15] heh, wallyworld, but he isn't around [22:15] I'm not sure who reviewed those changes, perhpas axw? [22:16] thumper: cool, I spoke with him a little yesterday. I'll pester him again today :-) [22:18] veebers: if the client is .1, when you go to upgrade it'll auto-increment to .2 [22:18] veebers: (because .1 is not in streams) [22:20] axw: so it'll go from rc1.1 -> rc2.2 ? [22:21] veebers: sorry, didn't notice the change in RC. that doesn't seem right. [22:26] axw: oh odd, this run through (each time a fresh bootstrap etc.) it's aliased it to .3 [22:27] veebers:that makes no sense. the client is just plain old "rc2", right? [22:27] axw: oh, I plugged '--version 2.0-rc2.2' onto upgrade-juju (previous run was --version 2.0-rc2.1) [22:27] axw: boostrapped with rc1 binary, using rc2 binary to execute the juju-upgrade [22:28] veebers: ok, that sounds a bit funky. if you specify a version we shouldn't be auto-incrementing anything [22:30] axw, ping [22:30] alexisb: coming [22:49] thanks axw [22:49] np [22:52] alexisb: apparently it was wallyworld who added the default security group thing :/ [22:52] i'll ping martin anyway [22:53] that must have been post the provider work [22:53] did his PR state why it was added? [22:54] I wonder if we can track it ot a bug [22:54] it probably was a user request [23:14] axw: I'm going to file a bug re: the juju-upgrade --version thing, I was able to manually recreate it too [23:14] veebers: thnaks [23:17] alexisb: sorry.. installing bluejeans plugin [23:36] axw: fyi: https://bugs.launchpad.net/juju/+bug/1626784 [23:36] Bug #1626784: upgrade-juju --version increments supplied patch version [23:42] mwhudson: apparently there's a meeting option: http://bluejeans.force.com/KnowledgeSearch/articles/Knowledge_Base/Mute-Participants-on-Entry-to-your-meeting/p [23:42] alexisb: can you set that please? ^^ [23:43] axw: ah awesome [23:43] axw: it was also the usual thing of "i know, i'll use the internal mic!" :( [23:49] Bug #1626304 opened: Charm GC in 1.25.6 leaves breakage behind