[01:04] wallyworld: axw bot is still being a prick [01:04] did jams' fix to the data race in the api server get fixed ? [01:04] sadly yes [01:04] i think so [01:04] there's 2 mongo races that i think are the cause of the remianing issues [01:04] I'll take a look at it this morning [01:04] oh [01:05] wallyworld: new ones though? [01:05] because it wasn't this bad last week [01:05] axw: not sure, haven't looked in detail but there's been various changes this week [01:06] axw: could you take a look at this first up, it attempts to fix another critical blocking 1.19.4 https://github.com/juju/juju/pull/155 [01:06] wallyworld: sure, looking [01:06] ta [01:08] wallyworld: haven't been able to land a branch all morning [01:10] davecheney: so last week, we had the 2 intermittent mongo failures which only happened every so often. lots has changed this week. stuff has broken :-( [01:10] i do think we've got systemic race conditions in our code which no one has really got a handle on [01:11] and/or mongo is shit [01:14] wallyworld: do you know why the peergrouper is getting an empty set of machines in the first place? [01:16] axw: not sure, it's all quite involved, i guessed that it could have been due to stuff initialising and replicaset stuff not being ready (likely during upgrade from non ha to ha env) and timer inside worker triggers publish of machine addresses but they aren't known yet [01:16] there are 2 triggers to publish - machine watcher and timer [01:17] wallyworld: then I would expect it's just going from empty to empty? hmm. anyway, I'll LGTM because it doesn't make anything worse AFAICT [01:18] axw: yes but the watcher won't have fired [01:20] my analysis is in bug comment 5, i can't see an other reason for the issue :-( [01:27] wallyworld: ok, i'll focus on finding those race conditoins [01:27] davecheney: we'll look as well [01:28] davecheney: the 2 i was aware of were one in bug 1305014 and another inside the apiserver code (not sure of bug off hand) [01:28] <_mup_> Bug #1305014: panic: Session already closed in TestManageEnviron

[01:33] * thumper goes to make a coffee [02:05] davecheney wallyworld: jam's fix has not landed [02:05] may explain why I'm getting panics and the race detector isn't happy with cmd/jujud [02:05] oh, bollocks, i thought it had [02:06] axw: what can I do to help land that today [02:07] axw: davecheney the fucking bug was marked as fix committed [02:07] hence i thought it had landed [02:07] wallyworld: yay issue tracking [02:07] but github says otherwise [02:08] davecheney: merge was attempted and tests failed, could just try again. rogpeppe has made added a remark about the solution being non-ideal [02:08] i've hit the "merge" button again [02:08] we can fix the non-ideal bit after it lands, we need to get this release out imo [02:08] seconded [02:08] sgtm [02:10] trivial review please: https://code.launchpad.net/~axwalk/gwacl/vnet-location-docalignment/+merge/224254 [02:10] looking [02:11] axw: dumb question, how is 2012 more recent than 2013? [02:12] wallyworld: "which is actually older than what was in the code." [02:12] yeah read that but still don't understand [02:12] wallyworld: 2012-whatever is the most recent published version for that API [02:12] so we were using an incorrect date? [02:12] wallyworld: yeah [02:12] ok [02:13] I don't think it actually matters, but I'd rather go by the docs [02:13] yup [02:27] davecheney: re: https://github.com/juju/juju/pull/156 [02:28] davecheney: axw has approved but I have a few questions [02:28] davecheney: just letting you know [02:29] thumper: sure [02:29] thumper: i'm not trying to land anything til the race fix lands [02:31] davecheney: done with comments [02:31] thumper: yup [02:31] i see your comments [02:31] i think oyu found one of my TODo's there [02:31] fwiw, almost all this stuff was just a string slung straight to the api server [02:32] but I will adjust the signatures to mandate the correct type [02:32] test 0 [02:32] ... Panic: Couldn't create temporary directory: mkdir /tmp/gocheck-3784560248718450071: file exists (PC=0x41078D) [02:32] wowo [02:34] haha [02:34] pseudo-random [02:35] davecheney: should it be the actual type or an interface? [02:35] just wondering [02:35] thumper: i'm thnking the concrete type [02:35] ok [02:35] we want to say "only machine tags here" [02:35] or units [02:35] or whatever [02:35] * thumper nods [02:36] This gives the compiler control rather than runtime assertion [02:36] better I think [02:37] thumper: yup [02:38] to fix this i'll need to change most of hte places where we have a struct like [02:38] type Machine struct { tag names.Tag } [02:38] to [02:38] type Machine struct { tag names.MachineTag } [02:38] and this is a good thing [02:42] thumper: consider yourself nagged for that sprint [02:42] its < 30 days [02:42] ack === _mup__ is now known as _mup_ [02:56] bodie_: I just finished reviewing 141 [02:57] all good from my perspective [03:10] wallyworld: http://juju-ci.vapour.ws:8080/job/github-merge-juju/252/console [03:10] what ? [03:10] tests didn't fail [03:11] did someone nuke this build ? [03:11] davecheney: looks like connection to ec2 instance disappeared half way through [03:12] faaaark [03:12] retry i guess [03:12] menn0, good to hear :) [03:32] wallyworld, the utopic ami expired a few hours ago. I just configured tests to use that to fix on test...maybe i need to check the ami used by git-merge-juju [03:33] sinzui: ah, could be it [03:33] although i thought we ran trusty [03:33] or even precise actually for the tests [03:33] yes, i'm sure it's precise [03:33] wallyworld, yeah, and trusty tests are happy. I will double check [03:34] ok, but it's waaaay past your eod [03:35] wallyworld, oh... [03:35] wallyworld, I think there is a correlation between git-merge-juju and a number of hung instance from a few hours hours ago. I had to terminate them. [03:36] really? oh [03:36] maybe you terminated a git-merge-juju one as well? [03:36] wallyworld, I have request an additional 20 instances. [03:36] great [03:37] Maybe I can also update the tests to switch to hp which is very good now that we addresses the ram instance ratio [03:38] * sinzui forces a rebuild [03:38] i think that couldn't do any harm [03:38] mgz is moving to get a nailed up hp cloud instance working to run the tests [03:39] I can do that in 30 minutes. [03:40] I can get slaves and slave helpers up quickly for trusty. [03:41] I have failed to create a fat 386 to test local deploy. I am pondering the consequences of never testing that 386 local provider works. [03:41] i don't think too many people would be using it [03:42] a surprising number download it from the ppa [03:42] once the nailed up instance is there, mgz needs to do a little script tweaking but it should be easy [03:42] wow, ok [03:42] i386 is so last century [03:43] decade maybe [03:48] wallyworld, https://pastebin.canonical.com/112317/ [03:48] jeeez, ok [03:48] * wallyworld is surprised [03:49] Indeed. abentley intends to break the numbers down by week to find proper trends is adoption and decline [03:50] your beta tester numbers are still generating [03:51] ok [03:52] i'd be interested in seeing those when done [03:53] potentially silly question: are juju controlled machines (specifically state servers) able to SSH between each other? I'm thinking about something that would involve distributing a file to all state servers. [03:56] menn0, They don't have the private keys [03:57] sinzui: ok thanks. (I think you mean the public keys right?) [03:57] menn0, they have public keys, that is why juju ssh workd [03:58] menn0, there isn't a private key on any of the juju machines that would allow an agent to ssh to another machine [03:58] sinzui: got it [03:58] thanks [03:58] * menn0 should have just looked in ~/.ssh ... [03:59] menn0, also, manual provision can happen across networks, so the design is that the agents can all find the state server, but not necessarily the each other [03:59] juju ci's state server cannot reach the lab, but the 4 machines I provisioned there can reach the state server. [04:00] sinzui: ok that's good to know. [04:00] I'm wanted to get a file generated on one state server to all other state servers [04:00] well that's one design I'm looking at [04:01] menn0, surely the master state-server is known to all machines. so all machines can ask for a task to pickup the file [04:03] wallyworld, beta testers https://pastebin.canonical.com/112318/ [04:03] sinzui: right, so you're thinking: a state server generates the file, tells the master to come and get it which it does, and then pushes it out to all other state servers. [04:04] menn0, I think that is possible [04:04] that could work [04:04] menn0, My experience is from observation. I really don't know how juju works. [04:05] 1.11.2 was big [04:05] sinzui: alternatively I think I can make this work by adding extending the API a little... [04:05] on the other hand, I have done the neigh impossible because I didn't read the code http://curtis.hovey.name/2014/06/10/building-trans-cloud-environments-with-juju/ [04:07] sinzui: :) thanks for your thoughts. you've nudged me in the right direction. [04:11] wallyworld, It you stare at the 1.19.x numbers you can see the transition from precise users to trusty users. [04:11] * wallyworld needs another coffee before staring at numbers [04:11] if there's any chance I could get a LGTM on https://github.com/juju/juju/pull/140 it would be quite helpful in moving Actions forward :) [04:12] (LBTM equally appreciated, though) [04:17] bodie_: doesn't look like william's issues with tags and canAccess function have been fixed? [04:30] do we have any helper functions for merging two slices of structs, or should I just do it by hand? [04:38] wallyworld, Are you getting more information about bad tests from walk-unit-tests-amd64-trusty than for the other unittests? [04:40] sinzui: the idea was that we'd try and solve the intermittent failures. that job was useful but with the switch to running the tests on ec2 instead of canonistack/tarmac, the main landing tests have become unreliable instead :-( [04:40] we can pass that job until things settle down a bit [04:40] pause [04:40] done [04:40] ok, ta [04:46] thumper: I've got a question, hangout? should be quick [04:46] sure [04:46] thumper: https://plus.google.com/hangouts/_/g4rgbccmbg5lchy6qcx7hsny6qa?hl=en [04:54] wallyworld, I'll have to have a look tomorrow morning, well past eod here, but I think I've addressed tags. I'm not totally certain what he was looking for with canAccess [04:54] for the queries from api to apiserver, everything is encapsulated by tags [04:54] ok [04:55] thanks for having a look! good night all [04:59] wallyworld, I need to sleep. I am a little concerned that local-upgrade on precise is not passing. maybe there is something in one of these logs if CI continues to fail http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/1414/ [04:59] ok, thanks, we'll look [05:39] thumper: wallyworld [05:39] [LOG] 0:02.374 DEBUG juju.environs.simplestreams fetchData failed for "http://127.0.0.1:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json": failed to GET object images/streams/v1/index.json from container juju-test-e76bfc6736366a8a [05:39] caused by: Resource at http://127.0.0.1:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json not found [05:40] caused by: request (http://127.0.0.1:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json) returned unexpected status: 404; error info: 404 Not Found [05:40] The resource could not be found. [05:40] an exmple of the random test failures I get on my machine [05:41] i'd need to see the whole log of the filed test and which test it is === vladk|offline is now known as vladk [06:01] axw: if you get a chance at any point, could you look at https://github.com/juju/juju/pull/124 ? william is happy with the implementation but hasn't had time to do a more detailed review [06:02] wallyworld: yep, no worries [06:02] ta, i have to go out for an hour or so, back later [06:03] adios [06:07] dimitern: morning, I started to work on NetworkInterfacesWatcher. I am going to change NetworkInterfaceDoc according to the final draft. Is it ok? [06:12] vladk, better not i think, because we'll need to add subnets and other things as well [06:13] vladk, we can still watch ifaces as they are though [06:19] dimitern: so I filter interfaces by machineId, rather than _id? [06:21] vladk, what do you mean? [06:22] vladk, i suppose there will be a machine.WatchInterfaces() method in state, returning a StringsWatcher reporting the ids of all interfaces for that machine, as they are created, enabled, disabled, or removed [06:23] vladk, you do need to add the IsDisabled flag to the iface doc though, but just that - for the other things that need changing, i think we should start with networks and subnets first, then the rest [06:28] dimitern: to read initial set of interfaces I need filter interfaces from the sate by machineId [06:35] vladk, yes, the interface doc has a machineId - you can use that, right? [06:35] dimitern: yes [07:59] jam: ping [08:07] TheMue: pong [08:08] jam: seen the latest comments on https://github.com/juju/juju/pull/150 ? [08:10] I haven't, I'll go look [08:11] jam: we have different levels to fix this issue. from low-level inside the jsonrpc package up to the command. I prefer ParseSettingsStrings in charm.Config [08:12] TheMue: well, I posted that you might even go for the 'schema' package, which is the stuff that validates already [08:13] however, I really don't want us to get too derailed here, this is mostly a passing-by stuff, and we thought things were working differently than they are. [08:13] so for now, document that we get \ufffd when you pass in invalid binary data (part of the actual api Client level tests), so that we at least assert the current behavior and know if we change it. [08:13] and I can live with whatever other results we get, as it won't be *worse* than what we've lived with forever. [08:14] TheMue: does that make sense to you? [08:17] jam: so you don’t expect cmd.Main to return something else than success? because we simply accept and document this behavior? [08:18] jam: as the json encoding always „corrects“ the invalid sequence to \ufffd [08:18] TheMue: I can live with it, given we've been living with it forever. [08:18] TheMue: it isn't what I prefer, but we don't have to fix everything, we have more important things today [08:19] jam: yes, that have been my thoughts this morning too. we only discovered this issue by thinking about it, but it never happened in reality so far [08:20] jam: ok, then it makes sense and I’ll change the latest added tests to be a bit more explicit and documenting, so that in case of somebody having to fix this error is having a good base to start from [08:20] TheMue: sounds good to me [08:21] vladk: just a reminder that you're On-Call-Reviewer today [08:21] and TheMue you're OCR tomorrow [08:21] jam: tested the json marshalling yesterday evening a bit in both directions as well as taking a look into the source. interesting that they removed the error for invalid utf-8 with go 1.2 [08:22] jam: thx for the hint [08:22] TheMue: seems like a pretty significant change, but I guess that's what we have to live with. [08:23] jam: yeah, especially as we use the websocket json codec directly, so we don’t even see the marshalled bytes. they are directly written to the socket [08:27] * jam heads to lunch [08:48] davecheney, ping [08:55] fwereade: https://github.com/juju/juju/pull/158 - FYI [08:55] axw, thanks [09:01] fwereade: ack [09:03] mgz: standup? [09:09] davecheney, can we have a quick chat about where you're heading with the tags stuff? there's clearly plenty to like but I don't have a clear idea of the plan [09:09] fwereade: sadly no [09:09] i am not at home [09:10] fwereade: you speak to tim frequently [09:10] he can represent me on this issue [09:10] davecheney, cool, thanks, I'll chat to him this evening [09:41] morning all [09:50] wwitzel3: morning [09:59] morning [10:19] vladk, jam: (hopefully) final changes https://github.com/juju/juju/pull/150. so please review (again) [10:36] jam: not sure if my "fix" for that agent.conf issue will do any good or not but it's all i could come up with as something to try from reading the code [10:46] jam, standup? === wallyworld__ is now known as wallyworld === jcsackett is now known as idioteque === idioteque is now known as foobarbazqux [12:12] * fwereade bbiab [12:33] stumble upon's logo reminds me of something [12:59] Looks like wallyworld's fix got upgrade broken local precise upgrades [12:59] * sinzui reports bug === alexisb_bbl is now known as alexisb [13:08] natefinch, jam, fwereade, alexisb : We have a regression cause by the fix for upgrade bug reported yesterday https://bugs.launchpad.net/juju-core/+bug/1334273 [13:08] <_mup_> Bug #1334273: Upgrades of precise localhost fail

[13:08] sinzui, lovely [13:10] perrito666, wwitzel3, mgz ^^^ you guys available to take a look at this bug [13:15] morning all [13:15] wwitzel3: can we push our 1 on 1 to this afternoon? [13:15] alexisb: nothing is jumping out at me from the change or the log in the bug... === anthonyf` is now known as anthonyf [13:19] mgz, well of course it couldn't be obvious that would be waaaay to easy ;) [13:19] natefinch: sure [13:20] mgz, The stall in the test log. where a single status call takes 10 minutes, then fails the test looks like the issue joyent upgrades had. Wallyworld said the fix was to ensure the state server got a sane list of addresses [13:22] sinzui: so, all the change does is return an error if the publish function is given an empty list [13:22] I don't particularly see how that regresses us... it must be something fun and side-effecty [13:23] mgz #136 from wallyworld/ignore-empty-machine-addresses [13:23] mgz, I am speculating...I really don't know [13:23] sinzui, mgz : does that mean we think that this current bug is a result of joyent shotcomings? [13:24] alexisb, no. I am just remarking that the fix for yesterdays critical broke another test in a similar way to a bug from last week [13:25] alexisb, CI loves juju yesterday. I could release something from yesterday as 1.19.4 [13:25] sinzui: I don't see that error propogated back up in the logs anywhere either [13:25] sinzui: github says https://github.com/juju/juju/commit/e01ac93e is a different commit [13:25] which it *should* be if that change actually affected anything [13:26] sinzui, ok [13:28] perrito666, I give you the latest data, there have been two broken revisions, I just to give you a log from what fails 15 minutes ago [13:28] sinzui: I was talking about "With the introduction of e01ac93e "Merge pull request #155 from wallyworld/peergrouper-publish-ignore-empty"" [13:29] perrito666, http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/ shows all the failed tests over the last 9 hours [13:29] oops [13:30] sinzui: as I say, the first failure comes from https://github.com/juju/juju/commit/e01ac93e0cbee312bf19ead78035a78ed2428871 [13:30] #153 from davecheney/112-state-life-takes-a-tag is the one [13:30] which is not wallyworld's tag [13:30] s/tag/rev [13:31] I updated the bug [13:31] mgz: you might find more answers there ^ [13:31] that does seem a little more promising [13:32] mgz, is there an obvious fix or is a commit we should consider backing out for this current dev release? [13:33] I think we should consider backing out the change and seeing if that resolves the issue [13:35] this might mean pain for upgrades later, this is an api change [13:36] of sorts [13:36] mgz, that seems very reasonable to me, sinzui your thoughts? [13:38] mgz...well, I have the tarball and installer from the previous pass. I can start the release now with fa4f6106 [13:49] mgz, are you preparing to backout the rev to test? [13:51] anyone happen to know whether fwereade is around? [14:01] alexisb: I presume I stick around with Gabriel and skip tosca this week? [14:02] natefinch, yes === foobarbazqux is now known as jcsackett === vds` is now known as vds [14:45] mgz, perrito666 Is anyone working on bug 1334273 or planning to backout the revision where the error started? [14:45] <_mup_> Bug #1334273: Upgrades of precise localhost fail

[14:46] I am not, I was under the impression mgz was on it [14:47] sinzui: I can do the backout if we want that [14:47] I'm not completely sure it'll resolve the issue, but seems worth trying [14:47] mgz we can do that or I release the version before it. [14:48] mgz, if the test passes after the backing out, then we know the rev is bad, that is all we learn [14:48] sinzui: I guess the question is, do we want the wallyworld change that comes after [14:49] because *that* bug was the blocking cause previously right? (the thing wallyworld's change tries to fix, panic on not having addresses) [14:49] mgz, yes, if it is independent. wallyworld's change was a hope to fix the other critical [14:50] okay, I'll do the revert, we send tip with that through ci, and release that if it's clean, otherwise release the rev before [14:50] sounds good? [14:51] mgz, yes sounds good :) [14:52] mgz, alexisb. I have a lot of anxiety regarding the delay of the devel release. We have more than 50 issues people aren't testing beause we always find one more critical bug. I am inclined to revert to my old behaviour of selecting a blessed revision from the past. In general, a bug that is in older versions of juju does not block a devel release, only recent regressions can block [14:53] +1 [14:54] sinzui, +1 [14:59] can I get a check/stamp on pr160 please [14:59] perrito666: ^ [15:00] natefinch: checking [15:00] >_< [15:02] aghh sorry, off by one in the kb [15:02] mgz: check [15:02] okay, sent to bot [15:02] perrito666, natefinch: standup or are you guys busy with the regression? [15:03] wwitzel3: coming [15:10] natefinch: ? [15:10] wwitzel3, perrito666: let's meet this afternoon, sorry, in a virtual sprint with the cloudbase guys until 1-ish [15:11] cool, I can then use my bw to continue downloading broken sword :p [15:23] sinzui: revert has landed [15:33] sinzui: the upgrade job is blue, but from before the revert landed anyway. [15:35] ? [15:35] if I'm looking at the jenkins job correctly, the latest run is blue, but it's from an earlier landing anyway [15:36] what does blue mean? [15:36] er, it passed. blue dot in the jenkins ui. [15:36] damn it [15:38] mgz, a race condition where upgrade won? There were a lot of failures and the rate is much worse than it was before the rev [15:38] mgz, if the job passes quickly in the next run, then I am convinced that a race condition was avoided [15:39] yeah, makes seeing particular blame on the change much harder [15:39] we have a few more trunk revs to see [15:49] does anyone know how to retrieve the Unit making the query in an APIserver endpoint? [15:50] I was passing the calling Unit's tag along with the entity request, but I was told that the UniterAPI has the calling Unit as a member variable === tvansteenburgh1 is now known as tvansteenburgh [16:43] jam1, did you want to meet? [16:43] alexisb: yeah, I think so [16:43] ok, our normal hangout [17:00] natefinch, perrito666, ericsnow: is now good? [17:01] wwitzel3: good for me [17:01] wwitzel3: coming [17:02] wwitzel3: can we do it in an hour? [17:02] lol [17:02] not coming [17:05] ping me when you are ready [17:05] * perrito666 cooks [17:14] sinzui: I've not seen any more runs on the local upgrade job, [17:15] but I've proposed a restore of dave's changes as it doesn't seem to have had an effect [17:15] mgz, It runs in a later phase [17:15] mgz, I was just looking if I could force the test to run earlier [17:16] mgz, were you planning to create a dedicate HP test machine? [17:17] sinzui: yup, though not completely sure about the hp part [17:17] mgz, HP is good now that we fixed the RAM to instances inbalance [17:17] mgz, I can provide a slave for you before you wake tomorrow [17:18] do I need a la [17:18] *slave, the unit test script just takes any machine right? [17:19] mgz, I have been pondering an update to the run-unit* to provision nova instances [17:19] that seems reasonable [17:19] A slave in our cloudy case means some jobs jump the queue. That helps you [17:21] okay [17:21] We could choose to run tests on the slave machine. I am going to try that for some tests. I really want to minimise our aws resources...then I thought changing the run* tests to use nova would help me [17:21] oh [17:22] mgz, your tests try once fast, then try with -p 2. Should I be doing the same? [17:22] I try test 4 times, maybe I could your your technique to minimose setups [17:22] sinzui: , ideally not, but I was considering proposing a change to the script to take a flag that does that [17:47] i'm getting this error from jenkin-slave even though the file listed exists and is world-readable: 2014-06-25 17:39:24 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /var/lib/juju/tools/1.17.4.1-trusty-amd64/downloaded-tools.txt: no such file or directory [17:47] any ideas? [18:03] perrito666, ericsnow: standup? [18:03] natefinch: sure [18:04] natefinch: coming [19:12] I wont be helping a test job to run sooner. My effort lead to a collision in lxc/mongod/jujud on the jenkins master. That 60 minute delay was not faster than letting tests run as they naturally want to [19:39] all the contents of the turkey wrap I was eating for lunch blew out the bottom and the cat got scared, ran through it, and I just finsihed wiping up all the mustard cat prints in my house. [19:42] wwitzel3: just imagining that gave me a chuckle :) (hopefully it wasn't too much work) [19:42] wwitzel3: I've had the same thing happen with small children [19:46] ericsnow: thankfully, wood floors [20:08] fwereade: around? [20:08] natefinch: o/ [20:08] thumper: [20:08] howdy [20:10] ericsnow: do you eat small children? :p [20:10] perrito666: only when they misbehave ;) [20:12] natefinch: got time for a quick hangout? [20:13] yeah [20:13] natefinch: https://plus.google.com/hangouts/_/g44xyud6z5kz3g6p775ebv6cfya?hl=en [20:36] I'd appreciate a review on https://github.com/juju/names/pull/11 [20:36] Its an ActionTag refactor to hide the implementation details of extracting a UnitTag from an ActionTag [20:38] thumper: I think it's Thursday in your timezone >:-} ^^ [20:40] Of course it's still Wednesday for mgz ;) [21:02] hi jcw4 [21:02] yes, thursday here [21:02] hi thumper :) [21:02] just after 9am [21:02] jcw4: there you go, you might want to look for better reviewers than me nevertheles [21:02] perrito666: your review comments are great [21:02] I'll take a quick look too if you like [21:03] thumper: excellent, thank you yes [21:07] thumper: re: exported attributes... I wasn't clear if I could access the internal attributes outside of a method on the internalStruct [21:08] I'll change it and make sure it still works [21:08] jcw4: all internal attributes are accessable inside the same package [21:08] as long as it is only used inside the names package, you should be fine [21:08] thumper: perfect [21:10] hmm... [21:11] * thumper writes a longer general comment. [21:13] * bodie_ grabs his binoculars and tries to catch a peek [21:15] * jcw4 counts the minutes, wondering what could cause such long deliberation... [21:17] * jcw4 is scared now [21:18] thumper, hey, I thought there was some meeting in 40 mins? don't seem to be invited any more [21:18] hmm... this is getting longer [21:18] fwereade: yes it is still on [21:18] thumper, since I seem to be up, I might swing by, it looked important iirc [21:19] thumper, what was it? [21:19] docker stuff [21:19] the meeting that is [21:19]