[00:05] Bug #1554797 opened: juju 2.0 bootstrap should explain what was missing [00:05] Bug #1554802 opened: juju deploy should give more information, or less [00:05] Bug #1554807 opened: juju backups restore makes no sense [00:10] so a noob go question what exactly does the "..." do [00:10] so for example you have "...string" instead of "string" [00:11] it's the varargs operator [00:11] so in a function declaration [00:11] func f (args ...string) lets you write [00:11] Bug #1554802 changed: juju deploy should give more information, or less [00:11] Bug #1554807 changed: juju backups restore makes no sense [00:11] f("a", "b", "c") [00:12] inside f args will be of type []string [00:12] ok thanks davecheney [00:12] alexisb: https://golang.org/ref/spec#Passing_arguments_to_..._parameters [00:12] alexisb: also: https://gobyexample.com/variadic-functions [00:13] it's slightly confusing when using f if you aready have a []string [00:13] in that case you have to use the ... as a suffix [00:13] var s []string [00:13] alexisb: ... can also be used during a function call to expand a slice into separate arguments [00:13] f(s...) // don't treat s, []string as a single argument, treat it as the arguments [00:14] o! davecheney that last bit is very helpful [00:14] Bug #1554802 opened: juju deploy should give more information, or less [00:14] Bug #1554807 opened: juju backups restore makes no sense [00:18] alexisb: we have both styles inside juju [00:18] if you have a fn that already uses a []string (or another slice) then it can be a little more work to pass it down to something else with the ... suffix [00:19] OTOH we have many APIs that take a []slice of things, but almost always are called with just one thing [00:19] so there is a lot of typing to declare a literal slice of just one thing, in which case changing those APIs to be variadic can make them more pleasant to use [00:21] thank you davecheney; that explanation gave me the insight I needed to figure out how to update the func call [00:21] geeze I wasted too much time on that :) [00:22] wallyworld: everything was going so well [00:22] lucky(~/src/github.com/juju/juju) % juju create-model testing2 [00:22] ERROR provider validation failed: invalid EC2 provider config: model has no access-key or secret-key [00:22] create model the right thing ? [00:22] a controller has many models ? [00:22] so if I have the local.testing controller [00:23] i should be able to create a new model in that ? [00:23] davecheney: currently, as of forever, each time you create a new model, you need to supply credentials [00:23] but [00:23] there's a feature branch which relaxes that requirement [00:23] so, i dn't need credentials to create the first model [00:23] if you are controller admin, you don't need to re-suipply [00:23] correct [00:23] but every subsiquent one I do ? [00:23] wat ? [00:23] yes, that was the jes design [00:24] you were on that team :-) [00:24] so much for avoiding head trauma [00:24] wallyworld: I blame tim [00:24] by default [00:24] we are fixing it for 2.0. there was a valid reason at the time [00:37] Hello juju-core! [00:37] should I see juju 2.0 in the Xenial archive when I apt-cache search or apt-get install juju? [00:37] I am currently only seeing 1.25, but could be pilot error [00:39] scratch that I see 2.0-beta1-0ubuntu1~16.04.1~juju1 in the archive [00:40] keep up the good work. Looking forward to beta2 [00:51] wallyworld: hey sorry I missed standup, didn't get home till 1:30am, so slept in a bit [00:51] wallyworld: is the format of creds.yaml document ? [00:51] davecheney: it's in the release notes [00:51] axw: no worries :-) did you want a chat now? [00:51] wallyworld: ta [00:52] wallyworld: sure, will be in tanzanite in a minute [00:52] davecheney: the tooling is improving around managing creds, not quite there yet [00:52] wow, first experience of existing unit test catching an actual error I introduced into the code [00:52] nice [00:53] davecheney: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U [00:53] alexisb: yay tests :-) [00:53] btw davecheney I always blame tim by default as well ;) [00:54] wallyworld: there now [01:09] Bug #1554819 opened: juju help create-model is misleading [01:09] wallyworld: are you around? [01:09] perrito666: in standup hangout with andrew [01:09] jam: you dont have the pre push script in your git [01:09] wallyworld: that is an invitation? [01:10] we are talking work stuff so feel free [01:13] wallyworld: natefinch: fyi: https://github.com/juju/juju/compare/nate-minver#files_bucket [01:13] katco: ty, will look after meeting [01:13] wallyworld: natefinch: nate-minver has master merged in; can merge into master with a bless [01:18] well that took longer than I was expecting... [01:18] but I guess I should expect that [01:20] menn0: http://reviews.vapour.ws/r/4100/ [01:26] thumper: looking [01:26] menn0: I'm just preparing a branch to merge master into model-migration [01:26] menn0: and I'm thinking we should merge model-migration-control into model-migration [01:27] thumper: I was thinking the same thing [01:27] menn0: because you are going to want these functions RSN [01:27] thumper: indeed [01:27] cool [01:27] let's get model-migration synced up with master first [01:27] because I think model-migration-control is ahead of it there [01:27] thumper: CI has picked up a timing problem with one of the tests which I'm working on now [01:27] thumper: and we can merge afterwards [01:28] sounds good [01:28] * thumper has make check running on merge master [01:28] good time to go make a coffee [01:38] yep [01:38] tests still running [01:38] thumper: that's how you know your change is good :) [01:38] thumper: how long do the tests ttake on your machine ? [01:38] mine are the best part of 30 mins [01:39] I don't think I have timed a full run recently [01:39] it used to be around 23 minutes [01:44] it takes 25 mins in CI [01:44] my times are 30-40 mins locally [01:48] hmm... [01:48] my machine has going suspiciously quiet [01:48] time.Sleep(60 * time.Minute) [01:48] github.com/juju/juju/cmd/jujud/dumplogs [01:48] last pass [01:49] somethings' waiting for monog to time out [01:49] then you will receive _ALL_ the stack traces [01:49] \o/ [01:54] lucky(~/src/github.com/juju/juju) % juju list-models [01:54] NAME OWNER LAST CONNECTION [01:54] testing admin@local 20 seconds ago [01:54] lucky(~/src/github.com/juju/juju) % juju destroy-model testing [01:54] ERROR "testing" is a controller; use 'juju destroy-controller' to destroy it [01:54] so, is "testing" a model or not !?! [02:04] davecheney: cmd/jujud/reboot timed out [02:04] rup row [02:04] davecheney: testing is probably the controller model [02:07] ah poo [02:07] someone has added another exported field to serviceDoc [02:07] * thumper goes to see what it is [02:08] CharmModifiedVersion [02:08] wallyworld: do you know about this? ^^ [02:08] maybe? [02:08] thumper: that i believe is from the resources work [02:08] hmm.. [02:08] yeah [02:08] nate did it [02:09] it is used to track whether a chanr for a service has changed at all [02:09] and fires a hook if needed [02:09] for what purpose? [02:09] if resources change [02:09] a hook is fired [02:09] it uses the same pattern as we use for config-changed hooks [02:10] thumper: although why that is on the serviceDoc i am not sure [02:11] i guess for config we always fire an initial config changed hook [02:11] whereas for charm-upgrade we don't want to do that [02:15] menn0: 2016-03-09 00:08:41 INFO juju.worker runner.go:281 stopped "engine", err: cannot open api: agent should be terminated [02:16] is this a dependency engine thing ? [02:16] i've never seen that final error message [02:18] davecheney: that's something fwereade's been working on I believe although I didn't realise it was in master [02:18] davecheney: when are you seeing it? [02:18] in master [02:19] davecheney: I under conditions I meant? [02:21] oh, bootstrap worked but the rest of the agents in the deploy just went to sleep and never woke [02:21] i'll have to redeploy to figure out what happened [02:21] to be fair, I did a backup while units were deploying [02:21] then restored the backup over the top [02:21] davecheney: that would do it [02:21] I didn't expect that to be a good result [02:22] i just wanted to see how many pieces broke off [02:22] davecheney: i believe that you get that error when a machine or entity can't be found at login (or is no longer in the Alive state) [02:23] davecheney: they thing that connects to the API returns that error in that case, which has special meaning: stop the agent and uninstall from the init system so it doesn't get restarted [02:23] davecheney: that behaviour has been there forever [02:23] davecheney: but Will has been fixing and improving that functionality [02:23] and that is indeed what it did [02:23] agent stoped and the upstart job went away [02:23] davecheney: i'm not sure if you're dealing with the old or the new version of it (not sure where fwereade is at with merging) [02:25] davecheney: I have no idea how restore is actually supposed to be used - i.e. what are the expected preconditions [02:25] me neither [02:25] which makes it a bit hard to tell if I broke it [02:26] thumper: review done [02:26] menn0: ta [02:26] davecheney: really though you shouldn't be able to hose things like this using it [02:32] davecheney: can I get you to try cmd/jujud/reboot tests? [02:32] even running by themselves, they are timing out [02:42] menn0: re Backend [02:42] menn0: was talking to fwereade this morning [02:42] before that it was stateMethods [02:43] he suggested using backend [02:43] so I went for consistency [02:43] happy to be more descriptive [02:43] thumper: I was thinking something like BinariesUploadBackend, or just UploadBackend [02:43] hmm... [02:44] thumper: given that there's other stuff in migration.go that's not related to tools/charms upload [02:44] thumper: I don't feel too strongly about it if you disagree [02:44] hmm... [02:44] sounds fine [02:44] * thumper makes changes [02:49] tools/lxdclient/client_instance.go:331: wrong number of args for format in Tracef call: 1 needed but 2 args [02:49] how did this even get into master? [02:49] thumper: yeah, I saw that too [02:49] I thought we caught that shit [02:50] % juju deploy wordpress -n 3 && juju deploy mysql -n 2 && juju add-relation wordpress mysql [02:50] [Units] [02:50] ID WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE [02:50] mysql/0 error idle 2.0-beta2.1 4 3306/tcp 54.160.80.170 hook failed: "db-relation-joined" for wordpress:db [02:50] mysql/1 unknown idle 2.0-beta2.1 5 3306/tcp 54.205.17.37 [02:50] wordpress/0 unknown executing 2.0-beta2.1 1 80/tcp 54.226.146.198 [02:50] wordpress/1 maintenance executing 2.0-beta2.1 2 54.204.148.132 (config-changed) installing charm software [02:50] wordpress/2 unknown executing 2.0-beta2.1 3 80/tcp 54.159.101.133 [02:50] \o/ reproducable builds [02:59] thumper: I'm around if you want to talk about CharmModifiedVersion [03:02] actually, brb [03:05] back [03:09] menn0: http://reviews.vapour.ws/r/4100/ updated [03:09] hi natefinch [03:10] natefinch: what is the purpose of the number? [03:10] thumper: we needed to update the service doc such that it would trigger charm-upgrade for something other than changing its charm url [03:11] thumper: this is because charm-upgrade is supposed to fire when resources change [03:11] thumper: so when resources change, we increment CharmModifiedVersion (we also increment it when the charm url changes, just in case) [03:13] ok [03:14] thumper: the PR review, if you're curious: http://reviews.vapour.ws/r/3910/ [03:15] Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values [03:17] menn0: my update to model-migrations landed (master) [03:17] menn0: I'll propose one that merges model-migration-control [03:17] and look [03:18] Bug #1554863 changed: juju bootstrap does not error on unknown or incorrect config values [03:21] Bug #1554863 opened: juju bootstrap does not error on unknown or incorrect config values [03:23] menn0: http://reviews.vapour.ws/r/4102/ [03:23] if you are happy to merge that branch in, lets do it [03:26] thumper: yep, I have that test fix ready [03:26] thumper: 2 secs [03:27] menn0: so.. you are going to merge one final thing into the model-migratiion-control branch first? [03:27] menn0: when it has the right commits, I'll let you get the bot to merge the two [03:27] thumper: yep, just this: http://reviews.vapour.ws/r/4103/ (review pls) [03:27] thumper: yep, I can handle the merge [03:28] wallyworld: you around? [03:28] thumper: mm-control into mm right? [03:28] yup [03:28] menn0: yeah, this one: https://github.com/juju/juju/pull/4662 [03:29] thumper: ah right, you've already done the merge [03:29] menn0: well, I clicked on a github button [03:29] not a lot to do really :) [03:29] natefinch: did you have a q? [03:30] thumper: so that PR should update if I get further changes into model-migration-control I guess [03:31] menn0: why add the wait? [03:32] * thumper actually reads the comment [03:32] wallyworld: yes, so... I was going to write those tests for charm push-resource by mocking out the http Client... however, it occurs to me, that it's pretty damn fragile to do it that way. I mean, it requires the tests to know what exact responses some package two layers away is expecting.. totally breaks encapsulation and relies on internal implementation details. [03:33] menn0: to be honest, still not sure why it waits [03:33] thumper: yeah, it took me a while of looking at the shared api watcher loop code to figure it out [03:33] thumper: there's a goroutine which calls Stop as the client side loop exits. it's outside of the main loop monitored by the tomb and can run *after* the worker loop exits [03:34] thumper: it never happens on my machine but it does in CI, especially on i386, ppc and arm [03:34] natefinch: yeah, for unit tests that's not very useful. that's where the CharmStore strcu can help. but then we need tests to ensure CharmStore does the right thing. and we do at some point need to next the calling of the csclient [03:34] menn0: but what does that do? [03:35] menn0: so are we saying that sometimes on other architectures, the results don't come as fast? [03:35] thumper: yep, on slower or different archs that cleanup goroutine runs a bit later and so the test wasn't seeing the Stop call [03:36] thumper: https://github.com/juju/juju/blob/master/api/watcher/watcher.go#L73-L86 [03:37] menn0: shipit [03:38] thumper: ship it for http://reviews.vapour.ws/r/4100/ [03:38] 2 little suggestions [03:41] wallyworld: well, I have tests to test that charmstore works and I have tests that test that csclient works... we should also have some full stack CI and/or feature tests, but if those fail, it really just means we have some assumptions that aren't well communicated in our APIs and not covered in our unit tests, which could be fixed easily. [03:41] s/charmstore/charmrepo.CharmStore [03:42] menn0: ta [03:42] natefinch: yep, a feature test to round it all out sounds like is all we need now [03:42] wallyworld: ok [03:42] menn0: ah... yeah, sould have fixed those [04:23] my kingdom for people to use an interface, once in a while, somewhere. [04:24] Bug #1507867 changed: juju upgrade failures

[04:36] Bug #1507867 opened: juju upgrade failures

[04:39] Bug #1507867 changed: juju upgrade failures

[04:39] Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation

[04:42] ug.... I can't believe the charm command depends on code inside github.com/juju/juju .... and of course it's now broken [04:48] Bug #1546561 opened: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation

[04:54] Bug #1546561 changed: juju sets wrong default gateway for lxc containers when using JUJU_DEV_FEATURE_FLAGS=address-allocation

[05:32] axw: could i get a small review? https://github.com/juju/charm/pull/196 [05:33] wallyworld: ok, looking [05:40] wallyworld: VerifyLocal isn't used anywhere except in a test. where will it be used? [05:41] wallyworld: oh, this is just the charm package. it'll be used in juju... never mind [05:41] axw: i'm doing a core branch that will use it - wehn we deploy bundles with local charm paths [05:41] wallyworld: LGTM [05:41] i almost have that branch ready [05:41] ty [06:41] dummy is the only provider that imports the apiserver [06:41] and it doesn't do anything with the api [06:41] if I delete the call to the apiserver from Dummy's bootstrap method [06:41] millions of tests fail [08:10] morning o/ [08:20] davecheney: fundamentally after bootstrap completes we should have an API server running. Its just that all other bootstraps do it via "jujud bootsrap-???". [08:59] davecheney, the main thing is that the dummy provider is basically evil -- but I'm pretty sure it *does* do things with the api? in that it exposes the info necessary to connect to the api, which comes from the apiserver it actually runs [09:00] davecheney, the fact that a "dummy" provider goes so far as to actually run an apiserver is the heart of the problem [09:00] davecheney, life would be better if dummy were dumber [09:01] davecheney, jam: is there a name for that style of test double, that attempts to *simulate* some external component, and invariably ends up hideously complex and brittle? [09:02] frobware: hangout? [09:31] fwereade: i want to find out what dummy is doing and move it into a test suite [09:32] the interesting thing is not all of the tests fail, only some packages, albeit spectularly [09:32] so I suspect that a byproduct of importing dummy is the get a sort of kind of working api server, which we helpfully advertise via a package singleton, and have logic that avoids reinitalising it if it is already present [09:34] davecheney, yeah, and we have that happy fun Reset lark as well :( [09:35] davecheney, fwiw, tests that *don't* fail when you break dummy would be excellent candidates for disentangling from JujuConnSuite, I think [09:35] davecheney, easier bits to carve off the edges, hopefully makes it easier to see what the pleftover problematic tests are depending on, maybe? [09:39] the sadface was I wasn't trying to eviscerate dummy [09:39] i was actually doing some refactoring of th apiserver [09:39] and found a bonkers circular dependency from juju/testing to dummy to the apiserver [10:03] dimitern, jam: standup? [10:39] i need a second review on this simple change to the charm package; anyone care to take a look? https://github.com/juju/charm/pull/195 [10:43] rogpeppe, isn't it better to switch to yaml.v2 throughout? [10:43] dimitern: i'm not going to be responsible for changing juju-core to use yaml.v2 throughout [10:44] rogpeppe, I meant the charm package [10:44] dimitern: and it's kinda reasonable to be compatible with both, i think [10:44] dimitern: it does use yaml.v2 only [10:44] dimitern: but clients can use yaml.v1 to marshal a Meta value [10:44] dimitern: and i don't want to break that [10:45] rogpeppe, any important differences between v1 and v2 wrt behavior ? [10:45] dimitern: there are a few differences - i think they were documented somewhere [10:45] dimitern: *most* of juju-core seems to use v2 now [10:45] rogpeppe, so marshaling with v1 and unmarshaling with v2 works as well as vice versa? [10:46] dimitern: it's possible that the only two places in core which use v1 are doing so by mistake [10:46] dimitern: yeah [10:46] dimitern: it's still YAML [10:47] rogpeppe, btw I had some issues recently with changes spanning multiple subrepos with slightly different dependencies.tsv [10:47] dimitern: yeah, it can be awkward [10:47] dimitern: i've found the new -N flag to godeps very useful [10:47] rogpeppe, it turned out we don't have a good way of enforcing same revs across multiple related projects [10:47] dimitern: for converging on an agreed set of deps [10:47] rogpeppe, what does it do? [10:48] dimitern: it updates dependencies only if the deps are newer than what's already there [10:48] rogpeppe, that's useful indeed [10:48] dimitern: i think there is fundamentally no way of enforcing revs across projects [10:49] dimitern: separate projects are independent [10:49] rogpeppe, there should be a way to declare nested deps for juju/juju/ at least and other standalone projects [10:49] rogpeppe, that PR LGTM btw [10:50] dimitern: what do you mean by "nested deps"? [10:50] rogpeppe, i.e. dependencies.tsv or juju/juju "including" other .tsvs per import path [10:51] dimitern: what would it do if those tsvs conflicted? [10:51] rogpeppe, some way to verify revisions in juju/juju/deps.tsv for repo X matches the rev used by repo Y that depends on X, and juju/juju depends on both X and U [10:51] s/U/Y/ [10:52] dimitern: that sounds like it's going to produce conflicts more often than not [10:52] rogpeppe, if they conflicted, you can know and do something about it, rather than get random build failures for subrepos (like I had for charm.v6 recently) [10:53] dimitern: what I tend to do now is something like: for repo in $(awk '{print $1' < dependencies.tsv}); godeps -N -u $(godir $repo)/dependencies.tsv; done [10:54] because charm.v6 needs bundlechanges, which in turn needs revX of yaml.v1 (and charm.v6 uses revY of yaml.v2), effectively refusing to build charm.v6 unless it also depends on yaml.v1 with same revX [10:54] dimitern: you got a build failure in charm.v6 because of a juju/juju tsv file? [10:55] dimitern: if in doubt, choose the latest version of all dependencies [10:55] dimitern: because it's fairly unusual for something to depend on being *earlier* than a certain revision [10:55] rogpeppe, yeah, that's what I usually do - and that works well for repos with merge gating that uses godeps -u as part of testing the merge [10:57] dimitern: one problem is that it's allowed to have cyclic dependencies between repos [10:57] dimitern: at least you had a build failure rather than a bug later on [10:58] rogpeppe, yeah, that's causing some of the issues I suppose [10:58] dimitern: i found that godeps -N eased my pain quite a bit [10:58] rogpeppe, this is the issue I was talking about: https://github.com/juju/bundlechanges/pull/16 [10:58] dimitern: 'cos you can just run it without worrying too much [10:59] rogpeppe, bundlechanges thus far didn't have to depend on yaml.v2, but without it it won't build as charm.v6 needs it [11:00] dimitern: charm.v6 doesn't need it [11:00] dimitern: only its tests do [11:00] dimitern: if you run godeps, it'll tell you that [11:03] rogpeppe, so you're saying that gating job for bundlechanges should've called godeps -u -t dependencies.tsv instead? [11:04] dimitern: i don't understand. that's an invalid godeps command. [11:05] dimitern: the gating job for bundlechanges should always call godeps -u dependencies.tsv as usual [11:06] rogpeppe, the "-t" according to "godeps -h" updates tests deps as well [11:08] dimitern: ah, that's an ambiguity in the help. -t is a no-op with -u. [11:08] dimitern: it only influences whether testing deps are printed without the -u flag. [11:08] dimitern: -u always updates all the deps mentioned [11:11] rogpeppe, ah, didn't know that detail :) thanks [11:12] dimitern: i should probably make the docs clearer [11:16] +1 :) [11:16] * dimitern steps out for ~1h [12:08] who is on-call reviewer? [12:08] =) please review [12:08] https://github.com/juju/utils/pull/199 [12:16] xnox: S390? Mainframe? [12:16] xnox: neat [13:01] dimitern: http://reviews.vapour.ws/r/4002/ should, I hope, be ready. [13:02] * dooferlad goes for lunch [13:02]