[00:14] babbageclunk: i have to head out for a bit soon to take kid to doctor in case you need me [00:14] wallyworld: no, I'm good for now [00:45] babbageclunk: bug 1641824 is fixed right? [00:45] Bug #1641824: Migrating a model back to controller fails: model XXXX has been removed [00:46] menn0: hmm - all but the last case. [00:48] menn0: I need to chase down the stuff that calls the NewHandlerArgs.Connect function and ensure that it calls release on the state at some point. I tried a while back but got lost in all the component stuff. [00:50] babbageclunk: ah right. that rings a bell. [00:50] babbageclunk: critical for 2.1? [00:51] menn0: oh hey, you fixed that bit to use my stateForRequestAuthenticatedTag func - that should make it easier. [00:53] babbageclunk: hooray :) [00:53] babbageclunk: that rings a bell too :) [00:53] menn0: I guess so - state leak on any model that uses resources. [00:53] menn0: sorry - I mean, I guess it's critical in that case. [00:53] babbageclunk: if you can find to take a look before the release goes out that would be awesome. [00:55] babbageclunk: menn0: this week only beta release is going out (beta3), first week of Jan - rc1 (tentative), 2nd week final (tentative too)... just an fyi \o/ [00:56] menn0, anastasiamac: I'll take another look now. [00:56] anastasiamac: ok thanks [01:00] menn0: Ok, I think I see how to do it now. [01:03] menn0: thumper: Ci is still seeing this issue https://bugs.launchpad.net/juju/+bug/1620438 [01:03] Bug #1620438: model-migration pre-checks failed to catch issue: not idle

[01:03] the latest failure was on Dec 13.... on 2.1 [01:04] menn0: thumper: is there a backport that needed to happen? [01:06] anastasiamac: not sure when the fix was made. thumper ? [01:07] menn0: last PR on the bug was merged 14 days ago... [01:07] menn0: and since it went into develop... I am guessing the issue is not fixed :( [01:08] anastasiamac: or the test is trying to start a migration before the model has actually finished deploying [01:09] menn0: http://reports.vapour.ws/releases/issue/57ce2d2b749a563a65a52631 [01:09] anastasiamac: let's reopen it for now [01:09] menn0: or that :) [01:09] so we don't forget [01:10] menn0: doen [01:10] done even [01:21] anastasiamac: that last resource migration PR landed btw [01:21] menn0: \o/ (I saw) [01:21] menn0: well done [01:21] menn0: What's a charm I can deploy that uses resources? [01:23] babbageclunk: cs:~cmars/mattermost [01:23] babbageclunk: that actively uses them [01:24] babbageclunk: etcd uses a resource too but it's only tied to a specific action [01:24] babbageclunk: just a placeholder resource after deploy [01:24] depends what you want to test [01:24] menn0: wow, the resources stuff doesn't have good test coverage, huh? I just changed the signature of several bits and still have a know nil pointer exception in my code but I can't make any of the tests fail. [01:24] *known [01:25] babbageclunk: yep :( I've found a bunch of places where there's no tests at all [01:25] babbageclunk: fixing one of those now while fixing a bug [01:32] menn0: should bug 1649738 be targeted to 2.1.1? or later like 2.2? [01:32] Bug #1649738: migrations should support renaming of models [01:33] menn0: my understanding that 2.1.1 should b mainly bug fixes for 2.1.x rather than new functionality.. [01:33] anastasiamac: 2.2 is more realistic given that it's potentially a big piece of work but alexis suggested 2.1.1 [01:34] anastasiamac: depending on where model names are still used to tag things, it might be quite small/easy or big/horrible [01:34] menn0: k. this means alexisb has a plan \o/ will go with her suggestion :D [01:34] menn0: well, we are all about extremes nowdays - nothing in the middle ;) [01:39] babbageclunk, validation complete :) [01:39] thank you [01:40] alexisb: yay! [02:15] thumper, anastasiamac or babbageclunk: https://github.com/juju/juju/pull/6702 [02:16] * anastasiamac looking [02:22] thumper: so what do we want the policy to be wrt downgrades with migrations? [02:23] thumper: 1.2.4 to 1.2.3 is ok? [02:24] menn0: lgtm [02:24] thumper: that is, only check major.minor? [02:24] anastasiamac: tyvm [02:25] menn0: anytime (...almost) \o/ [02:26] menn0: to make mattermost use resources, do I need to deploy it with an overriding resource, or is just deploying it enough? [02:26] babbageclunk: with mattermost, deploying it is enough [02:26] :( [02:26] I can't get it to hit my problem code. [02:27] babbageclunk: the mattermost binary distribution is a resource, used during the install hook [03:01] menn0: thumper: is there a meeting today? [03:01] * thumper votes no [03:01] sgtm [03:02] wallyworld: I'd forgotten about it. I vote no as well. [03:04] menn0: re downgrade, I'd suggest patch only [03:04] so 2.0.3 -> 2.0.2 [03:04] 2.1.0 -> 2.0.2 seems more dodgy [03:05] thumper: cool, that's what I've done. [03:05] menn0: we don't have a way to negotiate a version to talk to [03:05] thumper: basically, patch, build and tag are ignored [03:05] what if 2.0.3 modifies the descritpion format and 2.0.2 doesn't understand [03:06] thumper: 2.0.3 shouldn't do that [03:06] thumper: it's for bug fixes only [03:06] we should ensure that is the case then [03:06] thumper: the description format should arguably only be allowed to change if the minor version increases [03:06] something to add to a checklist [03:07] * thumper is testing HA pubsub branch [03:07] thumper: or we can allow downgrades only if the build or tag is different? [03:07] menn0: did you still want to meet in an hour? [03:07] I like your first idea better [03:07] ensure that the descirption format doesn't change in bug fix releases [03:08] jam: i'm happy to skip. lots of little bits of tidy up for the 2.1 release. [03:08] menn0: sgtm, hope you have a good day. [03:08] btw, I agree with the "major.minor" stuff [03:08] menn0: resources fix landed on 2.1... if ther is a chance plz forwardport to 2.2 (develop) [03:08] jam: and we only just had the sprint [03:08] though we have *not* been good about keeping real differences out of the micro releases [03:09] anastasiamac: not forgotten. I have a list of branches to forward port and that's on it. [03:09] jam: mayb it should b our NY resolution :D [03:09] menn0: \o/ [03:09] jam, thumper: i'm not sure how we robustly enforce it... [03:10] I'm not sure we can effectively... [03:10] could just be convention [03:10] and beatings [03:11] a cycle on a team that supports users? [03:12] anastasiamac: that's just crazy talk... [03:13] so a checklist then ... where to keep it? [03:14] menn0: part of review checklist? along with the item of 'did u consider upgradability?' [03:14] anastasiamac: but it's more of a thing to check at review time [03:14] anastasiamac: when commiting a PR you don't always know which version of Juju your change is going to land in [03:15] thumper, jam: there's a problem with relaxing the migration version check: post-migration you end up with a model with agents that are running tools ahead of the controller [03:15] menn0: hmmm if only we had some set of rules that could check codebase... [03:15] menn0: no... [03:16] menn0: we shouldn't support that [03:16] consider this [03:16] migrating from 2.0.2 -> 2.0.3 controller [03:16] the model doesn't change [03:16] it is still 2.0.2 [03:16] you can migrate it back then [03:16] but if you upgrade the model [03:16] nada [03:16] sorry [03:16] no move back for you [03:17] thumper: well that's already supported as it is now, without my PR [03:18] that is what we need to support... [03:18] I don't think we should support other than that [03:18] thumper: ok... well that works right now [03:20] thumper: what's missing is that we don't check controller versions, only the model version to the target controller version [03:20] thumper: there's a gap there where the model might be compatible with the target controller but the source controller is ahead of the target controller, meaning that migration API support might be missing [03:20] thumper: fixing that now [03:22] ok... [03:22] but ... [03:22] hmm... [03:23] so testing that target controller version >= source controller version, or just patch levels behind, yes? [03:23] menn0: ^^ that [03:23] thumper: quick HO? [03:23] sure [03:28] menn0, thumper: could one of you take a look at https://github.com/juju/juju/pull/6703 [03:29] It fixes the resource state leak. [03:31] I'mm'a go for a run [03:31] * babbageclunk goes for a run [03:43] gah, no I'm not - still doesn't work [03:45] babbageclunk: i'll have a PR ready for review a bit later, after your EOD. if you could look when you start tomorrow that would be greate [03:45] wallyworld: wilco [03:46] babbageclunk: it's to change how register remote relation works so we can remove a hack needed to lookup the remote app id on the consuming side [03:47] wallyworld: have u seen this one? remoteRelationsSuite.TestRemoteRelationsDead got nil instead of changes: https://bugs.launchpad.net/juju/+bug/1646861 [03:47] Bug #1646861: remoteRelationsSuite.TestRemoteRelationsDead got nil instead of changes

[03:47] that got fixed last week IIANM [03:48] wallyworld: do u have a PR? and do u know what branch it landed on? [03:48] develop [03:48] before we branched? [03:49] https://github.com/juju/juju/pull/6685 [03:49] no idea [03:49] maybe after [03:49] according to http://reports.vapour.ws/releases/issue/58418a80749a5656beeae59f, it was seen on Dec 12 on 2.1 [03:50] must have been after then [03:50] backport time [03:50] could u plz backport to 2.1? u may need to consider if it needs to b on 2.0 too [03:50] \o/ === frankban|afk is now known as frankban [12:19] jam: ping [12:19] voidspace: ? [12:20] jam: hey, you said you thought you'd seen code explicitly discarding constraints when there is placement [12:20] jam: above the container creation level [12:20] jam: and indeed the bundledata spec explicitly states this to be the case (but we'd like to change it) [12:20] jam: I wondered if you recalled whereabouts you'd seen this code? [12:21] voidspace: checking [12:21] jam: I don't *think* the charm package itself discards this information [12:25] voidspace: I don't see it right now. It was just something I came across in the past, might have been in lots of places as I've been digging in a lot of code lately. [12:25] jam: ok, no problem [12:26] jam: I'll keep digging [12:26] jam: it is explicitly documented in charm bundledata - so I'll construct a test to see if it does come out of that package [12:33] voidspace: I didn't think it was there, I thought it was somewhere like worker/provisioner [12:59] jam: rick_h: juju deploy ubuntu --constraints="mem=888M" --to kvm:0 [12:59] jam: rick_h: the constraint is honoured and works [12:59] jam: rick_h: definitely bundle specific [13:39] voidspace: good to know, sad to hear :) [14:05] perrito666, ping [14:11] alexisb: pong [14:11] sorry was taking a pill because yesterday I used my back in the wrong way [14:12] plus my internet is down :p good thing I have a backup internet [14:12] feels like monday [14:17] perrito666, it is monday for you isnt it? [14:17] it is, nad I have not had a Monday so Monday in months [14:18] perrito666, to help improve your monday... [14:18] I have a bug for you [14:18] https://bugs.launchpad.net/juju/+bug/1640210 [14:18] Bug #1640210: Restore-backup model is not usable because upgrade in progress

[14:18] also something triggered my differencial breaker in the office so after EOD ill have to run a full diagnostic to make sure nothing is leaking current [14:18] your favorite kind of bug [14:19] perrito666, please dont burn your new house down [14:19] alexisb: lol, lovely, Ill jump on it since my pending work from the sprint is awaiting for axw's patch to merge [14:20] I knew you would appreciate that bug ;) [17:32] wallyworld: ping - don't suppose you're around yet? [17:41] brb, relocation [17:42] voidspace: he will be here in about 5 hs [17:43] voidspace, wallyworld typcially starts around 9PM UTC [17:46] alexisb: thanks [17:46] perrito666: I guess I'll catch him later tonight [17:46] I have questions about the bundlechanges packages [17:46] voidspace: it's a lie; he is omnipresent [17:46] haha [17:46] voidspace: he's watching right now [17:46] katco: that would be nice... [17:47] frobware: voidspace: do you know if we ever implemented the default space as a configuration setting? [17:47] no-one has much experience with bundlechanges, but as usual it's more wallyworld's fault than anyone else [17:47] jam: I don't believe so [17:47] I'm wondering if "machine.AllSpaces" should be returning the default space if nothing else has been specified [17:48] jam: it would be better for us always to be explicit about spaces [17:49] jam: so machine.AllSpaces can always tell the truth === frankban is now known as frankban|afk [17:50] voidspace: well at some point we need to do *something* when requesting a container or machine that doesn't have a "--bind" or "--constraint space=" set [17:50] so *something* has to determine that the container/machine needs to go in the default space [17:51] voidspace: is there a bit of code that knows about the default space, or is it just that we let MAAS/EC2 give us a machine, which can be in any subnet/space ? [17:51] voidspace: theoretically there was supposed to be a default space that you would bootstrap into (detected at bootstrap time if nothing else supplied) [17:52] the extra cheap has is that it is the one that is named "default", but that especially feels bad on MAAS where you want to name them something meaningful to you [17:52] jam: my goodness, this was a while ago and you're making me think [17:52] jam: yep, on maas you should be able to specify which is the default [17:53] jam: I don't think we *enforce* the restriction that every machine must be in "the controller space", we just assume that everything is routable [17:54] voidspace: right, but there should also be a default space that applies to all machines when you don't specify something [17:54] jam: for ec2 we always have a default space and we don't let you remove spaces [17:54] which is not the controller space [17:54] but if you specify *nothing* then controller = default = whatever we bootstrap into [17:54] yep [17:54] voidspace: but is that *named* default, or is it a named space that we treat as default ?= [17:54] named "default" [17:55] jam: bah, so my understanding was a named space called "default" as it wasn't configurable [17:55] jam: I may be incorrect I'm afraid though [17:56] jam: gah, it's near EOD and I have my head in the bundlechanges code - I ought to be able to navigate this though [17:57] voidspace: sorry to distract you. good luck [17:57] voidspace: able to trace the calls through? [17:57] jam: no problem, I'm annoyed it isn't clearer [17:57] (for containers, if you haven't specified anything, but end up on a machine, if *it* is in a single space, then it seems ok to just use it) [17:58] yep, that has to be true [17:58] but that feels more like it should have only picked a machine that would have fit in the first place [18:46] rick_h, katco: currently add-credential requires a parameter specifying the cloud to which you're adding a credential. Do we want to make that optional? It would be more consistent with add-cloud if you could run interactive with zero args [18:47] natefinch: not at the moment [18:47] natefinch: for now let's leave that part [18:47] rick_h: yeah, outside the scope of this PR, you're right [18:47] natefinch: i agree that in interactive mode that's the consistent work we want, but there's bigger fish to fry atm [19:13] Any document on developing juju provider? [19:15] back === frankban|afk is now known as frankban [19:16] fengxia41103: There's this https://github.com/juju/juju/wiki/Implementing-environment-providers [19:19] ruh roh juju.tools.lxdclient client_instance.go:278 while removing instance "juju-e2f2ef-0": Failed to destroy ZFS filesystem: cannot open 'lxd-pool/containers/juju-e2f2ef-0': dataset does not exist [19:21] hmm... that might be fixed by now, realized this is an old test [19:21] er old test run [19:59] mgz, sinzui: is there something wonky with the representative tests? [20:00] abentley: ^ [20:00] http://juju-ci.vapour.ws/job/github-check-merge-juju/441/ [20:00] natefinch: they have sadly been pretty wonky for a while [20:00] anything in particular? I'll look. [20:00] 19:30:24 ERROR cmd supercommand.go:458 failed to bootstrap model: refreshing addresses: instances not found [20:01] oh, that message again... that's a new(ish) thing masking real problems [20:02] natefinch: means the lxd container didn't come up [20:02] natefinch: machine is probably full or similar again [20:02] natefinch: request, can you send a message to a list, any list, mentioning that the check job is failing your branch? [20:03] I've been fixing this stuff as people mention it and I think the overall message about things being screwed has not propogated upwards [20:05] brb reboot === tvansteenburgh2 is now known as tvansteenburgh === frankban is now known as frankban|afk [20:18] sinzui: could you please review https://code.launchpad.net/~abentley/juju-ci-tools/manual-endpoint-xfail/+merge/313274 ? === tvansteenburgh1 is now known as tvansteenburgh [20:25] mgz: will do [20:38] mgz: Do you suppose it's because the representative tests can run concurrently? [20:46] how does one relate application in different models? [20:46] applications [20:46] abentley: I think that is certainly a factor [20:48] mgz: test_check_token_win_remote_failure is failing on my machine. Is this due to your "OSX/Windows client tests now more useful" changes? [20:53] redir: that's the cross model relations work that wallyworld is driving and is behind a feature flag [20:53] redir: what makes you ask? [20:54] rick_h: OCR trying to verify QA but I don't know the spelling for making that relation. [20:54] rick_h: on a CMR bit wallyworld has a PR for [20:54] redir: juju relate model/application:endpoint I think [20:55] figured I'd dig up the spec if the lazy IRC didn't help [20:55] ahh / I tried : [20:55] but that's already used, duh. [20:58] doesn't work. I bet I need to run with a feature flag or something [20:59] redir: yea, need to have the FF enabled, probably at bootstrap time [20:59] redir: rick_h: that syntaxt isn't used yet. for now you 1. offer "juju offer mysql:db local:/u/me/mysql" and 2. relate "juju relate wordpress local:/u/me/mysql". steps 1 and 2 are done in different models [20:59] wallyworld: doh! ok I wasn't sure [20:59] tis ok, all wip [20:59] wallyworld: what's the FF magic incantation? [21:00] ff is called "cross-model" [21:14] wallyworld: sorry, still going through yours - thumper tried to trick me into looking at one of his, he was all "he's asleep, he won't mind" [21:14] lol [21:16] Alice is taking the baby birds we found in our Christmas tree to the SPCA. [21:16] Nice [21:24] mgz, abentley, sinzui: is there a fix for the representative tests machines? I can't land stuff right now because I don't know if the representative tests pass. I mean, I guess I could just ignore it and try to merge anyway, but that seems bad. [21:25] natefinch: what branch is this? [21:25] babbageclunk: are you looking at 6707 [21:25] ? [21:26] rick_h: the add cred updates and model status stuff [21:26] natefinch: so the add-cred updates we were going to hold until beta3 is tagged? [21:27] rick_h: right, right, sorry, got distracted by the test failures [21:27] natefinch: all good [21:27] natefinch: might as well hold both at this point since we're looking to tag just to not introduce anything the day of please [21:27] natefinch: and that'll give folks time to look and correct things [21:27] rick_h: sure thing [21:27] natefinch: ty for the email [21:28] redir: yeah, wallyworld emailed me it last night [21:30] oh [21:31] * redir stops looking [21:32] redir: sorry, i thought you we almost done and when babbageclunk stood me up in favour of thumper i figured you would come to the rescue :-) [21:32] well QA checked out [21:33] good cause it worked for me too [21:33] and I got as far as that one comment. [21:34] but I know babbageclunk is working on CMR with you so prolly more useful to have him looking at it [21:34] yeah [21:34] trivial port anyone? https://github.com/juju/juju/pull/6710 +10 -40, exactly same code merged into 2.1 [21:35] natefinch: ports do not need review unless they r vastly different from original [21:35] anastasiamac: cool [21:35] natefinch: self-stamp :D [21:42] wallyworld, ping [21:42] yo [21:42] do you mind if we meet early for our 1x1? [21:43] I am ready anytime [21:43] alexisb: sure, give me 10? [21:43] yep meet you in the HO === frankban|afk is now known as frankban === petevg is now known as petevg_afk [22:32] wallyworld: reviewed, sorry for the delay! [22:32] np at all ty === frankban is now known as frankban|afk [23:14] babbageclunk: changes pushed [23:32] I am getting a few mins late to standup caught in traffic [23:33] perrito666: no standup today [23:34] Oh didn't know, why? [23:35] * perrito666 stops driving like a mad man [23:35] Irc on the phone is fantastic for traffic jams [23:35] perrito666: due to not many people [23:37] thumper: hah, the one time since I'm back that I remember about the standup and it's not happening :-) [23:44] well looks like bluejeans isn't happening either [23:44] I wanted to try my new webcam :p [23:47] so maybe bluejeans is working fine, but chromium 53 is not. [23:47] redir: i'm on chromium 53 and bluejeans appears to be working [23:47] menn0: don't update [23:49] or something. Appears related to https://sslmate.com/blog/post/ct_redaction_in_chrome_53 [23:49] which is definitely happening for me on other sites (smile.amazon.com) [23:50] and if I look at the network requests when loading bluejeans I see that error too [23:50] this started after I updated and rebooted today. [23:53] menn0: redir: chromium did not work for me with bluejeans. had to use chrome :D otherwise i had no sound [23:58] are we not having standups this week or just today?