[01:30] it is right about now I want a debugger with local variable introspection [01:31] thumper: use PyCharm :-D [01:31] for golang? [01:31] yup [01:31] has debugging? [01:31] yup [01:31] since when? [01:31] ages [01:31] you use a golang plugin [01:32] but... but... PyCharm [01:32] any of the IDEs work [01:32] IntelliJ etc [01:32] but i like PyCharm so I can also open the Python juju client etc [01:32] they all use the same plugin [01:33] i don't think the offical plugin has all the features, i use one that's in development which will become offical [01:33] jetbrains took it over [01:34] axw: i have to head out to take kid to movie theatre, bbiab [01:34] wallyworld: sure, I'm half way through your review [01:36] i owe you a beer :-( === natefinch-afk is now known as natefinch [01:51] ericsnow: you around? [02:17] thumper: https://github.com/juju/juju/pull/4212 [02:17] ugly ass backport to 1.25 [02:18] needs a lot of testing as I had to bump the version of juju/utils to pick up dependencies of the juju/juju/testing package which the state/leadership tests use [02:20] ugh [02:20] reviweed [03:06] fuck-a-doodle [03:06] * thumper bangs his head on the desk [03:06] just figuratively [03:10] oh FFS [03:10] * thumper takes a deep breath and dives into the code again [03:22] um [03:22] % juju bootstrap --bootstrap-series=precise --upload-tools -v [03:22] error: flag provided but not defined: --bootstrap-series [03:22] how am I supposed to test 1.25 when it doens't understand this flag ... [03:23] what's olde english for --boostrap-series [03:23] --series? [03:23] i'll try it ? [03:23] i'll try it [03:24] also, juju help bootstrap ;) [03:24] lucky(~/src/github.com/juju/juju) % juju bootstrap --series=precise --upload-tools -v [03:24] Use of --series is obsolete. --upload-tools now expands to all supported series of the same operating system. [03:24] WARNING ignoring environments.yaml: using bootstrap config in file "" [03:24] WARNING This juju environment is already bootstrapped. If you want to start a new Juju [03:24] environment, first run juju destroy-environment to clean up, or switch to an [03:24] alternative environment. [03:24] ERROR environment is already bootstrapped [03:25] ^ that is a lie [03:25] juju destroy-environment foo --force -y [03:25] already bootstrapped sometimes means "last bootstrapped failed and we didn't clean up enough" :/ === urulama__ is now known as urulama [03:32] thumper: did you find the details about the juju/txn bug we talked about at standup [03:32] i'd like to look into that as a priority [03:32] 'cos that is horrible [03:35] no, sorry [03:37] :( [03:43] wow, 1.25 is old [03:43] no --format short [03:45] davechen1y: juju/txn ErrExcessiveContention [03:45] davechen1y: there was never a way to specify series for just the bootstrap machine before. you had to set preferred-series in environments.yaml [03:45] that's the one [03:45] axw: ahh [03:45] txn.go line 151 [03:46] yeah, i know that [03:46] so we said at standup that error X is happening, which doesn't match any of the preconditions, so the errror is replaced by ErrExcessiveContention [03:47] ok, i was wrong juju status --format short is implemented [03:47] but returns nothing if you have no machines deployed [03:47] which makes sense in a "thanks, that didn't help" way [03:48] heh [03:49] thumper: can you find the fix that you landed last time this happened ? [03:49] which i imagine probably jiggled a transaction operation to not do something [03:50] let me take a quick look [03:50] ta [04:05] thumper: fix confirmed, submitting http://reviews.vapour.ws/r/3645/ [04:16] ok [04:16] quick look doesn't find it I'm afraid [04:18] davechen1y: my test tear down is failing saying I have dirty sockets... [04:19] davechen1y: after more looking, I can't see what's going on [04:19] any hints on how to debug this? [04:21] thumper: linkage [04:21] wat? [04:21] link for some text of what you are seeing [04:21] please [04:22] davechen1y: http://paste.ubuntu.com/14676889/ [04:23] ta [04:23] thumper: normally whent hat happens mongo has crapped itself waaaaaya up in the piece [04:25] yeah, but only running one test [04:25] and it is recurring [04:25] so I'm guessing it is me [04:25] off [04:25] odd [04:26] normally this is when you forget to close something [04:26] i've always seen that in big test runs when mongo poops itself and this is just the aftershock of every suite setup and tear down [04:26] but I have the defer close [04:26] failing [04:37] hmm... logging is getting me places... slowly [04:50] thumper: this merge gets worse and worse [04:50] 'cos juju/juju/testing needs a newer version of juju/utils, had to update that [04:50] and juju/utils needs yaml.v2 [04:51] this is like the story about needing a nail to fix a horse shoe [04:51] to get a penny [04:51] to buy some milk [04:51] to feed a pig [04:51] to ride on sunday [04:52] well, at least you can see your journey... [04:53] my test is being torn down while running [04:53] beat that [04:53] I mean, WTF? [04:54] davechen1y: right now I have *no* clue as to what's going on [04:54] push it to a branch [04:54] i'll take a look [04:55] pushing [04:57] this is (one of the reasons) why dumping a bunch of unrelated crap into juju/utils is a terrible idea. If it was all separate repos, you could just update the one you need, and not update everything else. [04:59] davechen1y: https://github.com/howbazaar/juju/tree/migrate-machines [05:00] davechen1y: although I'm pretty much done... [05:00] davechen1y: let me point you at a few things: [05:01] state/migration_import_test.go line 185 [05:01] that line is never reached in the test [05:01] state/migration_import.go line 142, both the possible return places have logging, neither happens === akhavr1 is now known as akhavr [05:02] I get: [LOG] 0:00.255 DEBUG juju.state.import-model importing machine 0 [05:02] START: :784: MigrationImportSuite.TearDownTest [05:02] [LOG] 0:00.255 DEBUG juju.state closed state without error [05:03] no test assertion failed AFAICT [05:03] just start of tear down [05:03] it would be great if you figured this out, but I'm going to sleep on it [05:03] laters === blahdeblah_ is now known as blahdeblah [08:58] dooferlad, running 10 mins late... [08:59] frobware: ack [09:11] dooferlad, back... [09:12] frobware: see in in a sec then [09:22] wallyworld: I just submitted bug #1538462 about "juju bootstrap --debug" containing a lot of simplestreams "garbage" [09:22] Bug #1538462: simplestreams debug content is useless (juju bootstrap --debug)

[09:22] specifically, it is serializing something and putting just the pointer content into the log [09:23] 20130404:0xc8201f1e00 20130423:0xc8201f1ec0 20131123:0xc82040c0c0 20130313:0xc8201f16e0 20131022:0xc8201f18c0 20130928:0xc8201f1980 [09:23] is not particularly useful for anyone [09:40] Bug #1538462 opened: simplestreams debug content is useless (juju bootstrap --debug)

[09:50] frobware: dimitern: I got roped into a phone call for a client, so I won't be able to make standup today. [09:51] jam: ack [09:52] dimitern, do you have an /e/n/i I could look at from your IPv6 setup? [09:58] jam, np [09:58] frobware, not right now, but I can get one [09:59] dimitern, not desperately urgent [10:02] dimitern, voidspace: standup [10:03] sorry, omw [10:30] frobware, I'm typing in the HO chat [10:38] dimitern: we said don't do the hack with a yaml setting and take a couple of days to do it properly [10:38] dimitern, I'm confused about the proposed PR/change for default. [10:39] dimitern, are we going for a change that does NOT require a yaml addition? [10:40] frobware, voidspace, ok, let me think for a bit to see what are the options [10:40] and then we can decide? [10:41] dimitern, thanks. we need to convey our plans to cheryl too [10:42] wallyworld: https://github.com/juju/juju/compare/cloud-credentials...axw:cloud-credentials-prepareforbootstrapparams -- all tests pass, but I want to do some live tests and audit code before I propose it (tomorrow) [10:42] wallyworld: if you want to look before then, I don't expect too much will change [10:43] axw: ok, will do [11:41] frobware, I think I have a good plan for a "proper" fix [11:41] dimitern, great! [11:41] jam: hey, you still online? what are your issues with splitting config and dat directories? [11:42] here's the gist of it: http://paste.ubuntu.com/14678495/ [11:42] dimitern, want to HO to discuss? I can act as a sounding board. [11:42] wallyworld: I don't have a huge problem with it, I don't know that it actually provides clarity rather than just complexity, though. [11:42] frobware, I need to go out now, but let's chat when I'm back in <1h [11:42] wallyworld: the data we have I wouldn't put into /usr/share, for example [11:42] dimitern, ok, but probably after that as I have a couple of back-2-back meetings. [11:42] its not that kind of dataa [11:42] frobware, np [11:43] jam: it keeps pure config data that the user can and should look at and edit separate from stuff they should not edit lest the stuff things up. and it conforms to a standard [11:43] sure not in /usr/share but ~/config/juju for clouds and credentials [11:43] and the data dir for controller cache and other runtime stuff users should not see [11:44] we don't want to put in their faces files they are not expected to look at [11:44] we tell them - anything in ~/.config/juju you can edit and look at [11:44] that makes it easy for them [11:46] wallyworld: so can you link the actual "this is where you should put file X" stuff? The actual XDG spec just says what the variables are, but not how to pick which one [11:47] jam: i don't have the link, but perrito666 probably does [11:48] wallyworld: so there are a couple of articles on "ploum.net" that talk about this, but actually his notes seem to say everything should be in DATA [11:48] as they aren't just "preferences that can be reset" [11:48] everything in data makes no sense [11:49] clouds and credentials etc are definitely config [11:49] https://ploum.net/184-cleaning-user-preferences-keeping-user-data [11:49] wallyworld: credentials are critical information about remote systems [11:49] not just simple config [11:49] as in, if I lose them, I'm hosed [11:49] vs "I want tabular by default" is config [11:50] the pluom article at least says that you should be able to wipe config and start fresh with default settings [11:51] and that is *not* true of credentials [11:51] so perhaps the new jenv type stuff should go in "" not data [11:52] i'll discuss it some more [11:53] wallyworld: runtime is for "non-essential runtime files such as sockets and named-pipes" [11:53] and the lifetime of RUNTIME is bound to the logged in user [11:53] definitely not what we want [11:53] logging out shouldn't reset your credentials :) [11:53] so there be some way of separating user editable stuff from juju stuff [11:54] wallyworld: if users are vim ~/*/juju we've probably failed our CLI UX [11:54] as in, there may be thing they *could* edit, but we'd really be better off not suggesting they edit anything [11:54] (vim is not typesafe) [11:54] they need to poentially edit their personal clouds.yaml [11:54] wallyworld: we should provide CLI ways to describe a cloud instead [11:55] wallyworld: vim won't do syntax checking that the information they type is valid [11:56] the spec has an add-cloud command that assumes that a clouds.yaml exists already. we could allow it to be edited using a schema like we will for credentials [11:57] that article does make a point that i hadn't considered [11:58] I can't say pluom is authoritative, but the XDG spec tells you *what* the variables are, but not why to use them (at least that I've fonud) [12:00] +1 to that [12:01] ok, we'll look to see how using will turn out, and treat stuff there as needing to be persistent [13:03] fwereade, ping [13:16] morning [13:44] dimitern: you might like this new proposed addition to juju/utils: https://github.com/juju/utils/pull/193/files [14:35] rogpeppe1, looks nice :) [14:35] dimitern: thanks :) [14:36] rogpeppe1, I have a growing number of things to add to juju/utils .. in my abundant free time :) [14:36] dimitern: :) [14:36] dimitern: tbh i think we should split it up [14:36] rogpeppe1, subpackages or subrepos? [14:37] dimitern: subpackages [14:37] rogpeppe1, +100 [14:38] dimitern: and it's somewhat criminal that importing juju/utils side-effects http.DefaultClient [14:39] rogpeppe1, oh.. GetNonValidating.. ? [14:39] dimitern: no, grep 'func init' [14:40] rogpeppe1, ah, right :/ [14:41] dimitern, dooferlad, voidspace: http://reviews.vapour.ws/r/3648/ -- will do more manual testing, and testing with stakeholders before merging. but a review would help move that forward. [14:46] frobware, is this the same script as in master? [14:47] dimitern, yep [14:47] dimitern, should be 100% identical. the control happens via cli args. [14:47] frobware, this line: self.is_active = self.method == "dhcp" or self.method == "static" [14:48] frobware, reminded me of that case where we have a auto eth0 but manual, which has active, static vlan children [14:48] frobware, did we do anything about that? [14:49] dimitern, do you have a node to hand that boots with that config? [14:51] frobware, not now, but IIRC thedac had to deal with something similar in dellstack [15:01] dimitern, that case was covered by https://github.com/juju/juju/pull/4148 [15:02] Bug #1538583 opened: manual provider add-machine failed in api-command-rename

[15:02] Bug #1538589 opened: Container has different subnet

[15:03] frobware, right! so we're good then - LGTM I think [15:09] cherylj, can we get a CI build for #1532167 https://github.com/frobware/juju/tree/1.25-lp1532167 [15:09] Bug #1532167: maas bridge script handles VLAN NICs incorrectly

[15:10] abentley, mgz, can we get a CI run on frobware's branch ^^? [15:10] this is the one that backports the maas-spaces script to 1.25 [15:11] cherylj: I'll push it into the juju namespace [15:11] mgz: thanks! [15:50] frobware, can you have a look at this org draft - http://paste.ubuntu.com/14679880/ [15:51] frobware, so it came down to a few more things than I originally thought [15:51] dimitern, certainly looks like it. [15:51] frobware, I can still probably do it by standup time tomorrow, but not today [15:52] dimitern, sure. it's important we get it right. [15:52] * voidspace reading [15:52] voidspace, dooferlad, please have a look as well ^^ [15:52] dimitern: so for maas now the juju user has to tell us what space they want as default (effectively)? [15:53] dimitern: what about blake's suggestion - bootstrap without constraint and then pick as default the space that we bootstrap to? [15:53] to me this looks more complex than we *need*, but I'm digesting it properly [15:53] *still* digesting it properly [15:54] voidspace, the idea is to use environ constraints for the default, but also (in maas) discover and save the name in state for use in unspec. bindings later [15:54] voidspace, so it includes what we discussed with blake [15:55] voidspace, i.e. I think this is the "proper way" to do it, and it's not maas specific [15:55] dimitern: why do we *need* a different default space and controller space specifications [15:55] dimitern: can't we initially have just a default one [15:56] dimitern: or is that just for where controller and specified default *are* different [15:57] voidspace, they need to be distinct in the general case, as the controller "space" is more like a set of addresses from possibly different subnets in different spaces [15:57] hmm, doesn't sound like a space at all [15:57] voidspace, but in the default path, we'll set them to be the same in maas (when you don't give us anything specific) [15:58] voidspace, it's a space with no subnets, just addresses [15:58] voidspace, well, we can "invent" subnets like 10.20.30.44/32 strictly speaking [15:58] dimitern: according to our network model that *isn't* a space, and it would probably be less confusing if we didn't call it a space [15:58] but that's only internally in juju [15:59] dimitern: my problem with it is that you are asking the user for information they may not have, and don't need. [15:59] you can, at bootstrap, just get a machine and see what spaces it is in once it has been provisioned (as Blake suggested) [15:59] voidspace, no, we're not :) we're doing what the user said, if they did - otherwise we pick a sane default (at bootstrap) for both names [16:00] for maas, network.DefaultSpace is not necessarily a sane default [16:04] dimitern: if controller space isn't a real space, what's the use case for setting it to a real space? (and your doc says it must be a real space) [16:04] dimitern: what I'm really trying to say is that I don't understand why we need controller space and what it's for [16:04] does anyone know where the new account/creds stuff is documented? We want to show juju 2.0 to people at the charm summit but we can't seem to find the docs about like credentials.yaml and friends [16:04] dimitern: and I still don't think we need it [16:05] voidspace, because it may very well be a real space, dedicated for juju controllers only, and the user has configured it so it can be accessed from all other spaces [16:05] dimitern: the only place your doc mentions it being used is for selecting API endpooints [16:05] and know what they are doing [16:06] voidspace, that's what we need it for [16:07] your implementation as described *requires* it to be a real space (we always set it to something), whereas above you stated that it was really just a list of endpoints possibly in different spaces [16:07] dimitern: the implementation you describe in your doc doesn't permit that - it *must* be a real space [16:09] surely the only thing we *need* to overcome the existing problem is as follows (I may be wrong): [16:09] set the juju "default space" to the space from the primary nic of machine-0 [16:10] if the user wants to specify a default space they can, for the moment, specify that space as a bootstrap constraint [16:10] later on we can add a default space setting [16:13] the setting is need to store it [16:13] but it can be just in state, not in env.yaml [16:13] dimitern: right [16:13] dimitern: we need to store it [16:26] Bug #1538589 changed: Container has different subnet

[16:29] Bug #1538589 opened: Container has different subnet

[16:32] Bug #1538589 changed: Container has different subnet

[16:35] Bug #1538589 opened: Container has different subnet

[16:38] Bug #1538589 changed: Container has different subnet

[16:42] could anyone ptal http://reviews.vapour.ws/r/3634/ ? [16:43] katco, ericsnow: I have to pick up my daughter from school right when our meeting is starting today... can we start 15 minutes late? We could meet for a while beforehand, if you think we might run out of time. [16:43] natefinch: as long as you're available until the meeting is over, that's fine [16:43] natefinch: i don't anticipate this one running long [16:43] katco: ok [16:45] katco: oh, uh, I just noticed it runs through 5:30... I really kind of have to stop at 5 so I can make dinner for the kids. [16:45] natefinch: then we should start on time [16:45] katco: ok, I'll work it out. [16:45] natefinch: i can move it up a little as well if that works for ericsnow [16:46] katco: fine with me [16:46] natefinch: but that puts you leaving in the middle of it? [16:53] natefinch: well, just let me know what works for you. [16:56] Bug #1538652 opened: MAAS doesn't assign DHCP IP to new Node and doesn't update DNS table

[17:00] katco: I'll just pick up my daughter early, if I can be done at 5. [17:01] natefinch: moved it up. we should be done by 5 [17:02] Bug #1538652 changed: MAAS doesn't assign DHCP IP to new Node and doesn't update DNS table

[17:05] katco: sorry, I think I misunderstood. I was going to pick her up early to make the 2:30 time.... is there a way we can do an hour now-ish and 2 hours from 3-5 my time? I'm trying to avoid having to pick her up 45 minutes early from school. [17:06] natefinch: have you guys figured out resource-get? [17:06] katco: yeah, lemme give it one last test [17:08] Bug #1538652 opened: MAAS doesn't assign DHCP IP to new Node and doesn't update DNS table

[17:41] is there a way to force an update-status hook to get fired? [17:45] hey! it worked [17:46] \o/ [17:49] it works better when you don't forget you git stashed your previous bugfix [17:59] katco: can we meet for an hour now? [18:00] natefinch: sorry, i need to run some errands over lunch for the trip [18:00] natefinch: this is why things go on the calendar [18:01] natefinch: bbiab [18:38] frobware: dooferlad: the good news is that *only* the maas deploy tests are failing for maas-spaces now: http://reports.vapour.ws/releases/3546 [18:40] natefinch: ok back. so do you want me to put the meeting back to the original time? [18:50] ericsnow: i'm going to push the iteration planning back to its original time. i think natefinch is probably picking up his kiddo atm. [18:50] katco: k [18:59] katco: I'm here [18:59] natefinch: k, let's do this [19:00] ericsnow: going now after all [19:00] katco: k [19:54] cherylj: ping [20:00] perrito666: pong [20:16] cherylj: I have been assigned to https://bugs.launchpad.net/juju-core/+bug/1472711 and there is mention of work you are doing and I recall ian telling me too that you where doing work on this and that I was to help you [20:16] Bug #1472711: MAAS node has "failed deployment", juju just says "pending" when using juju add-machine

[20:17] perrito666: give me a minute, on a stand up. I'll let you know what's up with that :) [20:17] thank you [20:30] sinzui: why do pull requestest for machine-dep-engine keep getting opened and quickly closed? [20:32] thumper: because this is the bot https://www.youtube.com/watch?v=Z86V_ICUCD4 [20:39] Bug #1538735 opened: default-series breaks --bootstrap-series