[00:12] Bug #1606569 opened: transient "agent is lost"

=== ses is now known as Guest97665 === veebers2 is now known as veebers [01:02] so i should expect to see aws under known cloud types when running juju help add-cloud, yes? [01:04] redir: i think it's "ec2"... [01:05] anastasiamac: tx [01:05] redir: \o/ [01:07] interesting that it's azure:azure but aws:ec2 and google:gce [01:08] so would it be openstack:nova? [01:08] or since it is kind of ec2 compatible woudl it be openstack:ec2 [01:08] anyhow [01:08] naming things [01:14] i like consistency too but this has grown overtime and there is a difference between cloud name and cloud type I guess :) [01:14] veebers: juju mongodb3.2 is in yakkety-release now, so i'd hope it will be picked up by whatever yakkety CI you guys are doing... [01:20] anastasiamac, redir: mark has wanted ec2 to be renamed as aws for some time [01:20] just an FYI [01:20] * redir backs away slowly [01:21] is there an easy way to see what config options are available for the ec2 type? [01:21] easier than grep [01:21] thumper: sounds like it's worthy of a bug then :) it seems to be a simple change on the surface but will probabaly have a big effect :) might b wirthewhile tracking [01:21] and might be a good idea to try to do for 2.0... considering all the breaking changes we already tackkling \o/ [01:38] redir: look at provider/ec2/config.go [01:38] * thumper guesses at the filename [01:38] yeah, pretty much always config.go === natefinch-afk is now known as natefinch [01:41] redir: btw, aws is ec2, because there's also aws-china and aws-gov and there's azure-china [01:42] I guess the type could still be aws with aws and aws-china and aws-gov for cloud names [01:42] works for azure... [01:42] but naming things... [01:43] anyone know if we're getting our help topics back before 2.0 is released? We used to have help for constraints and clouds and any number of other things and they were all removed for some reason [01:44] I saw at a glance it was alpha sorted, but missed ec2... [01:44] of course the first cloud listed under juju clouds was aws [01:44] I just missed the whole type thing [01:45] * redir backs away further, slower [01:45] natefinch: I think I had the issue to remove them my first week on the job. [01:45] ok... have a failing import test written [01:45] so I couldn't tell you much about them. [01:45] I don't understand why those topics were removed [01:45] thumper: w00t [01:45] they were useful [01:47] It was bug #1564017 [01:47] Bug #1564017: 'juju help glossary' and 'juju help topics' are deprecated

[01:48] natefinch: i wanted to talk to u but it must be getting late for u.. do u think we could catch up tomorrow before the standup? [01:49] mayb 30mins before? [01:49] anastasiamac: I'm online for some time yet. Totally willing to talk now if you like. [01:49] natefinch: k. gimme 10 min :) [01:49] 10 minimum [01:49] :) [01:50] lol [02:02] natefinch: ho we've used yesterday? [02:04] anastasiamac: sure [02:05] natefinch: there :) here :) [02:09] axw: yt? [02:10] redir: I am [02:10] got a few minutes for a HO? [02:10] axw: ^^ [02:10] redir: sure, see you in standupo [02:11] k [02:35] tx again axw that was very helpful [02:35] redir: no worries [02:56] thumper: ping? [02:56] menn0: ya? [02:57] opinion required [02:57] I'm full of those :) [02:57] i'm making a change to the migrationmaster so that each instance (for each model) has it's own logger [02:57] so that it's possible to distinguish the activity for each [02:58] it's done but i've realised it's kinda ugly [02:58] right now it's using "juju.worker.migrationmaster:model-uuid" [02:58] which is really long [02:58] for example: [02:58] 2016-07-27 02:56:00 INFO juju.worker.migrationmaster:fcc877db-3451-440b-84f4-0d817000b4b9 worker.go:259 opening API connection to target controller [02:58] what about just: "juju.migration:model-uuid" ? [02:59] what about just: "juju.migration:model-uuid[:6]" ? [02:59] we use the last 6 chars of the uuid for the instance id [02:59] model-uuid[-6:] [02:59] python equivalent [03:00] changing the prefix (juju.worker.migrationmaster) makes it sufficiently different from other workers [03:00] I think that should probably stay the same [03:01] thumper: what about using the model name instead of the UUID? [03:01] * menn0 wonders if they are unique in a given controller [03:01] suspect they are [03:01] 2016-07-27 02:56:00 INFO juju.worker.migrationmaster:00b4b9 worker.go:259 opening API connection to target controller [03:01] how does that look? [03:01] I think the uuid is better [03:01] the models aren't unique [03:02] but namespaced to the owner [03:02] model names that is [03:02] right [03:02] what about: "juju.worker.migrationmaster:owner/name" [03:03] I guess that could get pretty long too [03:03] but at least it's readable... [03:04] consider... [03:04] "juju.worker.migrationmaster:foobar@external/production-foo" [03:05] yeah, I think the UUID is better [03:06] one thing it should probably log first would be owner/name :) [03:06] there is likely to be tooling which extracts the migration logs for a given model [03:06] thumper: that's not a bad idea [03:06] will require some API changes but nothing difficult [03:07] I'm really close to having volume migration done [03:07] just to round out the discussion, what about: [03:07] 00b123:juju.worker.migrationmaster [03:07] will be off line for about an hour shortly as I take Maia and my laptop to her hockey game [03:07] that will have a different base logger [03:08] so not caught with the juju=debug [03:08] logger hierarchy is based on "."s [03:08] thumper: true [03:08] w00t import tests pass [03:08] thumper: on the flip side it makes it easier to filter all the logs for a given model [03:09] juju.00b123.worker.migrationmaster? [03:09] migration.00b123 ? [03:09] really, all of this is a moot point if we had the model specific logs generated on the controller attached to the correct model when the logs are recorded [03:10] but we haven't quite figured that out [03:10] which would be WAY nicer if we had one 64 bit int as the primary key [03:10] rather than a futzing UUID [03:10] yep yep [03:11] IMO the best idea is not to munge the log heirarchy but give another dimension on which users can filter [03:11] menn0: hmm... $ git diff master | wc -l [03:11] 1492 [03:11] and a few more tests to write for migration_internal_test.go [03:12] natefinch: we have that (debug-log only shows you the logs for the model you're connected to) [03:12] natefinch: it just doesn't work well for model-specific workers which run in the controller [03:12] natefinch: if we did that right then none of this would matter [03:13] I'm going to raise this at the tech board meeting [03:13] menn0: then let's do that right ;) [03:13] natefinch: that's what I intend to raise at the meeting - doing it right [03:13] it might not even be that hard [03:13] I do think we should store some unique DB integer keys for models [03:13] and store those against the logs [03:14] and translate as necessary [03:14] less junk in the db [03:14] rather than storing perhaps two different uuids for every log line [03:14] thumper: to save space? probably [03:14] and faster queries [03:14] integer comparison is faster than string comparison [03:15] we did that at my last job... the real IDs were UUIDs, but there was a translation table to ints to save memory (we had millions of items in memory)... they are also more user friendly when counts are small [03:15] * thumper nods [03:15] thumper: file a ticket! [03:15] ha [03:15] menn0: I'm offline for a bit, but taking laptop to write more tests [03:15] volumes should be good to go when I get back [03:16] thumper: that's great news [03:16] now to do all the same shit with filesystems [03:16] hazaah [03:17] mwhudson: re: yakkity/mongo sweet thanks, I'll make sure that's passed on to the team [03:23] quick review anyone? Fixing windows by adding ciphersuites it actually supports: http://reviews.vapour.ws/r/5307/ [03:25] (it's two lines and a comment) [04:05] axw, menn0: pretty sure I have everything for migrating volumes - http://reviews.vapour.ws/r/5310/ [04:05] menn0: when we are both back, I'd like to chat about the bootstrap and upload tools issue [04:52] menn0: ping [04:52] thumper: pong [04:52] thumper: 1:1? [04:52] menn0: quick hangout? [04:52] yeah === frankban|afk is now known as frankban [08:00] axw, fwereade__: tech board? [08:00] menn0: coming [08:29] axw, you still here? [08:29] balloons: sure am [08:29] axw, I wanted to chat with you about your MP [08:30] balloons: sounds good. here or hangout? [08:31] axw, sure, let's do a hangout [08:55] balloons: there is a bug with "juju register". easy to fix, just adding a test for it now. [08:56] axw, ahh brillant. So indeed there's a bug [08:56] sorry I didn't file something specific for this [08:56] balloons: if you added a user with access to exactly one model, register would try to switch to it but failed to qualify its name [08:56] balloons: np [08:57] axw, right. When you talked about switching models, I had thought register did that for you [08:57] and that's how your change caused the issue :-) [08:57] balloons: only when you have exactly one, which I didn't when I tested [08:57] the world makes sense again [08:57] balloons: :) [08:58] frobware: Is it possible to install maas1.9 on xenial? Or do I need to make a trusty vm? [09:01] frobware: Ignore me, worked it out. [09:05] axw, so there's an MP that already moves that function to jujupy [09:06] balloons: which what? [09:06] axw, https://code.launchpad.net/~nealpzhang/juju-ci-tools/assess_multi_users/+merge/299463 [09:07] babbageclunk: you need trusty [09:07] frobware: Yeah - I see that there's no xenial in the stable ppa. [09:08] axw, so you can kind of see how it would work. You need a EnvJujuClient2B14 that inherits EnvJujuClient2 and overrides that func [09:08] frobware: Do you know if the trusty version of cloud-init needs your hack to the image? [09:08] babbageclunk: remind me which one :-D [09:09] frobware: The one to let it bring up the network when there's no dhcp. [09:09] babbageclunk: HO? [09:09] frobware: sure - which one? [09:10] frobware: https://hangouts.google.com/hangouts/_/canonical.com/standup?hl=en&authuser=1 [09:10] axw, it also looks like the code change could be made easier -- you can pass the model name to clone [09:19] frobware dooferlad: I have a more complete (albeit ugly) work-around for this ip addr sorting issue. Is either of you available for a quick HO to discuss? [09:20] frobware, macgreagoir: give me two minutes then I can. [09:20] macgreagoir: otp with babbageclunk :) [09:21] I'll let y'all ping me when ready, cheers :-) [09:22] Bug #1597941 changed: juju2.0beta10: websockets API usability Application Deploy failure to inform of required addCharm pre-requisite <2.0>

[09:23] macgreagoir: back [09:23] dooferlad: stand-up HO? [09:24] macgreagoir: https://hangouts.google.com/hangouts/_/canonical.com/james-mick ? [09:24] macgreagoir: we can put anything after canonical.com it seems [09:26] balloons: doh, thanks for that. that other MP will need to be updated too. [09:27] axw, if you want to redo your MP with that as a base, I'm approving it to land, so they can both go [09:27] balloons: okey dokey [09:33] axw, would you like a bug for the register issue? [09:33] balloons: do you want to go ahead and land that other MP? I'll need to retest, and also update the other new tests and test htem with my juju PR [09:33] axw, I was going to let Leo do it when he awakes in a few hours [09:33] balloons: don't worry about the bug, I'm on it and it's not on master anyway. [09:33] axw, do you need it before then? If so, that might be possible [09:33] balloons: ok, no worries [09:34] balloons: I'll just merge and work off his commit [09:34] rev [09:34] right, i asked him to remove a comment, but I don't think you should have a bunch of conflicts remerging trunk when it's in :-) [09:35] axw, I am curious though -- did the grant revoke test pass with your changes to the test itself? [09:35] axw, it should still have exposed the register bug -- did it not? [09:35] balloons: it did not [09:35] balloons: which is curious... [09:36] axw, any thoughts on why not? That would be useful to make sure it's caught [09:36] the manual test is very similar to what it's doing -- I'm not sure how it worked [09:37] axw, perhaps you can tweak assert_read_model to add some additional asserts? [09:37] balloons: yep, will look into it [09:38] axw, sorry for the scope creep, but we do want to make sure we have coverage :-) [09:38] balloons: no worries [09:53] balloons: actually leo's branch works with my juju PR without any further changes. I think because the API methods being used to verify read/write access [09:54] axw ohh really? [10:01] Bug #1605986 opened: Creating container: can't get info for image 'ubuntu-trusty'

[10:27] balloons: so to answer your question about why it wasn't failing: the test wasn't checking the exit status of the "juju register" pexpect process. register is failing right at the end, when it goes to set the current model. so the controller is set up, and further commands succeed because they're specifying a model with "-m" [11:13] frobware: bug 1585878 - does it affect maas 1.9 as well? [11:13] Bug #1585878: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <2.0>

[11:14] babbageclunk: I would expect it to if we don't issue calls to release when we do $(juju remove-machine 0/lxd/0). [11:15] frobware: I can't see the device allocated anywhere [12:00] babbageclunk: sorry, was otp. [12:02] frobware: no worries - worked it out - it was the version of my code where I'd added a method to the interface but hadn't added it to the impls yet, so no providers would allocate container addresses. [12:18] frobware: just noticed that the vsphere provider tries to implement the Networking interface but doesn't. Do you think I should add the other missing methods (Spaces, SupportsSpaceDiscovery) with stub implementations as well as adding ReleaseContainerAddresses? [12:28] babbageclunk: raise a bug for this. at the very least track it as an independent change. [12:29] frobware: ok [12:29] babbageclunk: discrete fixes are easy and trivial to revert -- should the need arise. And cherry-pick too. [12:29] frobware: you mean do it in a separate commit? Or in a separate PR? [12:30] babbageclunk: bug + separate PR. your change should be so trivial and obvious and discrete that it's a no-brainer to accept it. :) [12:30] ok cool [12:30] thanks [12:38] frobware: This whole area seems weird - there are providers for which SupportsNetworking returns true (and they implement the Networking interface) but the method implementations return errors.NotSupportedf. Why is this one interface? [12:40] frobware: I'm putting arch notes to this effect in commits. [12:59] Bug #1606917 opened: vsphere provider is missing some Networking methods [13:05] Bug #1600301 changed: cmd/jujud/agent MachineSuite.TestHostedModelWorkers fails because compute-provisioner never really starts

[13:33] macgreagoir: per or HO earlier... any chance you could try this: http://pastebin.ubuntu.com/21139080/ [13:33] macgreagoir: will look at the LXD / eth.cfg / cloud-init fix now [13:35] Bug #1606922 opened: private-address isn't updated on machine reboot [13:36] frobware: ack [13:36] macgreagoir: https://bugs.launchpad.net/juju-core/+bug/1602054/comments/14 [13:36] Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <2.0>

[13:37] macgreagoir: tree is here: https://github.com/frobware/juju/tree/master-lp1602054 [14:02] natefinch: standup? [14:05] Bug #1606939 opened: UNIQUE constraint failed

[15:22] ahhh.. roger that. i'm VM'd. i heard of people trying ubuntu native on the 2014 macbooks, but had problems with wifi and screen resolution, so i never went down that road. only guy i know with native ubuntu on a mac is curtis. [15:23] damn wrong channel :/ [15:46] can someone else TAL at http://reviews.vapour.ws/r/5305 ? i feel like i'm missing something and i'm not comfortable landing it [15:46] it's a very short review [15:47] natefinch: perrito666: frobware: et. al: ^^^ [15:48] checking [15:48] perrito666: ta [15:48] * perrito666 finally has internet [15:48] glorious 6Mdown 1Mup [15:48] :) [15:49] perrito666: btw thanks for your help yesterday. i was actually able to write a script to connect to mongo from outside the lxc container [15:49] katco: niice, care to share ? [15:49] perrito666: which is a huge relief! no more worrying about adding packages from within the container [15:49] perrito666: yeah i'll send it out to the list [16:14] katco: the diff from fwereade seems to break something else, I added a comment [16:14] perrito666: k tal [16:16] perrito666: if i'm reading that code correctly, doesn't the loop remove directories? so prior to fwereade's change, it would have deleted everything *except* for backups? [16:17] ah I see that is poc [16:18] poc? [16:18] not something I can say in front of children [16:18] so, the previous iteration would keep everything but backups, but done in the most awful way possible [16:19] it would loop over ignored list but do nothing unless one of those was backups [16:19] the new code will do the same, buut, I missed a part, and he is right, yes that code can land, despite how disgusting it is, it is a bit less so than theprevious one [16:22] oh i see, i inverted the test case [16:22] wow that is weird code [16:22] katco: there, I added a coment [16:23] katco: I presume it was done to "in the future we can expand this already complicated code with bleh" mindset, something that happens too often in backups [16:23] restore instead is mostly writen with "they asked me to quick patch this as restore is being replaced rsn" [16:25] lol yeah [16:25] perrito666: btw sent that script out [16:28] * katco goes for a walk [16:35] Bug #1606991 opened: TestWaitMinionNeverBecomeMinion wrong minion

[16:44] Bug #1606991 changed: TestWaitMinionNeverBecomeMinion wrong minion

[16:51] frobware: quick review please? https://github.com/juju/gomaasapi/pull/55 [16:54] babbageclunk: should Devices() return a copy or the pointers/refs? [16:56] frobware: Yeah, I wondered that - I followed the example of .Nodes(). It's more powerful, and since it's a test server returning the actual thing seemed ok. [16:59] Bug #1606991 opened: TestWaitMinionNeverBecomeMinion wrong minion

[17:01] babbageclunk: before continuing would like to understand the rationale for not returning copies. [17:04] frobware: I did that for consistency with the other similar methods (Nodes, Files, OwnedNodes, IPAddresses). I don't need it in this case, but it's conceivable that a future test might. [17:05] babbageclunk: just wondering if it makes test code brittle w.r.t. things changing underneath you [17:06] frobware: Not sure whether it's obvious, but only the tests use those methods - the live code only interacts with the server over HTTP. [17:06] babbageclunk: so the immediate question... why does it need exporting? [17:07] frobware: So that the test that I'm writing (for ReleaseContainerAddresses) can monkey with the devices to set them up. [17:07] babbageclunk: ah, I see [17:07] frobware: (Sorry, should probably put that on the PR.) [17:10] frobware: Added it. [17:17] * babbageclunk should be home already, whoops bye! [17:35] Bug #1607000 opened: Immortal zombie Juju controller on MAAS

[19:36] Bug #1607044 changed: WorkerSuite.TestUpdatesAfterPeriod timed out

[19:42] Bug #1607044 opened: WorkerSuite.TestUpdatesAfterPeriod timed out

[20:18] anyone seen a problem where c.Mkdir panics on windows? [20:19] nvm, looks like it's just cruft left from an earlier run... but evidently the random number generator on windows always produces the same random string for gocheck's mkdir [20:19] which uh... makes it somewhat less useful [20:25] Anyone know when Dimiter is off vacation? He wanted me to talk to him at Gophercon, but I wasn't able to catch him. [20:26] bodie__: no clue, sorry [20:26] bodie_: he was back, but is currently at a sprint. he should be back next week [20:26] Thanks katco :) [20:26] bodie__: hth === natefinch is now known as natefinch-afk [21:14] hmm... [21:14] bootstrapping lxd and having that feeling that it won't start because my squid-deb-proxy is not up to date... [21:14] * thumper waits to see [21:24] thumper: thanks for helping troubleshoot https://bugs.launchpad.net/landscape-client/+bug/1605002 [21:25] ahasenack: no worries [21:25] was the subordinate hook staying running? [21:25] thumper: it was your comment about the subordinate apparently still doing stuff, and the "machine lock", that lead me in the right direction [21:25] thumper: it was hung, like in an infinite loop [21:25] right [21:25] it got me thinking about how to surface that [21:25] so it was running according to juju, but not doing a thing really [21:25] if a hook has been running for a "long" time [21:25] we should highight somehow [21:26] highlight [21:26] yeah, don't know [21:26] timeouts are tricky [21:27] * thumper nods [21:38] redir: nice catch on my dumb test failure... embarassing [21:38] go test caught it [21:39] menn0: ^ [21:39] redir: I changed from using the full UUID to using the suffix and forgot to re-run the tests [21:39] figured that or it was a WIP [21:43] bdx [21:43] bdx [21:50] bdx: are you a pokemon? [21:50] ok buck [21:53] omg lol [21:53] whoops [21:54] must be [21:57]