[00:10] <thumper> menn0: thanks for that bomb
[00:10] <thumper> not
[00:11] <menn0> thumper: sorry :)
[00:11] <waigani> menn0: funny man :)
[00:11]  * thumper -> lunch
[00:12] <menn0> thumper, waigani: I initially going to make my email an "isn't it interesting that Dropbox is using Go too" email but couldn't resist when I saw that they had an errors package too.
[00:13] <menn0> from my brief look, juju/errors seems far more complete
[00:16] <jcw4> anyone comfortable answering fairly specific watcher implementation questions right now?
[00:20] <davecheney> waigani: you're OCR
[00:20] <davecheney> https://github.com/juju/testing/pull/19
[00:20] <davecheney> +1, or -1
[00:23] <waigani> davecheney: why not: MgoServer *MgoInstance ?
[00:27] <davecheney> why make a pointer when we don't need to ?
[00:27] <davecheney> MgoServer = &MgoInstance{}
[00:27] <davecheney> is the same as
[00:27] <davecheney> var MgoServer MgoInstance
[00:33] <jcw4> what is Aram Havarneanu's irc nick?
[00:33] <jcw4> (I'm going down the committer list for state/watcher.go, sorted by total commits)
[00:33] <davecheney> jcw4: aram doesn't work for canonical any more
[00:34] <jcw4> davecheney: thanks... you're coming up :) you're 7th in the list
[00:34] <davecheney> jesus
[00:34] <davecheney> that's scraping the bottom of the barrel
[00:34] <davecheney> reminds me of a friend
[00:34] <jcw4> haha
[00:34] <davecheney> who bills himself as Canberra's 7th best Blues DJ
[00:34] <jcw4> git log --format=%an state/watcher.go | sort | uniq -c | sort -nr
[00:35] <jcw4> davecheney: lol
[00:35] <jcw4> It looks like rogpeppe1 is offline for the last hour
[00:35] <jcw4> TheMue: online?
[00:35] <davecheney> jcw4: rog is in the UK
[00:35] <davecheney> themue is in germany
[00:35] <jcw4> davecheney: can you feel the cold breath?
[00:35] <davecheney> jcw4: maybne you should just ask your question :)
[00:36] <jcw4> okay...
[00:36] <davecheney> jcw4: it's winter in australia, i have my own cold breath
[00:36] <jcw4> davecheney: in the state watchers we have a common idiom
[00:36] <jcw4> w.out is some sort of changes channel
[00:36] <jcw4> in the watcher loop we have a local var of the same channel type
[00:37] <jcw4> we expose w.out via a (w* ..Watcher) Changes() api
[00:38] <davecheney> mmm
[00:38] <jcw4> when new changes are detected, we assign w.out to the local out var
[00:38] <davecheney> jcw4: can you point me to an example in the source ?
[00:39] <jcw4> in state/watcher.go, any loop() implementation
[00:39] <jcw4> I happen to be looking at actionWatcher around line 1596
[00:40] <jcw4> one of the select cases in the loop detects a read from the out channel
[00:40] <davecheney> http://dave.cheney.net/2014/03/19/channel-axioms
[00:40] <davecheney> the trick is here
[00:40] <davecheney>                 case out <- ids.Values():
[00:40] <davecheney>                         ids = &set.Strings{}
[00:40] <davecheney>                         out = nil
[00:40] <davecheney> the last line basically says,
[00:40] <jcw4> davecheney: right, that's what I'm getting to
[00:41] <davecheney> remove this case from the select loop
[00:41] <jcw4> davecheney: until a new change comes in right?
[00:41] <davecheney> uip
[00:41] <davecheney> yup
[00:41] <jcw4> k.
[00:41] <jcw4> so that's all context
[00:41] <davecheney> that is the only place that assigns out again
[00:41] <jcw4> my problem is
[00:41] <jcw4> Changes() reads directly from w.out
[00:42] <davecheney> mmm
[00:42] <jcw4> so, for some reason, if I initially load the changes collection, the first read doesn't hit the out <- changes.Values() case
[00:42] <waigani> davecheney: var MgoServer MgoInstance: MgoServer has type MgoInstance (not *MgoInstance) - it is a zero initialised value, not a pointer. Correct? And arn't pointers cheaper to pass around than values?
[00:42] <davecheney> waigani: we're never passing it around
[00:43] <waigani> oh
[00:43] <jcw4> and then the consumer of the watcher gets the same changes the second time it reads w.Changes()
[00:43] <davecheney> jcw4: ok
[00:43] <jcw4> thereafter it works as expected
[00:43] <jcw4> (I believe)
[00:43] <davecheney> you're probably right
[00:43] <davecheney> i don't know what "if I initially load the changes collection"
[00:43] <davecheney>  means
[00:44] <davecheney> waigani: nobyd is passing MgoServer around, it's a package level variable
[00:44] <davecheney> a singleton (if we used that word)
[00:44] <jcw4> before the for { select {...}} loop I pre-load changes that occurred before the watcher was started
[00:44] <jcw4> into the local changes set.Strings collection
[00:45] <jcw4> davecheney: i.e. the expectation is that when you start a new Actions collection, you'll get an initial event notification of all the pending actions, and thereafter you'll be notified when new actions are added
[00:46] <davecheney> jcw4: that sounds like the expected watcher pattern
[00:46] <jcw4> what's happening is the pending actions are getting sent twice
[00:46] <thumper> davecheney: you are in error (a little)
[00:46] <thumper> davecheney: sorry, missed some context
[00:46]  * thumper steps away
[00:48] <jcw4> davecheney: I just wonder if the local out var that we're using for signalling by setting to nil when the event is read shouldn't be an actual member on the watcher, and *that* is the channel exposed by Changes()
[00:48] <jcw4> davecheney: otherwise we just say; duplicate initial events are to be expected... deal.
[00:49] <davecheney> jcw4: can you show some code ?
[00:49] <davecheney> i'm just not feeling it
[00:49] <jcw4> davecheney: :)
[00:49] <jcw4> davecheney: I don't blame you
[00:49] <jcw4> davecheney: gimme a couple minutes
[00:50] <waigani> davecheney: right. So the definition of passing something = having a receiver for it in a func sig? Why are there no benefits to making a package level var a pointer?
[00:50] <davecheney> ok, i'll answer the second part first
[00:51] <davecheney> there is no justification for making it a pointer
[00:51] <davecheney> so why ?
[00:51] <davecheney> why allow the possiblity for someone to set it to nil
[00:51] <davecheney> when we don't need to
[00:51] <davecheney> the first part
[00:51] <davecheney> i don't follow
[00:51] <davecheney> can you say your first question again pls
[00:52] <waigani> davecheney: when do we get value from using a pointer instead of the value?
[00:54] <davecheney> if I want to give you a copy of something, i pass by value
[00:54] <davecheney> if I want to give you a reference to my thing, I pass a pointer
[00:54] <waigani> yep
[00:54] <davecheney> but this is not entirely related to the receiver of a method
[00:55] <davecheney> type V struct {}
[00:55] <davecheney> func (v *V) F() { fmt.Println("%p", v) }
[00:55] <davecheney> func main() { var v V ; v.F() }
[00:55] <davecheney> F is defined on a *V, not V
[00:56] <davecheney> but Go will altomatically take the address of v if needed,
[00:56] <davecheney> so if you have a V and that V is addressable, go will do this
[00:56] <davecheney> (*v).F()
[00:56] <davecheney> in short: you don't need to declare everything as a pointer type just to call pointer methods on it
[00:56] <davecheney> (there are exceptions, but they do not apply in this case)
[00:56] <waigani> oooh
[00:57] <jcw4> davecheney: fwiw, my test code seems to deadlock
[00:58] <waigani> I didn't realise, I thought v.F() would fail because it's the wrong type
[00:58] <davecheney> waigani: so, back at the change
[00:58] <davecheney> where we had
[00:58] <davecheney> var MgoServer = &MgoInstance{}
[00:59] <waigani> yep
[00:59] <davecheney> that is declare a new MgoInstance value, take it's address and assign that to MgoServer
[00:59] <davecheney> var can write
[00:59] <davecheney> var MgoServer MgoInstance
[00:59] <thumper> davecheney: alternatively though, if you have a *V, it will not dereference to pass to a receiver of type (v V)
[00:59] <thumper> davecheney: right?
[01:00] <davecheney> thumper: false
[01:00] <thumper> oh?
[01:00] <davecheney> that is the same as saying
[01:00] <davecheney> v1 := *v
[01:00] <davecheney> v1.SomeValueMethod()
[01:00] <thumper> hmm...
[01:00] <davecheney> lemmie check that
[01:01] <thumper> I thought it didn't
[01:01] <davecheney> http://play.golang.org/p/VrpMKUYmwe
[01:02] <jcw4> davecheney: I'm going to think more on these things... thanks for your help; I know I didn't articulate my question clearly :)
[01:03] <davecheney> jcw4: show code, receive clarity
[01:12] <waigani> davecheney: So, just to check I've got the point: There is no point making MgoServer a pointer because, being a package level var, we are by default always referencing the same value whenever we use the var?
[01:13] <davecheney> yes, that is true
[01:13] <davecheney> but I don't think explains the point
[01:14] <jcw4> davecheney: the more I look at it the more I'm convinced the problem is elsewhere http://paste.ubuntu.com/7762857
[01:14] <davecheney> there is no point in making the MgoServer a pointer, because there is no point in making it a pointer
[01:14] <waigani> lol
[01:15] <davecheney> jcw4: as i read it
[01:15] <davecheney> line 3 is ht eonly place where you can take things out of w.out
[01:15] <davecheney> and line 36 is the only place you can put them into w.out
[01:16] <jcw4> davecheney: okay; I kept reading line 36 as the case when w.out was being read
[01:16] <davecheney> jcw4: you can write line 17 as
[01:17] <davecheney> var out chan<- []string = w.out
[01:17] <davecheney> if you like
[01:17] <davecheney> that may make it clearer
[01:17] <waigani> davecheney: btw what is OCR? I think image parsing when I read that
[01:17] <davecheney> On Call Reviewer
[01:17] <davecheney> i didn't make that one up
[01:17] <davecheney> blame, fwre
[01:17] <jcw4> davecheney: I see to explicitly state it as a write only channel?
[01:17] <waigani> oh shit, am I OCR?
[01:17] <davecheney> waigani: yup
[01:18] <waigani> man...
[01:18] <davecheney> jcw4: if that helps explain what is going on
[01:19] <davecheney> the watcher code is subtle and confusing
[01:19] <jcw4> davecheney: it does clarify my understanding of that loop, but I'm still baffled as to how two calls to Changes() can return the same initial set of id's
[01:19] <jcw4> davecheney: only the first two calls
[01:19] <davecheney> the most subtle bit is the way we only allow one change event to escape the watcher at a time
[01:20] <davecheney> jcw4: does your merge function work ?
[01:20] <jcw4> davecheney: yes
[01:20] <jcw4> I'll show code
[01:21] <jcw4> davecheney: http://paste.ubuntu.com/7762872
[01:23] <davecheney> why is everyone passing *set.Strings ?
[01:23] <davecheney> unrelated
[01:23] <davecheney> but sort of related
[01:24] <davecheney> a set.Strings is a map
[01:24] <davecheney> and maps are already refernce values
[01:24] <jcw4> davecheney: I thought of that when I read your other comments
[01:24] <davecheney> unrelated
[01:24] <davecheney> save it for another day
[01:24] <jcw4> davecheny :)
[01:25] <davecheney> jcw4: are you sure line 43 is every true ?
[01:25] <jcw4> davecheney: ever true?
[01:26] <davecheney> if id, ok := id.(string); ok {
[01:26] <davecheney> if id isn't a string
[01:26] <davecheney> then your merge function won't behave as expected
[01:26] <davecheney> oh
[01:26] <davecheney> there is a check
[01:26] <davecheney> good
[01:26] <davecheney> id' write that as
[01:26] <jcw4> davecheney: afaik it is *always* a string, but if not it should die
[01:27] <davecheney> switch id := id.(type) {
[01:27] <davecheney> case string:
[01:27] <davecheney>  // do string things
[01:27] <davecheney> default:
[01:27] <jcw4> davecheney: +1
[01:27] <davecheney>   fmt.Errorf("id is not of type string, got %T", id)
[01:27] <jcw4> davecheney: my tests that pass : http://paste.ubuntu.com/7762882
[01:28] <davecheney> barf
[01:28] <davecheney> how about just testing the function in isolation
[01:28] <davecheney> you don't even need to make it a method
[01:29] <davecheney> it can just be a function
[01:29] <jcw4> you mean testing the merge() ?
[01:29] <davecheney> yup
[01:29] <jcw4> davecheney: that test is the overall watcher test, which seems to correctly handle queued actions before the watcher is started
[01:30] <jcw4> this whole issue came up because bodie_ 's tests were failing: https://github.com/binary132/juju/blob/752f0b9232f7ef05b45a0efde7ba40cc4578409e/state/apiserver/uniter/uniter_test.go#L803-L825
[01:31] <jcw4> davecheney: I feel like I'm sucking you into my mess, and I need to isolate the problem further first
[01:31] <davecheney> jcw4: the solution to that problem is to
[01:32] <davecheney> log and issue, one per open question
[01:32] <jcw4> davecheney: like a launchpad bug issue?
[01:32] <davecheney> jcw4: yup
[01:32] <davecheney> if there isn't an isue
[01:32] <davecheney> then it never happene
[01:32] <davecheney> afaiac
[01:33] <jcw4> davecheney: okay - your clarification on the channels helped; thank you!
[01:34] <davecheney> jcw4: np
[01:34] <davecheney> i don't think i helped
[01:37] <jcw4> davecheney: it did help; but I think I am looking in the wrong place for the problem
[01:44] <davecheney> waigani: jcw4 https://github.com/juju/juju/pull/262
[01:49] <davecheney> thumper: OH MY GOD
[01:49] <thumper> davecheney: whazzup?
[01:49] <davecheney> state/watcher.go +751
[01:50] <jcw4> davecheney: that actually is related to my problem I think
[01:51] <jcw4> davecheney: if I do var out chan []string = nil, then bodie_'s tests actually pass, but my state ones fail, and I'm pretty sure my state ones are right
[01:51] <jcw4> davecheney: (in actionsWatcher, not relationUnitsWatcher)
[01:52] <jcw4> davecheney: I assume your deity name in vain use was about using out:=w.out and then immediately assigning it to nil?
[01:53] <davecheney> jcw4: yup
[01:53] <jcw4> :)
[01:53] <davecheney> if that is actually part of the code
[01:53] <davecheney> rather than just being lazy and not figuring out the right declaration for out
[01:53] <davecheney> i'm a monkey's uncle
[01:54] <jcw4> davecheney: I assumed it was just being lazy; hence my attempt to copy it used the var out chan []string = nil instead  :)
[01:56] <davecheney> :emoji hmmm
[02:17] <davecheney> waigani: jcw4 https://github.com/juju/juju/pull/263
[02:22] <thumper> davecheney:  this assignment: id := id.(type)
[02:22] <thumper> davecheney: can you explain what it does exactly?
[02:22] <thumper> why does it reassign back into id?
[02:23] <davecheney> the id inside the scope of the switch _case_ will be the asserted type
[02:24] <davecheney> so the inner id shadows the outer id
[02:24] <thumper> I find that a little confusing that you are effectivly changing "id" to mean the "type of id"
[02:24] <thumper> I'd rather have a different name for it
[02:24] <davecheney> true, but consider the alternative
[02:24] <davecheney> swich id1 := id.(type) {
[02:24] <davecheney> case string:
[02:24] <davecheney>  // do something with id1
[02:24] <davecheney>  // do something else with id1
[02:25] <davecheney>  // copy some code from another place an use id by mistake
[02:25] <davecheney>  // oh fuk
[02:25] <thumper> hang on...
[02:25] <thumper> I think I get it now
[02:25] <davecheney> id inside the switch case shadows the original declaration of id
[02:25] <thumper> ok
[02:25] <thumper> right, id is still id
[02:25] <thumper> but it has a defined type
[02:25] <thumper> not interface
[02:25] <davecheney> yup
[02:25] <davecheney> yup
[02:25] <thumper> ok
[02:25] <thumper> I'm good then
[02:26] <davecheney> cool
[02:26] <davecheney> i agree it is a bit gross to deliberably shadow id
[02:26] <davecheney> shadowing is contentious
[02:26] <thumper> I agree it is better than the alternative
[02:26] <davecheney> but in this case, when you _want_ id to be of type string, or whatever
[02:26] <davecheney> by shadowing the outer declaration you avoid the footgun of having that other id declaration floating around
[02:27] <thumper> I found it mildly confusing to work out what was the actual switch on
[02:27] <thumper> as it doesn't appear clear
[02:27] <thumper> to start with
[02:27] <davecheney> you can also say (a bit piously)
[02:27] <davecheney> i've asserted that id _is_ a string, so it should act like a string
[02:27] <davecheney> but that sort of statement isn't helpful
[02:28] <davecheney> ok, time for some lunch I think
[03:02] <menn0> thumper: thanks for the review. Comments addressed: https://github.com/juju/juju/pull/214
[03:03] <thumper> kk
[03:03] <thumper> looking
[03:05] <lifeless> if that case was a separate function, you wouldn't blink twice about the id parameter being a specific type
[03:07] <menn0> thumper: thanks very much
[03:07] <thumper> np
[03:23] <davecheney> [LOG] 0:25.779 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo283910080
[03:23] <davecheney> [LOG] 0:25.780 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
[03:23] <davecheney> [LOG] 0:25.797 DEBUG juju.testing tls.Dial(127.0.0.1:60070) failed with dial tcp 127.0.0.1:60070: connection refused
[03:23] <davecheney> [LOG] 0:25.798 DEBUG juju.testing tls.Dial(127.0.0.1:60070) failed with dial tcp 127.0.0.1:60070: connection refused
[03:23] <davecheney> [LOG] 0:25.865 DEBUG juju.testing started mongod pid 15989 in /mnt/tmp/test-mgo283910080 on port 34290
[03:23] <davecheney> [LOG] 0:25.871 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo188237343
[03:23] <davecheney> [LOG] 0:25.872 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
[03:23] <davecheney> [LOG] 0:25.959 DEBUG juju.testing started mongod pid 16032 in /mnt/tmp/test-mgo188237343 on port 32859
[03:23] <davecheney> [LOG] 0:25.965 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo157584114
[03:23] <davecheney> [LOG] 0:25.966 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
[03:23] <davecheney> [LOG] 0:26.053 DEBUG juju.testing started mongod pid 16076 in /mnt/tmp/test-mgo157584114 on port 58000
[03:23] <davecheney> [LOG] 0:26.058 DEBUG juju.testing s
[03:23] <davecheney> the test is using the WRONG versino of mongodb
[03:23] <davecheney> unless I am mistaken, the test should be using
[03:26] <davecheney> our special juju-mongodb, right ?
[03:31] <thumper> um...
[03:31] <thumper> I think it looks for either
[03:31]  * thumper shrugs
[04:27] <davecheney> the replica set tests are getting worse
[04:27] <davecheney> replicaset_test.go:69:
[04:27] <davecheney>     c.Assert(err, gc.IsNil)
[04:27] <davecheney> ... value *mgo.QueryError = &mgo.QueryError{Code:0, Message:"couldn't initiate : can't find self in the replset config my port: 60785", Assertion:false} ("couldn't
[04:27] <davecheney>  initiate : can't find self in the replset config my port: 60785")
[04:27] <davecheney> [LOG] 0:12.884 DEBUG juju.testing killing mongod pid 27146 in /tmp/test-mgo432122435 on port 60785 with killed
[04:27] <davecheney> [LOG] 0:12.891 DEBUG juju.testing killing mongod pid 26447 in /tmp/test-mgo041410420 on port 40386 with killed
[05:33] <jcw4> davecheney: fwiw, my problem earlier is related to the fact that in the state/apiserver/uniter tests the StartSync() method is called on the watcher which forces the watcher to load new events from the database, rather than waiting for notifications from the transaction log
[05:34] <davecheney> :\
[05:34] <davecheney> i'm not sure either of those is a correct solution in the formal sense of the word
[05:34] <davecheney> sounds like choosing the right hammer
[05:34] <jcw4> :)
[05:34] <jcw4> davecheney: I remember fwereade saying handling duplicate events should be expected
[05:35] <jcw4> but when you're trying to write tests that are deterministic it's good to know all the paths that cause events
[05:35] <jcw4> :)
[07:34] <TheMue> morning
[07:53] <jam> morning TheMue
[07:53] <jam> thanks for updating the calendar dimitern, I was running to eat before the alternate meeting time, but now I can relax a bit.
[07:53] <dimitern> jam, :) yeah, some mix-up happened
[07:55] <TheMue> jam: heya,I’m fighting with the bootstrap/endpoints bug. have been able to simulate it exactly once (first run), all other tries, even when removing everything, succeeded ???
[07:56] <jam> TheMue: I feel like its a race condition, so I would put sleeps in with what seems appropriate times. (either delay starting the API server, or delay the mongo start, or... ?0
[07:57] <jam> TheMue: were you able to get a traceback or any more information from the first failure?
[07:57] <TheMue> jam: yep, that’s my current approach. I once had troubles with the dbus too, error seems to come here from mongo.
[07:58] <TheMue> jam: no, only the wonderful output: ERROR EOF :(
[07:58] <jam> TheMue: so if you grep labix.org/mgo/v2 for "EOF" you can see a bunch of tests that assert it:
[07:59] <jam>         // With strong consistency, it fails again until reset.
[07:59] <jam>         err = session.Run("serverStatus", result)
[07:59] <jam>         c.Assert(err, Equals, io.EOF)
[08:00] <TheMue> jam: thanks for the hint, will take a look here too
[08:01] <jam> TheMue: so it appears that EOF happens when the connection to mongo is broken, and you must issue a session.Refresh() in order to recover from it.
[08:01] <jam> now... *what* would be causing us to disconnect from mongo? Maybe the new ensureMongoServer code?
[08:01] <jam> Maybe ensureMongoServer is running while the API server is already up?
[08:01] <jam> causing us to reset our connections.
[08:01] <jam> If that seems true at all, then I would say we should not be starting the API server until ensureMongoServer has been run.
[08:02] <jam> TheMue: Nothing concrete here, but IIRC, ensureMongoServer restarts the mongo db into single-user mode so that it can set up proper admin credentials before restarting again.
[08:26] <vladk> dimitern: what do you think about https://github.com/juju/juju/pull/255
[08:27] <dimitern> vladk, looking
[08:31] <dimitern> vladk, that looks fine, but we need the networker in place
[08:32] <rogpeppe> looking for a review of this, please. anyone able to take a look? https://github.com/juju/charm/pull/11
[08:33] <rogpeppe> dimitern, jam, TheMue, urulama: ^
[08:35] <dimitern> rogpeppe, how about peer relations?
[08:35] <rogpeppe> dimitern: you can't make peer relations explicitly
[08:36] <rogpeppe> dimitern: so i *think* it's ok to just ignore them
[08:36] <dimitern> rogpeppe, so there can be no case in which the peer relation definition won't work?
[08:37] <rogpeppe> dimitern: yeah
[08:49] <TheMue> rogpeppe: reviewed
[08:49] <rogpeppe> TheMue: thanks!
[08:50] <TheMue> rogpeppe: yw
[08:54] <rogpeppe> dimitern: are you reviewing the branch, BTW?
[08:55] <dimitern> rogpeppe, sorry, got distracted and now i need to be in a call
[08:55] <rogpeppe> dimitern: ok
[08:59] <jam> dimitern: maas call
[08:59] <jam> ?
[09:13] <jam> dimitern: sorry I have to go pick up my son, apparently my wife didn't realize I had a call, bb in about 30 min...
[09:13] <dimitern> jam, sure, np
[09:41] <jam> dimitern: back
[09:53] <tasdomas> does the firewaller run on the machine agent only or on the state server as well?
[10:00] <rogpeppe> dimitern, TheMue, jam: next one in the sequence, review appreciated: https://github.com/juju/charm/pull/12
[10:05] <TheMue> rogpeppe: will take a look
[10:05] <rogpeppe> TheMue: thanks!
[10:17] <TheMue> rogpeppe: reviewed
[10:20] <rogpeppe> TheMue: thanks!
[10:30] <Egoist> why juju when i try to deploy charm from local, takes somekind of old code, no the new one, that I changed?
[10:31] <dimitern> Egoist, what commands are you running exactly?
[10:32] <Egoist> juju deploy --repository="path to repo" local:precise/"charm name"
[10:33] <Egoist> full example:
[10:33] <dimitern> Egoist, it will help if you do $ tree /path/to/local/repo
[10:33] <Egoist> dimitern: Why tree?
[10:34] <dimitern> Egoist, the revision to deploy is discovered from the local repo dir by walking it recursively
[10:34] <dimitern> Egoist,  if the subdirs in the repo are in an unexpected order, the wrong revision will be picked, but you can always specify an explicit revision
[10:35] <dimitern> Egoist, i.e. juju deploy --repository /path/to/repo local:precise/mycharm-5
[10:35] <Egoist> what do you mean by unexpected order?
[10:35] <dimitern> will pick mycharm with revision 5 from the repo
[10:35] <Egoist> what with something like this:
[10:36] <Egoist> juju deploy --repository="charms" local:precise/mongodb
[10:36] <dimitern> Egoist, unexpected, as in you might have multiple copies of the charm in the repo, some with duplicated revisions but different code inside
[10:37] <Egoist> but i have only one copy of the charm
[10:37] <Egoist> does it matter?
[10:37] <dimitern> Egoist, when you run that, it should tell you Added charm local:precise/mongodb-42
[10:37] <dimitern> Egoist, that's why I asked to see a paste of the repo structure
[10:38] <Egoist> whait i past you it
[10:38] <Egoist> wait*
[10:38] <dimitern> Egoist, thanks
[10:38] <dimitern> please use paste.ubuntu.com or something similar, not directly in the channel :)
[10:40] <Egoist> charms/
[10:40] <Egoist> └── precise
[10:40] <Egoist>     └── mongodb
[10:40] <Egoist>         ├── charm-helpers-sync.yaml
[10:40] <Egoist>         ├── config.yaml
[10:40] <Egoist>         ├── copyright
[10:40] <Egoist>         ├── hooks
[10:40] <Egoist>         │   ├── charmhelpers
[10:40] <Egoist>         │   │   ├── core
[10:40] <Egoist>         │   │   │   ├── hookenv.py
[10:40] <Egoist>         │   │   │   ├── host.py
[10:40] <Egoist>         │   │   │   └── __init__.py
[10:40] <Egoist>         │   │   ├── fetch
[10:40] <Egoist>         │   │   │   ├── archiveurl.py
[10:40] <Egoist>         │   │   │   ├── bzrurl.py
[10:40] <Egoist>         │   │   │   └── __init__.py
[10:40] <Egoist>         │   │   └── __init__.py
[10:40] <Egoist>         │   ├── config-changed
[10:40] <Egoist>         │   ├── configsvr-relation-changed
[10:40] <Egoist>         │   ├── configsvr-relation-joined
[10:40] <Egoist>         │   ├── database-relation-joined
[10:41] <Egoist>         │   ├── hooks.py
[10:41] <Egoist>         │   ├── install
[10:41] <Egoist>         │   ├── mongos-cfg-relation-broken
[10:41] <davecheney> nooooooooooooooo
[10:41] <Egoist>         │   ├── mongos-cfg-relation-changed
[10:41] <Egoist>         │   ├── mongos-cfg-relation-joined
[10:41] <Egoist>         │   ├── mongos-relation-broken
[10:41] <Egoist>         │   ├── mongos-relation-changed
[10:41] <Egoist>         │   ├── mongos-relation-joined
[10:41] <Egoist>         │   ├── replica-set-relation-changed
[10:41] <Egoist>         │   ├── replica-set-relation-joined
[10:41] <Egoist>         │   ├── start
[10:41] <Egoist>         │   └── stop
[10:41] <Egoist>         ├── icon.svg
[10:41] <Egoist>         ├── Makefile
[10:41] <Egoist>         ├── metadata.yaml
[10:41] <Egoist>         ├── README.md
[10:41] <Egoist>         ├── revision
[10:41] <Egoist>         ├── scripts
[10:41] <Egoist>         │   └── volume-common.sh
[10:41] <Egoist>         ├── templates
[10:41] <Egoist>         │   └── backup.py.tpl
[10:41] <Egoist>         └── tests
[10:41] <Egoist>             ├── 00-setup
[10:41] <Egoist>             ├── 100_configs.test
[10:42] <Egoist>             ├── 10-unit.test
[10:42] <Egoist>             ├── 200_deploy.test
[10:42] <Egoist>             ├── get-unit-info
[10:42] <dimitern> that'll take a while..
[10:42] <Egoist>             └── test_write_log_rotate_config.py
[10:42] <Egoist> dimitern: tree with charm
[10:42] <Egoist> why
[10:42] <TheMue> ouch
[10:42] <Egoist> "nooooooooooooooo"?
 please use paste.ubuntu.com or something similar, not directly in the channel :)
[10:42] <TheMue> Egoist: use pastbin or similar
[10:42] <Egoist> ok, sorry
[10:42] <dimitern> Egoist, right, so now what's in the revision file?
[10:43] <Egoist> 30
[10:45] <dimitern> Egoist, and when you run juju deploy --repository charms local:precise/mongodb what's the output?
[10:45] <dimitern> Egoist, try adding --debug before --repository as well and paste the full output please
[10:46] <dimitern> vladk, jam, standup?
[10:47] <jam> dimitern: brrt
[10:47] <Egoist> dimitern,
[10:47] <Egoist> dimitern, http://pastebin.com/9XDmiEyq
[10:49] <dimitern> Egoist, so what's the problem?
[10:49] <dimitern> Egoist, it seems you've deployed this charm 7 times in the same environment
[10:50] <dimitern> Egoist, each time you deploy from a local repo, the revision in the charm is used, if possible, if not an unique revision for the environment is picked
[10:51] <Egoist> but when i make changes in code, juju don't see it, and use some kind of old code
[10:51] <dimitern> Egoist, that's right, because you need to run juju upgrade-charm
[10:51] <Egoist> like i add log("something") to code, it doesn't appear
[10:51] <dimitern> Egoist, not deploy, after you change the charm code in the local repo
[10:52] <Egoist> if not deploy then what?
[10:53] <dimitern> Egoist, juju upgrade-charm
[10:53] <dimitern> Egoist, try juju help upgrade-charm
[10:55] <dimitern> Egoist, you deploy once, and then upgrade when you need to, otherwise, you can run juju destroy-service mondodb && juju deploy --repository charms local:precise/mongodb
[10:56] <dimitern> Egoist, but the latter takes more time and it's generally not recommended over using upgrade-charm
[11:00] <jam> dimitern: Egoist: if you want to use deploy (because you want to wipe what you have/are testing your deployment/etc) does "juju deploy --upgrade" work better at seeing the newer code?
[11:01] <dimitern> jam, deploy --upgrade is deprecated and useless right now with the api
[11:13] <Egoist> dimitern: Even if I make juju upgrade-charm i still don't see newer code :/
[11:14] <dimitern> Egoist, try running juju upgrade-charm --debug mongodb and paste the output?
[11:15] <dimitern> Egoist, use the same --repository charms argument to upgrade-charm as well
[11:15] <Egoist> dimitern, http://pastebin.com/JsTHXsyh
[11:15] <dimitern> Egoist, what's test?
[11:15] <Egoist> it's mongodb i just call it test
[11:16] <dimitern> Egoist, is that the name of your service running the mongodb charm>
[11:16] <dimitern> ok
[11:16] <Egoist>  yes
[11:16] <dimitern> Egoist, ok, so does juju status show any errors or issues?
[11:18] <Egoist> i remove every service i have, and deploy mongodb charm with new code, and it still dont see newer code
[11:18] <Egoist> and i have relation problem, that i want to fixed using this newer code
[11:19] <dimitern> Egoist, can you paste the unit-test-0.log to see what's going on during upgrade-charm and deploy? you can use juju scp 0:/var/log/juju/unit-test-0.log .
[11:23] <Egoist> ERROR exit status 1 (scp: /var/log/juju/unit-test-0.log: No such file or directory)
[11:23] <Egoist> i have something like this, but when i ssh to machine, this file is exists
[11:24] <dimitern> Egoist, try juju ssh 0 and then go to /var/log/juju - see what logs are in there (if you removed the service the log might be missing, so in that case can you repeat the steps you did before and get the unit log?)
[11:26] <Egoist> dimitern, http://pastebin.com/bsrE7deT
[11:30] <dimitern> Egoist, is this the log after running just deploy?
[11:31] <Egoist> i think yes
[11:31] <Egoist> should i execute juju upgrade-charm?
[11:32] <dimitern> Egoist, so yes please, and paste the log again - but before that, add a log message in config-changed hook to make sure the code has changed or not
[11:36] <Egoist> dimitern: Look, this is after code changed http://pastebin.com/msGX03VP
[11:37] <Egoist> nothing changed, i add log("Fresh Code")
[11:39] <dimitern> Egoist, that can't be the full log
[11:39] <dimitern> Egoist, I can't even see the upgrade process starting
[11:40] <Egoist> this is log i've got after execut juju upgrade-charm ...
[11:42] <dimitern> Egoist, ok, but it's not the full log, where's the rest?
[11:44] <Egoist> dimitern: http://pastebin.com/6CqS7Aup
[11:48] <dimitern> Egoist, and what were the exact juju commands you run on your machine locallly?
[12:04] <Egoist> juju upgrade-charm --repository=charms/ test
[12:06] <dimitern> Egoist, ok, it seems the issue is deeper, can you please file a bug against juju-core and attach the logs and the output of juju deploy --debug and juju upgrade-charm --debug and juju status to the report?
[12:33] <Egoist> dimitern: yes, of course
[12:33] <perrito666> morning people
[12:34] <dimitern> Egoist, thanks!
[12:34] <Egoist> dimitern: you mean report bug on launchpad? right?
[12:36] <dimitern> Egoist, yes, https://bugs.launchpad.net/juju-core/
[13:30] <wwitzel3> wallyworld_: http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/
[13:44] <stokachu> what is the use case for setting up mongo replication with a local provider?
[13:51] <perrito666> hey people, our licence is LGPL but most of our files (all but 3) have a header that say AGPL, this is something to be fixed right?
[13:56] <rogpeppe> next stage in bundle support - bundle directory reading. anyone fancy taking a look? https://github.com/juju/charm/pull/13
[14:01] <Egoist> I have a question about openstack and juju
[14:01] <rogpeppe> dimitern, TheMue, perrito666, wwitzel3, natefinch: ^
[14:01] <Egoist> why juju create security groups for everyu instance
[14:01] <Egoist> ?
[14:02] <rogpeppe> Egoist: it's so that it can manage the exposed ports for each instance individually
[14:03] <rogpeppe> Egoist: because ec2 does not allow changing the security groups of an instance after it has been started
[14:03] <rogpeppe> Egoist: you can work around this if you need to
[14:03] <rogpeppe> Egoist: there's an environments.yaml setting called "firewall-mode", which you can set to "global" which will cause juju to use only a single security group for all instances
[14:04] <rogpeppe> Egoist: it will mean though that some instances may expose a port that you don't want to be exposed
[14:08] <tasdomas> natefinch, could you take a look at https://github.com/juju/juju/pull/239 ?
[14:10] <Egoist> rogpeppe, thank you
[14:11] <stokachu> https://bugs.launchpad.net/juju-core/+bug/1338179 <- took me 4 minutes to bootstrap with local provider
[14:11] <_mup_> Bug #1338179: juju 1.20.x hangs at bootstrap <bootstrap> <cloud-installer> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1338179>
[14:23] <TheMue> rogpeppe: btw, doing your review
[14:23] <rogpeppe> TheMue: tyvm
[14:24] <perrito666> natefinch: could you review my tar push so I can merge it?
[14:24] <perrito666> since its your repo :p
[14:25] <natefinch> perrito666: haha ok
[14:26] <TheMue> rogpeppe: btw, did we agrred on the multiline arguments with return values in the next line notation? seen it several times in your code today, just wondering.
[14:27] <rogpeppe> TheMue: i don't think there was eventual consensus. i just try to write nice looking code
[14:27] <TheMue> rogpeppe: it still feels strange :)
[14:28] <rogpeppe> TheMue: the lines were getting too long otherwise
[14:28] <TheMue> rogpeppe: multiline args are ok for me too, but I still put the return values on the same line as the last arg
[14:29] <TheMue> rogpeppe: seems I need to familiarize myself with that notation
[14:30] <rogpeppe> TheMue: doing it this way means you can edit all arguments the same way (similar to the way we'd format a multiline slice)
[14:31] <TheMue> rogpeppe: yep
[14:31] <TheMue> rogpeppe: it’s only new, so it catched my eye’s
[14:43] <rogpeppe> TheMue: are you still reviewing?
[14:47] <TheMue> rogpeppe: almost done
[14:47] <perrito666> natefinch: I am sort of blocked by that review :p
[14:47]  * perrito666 adds pressure
[14:47]  * rogpeppe sympathises with perrito666
[14:47]  * rogpeppe wishes github understood prereqs
[14:48] <perrito666> rogpeppe: I have nate next to me, beats prereqs
[14:48] <wallyworld_> don't you mean "beat up" nate?
[14:48] <rogpeppe> wallyworld_: :-)
[14:49] <perrito666> wallyworld_: not yet
[14:49] <wallyworld_> oh, but it will be fun
[14:50] <perrito666> wallyworld_: well I feel sort of in debt, I could not be typing without his help
[14:50] <wallyworld_> yeah, but that was yesterday, today is a new day
[14:52] <TheMue> rogpeppe: you’ve got a review
[14:52] <rogpeppe> TheMue: ta!
[14:53] <perrito666> wallyworld_: well he saw what I did with the old kb, he can figure what is in it for him
[14:53] <wallyworld_> lol
[15:20] <rogpeppe> next in line for BundleArchive - some stuff so that we can more easily reuse some code that was in CharmArchive: https://github.com/juju/charm/pull/14
[15:20] <rogpeppe> TheMue, dimitern, perrito666, wallyworld_: review appreciated
[15:22] <wallyworld_> rogpeppe: in the middle of some hacking/reviewing here at the sprint, but can review soonish if no one gets to it
[15:22] <rogpeppe> wallyworld_: ta!
[15:26] <wwitzel3> natefinch, axw, wallyworld_: https://github.com/juju/juju/pull/269
[15:46] <axw> wallyworld_: https://codereview.appspot.com/106490043
[16:18] <rogpeppe> wallyworld_: change made as requested (i think)
[16:21] <rogpeppe> wallyworld_: are you still reviewing?
[16:30] <natefinch> rogpeppe: we were at lunch, he'll be back at his laptop in a minute
[16:31] <rogpeppe> natefinch, wallyworld_: np
[16:45] <wallyworld_> rogpeppe: +1, thanks for making the changes
[16:45] <rogpeppe> wallyworld_: ta
[17:31] <rogpeppe> wallyworld_: last remaining branch, if you have some time to look: https://github.com/juju/charm/pull/15
[17:32] <wallyworld_> rogpeppe: sorry, busy pairing right now, can try and look later
[17:41] <perrito666> go complains when I try to use bytes.Buffer as a writer, I suspect I chose the wrong type or am missing something, ideas?
[17:53] <rogpeppe> wallyworld_: thanks
[17:53] <perrito666> fixed
[17:53] <rogpeppe> perrito666: *bytes.Buffer
[17:53] <perrito666> rogpeppe: yup
[17:53] <rogpeppe> perrito666: usual idiom is: var buf bytes.Buffer; foo(&buf)
[17:53] <perrito666> rogpeppe: that is the way I took
[17:54] <perrito666> voidspace: link?
[18:03] <voidspace> perrito666: link to what?
[18:03] <perrito666> the xkcd/nasa thing
[18:05] <voidspace> perrito666: http://xkcd.com/1337/
[18:05] <katco> http://xkcd.com/378/
[18:06] <katco> be a real programmer.
[18:06] <voidspace> perrito666: http://blog.xkcd.com/2014/05/30/isee-3/
[18:42] <wallyworld_> axw: https://bugs.launchpad.net/juju-core/+bug/1338179
[18:42] <_mup_> Bug #1338179: juju 1.20.x slow bootstrap <bootstrap> <cloud-installer> <local-provider> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1338179>
[19:21] <wallyworld_> natefinch: https://bugs.launchpad.net/juju-core/+milestones
[20:29] <wallyworld_> sinzui: ping
[20:30] <perrito666> natefinch: https://github.com/juju/utils/pull/9 last time I move it :p
[20:31] <sinzui> hi wallyworld_
[20:31] <wallyworld_> sinzui: hey, we're almost in the same timezone this week :-) we need to cut a 1.20.1 release this week if possible. can i schedule that with you?
[20:32] <wallyworld_> we still need to verify some fixes, and assign bugs to milestone etc
[20:32] <wallyworld_> just wanted to give you a heads up
[20:32] <wallyworld_> we will be committing fixes to the 1.20 branch
[20:33] <sinzui> wallyworld_, I can do it any day this week.
[20:33] <wallyworld_> sinzui: is CI set up still to run the tests on the 1.20 branch for when we commit to it?
[20:34] <sinzui> wallyworld_, yes...it have been testing the branch since last week
[20:34] <wallyworld_> sinzui: great thank you, i'll ping you in X days when we are ready to look at cutting the release
[20:55] <ericsnow> voidspace: http://mumak.net/stuff/your-code-sucks.html
[21:01] <voidspace> axw: https://code.launchpad.net/~mfoord/juju-core/slow-replset/+merge/221709
[21:19] <wallyworld_> perrito666: https://bugs.launchpad.net/bugs/1336967
[21:19] <_mup_> Bug #1336967: Restore doesn't <backup-restore> <ec2-provider> <openstack-provider> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1336967>
[22:49] <thumper> waigani, menn0, davecheney: I'm about to get a call for a reference check, hoping it will be done by 11
[22:49] <thumper> I told them to call back in 15 minutes 20 mintues ago
[22:49] <thumper> not sure when they are going to call
[22:50] <menn0> thumper: np.
[22:57] <thumper> waigani, menn0, davecheney: although they still haven't called, so lets do the standup on time, and if they call I'll just drop off
[22:57] <thumper> here is the call
[23:13] <thumper> done
[23:45] <davecheney> thumper: waigani menn0 I have two PR's for names.Tag changes waiting for revie
[23:45] <davecheney> if you have the time today
[23:46] <menn0> davecheney: I will try to get to them soon. I might have to head out for a bit soon though.
[23:47] <waigani> davecheney: I'll also put it on the list to do today - if someone does not beat me to it
[23:48] <davecheney> kk