[02:27]  * thumper tries to formulate some replies
[02:31] <axw> thumper: did you want to look at my local-storage auth change before I land? I have fwereade's LGTM
[02:31] <thumper> axw: have I reviewed it?
[02:31] <axw> thumper: no, just fwereade
[02:31]  * thumper is replying to the upgrade emails
[02:32] <thumper> nah, I trust you, and if fwereade has acked it, that is good enough for me
[02:32] <axw> okey dokey
[02:32] <axw> cool
[02:32] <axw> thumper: the gist is, using TLS client certs for authentication; authentication=authorisation
[02:33]  * thumper nods
[02:58] <thumper> school run time
[03:16] <thumper> axw, wallyworld: reminder on the code review time in 15 min
[03:16] <wallyworld> yep
[03:21] <axw> thanks
[04:26] <thumper> ugh
[04:27] <thumper> having a very meh day
[04:36] <axw> thumper: I didn't really understand this statement in your email- "I think I agree with William here, these are more associated with a
[04:36] <axw> provider rather than just agent config."
[04:36] <thumper> axw: I was thinking that we wouldn't need to put it in the config
[04:36] <axw> my intention was for the provider to control what jobs get put into the MachineConfig, which drives agent.Config creation
[04:36] <thumper> but in state
[04:36] <axw> thumper: yes, but the bootstrap process puts the jobs into state
[04:37] <thumper> the machine jobs are defined in state
[04:37] <thumper> are we talking about the bootstrap jujud process?
[04:37] <thumper> or the machine agent?
[04:37] <axw> yep
[04:37] <axw> um
[04:37] <axw> what's the difference?
[04:37] <axw> cmd/jujud/bootstrap.go
[04:37] <thumper> one is 'jujud bootstrap' the other is 'jujud machine'
[04:38] <axw> currently does an InjectMachine with hard-coded set of jobs
[04:38] <thumper> there is a key/value store in format 1.16
[04:38] <axw> oh right. I'm talking about the former
[04:38] <thumper> for the agent config
[04:38] <thumper> so if you use that, you don't need to teach the format anything new
[04:39] <axw> hmm yes, it just felt a bit wrong to put it into something so free-form... but I suppose the machine agent doesn't care about this at all
[04:39] <thumper> right
[04:39] <thumper> but I do get your meaning
[04:39] <thumper> could be command line params to the bootstrap ?
[04:40] <thumper> although that isn't much better
[04:40] <thumper> and then creates a mix of data sources
[04:44] <axw> thumper: they've all got pros and cons, so I guess key/value will do; at least there's no format change required then
[04:44]  * thumper nods
[04:44] <axw> thumper: it sounds like we're thinking along the same lines regarding upgrades
[04:44] <thumper> good
[04:45] <axw> I was thinking more after I sent my email last night, and that the code that I will need to add for this could be used for state schema upgrades
[04:45] <thumper> even the multi-version jump?
[04:45] <axw> yes definitely
[04:45] <thumper> good
[04:45] <thumper> I think that previously that has been in the "too hard" basket
[04:45] <axw> having to hop along like that sounds horrible
[04:45] <thumper> but it definitely needs to be done
[04:45] <thumper> I keep thinking back to what we did with postgresql
[04:45] <thumper> where we had a number of patch files
[04:46] <thumper> a similar thing could be done for our version changes
[04:46] <thumper> for each minor version, we have a slice of functions to call
[04:46] <thumper> that will modify state based on what was left by the previous call
[04:46] <axw> yep that makes sense
[04:46] <thumper> so going from say 1.16 -> 1.18 would just require the one stack to be called
[04:46] <thumper> but 1.16 -> 1.22 (say) would run three, one after the other
[04:47]  * thumper waves hands
[04:47] <thumper> magic
[04:47] <axw> :)
[04:48] <axw> thumper: so I'm vaguely thinking that there'll be an environs/upgrade package, which will handle generic upgrades, and defer to an optional EnvironUpgrader interface, which an Environ may implement
[04:48] <axw> haven't thought through in much detail yet
[04:49] <axw> environs/upgrade would do schema upgrades
[04:49] <thumper> sounds good to me
[04:49] <axw> EnvironUpgrader would do provider-specific things, like adding jobs
[05:03] <thumper> axw: I'm wondering whether state/upgrade should do schema upgrades given that state has the core "state"
[05:04] <axw> thumper: yes, probably
[05:05]  * thumper calls a wash on today, back tomorrow
[07:12] <rogpeppe> mornin' all
[07:15] <axw> hey rogpeppe
[07:15] <rogpeppe> axw: hiya
[07:22] <rogpeppe> nice to see juju getting a shout out in this talk https://www.youtube.com/watch?v=sYukPc0y_Ro
[07:23] <axw> rogpeppe: yeah, saw that this morning - very nice! :)
[07:39] <rogpeppe> axw: last night thumper mentioned an email thread about upgrades - where is that?
[07:40] <axw> rogpeppe: I emailed fwereade and rogpeppe only; I'll forward to you if you're interested
[07:40] <axw> err not rogpeppe  )
[07:40] <rogpeppe> axw: please
[07:40] <axw> :)
[07:40] <axw> thumper
[07:41] <axw> actually I'll just CC the list, since it's grown into something that everyone will probably care about
[07:41] <rogpeppe> good plan
[07:42] <rogpeppe> wallyworld: hiya
[07:42] <wallyworld> hi
[07:42] <rogpeppe> wallyworld: you've replied to this, but i don't think you've pushed your changes yet : https://codereview.appspot.com/13842044
[07:42] <wallyworld> i have
[07:43] <wallyworld> i pushed to lp
[07:43] <rogpeppe> wallyworld: could you re-propose too, please?
[07:43] <wallyworld> it's been merged also
[07:43] <wallyworld> :-(
[07:43] <rogpeppe> wallyworld: so i can see the changes in codereview
[07:43] <wallyworld> i don't have that branch easily assessicle right now
[07:43] <wallyworld> look at lp
[07:43] <rogpeppe> ok
[07:43] <wallyworld> bit stressed trying to get @^%^@!^%@! gpg working
[07:44] <wallyworld> i can't generate a private key have have Go use it
[07:44] <rogpeppe> wallyworld: but in general it's nice to have the pushed version in codereview because the link is in the commit message
[07:44] <wallyworld> guess so
[07:44] <wallyworld> i hate codereview
[07:44] <rogpeppe> wallyworld: you can't generate a private key?
[07:44] <wallyworld> too hard to use
[07:44] <rogpeppe> wallyworld: funny, i think it's really good, but there y'go
[07:45] <wallyworld> i can generate fine'but when i try and use it in go, it complains it is encrypted
[07:45] <rogpeppe> wallyworld: what library are you using?
[07:45] <wallyworld> so i have a private key block which i got from pgp, then i use keyring, err := openpgp.ReadArmoredKeyRing(bytes.NewBufferString(signedMetadataPrivateKey))
[07:46] <wallyworld> i trying to generate some signed data to test with, i have both public and private key blocks from a test key i generated in gpg
[07:46] <wallyworld> errors.InvalidArgumentError = "signing key is encrypted" ("openpgp: invalid argument: signing key is encrypted")
[07:46] <wallyworld> is the error
[07:47] <wallyworld> i'm not sure how to make a signing key that is unencrypted
[07:48] <wallyworld> rogpeppe: i hate codereview because i can't see the whole diff at once, so it's hard for me to navigate around the changes
[07:48] <rogpeppe> wallyworld: i like codereview because i can see the whole file in context (and all the comments)
[07:48] <rogpeppe> wallyworld: but it would be nice if it was much faster
[07:49] <wallyworld> yeah
[07:49] <wallyworld> rogpeppe: i got to go and buy dinner, but if you had a clue as to how I can get a pulic and private key i can use with openpgp in go that would be awesome
[07:50] <rogpeppe> wallyworld: i'll have a look
[07:50] <wallyworld> thanks
[07:50] <wallyworld> i have a test private key but that comes from g a go lib test
[07:50] <rogpeppe> wallyworld: did you see this bug BTW? https://bugs.launchpad.net/juju-core/+bug/1229839
[07:50] <_mup_> Bug #1229839: provider/ec2: LiveTests.TestBootstrapWithDefaultSeries is broken <juju-core:New for wallyworld> <https://launchpad.net/bugs/1229839>
[07:50] <wallyworld> and the data is precanned
[07:50] <wallyworld> i replied
[07:51] <rogpeppe> wallyworld: so you haven't generated the private key yourself?
[07:51] <wallyworld> we have had that SetToolsPrefix in the code for a long time'
[07:51] <rogpeppe> wallyworld: it's hideous!
[07:51] <wallyworld> rogpeppe: i have, but go refuses to import as
[07:51] <wallyworld> per the above error
[07:52] <wallyworld> rogpeppe:  i have a chunk of text  wrpped with -----BEGIN PGP PRIVATE KEY BLOCK----- etc
[07:52] <wallyworld> but i can't use ReadArmoredKeyRing to get something i can sign stuff with
[07:52] <rogpeppe> wallyworld: what command line did you use to generate your gpg private key?
[07:52] <rogpeppe> wallyworld: just so i can reproduce your issue
[07:52] <wallyworld> rogpeppe: i used seahorse and exported it
[07:53]  * rogpeppe hasn't heard of seahorse
[07:53] <wallyworld> i generated a sign only key
[07:53] <wallyworld> it's a gpg gui
[07:53] <wallyworld> rogpeppe:  but i guess "gpg --gen-key" would have worked
[07:54] <rogpeppe> wallyworld: that's ok, i can never remember the gpg usage either :-)
[07:56] <axw> wallyworld: I just generated one, it worked for me
[07:56] <axw> with --gen-key
[07:56] <wallyworld> wtf
[07:57] <wallyworld> can you read it using ReadAmouredKeyRing
[07:57] <wallyworld> without getting an error
[07:57] <axw> wallyworld: yep
[07:57] <wallyworld> did you type in a passphrase when you generated it?
[07:58] <wallyworld> axw: i'm stupid
[07:58] <wallyworld> the reading in bit qorks
[07:58] <wallyworld> works
[07:58] <wallyworld> it's the signing that fails
[07:58] <wallyworld> 	plaintext, err := clearsign.Encode(&buf, keyring[0].PrivateKey, nil)
[07:58] <wallyworld> fails
[07:58] <axw> ah
[07:58] <wallyworld> using the keyring read in
[07:59] <axw> wallyworld: did *you* type in a passphrase?
[07:59] <axw> will seahorse allow you not to?
[07:59] <wallyworld> no, i'll try command line
[08:00] <axw> (gpg --gen-key assigned one even when I said not to)
[08:00] <wallyworld> not sure if that will force it
[08:01] <wallyworld> i how do i get an unencrypted private key is the question
[08:01] <wallyworld> don't know why Go needs that
[08:01] <wallyworld> anyway, got to run to get dinner, back layter
[08:05] <axw> wallyworld: call PrivateKey.Decrypt(passphrase)
[08:06] <axw> wallyworld: see the comment on the PrivateKey.Encrypted field (http://godoc.org/code.google.com/p/go.crypto/openpgp/packet#PrivateKey)
[08:07] <axw> rogpeppe: if you didn't see it yet, I forwarded the upgrade email chain to juju-dev
[08:07] <rogpeppe> axw: thanks
[08:20] <rogpeppe> axw: here are some notes i made on major-version upgrades a while ago: http://paste.ubuntu.com/6153562/
[08:26] <axw> rogpeppe: heh, pretty much what I wrote I think :)  nice to know I wasn't off base
[08:26] <axw> the pending flag bit is a bit different
[08:26] <rogpeppe> axw: yeah, it seemed pretty similar
[08:26] <jamespage> davecheney, still around?
[08:26] <axw> rogpeppe: I think thumper was suggesting that the API server just lock out all connections, and API clients keep attempting to reconnect
[08:27] <axw> so the "pending flag" is in effect cleared when they can finally connect
[08:27] <axw> I kinda like that approach
[08:31] <rogpeppe> axw: just shutting off access to all agents seems a little draconian.
[08:31] <rogpeppe> axw: but it does have some advantages
[08:32] <rogpeppe> axw: like you don't have to wait for everyone
[08:32] <rogpeppe> axw: but i think it might be good to let all the agents download their new version before we start to upgrade
[08:33] <rogpeppe> axw: that way we can have a clean break
[08:34] <axw> rogpeppe: what if the API server fails during upgrade? how would you roll back the tools on the machine agents?
[08:34] <axw> or do you mean, download but don't action
[08:35] <rogpeppe> axw: both are possible
[08:35] <wallyworld> jam: i have 2 simplestreams mps, which fix the issues you were talking about, i'm hoping to get these into 1.15 https://codereview.appspot.com/13899044/ https://codereview.appspot.com/13888043/
[08:35] <wallyworld> i got to go make dinner, but back later
[08:35] <rogpeppe> axw: if we make sure that at least the new API is backwardly compatible to the point of finding out the agent version, then agents can downgrade if the upgrade fails
[08:36] <axw> that sounds reasonable
[10:01] <dimitern> fwereade, hey
[10:01] <dimitern> fwereade, quick question
[10:02] <dimitern> fwereade, if we don't take an environ in NewSimpleAuthenticator in the provisioner, how should we get the state and api infos? The manual provisioner needs a state connection I think, so we can't just return nil stateInfo
[10:46] <jam>  fwereade: standup ?
[10:46] <jam> https://plus.google.com/hangouts/_/3d4586c62aa1310a0c3f40960494578688c86f1a
[10:50] <jam> fwereade: ^^
[11:26] <fwereade> huh, hangout experiencing difficulties
[12:16]  * TheMue => lunch
[12:30] <dimitern> fwereade, ping
[13:33] <abentley> sinzui: ping for standup
[14:49] <fwereade> natefinch, https://codereview.appspot.com/13802045/ LGTM with comments (and a followup?) -- let me know what you think
[14:50] <fwereade> natefinch, wait, sorry, I seem to have skipped some files
[14:52] <fwereade> natefinch, added to it
[14:56] <fwereade> natefinch, maybe not LGTM any more, but should be reasonably simple to address
[14:57] <fwereade> natefinch, I think you just need to make a distinction between nil tags and empty tags
[15:10] <natefinch> fwereade: good point about masking tags
[15:41] <dimitern> ping
[15:42] <dimitern> :)
[15:42] <dimitern> i meant fwereade ping
[15:42] <mgz> was going to ask :)
[15:45] <fwereade> dimitern, heyhey
[15:45] <fwereade> dimitern, looking
[16:17] <natefinch> fwereade: good call on empty tags... we actually aren't handling it well at all.   tags=   is getting treated as a single empty string tag, rather than an empty list
[16:20] <mgz> erk
[16:21] <fwereade> mgz, eh, that's what review are for
[16:21] <natefinch> ironcically, the "round trip" serialization tests don't catch this (I didn't have a test for it, but I added one, that still passes)
[16:21] <fwereade> natefinch, thanks for checking it out
[16:21] <mgz> fwereade: yeah, but I really should have looked out for that >_<
[16:21] <natefinch> because []string{""}  serializes the same as []string{}
[16:22] <natefinch> so, I wrote a specific test for it to check that tags= gets deserialized into []string{} ... which currently fails, but I'll fix that.   TDD, woo!
[16:23] <mgz> yeay!
[16:23]  * fwereade cheers
[16:33] <rogpeppe> fwereade: fancy a small review (ExtraConfig in configstore)? https://codereview.appspot.com/13912043/
[16:33] <rogpeppe> mgz, dimitern, TheMue, natefinch: ^
[16:34] <mgz> looking
[16:34] <TheMue> me too
[16:39] <TheMue> rogpeppe: one minor comment, otherwise LGTM
[16:40] <rogpeppe> TheMue: i'd prefer not to define yet another map[string]interface{} type
[16:40] <rogpeppe> TheMue: i'm wondering about consolidating all of them to one type
[16:40] <rogpeppe> TheMue: but in the meantime it's nice to avoid the type conversion if it's used with testing.Attrs, for example
[16:41] <TheMue> rogpeppe: as those types doesn't cost a lot i like them explicit to give a better semantic expression
[16:41] <rogpeppe> TheMue: what does that mean?
[16:42] <TheMue> rogpeppe: especially when you set data not directly near to the function call
[16:42] <rogpeppe> TheMue: sorry, i'm not sure i get you
[16:43] <TheMue> rogpeppe: you can say cfg := ExtraConfig{"foo": 1234} then do something else, maybe add some more config, and later call SetExtraConfig(cfg)
[16:43] <TheMue> rogpeppe: in this case already the initialization shows the usage of the data
[16:43] <rogpeppe> TheMue: it's never going to be used that way
[16:44] <dimitern> rogpeppe, +1 on naming types like map[string]interface{}
[16:44] <dimitern> rogpeppe, we have too many too generic ones already
[16:44] <TheMue> rogpeppe: sure for every developer until eternity? ;)
[16:44] <rogpeppe> dimitern: i think map[string]interface{} expresses exactly what is required
[16:44] <rogpeppe> dimitern: but i'm thinking of creating utils.Attrs and making *everything* use that
[16:45] <TheMue> rogpeppe: it's technical, yes, but it doesn't say anything about the intention
[16:45] <dimitern> rogpeppe, i don't want to argue, just giving my opinion
[16:45] <TheMue> dimitern: thanks
[16:45] <rogpeppe> TheMue: neither does "int", but we don't retype every int
[16:45] <rogpeppe> TheMue: the argument name or function name is usually good enough
[16:45] <TheMue> rogpeppe: will start to refactor :D
[16:47] <TheMue> rogpeppe: but if it is enough you don't even need to create a utils.Attrs
[16:48] <TheMue> rogpeppe: then let as stay with it as it is
[16:48] <rogpeppe> TheMue: the current advantage to using an unnamed type is that it's compatible with other named types.
[16:49] <TheMue> rogpeppe: that's right
[16:50] <rogpeppe> TheMue: and also, given that config.Config.AllAttrs returns map[string]interface{}, I think my function should accept that exact type, because that's where its attributes are coming from
[16:50] <dimitern> rogpeppe, there's already testing.Attrs btw
[16:50] <TheMue> many attrs ;)
[16:51] <dimitern> rogpeppe, and it's map[string]interface{}, so maybe while deciding to refactor all such cases should be considered in the codebase
[16:51] <rogpeppe> dimitern: i know - i made it :-)
[16:51]  * TheMue has to step out, somehow i'm stuck with my testing and will start freshly tomorrow morning
[16:51] <rogpeppe> dimitern: i'd move it to utils
[16:51] <rogpeppe> dimitern: and then make everything use it
[16:52] <TheMue> rogpeppe: +1 for utils, yes
[16:53] <TheMue> so, good n8 everybody
[16:58] <rogpeppe> mgz: about the overall intention of the ExtraConfig stuff: the intention is that the extra configuration attributes are created only once, at Prepare time; subsequent operations should not add attributes, as that may well be racy.
[16:59] <rogpeppe> mgz: adding endpoint address information should not be racy, as everyone will be trying to save the same info, so it's idempotent
[17:00] <mgz> rogpeppe: okay, I sort of see
[17:00] <mgz> but then how does that distinguish from just not letting the config get overritten once in place?
[17:00] <mgz> *w
[17:00] <mgz> (having the bool "has this been created" flag, that is)
[17:01] <rogpeppe> mgz: well, create fails if the info already exists
[17:01] <rogpeppe> mgz: so you can only set extra config attrs if you are the one that first created the info
[17:02] <rogpeppe> mgz: ... does that make sense? i'm not sure i understood your question
[17:03] <mgz> hm, sort of, I think this is implementation detail rather than something that will break things later anyway
[17:04] <natefinch> man, I love tests. I found like 4 bugs with the tests I wrote in the last hour
[17:04] <mgz> natefinch: :D
[17:04] <natefinch> mgz, fwereade: btw, you both missed the fact that constraints.IsEmpty had no tests, and actually had a bug in it ;)
[17:05] <mgz> I complained about the indenting, which should give me half points...
[17:05] <natefinch> rofl
[17:06] <natefinch> the indenting is as gofmt would have it, all hail gofmt
[17:06] <mgz> but but... it makes no sense ;_;
[17:06] <natefinch> mgz: it's grouping
[17:07] <natefinch> mgz: it's showing explicitly with the indenting what the implicit order of operations will do
[17:08] <natefinch> mgz: gofmt does similar stuff when it's all on one line by using spaces or no spaces to show what will get calculated together, it's actually pretty awesome
[17:09] <dimitern> fwereade, there it is the secret attrs patch https://codereview.appspot.com/13916043
[17:10] <rogpeppe> oops, just pastebin'ed all my aws security credentials
[17:10] <mgz> natefinch: I'd understand if it was just the indent after the ||, it's the indent after the first && that makes no sense
[17:12] <rogpeppe> fwereade: FYI here's what the environment info file looks like with *all* the attributes stored in it: http://paste.ubuntu.com/6155286/
[17:12] <natefinch> mgz: it makes more sense if you put another || at the end like this: http://pastebin.ubuntu.com/6155319/
[17:14] <mgz> okay, but that still took a little bit of thinking about, I'd be breaking out the brackets if I got that far
[17:14] <natefinch> mgz: yes, in general... but it's handy if you think you know what it's doing , and turn out to be wrong... at least you get a hint of it.
[17:15] <natefinch> mgz: this kind of thing has already saved my butt:  https://groups.google.com/forum/#!msg/golang-nuts/qFtA6g8AIxE/oumyR1ytP4MJ
[17:15] <fwereade> rogpeppe, hmm, I dislike that a bit less than I expected to
[17:16] <rogpeppe> fwereade: i think it has some definite advantages - it's nice being able to see everything in one place, minus all the config initialisation magic
[17:16] <fwereade> natefinch, ouch, I was so happy to see IsEmpty everywhere
[17:16] <natefinch> fwereade: well, there's a test for it now, no harm, no foul. :)
[17:17]  * fwereade strokes his chin thoughtfully
[17:17] <natefinch> (given that I was the wrong that wrote it and failed to write a test.....)
[17:17] <natefinch> s/wrong/one
[17:21] <fwereade> rogpeppe, it just feels like it's asking to replicate the Conn problems
[17:21] <rogpeppe> fwereade: the Conn problems?
[17:21] <fwereade> rogpeppe, the Environ
[17:21] <fwereade> rogpeppe, which is wrong
[17:21] <fwereade> rogpeppe, and which people keep trying to use because it's so ridiculously convenient
[17:22] <rogpeppe> fwereade: well, we'll want to purge the environment from the environ info when we can
[17:22] <rogpeppe> fwereade: (in fact, it might even be a command)
[17:22] <rogpeppe> fwereade: really, we only want to keep it around until after the first connection
[17:23] <rogpeppe> fwereade: but there's that problem with what happens if you lose contact with the last-contacted API address
[17:23] <rogpeppe> fwereade: but that's a problem for everyone, and most people *won't* have the extra config attrs
[17:24] <rogpeppe> fwereade: so i guess i'd prefer to work on that problem (finding API endpoints without any environ credentials), and just throw the credentials away at the first opportunity
[17:25] <fwereade> rogpeppe, well, up to a point -- we *do* still have the creds around in environments.yaml and it would be silly not to use them
[17:25] <rogpeppe> fwereade: well, one person does, yes
[17:26] <rogpeppe> fwereade: but by fixing the issue for other people, we fix it for that person too
[17:26] <fwereade> rogpeppe, yeah -- taking that knowledge (along with eg control-bucket) away from that user is not helpful I think
[17:26] <rogpeppe> fwereade: i'm not sure how much mechanism is worth adding here
[17:27] <fwereade> rogpeppe, I accept that a global fix would be ideal
[17:27] <fwereade> rogpeppe, but today we still need actual environ access for the CLI in a bunch of situations
[17:27] <rogpeppe> fwereade: indeed
[17:27] <rogpeppe> fwereade: i don't see what difference it makes how many attributes you've got in that file though
[17:28] <rogpeppe> fwereade: you've either got the environ attrs or not
[17:28] <rogpeppe> fwereade: keeping them all in one place makes our life simpler
[17:28] <rogpeppe> fwereade: (and probably users' lives too)
[17:33] <fwereade> rogpeppe, I need to sleep on it I think
[17:33] <dimitern> wtf is params.StatusData ?
[17:33] <fwereade> rogpeppe, at the moment I still feel that if yu can get a complete environ config from that file alone we screwed up
[17:33] <fwereade> dimitern, dict of useful info attachable to status
[17:33] <dimitern> somebody landed this and changed machine.SetStatus() underneath
[17:33] <fwereade> dimitern, relation hook status reporting is particularly bad
[17:33] <dimitern> ok, so do need to care about it in the provisioner?
[17:34] <fwereade> dimitern, I think you can ignore it safely for now, nothing sets it on a machine
[17:35] <dimitern> fwereade, ok thanks
[17:36] <fwereade> rogpeppe, I do see the advantages in rendering to the One True Format, once, explicitly, though
[17:36] <rogpeppe> fwereade: that's interesting. i'm not sure *how* that means we've screwed up, given that environments.yaml+info = the same thing
[17:36] <fwereade> rogpeppe, the problem is that it looks like a sane config but most if the time it is not
[17:37] <fwereade> rogpeppe, I have a thought though
[17:37] <fwereade> rogpeppe, what if we called it creation-config
[17:37] <fwereade> rogpeppe, that might make its status a bit more apparent
[17:37] <rogpeppe> fwereade: that's not a bad idea
[17:38] <rogpeppe> fwereade: or bootstrap-config
[17:38] <fwereade> rogpeppe, it's still a bit risky in the same way Conn.Environ is, but it's better than before
[17:38] <fwereade> rogpeppe, perfect
[17:39] <natefinch> I'm getting a weird test failure in state/service_test.go in TestUpdateConfigSettings
[17:39] <natefinch> code that is no where near anything I've touched
[17:39] <fwereade> rogpeppe, validate and complete it OAOO, record it locally so we can finish bootstrap nicely, subsequently stick to changing the state-servers field and fall back to bootstrap-config just in case it offers a save for a screwed situation
[17:40] <rogpeppe> fwereade: i could imagine a command, say clear-bootstrap-info, which would delete the local bootstrap config
[17:40] <rogpeppe> fwereade: although it's probably unnecessary
[17:40] <fwereade> rogpeppe, I'm not sure it deserves a UI
[17:40] <fwereade> rogpeppe, anyone who can be trusted to run it can handle deleting a few lines;p
[17:40] <rogpeppe> fwereade: yeah
[17:41] <rogpeppe> fwereade: what *might* be nice though is a way of exporting the file without the bootstrap-config
[17:41] <fwereade> rogpeppe, yeah, I think that definitely deserves a UI
[17:41] <fwereade> rogpeppe, import/export environment basically
[17:42] <rogpeppe> fwereade: yeah
[17:42] <fwereade> rogpeppe, but I think that vocab's taken so we should think of something else
[17:42] <rogpeppe> fwereade: endpoint
[17:42] <rogpeppe> fwereade: export-endpoint, import-endpoint ?
[17:43] <fwereade> rogpeppe, I'm wondering whether it's more like an identity almost
[17:43] <rogpeppe> fwereade: it would be great if it contained the environ's UUID
[17:44] <fwereade> rogpeppe, that's a good point
[17:44] <natefinch> mgz, fwereade, rogpeppe, dimitern: help with this test failure?  I don't know where it's coming from - http://pastebin.ubuntu.com/6155445/
[17:44] <fwereade> rogpeppe, we do something annoying like defer its creation to bootstrap-state now, don't we?
[17:44] <rogpeppe> fwereade: tbh it would be nice if the UUID was generated at bootstrap time
[17:44] <rogpeppe> fwereade: yeah
[17:44] <rogpeppe> fwereade: i argued against that at the time :-)
[17:44] <fwereade> rogpeppe, well forseen
[17:45] <fwereade> rogpeppe, eh, we can always add that to the info file, along with the state-servers, rather than jam it into config
[17:45] <rogpeppe> fwereade: that's true
[17:45] <fwereade> rogpeppe, just pick it up a bit later
[17:46] <dimitern> natefinch, probably you need to merge trunk and frank's changes for updating default/empty settings values?
[17:46] <rogpeppe> fwereade: although it would be nicer to verify that the other end has that UUID rather than taking it for granted we're talking to the right one
[17:46] <natefinch> dimitern: hmm... I did just merge trunk.. let me double check
[17:47] <fwereade> rogpeppe, agreed that Prepare-time UUID generation would be nicer
[17:47] <jam> rogpeppe: any chance to not double space the cert?
[17:48] <rogpeppe> jam: that's just how goyaml produces multiline strings
[17:48] <rogpeppe> jam: if you wanted to patch goyaml... :-)
[17:50] <jam> rogpeppe: is it part of the yaml spec? in that if you don't double space you end up with everything on-one-line ?
[17:50] <rogpeppe> jam: inside single quotes, yes
[17:50] <jam> rogpeppe: you can always use a custom type with a MarshalYAML or whatever the func is.
[17:50] <rogpeppe> jam: yaml has the most abstruse quoting rules ever
[17:50] <rogpeppe> jam: that can't help us, unfortunately
[17:51] <rogpeppe> jam: because MarshalYAML returns interface{} containing values which will be marshalled according to the usual yaml marshalling rules
[17:51] <rogpeppe> jam: GetYAML, i mean
[17:52]  * rogpeppe has reached eod
[17:53] <natefinch> dimitern: all set.  looks like it was old cruft from go install that needed to be rebuilt.
[17:54] <dimitern> natefinch, ah, yeah - we keep bumping into that
[17:54] <dimitern> fwereade, any chance of looking at https://codereview.appspot.com/13916043 ?
[17:55] <rogpeppe> fwereade: seems like we have a plan
[17:55] <fwereade> dimitern, sorry, got lost on the stack, doing it now
[17:55] <natefinch> dimitern: yeah, I've hit it before, just didn't think of it this time... I just try never to do go install anymore... it's too fraught with problems like that
[17:55] <fwereade> rogpeppe, I think so
[17:55] <fwereade> rogpeppe, thanks
[17:55] <rogpeppe> fwereade: cool.
[17:55] <rogpeppe> fwereade: i'm happy.
[17:55] <dimitern> natefinch, I tend to always do go install in cmd/juju and cmd/jujud before doing a live test with --upload-tools
[17:56] <rogpeppe> g'night all
[17:56] <jam> natefinch: I always use "cd cmd/juju; go build; ./juju ..." which means it won't ever find "jujud" next to it :)
[17:56] <fwereade> dimitern, nice, LGTM
[17:57] <natefinch> jam: yeah, I've taken to the go build; ./juju thing too
[17:57] <dimitern> fwereade, cheers, the next one coming up shortly
[17:58] <fwereade> dimitern, awesome, I am workecueing and will be around for a bit
[17:59] <dimitern> fwereade, nice! :)
[17:59] <natefinch> mgz, fwereade: updated the maas-tags stuff with some more tests and bug fixes and now we handle nil tags vs empty list of tags properly  https://codereview.appspot.com/13802045/
[18:09] <dimitern> fwereade, and the last one https://codereview.appspot.com/13919043
[18:36] <fwereade> natefinch, LGTM
[18:36] <fwereade> dimitern, looking
[18:37] <dimitern> fwereade, thanks!
[18:38] <fwereade> dimitern, natefinch: if you're both around, I think we may want to verify that we can still deploy a container on maas with the changes
[18:38] <fwereade> and I believe natefinch to have something resembling reliable maas access
[18:41] <fwereade> dimitern, pending verification, LGTM
[18:41] <dimitern> natefinch, you just need "juju deploy wordpres --to lxc:0" or something and make sure it works
[18:41] <dimitern> fwereade, but natefinch will need to pull my branch, right?
[18:42]  * dimitern brb
[18:53] <dimitern> fwereade, you a maas live test specifically?
[18:54] <fwereade> dimitern, that'sd where we need that providsioner
[18:54] <fwereade> sorry knuckle typing
[18:54] <fwereade> pig fat
[18:54] <dimitern> :)
[18:54] <dimitern> I can do a live tests on ec2 or the local provider (or both) tomorrow
[18:55] <fwereade> ec2 runs no lxc proisioner now I Thought
[18:55] <dimitern> so local provider then?
[18:56] <dimitern> I think ec2 has it though
[18:56] <dimitern> I've seen it start in the logs while live testing iirc
[18:56] <fwereade> dimitern, hmm, maybe that has not landed yet
[18:57] <fwereade> dimitern, see whether it does run on ec2
[18:57] <fwereade> dimitern, if it does, add a container and check it's deployed sanely even if not actually addressable
[18:58] <fwereade> dimitern, that'd be good enough for me I think
[18:58] <dimitern> fwereade, ok, will do first thing tomorrow
[18:59] <fwereade> dimitern, great, tyvm
[19:28] <natefinch> dimitern, fwereade: sorry, had to step out.  I can try pulling dimiter's branch and test it out
[19:29] <fwereade> natefinch, no worries, and only if it's convenient, we can do it tomorrow as easily
[19:29] <fwereade> I'm about to be off myself
[19:29] <natefinch> fwereade: figured. I'll actually see if I can just add everyone to the maas host's trusted_keys so we can all use this virtual maas environment
[19:30] <fwereade> natefinch, oo, that'd be handy
[19:30] <fwereade> natefinch, thanks
[19:39] <natefinch> fwereade: welcome
[20:49] <gary_poster> hello world.  I'm using juju core 14.1 on saucy and can't get local lxc environ to work.  I had it working fine on another machine with saucy a week ago, but not working here.  the lxc machine never goes past pending after 30 min, 45 min, 1 hr. excerpt from local log of most recent attempt (now 7 minutes into attempt) is here: http://pastebin.ubuntu.com/6156103/ .  My environments.yaml at this point in my attempts i
[20:49] <gary_poster> s entirely barebones: only a local environment with an admin-secret.  Can anyone help?  thumper, you around, despite incredibly early time for you?
[20:50] <gary_poster> To be clear, this is the kind of status I see: http://pastebin.ubuntu.com/6156113/
[20:51] <thumper> hi gary_poster
[20:51] <thumper> it is the start of my normal work day :)
[20:51] <gary_poster> hey thumper.  oh cool...I think :-) what time is it?
[20:52] <thumper> just before 9am
[20:52] <gary_poster> oh cool, not too bad
[20:52] <thumper> next week I will be 1 more hour closer to you
[20:52] <thumper> as we go to UTC+13
[20:52] <gary_poster> ah, right, then IIRC we get even closer when we do our time shift
[20:52] <thumper> gary_poster: can you post the log from ~/.juju/local/logs/
[20:52] <gary_poster> sure
[20:52] <thumper> gary_poster: yes
[20:53] <gary_poster> thumper, http://paste.ubuntu.com/6156123/
[20:54] <gary_poster> that is local/log/machine-0.log .  there is no machine-1 fwiw
[20:54]  * thumper nods
[20:54] <thumper> have a look in /var/lib/juju/containers
[20:55] <thumper> there should be a directory there gary-local-machine-1
[20:55] <gary_poster> there is
[20:55] <thumper> in there there should be two log files
[20:56] <thumper> can you pastebin them?
[20:56] <gary_poster> on it
[20:56] <gary_poster> container.log http://paste.ubuntu.com/6156133/
[20:57] <gary_poster> console.log (as root) http://paste.ubuntu.com/6156140/
[20:58] <gary_poster> thumper, ^^
[20:58] <thumper> gary_poster: yeah, looking
[20:58] <gary_poster> cool, thx
[20:59] <thumper> I think this is a key one: cloud-init-nonet waiting 120 seconds for a network device.
[20:59] <thumper> cloud-init-nonet gave up waiting for a network device.
[21:00] <thumper> also there seems to be some issues with the container.log
[21:00] <thumper> perhaps lxc in saucy has changed something
[21:00] <thumper> will need to follow up with serge
[21:01] <gary_poster> ack thanks thumper.  thank you for looking.  Not blocked here.  anything else you need from my machine?
[21:01] <thumper> perhaps apt-cache policy lxc
[21:03] <gary_poster> thumper, http://paste.ubuntu.com/6156168/
[21:03] <gary_poster> running away
[21:03] <gary_poster> thanks and talk to you later
[21:04] <thumper> kk
[21:51] <wallyworld_> sinzui: hello, did you want to catch up?
[21:52] <sinzui> wallyworld_, yeah
[21:52] <wallyworld_> mumble hates me at the moment
[21:52] <wallyworld_> so a hangout?
[21:52] <wallyworld_> https://plus.google.com/hangouts/_/57e2c830e5a49e266ebc4dbeef8b459386dbf5bf
[21:53]  * sinzui gets drink
[22:44]  * thumper goes for a walk to think through some issues (juju related)