[00:06] <thumper> oh FFS...
[00:36]  * thumper takes the dog for a walk
[01:35] <davecheney> thumper: i'm coming around to your way of thinking that we should have unit tests in place
[01:35] <davecheney> to assert if we add extra transitive dependencies
[01:40] <thumper> :-)
[01:43] <davecheney> ericsnow: ping, https://github.com/juju/juju/pull/1202
[01:43] <davecheney> its pretty easy to screw it up
[01:43] <davecheney> thumper: you said we had some tests in another package I could appropriate ?
[01:44] <thumper> davecheney: juju/osenv/package_test.go
[01:44] <davecheney> lucky(~/src/github.com/juju/juju/juju/osenv) %
[01:45] <davecheney> worst package name, ever
[01:46] <thumper> heh
[01:49] <davecheney> who wants to review this cheeky one ? https://github.com/juju/juju/pull/1202
[01:54] <davecheney> why does jc.Contains not work in a sane way
[01:55] <davecheney> c.Assert([]string{"a","b","c"}, jc.Contains, "c")
[01:55] <davecheney> doesn't work
[01:55] <menn0> davecheney: did you ever figure out the issue with tests leaving behind lots of stuff in tmp?
[01:55] <menn0> davecheney: my merge run just broke because the disk was full
[01:55] <davecheney> menn0: yes
[01:55] <davecheney> i logged the issue
[01:55] <davecheney> it's very hard to fix
[01:55] <davecheney> short version
[01:56] <davecheney> the mongo suite thing that caches mongos between suites
[01:56] <davecheney> lacks a signal to say "tehre are no more suites, shut yourself down"
[01:56] <davecheney> so the last suite will finish
[01:56] <davecheney> the test process will exit
[01:56] <davecheney> and mongo will die because it's parent died
[01:57] <axw> davecheney: can we not just run the tests within a script with $TMPDIR set to something temporary, then rm -f $TMPDIR after the test run?
[01:57] <davecheney> but the merge failing on the bot is a differnt issue
[01:57] <davecheney> axw: maybe
[01:57] <davecheney> i haven't looked into fixing the issue
[01:57] <davecheney> i just cron up
[01:57] <axw> I think we used to do that with tarmac
[01:57] <davecheney> rm -rf /tmp/test-mgo*
[01:58] <axw> fair enough
[01:58] <davecheney> but that bot is made afresh on each test
[01:58] <davecheney> it shouldn't fill up
[01:58] <davecheney> because it is a new machine every time
[01:58] <axw> ah yeah
[01:58] <davecheney> the leak is ~43mb per pacakge
[01:58] <axw> nice
[01:58] <davecheney> i think it's possible to fix the leak
[01:58] <davecheney> but we'd have to push gc.Mkdir() right down intot he mongo testing suite
[01:59] <davecheney> but seriously, why is jc.Contains useless ?
[01:59] <davecheney> params_test.go:265: c.Assert(imports, gc.Not(jc.Contains), "state")
[01:59] <davecheney> ... obtained []string = []string{"cert", "constraints", "instance", "juju/arch", "mongo", "network", "replicaset", "rpc", "rpc/rpcreflect", "service/common", "service/upstart", "state/backups", "state/multiwatcher", "storage", "tools", "utils", "utils/ssh", "version"}
[01:59] <davecheney> ... expected string = "state"
[01:59] <davecheney> ... Obtained value is not a string and has no .String()
[02:05] <menn0> davecheney: this could help with mongo suite issue: https://code.google.com/p/go/issues/detail?id=8202
[02:06] <menn0> letting us run something at the end of the test run
[02:09] <davecheney> yes, it will be very useful
[02:16] <davecheney> menn0: but it means 1.4 everywhere
[02:16] <davecheney> which is basically impossible
[02:18] <menn0> davecheney: ok. I didn't look into which Go version this was part of.
[02:19] <jw4> names package update to reflect simpler UUID based Action ID's : PTAL https://github.com/juju/names/pull/32
[02:19]  * jw4 thought we'd rolled reviewboard out to the names package recently?
[02:21] <davecheney> menn0: the magic is baked into the test runner that the go tool generates during the build
[02:21] <davecheney> jw4: is rb watching that repo ?
[02:21] <davecheney> JYNX!
[02:21] <jw4> davecheney: I thought I saw ericsnow say something about that
[02:22] <menn0> davecheney: yep I realise that. just didn't know what version the feature had been added.
[02:24] <menn0> thumper: this canary environment stuff is working out pretty well. 100's of genuine test failures.
[02:24] <thumper> I guess that's good
[02:24] <menn0> thumper: i suspect the number of fixes required will actually be a lot smaller
[02:28] <davecheney> jw4: change looks ok
[02:28] <davecheney> i can't lgtm it
[02:28] <jw4> thanks davecheney
[02:28] <davecheney> i'm too scared of compatibility issues
[02:29] <jw4> davecheney: yeah, we're still skating on "no-one is using actions yet"
[02:29] <davecheney> menn0: canary environment ?
[02:29] <davecheney> jw4: someone else will have to make that call
[02:29] <jw4> davecheney: kk
[02:29] <jw4> fwereade_: ? ^^
[02:31] <menn0> davecheney: as discussed in standups, it's a fully-featured environment that gets created in ConnSuite.SetupTest designed to screw things up when we forget to filter by env UUID. The data for the canary env gets returned unexpectedly breaking tests.
[02:31] <menn0> davecheney: undecided if it will just stay there
[02:31] <menn0> davecheney: but it's useful for finding issues right now.
[02:37] <davecheney> ok
[02:37] <davecheney> +1 to destructive testing
[02:38] <menn0> davecheney, thumper: I'm just checking the performance hit that the canary environment incurs... not good
[02:38] <menn0> 40-50% on my machine
[02:39] <menn0> so it might not stay there
[02:39] <menn0> a more targetted approach might be required
[02:39]  * thumper nods
[02:53]  * thumper glares at wallyworld
[02:53] <wallyworld> wot
[02:53] <thumper> I shouldn't have been talked into fixing this damn bug
[02:53] <wallyworld> \o/
[03:01] <thumper> stabby stabby
[03:01] <thumper> well, the tests are doing the right thing
[03:01] <thumper> ...
[03:01] <thumper> finding bugs in my code
[03:09] <thumper> ok... I think I have this done now
[03:10] <thumper> gah...
[03:10]  * thumper enfixorates some more
[03:16] <thumper> davecheney: jc.Contains is for string in string
[03:16] <thumper> davecheney: not item in slice
[03:16] <thumper> davecheney: which I dearly would have liked to use earlier too
[03:16] <thumper> davecheney: I think it is poorly named
[03:16] <thumper> davecheney: you can blame me for that
[03:16] <davecheney> s'ok
[03:16] <davecheney> i found an example
[03:16] <davecheney> test is proposed
[03:19] <thumper> wallyworld, menn0: http://reviews.vapour.ws/r/498/diff/
[03:19] <thumper> menno because you looked at it before
[03:19] <wallyworld> about time
[03:19] <thumper> wallyworld: because you made me do it
[03:20] <davecheney> just saw this fail, FAIL: upgrade_test.go:437: UpgradeSuite.TestLoginsDuringUpgrade
[03:24]  * thumper takes kids into town to get sushi
[03:31] <menn0> davecheney: can you get the details of the failure to me?
[03:32] <menn0> thumper-sushirun: looking
[03:33] <davecheney> menn0: sorry, closed the window
[03:34] <menn0> davecheney: np. was it on your machine?
[03:37] <davecheney> yeah
[03:43] <menn0> davecheney: there's another one in that suite that occasionally fails. I have a ticket for that.
[03:45] <davecheney> anyone ? http://reviews.vapour.ws/r/512/
[03:45] <davecheney> i'd like to have the argument about names today
[03:45] <davecheney> rather than monday
[03:49] <davecheney> make that monday week
[03:49] <jw4> davecheney: which names argument?  DB interface?
[03:49] <axw> wallyworld: I answered my own question about Xen; it's a general thing, not EC2-specific
[03:49] <axw> so name is stable
[03:50] <davecheney> yup
[03:50] <davecheney> of course
[03:50] <wallyworld> ok
[03:50] <davecheney> if nobody cares about the name
[03:50] <davecheney> or nobody has the will to argue
[03:50] <davecheney> that is also fine
[03:50] <davecheney> but it is spelt DB with two spaces after it :)
[03:50] <jw4> davecheney: you had me til the two spaces
[03:50] <jw4> davecheney: now I'm feeling argumentative
[03:52]  * davecheney cracks knucles
[03:52] <jw4> ah; hate to dissapoint you - I was just joking - I like DB
[03:52] <jw4> ;)
[03:52] <davecheney> all the good names are taken, several times over
[03:52] <davecheney> environ, env, db, state
[03:52] <davecheney> one in every package
[03:52] <davecheney> at least
[03:53] <jw4> I know, just like John
[03:53] <davecheney> jw4: i'd be happy to name the interface John
[03:53] <jw4> (and Dave for that matter)
[03:53] <jw4> haha
[04:09]  * thumper finally submits the branch for master
[04:21] <menn0> anastasiamac: nice job on sorting out that bug
[04:55] <anastasiamac> menn0: thnx for finding it :-) it was gr8 fun to fix
[04:55]  * anastasiamac is kind of a fan of strict accessor/mutator separation.. :-p
[06:06] <wallyworld> axw: can i offer you a small one? http://reviews.vapour.ws/r/516/
[06:07] <axw> looking
[06:11] <axw> wallyworld: lgtm
[06:11] <wallyworld> tyvm
[08:44] <mattyw> morning all
[08:56] <TheMue> morning
[09:18] <voidspace> morning all
[09:25] <TheMue> voidspace: o/
[09:50] <dimitern> morning mattyw, TheMue, voidspace
[09:51] <TheMue> dimitern: morning
[09:52] <mattyw> dimitern, TheMue voidspace morning
[09:52] <TheMue> mattyw: o/
[09:54] <voidspace> mattyw: o/
[09:54] <voidspace> dimitern: o/
[09:55] <mattyw> lots of people waving with their left hands - that's what I like to see
[09:55] <TheMue> mattyw: \o/
[09:57] <TheMue> mattyw: also there's no face, so maybe you see them from behind? ☺︎/
[09:58] <mattyw> TheMue, these are all good points
[09:58] <TheMue> mattyw: but best and most simple is to interpret it your way ;)
[10:41] <perrito666> morning
[12:08] <fwereade_> axw, ping
[12:09] <fwereade_> axw, I am looking at the charm storage changes
[12:11] <fwereade_> axw, it seems there is no way to ask where to download a charm from any more
[12:12] <fwereade_> axw, and so ISTM we have to depend on some funky magic whereby archive urls are always transformed versions of the charm urls in question
[12:37] <axw> fwereade_: who has no way to ask where to download from?
[12:37] <axw> the unit agent?
[12:37] <fwereade_> axw, yeah
[12:38]  * axw rolls back memory
[12:38] <fwereade_> axw, shouldn't the state server know where they can be downloaded from, and be able to tell the unit agent, rather than the unit agent inferring same?
[12:40] <axw> fwereade_: the problem I had with that was that the facades don't know anything about how they should be queried
[12:41] <fwereade_> axw, sorry, not quite following
[12:42] <axw> fwereade_: the API server is hosting the charm storage, right? how does it figure out the URL to send to the client?
[12:42] <fwereade_> axw, how does it figure out the URL to send to the client when new state servers are added? ;p
[12:43] <axw> fwereade_: the facade doesn't even know which address it should be contacted on - that's all at a higher level
[12:43] <axw> and the client knows what address it has connected to already
[12:44] <axw> we could do relative locations?
[12:45] <fwereade_> axw, I don't see why the facade needs to concern itself with that?
[12:46] <fwereade_> axw, IIRC what we used to do was ask the state server for the charm's archive URL
[12:46] <fwereade_> axw, we used to get that from state
[12:46] <fwereade_> axw, we also get things like lists of state server addresses over the api
[12:48] <axw> fwereade_: we could get a list of URLs (one for each API server), if that's what you're getting at?
[12:48] <axw> it seems a little counterproductive, since the API server is clearly up and available if it's responding to a request for URL... :)
[12:49] <fwereade_> axw, right, but it creates a distributed assumption about exactly where the charm server lives
[12:49] <fwereade_> axw, it's already moved once
[12:50] <axw> fair enough
[12:50] <fwereade_> axw, what long-term guarantees do we have that all state servers will always be charm servers, and will always use serve them on that path?
[12:50] <axw> fwereade_: it was my understanding that we'd always proxy through the API server
[12:51] <axw> I see your point though, it would be safer to tell the client
[12:51] <axw> also means other clients don't need that intelligence/stupidity recoded
[12:52] <fwereade_> axw, yeah
[12:52] <axw> I'll log a bug
[12:53] <fwereade_> axw, cheers -- do you reckon there's half a chance of getting it scheduled soonish?
[12:54] <axw> fwereade_: I'm happy to take a look early next week, could do with a rest from thinking about block devices
[12:54] <fwereade_> axw, awesome
[12:56] <axw> fwereade_: https://bugs.launchpad.net/juju-core/+bug/1394976
[12:56] <mup> Bug #1394976: api/uniter: Charm.ArchiveURL should query API server <juju-core:Triaged> <https://launchpad.net/bugs/1394976>
[13:02] <axw> fwereade_: (just out of curiosity) is there really any rush? because it's just the uniter, there's not backwards compatibility issue? I mean, even if we changed the path at which we served the archives, it wouldn't be the end of the world if the uniter threw a few errors before upgrading
[13:02] <axw> is there another reason I'm missing?
[13:06] <fwereade_> axw, ehh, I wanted to patch out the api so I could do some proper testing in the uniter and got all angried up when I couldn't find an api call to patch
[13:08] <axw> fwereade_: fair enough :)
[13:08] <perrito666> katco: https://twitter.com/ShiroSirius/status/535515056528969728/photo/1
[13:09] <axw> fwereade_: in the two new workers I just landed for storage, they accept interfaces rather than an api/*.State struct
[13:09] <fwereade_> axw, there might not be that much rush though, I am strongly tempted to just write the api call I need anyway, definitely ping me before you start work on it ;)
[13:09] <axw> so I managed to write a worker without any API at all...
[13:09] <fwereade_> axw, that is awesome
[13:10] <axw> sure
[13:10] <fwereade_> axw, the uniter api is sadly a bit more involved and a bit harder to patch out -- *unless* I just write that method, because there are actually only 2 methods I need on it at the moment, and it's only the charm one that's awkward
[13:25] <perrito666> hey, can I, from juju client, know which of the state servers of an HA setup is the master?
[13:31] <fwereade_> perrito666, that's awesome
[13:31] <fwereade_> perrito666, http://imgur.com/uVWFN92
[13:31] <perrito666> heh seems to be a trend these days the coder barbie thing I just saw the one of emacs vs vim and cracked
[13:38] <fwereade_> perrito666, yeah, it's *awesome*, I've just spent 10 minutes looking at examples and laughing like a drain
[14:32] <perrito666> natefinch: ping?
[14:37] <natefinch> perrito666: sorry, gotta run a quick errand for my wife, mind if we move it later?
[14:37] <perrito666> np
[14:38] <perrito666> natefinch: actually I suddenly have to rush run an urgent one too
[15:03] <wwitzel3> ericsnow, perrito666, natefinch
[15:04] <natefinch> stupid friggin' chrome on utopic
[15:50] <natefinch> ahh crud, school thanksgiving party thing.. gotta leave in a few minutes.
[15:50] <natefinch> ericsnow: if you run out of things to do, look at output variables.  Should be pretty well spec'ed out
[15:50] <natefinch> ericsnow: I'll try to figure out how to split up GCE work, but not going to have time to do it now
[15:53] <ericsnow> natefinch: no worries
[16:11] <perrito666> fwereade_: voidspace I am reviewer next tue but Ill be on holiday, back on fri when you two are reviewers does any of you want to swap with me so we dont have a day with only one rev and I get to do some reviewing?
[16:18] <voidspace> perrito666: fine with me
[16:18] <perrito666> deal then :D
[16:19] <voidspace> perrito666: can you swap them in the calendar
[16:19] <perrito666> yup, on it
[16:21] <perrito666> voidspace: I created new events
[16:21] <perrito666> bc if I change those i seem to change the whole series
[16:21] <perrito666> which is not good
[16:21] <voidspace> perrito666: ah, right - thanks
[16:48] <ericsnow> perrito666: what where those two issues you brought up during standup? (something about filenames and archives)
[16:55] <voidspace> dimitern: ping
[16:55] <dimitern> voidspace, pong
[16:55] <voidspace> dimitern: you said to look at the address collection
[16:56] <dimitern> voidspace, yeah?
[16:56] <voidspace> dimitern: I've been looking in the state package at the address stuff - that's mostly api server addesses
[16:56] <voidspace> dimitern: and in machine.go
[16:56] <voidspace> dimitern: the machine doc stores address info - is that what you meant?
[16:56] <dimitern> voidspace, it does but it shouldn't :)
[16:56] <voidspace> dimitern: I've also re-read the container addressability doc - and updated it a bit
[16:56] <voidspace> dimitern: heh
[16:56] <voidspace> dimitern: where is the address collection?
[16:57] <dimitern> voidspace, the idea is to have a separate addresses collection
[16:57] <voidspace> dimitern: I've tried grepping but failed
[16:57] <voidspace> dimitern: ah...
[16:57] <voidspace> dimitern: and have machine doc reference that
[16:57] <wwitzel3> fwereade_: *poke* need some of your time for the juju-run stuff I addresses
[16:57] <wwitzel3> addressed
[16:57] <dimitern> voidspace, which will contain "proofed", verified addresses linked properly to machines, subnets, etc.
[16:57] <voidspace> dimitern: right
[16:58] <dimitern> voidspace, ideally we'll drop the addresses from the machine doc at some point
[16:58] <fwereade_> wwitzel3, oh *hell* sorry
[16:58] <dimitern> voidspace, even now the addresses there are considered incomplete, plain wrong or unusable
[16:58] <wwitzel3> fwereade_: no trouble, you told me you'd forget and I would have to poke you today :)
[16:58] <voidspace> dimitern: hah, wonderful
[16:59] <dimitern> voidspace, :)
[16:59] <dimitern> voidspace, we'll fix that as we go
[17:00] <voidspace> dimitern: will the new address collection just be used for where we're managing addresses (ec2 with default vpc and maas)?
[17:00] <voidspace> so just for the new stuff
[17:01] <dimitern> voidspace, if you have a look at the older network model doc (the one with more details like the state docs and fields) there are some pointers what we need
[17:01] <voidspace> dimitern: cool, thanks
[17:01] <voidspace> I have that starr3ed
[17:01] <voidspace> *starred even
[17:01] <dimitern> voidspace, yeah - it should contain only addresses we know and can match (or manage)
[17:02] <voidspace> dimitern: "Juju networking model specification"
[17:03] <dimitern> voidspace, but please keep in mind that doc is a bit obsolete now by the "phase 1" model (i.e. compare the statements/assumptions in the old doc with the similar ones in the new model)
[17:03] <voidspace> dimitern: sure, I've just read that so its fresh
[17:03] <dimitern> voidspace, that's the one I think - it should say it's a low level tech spec
[17:04] <voidspace> dimitern: actually this one says "This document presents a high-level draft specification for discussion and approval."
[17:04] <dimitern> voidspace, hmm, so not this one, just a sec..
[17:04] <voidspace> dimitern: https://docs.google.com/a/canonical.com/document/d/1UzJosV7M3hjRaro3ot7iPXFF9jGe2Rym4lJkeO90-Uo/edit#heading=h.a92u8jdqcrto
[17:05] <voidspace> oops
[17:05] <voidspace> not that one
[17:05] <voidspace> https://docs.google.com/a/canonical.com/document/d/11KbAnVWf8GBJYznOEpzqSRxY7Os7FQSL9huIt1hq1Ao/edit#
[17:05] <voidspace> This one
[17:05] <dimitern> yeah
[17:05] <dimitern> no
[17:05] <dimitern> :)
[17:06] <voidspace>  so, uhm... which one?
[17:06] <dimitern> I've sent you a link in a pm
[17:07] <voidspace> ah!
[17:18] <fwereade_> wwitzel3, that's only a hair away from a ship-it-with-trivials, just explain why my suggestion for keeping the old form of newRelationIdValue is dumb
[17:33] <wwitzel3> fwereade_: yeah, so the way f.Var works internally, you must assign the value to the exact same pointer, if you want the flags to stack in the help output, e.g. -r, --relation
[17:37] <jw4> fwereade_: params.Entites use string for the Tag type instead of names.Tag
[17:38] <sinzui> Anyone, everyone there is an issue with 1.20.12 :( https://bugs.launchpad.net/juju-core/+bug/1395081 relates to a change in https://launchpad.net/juju-core/+milestone/1.20.12 that we need to identify quickly
[17:38] <mup> Bug #1395081: 1.20.12 breaks neutron-gateway, since all interfaces are brought up <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1395081>
[17:42] <jw4> fwereade_: can I make a params.Tags struct that is strongly typed?
[18:01] <jw4> fwereade_: fwiw, we already have a params.Tags type which we're using elsewhere
[18:34] <voidspace> happy weekend everyone
[18:35] <voidspace> g'night all
[18:38] <dimitern> wwitzel3, natefinch, perrito666, guys, urgent bug fix review - who can have a look? http://reviews.vapour.ws/r/518/
[18:38] <dimitern> the bug is https://bugs.launchpad.net/juju-core/+bug/1395081
[18:38] <mup> Bug #1395081: 1.20.12 breaks neutron-gateway, since all interfaces are brought up <cloud-installer> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1395081>
[18:39] <natefinch> looking
[18:39] <natefinch> are there side effects to us *not* bringing these up?
[18:40] <dimitern> natefinch, not really - if anything it was messing up maas environments for is
[18:40] <perrito666> dimitern: looks a lot like you are reverting or partially reverting a patch, could you add a reference to it in the commit?
[18:41] <dimitern> natefinch, and it's really *my bad*, because I backported that from trunk, but accidentally changed the behavior between 1.20.11 and 1.20.12
[18:41] <dimitern> perrito666, it's not a complete revert, it's just dropping some code which was the source of the issue - this code is already gone in more recent versions
[18:44] <dimitern> perrito666, updated the PR to include a link to the PR that changed that part of the code most recently
[18:44] <natefinch> cool
[18:45] <natefinch> dimitern: LGTM'd
[18:46] <dimitern> natefinch, thanks! and I've just confirmed it with the live test
[18:52] <bac> marcoceppi: you still going to do an amulet release today?
[18:53] <marcoceppi> bac: yes
[18:53] <bac> yay
[19:28] <fwereade_> jw4, don't tags get sent over the wire as strings anyway?
[19:29] <fwereade_> jw4, and don't we have to do manual stuff at the other end to turn them back into the right sort of tags anyway?
[19:58] <mgz> how do I set the log level of root to be debug rather than having that override up to warning that happens now?
[19:58] <mgz> I am failing to find this documented anywhere
[20:04] <natefinch> I think thumper is the only one who understands loggo
[20:05] <mgz> ...someone must have needed to debug juju at some point though,,,
[20:05] <mgz> I've not done it since that change, and I am currently going insane
[20:12] <perrito666> how considerate, x crashed
[20:13] <natefinch> mgz: I think juju set-environment logging-config "root=DEBUG"
[20:13] <natefinch> mgz: unless someone invalidated juju help logging
[20:14] <natefinch> which is entirely possible given our history of keeping the help up to date
[20:15] <mgz> natefinch: ta, seems we also have a logging-config thing to go in environments.yaml as well now?
[20:16] <natefinch> mgz: I think anything you can set with set-environment can be set in environments.yaml ... not that we actually have either documented anywhere
[20:32] <katco> if anyone wants to know more about the new leadership/lease services: http://reviews.vapour.ws/r/519/
[20:46] <natefinch> finally uploaded all my music to google music... I'd forgotten how much I like listening to music while I hack
[21:09] <jw4> fwereade_: we can discuss - but the short answer is no, it doesn't have to be that way
[21:14] <fwereade_> jw4, ahh, a TagSlice with a SetJSON or something? nice
[21:14] <fwereade_> jw4, I guess we'd need an InvalidTag type or something though?
[21:16] <jw4> fwereade_: what I found with the ActionTags (before I knew we were 'supposed' to convert to string before using) is that the reason they had trouble serializing was because the fields were private
[21:16] <fwereade_> jw4, ah yes
[21:16] <jw4> fwereade_: if we accept public fields then they serialize just fine
[21:16] <fwereade_> jw4, right, but we want them to be actual strings
[21:17] <fwereade_> jw4, over the wire
[21:17] <jw4> fwereade_: how come? (They all implement String() fwiw)
[21:17] <fwereade_> jw4, I have no interest in forcing that sort of structure on every client
[21:17] <jw4> fwereade_: I see
[21:17] <fwereade_> jw4, and I want people to be able to do things like use them as map keys
[21:18] <jw4> fwereade_: you mean in other client languages, or does Go not allow that either?
[21:18]  * jw4 goes to check
[21:19] <fwereade_> jw4, in general, but specifically in python I guess
[21:19] <fwereade_> jw4, seriously, a tag over the API is a string
[21:19] <fwereade_> jw4, smarter representations in go? awesome
[21:20] <fwereade_> jw4, subverting the deliberately trivial wire-format representation of an entity? not so much ;)
[21:20] <jw4> fwereade_: lol
[21:21] <jw4> fwereade_: okay - so in the params types should we not be using names.Tag or names.*Tag ?
[21:22] <fwereade_> jw4, yeah
[21:22] <fwereade_> jw4, and, hmm, you shouldn't be using charm.Actions either, I think
[21:23] <fwereade_> jw4, params has the same forces in play as internal state stuff does
[21:23] <fwereade_> jw4, if we use types from other packages, we allow changes to those other packages to magically change our wire format/db format
[21:23] <jw4> fwereade_: yeah - I remember that discussion
[21:23] <jw4> fwereade_: good point
[21:25]  * fwereade_ looks at the rest of apiserver/params and starts swearing
[21:25] <natefinch> dude, seriously?:  Bootstrap(ctx BootstrapContext, params BootstrapParams) (arch, series string, _ BootstrapFinalizer, _ error)
[21:26] <jw4> natefinch: what; four return values too much for you?
[21:27] <natefinch> jw4: you get TWO.  No more.
[21:27] <jw4> hehe
[21:27] <jw4> unless it's after a full stop?
[21:27] <natefinch>  (╯°□°）╯︵ ┻━┻)
[21:28] <jw4> haha
[21:28] <jw4> katco: your code is delightful to read
[21:28] <natefinch> katco: I think he wants something ;)
[21:28] <katco> haha
[21:28] <jw4> haha
[21:29] <katco> jw4: thank you so much... that's probably the highest compliment someone could give me
[21:29] <jw4> I just appreciate clean well laid out, well named, elegantly flowing code
[21:29]  * katco beams
[21:29] <jw4> now, do you think you could help me out with something katco ?
[21:29]  * jw4 is kidding
[21:29] <katco> rofl
[21:30] <jw4> about the last line not the prior two
[21:30] <katco> i got it ;)
[21:43] <natefinch> wow... environs.Environ is an interface with 18(!) methods on it.  Sad gopher is sad.
[22:01] <natefinch> happy weekend all
[23:21] <jw4> katco: do you want to write the Actions spec?
[23:35] <katco> jw4: i don't know, i think there are other plans for me
[23:36] <jw4> katco: I don't know what the emoticon is for tongue-in-cheek, but I couldn't help contrasting Leadership Spec with the Actions Spec
[23:36] <katco> oh lol
[23:36] <katco> fwiw i use ":p"
[23:37] <jw4> katco: that makes sense - I think of that as tongue sticking out, but that's probably more like it
[23:38] <katco> oh no you're right
[23:38] <katco> but that's for when i'm feeling cheeky :)
[23:38] <jw4> hehe
[23:38] <jw4> :-J
[23:39] <katco> lol there you go