[00:34] thumper: ship it [00:35] this is another examples of the code being adapted to fit the shoe [00:35] s/shoe/tests [00:35] in that example the test code _relied_ on the valye written into the apiInfo being localhost:nnnn [00:35] although in practice [00:36] 1. apiinfo's retried from jenv end config files never pointed to the localhost [00:36] 2. and even if they did point to localhost, they are always ip addresses, not the word "localhost [01:00] thumper: // Check that the returned environ is still the same. [01:00] env = obs.Environ() [01:00] c.Assert(env.Config().AllAttrs(), jc.DeepEquals, originalConfig.AllAttrs()) [01:00] this test will always pass because originalconfig is the same refernce returned by obs.Environ().Config() [01:45] wallyworld: I haven't been following the custom image metadata bug, but I just had a look and there is code to store custom image metadata in state already [01:45] wallyworld: it may not be working, but it is there... [01:46] axw: where is that code? [01:46] wallyworld: it's a bit different to the tools metadata. the simplestreams files just get stored in the env storage verbatim [01:46] wallyworld: one sec [01:46] wallyworld: cmd/jujud/bootstrap.go, storeCustomImageMetadata [01:46] axw: yes, there is code to put it in env storage [01:46] let me look [01:46] wallyworld: I suppose I consider env storage part of state now. [01:47] wallyworld: anyway, the image lookup code is meant to look in env storage as one of the sources [01:48] wallyworld: during bootstrap, we marshal whatever's in the --metadata-source directory through the ssh-init script, store it on disk on the bootstrap machine and point "jujud bootstrap" at it [01:49] wallyworld: I'm *fairly* sure I tested it when I did it, so possibly something has broken since it was first done [01:50] axw: yeah, for some reason that storage doesn't seem to be on the search path. i wasn't aware that we were putting the metadata on the root disk [01:51] i *think* adding it to a collection in state is the right thing to do [01:51] abstracts from simplestreams like for tools [01:51] wallyworld: I think there was a reason at the time, I don't recall though :/ [01:51] maybe it was just to get it done quickly [01:52] that is likely correct [01:52] wallyworld: if it's going to be changed again, whatever's in env storage should be migrated out [01:52] axw: yeah, although if it doesn't work anyway.... [01:53] but we should import [01:53] wallyworld: whether or not it's being searched, the data may be there [01:53] yep [01:56] anastasiamac: ^^ you might want to read up [01:56] we can continue on the current path and do the import after [01:56] anastasiamac: there's some code in bootstrap already that you should be able to make use of to marshal custom image metadata [01:57] axw: :) [01:57] axw: tyvm [01:58] wallyworld: sounds fine. I just wanted to clarify that it was actually done, it's just broken. since all that's changing really is moving from unstructured to stuctured format, we'll still need to determine what's wrong with the existing code [01:59] axw: thank you, i didn't realise we had done the work [01:59] wallyworld: nps, didn't tweak until I went and looked at the code :) [02:00] twig even [02:00] i didn't know there was code to look at :-) [02:09] thumper: menn0 https://github.com/juju/juju/pull/2652 [02:09] please review critically [02:11] Bug #1468579 opened: juju bootstrap failed - cannot dial mongo to initiate replicaset: no reachable servers

[02:14] davecheney: done [02:15] * thumper is building a utopic lxc container to test bug 1468365 [02:15] Bug #1468365: internal compiler error: fault

[02:15] thumper: it would be faster to build go 1.3.3 from source instead [02:16] :) [02:16] My machine now has go 1.4.2 due to lxc/lxd ppa [02:16] also 1.3.3 is not supported [02:16] so any fix will land in 1.5 [02:16] assuming it isn't aleady fixed in 1.4.2 [02:17] Bug #1468581 opened: juju bootstrap fails - Waiting for API to become available ERROR cannot get all blocks: EOF

[02:23] * menn0 has to do the kindy run [02:24] thumper: I also remove a shitload of locking in the mock that was not needed [02:24] initially it was there becayuse the testing stub thing was not concurrent safe [02:24] but I fixed that a while back [02:24] so those locks were just causing deadlocks in the test [02:24] ie, adding a lock to make s.config safe [02:24] would cause a deadlock somewhere else [02:24] the answer was to take almost all hte locking out [02:25] as it was not protecting anything in the structure [02:26] thumper: I'm with Dave, you should be building go from source. It's trivial and fast and makes it easy to switch versions (not to mention cross compile etc) [02:29] ericsnow: I don [02:29] ericsnow: I don't suppose you're around? [02:31] davecheney: if I wanted to compile go 1.3.3, how would I go about it? [02:32] damn... should have said -v on that call [02:32] * thumper waits [02:33] thumper: git clone https://github.com/golang/go && cd go/src && make.bash [02:33] natefinch: surely that'll make tip [02:33] thumper: sorry, add a git checkout 1.3.3 in there [02:34] sorry, git checkout go1.3.3 [02:38] Bug #1468581 changed: juju bootstrap fails - Waiting for API to become available ERROR cannot get all blocks: EOF

[02:41] Bug #1421260 opened: juju 1.21.1 bootstrap timeout

[02:41] Bug #1468581 opened: juju bootstrap fails - Waiting for API to become available ERROR cannot get all blocks: EOF

[02:41] Bug #1468584 opened: juju bootstrap failed - cannot initiate replica set: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)

[02:58] wallyworld: can you please review my response to your comments before I land? [02:58] sure [03:00] axw: thanks for replies. i don't think i'll ever get used to Go interfaces tending to end with "er". /me cringes [03:01] wallyworld: I anticipated that :) I did it to keep with the existing Lifer [03:01] fair enough :-) [03:01] wallyworld: good to go? [03:01] hmm, maybe i better read the diff, but i trust you :-) [03:03] yeah lgtm [03:08] wallyworld: that's good, because I already hit $$merge$$ ;p [03:08] figured you would [03:08] Bug #1468586 opened: juju 1.24.0 bootstrap failure - Waiting for API to become available - Error connection is shutdown

[03:40] thumper: shall I try and merge the db-log feature branch soon? [04:12] thumper: ping? [05:02] wallyworld: two more PRs up for review, these should be the last. there's a TODO in the EnsureDead PR about adding a test in worker/machiner which I'm going to do before it's landed [05:03] axw: ok, just in meeting, will look soon [05:03] wallyworld: nps, thanks [07:03] Bug #1468637 opened: action-set needs to accept input from stdin [07:07] axw: anastasiamac: it's fairly large but based on existing code for tools etc. would appreciate a review at some point. i'll look to land tomorrow before i go away http://reviews.vapour.ws/r/2031/ [07:07] wallyworld: will do [07:08] ty, no rush [07:08] wallyworld: sounds gr8 :D === thumper is now known as thumper-bbl [07:21] Bug #1468639 opened: leader-set needs to accept input from stdin [07:27] Bug #1468639 changed: leader-set needs to accept input from stdin [07:33] Bug #1468639 opened: leader-set needs to accept input from stdin [07:35] axw: dimitern: thx for reviews, will complete it when in office. dimitern, could run a bit late today. [07:35] TheMue: np [07:49] TheMue, ok, np [07:57] wallyworld: reviewed [07:58] ty, that was quick [08:12] Bug #1468653 opened: jujud hanging after upgrading from 1.24.0 to 1.24.1

[09:02] dimitern: hangout? [09:02] fwereade: ^^ === thumper-bbl is now known as thumper [11:16] how do I get all history from the api? [11:16] wallyworld, ^^ [11:16] history of what? [11:17] like, debug-log, but from the API [11:17] just all the events that have occurred [11:18] what events? [11:18] hook runs? [11:18] actions executed? [11:18] things the user has done to the environment [11:18] or like, a historical allwatcher [11:18] ah i see [11:19] i don't know we have that capability ie audit [12:03] in case anyone's interested in making new juju plugins written in Go, i've just made a little tool to make that somewhat easier - it generates a skeleton for a new multi-command plugin: go get github.com/rogpeppe/misc/cmd/newjujuplugin [12:04] rick_h_: our meeting in 9.5 hours clashes with the release meeting [12:04] thumper: well boo [12:04] rick_h_: can we either start later, or push it to next week? [12:04] thumper: good, I think I have to cancel/move anyway because of swim class [12:04] lets cancel then [12:04] you know you can always ping me [12:05] rgr [12:05] sounds good [12:05] laters folks [12:21] dimitern: ping [12:21] dimitern: I have a successful creation of a device with MAC and allocation of IP address [12:21] dimitern: container name is used as hostname [12:21] dimitern: the only "wrinkle" is that maas automatically appends ".maas" onto our hostname [12:22] voidspace, pong [12:22] dimitern: I can't tell if using that hostname actually routes successfully yet because container creation fails due to my networking issues [12:22] voidspace, awesome! [12:22] dimitern: however my replacement networking hardware just arrived [12:22] voidspace, that's to be expected and it's fine [12:22] dimitern: so I should be able to tell you shortly [12:22] dimitern: great [12:23] dimitern: I've added MAC address to IPAddress as well [12:23] voidspace, sweet! keep me posted then :) [12:23] dimitern: now a load of tests to fix and some to write... [12:23] dimitern: but no further tasks on this card that I'm *aware* of if nothing more comes up in testing [12:24] voidspace, well, it's definitely worth trying destroy-environment --force cleans up the devices [12:25] s/trying/verifying/ [12:25] dimitern: yup, good point [12:25] can try that now [12:25] dimitern: yes it does [12:25] dimitern: device just disappeared... [12:39] dimitern: ping [12:46] dimitern: i'm lunching now. hopefully will catch you later. [12:52] rogpeppe, I'm about to go out, but will ping you when I'm back [12:57] * dimitern steps out for ~1h [13:19] Bug #1468752 opened: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode [13:19] Bug #1468756 opened: Bootstrapping local environment hangs when apt on host is upset === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [14:01] * fwereade going to bed, hoping he can sleep a bit; probably back later [14:02] fwereade: have a good rest [14:03] natefinch: standup [14:11] rogpeppe, ping [14:11] dimitern: hiya [14:11] rogpeppe, hey, so what's up? [14:11] dimitern: i was just looking at configstore [14:12] dimitern: and wondering which state server addresses field i should use [14:12] rogpeppe, it depends I guess - if it's a local env or not [14:13] rogpeppe, ah [14:13] rogpeppe, well, any of them should work [14:13] dimitern: ok. i think i decided that server-hostnames was probably the best one to use [14:13] dimitern: because i'm passing them off to a remote server to do the connection [14:14] rogpeppe, just a quick note about it - those are never resolved if they contain hostnames, unlike the other [14:14] dimitern: is the only difference that one of them has resolved IP addresses in it? [14:15] rogpeppe, yeah, the hostnames are kept to make sure we only update the addresses if they changed (and not due to hostname-to-ip resolution) [14:15] dimitern: i didn't find the comments that clear [14:15] dimitern: it's not obvious that they both hold the same set of addresses in different forms [14:15] dimitern: just saying :) [14:15] dimitern: anyway, thanks for confirming [14:16] rogpeppe, fair point :) [14:16] rogpeppe, hostnames only serve a minor purpose - to avoid connection slowdown due to resolving names [14:16] (and are optional to begin with) [14:17] dimitern: hold on... which is which? [14:17] that is - unnecessary slowdown [14:17] dimitern: Hostnames is the unresolved set of addresses, no? [14:18] rogpeppe, hostnames are optional and are used if there when we're about to update the addresses (which are not optional) [14:18] s/if there when/if/ [14:18] too many predicates :D [14:19] dimitern: oh, so i think i'm using the wrong one then [14:19] rogpeppe, yes, they are as we received them [14:19] dimitern: i really don't understand now [14:19] rogpeppe, in brief, you should use addresses [14:19] :) [14:19] dimitern: ok [14:20] as with hostames YMMV [14:20] dimitern: so Hostnames contains resolved addresses? [14:20] rogpeppe, no, unresolved [14:20] dimitern: and Addresses is the addresses as received from the state server? [14:21] rogpeppe, it contains (most of the time, unless they're about to be updated) the same list as the addresses field, but when set, the addresses are resolved first and any unresolvable ones are dropped [14:22] dimitern: so why the "may contain unresolved hostnames" comment? [14:22] rogpeppe, Hostnames = as we received them, Addresses = only IPs after resolving Hostnames [14:22] rogpeppe, where? [14:22] // Hostnames holds a list of API addresses which may contain [14:22] // unresolved hostnames. It's used to compare more recent API [14:22] // addresses before resolving hostnames to determine if the cached [14:22] // addresses have changed and therefore perform (a possibly slow) [14:22] // local DNS resolution before comparing them against Addresses. [14:22] Hostnames []string [14:22] dimitern: that makes it sound like Hostnames is the one holding unresolved addresses [14:22] rogpeppe, ah, yeah - unresolved as in "the provider gave us a mix of ips and hostnames and we kept the later as-is" [14:23] rogpeppe, makes sense? [14:23] dimitern: no, i'm even more confused now [14:23] rogpeppe, here's an example: [14:24] dimitern: you said i should use Addresses, but that doesn't have the unresolved host names in it that i almost certainly want because they're the actual DNS names [14:25] rogpeppe, rogpeppe, Hostnames = ["sparkling-wine.maas", "172.10.20.30", "127.0.0.1"], Addresses = ["172.10.20.30", "127.0.0.1"] assuming the hostname resolves to the second item in Hostnames [14:25] dimitern: and FWIW my local.jenv has "localhost:17070" in both state-servers and server-hostnames fields, which isn't resolved [14:26] rogpeppe, but if we can't resolve sparkling-wine.maas (e.g. we're not using the maas dns server on the host using juju cli) it will be dropped [14:26] dimitern: ok, so in that case, i'm pretty sure i want to use Hostnames [14:26] dimitern: but you say that it may be empty even when Addresses is not? [14:26] rogpeppe, localhost is special - it's not resolved even if it appears in Hostnames [14:26] dimitern: weird - why not? [14:27] rogpeppe, it may be empty for example if you got a .jenv file from somewhere and want to use it - it will have addresses, but might not have hostnames [14:27] dimitern: even though Hostnames is the primary source? [14:27] rogpeppe, because localhost resolves both to 127.0.0.1 and ::1 and depending on prefer-ipv6 env setting one or the other is tried first [14:27] dimitern: ah, because it might be from an old version of juju which doesn't support that field? [14:28] rogpeppe, indeed [14:28] dimitern: i definitely think this could do with some better docs [14:29] rogpeppe, agreed [14:29] rogpeppe, for really bad cases of missing or misleading docs, please file a bug [14:29] dimitern: but thanks very much for the explanation [14:29] dimitern: i shall change my code to use Hostnames by preference and fall back to using Addresses if len(Hostnames) == 0 [14:29] rogpeppe, no worries [14:30] rogpeppe, yes, unless the place you'll be using those addresses cannot resolve one or more hostnames in it [14:31] dimitern: well, it'll eventually just pass those addresses to api.Open [14:31] rogpeppe, yes [14:31] rogpeppe, and it mightl fail for unresolvable ones, but likely succeed for the others [14:31] dimitern: and there's no way that my code can tell whether the server it's passing the addresses to will be able to resolve the addrs [14:32] rogpeppe, except an educated guess, yes you can't generally know [14:32] dimitern: my client is crude and uneducated :) [14:33] rogpeppe, e.g. if you're trying to connect to a maas environment outside maas's network it will most likely fail; for ec2 OTOH it will work [14:33] dimitern: yeah, not much i can do about that [14:34] rogpeppe, yeah === kadams54 is now known as kadams54-away [15:18] Hello Folks, Can anyone point out to me how quantum-gateway charm interacts with OpenStack Keystone. I don't see any relation between two. [15:20] Syed_A, keystone acts as a service directory and other openstack services can use it to discover others, outside the relation context [15:22] dimitern: Yes but if a service wants to use keystone it must have AUTH_URL available to it. I am trying to figure from where metadata agent is getting keystone url. [15:24] In my openstack environment, instances are failing to get metadata from nova-api-metadata. And apparently the reason is the metadata agent is trying to contact keystone on loclahost instead of AUTH_URL [15:25] Bug # changed: 1348663, 1442308, 1447895, 1454678, 1462146, 1464616, 1466167, 1467690, 1468584, 1468586 === kadams54 is now known as kadams54-away [15:29] alexisb: ping. [15:31] mbruzek1, pong [15:32] alexisb: Is anyone in core working on a digitalocean provider? Kapil wrote a plugin that works with Digital Ocean, but that is a plugin. [15:32] mbruzek1, no [15:33] alexisb: I ran into a Digital Ocean person at Dockercon and he seemed very interested in talking with us. [15:33] hmpf, merge conflicts [15:33] alexisb: Is there some documentation / instructions about how to write a provider? (Is this something I could contribute?) [15:34] mbruzek1, we would be help to consult them through the process [15:34] mbruzek1, there is limited documentation [15:35] mbruzek1, but if they are willing to do the work we would be happy to help them along [15:35] mbruzek1, I will tell you that writing a provider is not a straight forward, painless process [15:35] something the team is eager to address, but work we are not currently scheduled to do [15:36] alexisb: I am going to email the D.O. person back who would be the contact on core? [15:36] myself and katco === kadams54-away is now known as kadams54 [15:36] OK thank yo [15:58] alexisb: just checking you're still available === kadams54 is now known as kadams54-away [15:59] voidspace, yes [15:59] alexisb: great [15:59] I moved us out 30 minutes [15:59] I will be there is one minute :) [15:59] alexisb: ok [16:09] gnah, one gofmt, try again === kadams54 is now known as kadams54-away [16:17] ericsnow: bug 1468815 [16:18] Bug #1468815: Upgrade fails moving syslog config files "invalid argument"

[16:18] mgz: k === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === natefinch is now known as natefinch-afk [18:03] any juju-core members who are online, team call [18:03] cmars, ^^ [18:20] this conversation made me hungry, I might go for a seccond apple [18:29] Bug #1468855 opened: Feature Request for enhanced configurability of lxc hostname naming convention

[19:35] could someone spare me a moment for a quick review on a critical bug fix? http://reviews.vapour.ws/r/2035/ [19:36] ericsnow: looking === natefinch-afk is now known as natefinch [19:39] ericsnow: ship it [19:39] natefinch: thanks [19:51] ericsnow: is this what we're trying to write? https://github.com/juju/juju/blob/master/apiserver/common/registry.go#L121-L126 [19:51] katco: not exactly [19:52] katco: we want to add methods onto an existing facade [19:52] katco: I suppose we could use a separate facade... [19:52] ericsnow: shouldn't all components have their own facade? [19:52] katco: that would likely be easier [19:52] katco: they don't now [19:53] katco: (at least for the uniter) [19:53] ericsnow: so the uniter is a facade, and we want to add methods onto it? [19:53] katco: all of those are crammed into the uniter facade [19:53] katco: right [19:54] katco: though it might be worth seeing if there is any technical reason not to use a separate facade for the component [19:55] ericsnow: ty, i'll continue poking around [19:55] katco: cool [20:03] ericsnow: can I make those changes to process? Command as []string and port ranges? [20:03] natefinch: give me a few minutes to wrap something up [20:03] ericsnow: port ranges are more of a nice to have, but the command thing I think is a must [20:03] ericsnow: np [20:04] I have an hour before I have to go make dinner though [20:29] whoever decided that . should not match \n should be flogged [20:30] natefinch: regexes are enough problem as they are without having to worry about them being multilined [20:31] perrito666: why should \n be special? It's just another character.... by making . match everything except that, you're making a special case for no reason [20:31] natefinch: \n is not a newline everywhere :p [20:32] perrito666: that's even worse [20:32] if you are matching a multiline entity with a regex, you are a daltonic wiring a bomb [20:33] * natefinch learns a new English word from the ESL guy. [20:35] natefinch: ? [20:35] daltonic [20:35] ah, I believe color blind might be more usual? [20:36] I never knew there was a word for "someone who is color blind" [20:36] perrito666: yep [20:36] it's a brazilian/south americanism [20:36] google says it's from the French word daltonisme, which is where I suspect perrito666 got it [20:37] first scientific paper on the subject of color blindness, Extraordinary facts relating to the vision of colours, was published by the English chemist John Dalton in 1798[5] after the realization of his own color blindness. Because of Dalton's work, the general condition has been called daltonism, although in English this term is now used only for deuteranopia. [20:37] it is called daltonismo in spanish too [20:42] natefinch: anyway I think you always tend to learn more words of your language by non native speakers as they lookup in formal sources to translate words they use regularly and you might not [20:54] ericsnow: 5 minutes [20:54] natefinch: I've replied. [20:54] cool [20:55] natefinch: basically I'd rather pursue alternatives [20:55] natefinch: and for the portrange we should use the code we already have for that [20:55] natefinch: basically move the core network package over to the utils repo or something [20:58] marcoceppi: there is no audit yet, but we are hoping it will drop out of planned work [20:58] marcoceppi: not any time soon though [20:58] :( [20:58] sorry dude [20:59] ericsnow: thanks. I disagree about the c ommand thing, but don't have time to talk about it now. Gotta go make dinner. [20:59] natefinch: k === natefinch is now known as natefinch-afk [21:23] menn0, offhand, how does presence intersect with multi-env? [21:24] interact? whatever ;p [21:24] menn0, ah I see [21:25] menn0, not global, but parameterised by id [21:25] uuid [21:25] menn0, many thanks for your inestimable rubber-ducking [21:25] menn0, (I guess we have to do manual cleanup of those on env destroy then?) [21:26] fwereade: in standup [21:26] menn0, np [21:30] fwereade: so yes, not global [21:32] fwereade: I was thinking that eventually there could be just one low level watcher goroutine that is env agnostic (potentially more efficient when you have 100's of envs in one state server) [21:32] fwereade: what do you mean regarding manual cleanup? [21:51] menn0: got a moment? I want to talk about a broken environment (mine) [21:52] thumper: give me a minute. i've almost finished writing a complainy email. [21:52] heh, ok [22:10] fwereade: not sure if you're coherent enough to talk about mgo txns? [22:19] waigani: chat? [22:19] menn0: yep, standup chan? [22:20] waigani: see u there [22:41] wallyworld: I have a physio appt during our normal call time [22:41] wallyworld: want to do it now? [22:52] mramm: are you really here? [22:52]