[00:20] <fwereade> davecheney, pong
[00:40] <davecheney> fwereade: just checking in about that config hook bug
[00:40] <davecheney> but i solved my own problem
[00:40] <fwereade> davecheney, ah cool
[00:41] <fwereade> davecheney, the config hook -- I, er, just remembered python wrong and just kept on reinforcing my own crackfulness :/
[00:41] <davecheney> fwereade: fairy nuf
[00:41] <davecheney> it worked properly for a while
[00:41] <davecheney> but i'll stop blaiming the charmers for breaking the charm
[00:51] <fwereade> davecheney, it did change pretty recently, last few days, and that's the only time I've seen the bug exposed
[01:01] <davecheney> fwereade: was broken for 1.9.4
[01:01] <davecheney> possibly not broken for 1.9.3
[01:03] <davecheney> fwereade: https://bugs.launchpad.net/juju-core/+bug/1090176/ raised on 14/12
[01:03] <_mup_> Bug #1090176: worker/uniter: precise:wordpress charm is unstable <juju-core:New> < https://launchpad.net/bugs/1090176 >
[01:44] <davecheney> holy shit launchpad is being a bitch today
[01:44] <davecheney> EOF after EOF
[06:58] <fwereade> davecheney, thanks, sorry I missed that bug
[07:44] <fwereade> rogpeppe, ping
[08:04] <rogpeppe> fwereade: pung
[08:07] <fwereade> rogpeppe, heyhey
[08:07] <rogpeppe> fwereade: mornin'
[08:09] <fwereade> rogpeppe, I am wondering about InitDir and LogDir, and how we should be setting those for principal units such that their subordinates are set up right, but in such a way that we can run sane tests
[08:10] <fwereade> rogpeppe, eg currently I can't test actual subordinate deployment without hitting /etc/init
[08:10] <rogpeppe> fwereade: yeah, i've wondered about this
[08:10] <rogpeppe> fwereade: python just does it with mocks, presumably
[08:11] <fwereade> rogpeppe, the obvious answer is to just make the default InitDir and LogDir in the deployer package accessible, so we can swap them out for tests
[08:11] <fwereade> rogpeppe, but I'm not quite sure that's actually the right thing to do
[08:12] <fwereade> rogpeppe, a bit too much action-at-a-distance for my tastes
[08:12] <rogpeppe> fwereade: are you thinking of making them parameters?
[08:13] <fwereade> rogpeppe, maybe-probably, but the question that is really vexing is the ultimate source of those values
[08:14] <fwereade> rogpeppe, ah, sorry, you mean command line params?
[08:15] <fwereade> rogpeppe, because I am still very keen on the idea that we can basically drop all the command-line params except entityName and dataDir
[08:15] <rogpeppe> fwereade: no, i didn't
[08:15] <rogpeppe> fwereade: and i'm working on a CL that does that as we speak
[08:16] <fwereade> rogpeppe, really? awesomesauce
[08:16] <fwereade> rogpeppe, I sketched something similar over the weekend but it's not really primetime-capable yet
[08:18] <fwereade> rogpeppe, the code seemed to be leading me towards an agent package with a Conf{DataDir,EntityName} and a bunch of Read/Write methods for state info bits
[08:19] <fwereade> rogpeppe, (and also the agenty bits of environ/tools.go, and the upgrader, and possibly openState and runTasks from curent jujud)
[08:19] <rogpeppe> fwereade: i'm not changing anything other than the way the parameters get to jujud
[08:20] <rogpeppe> fwereade: but you may be right that that's the way to go
[08:20] <fwereade> rogpeppe, ah, interesting, how are you doing bootstrap?
[08:20] <rogpeppe> fwereade: just plonk the params in files rather than put them on the command line
[08:20] <fwereade> rogpeppe, if the above suggestion doesn't immediately turn you off I will probably do a bit more in that direction
[08:20] <fwereade> rogpeppe, I was wondering in particular about the paths to those files for bootstrap vs for agents
[08:21] <fwereade> rogpeppe, but this is not actually a very interesting thing to ask you
[08:21] <fwereade> rogpeppe, I shall await a CL with good cheer
[08:22] <rogpeppe> fwereade: why should bootstrap be different?
[08:22] <rogpeppe> fwereade: (perhaps i just haven't encountered the problem yet!)
[08:23] <fwereade> rogpeppe, it doesn't have its own directory, but the agents do, that's all
[08:24] <fwereade> rogpeppe, putting the files it needs *somewhere* is easy -- putting them in the *right* place seemed a bit trickier
[08:24] <rogpeppe> fwereade: for the time being, i was keeping the parameters global
[08:25] <rogpeppe> fwereade: (thinking that we can move towards a per-agent model as a next step - the main thing is getting params off the command line)
[08:25] <fwereade> rogpeppe, my only issue there is that you still need per-agent storage for password/oldPassword
[08:26] <fwereade> rogpeppe, so I'm not sure whether it's even possible to *completely avoid the issue
[08:26] <rogpeppe> fwereade: initial-password can still be global
[08:26] <fwereade> rogpeppe, so we always set the same initial password for everything? feels like a bit of a step back
[08:27] <fwereade> rogpeppe, (but password cannot be, anyway, right?)
[08:28] <rogpeppe> fwereade: we do currently use the same initial password for all agents started from cloudinit
[08:28] <rogpeppe> fwereade: and password already uses the entity name specific storage
[08:30] <fwereade> rogpeppe, the first bit surprises me -- I'd expect the provisioner to set an initial password for the MA and write that into the cloud-init
[08:31] <fwereade> rogpeppe, similarly to what the deployer does before installing the upstart job
[08:31] <rogpeppe> fwereade: the cloudinit is passed a single StateInfo
[08:32] <rogpeppe> fwereade: that tells anything in the new instance how to connect to the state.
[08:32] <fwereade> rogpeppe, right, and shouldn't that StateInfo have a fresh password, generated by the provisioner and assigned to the machine?
[08:33] <rogpeppe> fwereade: that it does
[08:33] <rogpeppe> fwereade: your point being?
[08:34] <fwereade> rogpeppe, that I don;t see how a global initial-password can fit in with per-entity initial passwords, because it's perfectly possible that two new entities might come up at the same time and each need their own initial-passwords
[08:35] <fwereade> rogpeppe, if we only have one slot to store that in, we have a problem
[08:35] <rogpeppe> fwereade: ah, one mo. it's not a problem for the provisioner vs MA, but it is a problem for the MA starting the unit agent
[08:35] <fwereade> rogpeppe, yeah, indeed
[08:36] <fwereade> rogpeppe, sorry, that is my perpetual perspective, I frequently forget that it is different to other peoples'
[08:36] <fwereade> 's
[08:38] <rogpeppe> fwereade: in which case, i don't see (at this moment) any particular problem with having bootstrap-state getting the password from the machine agent's dir (or we could have a "bootstrap" entity name if we wanted)
[08:39] <fwereade> rogpeppe, a possibility is to keep the command-line args to bootstrap, because that's a one-shot, and we don't need t worry about it being run with stale data
[08:40] <rogpeppe> fwereade: that is a possibility, yeah. except i'd like to reuse the code that makes the state.Info, but perhaps it's not worth it.
[08:41] <fwereade> rogpeppe, I didn't finish it at the w/e but I was coming down on that side of the question
[08:41] <rogpeppe> fwereade: and bootstrap-state is different too, as it doesn't change the password
[08:42] <fwereade> rogpeppe, I thought that was indeed maybe the case but I didn't dig in
[08:42] <rogpeppe> fwereade: it is the case - that initial password is changed when the first connection arrives
[08:45] <fwereade> rogpeppe, ok, cool
[08:45] <fwereade> rogpeppe, well, I shall hold off from any fancy agent packages for now
[08:46] <rogpeppe> fwereade: what else did you see as a possible client for this possible package (other than jujud itself)?
[08:47] <fwereade> rogpeppe, when we're deploying, ISTM that it would be nice to construct the appropriate Conf and just WriteAddrs(), WriteCACert(), WriteOldPassword()
[08:47] <rogpeppe> fwereade: problem is that it doesn't work for cloudinit
[08:47] <rogpeppe> fwereade: and in the end it's just three file names
[08:48] <fwereade> rogpeppe, also WriteTools, I suspect
[08:49] <fwereade> rogpeppe, and, honestly, "it's just 3 file names" is not IMO a valid argument for having 2 or 3 copies of the same data
[08:49] <fwereade> rogpeppe, I think the bar for data duplication is much higher than that for code duplication
[08:50] <rogpeppe> fwereade: three path name constants ? :-)
[08:51] <fwereade> rogpeppe, one day, agents will have some mechanism by which we can update certs and servers, right?
[08:52] <rogpeppe> fwereade: yup
[08:53] <fwereade> rogpeppe, ok, that's a derail, sorry, I think I have a tighter focus if I can articulate it
[08:54] <fwereade> rogpeppe, I feel the burden of proof is on you, to demonstrate the overwhelming advantages of separating the code for reading and writing the same information
[08:54] <fwereade> rogpeppe, but I suspect you do not share this perspective
[08:55] <rogpeppe> fwereade: i tend to factor out only when it becomes useful. currently we read this info in one place only, and write it in two places (but in two different ways)
[08:55] <rogpeppe> fwereade: so actually factoring out will only add code currently (package overhead)
[08:56] <rogpeppe> fwereade: but i agree that it will probably be a good thing for the future
[08:58] <fwereade> rogpeppe, my own global perspective is that we already have agenty stuff scattered all over jujud, environs, and deployer, and that the overhead of an additional package to collect those things is dwarfed by the current overhead of having to remember how all those bits fit together
[08:58] <fwereade> rogpeppe, it's primarily a my-puny-brain argument
[08:59] <rogpeppe> fwereade: if it really is possible to collect all those things in a nice way, i'm definitely +1
[09:01] <fwereade> rogpeppe, my problem is basically that I can't see anyone agreeing to review the change if it happens all at once, but that the initial moves to get us into a position where it makes sense are all kinda pointless and inconvenient in isolation
[09:01] <fwereade> rogpeppe, probably I should hack the whole thing out in a frenzy, propose -wip, and also propose a bunch of others with links saying "it may look crazy now, but it lets us do this"
[09:02] <fwereade> rogpeppe, or maybe I should just be biding my time
[09:02] <fwereade> rogpeppe, I believe that the jujud change you are making is a big step in the right direction, and it may be that the landscape will look different once that's in
[09:02] <rogpeppe> fwereade: leave it for now - this CL i have may go in that kind of direction, we'll see
[09:03] <rogpeppe> fwereade: i feel that the most important thing is removing the command-line params (because that makes us upgradable) - the rest is internal refactoring
[09:03] <fwereade> rogpeppe, yeah, agreed
[09:04] <dimitern> rogpeppe: hey, could you take a look please - https://codereview.appspot.com/6940073/
[09:05] <fwereade> rogpeppe, incidentally, how would you feel about old-password rather than initial-password? it makes it a little bit clearer that we can get password-changing for free just by renaming password to old-password
[09:05] <fwereade> rogpeppe, nbd, just a suggestion
[09:06] <fwereade> rogpeppe, aaaanyway, I'll be going for the mocked-dirs approach for InitDir and LogDir
[09:07] <rogpeppe> fwereade: i hadn't thought about it from that perspective before; let me think a mo
[09:07] <fwereade> rogpeppe, with a possible view to one day putting those into whatever state dir you choose for the agent
[09:08] <fwereade> rogpeppe, (one request -- please put them in a subdir, like "agent" or "conf" or something, rather than just in the agent dir)
[09:08] <rogpeppe> fwereade: any particular reason?
[09:09] <fwereade> rogpeppe, tidiness :)
[09:09]  * rogpeppe thinks extra directory hierarchies are often more clutter than tidiness :-)
[09:10] <rogpeppe> fwereade: too many times i've been in situations where everything is buried in small collections of files in too many directories
[09:11] <rogpeppe> fwereade: what is the agent dir *for* if not to store this kind of info?
[09:11] <fwereade> rogpeppe, I guess all the uniter currently has is charm/ and state/, for some reason I thought it was more
[09:12] <fwereade> rogpeppe, but then state/ is uncomfortable in the same namespace as things like addrs and ca-cert, I think
[09:12] <rogpeppe> fwereade: if we were dynamically creating all kinds of different names, i'd agree. but for a few well-known names, i'd prefer them at the top level
[09:12] <rogpeppe> fwereade: i don't think so
[09:13] <rogpeppe> fwereade: we have control over that name space
[09:14] <fwereade> rogpeppe, I'm not sure about our discipline levels though -- I have certainly been thoughtlessly dumping uniter-specific stuff directly into the agent's directory
[09:14] <fwereade> rogpeppe, maybe the answer is that those should be uniter/state and uniter/charm, leaving the "agent" dir to have "agent" things in it
[09:15] <rogpeppe> fwereade: i dunno. if "state" and "charm" are all there are, i don't see a particular need to have them in their own directory. "uniter.state" and "uniter.charm" might be better if you're worried about collisions.
[09:16] <fwereade> rogpeppe, yeah, that's not bad
[09:17] <fwereade> rogpeppe, but as you say probably not even necessary
[09:18] <fwereade> rogpeppe, anyway, do you agree that exposing deployer.InitDir and .LogDir for tests to mess with is probably the right approach?
[09:19] <fwereade> rogpeppe, (for now only)
[09:19] <rogpeppe> fwereade: sounds reasonable, yeah
[09:19] <fwereade> rogpeppe, cool, cheers -- interesting discussion, looking forward to seeing the cmdline params going away
[09:19] <rogpeppe> fwereade: me too :-)
[09:24]  * fwereade -> breakfast
[09:38] <dimitern> rogpeppe: ping
[09:39] <rogpeppe> dimitern: pong
[09:40] <rogpeppe> dimitern: am looking at your CL BTW
[09:40] <dimitern> rogpeppe: ok, thanks!
[10:37] <fwereade_> dimitern, sent a few comments
[10:37] <dimitern> fwereade_: thanks!
[11:00] <jam> mramm: /wave
[11:00] <mramm> jam: /wave back
[11:01] <jam> mramm: do you have mumble installed? We generally chat on mumble.canonical.com
[11:01] <mramm> jam: I don't, installing it now
[11:34] <rogpeppe> dimitern: you've got some comments.
[11:35] <dimitern> rogpeppe: cool, ty
[11:35] <rogpeppe> dimitern: i haven't finished yet, but i thought there's enough for you to be getting on with for the time being
[11:35] <dimitern> rogpeppe: yes,  and i have some from william as well, so I'll get on to it
[11:42] <rogpeppe> dimitern: ping
[11:43] <dimitern> rogpeppe: pong
[11:43] <rogpeppe> dimitern: i'm looking at lines 852 to 873 and wondering what they do that isn't done by lines 874-876
[11:43]  * dimitern looking
[11:44] <dimitern> which file?
[11:44] <rogpeppe> dimitern: service_http.go, sorry
[11:45] <dimitern>  rogpeppe: well, the first part handles the more bizarre urls, while the second part handles the main urls
[11:46] <dimitern> rogpeppe: and also because of the trailing slash auto redirection in net/http server
[11:46] <jam> wallyworld___: if you're still around, I dug into the openstack code, and it looks like TempURL is a WSGI middleware, which hints that it it something that may or may not be actually installed on a given openstack site
[11:46] <dimitern> rogpeppe: *missing trailing slash* actually
[11:47] <jam> wallyworld___: so that would be something to check
[11:47] <wallyworld___> jam: yes, that agrees with what martin said also
[11:47] <wallyworld___> jam: i sent an email to someone who has helped me previously, we'll see what comes of it
[11:48] <rogpeppe> dimitern: can you give me an example?
[11:49] <dimitern> rogpeppe: ok, so I need to handle /v2/tenant-id/servers/<id> but also /v2/tenant-id/servers (no slash at both places), AND also .../ (any url with trailing slash)
[11:49] <jam> wallyworld___: right, so it isn't that you need to have an admin set up a temp key for each user, they can do that themselves. But an admin needed to have the whole site have temporary urls enabled.
[11:49] <dimitern> rogpeppe: the first one will get handled in the /v2/tenant-id/ part, so I need to catch it and handle it with the second
[11:49] <wallyworld___> jam: yes, so we'll see what we are told as to whether it has been setup for canonistack or not
[11:50] <rogpeppe> dimitern: won't the /v2/tenant-id/servers handler catch all of them?
[11:50] <rogpeppe> dimitern: sorry, /v2/tenant-id/servers/
[11:51] <dimitern> rogpeppe: no, because it's /v2/tenant-id/servers
[11:51] <rogpeppe> dimitern: well, you'd need a handler for /v2/tenant-id/servers *and* /v2/tenant-id/servers/
[11:51] <dimitern> rogpeppe: and if it was ../servers/ it will, but I don't need that, since the API expects no slash anywhere at the end
[11:52] <dimitern> rogpeppe: hmm.. I'll try this it may simplify that func
[11:52] <rogpeppe> dimitern: that's easy enough to check for (you could even have a general handler, wrapping another handler, that forbids a trailing slash)
[11:53] <dimitern> rogpeppe: can you give me an example of that?
[11:53] <rogpeppe> dimitern: ok, one mo
[11:58] <rogpeppe> dimitern: http://paste.ubuntu.com/1447373/
[11:58] <fwereade_> yay: http://paste.ubuntu.com/1447375/
[11:59] <dimitern> rogpeppe: ty
[12:00] <rogpeppe> dimitern: that's a fairly general technique - you can use it for all kinds of things
[12:00] <dimitern> rogpeppe: I see, ok, sounds good, will give it a try
[12:01] <rogpeppe> fwereade_: did the juju charm not work before?
[12:01] <fwereade_> rogpeppe, I thought it was a subordinate, and it appears to be acting like one :)
[12:02] <rogpeppe> dimitern: i recommend going for some of my other suggested changes first BTW - they're pretty much orthogonal to the path handling
[12:02] <fwereade_> rogpeppe, however a bunch of the subordinates declare a juju-info interface :/
[12:02] <rogpeppe> fwereade_: yay!
[12:02] <fwereade_> rogpeppe, so I can't work with those
[12:02] <rogpeppe> fwereade_: hmm, is that not allowed now?
[12:03] <fwereade_> rogpeppe, duplicate relations were never allowed, it's a straight-up bug IMO
[12:03] <rogpeppe> fwereade_: ah yeah
[12:03] <fwereade_> sorry a juju-info *relation*
[12:04] <fwereade_> rogpeppe, (requiring juju-* interfaces is ok, but not providing them; and hooks and relations can't start with juju-)
[12:06] <fwereade_> oh, are we meeting?
[12:10] <rogpeppe> fwereade_: good question
[12:10] <rogpeppe> fwereade_: i have some lunch smells coming from downstairs
[12:11] <fwereade_> rogpeppe, oh, no, apparently it's an hour away yet
[12:11] <rogpeppe> fwereade_: cool. mmm scrambled eggs & smoked salmon on bagels. not so healthy but v tasty
=== mohits1 is now known as mohits
[12:58] <jam> so I went to: https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7# but so far nobody else has joined. I know I'm still early, but I figured I'd check if I have the right link.
[12:58] <jam> It was part of one of the calendar invites. (though I seem to have 2 invites... ?)
[13:01] <dimitern> guys?
[13:03] <jam> mramm: we see you, but I don't hear you, or you seem to hear me
[13:03] <jam> rogpeppe: are you still here this week? ^^
[13:04] <rogpeppe> jam: i am
[13:04] <rogpeppe> jam: i'm joining now
[13:04] <jam> sounds good
=== otubo1 is now known as otubo
[14:26] <fwereade_> wallyworld___, ping
[14:26] <wallyworld___> hi
[14:27] <fwereade_> wallyworld___, I seem to be seeing duplicate changes in some of your CLs
[14:27] <wallyworld___> hmmm. i just lbox proposed them, but there's about 3 branches stacked on each other so perhaps it got confused
[14:27] <fwereade_> wallyworld___, for future reference, please ease my puny brain by doing `lbox propose -req lp:some/branch`, and the
[14:27] <fwereade_> wallyworld___, yeah, it doesn't autodetect
[14:28] <wallyworld___> sorry, i did think i did the -req param but i must have messed it up
[14:28] <wallyworld___> too many things on the go
[14:28] <fwereade_> wallyworld___, -req only works the first time you propose I'm afraid
[14:28] <wallyworld___> i'm also used to just using lp
[14:29] <fwereade_> wallyworld___, to fix it I think you need to delete the MP and start again
[14:29] <fwereade_> wallyworld___, from my pov don't waste time with that now
[14:29] <wallyworld___> oh, so if i lbox propose some futher changes, it doesn't work?
[14:29] <fwereade_> wallyworld___, yeah, -req status can't change
[14:29] <wallyworld___> i -req i mean?
[14:29] <fwereade_> wallyworld___, I think it's a property of the LP MP and LP doesn't let yu change it
[14:30] <wallyworld___> lp does handle things correctly
[14:30] <wallyworld___> you can change a base branch and the diffs up the line are all ok
[14:30] <wallyworld___> i'll just try not to have so much stuff in progress
[14:31] <fwereade_> wallyworld___, ha, yeah, that's probably the answer
[14:31] <wallyworld___> part of the issue is the need to land stuff in lock step
[14:31] <fwereade_> wallyworld___, fwiw LP doesn't seem to know that https://codereview.appspot.com/6923056/ and https://codereview.appspot.com/6929055/ share content either
[14:32] <wallyworld___> lp only knw about its own diffs, not codereview
[14:32] <fwereade_> wallyworld___, I *think* lockstep package ugliness is orthogonal to this
[14:32] <wallyworld___> what i mean is i have to delay goose stuff till jujucore is +1, and visa versa
[14:32] <fwereade_> wallyworld___, yeah, but LP is claiming a 600-odd-line diff for each of those, and they definitely share content
[14:33] <wallyworld___> ah ok. that implies i forgot the -req sadly
[14:33] <fwereade_> wallyworld___, meh, it happens :)
[14:34] <rogpeppe> boiler man has just come. will be afk for a little
[14:34] <wallyworld___> plus today go get ate my homework, so when i pushed stuff after that it may have screwed up also
[14:34] <fwereade_> wallyworld___, you have a review on https://codereview.appspot.com/6923056/ which may cover some others too, I will try to figure it out
[14:34] <fwereade_> wallyworld___, haha, ouch, that's happened to me too :)
[14:34] <wallyworld___> i really hate go's lack of proper dependency versioning
[14:35] <wallyworld___> thanks for wading through all my crap though
[14:35] <wallyworld___> i owe you a beer
[14:35] <fwereade_> wallyworld___, np at all, but I may take you up on that all the same ;p
[14:35] <wallyworld___> ok, for sure
[14:36] <wallyworld___> right now, i just want to land them all to clear my plate :-)
[14:36] <fwereade_> wallyworld___, if the bits I've said look good are actually originally from a different branch, feel free to assume their little micro-LGTMs apply
[14:36] <fwereade_> wallyworld___, the only blocker there is the "local" test
[14:37] <wallyworld___> ok, i'll look at the email, which local test?
[14:37] <fwereade_> wallyworld___, https://codereview.appspot.com/6923056/patch/6001/3006
[14:38] <fwereade_> wallyworld___, or rather https://codereview.appspot.com/6923056/diff/6001/environs/openstack/local_test.go
[14:38] <fwereade_> wallyworld___, which lets you see my actual comments
[14:38] <wallyworld___> the was alsoi *think* i just copied the ec2 stuff for that
[14:39] <wallyworld___> bah
[14:39] <wallyworld___> ignore the first bit of garbage above
[14:41] <fwereade_> wallyworld___, (I did mean to fix those tests when I noticed them but... y'know how it is :))
[14:41] <wallyworld___> np, i'll fix the openstack stuff tomorrow
[14:44] <wallyworld___> fwereade_: i'm off to bed now (well after midnight here), thanks for reviewing, have a good break if i don't "see" you again before you go
[14:44] <fwereade_> wallyworld___, cheers, sleep well -- sorry to keep you up
[14:44] <fwereade_> wallyworld___, and happy holidays :)
[14:44] <wallyworld___> np, i was awake anyway, too much to do
[15:04] <fwereade_> rogpeppe, btw, https://codereview.appspot.com/6944058/ has been addressed I think
[15:05] <fwereade_> and, jam or dimitern (or anyone else on?) I would *really* like to get https://codereview.appspot.com/6946071/ merged before I finish today and want for but one LGTM
[15:05] <dimitern> fwereade_: ok, looking
[15:05] <fwereade_> dimitern, awesome
[15:06] <fwereade_> dimitern, if you're new to the uniter you may have questions, ask away as you encounter them
[15:06] <dimitern> fwereade_: sure
[15:09] <dimitern> fwereade_: so basically, instead of reading the state in a few places, you read it once?
[15:09] <fwereade_> dimitern, that is one of the important bits, yes
[15:10] <fwereade_> dimitern, the rough chain is:
[15:10] <dimitern> fwereade_: i didn't see what happened to the ModeStart though
[15:10] <fwereade_> dimitern, keep a local copy of state, because:
[15:11] <fwereade_> dimitern, I need to write my started state, and don't have any other easy way of inferring what it should be, and I don't want to have to read state every time I write it
[15:11] <fwereade_> dimitern, because: I now need to keep track of whether I've run the start hook
[15:11] <dimitern> fwereade_: yeah
[15:11] <dimitern> ok
[15:12] <fwereade_> dimitern, because: I can no longer assume that we've already started when we run config-changed, and the correct action at that point depends on whether we've started
[15:12] <dimitern> fwereade_: I see
[15:13] <dimitern> fwereade_: I'm looking at that exactly
[15:13] <fwereade_> dimitern, I don;t think there ever was a ModeStart -- there's a ModeStarting, which no longer needs to set unit status because ModeConfigChanged will have already done it
[15:14] <fwereade_> dimitern, and then there's the mode that runs "normally" which is ModeAbide
[15:14] <dimitern> fwereade_: yeah, ModeStarting
[15:14] <dimitern> fwereade_: LGTM
[15:15] <dimitern> it's actually not hard to follow
[15:15] <dimitern> :)
[15:15] <fwereade_> dimitern, awesome :D
[15:15] <fwereade_> dimitern, tyvm
[15:37] <fwereade__> rogpeppe, heh, deployer tests will be much easier once you've killed the cmdline params too
[15:37]  * fwereade__ finds something else to do
[17:12] <rogpeppe> fwereade__: ping
[17:12] <fwereade__> rogpeppe, pong
[17:12] <rogpeppe> fwereade__: what do you think of storing the server cert and key inside mongodb?
[17:13] <rogpeppe> fwereade__: so the only time we need to store them in a file is for mongodb itself
[17:13] <fwereade__> rogpeppe, not sure what the benefit is
[17:13] <fwereade__> rogpeppe, we need the cert to connect in the first place though
[17:14] <rogpeppe> fwereade__: no, we never need the server cert to connect
[17:14] <rogpeppe> fwereade__: it's for the server only
[17:15] <fwereade__> rogpeppe, ah, sorry, wrong cert -- and, um, actually not sure at all
[17:15] <rogpeppe> fwereade__: currently the server cert and key gets passed in cloudinit, but with the api server being a task/worker of the machine agent, we don't necessarily know whether we want to do that when we create the cloudinit script
[17:15] <fwereade__> rogpeppe, ah, ok, this makes sense
[17:15] <fwereade__> rogpeppe, yeah
[17:16] <rogpeppe> fwereade__: storing them in mongodb means that anyone with access to mongodb can act as a state server, which seems reasonable
[17:16] <fwereade__> rogpeppe, I am generally -1 on storing anything outside state tbh
[17:16] <fwereade__> rogpeppe, I think I'm firmly +1 on keeping them in mongo
[17:16] <rogpeppe> fwereade__: ha, we can even store the mongodb passwords inside mongo, i think
[17:17] <rogpeppe> fwereade__: and i think that might be necessary
[17:17] <fwereade__> rogpeppe, yeah -- long-term they'll be API passwords, not mongodb passwords, right?
[17:17] <rogpeppe> fwereade__: no, we will need a mongodb password too
[17:17] <rogpeppe> fwereade__: otherwise anyone could get access to the mongodb
[17:18] <fwereade__> rogpeppe, for each agent?
[17:18] <rogpeppe> fwereade__: and bypass the api
[17:18] <rogpeppe> fwereade__: i dunno. probably not. maybe just one password
[17:18] <fwereade__> rogpeppe, that sounds more like it to me, but I may be missing something
[17:19] <rogpeppe> fwereade__: but we'll still need some way of communicating that password to new machines that we might wish to become api servers.
[17:19] <rogpeppe> fwereade__: and i think the solution is simply to make it available through the API
[17:19] <rogpeppe> fwereade__: (only to sufficiently deserving entities, of course)
[17:20] <fwereade__> rogpeppe, yep, I'm convinced
[17:20] <fwereade__> rogpeppe, probably one password per deserving entity, I guess
[17:20] <rogpeppe> fwereade__: maybe, i dunno
[17:21] <rogpeppe> fwereade__: probably, as that's exactly what we do now
[17:21] <rogpeppe> fwereade__: depends if mongodb provides some kind of log of stuff any particular user has done
[17:21] <rogpeppe> fwereade__: if not, there's probably no point
[17:22] <fwereade__> rogpeppe, all will no doubt become clear in the fullness of time :)
[17:22] <rogpeppe> fwereade__: only problem is i can't store the server cert and key in the state currently, because everyone has access to it.
[18:12] <rogpeppe> fwereade__: gotta go, haven't got it working yet, sorry.
[18:13] <rogpeppe> g'night all
[20:36] <hazmat> anybody around?
[20:36] <hazmat> just trying to verify go 1.0.2 is the one with the http client regression
[20:39] <hazmat> cause its also the distro version for golang in quantal i believe..
[22:01] <arosales> davecheney: Hello
[22:03] <arosales> fwereade_:  you guys having a G+ hangout?
[22:05] <davecheney> arosales: doubt it
[22:05] <davecheney> isn't mark on medical leave ?
[22:05] <arosales> he is, but he asked I kick a G+ off if folks were interested in having one.
[22:05] <arosales> davecheney: just saw you and fwereade_ in channel though  . . .
[22:06] <davecheney> william is _supposed_ to be on leave
[22:06] <arosales> :-)
[22:06] <arosales> davecheney: so its just you huh
[22:06] <arosales> at this time anyways
[22:06] <fwereade_> arosales, davecheney: I, er, sort of am -- I'm just writing documentations, which hardly counts as work ;p
[22:06] <davecheney> arosales: two secs, changing computers
[22:06] <fwereade_> arosales, davecheney: but no, I don;t really fancy a call ;)
[22:06] <arosales> fwereade_: hey thats my whole job ;-)
[22:06] <arosales> lol
[22:07] <fwereade_> arosales, it was perhaps hard to detect the irony dripping from my voice
[22:07] <fwereade_> or not ;)
[22:07] <arosales> fwereade_: ah
[22:07] <fwereade_> but, y'know, the CL's still open and if I come back to it in 2 weeks it'll be the last thing I want todo
[22:07] <arosales> fwereade_: davecheney: totally up to you guys on a G+. Only if it is useful or you need some one to say hello to :-)
[22:08] <fwereade_> arosales, I'm good thanks :)
[22:08] <arosales> fwereade_: I'll let you get back to the all too important work of docs ;-)