[00:00] marcoceppi: no I haven't had that problem with it yet [00:03] LiftedKilt: :| I've it hit it twice, want to check if there's a bug [00:08] Bug #1564662 opened: Juju binaries should be stripped

[00:11] marcoceppi, LiftedKilt what provider? [00:11] cherylj: me, aws [00:12] marcoceppi: ah, I bet your deploys were to hosted environments [00:12] and I bet that we only clean up the admin model [00:12] (d'oh, I said environments) [00:13] I've been switching between 1.25 and 2.0 too much today [00:13] marcoceppi: when you used kill-controller, was your controller machine alive? [00:13] marcoceppi: also, there's the rate-limiting bug [00:14] bug 1537620 [00:14] Bug #1537620: ec2: destroy-controller blow the rate limit trying to delete security group - can leave instances around <2.0-count>

[00:23] Bug #1564662 changed: Juju binaries should be stripped

[00:32] Bug #1564662 opened: Juju binaries should be stripped

[00:32] Bug #1564677 opened: Create one binary for juju and all plugins

[00:33] evening all [00:34] katacoh~~~ [00:35] Bug #1564677 changed: Create one binary for juju and all plugins

[00:36] mgz: lol is that some weird way of spelling my name? [00:38] Bug #1564677 opened: Create one binary for juju and all plugins

[00:38] katco: it was just the musical version... [00:38] mgz: or perhaps the japanese literal pronunciation [00:44] katco: hm, I'd guess that would be キャットコ [01:02] mgz, そうです :p [01:03] bogdanteleaga: :) [01:31] hey axw, can you take another look? http://reviews.vapour.ws/r/4389/ [01:32] cherylj: looking [01:32] Bug #1564694 opened: Proxy updater fails with "permission denied" [01:33] cherylj: LGTM, thanks [01:33] thanks, axw! [01:38] fucking fuck [01:38] thumper: this new default "default" model thing messes with migrations somewhat [01:38] in what way? [01:38] thumper: it means that you've got to remember to delete the "default" model on the target controller before you migrate [01:39] or just always create one called "to-migrate" [01:39] :) [01:39] thumper: sure, but it's dumb that we're setting up people to fail [01:40] well... [01:40] we aren't going to be migrating the default model very often [01:40] * thumper thinks [01:40] ... [01:40] maybe [01:56] Bug #1564700 opened: juju 1.25 -- go 1.6 -- provider/joyent tests explode due to incorrect use of AddCleanup [02:12] menn0: https://github.com/juju/juju/pull/4957 [02:17] davecheney: will take a look in just a sec [02:18] menn0: can we juat warnfpr conflicting models? [02:18] menn0: seems we should do that anyway? [02:19] warn on conflicting models [02:20] rick_h_: warn and do what? rename the model and migrate it anyway, or abort? [02:23] thumper, rick_h_: FYI agent API connection cut over to the target controller during migration is sooo close [02:23] \o/ [02:24] thumper, rick_h_: it's failing now because I didn't update the CA cert in the agent conf [02:24] thumper, rick_h_: and of course, there's currently no way to do that... so I'm going to have to add that [02:24] :) [02:25] thumper, rick_h_: I've found a bunch of other stuff that isn't quite right along the way but I'm ignoring them for now [02:29] thumper: I put this up yesterday but it hasn't had a review. could you take a look please? http://reviews.vapour.ws/r/4370/ [02:29] sure [02:32] davecheney: as I said on the review, holy crap, ship it! [02:32] how did that get in? [02:36] menn0: I'll look at the branch after my coffee break [02:36] menn0: just submitted my gomaasapi merge for AllocateMachine [02:36] phew [02:37] thumper: painful? [02:37] thumper: no rush on that PR actually [02:37] a bit time consuming [02:37] had to refactor a few test classes [02:37] also added explicit error types into gomaasapi [02:37] thumper: actually hold off with the review completely until I get the CA cert stuff done [02:37] so we don't leak net/http errors [02:37] menn0: ack [02:37] added other utility helpers etc [02:37] next one will be much faster [02:38] ok cool [02:38] * thumper -> coffee [02:38] throw your hands in the air for the joyent mock server that isn't safe for concurrent access! [02:43] davecheney: \?/ [02:44] thumper: you *can* review this one: http://reviews.vapour.ws/r/4397/ [02:44] menno sorry at the airport. yea warn and abort [02:51] rick_h_: that's basically what will happen, although currently perhaps not as early as it could [02:54] thumper: I need to fork the joyent/gomanta package [02:54] I cannot fix it from outside because of the way it's written [02:54] I thought I could dot he same hack we did with the maas mocks [02:54] but that won't work [03:05] bugger [03:05] davecheney: can we just submit the fix to them? [03:05] we can apply pressure to get it merged [03:05] especially if it is just wrong [03:06] how fast do you want it fixed ? [03:06] i'll make a gentlemans bet that they have abandoned that code [03:06] why don't we cut over to our fork and then we can discuss upstreaming at a later date [03:09] thumper: pls review this one now: http://reviews.vapour.ws/r/4370/ [03:10] * menn0 tries out a migration again [03:18] axw: we don't use environ Storage() any more do we? [03:18] thumper: I think MAAS might be the only provider that needs it now, but it should be internal to the provider [03:18] what does maas use it for? [03:18] thumper: perrito666 was working on excising the last bits, I'm not sure if it's finished [03:19] thumper: for recording which machines host controllers [03:19] ugh [03:19] should so just do that with tags [03:19] thumper: tags don't work like that in MAAS [03:19] we do use tags in other providers [03:19] hmm... [03:20] thumper: why does it matter? [03:20] because we want to make another provider type under the covers for maas 2.0 [03:22] thumper: I'm all for dropping maas/storage.go if we can, but I'm not sure what else we can use to record controllers in the environment [03:22] I'll think on it while dealing with maas 2 stuff [03:23] we can probably delete half of what's in there anyway [03:28] thumper: migration with api cutover worked! [03:28] fuck yeah!!! [03:28] thumper: I had to do some dodgy shit to make it happen though [03:29] thumper: the main problem is that the watchers coalesce events so it's easy for the minion to miss phases [03:30] yeah... [03:30] that is bad [03:30] thumper: more synchronisation is needed to fix that properly... it's something that had to happen anyway [03:31] thumper: also, the migration master is quite fragile if it gets interrupted [03:31] thumper: I know what to do there, but it requires API changes [03:31] axw: tyvm for fixing the concurrent bootstrap issue btw [03:31] axw: that's made my life a lot easier [03:32] menn0: cool, no worries [04:35] ok, I'm outa here [05:36] Bug #1258027 changed: cloudinit: disable apt-get update/upgrade

[07:35] axw: hiya [07:35] rogpeppe1: howdy [07:36] axw: i wonder if you could enlighten me as to exactly what a controller uuid is... [07:36] axw: can it be used just like any other model uuid? [07:36] rogpeppe1: it's just the UUID of the admin model [07:36] a special model [07:36] axw: ah, ok [07:36] axw: does it have a special set of API facades? [07:37] rogpeppe1: you can use the Controller facade if you're not connected to a specific model [07:37] I don't know if there are others [07:37] axw: but the admin model will always exist, presumably? [07:38] axw: and... is not connecting to a specific model actually supported? [07:38] rogpeppe1: I don't know what would happen if you tried to delete it TBH [07:38] axw: i see that you're currently allowed to connect with no uuid, but it looks like it's legacy code [07:38] axw: at least, the comments seem to indicate that [07:39] rogpeppe1: it works at least :) probably not recommended [07:39] axw: ok, that's useful thanks. BTW, can you deploy services in the admin model? [07:40] rogpeppe1: yes, for now at least [07:40] no plans to change it, though I kinda wish we'd lock off controller machines by default [07:41] axw: i'm thinking there should be a doc comment somewhere describing all of this [07:41] axw: but perhaps i've not found it yet [07:41] rogpeppe1: yeah, docs on internals are severely lacking [07:42] axw: to be fair, this isn't really internal [07:42] I intend to write some when I'm not furiously coding for 2.0 :) [07:42] yeah, true [07:42] axw: it's detail that users of the API need to know [07:43] axw: thanks for clearing this up anyway. i've never been quite sure about this stuff. [07:43] rogpeppe1: np [07:43] axw: (and FWIW it seems that no-one else is either :-]) [07:43] :) [07:43] me included... getting there tho [08:20] axw: one other thing: if i want to grant a user admin-level access, is it sufficient to pass params.ModeWriteAccess to GrantModel? [08:20] axw: it seems a bit odd to me that GrantModel takes a string not a ModelAccessPermission for that argument [08:21] rogpeppe1: I believe so - you may want to double check with cmars, who added that. I'm pretty sure that's what you need to do tho [08:21] axw: ok, thanks. so "write" implies read permission and admin rights. [08:22] axw: i guess i could just use a string literal (shock, horror!) [08:22] rogpeppe1: sorry, you need to give write access to the user on the admin model [08:22] that's my understanding anyway [08:22] that makes them an admin [08:22] axw: ah, i don't want them to get admin access to the controller [08:22] rogpeppe1: write on any other model just gives them read/write access to that model, of course [08:23] axw: just the ability to do anything within the given model [08:23] axw: i guess i was confused by: [08:23] // ModelAdminAccess allows a user full control over the model. [08:23] ModelAdminAccess ModelAccess = "admin" [08:24] rogpeppe1: somewhere along the line write gets translated to admin [08:24] axw: which i *think* is equivalent to "write" at the top level [08:24] not sure why there's two spellings [08:24] axw: i've seen at least three different representations of that same set of things [08:25] rogpeppe1: yeah, I've seen them in params, juju/permissions (which should be core/permissions), and state [08:25] we could do without the one in state, that should just use the one in core/permissions [08:25] axw: i guess [08:26] axw: the one in juju/permission is an int though [09:00] rogpeppe1: FYI, this branch adds the API for getting the list of users that have access to a model: https://github.com/juju/juju/pull/4959 [09:00] rogpeppe1: (included within results of ModelManager.ModelInfo) [09:00] Bug #1564791 opened: 2.0-beta3: LXD provider, jujud architecture mismatch [09:00] axw: cool, looking [09:01] rogpeppe1: I'm not in a hurry for a review, logging off now - would appreciate comments if it's missing what you need tho [09:01] axw: ok, will do it now so i remember :) [09:01] :) [09:01] fwereade: hangout? [09:03] voidspace: standup? [09:04] dooferlad: omw - sorry [09:06] dooferlad: babbageclunk: frobware: browser issues === urulama_ is now known as urulama [10:29] babbageclunk: frobware: drop-maas-1.8 landed apparently! [10:29] which is great news [10:39] voidspace: yep, nice [10:44] voidspace: o/ [11:02] morning all [12:12] babbageclunk: right, daily report (so far) written up [12:12] babbageclunk: with obligatory rant written and then thrown away [12:13] babbageclunk: our merge failed - failing tests https://github.com/juju/juju/pull/4943 [12:13] babbageclunk: we can look at that after lunch, I'm going on lunch now [12:25] Bug #1564880 opened: modelmanager.Client.GrantModel should be idempotent [13:27] voidspace / frobware: Smallest diff of the day if you can +1 it http://reviews.vapour.ws/r/4400/diff/# [13:38] Man, I do not understand "go test" at all [13:43] perrito666: you went on vacation and decided to build a PPA? I bet you're happy to get back to work, where it's less stressful and annoying [13:43] natefinch: well I decided to try the software but for that I wanted it to be packaged [13:44] perrito666: bah. packaging go code in a PPA is a waste of time. That's the whole point [13:47] natefinch: installing things in a server that are not in a package is an accident wairing to happen [13:48] plus, deb packages not only hold the binary, they also hold a basic conf and permission setting [13:49] unless you are the kind of person that enjoys writing systemd services and upstart jobs [13:49] anyone good at git spelunking here? i'd like to find the code review that the changes in 520a90f3cc6f2a2f9fcb967fa78ea625be19042c were reviewed in... anyone know a decent way of doing that? [13:49] perrito666: that's true... though to be fair, you have to write all that to make the PPA :/ === lazyPower is now known as lazy|travel [13:50] i see lots of commits around that time but none with a review comment [13:50] rogpeppe1: lemme check [13:51] once upon a time, every commit to juju master had a link to the associated review :-\ [13:51] perrito666: thanks [13:51] rogpeppe1: that is the issue of merging [13:51] perrito666: i don't understand why [13:52] rogpeppe1: well you can have N commits inside a merge, a sane approach would be to flatten them before the merge [13:52] perrito666: surely every commit in both the master branch and the merged branch should have been reviewed? [13:52] probably this one: http://reviews.vapour.ws/r/3654/ [13:52] natefinch: nope [13:53] here ya go http://reviews.vapour.ws/r/3677/ [13:53] hint https://github.com/juju/juju/search?q=520a90f3cc6f2a2f9fcb967fa78ea625be19042c&type=Issues&utf8=%E2%9C%93 [13:54] I didn't do any git magic, just looked for reviews posted by andrew around the time of that commit that sounded likely :) [13:55] you can actually look for the hash in github and filter by issues, prs are issues [13:55] perrito666: hmm, i wonder why the commit message doesn't have the reviewboard link, since https://github.com/juju/juju/pull/4237 shows it [13:56] rogpeppe1: because the rb link is in the Pull Request not on the commit [13:56] perrito666: hmm, doesn't the bot ensure that the PR description is included in the commit message [13:56] ? [13:57] perrito666: lots of them do, so why not this one? [13:57] rogpeppe1: the merge request commit message is https://github.com/juju/juju/commit/b033024f0dc55e2bc371978828e7301a532fc926 [13:57] but the one you are looking at is https://github.com/juju/juju/commit/520a90f3cc6f2a2f9fcb967fa78ea625be19042c [13:58] so, you are looking at andrews commit not the bots one [13:58] git is fun like that [13:58] perrito666: yes i'm looking at andrew's commit [13:58] perrito666: (that's the one i'm interested in) [14:01] perrito666: ha, that commit message is in four places [14:01] rogpeppe1: yes, this is what happens [14:01] perrito666: sorry, 3 places [14:01] * perrito666 types [14:01] perrito666: i'd expect 2 places but not 3 [14:02] rogpeppe1: http://i.imgur.com/6krXnLO.png [14:02] so the message repeats in both the actual commit and the merge [14:02] the merges the bot does are not proper code merges but tree merges [14:03] where the commits by the pr are added to the tree and there is a "merge" commit marking said addition [14:03] rogpeppe1: http://stackoverflow.com/questions/17818167/find-a-pull-request-on-github-where-a-commit-was-originally-created/17819027#17819027 [14:03] I am curious about the 3 places though, might come from more than one people merging that branch into their work and then PRing [14:03] I believe that our current feature branch approach is not being so good and our not squashing neither [14:03] rogpeppe1: that worked for me... beware, it adds pull requests to the branches you get from github, wich is a lot [14:04] rogpeppe1: after doing that and git describe --all --contains I get remotes/origin/pull/4282~10 [14:04] the good thing is, after using bzr during a couple of days I re discovered my love for git [14:04] perrito666: yeah, it's odd. i see both 520a90f3cc6f2a2f9fcb967fa78ea625be19042c and c839dfdf8f226760ebeaa7eb302a2f1972763cc1 neither of which are merges [14:05] hmm.. which is ian merging master, which is not super useful actually [14:05] no, I tend to rebase master, makes clearer trees [14:06] I dont want to be steve jobs-y but, we are using it wrong [14:06] perrito666, natefinch: i'd like to come up with a script: showreview , which will automatically find the review link where the given commit was reviewed [14:06] perrito666, natefinch: do you think that's possible? [14:07] perrito666, natefinch: because i'm often doing some archeology using git blame, and that points me to a commit but then i want to know more about the context [14:07] rogpeppe1: yes, graphical tool shows it so it should be [14:07] perrito666, natefinch: i.e. this was broken then, but was there a good reason for that? [14:07] I think it must be possible, it's just tricky with all the merging we do, and as perrito666 said, I think we're doing it wrong [14:08] rogpeppe1: you need to trace back on the commit graph until your commit and whatever next merge is there should be the one [14:10] perrito666, natefinch: interestingly despite having the same commit message, both those commits are actually quite different [14:11] rogpeppe1: that might be because of the use of amend [14:11] on one of them at least [14:11] Does anyone know if we are building Juju 2.0 for ppc64le on 14.04 ? I have a partner trying to install and is so far unable [14:24] Juju 2.0 on ppc64le and 14.04 ... [14:24] mbruzek: in theory, I think so? AFAIK, we support ppc64le and 14.04 [14:25] natefinch: can you show me the binaries that the ppa supports? [14:25] I can't seem to find it... [14:25] mbruzek: uh... I have no idea, I'm sorry. [14:26] mbruzek: https://launchpad.net/ubuntu/wily/ppc64el/juju-core [14:26] natefinch: OK I don't either. [14:26] mbruzek: I try to stay away from launchpad and PPAs as much as possible [14:27] natefinch: Munging your URL I found nothing: https://launchpad.net/ubuntu/trusty/ppc64el/juju2 [14:27] mbruzek: ah juju2 sorry I missread you [14:27] no, I dont know about 2 [14:27] babbageclunk: https://github.com/juju/juju/pull/4962 [14:27] perrito666: Thanks for link... [14:28] This partner is only using LTS versions so since we haven't yet released 16.04 is a big ask of us [14:29] rick_h_: ^ mbruzek is asking about juju2 on ppc64el.. do we have a PPA which supports that? [14:29] (on trusty) [14:33] errors.Errorf("(cannot happen) [14:33] lol [14:34] natefinch, katco: you might be interested to see that subtest functionality has actually landed in go tip; not that it makes much difference in gocheck-land: http://tip.golang.org/pkg/testing/#T.Run [14:36] rogpeppe1: ahh, cool, I knew they were working on that. Is there explanation on how it should be used and what the output looks like? [14:36] rogpeppe1: interesting... i wonder if niemeyer will update gocheck to take advantage [14:36] katco: i somewhat doubt it, but you never know [14:36] natefinch: suck it and see :) [14:36] rogpeppe1: lol [14:37] gah, there is so much charmstore logic littered around our code.... [14:43] katco: That's nice, makes sense for gocheck to support it.. we'll just need to wait until it's mainstream.. a couple of years at least :( [14:43] niemeyer: hehe well it'll get there [14:44] we need a gotpkg.in/hipstergocheck that implements features before they are mainstream :p [14:48] frobware: dooferlad: http://reviews.vapour.ws/r/4401/ [15:17] natefinch: mbruzek i'm not sure we do. mgz and sinzui should be on soon and would know for sure [15:17] Hi rick_h_: we got it sorted, abentley and perrito666 helped me out. [15:18] rick_h_: It turns out they needed to add the ppa:juju/devel ppa. [15:18] rick_h_: I want to update the devel docs to suggest the devel ppa, do you object to that in anyway? [15:23] mbruzek: pr and o'll look and see if there's something better? [15:24] mbruzek: i guees since it's not final we push folks at xenial as it's not either [15:24] fwereade: hey we need you in a chat rq, do you have a moment? [15:24] katco, sure [15:24] fwereade: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [15:29] rick_h_: https://github.com/juju/docs/pull/951 [15:29] rick_h_: The issue with the partner was resolved, but if this change was in the docs they might not have had the problem. [15:34] frobware: ping [15:36] dooferlad: pong [15:36] frobware: are you making any progress with https://bugs.launchpad.net/juju-core/+bug/1556137 ? [15:37] Bug #1556137: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count>

[15:37] dooferlad: over and above the comment I added yesterday I'm doing nothing more... [15:38] Are you free to jump in a hangout and discuss it? [15:38] sure [15:39] frobware: https://plus.google.com/hangouts/_/canonical.com/sapphire?authuser=0 [15:49] hi there, the juju-core deb source used by ppa:juju/stable, where is it maintained? [15:50] freyes: you mean the source for the package? [15:50] perrito666, yup, the debian/ directory [15:59] freyes, checkout https://code.launchpad.net/ubuntu/+source/juju-core [16:01] niedbalski, those are the debian sources for the packages that have been uploaded to the distro archives, I looking repository where the debian sources for juju-core are maintained [16:02] freyes, ah stable ppa. I have no idea, maybe abentley mgz ^^ ? [16:04] freyes: for xenial proposed packaging, see lp:~juju-qa/ubuntu/xenial/juju/xenial-2.0-beta3 [16:04] freyes: I missed the initial question so I'm not sure what you're after [16:04] mgz, which one is used for ppa:juju/stable ? [16:06] freyes: last time I think and ol version of lp:~juju-qa/juju-release-tools/packaging-juju-core-default but that is changing [16:08] mgz, thanks, I think that will work for what I want [16:09] freyes: remember juju uses streams for everything but the client, so just rebuilding a debian package doesn't do much [16:10] mgz, yes, I'll use --upload-tools to make sure I use the version I have built [16:11] freyes: if you're going to be using --upload-tools you can just use a go build, you don't need the debian bits [16:12] mgz, this is part of a longer story, I need to provide a user with a patched 1.25.0 version to fix an specific problem they are having [16:12] and then they'll be able to upgrade [16:12] mgz, funny, isn't it? === urulama is now known as urulama|afk [16:27] katco, natefinch: we're done talking, if you want to continue our standup [16:28] ericsnow: sounds good brt [16:29] freyes: I am interested in this, are you going to write up what you've done to mailing list or similar? [17:48] ericsnow, katco: sorry, was at lunch. Want to meet now, or ? [17:49] natefinch: we decided there probably wasn't much to discuss, unless you have anything [17:50] ericsnow: nah... really just need reviews on my branches so I can get them landed.. they're all dependent, so it makes things difficult the longer they stick around [17:50] natefinch: feeling your pain :/ [17:55] ericsnow: maybe I'll just squash them all into a single commit [17:56] natefinch: that certainly makes rebasing easier [17:56] ericsnow: yeah, that's why I've started doing that for individual PRs [18:59] Bug #1565044 opened: s390x unit tests fail because not tools for arch

[19:01] apparently github now allows squashing on merge, oh the hapiness [19:02] oh no way [19:03] that would fix rogpeppe2 complain from today [19:06] oh man, that's awesome [19:06] and you can turn off the non-squash merge [19:25] Yet another problem with full stack tests: Change a function deep in the stack... now try to find tests that need to update to test that function. [19:25] Sure, you can run the tests and fix ones that fail... but that doesn't mean there aren't tests that are passing and shouldn't be. [20:32] oh crap [20:32] evidently you need to remember to do --parent when you rbt post -u [20:33] This diff has been split across 120 pages [20:34] ericsnow: do you know if there's any way to remove an errant diff from a review? [20:34] natefinch: better to just push up the correct one [20:36] ericsnow: how do I do that? rbt post complains the commit is already on reviewboard [20:37] natefinch: not sure [20:38] natefinch: perhaps add another commit? [20:41] well, as long as no one looks at changelist #2, we're all set :) [20:44] ericsnow: btw, just doing another rbt post -u with --parent added another changelist, and as long as you look at 0-N and skip the intermediary ones, it's fine [20:44] natefinch: yep [21:17] Bug #1565089 opened: create-model does not use the same config format as bootstrap

=== urulama|afk is now known as urulama|eow