#juju-dev 2012-07-02
<Aram> morning.
<TheMue> Morning
<davecheney> howdy
<Aram> hey.
<fwereade> davecheney, Aram, TheMue, morning
<davecheney> fwereade: morning
<davecheney> fwereade: looking forward to your testing change getting merged, we have a lot of overlap
<fwereade> davecheney, just saw your mail
<fwereade> davecheney, I'm feeling very conflicted ovr it
<fwereade> davecheney, part of me is saying "just break it into 6 separate CLs"
<davecheney> fwereade: i don't think that will reduce the wall time of merging it
<fwereade> davecheney, but a bigger part is saying "this is really all one change: it's actually going to make it harder and take longer"
<fwereade> davecheney, cool, glad it seems that way to you too :)
<davecheney> fwereade: if there are improvements to be made, they can be done after this change it merged
<fwereade> davecheney, let's hope niemeyer sees it that way :)
<davecheney> aye, there's the rub
<TheMue> Hmm, once again morning, connection seems to be broken.
<fwereade> TheMue, heyhey
<TheMue> fwereade: How has the weekend been?
<fwereade> TheMue, very nice thanks
<fwereade> TheMue, went to a charmingly low-rent charity event on saturday -- bunch of different foods and presentations from various nationalities
<davecheney> have a nice evening folks, i'll be online later
<TheMue> fwereade: We've been outside a lot, at friends on Saturday and in our own garden and a park on Sunday.
<fwereade> TheMue, lovely :)
<TheMue> fwereade: Enjoyed it a lot.
<fwereade> TheMue, I bet, sounds pleasingly idyllic
<TheMue> fwereade: Yep. We've got a park here near our home town which has founded for larger exhibition more than 10 years ago. And since then we're several times there each year.
<TheMue> fwereade: https://plus.google.com/photos/107694490695522997974/albums/5760290760673390033 shows some pics from yesterday
<fwereade> TheMue, awesome!
<fwereade> TheMue, Malta is a bit lacking in green spaces, they're probably what I miss most
<TheMue> fwereade: Hehe, yes, can imagine. Your change hasn't been small. Where in England did you lived before?
<fwereade> TheMue, london, which is pretty green really all things considered
<fwereade> TheMue, I grew up in the countryside in gloucestershite though so that's really what I feel is a "correct" environment, if you know what I mean
<fwereade> er, gloucestershi*r*e
<TheMue> fwereade: *rofl*
<fwereade> TheMue, it's a nice place, a little village in the costwolds called eastleach
<TheMue> fwereade: I sadly hadn't the chance to visit Britain yet, but there are so many places I want to see.
<TheMue> fwereade: From the crowded London to the Outer Hebrides.
<fwereade> TheMue, never been on the outlying islands
<fwereade> TheMue, been camping by the sea pretty far north in scotland
<TheMue> fwereade: So far I've only been in Heathrow for transit. *lol*
<fwereade> TheMue, haha
<fwereade> TheMue, the lake district is gorgeous
<TheMue> fwereade: We've seen so many fantastic locations in TV. I think we'll take a longer time and a Land Rover Defender and then cruise all over UK.
<fwereade> TheMue, I can think of worse ways to spend a month :)
<TheMue> fwereade: I would also take an other great Britain car, but that would be a bit expensive: An Aston Martin.
<fwereade> TheMue, haha
<TheMue> fwereade: I've got a part of a single malt cask on the Isle of Arran. We bought it a few years ago with some friends.
<fwereade> TheMue, I remember talking about it in budapest :)
<TheMue> fwereade: I can't hide that I've got a passion for the British culture, even that I've not been there. Funny, isn't it?
<fwereade> TheMue, it has good bits and bad bits, but the good bits somehow seem to have generated a lot of good PR ;)
<TheMue> fwereade: You definitely have better insides than me.  OTOH I'm only a tourist. :D
<TheMue> fwereade: I'm off for about an hour, routine visit at the dentist.
<hazmat> morning folks, tool question, does lbox submit -adopt notice local modificattions you've had to make to someone else's branch?
<hazmat> it does
<Aram> I hate it when I fix bugs but I don't understand my own fix.
<Aram> heh.
<Aram> go it.
<Aram> wow, this one was subtle.
<hazmat> fwereade, is there any docs extant for various cli changes in gojuju ?
<hazmat> actually even an auto generated go docs at a public site would be nice
<fwereade> hazmat, heyhey
<fwereade> hazmat, --help will tell you what exists, but it is not otherwise explicitly available anywhere; that is a sensible idea
 * hazmat works through compiling the tree
<hazmat> oh.. install is now get
<hazmat> bson in charm urls?
<hazmat> has install always been get. its been a while i guess
<hazmat> oh.. the bson is the incremental serialization work
<hazmat> for mongo
<hazmat> i thought most of that was in mstate
<fwereade> hazmat, sorry, I am missing a little bit of context
<hazmat> fwereade, ./cloudinit_test.go:210: undefined: Commentf ? do i need a more recent version of go? or am i missing a lib
<fwereade> hazmat, that's in gocheck
<hazmat> fwereade, shouldn't i have gotten an import error then?
<fwereade> hazmat, probably out-of-date
<fwereade> hazmat, `go get -u launchpad.net/juju-core/...`, I think (but make sure you don;t have local changes you want to keep if you do this)
<fwereade> hazmat, also worth checking what version of go you have
<hazmat> 1.0.1
<hazmat> fwereade, re go get juju-core what's the ... ?
<Aram> literal ...
<hazmat> sure.. just curious what it meant
<fwereade> hazmat, and everything underneath it
<hazmat> ah
<hazmat> fwereade, thanks
<fwereade> hazmat, (or imported by it, but that's go get's work not the ...'s, if you see what I mean)
<fwereade> hazmat, not sure whether 1.0.1 will pick all the latest library versions, if you still have trouble consider updating that
<fwereade> hazmat, offhand, do you have any idea of the approximate range of ratios between zookeeper time and wall clock time at the client end of a specific connection?
<fwereade> hazmat, s/zookeeper time and/the apparent rates of progression of zookeeper time and of/
<hazmat> fwereade, not sure what you mean.. notifications from zk are delivered in order
<hazmat> but the delay in delivery is subject to the quality of the network connection
<fwereade> hazmat, they are delivered in order but 2 conns do not necessarily have the same idea of "now"
<hazmat> fwereade, right
<fwereade> hazmat, not just that, I'm pretty sure the docs state that two conns can be out of syn by order-of 10s of seconds
<hazmat> fwereade, each conn is an independent view of the ordered stream
<fwereade> hazmat, quite so; this indicates that a client may see two events that are 100ms apart in ZK time arrive only 50ms appart on wall clock time
<fwereade> hazmat, or possibly 1ms apart
<hazmat> fwereade, that sounds odd, but given a conn on a separate server of the zk quorum that's a little out of date perhaps.. the conn can request the server catch up via sync
<hazmat> fwereade, in what context is that an issue?
<fwereade> hazmat, yeah, I know about sync, it's not in gozk AFAICS
<hazmat> are you trying to have multiple conns in a single server?
<hazmat> er. process
<fwereade> hazmat, testing of the presence nodes using two separate connections
<hazmat> fwereade, the possibility is greatly diminished of long deltas in independent views of time if their connected to the same server and the same network quality
<hazmat> fwereade, there are numerous tests in txzk that i've looped 10s of k that exercise multiple conns fwiw
<hazmat> fwereade, is this a theoretical concern or something you've seen in practice?
<fwereade> hazmat, ok; but I have directly observed an alternate connection, running in test X, to have a conception of ZK "now" that corresponds to a state that was current during a previous test
<hazmat> fwereade, are the tests building state across tests?
<fwereade> hazmat, this happens very unpredictably
<fwereade> hazmat, no
<fwereade> hazmat, the main connection nukes everything between test cases
<hazmat> so it sounds like a test framework issue then with cleanup
<hazmat> fwereade, or perhaps a bug in gozk delivering events on closed conns
<hazmat> fwereade, does the conn get closed/open for teardown/setup?
<fwereade> hazmat, no; I'll try doing that
<hazmat> fwereade, if it doesn't then yes.. its quite possible your getting event delivery on old state
<fwereade> hazmat, but based on what I've seen that will only add more uncertainty...
<hazmat> keep in mind you've only got one execution thread
<fwereade> hazmat, new conns get events from older state
<hazmat> fwereade, was the old conn closed?
<fwereade> hazmat, no, the old conn is still being used to perform new operations, which I expect the alternate conn to respond to
<fwereade> hazmat, or vice versa in some tests
<hazmat> fwereade, that sounds like an event dispatch issue with events
<hazmat> i'd try instrumenting gozk
<fwereade> hazmat, is it not behaviour consistent with the somewhat loose guarantees that ZK makes?
<hazmat> and printing out with handle info
<fwereade> hazmat, yeah, I will look into that, it's perfectly plausible
<hazmat> fwereade, old events on new conns? no
<hazmat> that's not part of the guarantee, the event only happens on state observation
<hazmat> and temporarily if that state is new, it should never see an old event
<fwereade> hazmat, potentially old view of history implies potentially old state changes, doesn't it?
<hazmat> ie. seeing old event on new state, would be a violation of the guarantee zk makes
<fwereade> hazmat, does a new conn guarantee up-to-date view of history?
<hazmat> fwereade, temporarily its should be up to date
<fwereade> hazmat, it explicitly does not AIUI
<hazmat> fwereade, connected to the same server yes it does
<hazmat> fwereade, the only exception is if your running a quorum of servers
<hazmat> and connecting to a not quite up to date server with the new conn
<fwereade> hazmat, hold on though: it guarantees that a single client will only see a single view of history, and that that view is independent of the server it connects to
<hazmat> its not eventually consistent
<fwereade> hazmat, therefore, surely, it is possible that two clients connected to the same server may have an alternate view of history
<hazmat> fwereade, feel free to verify, but it sounds like a code bug not a zk bug
<hazmat> fwereade, the state is in memory on the zk server and modified by each op
<hazmat> fwereade, and flushed to disk, a new client, will see current state
<hazmat> as i said there are exceptions, but not to a single server setup
<fwereade> hazmat, Single System Image
<fwereade>     A client will see the same view of the service regardless of the server that it connects to.
<hazmat> and even then the limiting factor is the overall speed of the quorum to propagate changes
<hazmat> fwereade, history doesn't exist from a client perspective, there is only present state and future observation
<fwereade> hazmat, yes: but for it to have the single system image, history surely *must* exist at the server level?
<hazmat> fwereade, yes.. but your asking about the delta between multiple clients
<hazmat> fwereade, it does but its not exposed
<hazmat> fwereade, and its only the delta on disk, not in mem
<fwereade> hazmat, will look into it further, but still unconvinced that the fact the server is standalone guarantees consistency of client connections
<hazmat> fwereade, the watch notifications for the client are in mem and are queued up
<hazmat> again the notification carries no state
<hazmat> only the change info, observation is required to capture state
<hazmat> fwereade, feel free to verify, but it sounds like a code bug not a zk bug
<hazmat> fwereade, the zk lists are pretty helpful
<fwereade> hazmat, sure, that's the plan -- but I'm not actually claiming a ZK bug, I'm just claiming that this surprising behaviour is not actually inconsistent with the guarantees made by the docs
<hazmat> fwereade, that a new client sees non current state
<hazmat> against a single server
<hazmat> i don't think so
<fwereade> hazmat, I agree that the explanation for this bit:
<fwereade> Sometimes developers mistakenly assume one other guarantee that ZooKeeper does not in fact make. This is:
<fwereade> Simultaneously Conistent Cross-Client Views
<fwereade> hazmat, *does* always mention multiple servers
<hazmat> fwereade, like i said.. on a single server.. that's not possible.. we have many tests in python to verify that
<hazmat> but i'm just repeating myself at this point...
<hazmat> fwereade, and the form of consistency i'm referencing is weaker than whats in there
<fwereade> hazmat, ok, I misunderstood your statement that you had verified this precise behaviour, and I accept your diagnosis of the likely cause; that is why I'm looking into it ;)
<fwereade> hazmat, the actual original question I asked though is different, and does potentially involve multiple servers
<fwereade> hazmat, and client connections from separate machines
<hazmat> fwereade, perhaps you should backup and explain what the goal is?
<fwereade> hazmat, the goal is to understand what could be causing unpredictable test failures in which two separate zk connections on the client are respectively seeing snapshots of state that appear indicate that deleting a node on conn A does not guarantee that the next request for state made on conn B will see that the node has been deleted
<hazmat> fwereade, has the delete node op completed before B makes a request?
<hazmat> fwereade, and you don't want to restrict to single server?
<fwereade> hazmat, the calls are performed synchronously; my understanding is that the call completing without error indicates that the operation has completed successfully
<fwereade> hazmat, in the general case of the problem, assuming multiple zookeeper, my initial question about relative rates of time progression may be relevant, but just for now we can worry about single servers
<hazmat> fwereade.. well its still likely async.. there are two results to check
<hazmat> the api call, and the result call
<hazmat> given that you've got a single server (*ignoring multi server for a moment) for your tests it would appear to be a bug in gozk
<hazmat> the unpredictable nature of the failures reinforces that guess, namely that something isn't properly waiting on results
<fwereade> hazmat, ok, so, by "still likely async", do you mean "a line of code immediately following `err := conn.Delete("/some/path"); c.Assert(err, IsNil)` is not guaranteed to see the change"
<hazmat> fwereade, you need to go deeper
<hazmat> fwereade, conn.Delete is what?
<hazmat> a gozk binding to the libzk
<hazmat> underneath the hood its doing what
<fwereade> hazmat, that is what I intend to do
<hazmat> i'd guess adelete
<hazmat> which is async
 * hazmat takes a look
<hazmat> interesting
<fwereade> hazmat, zoo_delete which I presume is not adelete
<Aram> Delete does zoo_delete which is synchronous.
<Aram> gozk is sync.
<hazmat> wow
<hazmat> ok..
<hazmat> fwereade, so i'd suggest instrumenting delete and the subsequent client op with some prints
<Aram> I suspect you simply check against the wrong version.
<Aram> that's why you don't see the change.
 * Aram didn't read much of the backlog.
<hazmat> so gozk is sync, and gojuju runs with a single thread ?
<hazmat> Aram, interesting idea
<hazmat> Aram, versions are only passed for modifications
<hazmat> in this case its an observation that shows old state
<fwereade> hazmat, sorry, lunch
 * hazmat moves onto openstack provider review
<hazmat> fwereade, could pastebin the test in question?
<fwereade> hazmat, the clearest situation is in line 10 of http://paste.ubuntu.com/1071241/ -- when it occurs, other connections are known to have been going around creating the node we're watching in the past
<hazmat> fwereade, that looks like the same connection?
<fwereade> hazmat, yes, it is an alternate connection is a previous test about which I am concerned
<niemeyer> Gooooood morning!
<Aram> hi niemeyer.
<Aram> how was your trip?
<hazmat> niemeyer, g'morning, how was i/o?
<Aram> and how was SF?
<niemeyer> hazmat: Superb
<niemeyer> Aram: Superb too :)
<niemeyer> Aram: Great to meet all the folks
<TheMue> niemeyer: Heya
<Aram> niemeyer: yeah, that must have been great.
<hazmat> fwereade, what happens to the conn in setup/teardown?
<hazmat> is there anyway to get the go test to be verbose about test cases being run?
<fwereade> hazmat, in TearDownTest, recursively delete everything and (IIRC, checking) panic on error except nonodoe
<niemeyer> http://arethegovideosupyet.com/ < This is great :)
<hazmat> fwereade, so it is the same open connection for multiple tests?
<fwereade> hazmat, -test.v -gocheck.vv should give you plenty
<fwereade> hazmat, yes
<TheMue> niemeyer: Yep, funny idea. Waiting for the next ones to be online.
<niemeyer> How're things going in juju-dev land?
<TheMue> niemeyer: First a hurdle but now moving forward.
<niemeyer> fwereade: So, hazmat tells me we're not testing our code properly because we have a bug. What's up there?
<fwereade> niemeyer, I am still trying t characterize it properly
<fwereade> niemeyer, the stars appear to be aligned such that I can repro more often than not
<niemeyer> fwereade: Ah, this is perfect
<fwereade> niemeyer, but I am still trying to coax an "aha" out of the data
<niemeyer> fwereade: http://paste.ubuntu.com/1071241/ is this the test?
<fwereade> niemeyer, that is one of the many that *can* exhibit anomalous behaviour
<fwereade> niemeyer, but the vast majority of the presence suite has been *slightly* flaky for a while, and I now appear to be close to pinning down the problem
<niemeyer> fwereade: Ah, that's awesome
<niemeyer> fwereade: Does it fail if you run just presence in isolation?
<fwereade> niemeyer, very very very rarely
<niemeyer> fwereade: Your more-often-than not is achieved with a few packages, or just with the whole suite?
<fwereade> niemeyer, just state
<niemeyer> Nice
<niemeyer> fwereade: What's the liveness timing being used by the tests?
<fwereade> niemeyer, 50ms, and there is certainly something tricksy there which I think I am close to accounting for
<fwereade> niemeyer, ie sometimes we get mtimes more than 100ms apart when we do that
<niemeyer> fwereade: This may well be the issue
<niemeyer> fwereade: The GC may be stopping to collect stuff
<fwereade> niemeyer, this is surely *part* of the issue
<fwereade> niemeyer, I am trying to eliminate it and see whether I can goose theweirder one into existence
<niemeyer> fwereade: Does it change the situation if you set GOMAXPROCS=4?
<fwereade> niemeyer, hmm, quite possibly; but that's another dimension of phase space that I don't need right now I think
<niemeyer> fwereade: Well, perhaps without the parallel collection that went into tip it wouldn't make much of a difference anyway
<fwereade> niemeyer, well, we need timing tweaks, but the real important ones will come in real usage I think
<fwereade> niemeyer, if we make them noticeably more generous than whatever I find to be rock-solid in test usage we will hopefully be ok
<niemeyer> fwereade: Agreed
<niemeyer> fwereade: Is there anything more unusual than the timing bits, that you'd like a second pair of eyes over?
<fwereade> niemeyer, if I can't figure it out today I will cry uncle, but I feel like I'm converging on something
<niemeyer> fwereade: Superb, you have me excited on the other side meanwhile ;-D
<fwereade> niemeyer, cool :)
<niemeyer> fwereade: Any luck there?
<fwereade> niemeyer, broke for supper at an opportune point; it looks like there was a case we'd missed in the code, subtly distinct from the normal failures due to c pauses/whatever
<fwereade> niemeyer, state seems to be solid, given a fix for that
<fwereade> niemeyer, trying a few full runs
<niemeyer> fwereade: Oh, so happy that you found it.. even if I don't know what the issue really is yet :-)
<fwereade> niemeyer, there's another bit of the issue which is trivial and embarrassing and kinda contributed to some of the confusion
<fwereade> niemeyer, not all the tests were nicely cleaning up pingers on failure
<fwereade> niemeyer, so I plan to do a pass for that too
<niemeyer> fwereade: Aha, that was my initial guess at the problem
<niemeyer> fwereade: Not to be embarrassed, though.. it's kind of easy to miss tear downs in any testing
<fwereade> niemeyer, the thing is, I knew about that -- the first failure often causes a cascade -- but there was always a particular mode of initial failure that didn't seem to match reality
<niemeyer> fwereade: Well, I appreciate you going after root cause.. a lot of people just ignore the obvious hints and go for the trivial solutions
<fwereade> niemeyer, has to be done really
<fwereade> niemeyer, fwiw there's a very occasional store failure that I never remember to capture
<fwereade> niemeyer, primarily because the sheer weight of mongo logs is intimidating
<fwereade> niemeyer, I promise that next time I see it I will make a proper bug
<fwereade> ;)
<niemeyer> fwereade: If it's the one I'm thinking off, it's just timing
<fwereade> niemeyer, sounds very plausible
<niemeyer> fwereade: I feel bad for it.. I've been kind of postponing increasing the timing to see if it will force myself to get the test to run faster rather than going for the easy solution
<niemeyer> fwereade: I can tell it's not working so far
<fwereade> niemeyer, I can sympathise
<niemeyer> brb
<niemeyer> fwereade: Dude
<niemeyer> fwereade: There?
<niemeyer> davecheney: Morning!
<davecheney> niemeyer: howdy!
<niemeyer> davecheney: Good to see you around from the usual time zone :)
<niemeyer> davecheney: Less overlap, but at least it's easy to actually talk :)
<davecheney> indeed
<davecheney> hows things ?
<niemeyer> Pretty good. Just having a look at William's monster branch
<niemeyer> Looks very nice
<davecheney> niemeyer: it would be awesome if that got a green light
<davecheney> i need his refactorings of zksuite etc for the local ec2 tests
<niemeyer> davecheney: Thanks for reviewing it too, btw.. really appreciate having more eyes
<davecheney> niemeyer: anytime
<niemeyer> davecheney: It will surely get a green light
<davecheney> it is big, and a lot of the changes are one line per file
<niemeyer> davecheney: huge improvement overall
<davecheney> indeed
<niemeyer> davecheney: The concerns I have so far are lateral.. e.g., mstate needs to be included
<davecheney> niemeyer: in related news, I have a fix for the location constraint issue in goamz
<davecheney> but am unsure how to write tests for it
<niemeyer> davecheney: Hmm
<niemeyer> davecheney: Can you please open a CL with the fix?
<niemeyer> davecheney: I can have a look and suggest something
<davecheney> niemeyer: twosecs
<davecheney> niemeyer: https://codereview.appspot.com/6344050
<niemeyer> davecheney: Checking
<davecheney> niemeyer: i can add support for LocationConstraint parsing into s3 test if you like
<niemeyer> davecheney: Okay, so
<niemeyer> davecheney: The testing seems to be easy to do inside s3_test.go
<niemeyer> davecheney: We mock the server, and can easily compare the result against something we own.
<niemeyer> davecheney: We don't even need to parse it
<niemeyer> davecheney: Check out.. hmmm..
<niemeyer> davecheney: Well, we actually don't have an example yet
<niemeyer> davecheney: But the req we get out of WaitRequest is a normal http.Request
<niemeyer> davecheney: With a Body and all
<davecheney> niemeyer: yeah, I can address the TODO in the s3_test server
<niemeyer> davecheney: A second detail: it looks like this info is well suited for a Name field
<niemeyer> davecheney: Region.name
<niemeyer> davecheney: Region.Name
<davecheney> niemeyer: yes, there are a number of places where we want to convert from the Region type back to its canonical name
<davecheney> niemeyer: https://codereview.appspot.com/6347059 << adds Region.Name
<niemeyer> davecheney: The map is a nice touch, thanks
<niemeyer> davecheney: LGTM
<davecheney> niemeyer: that was a TODO from environs/ec2
<niemeyer> davecheney: Ah, I didn't recall.. still looks like a good idea then! ;-)
<davecheney> niemeyer: i'll address the todo in juju after I commit the location constraint fix
<davecheney> so that people get a hint to go update goamz
<niemeyer> Super
 * niemeyer => dinner.. back soon
<davecheney> niemeyer: would you mind commiting williams lp:~fwereade/juju-core/vast-zookeeper-tests-cleanup ?
<niemeyer> davecheney: Hmm.. there are a few trivial details there to be sorted out.. I think I'd prefer to let him consider these details, including the mstate stuff, to see how to push it forward before getting it in
#juju-dev 2012-07-03
<davecheney> niemeyer: sure thing
<niemeyer> davecheney: ping
<davecheney> niemeyer: ac
<davecheney> niemeyer: ack
<niemeyer> davecheney: Yo
<niemeyer> davecheney: I was having a look at go-cmd-jujud-services
<niemeyer> davecheney: A few points:
<niemeyer> - You mention the actual meat of the change. Has anything changed within the moved files themselves? Just wondering if I should review that or not.
<niemeyer> - I was expecting the package to be service/<service name>/*.go
<niemeyer> More precisely, juju-core/service/<service name>/*.go
<niemeyer> Moving them out of jujud but keeping all of the services within the same file would allow importing, but preserve the "mess" which is having all of those unrelated things in the same place
<niemeyer> I think that's it.. otherwise the idea of moving sounds great
<davecheney> niemeyer: thanks for the feedback, i'll fix up the CL and repropse
<davecheney> niemeyer: i'm going to do the service CL in three parts, which might make it easier to review and merge
<davecheney> 1, cmd/services
<davecheney> 2, split provisioner and provisioning
<davecheney> 3, move provisioner to the new package
<niemeyer> davecheney: Sounds good
<davecheney> niemeyer: does bzr have the concept of hg cp ?
<niemeyer> davecheney: Btw, I suggest juju-core/services
<niemeyer> davecheney: Hmm.. not sure
<davecheney> niemeyer: yes, good idea, they dont' belong directly in cmd
<davecheney> niemeyer: just trying to reduce the size of the CL that just bifurcate provisioning.go
<niemeyer> davecheney: Cool.. as long as we don't move + change the code at the same time, it's easy to review either way I think
<niemeyer> davecheney: If there are changes that are tricky to avoid, it's fine to just mention them in the description so we can have a more careful look rather than assuming it's just coded being moved
<davecheney> niemeyer: https://codereview.appspot.com/6350064 << just moves Provisioner into it's own file (and tests)
<davecheney> which will make the other change easier to digest
<niemeyer> davecheney: If it's just moving, +1 for sure
<davecheney> niemeyer: yeah, just splits so I can move later and the diff will just show the package header changed and a few imports
<niemeyer> davecheney: Awesome, thanks, sent the LGTM there too
<davecheney> niemeyer: this will have a small impact on williams test CL as well
<davecheney> i'll work with him this afternoon to help unbreak it
<davecheney> niemeyer: can I propose a branch on top of his banch ? ie, can I do the fixes for his branch and he can import them ?
<niemeyer> davecheney: Absolutely
<davecheney> niemeyer: right, sounds fair, and I want his coretesting and zksuite types
<niemeyer> davecheney: Neat, branches are lovely in those cases
<niemeyer> davecheney: What would otherwise be a blocker is just a branch + merge
<davecheney> niemeyer: https://codereview.appspot.com/6344071 << much smaller
<niemeyer> Phew'
<niemeyer> davecheney: LGTM
<niemeyer> Okay.. time to sleep now
<niemeyer> Good night all
<niemeyer> davecheney: and good afternoon for you
<fwereade> davecheney, morning
<davecheney> fwereade: howdy
<davecheney> you've got a green light to drop that massive branch
<davecheney> but i've spent the day making conflicts
<davecheney> so sorry about that
<fwereade> davecheney, ah, no worries, I expect I can manage :)
<davecheney> fwereade: let me know if I can be of use, the faster I can get your changes, the better
<fwereade> davecheney, you can just merge from that branch and work on top of it -- but then the requested changes to that will lead you to have to deal with probably as many conflicts
<davecheney> fwereade: yeah, i've got a few branches in the air at the moment
<davecheney> but i'm truing to keep my main 'provision on ec2' as close to trunk as possible
<davecheney> error: cannot upload tools: cannot make S3 control bucket: The specified location-constraint is not valid
<davecheney> s3 can get stuffed
<davecheney> you _must_ specify a LocationConstraint if you are _not_ using us-east-1 or us-west-1
<davecheney> but you _mustnot_ specify one if you _are_ using us-east-1
<davecheney> which is bullshit
<fwereade> davecheney, eww
<davecheney> fwereade: going to be a bit of a shit to write a mock for
<fwereade> davecheney, yeah, I bet
<davecheney> fwereade: this is a nasty wart from us-east-1 being special because it's the first region
<TheMue> Hi fwereade
<fwereade> TheMue, heyhey
<TheMue> fwereade: Just watching the I/O talks.
<fwereade> TheMue, I must get to those
<fwereade> TheMue, somewhat code-obsessed at the moment
<TheMue> fwereade: Yeah, with your great change
<fwereade> TheMue, I'm going through an obsessive set of running the presence tests
<fwereade> TheMue, sadly they are not 100% reliable
<fwereade> TheMue, *but* I'm pretty sure that every failure is now timing-related and can be attributed to impolite schedulers and/or GC pauses
<TheMue> fwereade: Hard to fix stuff.
<fwereade> TheMue, yeah, GOMAXPROCS seems to help
<fwereade> TheMue, but that could just be my monkey-brain overlaying patterns where none exist
<TheMue> fwereade: *rofl*
<TheMue> fwereade: Could you please help me with todays firewall code?
<TheMue> fwereade: It's regarding line 278ff.
<fwereade> TheMue, sure, lookin for it...
 * fwereade looks somewhat apprehensive
<TheMue> fwereade: Thx, and there especially  line 281.
<TheMue> fwereade: Here a machine, not the machine state, is retrieved from the provider.
<TheMue> fwereade: Sadly I don't find yet what has this role in our code today.
<TheMue> fwereade: Did it change or isn't it yet ported?
<fwereade> TheMue, in go I think that's called an Instance
<fwereade> TheMue, corresponds to ProviderMachine, right?
<TheMue> fwereade: That's what I want to find out.
<fwereade> TheMue, I'm 99% sure it corresponds directly to environs.Instance
<TheMue> fwereade: OK, will take a deeper look. That may be the missing link.
<TheMue> fwereade: Thank you.
<fwereade> TheMue, a pleasure :0
<fwereade> TheMue, *dammit*, I have to go to the bank, wanted to finish this off before :/
<fwereade> TheMue, meeting in 50 mins, right?
<davecheney> niemeyer: thanks for your review
<davecheney> niemeyer: figuring out how to test a condition that can only be false if you're talking to the real us-east-1 is tricky
<niemeyer> Yo!
<niemeyer> davecheney: Hmm
<niemeyer> davecheney: Does it fail if you keep the constraint while talking to us-east-1?
<davecheney> niemeyer: yes
 * davecheney facepalms
<davecheney> that was the first thing i tried
<davecheney> us-east-1 is ... special
<niemeyer> davecheney: Lovely
<niemeyer> davecheney: Anyway, that still sounds easy to test in s3_test.go
<davecheney> niemeyer: otherwise it would be straight forward
<davecheney> niemeyer: i
<davecheney> i'll take another crack tomorrow
<niemeyer> davecheney: We have the payload at hanhd
<niemeyer> davecheney: And also have the test region at hand
<niemeyer> davecheney: We can tweak the region however we want, and see the effect on the payload
<niemeyer> Isn't it meeting time?
<niemeyer> fwereade, TheMue, davecheney: Meeting?
<fwereade> niemeyer, SGTM
<TheMue> Yes, but currently phone.
<TheMue> In a few moments.
<davecheney> niemeyer: sure, two secs
<niemeyer> Hmm.. Aram isn't around
<niemeyer> Starting a Hangout
<davecheney> niemeyer: send the invite to david.cheney@canonical
<niemeyer> Done
<niemeyer> fwereade: ping
<davecheney> nouns that are taken: service, agent, command, process
<niemeyer> worker?
<davecheney> possible nouns: daemon,
<davecheney> ^ pretentious ?
<davecheney> http://laughingmeme.org/2005/12/23/there-are-only-two-hard-things-in-computer-science-cache-invalidation-and-naming-things/
<fwereade> davecheney, and off-by-one-errors
<niemeyer> fwereade, davecheney: Suggestion: Life, SetLife and WatchLife..
<TheMue> +1
<davecheney> good discussion tonight
<davecheney> just for reference, i'll sleep on the renaming stuff we discussed and email tomorrow
<TheMue> davecheney: ;)
<davecheney> i am in agreement that we want to avoid the situation of a bug report that says 'something something agent did not blah'
<davecheney> and we have to ask for clarification on if they mean the agent process, or the one of several agent 'services' we had running inside that binary
<Aram> hello.
<Aram> grr, dreadfully sorry I couldn't make it to the meeting.
<Aram> had internet problems all morning.
<Aram> meh.
<davecheney> i blame the leap second
<TheMue> Hmm, could it be that todays "provider".get_opened_ports() has no counterpart?
<hazmat> TheMue,  what would the counterpart be? get closed ports?
<TheMue> hazmat: Hi, eh, wrong wording. I mean the ported part, which I expected in environs.Environ.
<hazmat> ah
<hazmat> yeah.. status will need that, else its not really used outside of the provider
<hazmat> er. provisioning agent
<fwereade> TheMue, seems that way, it's not in the interface
<TheMue> hazmat: Yes, I'm porting firewall.py for the provisioning agent. And this type needs it to retrieve the current open ports to compare it with the state.
 * niemeyer waves
<Aram> hi niemeyer.
<niemeyer> Aram: Yo
<Aram> niemeyer: sorry for not making it to the meeting :(.
<Aram> my internet didn't work.
<Aram> which is a first, after an year of staying here.
<niemeyer> Aram: It's ok, we can catch up later.. just a bit unfortunate because we talked about the proposal in the ML and covered a few angles, but we can revive that again
<Aram> yes, I really want to hear opinions about that.
<niemeyer> Aram: Well, me too ;)
<Aram> niemeyer: more lbox trouble...
<Aram> http://paste.ubuntu.com/1073238/
<fwereade> niemeyer, hey, I have something that looks very similar: http://paste.ubuntu.com/1073263/
<niemeyer> Hmm
<fwereade> everyone, I have to go a bit early today... I will certainly be back on in the evening to submit that change, by hook or by crook ;)
<niemeyer> fwereade: Cheers
<Aram> niemeyer: maybe it's a leap second bug ;)
<Aram> fwereade: have fun.
<niemeyer> Aram: Possibly :)
<fwereade> Aram, haha :)
<fwereade> cheers guys, see you later
<niemeyer> Aram: Can you please run with -debug?
<niemeyer> Aram: It looks like codereview might be blowing up
<Aram> niemeyer: sure thing
<niemeyer> Aram: Seems that reaching that point is returning without err
<niemeyer> Aram: oh, wait, maybe I misread
<Aram> niemeyer: http://paste.ubuntu.com/1073272/
<niemeyer> Aram: The code on goetveld definitely looks wrong
<niemeyer> Aram: Hah, it's the same problem as before :(
<niemeyer> Aram: Just in a different package
<Aram> heh.
<niemeyer> Aram: The change in redirect semantics sucks
<Aram> niemeyer: yeah, I don't think this should have happened, document the old behavior and stick with it until at least go 1.1.
<niemeyer> Aram: I'll see what I can do to workaround the issue.. the change in semantics is actually a problem in this case, because I want the response before the redirect, and there's apparently no way to do this now
<Aram> lunch
<niemeyer> Aram: lbox is coming
<Aram> niemeyer: fantastic
<niemeyer> Aram: I'll rebuild against golang-stable.. filed a bug against golang and Brad F. will revert his change next week
<niemeyer> Aram: There's simply no way to grab a response before a redirect with his change
<niemeyer> Aram: Which is needed in this case, because the login endpoint redirects, and we want its Cookie before we move on
<Aram> niemeyer: I see.
<Aram> niemeyer: so you bakported the exp/ stuff we're using?
<niemeyer> Aram: We're not using anything experimental
<niemeyer> Aram: It was using golang-tip just for historical purposes (IOW, before Go 1 was out, we depended on tip)
<niemeyer> Aram: It turns out that it's handy to depend on tip, though..
<niemeyer> Aram: I may well roll it back after next week
<niemeyer> Aram: I wouldn't have caught the bug on time otherwise
<niemeyer> Aram: Silly me.. apparently it does need exp/ from tip
<Aram> yeah, I remembered I couldn't compile it at some point.
<Aram> because of this.
<niemeyer> Aram: You were totally right
<niemeyer> Aram: I'll just embed it for the moment
<niemeyer> Aram: lbox should be good
<Aram> niemeyer: thanks.
<niemeyer> Aram: ping
<Aram> pong
<Aram> seen your email
<niemeyer> Aram: Cool, i was actually going to suggest something, but I'm just reviewing the pre-req.. will work out well
<Aram> niemeyer: updated that CL, also seen your bug report, will fix it tomorrow, will retreat for now, it's kind of late here :).
<niemeyer> Aram: I can imagine.. almost finishing the last review
<niemeyer> Aram: Thanks a lot for your help on that stuff
<Aram> my pleasure.
<niemeyer> davecheney: Morning!
 * niemeyer heads off for dinner
<davecheney> ziing
<fwereade_> davecheney, heyhey, I just merged that monster
<fwereade_> davecheney, I hop it didn't mess with your Machiner plans too badly
<davecheney> fwereade_: nah, it was a few minutes work to rebranch and do it again
<davecheney> fwereade_: the benefits far outweigh the cost
<fwereade_> davecheney, btw, if you ever spot the presence tests misbehaving, scream and should and send me the log output please :)
<fwereade_> s/should/shout/
<davecheney> m_3: you around ?
<davecheney> niemeyer: I had to repropose the machiner -> service/machiner branch here https://codereview.appspot.com/6348077
<davecheney> additionally, now it's not a prereq, the branch is much cleaner
<m_3> davecheney:
<m_3> yo
<m_3> davecheney: my reply probably just got out on smtp
<davecheney> m_3: cool
<m_3> tomorrow'd probably be great for Ultimo if that works for you
<davecheney> yeah, that sounds good
#juju-dev 2012-07-04
<davecheney> niemeyer: thanks for the review
<niemeyer> davecheney: np!
<davecheney> i have in the back of my mind the request to rename those packages
<davecheney> worker/agent/etc sound like good solutions, but I'd liek to give it a little more thought
<davecheney> maybe go for a walk and a sit before proposing anything
<niemeyer> davecheney: "worker" seems the best option so far
<niemeyer> davecheney: We already use agent nowadays with a different meaning
<davecheney> niemeyer: yeah, all the good options are taken
<davecheney> niemeyer: lbox has just started to panic on me
<davecheney> pls hold for the paste
<davecheney> http://paste.ubuntu.com/1074143/
<davecheney> is this related to the issue you raised in the mailing list ?
<niemeyer> davecheney: Can you please update it?
<niemeyer> davecheney: It is related indeed
<niemeyer> davecheney: I've backported it from tip to stable for now, though, so we can continue moving forward while Brad fixes it
<davecheney> niemeyer: will do
<niemeyer> Alright, bed time here
<fwereade_> davecheney, since you have been doing Provisioner lately, I was wondering whether you had wisdom to impart re handling of environ configs
<davecheney> fwereade_: possibly, what are you trying to do ?
<fwereade_> davecheney, because I'm getting very uncomfortable with the usage of naked ConfigNodes
<fwereade_> davecheney, I'm not *quite* sure yet what I'm aiming for -- I'm working on getting Initialize to set up the environment node
<fwereade_> davecheney, and it seems to me that Initialize alone should be responsible for "name" and "type", which should otherwise be unsettable
<davecheney> fwereade_: i see your concern
<davecheney> for the moment we've solved it via contract, by saying the environs should refuse to update those keys
<fwereade_> davecheney, yeah, I just can't really articulate it further in a useful way
<davecheney> once set
<davecheney> from my point of view, i'm happy with ConfigNode providing a very simple interface
<davecheney> but, i'm not the architect of this project :)
<fwereade_> davecheney, ah, sorry, totally missed your important point -- what is it that enforces those non-changes?
<davecheney> a loose agreement inside the environ itself
<davecheney> backed entirely by a comment
<fwereade_> davecheney, ok, gotcha
<davecheney> environs/ec2/ec2.go#SetConfig
<fwereade_> davecheney, the trouble is that EnvironConfig is acessible to any numpty with a State ;)
<davecheney> i would be less concerned with people changeing the name of the environ than pinching the secrets which are stored in the same key
<fwereade_> davecheney, sure, that too ;p
<davecheney> fwereade_: are you protecting against a back actor, or a well meaning, but misguided mistake ?
<fwereade_> davecheney, well-meaning mistakes are my primary concern really
<fwereade_> davecheney, I am just generally concerned that which-environ-to-use is a subtler problem than it may at first appear
<fwereade_> davecheney, this is mainly on the client side
<davecheney> fwereade_: i concur
<davecheney> fwereade_: but I have a plan to un fuck it a bit
<fwereade_> davecheney, I would like a clean way to express the stuff we need to do on first access to an env
<davecheney> i'm going to figure out, in cloudinit, what the real internal IP of machine/0 is, so we can write it into the state then and there
<davecheney> fwereade_: on a related note, how does jujutest come up with the dnsname for the first machine as i-3.example.com ?
<fwereade_> davecheney, er, not sure I'm afraid
<fwereade_> davecheney, continuing above I feel that it should be obvious and easy to use a juju.Conn in such a way that:
<fwereade_> davecheney, on bootstrap, we use the environments.yaml config exclusively
<fwereade_> davecheney, on subsequent operations, we push the missing keys from environments.yaml into state, and subsequently use only the config from state
<davecheney> fwereade_: gotta fly -- tonight is my night to help out at the bowls club
<fwereade_> davecheney, np, have fun, take care :)
<davecheney> catch you on the other side
<fwereade_> heya TheMue
<TheMue> fwereade_: Hi
<TheMue> fwereade_: Successfully get your branch in? ;)
<fwereade_> TheMue, yeah, thanks :)
<fwereade_> TheMue, hope the merge doesn't hurt too much :)
<TheMue> fwereade_: So far my new code is totally outside, it only uses state. So it should be no problem when merging it into my branch.
<jamespage> morning juju dev's
<jamespage> is anyone able to help me diagnose why one of the charms in launchpad is not accessible in the charm store?
<james_w> jamespage, you know about http://jujucharms.com/tools/store-missing ?
<jamespage> james_w, no I did not - thanks
<james_w> but unless you're asking about shelr.tv that's probably not going to be very useful
<jamespage> james_w, no - my query is with reference to the 'ubuntu' charm
<james_w> ah
<james_w> indeed, not very useful
<james_w> I've no more ideas, sorry, I'll return you to waiting for a dev
<niemeyer> Hey there!
<TheMue> Heya niemeyer
<fwereade_> niemeyer, heyhey
<james_w> hi niemeyer
<james_w> jamespage, has a question about why ubuntu isn't in the charm store: http://jujucharms.com/tools/store-missing
<niemeyer> james_w: In a meeting, will be with you on a sec
<Aram> hey all.
<niemeyer> Aram: Heya
<niemeyer> james_w: Okay, so how can I help?
<james_w> <jamespage> is anyone able to help me diagnose why one of the charms in launchpad is not accessible in the charm store?
<james_w> <jamespage> james_w, no - my query is with reference to the 'ubuntu' charm
<niemeyer> james_w: Which branch is that?
<james_w> lp:charms/ubuntu
<niemeyer> james_w: We've debugged this problem before, actually
<niemeyer> james_w: Clint asked me about it back in May
<niemeyer> james_w: This was the issue: https://pastebin.canonical.com/66332/
<james_w> hah
<james_w> niemeyer, where did you find that output?
<niemeyer> james_w: From Tom
<james_w> it would be great to have it on http://jujucharms.com/tools/store-missing
<niemeyer> james_w: This is supposed to be integrated in the charm-store proper
<niemeyer> james_w: In the API
<james_w> niemeyer, I suspect that's a bug in the bzr freshness check for package branches
<niemeyer> james_w: So anyone can query it and put wherever
<james_w> niemeyer, aside from fixing the bug you can disable that check
<niemeyer> james_w: How do you mean?
<james_w> niemeyer, I assume it's the MISSING line that is throwing it off?
<niemeyer> james_w: It's the fact it's outputting an error, yeah
<james_w> niemeyer, so anything on stderr causes the import to bail?
<niemeyer> james_w: No, but this certainly does:
<niemeyer> % bzr checkout --lightweight lp:~charmers/charms/precise/ubuntu/trunk
<niemeyer> Most recent Ubuntu version: MISSING
<niemeyer> Most recent Ubuntu version: MISSING
<niemeyer> Most recent Ubuntu version: MISSING
<niemeyer> james_w: Well, or maybe I'm lying
<niemeyer> james_w: Let me check reality
<niemeyer> james_w: The command is really failing
<james_w> non-zero exit code?
<niemeyer> james_w: No, I'm lying again, sorry.. I did something silly that resulted in echo $? == 1
<niemeyer> [niemeyer@gopher ~/trunk]% bzr revision-info
<niemeyer> Most recent Ubuntu version: MISSING
<niemeyer> Most recent Ubuntu version: MISSING
<niemeyer> 2 clint@ubuntu.com-20120522222745-k46xvcynebiva0xd
<niemeyer> [niemeyer@gopher ~/trunk]% echo $?
<niemeyer> 0
 * niemeyer checks implementation
<james_w> ok
<niemeyer> james_w: It's getting the combined output
<niemeyer> james_w: I'll fix that and invite Tom to redeploy
<james_w> niemeyer, fix it to do what?
<niemeyer> james_w: To get stdout
<james_w> ok
<james_w> we can also make the message go away
<niemeyer> james_w: It's slightly worse for debugging
<niemeyer> james_w: But I'd rather have it working instead ;-)
<niemeyer> james_w: That's certainly a better option overall for bzr
<niemeyer> james_w: Having every command spitting out an arbitrary number of irrelevant messages sounds bad
<james_w> right, bzr shouldn't activate the check for that url
<james_w> but we can also have the charm importer tell bzr to just never even bother thinking of doing the check
<niemeyer> james_w: How do we do that?
<james_w> I'm looking
<niemeyer> james_w: Cheers
<james_w> bazaar.conf: launchpad.packaging_verbosity = off
<james_w> there may be a way to set it on the command-line, but I don't think so
<james_w> and you can escalate https://bugs.launchpad.net/bzr/+bug/1020935 if you like
<james_w> ah, https://bugs.launchpad.net/bzr/+bug/888615/comments/4
<james_w> that's presumably better than the config file
<niemeyer> james_w: I'll probably just pick stdout
<james_w> niemeyer, that harms debugging?
<niemeyer> and  let it complain
<james_w> can you capture stderr and include it if the command fails or something so that you can have both?
<niemeyer> james_w: It could, because interleaving stderr/stdout means errors are in context, but in practice this seems to have made more harm than good, so I'm happy to adapt to reality
<james_w> yeah
<james_w> I've always found doing both to be tricky, I wish more libraries allowed for getting at both individually and an interleaved stream
<niemeyer> james_w: Yeah, it's seldomly done because one can't actually do it perfectly unless it's done at the kernel level due to buffering
<niemeyer> james_w: The correct way to interleave is to use a single fd, and then the individual streams are gone
<james_w> niemeyer, yeah, agreed it's not easy
<james_w> I still want it though :-)
<niemeyer> james_w: +1 :)
<niemeyer> Lunch time
<niemeyer> Quiet day
#juju-dev 2012-07-05
<davecheney> niemeyer: howdy
<davecheney> sorry i'm a bit slow off the mark today
<davecheney> m_3 and I are checking out a coworking space in the city today
<davecheney> niemeyer: short status report, got ec2 local tests working with a provisoiner working last night
<davecheney> but there are a few problems that need to be solved before I can propose it
<niemeyer> davecheney: Heya
<niemeyer> davecheney: Neat, sounds good
<davecheney> niemeyer: the main one is we ask ec2test for the DNS name of machine/0
<davecheney> whcih returns something liek i-3.example.com
<davecheney> which breaks the local test because it then uses that hostname in the stateinfo passed to anyone who wants it
<davecheney> so I need to add some kind of hook to either ec2test to say 'always return localhost' as the dns name, or to be able to override it if the test is running in local mode
<davecheney> niemeyer: the second problem is ec2 is hard coded to expect the zkport to be 2181
<davecheney> but that is simpler to fix
<davecheney> i'll propose a fix real soon now
<niemeyer> davecheney: Hmm
<niemeyer> davecheney: Wait, you mean you're putting a worker within the ec2 tests?
<davecheney> niemeyer: by worker, do you mean provisioner ?
<niemeyer> davecheney: a juju-core/worker
<davecheney> niemeyer: yes, the tests that roger left bootstrap an environment then try to do a state.AddMachine
<niemeyer> davecheney: Within the *ec2* tests?
<niemeyer> davecheney: I may be wrong, and will be happy to look at it, but it doesn't sound entirely right
<davecheney> niemeyer: yes, roger extended jujutest/livetest to start a machine in the provisioned environment
<davecheney> hang on, will get a link
<davecheney> niemeyer: sorry, m_3 just turned up
<davecheney> https://codereview.appspot.com/6347044/ << not a proposal
<niemeyer> davecheney: No worries, I'll actually have to step out for dinner
<davecheney> this is a grab bag of rogers stuff and my additions
<davecheney> niemeyer: the key change is https://codereview.appspot.com/6347044/patch/10001/11012
<davecheney> specifically, if hasProvisioner then testprovisioner
<niemeyer> davecheney: I'm indeed a bit lost.. in a sentence or two, what is this testing?
<davecheney> niemeyer: the changes to jujutest test that after bootstrapping, a provisioner is running, and it can start an instance with state.AddMachine
<niemeyer> davecheney: I can't see how we could possibly be testing that without a functional test
<niemeyer> davecheney: How can we be testing that after bootstrap a provisioner is running? This is entirely dependent on details of ec2 itself
<davecheney> yes, i haven't got that to work in the ec2 amazon tests yet because of the push secrets problem
<davecheney> this only works when we make the local provisioning agent in process for local_test.go
<davecheney> but in theory, once the secrets are pushed (faux juju deploy) the test will also pass on the real ec2
<niemeyer> davecheney: The point is that there's nothing being tested there
<niemeyer> davecheney: The live real tests can do that on real EC2
<niemeyer> davecheney: If we fake the precise point we want to test, what's the purpose of the test?
<davecheney> niemeyer: this test should (ha!) work on the real ec2 as well
<davecheney> so at the moment all I can prove is the test case works when we fake out all the moving parts behind it
<davecheney> that is, localtest continues to work with a test plan that expects a provisioner
<davecheney> once the pushing of secrets is fixed, we can remove the 'hasprovisioner' field as it will always be true
<niemeyer> davecheney: I understand, but this doesn't seem to be going in a good direction
<niemeyer> davecheney: All this faking isn't buying us stability or anything
<niemeyer> davecheney: It's messing up the code instead
<davecheney> niemeyer: should I put this on hold until we know how to fix the pushing of secrets and can do a real test in a real ec2 ?
<niemeyer> davecheney: No, I think we should fix the problems we have to fix for getting the real EC2 running
<davecheney> niemeyer: cool, that means resolving the secrets problem
<niemeyer> davecheney: The secrets problem is resolved in deploy
<niemeyer> davecheney: There's no *real* problem.. we just need to do the same thing we used to do
<niemeyer> davecheney: Sorry, I'm kind of stating that with the belief I know what's going on, and maybe I'm wrong
<niemeyer> davecheney: So please don't take that at face value.. feel free to bring other points
<davecheney> niemeyer: thats cool
<davecheney> the problem i think I'm solving is
<davecheney> 1. get boostrapping working -- which I believe is done, juju bootstrap works
<davecheney> 2. prove it with tests
<davecheney> 2 is tricky, and this CL is part way towads solving it
<niemeyer> davecheney: There are also several bits in the same CL that should be broken down so we can debate about them (and integrate them!) in isolation
<niemeyer> davecheney: e.g. there's a fix for cloudinit, etc
<davecheney> niemeyer: yes, i'll peel off those bits
<davecheney> just at the moment i'm taking another pass at the s3 location constraint proposal
<davecheney> because I want to commit that before telling everyone to please go get -u
<davecheney> then i'll start to pull apart this CL
<niemeyer> I find this, for instance, unexpected:
<niemeyer> 	  87                 err = t.seedSecrets(env)
<niemeyer>   88                 c.Assert(err, IsNil)
<niemeyer>   89                 if t.HasProvisioner {
<niemeyer>   90                         t.testProvisioning(c, st)
<niemeyer>   91                 }
<niemeyer> davecheney: This is in TestBootstrap
<davecheney> yes, all environments should have a provisioner, but we can't do that yet
<davecheney> sorry, all providers
<niemeyer> davecheney: So why would we be seeding secrets if we're testing bootstrap?
<davecheney> niemeyer: right, i understand
<davecheney> I will make a new test case
<niemeyer> davecheney: In fact, not only seeding secrets, but hacking the environment configuration arbitrarily
<davecheney> niemeyer: agreed, this is to work around the fact that bootstrap doesn't push the complete environment configuration into the state
<davecheney> if it did, then this wouldn't be a problem
<niemeyer> davecheney: But this is TestBootstrap! :)
<niemeyer> davecheney: It does not, and it should not
<davecheney> understood, i'll rework it
<niemeyer> davecheney: If the idea is to test a real ec2 deployment on live tests, we should call fwereade_'s conn.Deploy
<niemeyer> davecheney: and let it do the work
<davecheney> niemeyer: i'll try that
<niemeyer> davecheney: There's another issue with the CL approach as well that is good to keep in mind
<niemeyer> davecheney: One of the goals of jujutest is for it to be reusable across providers
<davecheney> yes
<niemeyer> davecheney: So we have to watch out for provider-specific behavior there.. in some cases we may need to hook onto the provider
<niemeyer> davecheney: Via a callback or whatever
<niemeyer> davecheney: But ideally we should be able to take these tests, plug on the OpenStack or Compute Engine backend, and have them working
<davecheney> niemeyer: yes
<davecheney> just checking what abuse i've done to jujutest
<niemeyer> davecheney: The configuration is the only thing that stands out to me
<davecheney> niemeyer: the complication is the ec2 environ has two modes
<davecheney> local fake ec2 mode and amazon mode
<davecheney> supporting that is hard
<davecheney> for example, fake ec2test server gives back DNS names which are impossible
<davecheney> ie, i-3.example.com
<davecheney> which can't be used as value StateInfo addresses
<niemeyer> davecheney: Right, but the question is where do we draw the line
<niemeyer> davecheney: I don't think it'd pay off if we simulated the *whole* provider
<niemeyer> davecheney: How do we actually deploy a machine?
<niemeyer> davecheney: How do we get unit agents running and interacting?
<niemeyer> davecheney: Faking out all of that stuff would have us with white hair by then
<davecheney> and as you say, doesn't actually test anything
<niemeyer> davecheney: It could test, the interaction between the pieces, but indeed not the *deployment* of the pieces, since that's all faked indeed
<niemeyer> Meaning it could be entirely broken and we'd think it's alright
<niemeyer> davecheney: So, to begin with, I'd be happy with
<davecheney> it's really about continuing the illusion of the ec2 provider in local mode
<niemeyer> if !t.CanOpenState { return }
<niemeyer> davecheney: At the top of the test that checks the real provisioning agent with conn.Deploy
<niemeyer> davecheney: run that with real Amazon only
<niemeyer> davecheney: This means we're testing stuff *for real*, cloud-init, running of commands, upstart script, and Inc.
<davecheney> niemeyer: ok, i'll try that
<niemeyer> davecheney: Of course, we won't be able to run that all the time
<niemeyer> davecheney: But for that we have the unit tests, closer to the implementations themselves
<niemeyer> davecheney: As soon as we have stuff working like that, I'll be happy to setup an integration test somewhere that does the boring work for us
<niemeyer> davecheney: I mean, integration test runner
<niemeyer> davecheney: LiveTest is already an integration test
<niemeyer> LiveSuite, that is
<davecheney> niemeyer: thank you for your time this evening
<niemeyer> davecheney: Sure thing, I'm glad to have that stuff moving forward.. we're about to have something real working, and that's quite exciting
<davecheney> i'm going to take a break on this CL and work on the s3 location one for a little
<davecheney> niemeyer: it's been working for over a week
<davecheney> actually, no
<davecheney> thta is not true
<davecheney> once we have deploy it works
<davecheney> also, ... value *net.OpError = &net.OpError{Op:"remote error", Net:"", Addr:net.Addr(nil), Err:0x28} ("remote error: handshake failure")
<davecheney> fu amazon
<niemeyer> Yeah, Amazon has been going through some bad times
<davecheney> niemeyer: changing gears
<davecheney> I'd like to change the s3 tests to hit a number of regions
<davecheney> not just USEast
<davecheney> is there anyting in juju-core that I can crib for reusing a test ?
<niemeyer> davecheney: Should be easy to have a setting on the suite type on s3i_test.go, and instantiating a couple of them with different values at the Suite(&S{..}) call time
<davecheney> I'm thinking jujutest/tests.go
<davecheney> niemeyer: yes, that is what I want to do
<niemeyer> davecheney: But if it's s3, s3i_test.go is the thing
<niemeyer> TheMue, fwereade: Mornings!
<TheMue> niemeyer: Morning
<TheMue> niemeyer: You're up early today.
<niemeyer> TheMue: Yeah, couldn't sleep for whatever reason
<TheMue> niemeyer: So used the time for a relaxed start with a good breakfast
<niemeyer> TheMue: Yeah, exactly
<fwereade> niemeyer, heyhey
<TheMue> fwereade: Heya
<niemeyer> fwereade, TheMue: How're things going guys? Good progress there?
<TheMue> niemeyer: Think so, yes. Setting up my tests.
<fwereade> niemeyer, not too bad, getting default-series handling right is a touch fiddly
<fwereade> niemeyer, had been hoping to chat to dave this morning, but missed him
<niemeyer> fwereade: Aw
<niemeyer> fwereade: What's the trickiness around it?
<fwereade> niemeyer, at the heart of it is now we initialize state
<fwereade> niemeyer, how
<fwereade> niemeyer, the current Initialize does basically nothing
<fwereade> niemeyer, what I would like to do is (among the other stuff) to put in a complete environ config, excluding only secrets, at bootstrap time
<niemeyer> fwereade: That sounds great
<fwereade> niemeyer, but that has distressingly far-reaching consequences
<niemeyer> fwereade: Oh?
<fwereade> niemeyer, I'm hoping that I will be able to see a way to break this down into 2 changes with hindsight
<fwereade> niemeyer, well, the whole bootstrap pipeline needs to change to accept that complete environ config
<niemeyer> fwereade: How so?
<niemeyer> fwereade: Bootstrap() is in the environ, and the environ knows its own config
<fwereade> niemeyer, cloud-init and initzk
<niemeyer> fwereade: So on that side at least, we're good
<niemeyer> fwereade: Right, on the other side we have to load it
<niemeyer> fwereade: A base64 option to initzk should do the deal
<fwereade> niemeyer, yeah, that's basically done
<fwereade> niemeyer, also, we need to be able to figure out which bits are secret and which aren't
<fwereade> niemeyer, and ATM it feels like we can't sanely get away without some sort of distinction between a loosely-specified user config and a strict real config... but we'll see how we go there
<niemeyer> fwereade: The only thing that knows about that is the environ
<fwereade> niemeyer, (I feel it is a profoundly bad thing to have the remote components inferring anything at all about their config, and they should not even accept junk like authorized-keys-path)
<niemeyer> fwereade: Handly enough, when sending the environ itself can filter out secrets
<niemeyer> fwereade: given that this is an implementation detail behind Bootstrap
<fwereade> niemeyer, sure; but I think Conn will also need to get the secrets so it update state on first access
<fwereade> niemeyer, none of these things are intrinsically painful, but I have yet to see how to turn it into a very clean set of CLs
<niemeyer> fwereade: I don't think it needs to know those details
<niemeyer> fwereade: (so far)
<niemeyer> fwereade: It just has to send the config it has
<niemeyer> fwereade: So we can make the operation be "send initial config if never done before" rather than "send secrets"
<fwereade> niemeyer, hmmmmm, so maybe we shouldn't set anything in /environment on bootstrap at all?
<fwereade> niemeyer, I would be a lot more comfortable if an initialized state implied valid data, even in the /environment node, eschewing only secrets
<niemeyer> fwereade: Your idea of sending an initial configuration when we have none sounds good, but it doesn't solve the entire problem, so we can postpone it for the moment I guess
<niemeyer> fwereade: These two options do not conflict with each other, though
<niemeyer> fwereade: "Bootstrap with config-secrets" & "send initial config if never done before" can be friends :)
<niemeyer> Sorry
<niemeyer> fwereade: "Bootstrap with config <minus> secrets" & "send initial config if never done before" can be friends :)
<fwereade> niemeyer, consider environment-specific settings that should not change, such as the control bucket
<fwereade> niemeyer, hm, we'll be broken anyway if that changes, won;t be able to find the bootstrap machine anyway
 * fwereade ponders
<fwereade> niemeyer, I guess it just feels kinda icky to ever *overwrite* env settings without checking them
<fwereade> niemeyer, it feels smarter to send public settings OAOO, and then to update them with secrets alone OAOO
<niemeyer> fwereade: Okay, I see your point, agreed
<niemeyer> fwereade: This can be solved in a somewhat clean way, I suppose, if we introduce ConfigSecrets in the Environ interface, returning []string
<fwereade> niemeyer, anyway, it is progressing nicely enough, and I'll know better how to split it all up cleanly before too long
<fwereade> niemeyer, yeah, something like that
<niemeyer> fwereade: I'd be happy with that
<TheMue> Lunchtime
<niemeyer> TheMue: Enjoy!
<Aram> hey all.
<niemeyer> Aram: Morning
<fwereade> Aram, heyhey
<fwereade> niemeyer, I just had a thought... what would happen if we made State.EnvironConfig() return an environs.EnvironConfig? allthe consequences I can currently see are positive ones
<fwereade> niemeyer, we wouldn't be able to casually update it as we currently do, thanks to it currently being a ConfigNode
<niemeyer> fwereade: How do we Write it?
<niemeyer> fwereade: Stat.SetEnvironConfig?
<niemeyer> State
<fwereade> niemeyer, I had been thinking of a distinct State.UpdateConfigSettings(map[string]interface{})
<fwereade> sorry UpdateEnvironConfig
<niemeyer> fwereade: Does it replace or does it append?
<niemeyer> fwereade: I suppose it replaces, so Set would be better.. anyway, +1
<fwereade> niemeyer, cool, thanks
<fwereade> niemeyer, I had originally been thinking of appending, but that's by the by
<niemeyer> fwereade: That'd mean we'd need an extra interface for removing keys, and it'd be different from the interface we have on Environ for the same purpose
<fwereade> niemeyer, true
<fwereade> niemeyer, not sure when we actually want to do that though
<niemeyer> fwereade: Hmm.. all the time?
<niemeyer> fwereade: I mean.. what other way would a config be updated?
<niemeyer> fwereade: Maybe you have something else in mind that I've missed
<fwereade> niemeyer, I mean I don't know when we delete keys from an environ config
<fwereade> niemeyer, I guess I'm missing something?
<niemeyer> fwereade: We surely are able to have missing keys, right?
<niemeyer> fwereade: Maybe we shouldn't allow that, or should say that missing keys and a key set to "" are the same?
<niemeyer> fwereade: Either way, the effect is the same.. Set would replace
<fwereade> niemeyer, IMO we shouldn't really ever have an /environment with missing keys (that aren't secrets)
<fwereade> niemeyer, we should do all our fuzzy guessing at defaults OAOO, when we load the config
<niemeyer> fwereade: I don't think that's the case today, and it doesn't feel sane to force the user to have all possible keys, even those not wanted, set
<fwereade> niemeyer, having missing keys in the provider config has always been an irritation in the python
<niemeyer> fwereade: In which sense?
<fwereade> niemeyer, self.config.get("region", DEFAULT_REGION) all over the place, occasional self.config["region"]s that blow up at unexpected times
<fwereade> niemeyer, it's just ugly
<fwereade> niemeyer, and I don't see why we shouldn't construct complete configs with real values as soon as they enter the system
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: This is bogus indeed
<fwereade> niemeyer, yeah... I was somewhat upset when I saw we'd copied those flaws over
<niemeyer> fwereade: The point, though, is that some values may be actually missing. You seem to be implying what I said above regarding having unset keys behaving as "", though
<niemeyer> fwereade: Not all values have defaults
<niemeyer> fwereade: In some, the "unset" value is signal
<fwereade> niemeyer, hmm, yes; I don't see any of those in go atm though
<niemeyer> fwereade: That's not relevant.. the system is far from complete. We're talking about what we want to happen in those cases.
<niemeyer> fwereade: We also can't default to "", because our config is typed
<fwereade> niemeyer, fair point, ok, but consider a setting that *does* have a significant effect, like ec2-uri
<niemeyer> fwereade: Yep, good example
<niemeyer> fwereade: What's your feeling about it?
<fwereade> niemeyer, that an unset ec2-uri is a really bad signal for "not really EC2, modify behaviour appropriately" :)
<fwereade> niemeyer, it's all very well in a user config
<fwereade> niemeyer, but internally I would far rather have "ec2-uri" always containing a real value, and another "this-is-not-really-ec2" value that controls the different behaviour
<niemeyer> fwereade: I'd rather not, to be honest
<niemeyer> fwereade: Or maybe I do.. hmm
<niemeyer> fwereade: digesting, just a sec
<fwereade> niemeyer, it does feel like squishing far too much subtle meaning into a single value
<niemeyer> fwereade: I don't understand that.. it's the endpoint we're talking to.. how's that subtle?
<fwereade> niemeyer, that bit is fine... but let me find a code ref
<fwereade> niemeyer, ok, its impact is limited, because I got annoyed and did this:
<fwereade>     @property
<fwereade>     def using_amazon(self):
<fwereade>         return "ec2-uri" not in self.config
<fwereade> niemeyer, and even that is not heavily used
<niemeyer> fwereade: This is wrong, actually
<niemeyer> fwereade: Because it may be set to an endpoint in Amazon
<fwereade> niemeyer, it's wrong if someone sets ec2-uri explicitly
<niemeyer> fwereade: I don't understand this particular issue
<niemeyer> fwereade: Why!?
<niemeyer> fwereade: It certainly wasn't the intention when I put it there
<fwereade> niemeyer, that is what AFAIK it has always been used for
<fwereade> niemeyer, I always considered it somewhat nasty
<niemeyer> fwereade: The goal of this setting is to send the endpoint manually, as its name indicates
<niemeyer> fwereade: I don't get the leap on how it can be something else than that
<fwereade> niemeyer, so, yes, it would be *even* better if we didn't have this ugly and frequently-incorrect overloading of meaning
<fwereade> niemeyer, I would guess that someone doing non-ec2 ec2 provider work made an unhelpful assumption
<fwereade> niemeyer, I stipulate that a this-is-not-amazon setting would be superior in every way
<niemeyer> fwereade: Yeah, that sounds like the heart of the issue we've been brainstorming on
<niemeyer> fwereade: If we need such a setting, +1
<fwereade> niemeyer, but then, assuming we fix that
<niemeyer> fwereade: Do we need such a setting?
<fwereade> niemeyer, possibly, and possibly not, I would have to look through a bit more carefully
<fwereade> niemeyer, but, ok, consider a correct ec2-uri setting
<niemeyer> fwereade: Okay
<fwereade> niemeyer, how do we gain by leaving that as "", when we could just as easily infer the real value *only* when parsing user configs, and ensure that the contents of /environment are always correct and need no further substitutions?
<niemeyer> fwereade: Because when a user questions for the configuration of their environment, I'd rather tell them what they've set
<niemeyer> fwereade: We also lose the ability to do changes
<niemeyer> fwereade: It's fine to adapt values we've set ourselves.. it's not fine to hack user-given values in general
<fwereade> niemeyer, I feel that argument might not apply all that well to omitted settings... don't they imply "figure it out for me", rather than "I wish to communicate with the fairyland EC2 which has no endpoint?" ;)
<niemeyer> fwereade: Exactly
<niemeyer> fwereade: What I mean is that "figure out for me" does not mean "figure out for me just when I bootstrap"
<fwereade> niemeyer, ok, I've caught up, I think I agree there :)
<fwereade> niemeyer, so there are indeed some settings that can reasonably be left unset
<fwereade> niemeyer, and still have a valid config
<fwereade> niemeyer, how does authorized-keys fit in here?
<fwereade> niemeyer, I'm pretty certain that should be an environment setting
<fwereade> niemeyer, and I'm also pretty sure that existence of authorized-keys-*path* in the /environment node indicates that we've screwed up pretty badly
<niemeyer> fwereade: Agreed on both
<niemeyer> fwereade: keys-path should be translated to keys as we do today
<fwereade> niemeyer, ok; would you agree that an authorizedKeysPath field on environConfig is an unwarranted temptation to foolishness?
 * niemeyer looks
<niemeyer> fwereade: Which environConfig?
<fwereade> niemeyer, ec2
<niemeyer> fwereade: You mean providerConfig?
<fwereade> niemeyer, er, sorry, yes
<niemeyer> fwereade: np, just to make sure we're on the same page
<niemeyer> fwereade: Do you have alternative suggestions?
<fwereade> niemeyer, essentially, that we have 2 paths for config parsing -- fuzzy user configs and strict internal configs
<fwereade> niemeyer, strict configs can have empty values as discussed above ofc, but we do need to do slightly different work when interpreting user configs and when checking for validity of internal ones
<niemeyer> fwereade: Feels like a lot of code and work for a one-off field
<fwereade> niemeyer, similar considerations IMO apply to region
<niemeyer> fwereade: Hm.. why?
<niemeyer> fwereade: The path is special because we load from the filesystem on one side, and don't care about the other side
<fwereade> niemeyer, because region is an env property that should be immutable
<niemeyer> fwereade: The region doesn't feel similar
<fwereade> niemeyer, the "what if the default changes" argument applies in the opposite direction
<niemeyer> fwereade: The path being changed is irrelevant
<niemeyer> fwereade: A region being changed can be caught up on SetConfig and refused
<niemeyer> fwereade: Seem simple
<niemeyer> Seems
<fwereade> niemeyer, I was referring to the "changing defaults" argument you made wrt ec2-uri
<niemeyer> fwereade: Erm.. I'm even more confused now
<fwereade> niemeyer, if we change the ec2-uri default it is a bad thing to have baked it in from the start
<fwereade> niemeyer, if we change the region default it is a bad thing NOT to have baked it in from the start
<niemeyer> fwereade: I'm not suggesting we change anything right now..
<niemeyer> fwereade: I was pointing out reasoning why having unset fields matters
<niemeyer> fwereade: The region may be hardcoded yeah, because it can't be changed
<fwereade> niemeyer, ok, and that then implies again that if we get an /environment without a region, we have screwed up, just as we have if we get an /environment with an authorized-keys-path
<fwereade> niemeyer, and hence is IMO support for the idea that user configs and internal configs are different enough that we want separate paths for interpreting them
<niemeyer> fwereade: Sorry, I don't see the relation between these two points.
<fwereade> niemeyer, both should translate to the same type
<niemeyer> if region == "" { region = "us-east-1" }
<niemeyer> fwereade: Why are we discussing this? :)
<niemeyer> fwereade: The path case is special.. the region case is trivial
<fwereade> niemeyer, because I think that interpreting an /environment config in exactly the same way as one from environments.yaml is sloppy and risks bugginess
<niemeyer> fwereade: I've been trying to demonstrate that this is not the case.. preventing a region from changing is if oldRegion != newRegion && oldRegion was set { return error }
<niemeyer> fwereade: We don't need a new code path for these three lines
<niemeyer> fwereade: Do I misunderstand?
<fwereade> niemeyer, since you're talking about changing regions at runtime, I think so
<niemeyer> fwereade: Okay, so please bear with me while I adapt to reality
<fwereade> niemeyer, earlier you pointed out that some settings should remain empty, and not be baked in at parse time, on the basis that we may wish to change the defaults in future and having them baked into the env config would therefore be bad
<fwereade> niemeyer, agreed?
<niemeyer> fwereade: Can we please focus on the specific issue of region being changed?
<niemeyer> fwereade: Otherwise we'll derail I think
<fwereade> niemeyer, this is directly relevant to region changes
<niemeyer> fwereade: Yeah, so how is region changed difficult to do with current infra?
<fwereade> niemeyer, do you agree with how I characterised your position above?
<niemeyer> fwereade: THat's the core point
<niemeyer> fwereade: Okay, I guess you do want to review the points made?
<fwereade> niemeyer, I am laser-focussed right at the moment, because I think it will help our communication
<niemeyer> fwereade: Ok
<fwereade> niemeyer, do you agree with my statement that " earlier you pointed out that some settings should remain empty, and not be baked in at parse time, on the basis that we may wish to change the defaults in future and having them baked into the env config would therefore be bad"
<niemeyer> fwereade: More precisely,
<niemeyer> fwereade: So the point I made is that having unset values allows us to change the values *when that's wanted*, and I also said that it makes sense to allow values to be unset because some settings have unset values naturally, and we can't have a value like "" for unset because we have typed values in the configuration, and also that we want to show users the configuration that they've made
<fwereade> niemeyer, maybe we should skip sideways a little -- what is the distinction between a "naturally unset value" and an unset value that indicates that some default substitution should be made?
<fwereade> niemeyer, can you give me an example of the first kind?
<niemeyer> fwereade: A naturally value is any value that is unset, and should remain as so because we want to know it's unset
<fwereade> niemeyer, but I can think of two cases where failing to bake them in will kill environments (even if one of them is historical)
<fwereade> niemeyer, that is, will kill environments if we ever change the default settings
<niemeyer> fwereade: I don't understand.. suppose we have a new "environment-description" field
<niemeyer> fwereade: By default we call it "No description for this environment."
<niemeyer> fwereade: We've made a typo.. now we want to fix it
<niemeyer> fwereade: Bingo.. we change the code so that the unset value now returns the proper description.
<fwereade> niemeyer, ok, that is an example where there are distinct benefits to deferring the substitution rather than doing so at parse time
<niemeyer> fwereade: If the user has put his own description, though, we don't want to touch that.
<fwereade> niemeyer, I am aware of these examples
<fwereade> niemeyer, you already explained it perfectly wrt ec2-uri
<niemeyer> fwereade: Yeah.. so can we go back to region?
<fwereade> niemeyer, absolutely! what happens when we change the default ec2 region and it has been left unset?
<niemeyer> fwereade: We don't change it
<fwereade> niemeyer, never ever?
<niemeyer> fwereade: How can we possibly change the region of a running environment?
<fwereade> niemeyer, well, yeah, that would be crackful
<fwereade> niemeyer, how can we possibly predict thatus-east-1 will be the appropriate default region for ever and ever?
<niemeyer> fwereade: We can't, we shouldn't, and as far as we know, we don't.. !?
<fwereade> niemeyer, well, if we allow region to remain unset, how can we prevent a default region change from causing a *runtime* region change when that env is upgraded?
<niemeyer> fwereade: Why don't we set the region?
<niemeyer> Jul 05 10:04:14 <niemeyer>      if region == "" { region = "us-east-1" }
<fwereade> niemeyer, well, we do; but that's a setting that the user did not make
<fwereade> niemeyer, you seemed to be arguing that we should not do that
<niemeyer> <niemeyer> fwereade: So the point I made is that having unset values allows us to change the values *when that's wanted*
<fwereade> niemeyer, agreed and understood
<niemeyer> Jul 05 10:04:14 <niemeyer>      if region == "" { region = "us-east-1" }
<niemeyer> fwereade: I said that :)
<fwereade> niemeyer, you *also* argued, and reiterated, that we should not show the user settings that they did not set
<niemeyer> fwereade: True
<fwereade> niemeyer, these positions are in conflict
<niemeyer> fwereade: The region case is fine, though
<niemeyer> fwereade: and I've been saying that for a while
<niemeyer> Jul 05 10:01:50 <niemeyer>      fwereade: The region may be hardcoded yeah, because it can't be changed
<niemeyer> fwereade: That said, there's a bit missing it seems, which is why I was trying to focus on how we do that in practice and avoid side-tracking
<fwereade> niemeyer, I have shown you 2 ways in which a user config is a stupid /environment config -- authorized-keys-path and region -- and I can name more (acquired-mgmt-class and available-mgmt-class, off the top of my head)
<niemeyer> fwereade: It doesn't look like there's a place for us where we get an Environ to intercept a configuration that is about to be put in SetConfig, in a way that it has both the old and the new config
<niemeyer> fwereade: Sorry, that path has proven unhelpful already.. I've been repeatedly pointing out that region is easy to solve, and you've failed to provide any facts for why it's not
<niemeyer> fwereade: If there's a reason why region is hard to solve, please tell me as I do want to understand
<niemeyer> fwereade: But focus on it.. no backtracking
<fwereade> niemeyer, region is not hard to solve in the small
<fwereade> niemeyer, the fact is that certain values, one of which is region, can be safely omitted from environments.yaml but should not be omitted in /environment
<fwereade> niemeyer, and that certain values that can be set in environments.yaml *should* be omitted in /environment
<fwereade> niemeyer, I am arguing that there is a meaningful distinction between parsing the two environment configuration styles, and that using the same code to do so is going to bite us one day
<niemeyer> fwereade: I find much more likely that duplicating the same configuration parsing with different semantics will bite us.
<niemeyer> fwereade: If we have problems, let's address them
<niemeyer> fwereade: The one thing I see missing is a way to handle a configuration delta for an environment
<niemeyer> fwereade: At no point the Environ has both old and new config in a way it could refuse it
<fwereade> niemeyer, agreed
<niemeyer> fwereade: I suggest introducing ValidateConfigChange(oldConfig, newConfig)
<niemeyer> fwereade: In the EnvironProvider interface
<niemeyer> fwereade: And explicitly state that oldConfig will be nil when it's first set
<niemeyer> fwereade: So that we can introduce logic in there which can act on initial setup
<niemeyer> fwereade: Such as the handling of -path
<fwereade> niemeyer, hmmm, ok, I think I see where you're going
<fwereade> niemeyer, this would indeed address the potential problem of incompatible config replacements
<niemeyer> fwereade: and give an entry point for handling the harcoding of region, and the weirdness of path
<fwereade> niemeyer, ie, exploding if we see missing region or existing path?
<niemeyer> fwereade: Missing region is fine, we hardcode it to us-east-1 on first setup
<fwereade> niemeyer, sure, ok, thinko
<fwereade> niemeyer, but seeing an attempt to replace with missing, or otherwise change it
<niemeyer> fwereade: existing path is an interesting question..
<niemeyer> fwereade: I think we should ignore the setting
<niemeyer> fwereade: and clean it up after we load it onto -keys
<niemeyer> fwereade: So the env deployment only ever sees -keys
<niemeyer> fwereade: Or!
<niemeyer> fwereade: Perhaps even better
<niemeyer> fwereade: We can load it and compare to the current -keys, and update it if so
<niemeyer> fwereade: But never let -path itself pass onto the state
<niemeyer> fwereade: We don't even have to compare I guess
<fwereade> niemeyer, wait, when are we replacing env configs at runtime on the client?
<niemeyer> fwereade: juju set-env?
<niemeyer> fwereade: and on the first deploy
<niemeyer> fwereade: That stuff is done in the client
<niemeyer> fwereade: Server side is too late..
<fwereade> niemeyer, ahhh, ok, so only on the first SetConfig
<niemeyer> fwereade: juju set-env should do something like: 1) State.EnvironConfig; 2) update EnvironConfig with keys provided in the cmd line; 3) call ValidateConfigChange(old, new); 4) if all good, call SetEnvironConfig on State
<fwereade> niemeyer, where's the Environ?
<niemeyer> fwereade: No where in that picture..
<fwereade> niemeyer, ah, I think I misunderstood you when you said "EnvironProvider interface" above
<niemeyer> fwereade: Yeah, I meant EnvironProvider interface indeed, not Environ
<fwereade> niemeyer, sorry :)
<niemeyer> fwereade: By the time it reaches the Environ it should be sweet
<fwereade> niemeyer, ok, I need to think about this some more -- I do see it will be useful
<fwereade> niemeyer, a semi-related thought: why do we error out when parsing environments.yaml if any environ has a problem? (unless that problem is "unknown type" in which case we continue)
<niemeyer> fwereade: Convenience, probably.. I don't see either way as being specially better than the other
<fwereade> niemeyer, how would you feel about ignoring invalid environments in the same way we do ones with unknown providers?
<niemeyer> fwereade: Sounds fine
<niemeyer> fwereade: Assuming it's not the one in use, of course
<fwereade> niemeyer, indeed so, I need to double-check how that's handled, but it should be fine
<fwereade> niemeyer, ok; *then*, how would you feel about dropping authorizedKeysPath from ec2.providerConfig, and loading them into .authorizedKeys when we encounter them?
<fwereade> niemeyer, with what I suggested above, a bad setting won't prevent other envs from loading; but it will mean we don't have this lurking field that is profoundly wrong if used on the server side
<fwereade> niemeyer, (yeah, attempts to Open that environ will fall over wit the original error)
<niemeyer> fwereade: ValidateConfigProvider takes two configurations, which were previously parsed, in a single location
<niemeyer> fwereade: Considering this, it's not clear to me what you're suggesting
<niemeyer> Sorry, I meant ValidateConfigChange
<niemeyer> fwereade: Where would the -path be translated into -keys?
<fwereade> niemeyer, I'm suggesting we do that when we load the environments.yaml, and wondering whether you would consider that to be evil
<niemeyer> fwereade: Where would that be?
<fwereade> niemeyer, ec2.NewConfig
<niemeyer> fwereade: Hmm
<fwereade> niemeyer, (ok, so technically just a fter we load the environments.yaml ;))
<niemeyer> fwereade: Seems alright
<niemeyer> fwereade: We can easily move if we find a reason why that's bad at some point
<fwereade> niemeyer, cool, it will make me much more comfortable, at least at the moment :)
<niemeyer> fwereade: That's great :)
<fwereade> niemeyer, cheers
<niemeyer> Lunch time
 * niemeyer waves
<fwereade> niemeyer, ping
<niemeyer> fwereade: pongus
<fwereade> niemeyer, I've been wondering about juju.Conn.Environ
<fwereade> niemeyer, and have been unable to figure out whether it matters that it is potentially out of sync with the state
<fwereade> niemeyer, I think the answer is probably "not yet, but it will do as soon as we can extract config information from it"
<niemeyer> fwereade: Do you have a scenario that is concerning you, so that I can better approach your thinking?
<fwereade> niemeyer, well, a while ago IIRC we tentatively agreed that DefaultSeries would be a sensible thing to add to Environ
<fwereade> niemeyer, if it is, then as soon as the deploy command tries to get it (as loaded from environments.yaml) rather than from the /environment-backed config
<fwereade> niemeyer, ...then we have a problem
<fwereade> niemeyer, I am -1 on that now
<fwereade> niemeyer, we probably need DefaultSeries, and the other common properties, on EnvironConfig
<fwereade> niemeyer, and since we can't get an EnvironConfig from an Environ it thus doesn't matter
<fwereade> niemeyer, since the only thing we will need from Environ is Secrets
<fwereade> niemeyer, and that will only be relevant when the State environ config has no secrets of its own to overwrite
<niemeyer> fwereade: Hmm
<fwereade> niemeyer, so, on reflection, what I'm really asking is "are we OK with adding DefaultSeries, Name, Type, etc, (AuthorizedKeys?) to EnvironConfig?"
<niemeyer> fwereade: We can't get an EnvironConfig from an Environ?
<fwereade> niemeyer, don't think so, may be blind
<fwereade> niemeyer, nope, no access
<niemeyer> fwereade: A bit surprising, but I guess it's ok.. we need the config to create the environ in the first place
<niemeyer> fwereade: Which means we must already have it
<fwereade> niemeyer, I think this is actually a good thing, there's no need to know any of that information (other than the secrets) from the Environ
<niemeyer> fwereade: So, to your question
<niemeyer> fwereade: What do you mean by "DefaultSeries", more precisely?
<niemeyer> fwereade: What is that, a constant, a method, ..?
<fwereade> niemeyer, I mean the value of the default-series key, returned from a method that is part of the EnvironConfig interface
<niemeyer> fwereade: No, that's bogus
<niemeyer> fwereade: Wait, wait
<niemeyer> fwereade: Not in the way I initially thought.. I see you selected the things that are meaningful cross env
<niemeyer> fwereade: Hmmm
<fwereade> niemeyer, yeah, that was the idea
<niemeyer> fwereade: Not sure.. it feels like we'll be increasing the API surface, and in a way faking it out because we do need to know the string values in more than one place (set-env, parsing, etc)
<niemeyer> fwereade: What's the goal?
<fwereade> niemeyer, proximate goal is "implement deploy as required" ;)
<fwereade> niemeyer, for that I need the default-series one way or another
<fwereade> niemeyer, and I'm not quite sure that it's better to have State.EnvironDefaultSeries than it is to have State.EnvironConfig return an EnvironConfig that I can then ask
<niemeyer> fwereade: Sure, but what I'm comparing against is config.Get("default-series")
<fwereade> niemeyer, ofc I could just use the ConfigNode directly :)
<niemeyer> fwereade: Which you can then ask anyway
<niemeyer> fwereade: Didn't we talk about that yesterday, or was it Dave?
<fwereade> niemeyer, I guess I just hate having the environment config node available for direct manipulation outside the state package
<niemeyer> fwereade: I see
<niemeyer> fwereade: So, I like the principle of what you want too
<fwereade> niemeyer, you seemed cautiously +1 on State.EnvironConfig returning an actual EnvironConfig earlier :)
<niemeyer> fwereade: Let's try to solve the key issue I mentioned above then
<niemeyer> fwereade: Yes, I still am
<niemeyer> fwereade: It sounds reasonable.. we just have to solve that mismatch in a nice way
<fwereade> niemeyer, jolly good :)
<niemeyer> fwereade: We have two places (config and cmdline) talking about env-config in terms of string keys
<niemeyer> fwereade: How do we translate that?
<fwereade> niemeyer, well, I'm not 100% sure on this, but for context's sake consider get_serialization_data in python
<fwereade> niemeyer, I don't think we *have* to expose it in the same way, but it might be quite nice
<fwereade> niemeyer, ha, no, forget it
<fwereade> niemeyer, the keys in that are not necessarily the valid keys for the env
<niemeyer> fwereade: Right
<niemeyer> fwereade: We're translating key <=> method
<niemeyer> fwereade: and there's the extra complexity that Environ is an interface
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: That translation is exactly what NewConfig does
<fwereade> niemeyer, those schema.FieldMaps are looking like they suddenly want to be reused somehow :)
<niemeyer> fwereade: They are already being used, precisely within NewConfig
<fwereade> niemeyer, yeah; and they're doing ~exactly the job we want them to do in env-set
<fwereade> niemeyer, except some can't be changed
<niemeyer> fwereade: Well, and that's exactly the method we should use there?
<fwereade> niemeyer, how do we properly error on unrecognised settings?
<niemeyer> fwereade: NewConfig does
<niemeyer> fwereade: (already)
<fwereade> niemeyer, no it doesn't
<fwereade> niemeyer, there's a commented-out test saying "should we error?"
<niemeyer> fwereade: Ah, sorry, ok.. it's the opposite.. it errors on required+not found
<fwereade> niemeyer, I would be +1 on making that stricter though
<niemeyer> fwereade: =1
<niemeyer> fwereade: +1
<niemeyer> fwereade: =1 is great, though :-)
<fwereade> haha
<fwereade> niemeyer, ok, with more strictness, it's trivial
<fwereade> niemeyer, grab serialization data from existing config, poke in new key, reparse, and ValidateConfigChange
<niemeyer> fwereade: Woohay!
<fwereade> niemeyer, ok, I'll make the parsing stricter
<niemeyer> fwereade: Reading it, ValidateConfig should be clear enough, btw
<niemeyer> fwereade: The parameters will make the semantics clear
<fwereade> niemeyer, with (old, new EnvironConfig), yeah
<niemeyer> fwereade: Right
<fwereade> niemeyer, bah, keyword
<fwereade> niemeyer, we'll think of something :)
<niemeyer> fwereade: Interestingly, it's not
<fwereade> niemeyer, oh! sweet!
<niemeyer> fwereade: new, make, delete, etc
<niemeyer> close
<fwereade> niemeyer, yeah, all functions :)
<fwereade> niemeyer, hadn't appreciated that properly until just now :)
<niemeyer> fwereade: Yeah, handy
<fwereade> niemeyer, anyway, I'd better be off for a bit
<fwereade> niemeyer, ttyl
<niemeyer> fwereade: Have a great one
<fwereade> davecheney, ping
<davecheney> fwereade: ack
<fwereade> davecheney, I'm planning to change State.EnvironConfig and associated watcher to return actual environs.EnvironConfig~s; any thoughts/objections?
<davecheney> fwereade: is that type already in the tree ?
<fwereade> davecheney, yeah, it's the interface implemented by all env config types
<fwereade> davecheney, so hopefully the provisioner will just be able to SetConfig(newConf) and not worry about errors
<davecheney> fwereade: sounds excellent
<davecheney> my concern would be in the type of the thing that is passed to the SetConfig (ish) method in the actual provider
<fwereade> davecheney, assuming we manage to avoid monumental scrwups like somehow saving environments for the wrong type, anyway ;)
<davecheney> +1
<fwereade> davecheney, expand on concern?
<davecheney> fwereade: i'm guessing that inside, say, the ec2 environ, it still gets the config object of it's coerced type ?
<davecheney> if that is true, then I have no objection
<fwereade> davecheney, the Environ.SetConfig methods all cast to the appropriate type, and as I said if we don't manage to screw that up we're golden
<fwereade> davecheney, the plan is not to even bother sending configs that aren't valid
<davecheney> i originall had a type assertion at that point, but gustavo felt it was appropriate to just let the runtime panic
<davecheney> which is pretty reasonable given how hard you would have to fuck that up
<fwereade> davecheney, yeah, I think that's way over on the "programmer error" end of the spectrum
<fwereade> davecheney, f7u12: state.AssignmentPolify, state.Info; both used by environs; import loop
<fwereade> davecheney, not so bad, I just need to move them somewhere, but eww
<fwereade> davecheney, I'll decide where tomorrow, sleeping now ;)
<davecheney> urgh
<davecheney> fwereade: want to leave it with me ?
<fwereade> davecheney, no worries, I'll deal with it :)
<davecheney> kk
<fwereade> davecheney, (both of them seem to me to be reasonable members of environs instead; sanity check?)
<davecheney> niemeyer: thanks for the review
<davecheney> i'll do a followup fix for the lower case naming thing (fscking us-east-1)
<davecheney> fwereade: is there a commit syntax for lp that closes issues ?
<davecheney> Fixes issue 1234. ?
<fwereade> davecheney, err, I forget, something like that; but I think lbox takes -bug 123456
<davecheney> ahh, cool
#juju-dev 2012-07-06
<Aram> good morning.
<fwereade> yay, I has power
<fwereade> going out to get some coffee and a pastry, still recovering from broken fridge :/
<fwereade> heya TheMue
<TheMue> Hi fwereade
<TheMue> Hmm, I hope my line gets more stable when the new provider has set it up.
<TheMue> Just seen, need a new watcher.
<fwereade> TheMue, sorry, what watcher is that now? :)
<TheMue> fwereade: The ServiceWatcher for added or removed services. It's needed by the firewall.
<fwereade> TheMue, ah, cool
<TheMue> fwereade: Thx to your watcher changes it's pretty simple now.
<fwereade> TheMue, I kinda suspect that about 50% of juju will actually just be watchers of one sort or another by the time we're done :)
<fwereade> TheMue, awesome
<TheMue> fwereade: Yes, we're a kind of event-driven
<fwereade> TheMue, yeah, totally
<TheMue> fwereade: So one architecture alternative could have been that all those watchers publish their changes to a kind of bus where interested listeners subscribe to those events.
<fwereade> TheMue, not sure, there are a number of subtle ordering interactions in a couple of places
<fwereade> TheMue, we only want to watch X in between a specific pair of events on Y, for example
<fwereade> TheMue, and we don't want to just watch ALL THE CHANGES all the time
<fwereade> TheMue, I guess it could be done
<TheMue> fwereade: That's depending on the subscription mechanism, would be possible
<fwereade> TheMue, but I think unwatching X at the right time, in the example above, would be a bit fiddly
<fwereade> TheMue, offhand, do you know whether we currently have any mechanism for putting *valid* environment configs into /environment?
<fwereade> TheMue, I know we can poo an arbitrary map[string]interface{} in but I don't think there's yet any way to push a real env config implemented in real code
<TheMue> fwereade: No, that doesn't sound real got.
<TheMue> fwereade: The environment fields depend on the chosen environment?
<fwereade> TheMue, yeah
<fwereade> TheMue, I'm implementing bits and pieces in that area right now
<fwereade> TheMue, I'm just trying to figure out whether I will break things *any worse than they currently are* if I follow my preferred path
<TheMue> fwereade: So I would setup a type hierarchy per environment and implement a Validate() on each type working top-down.
<fwereade> TheMue, whoa, hierarchy?>
<TheMue> fwereade: I'm doing so for my private RSS and Atom implementation.
<TheMue> fwereade: And that could be marshaled to e.g. JSON inside the node.
<fwereade> TheMue, we already have code for validating them
<fwereade> TheMue, NewConfig :)
<TheMue> fwereade: Just see it, very generic.
<niemeyer> Morning!
<fwereade> niemeyer, heyhey
<niemeyer> fwereade: Heya!
<fwereade> niemeyer, how's it going?
<niemeyer> fwereade: Great
<niemeyer> fwereade: A little bit on the short side in terms of sleep, but hopefully will fix that tomorrow :)
<fwereade> niemeyer, awesome; thanks again for the conversation yesterday, everything seems to be lining up really neatly now
<niemeyer> fwereade: My pleasure!  Appreciated too.
<fwereade> niemeyer, I have a couple of CLs that should be short/sweet: https://codereview.appspot.com/6345071/ and https://codereview.appspot.com/6351068/
<TheMue> niemeyer: Morning
<niemeyer> TheMue: Heya
<niemeyer> fwereade: Looking
<niemeyer> fwereade: https://codereview.appspot.com/6345071/ done
<fwereade> niemeyer, cheers
<niemeyer> fwereade: I'm not sure about the other one.. what's the benefit?
<niemeyer> Aram: ping
<TheMue> Hmm, sh**, have to reboot. Back in a moment.
<fwereade> niemeyer, sorry, was making lunch
<fwereade> niemeyer, benefit is that we can make State.EnvironConfig return an environs.EnvironConfig
<fwereade> niemeyer, which really feels like the Right Thing now I've started implementing it
<fwereade> niemeyer, (but incorporating the move in the forthcoming CL for EnvironConfig felt a bit much)
<niemeyer> fwereade: How about moving EnvironConfig to state instead?
<fwereade> niemeyer, don't think so offhand -- we also need NewConfig, and IMO that's unquestionably part of environs
<fwereade> niemeyer, besides, the environs are meant to not depend on state, right?
<niemeyer> fwereade: Why do we need NewConfig on State?
<niemeyer> fwereade: Or is the state supposed to not depend on environs? ;-)
<fwereade> niemeyer, because if we try to do environs.NewConfig from state we get an import cycle
<niemeyer> fwereade: Why do we *need* NewConfig on state?
<niemeyer> fwereade:
<niemeyer> [niemeyer@gopher ..juju-core/state]% grep -r environs *
<niemeyer> [niemeyer@gopher ..juju-core/state]%
<fwereade_> niemeyer, sorry, don't know what happened there
<fwereade_> niemeyer, because State.EnvironConfig wants to return an EnvironConfig, and all it has is a map[string]interface{}
<niemeyer> fwereade_: Hmm.. something else seems wrong then
<niemeyer> Thinking
<niemeyer> fwereade_: Not sure if you've seen this, btw:
<niemeyer> niemeyer> fwereade:
<niemeyer> <niemeyer> [niemeyer@gopher ..juju-core/state]% grep -r environs *
<niemeyer> <niemeyer> [niemeyer@gopher ..juju-core/state]%
<fwereade_> niemeyer, yeah, tautologically so; environs was importing from state
<niemeyer> fwereade_: Yes, which is a point worth bringing into the discussion
<niemeyer> fwereade_: You say it's uncontroversial. It would be if we were simply taking a dependency down, but we're inverting a dependency
<niemeyer> fwereade_: Some of the purpose of the Conn, for example, is precisely to integrate an environ with a state
<fwereade_> niemeyer, environs is responsible for creating every known (non-test) instance of the types it imports from state
<fwereade_> niemeyer, from a certain perspective, environs is the only "source" of those types
<fwereade_> niemeyer, you were once very firm that environs must not depend on state -- do you recall something specific that changed your perspective?
<fwereade_> niemeyer, another thought; if InstanceId were a type, that would be another one that would naturally live in environs and be used by state
<niemeyer> fwereade_: That's not a relevant point.. the only purpose of state.Info is to provide it onto the state package as an argument to Dial. Of course it won't be *created* by the state package.
<fwereade_> niemeyer, fair point indeed
<fwereade_> niemeyer, the heart of it is that if we want State.EnvironConfig to return an environs.EnvironConfig, or even to be able to check the sanity of environment config changes, state needs to use environs
<TheMue> So, new ServicesWatcher for review is in.
<niemeyer> fwereade_: I'm not sure we do.. let's look at the overall issue without an established dogma to make sure we're doing the right thing
<niemeyer> fwereade_: Here is an idea..
<niemeyer> fwereade_: Configuration always comes in the form of keys, right?
<fwereade_> niemeyer, yes
<niemeyer> fwereade_: In state, in environments.yaml, and from the cmdline
<fwereade_> niemeyer, agreed
<niemeyer> fwereade_: We actually have infrastructure to deal with that information as keys even, in the form of the schema package
<fwereade_> niemeyer, right...
<niemeyer> fwereade_: So, it's at least interesting that we chose to transform that information onto a type so early on
<niemeyer> fwereade_: What if..
<niemeyer> fwereade_: EnvironsConfig was not an interface..
<niemeyer> fwereade_: EnvironConfig, that is
<niemeyer> fwereade_: But rather, *state.EnvironConfig
<niemeyer> ?
<fwereade_> niemeyer, how will that end up being noticeably different from the python-style data-bag?
<niemeyer> fwereade_: I don't know what's the underlying statement you're making with that. The configuration of an environment *is* a data bag.
<niemeyer> fwereade_: And this is quite bogus:
<niemeyer> / EnvironConfig represents an environment's configuration.
<niemeyer> type EnvironConfig interface {
<niemeyer>         // Open opens the environment and returns it.
<niemeyer>         Open() (Environ, error)
<niemeyer> }
<niemeyer> fwereade_: This is just wrong..
<fwereade_> niemeyer, ok, we followed this approach in python, and we ended up in a totally ridiculous situation, in which keys were added and used willy-nilly without even being used in the schema
<niemeyer> fwereade_: The interface of an environment configuration cannot tell us anything about the configuration, but *opens* the environment
<niemeyer> wtf?
<niemeyer> fwereade_: Well, we don't want that to happen for sure
<niemeyer> fwereade_: But that's a separate issue
<niemeyer> fwereade_: and one that you just helped solving, in fact ;)
<fwereade_> niemeyer, well, it is a big advantage of turning things into actual types as early as we can :)
<niemeyer> fwereade_: I'm not sure.. that's exactly why I started with this:
<fwereade_> niemeyer, how is the configuration of an environment anyone's business but the environ itself? there are, it is true, some common properties, but they can be added to the EnvironConfig interface as we feel the need for them
<niemeyer> <niemeyer> fwereade_: Here is an idea..
<niemeyer> <niemeyer> fwereade_: Configuration always comes in the form of keys, right?
<niemeyer> <niemeyer> fwereade_: In state, in environments.yaml, and from the cmdline
<niemeyer> <niemeyer> fwereade_: We actually have infrastructure to deal with that information as keys even, in the form of the schema package
<niemeyer> <niemeyer> fwereade_: So, it's at least interesting that we chose to transform that information onto a type so early on
<niemeyer> fwereade_: Aren't you trying to inject a dependency on environs onto the state just so you can get an EnvironConfig from it?
<niemeyer> fwereade_: Clearly it seems to be someone else's business too
<niemeyer> fwereade_: cmdline, state, config
<fwereade_> niemeyer, well, the state has to store EnvironConfigs somehow, right?
<niemeyer> fwereade_: The configuration of an environment has well known fields, and then other flexible fields
<fwereade_> niemeyer, sure, I would like at some stage to split the common fields out into their own type, but that's orthogonal
<niemeyer> fwereade_: What I'm suggesting is that we, actually, realize the EnvironConfig into exactly what it is
<niemeyer> fwereade_: We can have methods on it
<niemeyer> fwereade_: And can also have a Specific method, for example that returns all the unknown fields
<niemeyer> fwereade_: (*without* the well known ones.. we handle those internally)
<fwereade_> niemeyer, and how are we meant to have any sanity-checking on those unknown fields?
<niemeyer> fwereade_: That's the environ's business to do
<fwereade_> niemeyer, ok, so State.Set/UpdateEnvironConfig should just poo whatever it's given into /environment and damn the consequences?
 * niemeyer waits until fwereade_ relaxes again
 * fwereade_ is sorry, but this feels like a pretty fundamental change in direction of which I had no warning
<TheMue> fwereade_: Who, in the sense of which part of the code, knows what unknown fields are valid?
<fwereade_> TheMue, something in environs
<niemeyer> fwereade_: I think you're being slightly unfair
<niemeyer> fwereade_: You're the one changing the direction of things
<niemeyer> fwereade_: This is in state, today:
<niemeyer> / EnvironConfig returns the current configuration of the environment.
<niemeyer> func (s *State) EnvironConfig() (*ConfigNode, error) {
<niemeyer>         return readConfigNode(s.zk, zkEnvironmentPath)
<niemeyer> }
<niemeyer> fwereade_: We're "pooing" stuff with "damned consequences" in the current code base
<fwereade_> niemeyer, yes, and I feel it's a serious problem
<TheMue> fwereade_: If it's in environs it doesn't seem unknown to me. environs only should handle well knows fields. If we have a need for more we should define a validator function type so that the provider/user of those fields could also provide a validator.
<fwereade_> TheMue, so every time we create a State we pass in an EnvironConfigValidator?
<niemeyer> fwereade_: Yes, so let's run through this with less emotion, ok? I'm not changing the direction of anything, and I'm not taking you by surprise on anything
<fwereade_> niemeyer, you were very very clear in orlando that environs must not depend upon state
<TheMue> fwereade_: Only when changing the content of the EnvironConfig.
<niemeyer> fwereade_: and it does not depend on state.. it depends on data
<niemeyer> fwereade_: We can put EnvironsConfig onto  the foobar package if you want
<fwereade_> niemeyer, seeing environs using state, I thought "oh, that's just a mistake that has lain dormant because we hadn;t yet implemented enough to be aware of the problems"
<niemeyer> fwereade_: I didn't say in Orlando "let's make state depend on environs"
<niemeyer> fwereade_: Changing 6 by 12/2 won't help
<fwereade_> niemeyer, ok, so your position is that state and environ should not know about one another at all?
<niemeyer> fwereade_: Yes
<fwereade_> niemeyer, but state should hold environment configuration?
<niemeyer> fwereade_: Re-read that question again, and think through it in the broader sense of things for a moment
<niemeyer> fwereade_: What *is* the state?
<fwereade_> niemeyer, a description of the desired state of the environment?
<TheMue> fwereade_: Is it something that represents a state or is it something we only store convenient in ZK?
<niemeyer> fwereade_: Exactly.. it's the information about the whole environment
<fwereade_> TheMue, AFAICT it absolutely represents state... not sure what you're getting at
<niemeyer> fwereade_: We can put the type elsewhere
 * TheMue asks to reflect this topic from a distance.
<niemeyer> fwereade_: But the state will necessarily have to *hold the state configuration*!
<niemeyer> Erm
<niemeyer> fwereade_: But the state will necessarily have to *hold the environment configuration*!
<niemeyer> fwereade_: There's simply no option for it to not do it
<niemeyer> fwereade_: It does today, already
<fwereade_> niemeyer, yes, this is at the heart of my conviction that the state package is a natural consumer of the environs package
<niemeyer> fwereade_: That's the fundamental disagreement
<niemeyer> fwereade_: The environs package *talks to the environment*
<niemeyer> fwereade_: There's zero reason for the state package to talk to the environment
<fwereade_> niemeyer, which abstracts away the differing features of various environs such that they can be used by other code without them having to worry about the differences between them
<TheMue> fwereade_: My understanding has been that other packages (like environ) just *use* state.
<niemeyer> fwereade_: The right thing for us to do is to break the dependency, both ways
<fwereade_> niemeyer, ok, fine as far as it goes, wrt the types moved in the CL
<fwereade_> niemeyer, but it seems to me that it is valuable for the state to be able to validate its environ config somehow
<TheMue> IMHO environs has to read the configuration from state and instantiate the according "factory" (dislike the word) which then uses the config data to do the real setup.
<niemeyer> fwereade_: It's valuable to validate the environ config somehow, agreed
<niemeyer> fwereade_: The state doesn't have to do that, though
<fwereade_> niemeyer, and I don't see how it can do that without using code from the environs package
<niemeyer> fwereade_: The state package doesn't have to do that
<TheMue> niemeyer: Validation has to be provided by the various environs, EnvironConfig only provide a mechanism.
<niemeyer> TheMue: You can assume I understand that
<fwereade_> niemeyer, I would prefer that it be *impossible* to set a broken environment config via the state package
<TheMue> niemeyer: Fine
<fwereade_> niemeyer, I guess we could also pass a ConfigValidator into state.Open, or something..?
<fwereade_> niemeyer, hmm, ok, actually, the fundamental thing I don't understand is whystate  should not depend on environs
<TheMue> fwereade_: IMHO only when writing the config.
<fwereade_> niemeyer, would you expand on that a little?
<niemeyer> fwereade_: It feels like a slightly abstract goal to me. There are very few places the system gets unreliable configuration from the outside world.
<fwereade_> TheMue, so it's not worth checking validity on the way out? only on the way in?
<niemeyer> fwereade_: On the way out?
<TheMue> fwereade_: If it only can be written well validated, reading could be assumed as ok, yes.
<niemeyer> TheMue: +1
<niemeyer> fwereade_: We're not checking anything else for brokeness every time we load from state.. (?)
<fwereade_> niemeyer, aren't we? in general I think we return either errors or valid instances, rather than timebombs without errors
<TheMue> Exactly, only when during a following operation something weird is discovered an error is returned. This indeed can happen in operations depending on the config too (e.g. by changing it concurrently while it's already loaded by another part).
<niemeyer> fwereade_: No.. if you get "poo (*&@(*#&(!" as a service name.. do we validate that?
<niemeyer> fwereade_: This feels like a total departure
<fwereade_> niemeyer, yeah, probably
<fwereade_> niemeyer, could we return to "why should state not use environs" please? I think there's something I'm missing there
<TheMue> Errors always may and can happen, so it's more useful to keep our software handling those errors well.
<TheMue> fwereade_: It's a dependency thingy. environs uses state, state uses environs? Can't say exactly why, but I dislike this behavior.
<fwereade_> TheMue, that's unpossible :)
<niemeyer> fwereade_: Because it's much easier to keep things on track that way. The environs package and the specific implementations of environs have the goal of talking to an IaaS provider.
<niemeyer> fwereade_: The state package has no business there.
<niemeyer> fwereade_: If we start breaking that line, something is going wrong
<niemeyer> fwereade_: That said,
<niemeyer> fwereade_: I wouldn't be opposed to, for example,
<fwereade_> niemeyer, I agree with that bit unquestionably :)
<niemeyer> fwereade_: Introducing the environs/config package
<niemeyer> fwereade_: and importing *that* from state
<fwereade_> niemeyer, it's the other direction I don't see a fundamental problem with, because the state describes the environ and it seems odd to stipulate that it cannot know anything about the environ
<fwereade_> niemeyer, ah-ha!
<fwereade_> niemeyer, I can totally live with that
<niemeyer> fwereade_: Woohay middle ground ;0
<niemeyer> ;)
<fwereade_> :D
<TheMue> :D
<fwereade_> niemeyer, so the Open stuff stays in environs, and all the other config stuff moves?
<niemeyer> fwereade_: Yeah, we'll have to figure how to handle Open
<niemeyer> fwereade_: I never liked the idea of EnvironConfig handling Open, fwiw
<niemeyer> fwereade_: I think EnvironProvider.Open sounds sane..
<fwereade_> niemeyer, that sounds pretty plausible to me
<fwereade_> niemeyer, I'll kick it around and see how it turns out
<niemeyer> fwereade_: Btw, I have a bikesheddy desire of renaming env to envs
<niemeyer> Erm
<niemeyer> fwereade_: Btw, I have a bikesheddy desire of renaming environs to envs
<niemeyer> and Environ to Env
<niemeyer> :-)
<niemeyer> Maybe some day
<fwereade_> niemeyer, +1 but it feels like a distraction right now ;)
<niemeyer> fwereade_: It is
<fwereade_> niemeyer, other issue -- should we keep Info and AssignemntPolicy in state, and consider environs' usage of same to be an acceptable purity break?
<fwereade_> niemeyer, if not, where do they go?
<niemeyer> fwereade_: I think both of these belong in state
<niemeyer> fwereade_: Inherently
<niemeyer> fwereade_: Info we've talked about
<niemeyer> fwereade_: AssignmentPolicy is logic fully implemented in state
<fwereade_> niemeyer, yeah, I'm ok with it, just wanted to confirm
 * fwereade_ breaks out the chainsaw and goes to work on environs :)
<niemeyer> fwereade_: ROTFL
<TheMue> fwereade_: Be careful, don't forget the earmuffs and safety glasses.
<TheMue> So folks, will continue tomorrow. Have to do some final preparations before the birthday guests are coming.
<niemeyer> TheMue: Oh, is it your birthday today?
<niemeyer> fwereade_: Oh, btw, I was going to ask you earlier about mstate vs. the test reorganization
<niemeyer> fwereade_: Have you had a chance to look at that?
<Aram> niemeyer: pong, oops, different computer.
<Aram> niemeyer: thanks for the reviews.
<Aram> reviewing the reviews.
<Aram> great, thanks.
<Aram> niemeyer: I can answer the last question, I am duplicating william's changes.
<fwereade_> niemeyer, yeah, I started talking to Aram and he was already on it :)
<fwereade_> (so it was a short conversation :))
<niemeyer> Aram, fwereade_: Thanks!
 * fwereade_ straightens up, bloody to the elbows
<fwereade_> niemeyer, https://codereview.appspot.com/6355077 :)
<niemeyer> fwereade_: Awesome!
<niemeyer> fwereade_: I'll have a look right after lunch
<fwereade_> niemeyer, cool, enjoy :)
<niemeyer> fwereade_: Thanks!
<niemeyer> fwereade_: The CL is not quite what I had in mind
<niemeyer> fwereade_: Just thinking through about pros/cons now
<niemeyer> fwereade_: https://gist.github.com/3061697
<niemeyer> fwereade_: Do we need anything else?
<niemeyer> Aram: ping
<Aram> pong niemeyer.
<niemeyer> Aram: Yo
<Aram> hey.
<niemeyer> Aram: How're you doing there.. are you working or relaxing?
<niemeyer> Aram: I was going to invite you for a call, but I know it's late
<niemeyer> Aram: So it can wait if that's the case
<Aram> yeah, I'm working, I've had some errands to do today, but I'm compensating this evening/night.
<niemeyer> Aram: Awesome, can we have a quick sync up call then?
<Aram> yes, yes, skype?
<niemeyer> Aram: G+?
<Aram> ok
<niemeyer> Aram: Inviting
<niemeyer> Aram: https://codereview.appspot.com/6356060/diff2/2001:6002/mstate/service.go
<niemeyer> Aram: unit.Life()
<niemeyer> Aram: Remove only Life() == Dead
<niemeyer> Aram: SetLife..
<Aram> https://codereview.appspot.com/6356060/diff2/2001:6002/mstate/state.go?column_width=80
#juju-dev 2012-07-07
<fwereade> niemeyer, response to https://codereview.appspot.com/6355077/ fwiw
<niemeyer> fwereade: I'm almost done with the reply
<fwereade> niemeyer, cool :)
<niemeyer> fwereade: Done
<niemeyer> fwereade: Actually, we don't need Get and Set..
<niemeyer> fwereade: If Validate wants to mutate the configuration, grab the map, do whatever, and return a new config
<niemeyer> fwereade: This way a Config is immutable
<niemeyer> fwereade: Which is a nice property and goes towards your desires
<fwereade> niemeyer, ok, that would probably work for me
<niemeyer> fwereade: So ValidateConfig(old, new) => (valid *Config, err error)
<fwereade> niemeyer, yes indeed (sorry, laura is being obnoxious ;))
<niemeyer> fwereade: It's Saturday, she's right! :p
<fwereade> niemeyer, nah, hitting me in the balls when I censured her for interrupting a conversation ;p
<niemeyer> fwereade: ROTFL
<niemeyer> fwereade: That's a bit extreme indeed ;-)
<fwereade> niemeyer, (I don't think it was deliberately targeted but that did not make it a notably more enjoyable experience ;))
<niemeyer> fwereade: I know.. it's just the easiest target for her size
<fwereade> niemeyer, yeah :)
<fwereade> niemeyer, my only reservation remains that I don't really see on what basis you make the distinction between environ config and all the other things that we handled as dicts in python
<fwereade> niemeyer, I've been loving knowing exactly what's in the types and don;t really see any drawbacks :)
<niemeyer> fwereade: I think you're too focused on how Python used a dict for the configuration
<niemeyer> fwereade: The configuration *is* a dict
<niemeyer> fwereade: That's not the issue per se
<niemeyer> fwereade: and as I explained in the reply, you'll continue having a type in the exact places we have them today
<niemeyer> fwereade: Nothing is changing
<niemeyer> fwereade: We're just gaining in: a) Being able to carry that type around in a better form, in and out of state; b) Having a proper interface that reveals the common fields; c) Having a properly typed EnvironConfig in *more* places
<niemeyer> fwereade: Right now we do provider.NewConfig(attrs).Open()
<niemeyer> fwereade: We'll now do provider.Open(config)
<niemeyer> fwereade: The typing happens inside the same path
<fwereade> niemeyer, that is indeed surely nicer
<fwereade> niemeyer, I think the specific thing I am paranoid about is that State.SetEnvironConfig will be unable to do appropriate replacement validation, and I prefer to mistrust my clients (even when I myself am writing the client ;))
<niemeyer> fwereade: I have the same concern, and I see the solution I'm suggesting as doing a better job in exact that regard
<niemeyer> fwereade: SetEnvironConfig is too late for doing validation.. we shouldn't allow an invalid config to ever reach it
<niemeyer> fwereade: The proper place to do configuration validation is "at the door"
<fwereade> niemeyer, I totally agree there -- it's just that, well, bad things happen and stupid code slips in, and I'm twitchy about being unable to do sanity-checking in the state package
<fwereade> niemeyer, offhand we want to set env state (1) at Initialize time, (2) at env-set time, (3) (probably) when setting constraints when we get to them and (4) on first secure connection, for the secrets
<fwereade> niemeyer, the burden of putting the sanity-checking in each of those places is I agree not overwhelming
<fwereade> niemeyer, but my heart says that I should be able to fling anything I want at State.SetEnvironConfig and have it dourly block crazy requests
<niemeyer> fwereade: Man.. do you want me to implement that?
<niemeyer> fwereade: This is trivial really
<niemeyer> fwereade: We only need a single function that does validation of configuration at entrance
<niemeyer> fwereade: This is getting totally out of proportion to the actual problem
<fwereade> niemeyer, sorry, I'm not even really arguing against your approach any more -- I'm mostly just trying to figure out where I'm being crazy
<niemeyer> fwereade: The root of the problem is that you're obsessed about doing validation at SetEnvironConfig, and can't see that it's trivial to do validation in *one single place* elsewhere
<niemeyer> fwereade: That should be the place where we get EnvironConfig from..
<niemeyer> fwereade: If the way we use to load EnvironConfig validates it, how can we possibly get an EnvironConfig into State.SetEnvironConfig that is invalid?
<fwereade> niemeyer, ok, I appear to have missed something... the Validate method you propose takes a *Config
<fwereade> niemeyer, well, two, but I thought you were saying we should be calling ValidateConfig(nil, someConfig)
<niemeyer> fwereade: Yes, that's the interface through which the *provider* validates the config
<niemeyer> fwereade: Who calls it?
<niemeyer> fwereade: How do we get from yaml onto a *Config?
<fwereade> niemeyer, ok; but that is not validating at the gate
<niemeyer> fwereade: No, it's not, it's infrastructure to do what must be done
<niemeyer> fwereade: We can have something within environs itself that validates it at the door
<niemeyer> fwereade: Leave Read there, for example
<niemeyer> fwereade: and run ValidateConfig on all configuration we get from environments.yaml
<fwereade> niemeyer, ok, *that* SGTM
<fwereade> niemeyer, it seemed to me that I had propsed something that validated at the gate and you were saying we didn't need that
<niemeyer> <niemeyer> fwereade: We only need a single function that does validation of configuration at entrance
<fwereade> niemeyer, (I'm not *specifically* obsessed with validating in state -- more with being sure that if I see a *Config I can know is actually valid)
<niemeyer> <niemeyer> fwereade: The proper place to do configuration validation is "at the door"
<niemeyer> fwereade: It seems like I've been repeating that since yesterday
<fwereade> niemeyer, yeah, and your proposed solution did not allow for that -- but I think moving Read/ReadBytes does
<niemeyer> fwereade: How did it not allow hat?
<niemeyer> that
<fwereade> niemeyer, I guess I'm missing something still... how did it allow for it?
<niemeyer> fwereade: Can you please tell me what do you see as a blocker?
<niemeyer> fwereade: I've been saying the same thing, so maybe if you tell me what's the limitation I can fix my explanation, or figure what I'm thinking wrong
<fwereade> niemeyer, it seemed to be explicitly allowing for unvalidated *Configs to be floating around...
<fwereade> niemeyer, I think I am happy with your latest suggestion
<niemeyer> fwereade: "Floating around" is somewhat unprecise
<niemeyer> fwereade: ValidateConfig does validation, it takes two *Config values
<niemeyer> fwereade: So, necessarily, it is possible for an unvalidated *Config to exist before it is validated
<niemeyer> fwereade: We do validation as soon as possible
<fwereade> niemeyer, but what you suggested yesterday AFAICT indicated that you expected people to get *Configs from the config package, and to make sure they used ValidateConfig from the environs package, before they did anything with that *Config
<niemeyer> fwereade: That's been the plan I'm trying to suggest since I first suggested a proper EnvironConfig type rather than interface
<niemeyer> fwereade: Yes, that's what I'm still suggesting
<niemeyer> fwereade: I also said we should verify as soon as possible
<niemeyer> fwereade: Using that same mechanism
<fwereade> niemeyer, huh, OK, I thought that by moving Read into environs we could guarantee that nobody saw a *Config that hadn't passed through Validate
<niemeyer> fwereade: YES!
<niemeyer> fwereade: Those two things do not conflict!
<niemeyer> :-)
<niemeyer> fwereade: "As soon as possible" may involve Read, and whatever
<fwereade> niemeyer, ...but *without* Read in environs, we surely make it a lot easier to forget to validate?
<fwereade> niemeyer, hence my discomfort
<fwereade> niemeyer, anyway, thank you for bearing with me
<niemeyer> fwereade: Sure, it was my mistake to suggest that in environs/config in the paste.. I clearly didn't think through
<niemeyer> fwereade: This has always been my feeling, though, and I think you'll agree with me if you read back
<fwereade> niemeyer, yeah, it was the code I was disagreeing with
<fwereade> niemeyer, I had a strong feeling of us somehow being in violent agreement
<niemeyer> fwereade: Phew, glad to hear it :)
<fwereade> niemeyer, I think I conceded the validate-at-the-gate point yesterday, and it seemed to me that reading via environs was the only way to do it
<niemeyer> fwereade: Well, I hope we do understand each other
<niemeyer> fwereade: Because I'm still suggesting an EnvironConfig in the form that is in the paste
<niemeyer> fwereade: and the use of environs/config for having it, so that we can use in State et al
<niemeyer> fwereade: Reading it, and validating it, can be done within environs, though
<niemeyer> fwereade: Is that what you understood from the agreemnet as well?
<fwereade> niemeyer, the only tweak I would favour is to put the common fields in as fields and keep the provider-specific types in a map, but even that is not worth the time we'd spend debating (unless you immediately think it's a good idea ;))
<fwereade> gahh not provider-specific *types*
<fwereade> provider-specific attributes/settings/whatever-we-call-them
<niemeyer> fwereade: I don't think it's a good idea only because state needs the full map
<fwereade> niemeyer, we're copying the map anyway
<fwereade> niemeyer, but I concede :)
<niemeyer> fwereade: Well, I don't understand the suggestion then.. you suggested having only provider-specific types in the map, I said state needs the full map, you say ... ?
<niemeyer> fwereade: I'd be happy with having an additional method, like CustomMap(), that excludes the well known fields
<niemeyer> fwereade: I don't know if that's what you're suggesting?
<fwereade> niemeyer, I say "we'll be implementing Map such that it copies, anyway, and the 5 lines of code to explicitly poke in the common field values is not going to be a ig deal"
<niemeyer> fwereade: It sounds like too much trouble for little reason..
<fwereade> niemeyer, like I said I don;t think the benefits outweigh the costs of talking about it
<fwereade> ;)
<niemeyer> fwereade: c.m.Get("default-series").(string) vs. 1) Do the same once; 2) Augment the struct; 3) Reinject the fields
<niemeyer> fwereade: Sure, sorry..
<niemeyer> fwereade: Something like Extras() seems like a good idea, though
<niemeyer> fwereade: Returning a map of unknown fields
<fwereade> niemeyer, oh, wait, one more thought... Secrets are an env-specific subset of Extras
<niemeyer> fwereade: Yeah
<fwereade> niemeyer, meh, we'll figure something out
<fwereade> niemeyer, it's certainly not enough to invalidate your suggestion
<niemeyer> fwereade: I think provider.ConfigSecrets(config) => <somethign> could do it
<fwereade> niemeyer, we also want to be able to strip them out, but nowhere we want to do that won;t have a real Environ anyway
<fwereade> niemeyer, there are certainly no architectural issues with it
 * fwereade is happy
<fwereade> niemeyer, thanks again for spending your weekend on this ;)
<niemeyer> fwereade: No problem, and sorry for being unable to articulate the idea in a clearer way before
<fwereade> niemeyer, it takes 2 to have a communication problem ;)
<niemeyer> fwereade: Thanks :-)
<niemeyer> fwereade: Heading out for lunch.. have a nice weekend in case we don't speak today again
#juju-dev 2013-07-01
<thumper> davecheney: is there a way to use a standard lib function to expand "~/foo" to "/home/tim/foo" if $HOME is /home/tim ?
<thumper> davecheney: or is it expected that we do that manually?
<davecheney> thumper: sorry I missed your question before
<davecheney> i am checking on ~
<davecheney> the answer might be 'it's a shell thing'
<davecheney> but there might be an expand function
<thumper> I didn't find one
<thumper> so wrote one in utils
<davecheney> SGTM
<davecheney> i think that is the correct answer
 * thumper is also importing gocheck as gc
<davecheney> +1
 * davecheney is trying saucy
<davecheney> hmm, no xmir when running under vmware ...
<davecheney> thumper: wallyworld https://codereview.appspot.com/10818043
<davecheney> ^ trivial
 * wallyworld looks
<wallyworld> davecheney: jeez, that was a hard one
<davecheney> thats what she said
 * thumper tries to work out why the test is panicing
<thumper> ah...
<thumper> fark
 * thumper sighs...
<thumper> panic gone
<thumper> now just an error
<thumper> wallyworld: wow, tweaking the local provider config tests took *much* longer than expected
<wallyworld> usually does
<thumper> wallyworld: update coming through
<wallyworld> cool. i'm trying to debug a bootstrap issue :-(
<davecheney> crap
<davecheney> lucky(~) % juju bootstrap -v
<davecheney> 2013-07-01 02:38:11 INFO juju ec2.go:144 environs/ec2: opening environment "ap-southeast-2"
<davecheney> 2013-07-01 02:38:11 INFO juju ec2.go:254 environs/ec2: bootstrapping environment "ap-southeast-2"
<davecheney> 2013-07-01 02:38:18 INFO juju tools.go:25 environs: reading tools with major version 1
<davecheney> 2013-07-01 02:38:19 INFO juju tools.go:29 environs: falling back to public bucket
<davecheney> 2013-07-01 02:38:20 ERROR juju supercommand.go:234 command failed: use of closed network connection
<davecheney> error: use of closed network connection
<wallyworld> thumper: could you do me a favour when you have time? could you pull lp:~wallyworld/juju-core/container-constraint and run the tests in ./constraints? They pass locally for me but the bot complains about TestRoundtripYaml and i'm stuffed if i know why
<thumper> kk
<thumper> davecheney: I've not had ap-southeast-2 actually work for me
<thumper> davecheney: it would start instances but then say "nope, no instances for you"
<davecheney> us-east-1 fails with the same error
<davecheney> why doesn't the error say what failed
<davecheney> i'm guessing it fell off the end of the cloud image list
<thumper> ugh
<thumper> wallyworld: running the tests now
<wallyworld> thanks
<wallyworld> thumper: how'd you go running the container tests?
<wallyworld> /scontainer/constraints
<thumper>  fail in ConstraintsSuite.TestRoundtripYaml
<thumper>     c.Assert(cons, DeepEquals, t)
<thumper> ... obtained constraints.Value = constraints.Value{Arch:(*string)(0xf8400ccab0), Container:(*instance.ContainerType)(nil), CpuCores:(*uint64)(nil), CpuPower:(*uint64)(nil), Mem:(*uint64)(nil)} ("arch=i386")
<thumper> ... expected constraints.Value = constraints.Value{Arch:(*string)(0xf840056380), Container:(*instance.ContainerType)(0xf840056370), CpuCores:(*uint64)(0xf84006c158), CpuPower:(*uint64)(0xf84006c160), Mem:(*uint64)(0xf84006c168)} ("arch=i386 container=lxc cpu-cores=4096 cpu-power=9001 mem=18000000000M")
<wallyworld> sigh. that's what the bot says but they pass for me
<thumper> hmm... that's weird
<wallyworld> and the code looks fine
 * thumper takes a look
<thumper> wallyworld: yeah man, that looks weird
<thumper> wallyworld: have you told it how to deserialize instance.ContainerType?
<thumper> wallyworld: actually WTF?
<thumper> wallyworld: I see the earlier test for the individual container type
<wallyworld> the deserialisation is done in the SetYAML
<wallyworld> ContainerType is a string, so SetYAML is not required except for the fact that it doesn't handle "" properly
<thumper> wallyworld: ok, found it
<wallyworld> great cause my eyes didn't
<thumper> wallyworld: if you change "Mem:       uint64p(18000000000)," to something smaller, it passes
<thumper> don't ask me why
<wallyworld> that value was always there
<wallyworld> before my changes
<wallyworld> oh well, i'll change to smaller. but i wonder why it works for me
<wallyworld> thumper: what version og go are you ruinning?
<wallyworld> i'm on 1.1
<wallyworld> perhaps it's a 1.1 vs 1.03 thing
<thumper> go --version and go --help don't work
<thumper> ffs
<thumper> 1.0-2
<thumper> 1.0.2-2
<wallyworld> ok, that may explain it
 * thumper nods
<wallyworld> 1.0.x vs 1.1
<wallyworld> thanks for helping with that!
<thumper> but why did the test pass before on the bot?
 * wallyworld tweaks and re-approves to land
 * wallyworld has  no idea
<wallyworld> thumper: actually, there wasn't a setYAML before
<wallyworld> so parseuint64 wasn't called
<thumper> ?!
<wallyworld> maybe the issue is in there
<wallyworld> thumper: could you perhaps print any error in setyaml
<wallyworld> and see what it says
<thumper> where is the setyaml?
<wallyworld> since decoding will abort on the first error
<wallyworld> constraints.go
<wallyworld> parseUint64 is in there also
<thumper> 2013-07-01 03:36:10 ERROR juju.constraints constraints.go:199 must be a non-negative integer
<wallyworld> well there you go. it is in parseUint64
<wallyworld> strconv.Atoi
<thumper> wat?
<thumper> oh, turning a big int into a smaller int
<thumper> and causing the signed  bit to flip
<wallyworld> maybe there is a AtoUi
<wallyworld> i'll look
<thumper> wallyworld: why not use ParseUint64?
<thumper> in strconv
<wallyworld> nope, need to call parseUint directly
<wallyworld> yep
<thumper> ParseUint(s string, base int, bitSize int) (n uint64, err error)
<thumper> right
<wallyworld> will make the fix
<thumper> want me to try that here?
<thumper> as I get the error?
<wallyworld> ok, thanks
 * wallyworld still wonders how it passed before
<thumper> -		if val, err := strconv.Atoi(str); err != nil || val < 0 {
<thumper> +		if val, err := strconv.ParseUint(str, 10, 64); err != nil {
<thumper> that change makes it pass here
<thumper> you may find it was calling ParseUint by default
<wallyworld> if val, err := strconv.ParseInt(str, 10, 64); err != nil || val < 0 {
<wallyworld> is what we'd want if we want to check for -ve ints, no?
<thumper> surely the ParseUint checks for netagives
<wallyworld> ok, parseuint might do that
<wallyworld> i'll look
<wallyworld> yes, you get an invalid syntax error
<wallyworld> not as nice as our error message
<thumper> davecheney: I need to find out the local ip address
<thumper> davecheney: localhost isn't good enough
<davecheney> thumper: of what ?
<thumper> that's the question isn't it
<davecheney> of the bound interfaces
<davecheney> ?
<thumper> yeah...
<thumper> I'm not entirely sure...
<thumper> so I want wlan0 or eth0...
<davecheney> http://golang.org/pkg/net/#InterfaceAddrs
<thumper> but not lxcbr0
<davecheney> start with net.Interfaces
<thumper> or veth*
 * thumper looks
<davecheney> then inspect the Name property
<davecheney> and then call .Addrs() on it
<thumper> kk
<davecheney> i *think* that these were all in 1.0
<davecheney> they did get a spruce up
<davecheney> guess we'll cross that bridge when we get there
<thumper> wallyworld: btw, found a weird constraints bug
<thumper> "arch=i386 container=lxc cpu-cores=4096 cpu-power=9001 mem=18000000000M"
<thumper> wallyworld: it finds the M suffix for mem without removing the digits
<thumper> because it isn't that many megabytes
<davecheney> thumper: possibly mem is alwasy in megabytes
<thumper> davecheney: actually I think you're right
<thumper> davecheney: arse
<thumper> davecheney: the Name() of them all are "ip+net"
<thumper> davecheney: I was hoping to get "eth0" or "wlan0" etc
<thumper> sorry, Network()
<thumper> wallyworld: yay, it merged
<wallyworld> \o/
<wallyworld> thanks thumper for the help
<thumper> wallyworld: np
<thumper> davecheney: I think Interfaces is what I need
<davecheney> kk
 * thumper away for kids activities....
<jam> wallyworld_: /wave
<wallyworld_> hi
<wallyworld_> oh look at the time
<jtv> jam: thanks for your review...  Looking closer at Environ.Instances() and the StateInfo() loop that's duplicated between providers, I am plagued by doubts about what should happen in the case without a state server.
<jtv> If Instances() returns success in that case, then the loop will just keep polling.  But this may be by design ("waiting for bootstrap to finish"), or  it may be an accident ("we always have an instance anyway... except maybe in tests").
<jtv> If Instances() returns ErrNoInstances, then StateInfo() will return ErrNoInstances which may or may not be appropriate.
<jtv> (This is the part people always miss when they say good code needs no comments: computers need to know what to do, humans need to know intent)
<jtv> In the OpenStack/EC2 providers, Instances() returns no error in this particular case, so maybe the interface documentation is just not quite right in leaving this particular hole.
<rvba> jam, mgz: Hi, would you mind updating gwacl in the landing environment?  (It should not break anything, we've just added new methods that are needed for our work on the provider)
<jam> rvba: updating now
<rvba> ta
<jam> rvba: says we are on r146, does that match?
<jam> jtv: the case without a state server is pretty underdefined, given it only happens during bootstrap until the state is up.
<jam> jtv: I would guess we are trying to loop until we see the bootstrap node
<jam> Certainly today if you do "juju bootstrap; juju status" it polls until the state server is up.
<jtv> Ah...  OK, then we'll want to update the spec for Instance().  Thanks.
<wallyworld_> anyone know how to do this in mongo: select * from foo where not exists (select from bar where bar.id = foo.id) and foo.acme = 'fred'
<jam> wallyworld_: it looks like there is a $nin operator: http://docs.mongodb.org/manual/reference/operator/
<jam> though that requires passing the array
<wallyworld_> jam: thanks yeah, just saw that myself
<wallyworld_> it seems that 2 queries are needed :-(
<jam> wallyworld_: well, you have two queries above
<jam> it just happens that one is inlined :)
<wallyworld_> well
<wallyworld_> relational dbs do it all in the db
<wallyworld_> so faster, optimised, etc
<jam> wallyworld_: well, the query planner can do stuff like do the "and foo.acme" before doing the "select from bar".
<jam> sure
<wallyworld_> and the data does not have to be serialised back to the client etc
<wallyworld_> s/data/intermediate records
<jam> wallyworld_: "The second part is impossible. MongoDB does not support joins or any  sort of cross querying between collections in a single query. Querying  from one collection, saving the results and then querying from the  second is your only choice unless you embed the data in the rows  themselves as I mention earlier."
<jam> If you can't query between collections, then you can't do what you were asking without 2 requestts.
<jam> I thought I remembered something about no-cross-joins
<jam> But I also wasn't sure if it is was something that changed wrt mongo version updates.
<jam> wallyworld_: http://stackoverflow.com/questions/12437017/group-based-cross-collection-query-in-mongodb-inc-having-clause
<jam> seems pretty close to what you were trying to do
<jam> it certainly was a 'user_id not in ...'
<wallyworld_> jam: thanks, looking
<jam> wallyworld_: well, it is saying, you can't really do that, you need to model the data differently.
<jam> not exactly what you were hoping for, I'm sure.
<wallyworld_> jam: sad thing is, doing it in 2 queries crosses transaction boundaries also
<wallyworld_> seems like a pretty bad limitation of mongo :-(
<wallyworld_> if you want to avoid contention on document collections, you need to split them up, but then you can't join them again for queries
<jam> wallyworld_: it sound like there is a per-db lock anyway: http://docs.mongodb.org/manual/faq/concurrency/
<jam> multiple-readers 1 writer
<jam> actually similar to SQLite from the sound of it.
<wallyworld_> hmmm. if the locks are per database, i wonder why issues with doc contention were brought up in reviews
<wallyworld_> per database seems crazy in any case
<jam> jcastro: poke
<wallyworld_> jam: also, doing it in two queries is "dumb" also because if the data set is large, you can't possibly expect to be able to efficiently read the entire collection into memory just to create the array for the second query
<wallyworld_> recipe for disaster really
<rvba> Hi there, would someone be free to review this branch: https://codereview.appspot.com/10788043/? (it has already been reviewed and approved â with a few changes â by Jeroen).
<jam> rvba: I'm on-call today, I'll try to give it a look.
<rvba> Thank you jam.
<jam> rvba: you're thread got split between 2 submissions, right?
<rvba> jam: no, it's just that every time I run 'lbox propose', a new MP is created.
<rvba> jam: here is the original MP: https://codereview.appspot.com/10732045/
<jam> rvba: do you happen to use a different email address for your Reitveld account than your LP one? it does generally work correctly for me on 'lbox propose'.
<rvba> jam: my Reitveld account is setup with my .c.c email address, my lp account has 2 email addresses associated to it, one of which is the .c.c email address.
<jam> rvba: so I don't know the Azure model of things. How are you filtering to only include the instances associated with the environment.
<jam> Is that the "ServiceName: container" stuff?
<rvba> jam: yes
<jam> rvba: unrelated to your changes, a general question about Azure. Are you able to run the common tests in environs/jujutest? Or you don't have a local-only Double implementation of the provider to talk against?
<jam> you seem to do more of a 'push these responses into the queue, and test that you parse them out again"
<rvba> jam: I haven't tried to run the common tests.
<jam> rvba: the idea is to do an interface level test, to ensure that all Environ implementations have the same basic API and semantics.
<jam> So far most implement a local-only version, and then also let you run with a "-live" flag to run against an actual remote service
<rvba> jam: yeah, we don't have a Double implementation.  We just "patch" the http dispatcher.
<rvba> jam: it's a bit less clean than having a double, but it's much less work.
<jam> rvba: and you have to rewrite the shared test suite
<jam> though it isn't *that* thorough at this point.
<jam> though you could still probably use it for live testing.
<rvba> jam: yeah, it looks like something we could use, once we have all the methods in place, to test the provider live.
<jam> rvba: The method we used for Openstack was after we got a couple things implemented, hook it up, and then stub out methods we don't support yet
<jam> so you can get a decent "ratcheting" of passing tests.
<rvba> Sounds like a good ideaâ¦ we're still mostly fighting with Azure at this point, but that's something we could do once we have implemented the methods to start a node and bootstrap the env.
<rvba> Thanks for the review jam.
<jam> rvba: the goal is that we can test provider-specific things at that level, and then all other tests can just use DummyProvider and not worry about provider-specific differences.
<rvba> Okay
<jam> rvba: happy to review. It seems mostly about Azure specific bits, which I trust you to know more about than I
<jam> rvba: actually, your patch was the next in the review queue anyway
<jam> rvba: you need to set a commit message on: https://code.launchpad.net/~rvb/juju-core/az-list-instances/+merge/171966
<rvba> Good point, done.
<jam> wallyworld_: if you're still around, your patch didn't pass because the regex failed to match.
<wallyworld_> oh, let me look
 * wallyworld_ sighs, fixing
<jam> wallyworld_: I can't help you too much. "This enourmous string" doesn't match "this enormous regex"
<wallyworld_> jam: yeah i hate that test. i don't need any help. i've had the misfortune of dealing with it before :-)
<mramm> hey hey
<mramm> long week of travel and now I'm back in michigan.
<mramm> weekend of travel I guess
<jtv> Does anyone have time for a refactoring review?  It turned out rather huge, but on the bright side, lots of code disappears!  https://codereview.appspot.com/10830044
<jtv> As soon as this is reviewed, I can go and disappear some more of the stuff.  :)
<jam> jtv: if you're still here LGTM
<jtv> Thanks jam!
<thumper> morning
<mramm> morning
<jtv> Morning thumper
<jtv> Say, want to review some code destruction while I sleep?
<thumper> jtv: you're up late
<jtv> Not very.  I'm in Europe.  :)
<thumper> jtv: rack 'em up
<thumper> mramm: call?
<jtv> Thanks!  Got one vote already: https://codereview.appspot.com/10830044
<jtv> nn :)
<mramm> sure we can chat for a few, I have to leave in 20 min though
<thumper> wallyworld_: hey
<wallyworld_> yello
<thumper> wallyworld_: got some time to talk?
<wallyworld_> sure
<thumper> now?
<wallyworld_> yep
 * thumper starts a hangout
<thumper> wallyworld_: https://plus.google.com/hangouts/_/b4eba4c9a6ff830eafe2a6ab79cd49bc4c8d0579?hl=en
#juju-dev 2013-07-02
<wallyworld_> thumper: https://codereview.appspot.com/10854043
 * wallyworld_ goes to look for food
<wallyworld_> bigjools: you seen this error trying to compile the go-curl stuff? https://pastebin.canonical.com/93649/
<wallyworld_> this is from one of the IS guys trying to deploy juju from source for prodstack
<bigjools> I have no
<bigjools> t
<bigjools> is it a 1.1 vs 1.0 thing?
<wallyworld_> maybe it's a precise/Go version issue
<bigjools> or missing go dev headers
<wallyworld_> could be. precise only has 1.0.2 i think
<bigjools> it should work on 1.0
<bigjools> looks like a missing package to me
<bigjools> I am using 1.0.2 here and it works
<wallyworld_> i asked them to install the deps that were in the go-curl email
<wallyworld_> they had done that
<bigjools> does he have golang-src installed?
<bigjools> that too, yes
<wallyworld_> not sure about golang-src. that surely shouldn't be needed?
<bigjools> it will have .h files needed to compile
<wallyworld_> i guess that's relevant for goc stuff
<bigjools> /usr/share/go/src/cmd/cgo/out.go:typedef __SIZE_TYPE__ GoUintptr;
<bigjools> ed@beast:~/canonical/GO/src/launchpad.net/gwacl$ dpkg -S /usr/share/go/src/cmd/cgo/out.go
<bigjools> golang-src: /usr/share/go/src/cmd/cgo/out.go
<bigjools> it's needed
<wallyworld_> ok, thanks. i'll let him know. we should add that to any doc
<bigjools> yeah
<bigjools> dunno why I have it installed, something will have pulled it in
<wallyworld_> i have it installed cause i built Go 1.1 from source
<bigjools> why are you using 1.1?
<bigjools> I know 1.0 is unsupported, but ...
<bigjools> 1.0 is still default in raring it seems
<davecheney> juju add-machine is very useful, thanks wallyworld_
<wallyworld_> davecheney: no problemo. what are you using it for?
<davecheney> need a precise machine to simular an lp builder
<davecheney> so i can figure out wtf has happened to the release ppas
<bigjools> davecheney: can I help?
<davecheney> bigjools: nah, it's not lp specifically
<davecheney> i suspect becaue the builders are using such an old version of go
<bigjools> maybe I can still help :)
<davecheney> we're getting screwed over with compatability issues
<bigjools> have you tried using pbuilder?
<davecheney> basically the /usr/bin/juju from the ppa can't talk to ec2 and/or our cloud image query thing
<davecheney> but one I build myself, from the same source, can
<bigjools> it creates a build env using package versions from a particular release
<davecheney> yup
<davecheney> which is why I'm making a precise machine to try to emulate it
<bigjools> ugh, pbuilder didn't recreate your problem?
<davecheney> can't be fucked with that
<davecheney> this is what vm's are for
<bigjools> pbuilder is much easier mate
<davecheney> juju is easier
<davecheney> :)
<bigjools> :)
<davecheney> where is the tm symbol on my keyboard
<bigjools> well pbuilder is the closest thing you'll get to what the builders do
<bigjools> â¢
 * bigjools offers a copy/paste token
<bigjools> Juju is fucking awesomeâ¢
<davecheney> keep repeating it
<davecheney> soon it'll be 2nd nature
<bigjools> I need a slogan for maas
<davecheney> for the maas's not the class's
<davecheney> er
<davecheney> masses not the classes
<bigjools> not bad
<wallyworld_> thumper: all those comments about machine 0 etc - all that stuff existing previously in the tests - i just moved it around and extracted some common logic
<wallyworld_> i'm wondering whether we want to do a clean up at the end of this work rather than fixing a bunch of existing stuff that isn't too badly out of date now
<thumper> wallyworld_: I'd be up for a separate branch
<thumper> it was more of an observation
<thumper> and we should work to make tests easier
<wallyworld_> agreed
<wallyworld_> i'm writing tests for having assignnew honour container constraints
<wallyworld_> so when that's done, we can deploy into a new container without needing add-machine first
<thumper> cool
<thumper> ugh
<wallyworld_> thumper: https://pastebin.canonical.com/93667/ https://codereview.appspot.com/10858043
<davecheney> anyone tried to compile juju on precise recently ?
<davecheney> http://paste.ubuntu.com/5835154/
<bigjools> see my convo with wallyworld_ from earlier
<davecheney> le shit
<bigjools> install golang-src, basically
<davecheney> ubuntu@ip-10-248-67-205:~/src/github.com/andelf/go-curl$ dpkg -l | grep golang
<davecheney> ii  golang-go                        2:1-5                        Go programming language compiler
<davecheney> ii  golang-src                       2:1-5                        Go programming language compiler - source files
<bigjools> huh
<bigjools> ummmm
<bigjools> so GoUintptr is declared in the files that package installs
<davecheney> #include "_cgo_export.h"
<davecheney> ^ this is a bit suspect
<davecheney> how did this manage to build on the lp builders
<davecheney> ?
<bigjools> does it build ok on raring?
<davecheney> will check
<davecheney> it builds ok on my R machine
<davecheney> but I need to check
<davecheney> please hold
<bigjools> it builds for me locally
<davecheney> same
<bigjools> on raring
<bigjools> but that means nothing in the world of building packages
<davecheney> http://www.keepcalm-o-matic.co.uk/p/keep-calm-it-works-on-my-machine/.
<davecheney> http://www.keepcalm-o-matic.co.uk/p/keep-calm-it-works-on-my-machine/
<davecheney> bigjools: it builds fine on raring
<bigjools> fun
<bigjools> any idea what difference would cause this?
<bigjools> and feel free to file a bug on bugs.launchpad.net/gwacl
<davecheney> raring has a different version of go and libcurl3
<davecheney> ^ first guess
<bigjools> it's not going to help now, but here's another reason to push an SRU
<davecheney> lucky(~) % juju scp -e ap-southeast-1 1 bin/juju .
<davecheney> cp: cannot stat â1â: No such file or directory
<davecheney> error: exit status 1
<davecheney> ^ did I derp, or is this a bug ?
<davecheney> bigjools: confirmed, go-curl/gwacl works on go 1.0.2
<davecheney> i am checking if it can compile for 1.0.1 or earlier
<bigjools> what does precise have?  I can't tell from the package versioning
<davecheney> it's called go1
<davecheney> not really sure what it is under the hood
<bigjools> not sure how the distro guys can keep an unsupported release in an LTS
<davecheney> bigjools: there is a big disconnect going on there
<davecheney> bigjools: https://launchpad.net/juju-project << can you add https://launchpad.net/gwacl to this list ?
<bigjools> sure
<davecheney> ta muchly
<davecheney> chasing down which versions of go can't compile go-curl
<davecheney> then I can try to figure out the bug that was fixed between releases
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1196811
<jamespage> davecheney, mgz: any update on next release of juju-core? standing by to help upload to saucy
<davecheney> jamespage: i'll forward u an email with the latst state of play
<jamespage> davecheney, thanks
<davecheney> done
<jtv> fwereade: I did the first part of that refactoring of duplicated provider code that you wanted me to do.  Thumper was going to review it, but I guess it didn't work out.
<jtv> I don't suppose you could provide the second review?  It's here: https://codereview.appspot.com/10830044
<mgz> fwereade: sorted out the laptop issue I take it?
<fwereade> jtv, sure, thanks for doing that, sorry I missed you
<fwereade> mgz, yeah, it all seems happy again
<fwereade> jtv, LGTM, that's awesome -- thank you very much for picking that up
<wallyworld> fwereade: i'm on leave for the rest of the week but would love to land a couple of branches. would you be up for a look? it's deployment constraints stuff
<wallyworld> https://pastebin.canonical.com/93667/
<jam> fwereade: can I get a follow up review of: https://codereview.appspot.com/10809043/ ?
<jam> mgz: if you can look at it as a second +1 that would be great, too
<jam> I'm trying to take over Rogs' branch for now, and then transition to having a machine agent that only talks via api
<fwereade> jam, sure
<fwereade> jam, don't burn too much time on rog's branch -- it's a slight detour from that goal, I think
<fwereade> jam, nice-to-have not must-have
<jam> fwereade: well, it changes the names for some apis, but that might be internal only.
<jtv> fwereade: fantastic â I'll do the rest after.
<mgz> jam: sure
<mgz> codereview is being a right bint today...
<jam> fwereade: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
<jtv> fwereade, you might know this: the ec2 implementation of StateInfo doesn't use DNSName(), but goes straight to the EC2 object's DNSName field.  That saves it a query to the EC2 API... would it be a problem if I made it go through DNSName()?
<fwereade> jtv, that sounds like a problem with ec2.Instance.DNSName() not caching sensibly
<fwereade> jtv, so I think I'm fine with that
<jtv> Thanks.  I think it may be an optimization, because in a way, what StateInfo() does there is a parallel WaitDNSName().
<jtv> In fact, WaitDNSName() is another piece of code that so far appears as if the exact same loop would do for all providers.
<fwereade> jtv, yeah, like much of the environs code :(
<jtv> True.  :)
<mgz> yeah, it's a bad interface
<fwereade> jtv, I hadn't even noticed that one though
<jtv> By the way, do I understand correctly that StateInfo() is there to return *a* state server, not necessarily as many as it can?
<fwereade> jtv, it's currently there to return just one
<jtv> Well some providers don't need to wait for DNSName.  But in those cases, the generalized WaitDNSName loop would still do the right thing.
<jtv> OK, thanks!
<fwereade> jtv, but we don't want to restrict it to that
<jtv> I tried generalizing *all* StateInfo implementations, but the dummy one deadlocks.
<fwereade> jtv, gaah, blasted dummy provider... I guess it wasn't clear why?
<jtv> Instead, I'm going with the approach of "utility re-usable implementation."
<fwereade> jtv, sgtm
<fwereade> jtv, in general, when you come across things like WaitDNSName, I'd really appreciate bugs tagged tech-debt
<fwereade> jtv, trying to enumerate them all in one go is clearly a non-starter
<fwereade> jtv, but being able to look at them will be useful
<jtv> I didn't go too deeply into it, but my impression was that the dummy provider deadlocked on its two locks somehow, one of which might be needed only for bootstrapping or something.
<jtv> Double-locking is nasty.
<jtv> On first invocation, I think StateInfo will return only those state servers that have been defined *before* StateInfo was called (it doesn't discover newer additions) and that are among the first to have their DNS names.
<fwereade> jtv,+1
<jtv> Thanks!  I'll get right to it.  After this, the most complicated StateInfo implementation  among the providers should be the dummy one.  :)
<fwereade> jam, comment for consideration in upgrader,let me know yourthoughts please
<mgz> hm, unhappy bot
<mgz> something caused both openstack and ec2 tetsts to timeout after 10mins
<mgz> which is odd, as I merged into trunk and ran the suite locally before submitting
<fwereade> jtv,ping
<mgz> fwereade: past his eod really, you may be best off emailing
<jtv> fwereade: yes?
<fwereade> jtv, I asked in the review -- could you make the dns name different from the instance id? or have I misunderstood what's going on in that test?
<fwereade> jtv, but don't worry about it today unless you want to :)
<jtv> fwereade: I'll just have a look at what you wrote there then, thanks.
<jtv> But I think you're right.
<jtv> Say... what time unit does utils.AttemptStrategy use?  It seems weird that tests use 0.25e9 and 0.01e9 â why not something much smaller?
<jtv> I believe 0.01e9 equals 10,000,000.
<jtv> Probably nanoseconds, but even then... why not 1?
<jtv> And why floating-point notation?
<mgz> if tim pops in, tell him I'm just finishing cooking
<thumper> morning
<mgz> hey thumper
<thumper> hi mgz
<fwereade> thumper, heyhey
<thumper> hi fwereade
<thumper> fwereade: I'm consolidating the bootstrap functions found in environs/*/state.go
<thumper> into one place
<thumper> as I wasn't going to copy and paste yet again
<fwereade> thumper, <3
<thumper> heh: current error: "file \"provider-state\" not found not found"
 * thumper fixes too
<fwereade> thumper, ah, balls, I had a branch that fixed a bunch of those, and I could see the bits rotting one by one while I was distracted :/
<thumper> heh
<thumper> this one was in localstorage/storage.go
<wallyworld> mramm: hi, another issue that we need to communicate on (besides the packaging thing) - i saw a conversation in #juju where it was thought the reason for deprecating default-image-id was to make it easier for the developers
<mramm> wallyworld: haha
<wallyworld> haha indeed! it's easier for s to keep that setting
<mramm> we need to finish up the sync tools story
<mramm> so that none of that seems complicated anymore
<wallyworld> yeah. and explain the rationale for various design decisions
<mramm> yep
<mramm> sounds like a good blog post
<wallyworld> you are an ideas man
<mramm> for the one blog post a month thing ;)
<wallyworld> i'm going to blog about the simplestreams stuff when it is done
<wallyworld> but there's more to do yet
<mramm> cool
 * thumper feels a tread being pulled
 * thumper feels like screaming a little
<thumper> copy and paste FTL
<thumper> oh ffs
<thumper> that is 2-3 hours down the drain
<thumper> someone else has already landed this code
<davecheney> arosales: sorry, i'm late for the clal
<davecheney> i thought it was at 10 for unknown reasons
<davecheney> i'll get my headset now
<arosales> davecheney, no worries in the hangout when you are ready
<davecheney> ok, i'm in the hangout now
<davecheney> arosales: ok, i'm in the hangout now
 * thumper afk to collect sick child
#juju-dev 2013-07-03
<thumper> oh ffs
<thumper> lbox choked on this: https://code.launchpad.net/~thumper/juju-core/consolidate-bootstrap-state/+merge/172701
<thumper> bigjools: you like go, care to review?
<bigjools> thumper: I LOVE go
<bigjools> thumper: but I might have to pass, I'm not really working today
<thumper> bigjools: oh?
<thumper> :(
<thumper> neither is wallyworld
<bigjools> it's easier to ask for forgiveness than to block ;)
<thumper> bigjools: ha, not blocked
<thumper> davecheney: what does it mean for a struct to embed an interface?
<davecheney> thumper: type S struct { io.Reader }
<davecheney> ^
<thumper> yeah, or similar
<thumper> in this particular instance it is environs.Environ
<davecheney> it's a shorthand for having to type out all the methods in the io.Reader interface
<thumper> and it only defines some methods
<thumper> what about the methods it doesn't define?
<thumper> you don't normally type out methods inside a struct
<thumper> I know about embedding an interface in an interface
<davecheney> that is correct
<thumper> but this is different
<davecheney> yeah, interface inside interface really just is short hand
<davecheney> so, by embedding an io.Reader inside S this method is automatically crated
<davecheney> type (s *S) Read(...) { return s.Reader.Read(...) }
<davecheney> there actually is not forwarding method
<davecheney> but the world behaves as it is is
<thumper> ...
<thumper> oh
<thumper> so we can implement an interface
<thumper> without implementing all the interface
<thumper> I get it now
<bigjools> what happens when an unimplemented method is called?
<davecheney> well ... yues
<davecheney> S.Reader is nil
<bigjools> so, boom?
<davecheney> so S.Read will blow up unless something has been assigned to S.Reader
<bigjools> isn't this dangerous?
<davecheney> i'm not really sure what you're trying to do
<davecheney> thumper
<thumper> davecheney: it isn't me, it is me understanding our existing code
<davecheney> ok
<thumper> we have a test that is testing bootstrap and has a fake environment
<thumper> it only implements the functions it cares about
<thumper> and passes the test structure through as an environs.Environ
<thumper> seems to work
<davecheney> yup
<bigjools> davecheney: any luck working out go-curl with Go1?
<davecheney> bigjools: we need at least version 1.0.2 to make it work
 * davecheney finds issue
<davecheney> bigjools: https://bugs.launchpad.net/gwacl/+bug/1196811
<bigjools> k
<thumper> omg...
<thumper> we are going to have some work cut out with HA state
<thumper> there is a lot of code that assumes one and only one state server
 * thumper passes that problem on to a future self
<thumper> davecheney: what's the practicle difference between path.Join and filepath.Join?
<thumper> practical
<thumper> grrr
<thumper> freaking import loops
<davecheney> thumper: path is an ideal path, filepath is OS specific
<thumper> davecheney: so which should we be using? filepath?
<davecheney> if it is a filesystem path, filepath
<davecheney> if it is an ideal path, a url, use path
<jam> thumper: I'm looking at your branch, btw.
<thumper> jam: oh, ok
<thumper> jam: there are two
<jam> thumper: pratical matters, 'filepath' will create '\' in names on Windows, "path" never will
<jam> I would point you towards using 'path' as a default unless there are strong reasons not to.
<jam> I had to audit a bunch of places recently to get a client on win32 to work
<jam> thumper: so while I agree with dfc's comment, I would add to it "if in doubt, use path"
<jam> as those generally still work on all platforms.
<jam> The only things I've found that need '\' are: dir (because it uses / to indicate argument flags), and the actual executable that you are spawning
<jam> thumper: for https://code.launchpad.net/~thumper/juju-core/consolidate-bootstrap-state/+merge/172701
<jam> I'm a little unsure about having a LoadProviderState function that returns a list of instances
<jam> 'state' sounds like an object to me
<thumper> jam: sorry, afk now and not wanting to think too deeply.  We could change it to be LoadProviderInstances
<thumper> it never was a "state" type thing
<thumper> just one instance id
<thumper> and later more than one
<jam> mgz_: I did try manually merging and just running the ec2 tests on go-bot, and it failed for me.
<jam> I'm running them now to make sure it runs fine without your patch.
<jam> My guess is that the patch introduces a bad setup/teardown which causes a test to hang
<jam> and thus gets killed after 5min
<jam> With -gocheck.v I see this: http://paste.ubuntu.com/5839627/
<jam> without the merge, I see this: http://paste.ubuntu.com/5839628/
<jam> So I'm pretty sure BootstrapMultiple is the culprit
<jam> except running just "go test -gocheck.v -gocheck.vv -gocheck.f BootstrapMultiple" passes the test.
<jam> makes me wonder if there is a timing related issue
<jam> one test not cleaning up in time for the other test to have a clean slate.
<jam> hmmm... picked the wrong test.
<jam> I saw the one that was skipped, but we have 2 skipped.
<jam> I need the one after BootstrapWithDefaultSeries
<jam> jtv: poke
<jam> not sure if you are still around
<jtv> Hi jam
<jam> I'd like to see one more test for https://codereview.appspot.com/10905043/, but I can help you add if if you need.
<jtv> About to go into my standup!
<jam> specifically, lets test this against all environs, so we all do the same thing.
<jam> mgz_: so the full run without your patch is: http://paste.ubuntu.com/5839699/
<jam> that would mean TestDestroy is what is failing.
<jam> running it by itself with -gocheck.vv passes, though with: http://paste.ubuntu.com/5839700/
<jam> jtv: when you're back, I think I've reviewed all your branches.
<jam> (my personal queue has emptied)
<jtv> jam: just out of the call & looking at your review.  Thanks for running the tests as well; it's been taking me ages to get a cloud instance set up for that.
<jtv> (My working machine is an i386 installation, so can't run all of the tests)
<jtv> fwereade: is https://codereview.appspot.com/10869043/ to your satisfaction with the explanation & added comment?
<jam> jtv: I didn't actually run the tests for your patches. I'm going over a failing submission from mgz.
<jam> jtv: but I certainly can on request :)
<jtv> oh
<jtv> Well, I'm trying to run tests.  :)
<jam> mgz_: mgz_: http://paste.ubuntu.com/5839754/ is the test suite with danilos' patch. It almost looks like CheckEnvironmentsOnConnect is running too fast. So it is starting up and stopping and then another thread gets stuck waiting for stuff to come up.
<jam> jtv: and the bot will run all the tests when it goes to land
<jtv> jam: I wonder if the review changes to my branch could be handled in a separate branchâ¦ I've already started on a new branch and with colocation this sort of thing is very awkward.  I think it's been costing us a lot.
<jtv> oh nm, my current code can wait.
<jam> jtv: do you use a lightweight checkout or cobzr?
<jam> bzr commit/bzr shelve; bzr switch works pretty well for me.
<jtv> Yes.
<jam> jtv: as for the original question, yes you could do it in a followup.
<jtv> Thanks.
<jtv> jam: I did wonder why 10ns is too short  a timeout â why wait at all?  Really the only reason I didn't set zero was that that number might have a special meaning.
<jam> fwereade: just a mechanical rename change: https://codereview.appspot.com/10906043/
<jam> jtv: if you are dealing with goroutines
<jam> you might need a sleep
<jam> because they are not preemptive
<jam> and if the timeout is too short, it will just return "false" immediately
<jtv> I was told even time.Sleep(0) would yield.
<jam> and never give the other goroutine a slice to do its init/etc.
<jam> jtv: I looked at AttemptStrategy
<jam> it always retruns 1 time without sleeping
<jam> and then if now + delay < end it won't ever sleep
<jam> jtv: http://paste.ubuntu.com/5839772/
<jam> if I havent set end yet, just return true
<jam> once it is set
<jam> if now + delay > end return false
<jam> no sleep
<fwereade> jam, a suggestion -- NotifyWatcher is an interface, EntityWatcher is an implementation of that interface? don't actually need to export entityWatcher
<jam> so we could set Total up
<jam> and Delay to 9
<jam> sorry, to 0
<jtv> So this makes our tests invisibly timing-dependent?  Bummer.
<jam> jtv: well, the current codebase is far more timing dependent than I would like
 * jtv sad
<jam> fwereade: that would be possible, but does it benefit us to call the public interface something else in its private implementation ?
<jam> fwereade: seems more like a case of "so what watchers do I have, oh this entity thing..."
<fwereade> jam, I think so, because eg CleanupWatcher has Changes() <-chan struct{}
<jam> fwereade: so I guess it depends on what your thoughts on why some things should be a NotifyWatcher (significant detail is that it has a Changes that returns no content), and entityWatcher whose significant detail is that it watches a document.
<fwereade> jam, it might be a dumb idea -- but ISTM that the document watching is very much an implementation detail
<fwereade> jam, we could go either way, I think, either have N types for N different watchers -- MachineWatcher, UnitWatcher, ServiceWatcher, blah, blah
<fwereade> jam, or just categorize them all by what sort of data they send and save a load of boilerplate at the API level
<fwereade> jam, the middle ground where we categorize by implementation seems a bit off though
<jam> fwereade: if they don't have a functional difference, I'd like to go with the NotifyWatcher at API level.
<fwereade> jam, yeah, that's what I'm thinking
<fwereade> jam, but it may as well be what we expose in state as well
<jtv> jam: thanks for explaining the timing issue by the way.  The code I based this on just set the timings to 0.01e9 and 0.25e9, without documentation â with this knowledge looked more like a deliberate trap than proper software engineering.
<jam> jtv: there was a discussion about what was 'right', I think we want to go with 10*time.Millisecond rather than 0.01e9
<jam> we've used it in most of the other places
<jam> though the discussion at the time was "I perfectly understand that the field is in Nanoseconds and find the shorter scientific notation more readable"
<jam> jtv: I don't know if it was clear, you don't have to fix DummyProvider in your patch
<jam> I was just offering ways in which it might have been hanging.
<jtv> Ah yes, the if-normal-people-can-read-this-I-won't-be-elite argument...  :/
<jtv> I hadn't gotten to that point yet â still documenting the timing issue.  :)
<jtv> Because really, I don't care a hoot what the timing should be, just that it be clear _why_ it is what it is.
<jtv> Exactly so that this conversation (or worse, ill-advised code change) doesn't have to happen again.  :-)
<jam> jtv: yeah, I personally find the attempt strategy's logic a bit odd. So that the actual time you sleep isn't >= Total, but instead >= Total-Delay
<jtv> These things do get hairy if you want to get them right... sometimes the accounting gets a bit weird if you also want it to include the time spent doing the accounting itself and such.
<jtv> But I'm merrily staying out of that for now, just documenting what the crucial factors are that should urgently have been documented originally.
<jam> jtv: yeah, and is the statement meaning "I want to wait no more than X" or "I want to wait at least X"
<jtv> Good one.
<jam> fwereade: also, you didn't LGTM the upgrader-api branch
<jam> I think I responded to your requests
<jtv> Most of these things most readers won't need or want to care about â the arrogance of assuming that the reader will want to spend their time grokking the author's life work and deep thoughts is just stunning.  Writing "0.01e9" for "integer numer of nanoseconds" is only clear to the author, or someone who went to all that trouble.
<jam> fwereade: there is also some confusion as bits of the API code just copy & pasted the state code, which isn't quite what we want. I think there having an interface for NotifyWatcher might make it clearer that API probably wants to share the interface, but not the implementation.
<fwereade> jam, yeah, I'm just doing a last pass on the upgrader now
<fwereade> jam, and, yeah, if API code is copy-pasting state code someone's doing it wrong
<fwereade> jam, which bits in particular?
<jam> fwereade: state/api/watcher.go
<jam> looks very cut & pasted
<jam> with newEntityWatcher et al
<fwereade> jam, yeah, I agree that should be using the interface
<fwereade> jam, but it's not quite cut and pasted, it's more a translation layer
<fwereade> jam, which inevitably bears some resemblance, it is true
<jam> fwereade: well, I think it started out as a C&P and then was a bit adapted. However, I think a lot of the internals aren't actually relevant.
<jam> fwereade: note that there are no *callers* of newEntityWatcher in API
<jam> which is how I know it is a C&P
<fwereade> jam, I think it was more not-actually-deleted than C+P
<fwereade> jam, however it does rather imply that nobody got around to finishing the tests for stuff like the machiner api
<fwereade> jam, which would/should be using that code for the machine watch
<fwereade> jam, well, never got round to actually finishing the client side of the api, actually
<fwereade> jam, nothing to do with the tests
<jam> fwereade: much of the client side is definitely unimplemented :)
<jam> or :'( depending on your POV
<fwereade> jam, heh
<fwereade> jam, so anyway AFAIK in that file entityWatcher is good, lifecycleWatcher is crack (but easily fixable) and environConfigWatcher should never have been implemented
<fwereade> jam, (LW drops events -- we could fix it either by coalescing (hard work) or flip-flopping between reads from in and writes to out (easier, probably smarter too))
<jam> fwereade: how does it drop changes?
<jam> because it switching what "out" to use?
<jam> it looks like it is coallescing
<jam> or is it that it just ends up with "Latest"
<jam> even if it got a set/unset/set ?
<fwereade> jam, LW reads from in and overwrites changes
<fwereade> jam, if it hasn't already been sent on to out
<fwereade> jam, switching outs is great
<jam> fwereade: "ids, err = w.merge(ids, ch);"
<jam> fwereade: isn't that merging rather than overriding?
<fwereade> jam, state/api/watcher.go?
<jam> fwereade: ah, state/watcher.go
<fwereade> jam, AFAIK state.LifecycleWatcher is ok (although I do need to land those branches)
<jamespage> jam, fwereade: hey guys
<jam> hi jam
<jam> jamespage: ^^ :)
<jamespage> lol
<fwereade> jamespage, heyhey
<jamespage> so  - golang versions
<jamespage> right now we have version 1 in 12.04
<jamespage> 1.0.2 quantal->raring
<jamespage> and 1.1.1 sometime in saucy
<jam> jamespage: sure. and we *really* want something >= 1.0.2 in P
<jam> but even the patched 1.0.2 isn't great
<jamespage> so the version 1 in 12.04 is no good anyway you look at it - why?
<fwereade> jam, jamespage: yeah, if we're stuck with 1.0.x we'd really like 1.0.3
<Daviey> jam / fwereade: Can you pinpoint exactly why 1 isn't suitable?
<davecheney> jamespage: the version in P won't build the gwacl (azure) support package that julian is working on
 * davecheney scrobbles for issue
<davecheney> https://bugs.launchpad.net/gwacl/+bug/1196811
<jam> davecheney: and I think your SSL connection problems are also related to the 1.0.2+backported changes.
<jam> jamespage: ISTR that go1 has other problems with HTTP support.
<Daviey> Didn't we have a work around for the go-curl issue?
<jam> I'm 70% sure that it just won't pass the juju-core test suite for even juju-core 1.10
<fwereade> jam, jamespage, davecheney: yeah, in practice we see the tools bucket response hang up if we use 1.0.2, right?
<jam> Daviey: IIRC, the original problem is that go SSL support internally doesn't support renegotiating the connection. Which the workaround was to depend on go-curl
<jam> which has a different cgo related failure
<Daviey> The reason jamespage and myself are exploring this, is that we may have pushback and other complexities bringing back a newer golang.. So we want to be certain it's our best effort.
<davecheney> fwereade: jam i think we had this problem as early as Altanta but didn't have the time to investigate properly
<jam> Daviey: "pushback on newer golang" even for 1.0.3 ?
<Daviey> Well, we might attack that differently TBH
<jam> AFAIK, we could live with 1.0.3 because that is what we are ensuring support for. We would like 1.1+ because go authors have themselves stopped support for the 1.0 branch
<jam> (so there will never be a go 1.0.4)
<fwereade> Daviey, and just to confirm (I guess this is a stupid question) there's no way we can build it for P without tools distributed in P?
<davecheney> jam: and there are bugs in 1.0.3
<davecheney> loooots of ugs
<davecheney> bugs in the http library
<Daviey> 1.0.3 might be fit for a point release SRU to precise, but considering it seems that much iternal stuff is changing.. personally (as an SRU member), i am uncomfortable with that based on what i currently know
<jam> davecheney: fewer than in go 1.0 :)
<Daviey> fwereade: We /can/, but it would piss some people off.
<davecheney> Daviey: i can attest to the commitment of the Go authors to backwards compatibilty
<jam> Daviey: the SRU idea is that we don' want to break people that are using the existing thing, or introduce regression in what is working for them. I *think* 1.0.3 is a sufficiently-better-than-1.0 for parties that are using golang on P
<davecheney> we have a tool which runs as part of every single CI build that valdiates we never depricate or change a symbol that existed at Go 1.0
<fwereade> Daviey, more or less than changing the golang version in P? because being able to use the same golang version across the board would be very handy...
<Daviey> davecheney: Well, anyone else using Go in 12.04 has had to work their app based on known issues that we are talkign about now.  The thing that worries me is that we change the known broken behaviour, and it regresses their stuff.
<fwereade> Daviey, and if we piss people off either way I'd prefer to devote our efforts towards the one that works better for us...
<Daviey> unless the workarounds are known to also work with a known good version?
<davecheney> Daviey: that is fair
<jamespage> fwereade, thats some of the challenge: saucy will get 1.1.1 soon-ish making that immediately inconsistent with earlier releases
<davecheney> i do not have reliable stats on the various install paths for Go
<davecheney> many many people were using Gustavo's PPA versions
<davecheney> they have been quite surprised that they disappeared
<Daviey> Which is a good reason PPA's are dangerous to depend upon.  The primary archive we are duty bound to support by promise.
<Daviey> Anyway...
<davecheney> Daviey: certainly, i am in no way arguing the rightness or wrongness of that approach
<davecheney> only offering a data point that main was not the only way people get Go on P
<Daviey> If it takes a few hours to have dual toolchain support in Go, that is better time spent than jamespage and myself fighting with the rest of the distro team to force something in.
<Daviey> Soo. if we can evaluate feasibility of dual support, it gives us more merrit eithetr way
<jam> Daviey: I know you can set GOPATH and compile with more than 1 go binary
<jamespage> support for 1.1.x and 1.0.x
<jamespage> ?
<Daviey> If it's going to be super hard, and lots of time - we have documented reasons why backporting the newer version is Superior
<jam> (I've done it from time to time)
<jam> I'm not sure how you turn that into builtin support for more than one version.
<Daviey> jamespage: Yeah, i am hoping we can build for 1.0 and 1.X concurrently
<jamespage> so client tooling works for 12.04 -> current dev release right
<Daviey> Oh!
<Daviey> then is backporting a newer golang a theoretical problem?
<Daviey> solve a  theoretical problem, rather?
<jam> jamespage: "client tooling works" ?
<jamespage> sorry - that was misleading
<jamespage> so that the juju-core package is either building against lastest 1.0.x golang or latest 1.1.x golang
<jamespage> in the distro backports pocket which is how we are proposing to distribute this officially for precise
<jam> jamespage: today we can build with 1.0.3 and 1.1.1
<jamespage> OK - Daviey: I think the right thing is to get the 1.0.x version consistent across 12.04->13.04
<jamespage> we are only 1 release away from next LTS at which point most people will start to use 14.04 anyway
<Daviey> jamespage: Are you suggesting we pursue an SRU, or the backport track for 1.0.x?
<Daviey> To confirm, everyone thinks we do indeed need a newer golang available in 12.04?
<jam> Daviey: to build Main package with a tool, doesn't that tool need to be an SRU?
<Daviey> jam: it's not main, so that isn't an issue
<davecheney> Daviey: yes, precise is essentially the only release that matters for Juju until we reach the next LTS
<fwereade> Daviey, yes, we do
<Daviey> jam: There is likely going to be some push back on the prospect of backporting a toolchain package.
<jam> fwereade: https://codereview.appspot.com/10906043/ updated to make NotifyWatcher an interface{} which is implemented by entityWatcher.
<Daviey> fwereade / davecheney: Right.. Would you mind outlining the specific reasons why "1" isn't suitabl.. just so jamespage and I have some things we can use to support this
<jam> well, once lbox propose finishes
<davecheney> Daviey: 1 ? you mean the current version in P ?
<Daviey> Yeah
<davecheney> in addition to the problems of http bugs that affects P, Q and R
<davecheney> it also contains bugs that prevents our windows azure support from compiling
<Daviey> davecheney: Do you have commits to hand that fixe these issues?
<davecheney> Daviey: to fix https://bugs.launchpad.net/juju-core/+bug/1196811 ?
<Daviey> (or bugs)
<davecheney> there is no bug for the http issues with juju 1.11.2
 * davecheney creates one
<Daviey> yeah
<jamespage> Daviey, re SRU or backport - probably SRU
<jamespage> and we should probably try to get a MRE for golang at some point in time
<Daviey> davecheney: Do you know how this was fixed in golang >=1.0.2?
<davecheney> i'm sure it's already been discussed, but there is an open issue where the builders do not use packages from backports
<Daviey> davecheney: Yep, that isn't a blocker
<davecheney> Daviey: no, i only reproduced the problem this afternoon
<davecheney> the 1.11.2 breakage is not reproducable using the upstream go  1.0.2 release
<jam> davecheney: btw, have you tried building 1.0.2 from source? One argument I read in the past was that the Ubuntu package of 1.0.2 backports a change that actually broke things.
<davecheney> only our version of 1.0.2 shipped in Q and R
<davecheney> jam: see just above
<jam> davecheney: yeah, you hit enter before me :)
<Daviey> jamespage: Before being confident in processing an SRU, it would probably have to be raised with the TB first - "intent to MRE, with a trial SRU first".. and Some decent assurance we won't screw people using the current version.
<davecheney> Daviey: https://bugs.launchpad.net/juju-core/+bug/1197326
<_mup_> Bug #1197326: environs/ec2: juju 1.11.2 cannot bootstrap when built with go 1.0.2-2 <juju-core:New> <https://launchpad.net/bugs/1197326>
<davecheney> I am looking for older bugs, we've had this problem before but didn't pick the the cause before now
<jam> fwereade: "no idea how this charm". It is part of JujuConnSuite, *way* too much stuff gets added there. :). Though all that code is going to get overhauled anyway as the client-side API is finished up.
<jam> mgz_: are you around yet? https://codereview.appspot.com/10906043/ could use your rubber stamp
<fwereade> jam, ha. yes, JujuConnSuite is a monster (and actively dangerous in some ways... it sets up both client-only and server-only state)
<jam> fwereade: a lot of that Upgrader code existed because I thought I needed a Unit to test, and to have a unit you need a service and a service needs a charm, etc.
<jam> (Upgrader test code)
<jam> fwereade: fwiw, I side-tracked for NotifyWatcher, but I'll be on Upgrader-client-API and Upgrader-Worker as the next things in the pipe.
<jam> fwereade: as a question there. rog made it so that we start the state worker if we query the api and see a job that requires it.
<fwereade> jam, no worries, it's pretty clearly going to be useful imminently, I'm not complaining about it
<jam> However, when we start StateWorker, it just starts jobs immediately.
<jam> Is it supposed to be looking at the list?
<jam> I'm trying to sort out how I switch UpgradeWorker from state to API and whether I'm missing something vs just starting it like it is today
<jam> fwereade: also, what needs to be done to land  your 'remove TxnRevno' patch?
<jam> fwereade: I need to tweak the Upgrader watcher, and I'd like to depend on your change.
<jam> davecheney: what package would you like me to run on go-bot? I don't want to upgrade to 1.1.1 until we know we can get it into P, but we certainly need >go1 (go-bot runs on P)
<davecheney> jam: the only thing I can suggest is whatever ships in the series the bot is running
<fwereade> jam, sorry, phone
<fwereade> jam, I just need to remove certain appendages from certain other parts of myself and maybe get a second LGTM on the prereq -- that will happen today
<fwereade> jam, I think you need to remove Upgrader from the stateWorkers list, not start as a state worker, and start it as a api worker -- but I guess you'reasking for somethingmore?
<fwereade> jam, I think that the list is just about figuring out when we no longer need a state connection
<jam> fwereade: well, roge mentioned something about asking the API for what jobs to run
<jam> fwereade: as for 2 LGTMs... when we are 4 people down, it is really hard to get enough reviews to maintain velocity.
<fwereade> jam, ah, yes, that does make sense -- we should always start an API connection and get jobs from that
<fwereade> jam, and figure out workers from jobs
<jam> fwereade: right, it seems to start the API connectio, get a list of jobs, and then does nothing but start a StateWorker.
<jam> which hard-codes the workers it runs.
<fwereade> jam, but this is just dickery that pushes back starting just one freaking job with an api connection
<fwereade> jam, which is all I have cared about for like th last month
<fwereade> jam, and which somehow has not happened
<fwereade> jam, and which is why we have all these half done workers
<jam> jtv: point of clarification: "make([]foo, 0, 10)" creates a slice with len(0) and cap(10). So you don't have 'nil's on the end.
<jam> fwereade: acked
<fwereade> jam, once we have that tracer bullet landed I thinkit will be much easier to trim away the ther bits
<jam> fwereade: btw, bot tells me you were right about the charm not being there. I had copied it from somewhere else, apparently I wasn't running what I thought I was...
<fwereade> jam, ha, at least JujuConnSuite's a bit less awful than I feared ;p
<jam> fwereade: api client discussion. Should state/api/upgrader/* take objects that are 'state/*' objects, or should they be "state/api/params/*' objects?
<jam> I know we have to use state/api/params on the wire to the apiserver
<jam> but what should the client interface be?
<jam> state/* so that the API code looks like the existing raw state code?
<jam> or state/api/params code so it looks closer to what will actually be sent to the APIServer ?
<fwereade> jam, params please
<jam> fwereade: k
<fwereade> jam, before too long, hopefully, the only thing that knows about state will be the api
<jam> fwereade: so one thing I was thinking about. Shouldn't state/* be the only things that touch the db, and state/apiserver/* be using the state/* apis?
<fwereade> jam, is that not the case today?
<fwereade> jam, it's certainly the intent
<jam> fwereade: well, it wasn't true as I was implementing Pinger, but I'm not sure about the existing code.
<jam> and I'm realizing I was wrong there, so it could have just been me.
<jam> Upgrader does
<jam> and the Machiner code I've looked at does
<fwereade> jam, does touch the DB?
<fwereade> jam, or does hide it? :)
<jam> fwereade: Upgrader and Machine* seem to use state calls, *not* DB calls
<fwereade> jam, good-oh :)
<jam> Pinger as I was writing it was copying presence and using DB calls, but I was slowly working that out.
<fwereade> jam, ah, got you, cheers
<jam> fwereade: also, state/api/upgrader/* presents a single-object interface?
<fwereade> jam, but the existing SetAgentAlives should give you Pingers already, right?
<jam> rather than the multi-way at state/apiserver/upgrader/* ?
<fwereade> jam, I am agnostic there -- if you're rewriting enough of the upgrader worker I'm fine using direct API calls
<jam> fwereade: there is no API for SetAgentAlive
<fwereade> jam, the bigger the worker the more concerned I am that we maintain the appearance/semantics of the state api
<jam> there is pinger_test.go, but it just tests that a disconnect can be noticed, which is true, but not quite reality.
<jam> fwereade: I'd like the api/* code to be reasonably consistent. If we want single-object or multi-object there, now is the time to decide
<jam> I'd personally like to push multi-object as far down as we can.
<jam> But I think api/machine/* is all single-object
<fwereade> jam, if you're arguing consistency I think we have to go single
<fwereade> jam, because we do not want to rewrite all the workers
<fwereade> jam, long-term I would kinda like to move away from that
<jtv> jam: ah thanks â I wasn't aware of the third argument, or had forgotten.
<fwereade> jam, but the current plan is to wrap them in a thin layer to minimise reimplementation burden of the original workers
<jam> jtv: anyway, it is a hint, not a requirement.
<jtv> It does make it a lot easier.  Thanks again.
<jam> fwereade: machiner.SetStatus() takes an args that is an array
<jam> ah stupid, I'm in apiserver
<jam> of course it does
<fwereade> jam, yeah, the idea is just to fix what we send over the wire so it's a bit more flexible but to maintain the interface
<fwereade> jam, on the client side
<fwereade> jam, when it's really no more costly to fix the worker I have no qualms about doing so early
<fwereade> jam, at least the various facades are split up so we can drop the domain object style code one facade at a time
<fwereade> jam, sane?
<jam> fwereade: seems ok to me
<fwereade> jam, hell, cath popped out and is not back yet, and laura's getting a bit screamy, I might have to skip standup today
<jam> k
<jam> jtv: you need to import "time" at the top of polling_test.go
<jtv> Yes I know, thanks
<jam> jtv: sorry if I came across as bugging. I just try to inform people about bot results since they don't seem to poll it themselves.
<jtv> No it's fine, really.  I appreciate it.
<jtv> It's just that I happened to be already on it.  :)
<jtv> jam: if people aren't noticing their landing failures, that may mean they've got too much work in-flight, which in turn might mean that the process needs tweaking.
<jtv> For example, if branches take too long to complete when the "real" work is already done, people  will work around the blockage by taking on additional work.
<fwereade> jam, I think I'm going to land https://codereview.appspot.com/10798043, would you just cast a quick eye over it on general principles please?
<jam> fwereade: Upgrader.Tools currently returns the desired Tools for a given agent. But we don't have an API to get the *actual* current tools for an agent.
<fwereade> jam, do we need that in the API?
<jam> fwereade: I don't know. I know I expected it as part of testing
<fwereade> jam, state has Unit and Machine.AgentTools
<fwereade> jam, I don't think it's necessary tbh -- all your testing of what-actually-happened should probably be against independent state instances regardless, right?
<jam> fwereade: offhand Upgrader.Tools sounds like something that could just return the desired tools. Vs a Machine.Tools that should return the current running tools.
<jam> so we're probably fine.
<jam> It was just a moment of surprise
<fwereade> jam, cool
<jam> fwereade: still LGTM
<jam> fwereade: ran into something interesting. It seems you cannot embed types in api/params
<jam> if you do, they don't get serialized back properly by rpc.jsoncodec
<jam> direct server tests don't notice,because you test the object being returned
<jam> but client-side tests notice
<jam> the data isn't on the wire
<fwereade> jam, aww, wtf
<jam> fwereade: http://paste.ubuntu.com/5840230/
<jam> Without that change to api/params/params.go I was getting Error == null, but no JSON content for the embedded AgentTools fields.
<fwereade> jam, that's really unhelpful :/
<fwereade> jam, ah, apparently it's fixed in 1.1
<fwereade> jam, although that is of limited value to us :/
<jam> fwereade: depends how the conversation goes :)
<jam> fwereade, mgz_: If you have the time this is the changes to get client-side Upgrader up and running: https://codereview.appspot.com/10711044/
<mgz_> looking
<fwereade> jam, cool, just a mo
<jam> mgz: fwereade: I'm off for today, but I'd love to get feedback before I start work tomorrow.
<fwereade> jam, np
<jam> I might even stop by tonight.
<arosales> Is it correct to state the only valid option to add-unit in juju-core  is "-n"
<arosales> "add-unit -c" or "add-unit --count"  to look to be supported
<fwereade> arosales, -n/--num-units are all we implemented it seems -- if we should have --count as well, would you open a bug please?
 * fwereade needs to head out a bit early today, will see you all later
<arosales> fwereade, thanks for the info and will do re: --count
<mgz> if its just an alias, do we actually want that versus just a deprecation in python/unsupported notice in juju-core?
<mgz> potentially there are scripts that use it, but we need some paths for updating the commandline interface
<jam> mgz: did you get a chance to look at upgrader-api-client?
<mgz> jam, yeah, commenting now
<jam> thx
<mgz> jam: lgtmed
<thumper> morning folks
<thumper> small victory
 * thumper chucks some stuff away
<thumper> harder to get it merged than I care about
<thumper> not worth the effort right now
 * thumper feels like he is missing a step somewhere
 * thumper is unblocked
<thumper> I hate, *hate* having to guess why something works...
 * thumper adds some doc
#juju-dev 2013-07-04
<bigjools> g'day thumper
<thumper> hi bigjools
<bigjools> talking to yourself all morning and I felt sorry for you
<thumper> :)
<jtv> fwereade: can I just run another refactoring by you that might slim down the providers a bit more and save us some time?
<fwereade> jtv, sure, but I'm in a meeting at the moment
<jtv> OK, I'll hang on
<fwereade> jtv, so expect slightly slowresponses
<jam> rvba: I think I know why lbox is creating a new Rietveld review when you submit, though I don't know how to fix it. Specifically, lbox edits the description of the merge to include the link to codereview..., Your proposals are getting a new comment, but *not* getting the description edited.
<rvba> jam: that's right, when I run 'lbox propose' it spits out an error ("Failed to update merge proposal").
<fwereade> jtv, I'm here now
<jtv> fwereade: argh, just going into my standup!   Got time in half an hour?
<fwereade> jtv, sure :)
<jtv> Thanks!
<TheMue> jam: as I didn't follow rog with the upgrade stuff, could you pls give a short intro into it to me?
<jam> TheMue: basic summary, bootstrap a 1.10 system, add a couple of units to it. Then try to upgrade it to 1.11
<TheMue> jam: and currently no issue nor card where he noted the problems? ok ...
<jam> TheMue: so I think the test can be : juju bootstrap; juju status; juju deploy mysql; # wait for it to run; juju upgrade-juju --upload-tools
<jam> TheMue: I believe it was pretty ad hoc testing. It came up in a meeting, so he poked at it.
<fwereade> jam, TheMue, you should check 1.10 agents bootstrapped both with 1.10 and with trunk, upgrading to trunk in each case
<jam> fwereade: so juju-1.10 bootstrap && juju-1.10 deploy && juju-trunk upgrade-juju --upload-tools
<jam> as well as juju-trunk for all of those, correct?
<TheMue> fwereade: yep, will do
<jam> rvba: the only thing that comes to mind is when you gave lbox permissions to run as your account, it somehow didn't get the right perms. But that doesn't quite make sense, since it can post for you, I would think that means it can change things for you as well.
<fwereade> jam, yes
<jam> fwereade: thoughts on a name for State.Watch? that watches the same document as WatchEnvironConfig but uses a NotifyWatcher rather than putting the content into Changes()?
<jam> current best guess was "WatchForEnvironConfigChanges" which is quite a bit more verbose than other watcher.s
<fwereade> jam, that doesn't sound too awful -- because I think it'll be becoming plain WatchEnvironConfig once we get rid of the current implementation
<jam> fwereade: should I be pushing to make all current WatchEnvironConfig callers do it? It seemed much larger than trying to get this other bit done.
<jam> fwereade: fwiw, I can't see any direct testing of WatchEnvironConfig seeing changes to the environment.
<fwereade> jam, yes but not today -- parallel implementation gets us where we need quicker
<fwereade> jam, ha
<jam> there is WaitForEnviron stuff in workers
<jam> well, maybe state_test.go.
<fwereade> jam, yeah, that looks like it does roughly the right thing
<jam> fwereade: alternatively, I only really need WatchAPIVersion which could secretly do environ config underneath
<fwereade> jam, sure, that'd be what you expose over the api
<jam> fwereade: right, which means it is what I could expose on State
<jam> and assert in the test suite
<jam> and the implementation would be on the Environ Config doc.
<fwereade> jam, but in state I'd rather name it after what it does today, ie watch everything in the config
<fwereade> jam, we can filter better later behind the api
<fwereade> jam,sane?
<jam> fwereade: do you think we would filter in the API, or filter in the future watcher?
<fwereade> jam, I *suspect* we'll have cause to do smarter filtering directly in state
<fwereade> jam, but I'm agnostic really
<jam> fwereade: from what I've read in the code, the only way to set the agent-version is to rewrite the hole Config dict. Does that match your understanding ?
<fwereade> jam, yeah, afraid so
<jam> (environs/jujutest/livetests.go setAgentVersion is the only place I've seen it)
<fwereade> jam, honestly I don't actually think agent-version fits very well with the rest of environ config anyway,it's been a bit of a dumping ground
<fwereade> jam, but as usual until it's obscured behind the api we're stuck with it
<mgz_> go 1.1.1 for saucy built okay: https://launchpad.net/~james-page/+archive/golang-backports
<jam> fwereade: one of the tests I'm cribbing from (state/unit_test.go TestWatchConfigSettings) has an assert that changing an object 2 times results in only OneChange.
<jam> When I try that on an EntityWatcher, it fails
<jam> should I be asserting that or just not worry about it
<fwereade> jam, that is surprising to me, I think it deserves a little bit of worry
<fwereade> jam, paste me the test you have maybe?
<jam> fwereade: I might have just been doing it wrong. Testing again now looks like it is doing the right thing... :(
<fwereade> jam, ok, cool :)
<jamespage> fwereade, mgz, jam: backport of golang 1.1.1 for 12.04->13.10 - we need to put that somewhere more official for the juju-core PPA builds
<jamespage> https://launchpad.net/~james-page/+archive/golang-backports
<jtv> fwereade: got time for a hangout?
<fwereade> jtv, sure
<fwereade> jtv, would you start one please?
<jtv> Working on it...  whom do I invite?
<jtv> Found you!
<jtv> fwereade: G+ says it looks like you aren't available.  It does that a lot for me.
<jtv> Maybe I invited your wrong account after all.
<fwereade> jtv, https://plus.google.com/hangouts/_/51118536cbb3ae1f18ea3cec8ef8be231497d69b?hl=en
<jtv> Thanks
<jtv> fwereade: buggeration...  once again the dummy provider is the *only* provider that doesn't play along.  I'll have to go with a "utility" Bootstrap.
<jtv> A shame, because there already is an environs.Bootstrap and I can't just move functionality in there.
<jtv> Although...  I guess with the dummy provider I can just see whether the changes will actually break tests.
<fwereade> jtv, I would not object to a type switch that accommodates strange providers that want their own Bootstrap method
<fwereade> jtv, even if doing that *just* for the dummy kinda smells
<jtv> Positively reeks.  :)
<fwereade> well put :)
<fwereade> jtv, curse that dummy provider... it doesn't even properly do bootstrap *anyway* AFAIR
<fwereade> hey ho
<jtv> Well in that case there's hope.
<fwereade> jtv, IIRC it has a bunch of stuff copy-pasted and then diverged from jujud bootstrap-state
 * fwereade wonders if there's something nearby he can set fire to on general principles
<jtv> Good thinking.  Fire helps.  Fire cleanses.
<jam> jamespage: what does "somewhere more official" mean?
<jam> Do you want it under ~juju/+archive/golang or something like that?
<jamespage> something like that yes
<jam> jamespage: Can I just copy the ones you already have?
<mgz_> you can.
<fwereade> jam, hey, tag vs id in the api -- does that phrase cause any immediate response?
<fwereade> jam, some places it seems we use tags, some places ids
<jam> fwereade: tag == Machine.Tag() or Unit.Tag()
<jam> so you can pass one to be for any agent
<jam> Id can only be used for a specific one in context
<jam> fwereade: so I would use Tag unless you have a different reason to
<fwereade> jam, sure -- I guess I'm asking why we use ids anywhere
<jam> though it is "ok" to do stuff like GetMachine(id) because you have the context
<jam> fwereade: hysterical raisons ?
<fwereade> jam, that kinda works against the possibility of common reuse though
<jam> fwereade: so IMO, I would use Tag unless you really needed something else. As tag => id is lossless
<jam> and Id => Tag can only be done with external context.
<fwereade> jam, technically it works both ways actually, but we're not sure it will always do so
<jam> fwereade: from what I've seen of Id it is just an integer in a string
<jam> Is unit Ids different?
<fwereade> jam, or unit name, or service name, or...
<fwereade> jam, machine, service, unit, user
<jam> fwereade, mgz: When you get a chance, feedback on https://codereview.appspot.com/10891044/ will help me get the Worker up and running.
<jam> fwereade: I'll note that today we have: globalKey which gives essentially the same result as Tag() except it is private and only the Presence code seems to use it
<jam> Tag() which gives a unique and segmented identifier, but no code to actuall y invert any given Tag back into its original type
<jam> (something that takes a Tag and gives you a UNit or Machine)
<jam> and Id
<fwereade> jam, globalKey is used in any collection that holds data associated with more than one type of entity
<jam> which is pretty context sensitive, and nobody wants to inspect it.
<jam> fwereade: but why did we reinvent globalKey calling it Tag?
<fwereade> jam, globalKey is (1) internal and (2) a bit more complex -- relation units have globalkeys for the settings and scope collections, which don't correspond to actual entities themselves
<fwereade> jam, tag solves roughly the same problem, but in a human-readable and externally visible context
<jam> fwereade: anyway, all the API stuff *I* wrote uses Tag. I'd like to see more of that in the API because we defined Tag as being namespaced and unique.
<thumper> jtv: please wait
<fwereade> jam, great, +1
<thumper> jtv: with the bootstrap refactoring
<thumper> jtv: as I have some in progress
<thumper> jtv: that I have been using wtih local provider
<fwereade> jam, in that case I think I will be smacking some of the machiner bits around so I can move existing code into common and reuse it
<jam> https://codereview.appspot.com/10891044/ adds the WatchForEnvironConfigChanges and hooks the UpgraderAPI to use it. Which is the last piece the actual Worker should need. Which is the next step I want to finish off.
<fwereade> jam, dropping things like MachineLifeResults when they could just be LifeResults etc
<jam> fwereade: sounds good to me.
<fwereade> jam, great, thanks for the sanity check
<jam> I was fortunate that I knew what I was working on was going to be for both Uniters and Machiners so I had to be agnostic :)
<fwereade> jam, cool
<jam> Though it doesn't, today, support Uniters because of that lack of Tag => agent lookup mechanism.
<fwereade> jam, hmm, I think that does exist somewhere actually... just a mo
<fwereade> jam, state.go:562?
<fwereade> jam, specifically State.Authenticator, a few lines up, which uses it
<fwereade> jam, hey, do we have a meeting now? I thought I saw it on my calendar this am but it seems to bemissing now
<jam> fwereade: thanks, I'll keep that in mind when I enable Uniters in Upgrader. It probably holds all I need for the "are you allowed to do this" check.
<jam> fwereade: I saw mramm mark it as removed.
<fwereade> jam, yeah, should be
<jam> I think he was off
<jam> so he just cancelled it
<fwereade> jam, ah, I thought he was coming in for it
<fwereade> jam, still, my nose still has the same amount of skin
<jam> fwereade: he was coming in for the "early" meetings. Apparently 11:00UTC isn't early enough.
<mgz_> jam: reviewed
<jam> fwereade: I don't see an exposed API in state/api/*/* that actually runs a Watcher. And the one in state/api/watcher.NotifyWatcher requires a State object.
<jam> fwereade: am I missing something?
<jam> I have the feeling the naming in the API is my fault
<fwereade> jam, just a mo,let me look
<jam> and that is the "this was copied out of state/watcher.go" without someone actually thinking it through.
<fwereade> jam, it's a *State, not a *state.State
<fwereade> jam, yay helpful naming
<fwereade> jam, not sure it is your fault though
<jam> fwereade: well I renamed it from EntityWatcher
<fwereade> jam, I think that's a good thing though?
<jam> but probably should have gone the route of making it an interface and leaving it an entity watcher.
<jam> fwereade: well, it directly calls Watch inside of the loop() function
<jam> which means I can't reuse the code for WatchAPIVersion
<jam> fwereade: and also, no code actually calls newNotifyWatcher
<jam> so I'm probably fine changing it :)
<jam> fwereade: my thought was that the client API for Upgrader would be
<fwereade> jam, I think I'm missing something myself, surely we only need one implementation client-side for anything server side with a `Changes() <-chan struct{}`?
<jam> Upgrader.WatchAPIVersion(agentTag string) (state.NotifyWatcher, error)
<jam> though that could certainly be api.NotifyWatcher
<jam> because we don't want to expose "state" things in the API
<fwereade> jam, yeah, I think it's just a NotifyWatchResults or whatever it's called?
<jam> fwereade: well, the API on the wire returns you a NotifyWatcherId which is the handle to the specific watcher running in the API server.
<jam> that comes from NotifyWatchResults
<jam> you then need to turn that into something that calls Changes or Next or whatever.
<jam> and I'd like WatchAPIVersion to do that translation for you.
<fwereade> jam, I think that's what the state/api watcher code does
<fwereade> jam, ah, hmm, that's still very much domain-object-centric, though, isn't it
<jam> fwereade: it *does* but with a caveat, that it also   Call("Machine", "", "Watch", "0") for you before
<jam> at the beginning of loop()
<jam> While what I want is to hand something the NotifyWatcherId I already have.
<fwereade> jam, gaah, I see
<jam> fwereade: which I could just rip out the code as it exists, since nobody actually calls newNotifyWatcher.
<jam> or instantiates an api.NotifyWatcher.
<fwereade> jam, yeah, I'm pretty sure we should be constructing those with watcher ids
<fwereade> jam, or perhaps, for clarity/consistency's sake, with a NotifyWatchResult
<fwereade> jam, because a StringsWatchResult will need the ancillary first-event-contents data, even if there isnone for the notify watcher
<jam> fwereade: sure. Though looking at the code, I don't think it works today.
<jam> ah nm
<fwereade> jam, (btw, domain-object-centricity on watcher bothers me very little, don't go fixing that unless there's a clear reason to)
<jam> I thought it was blocking on something ,but it is blocking in a defer x
<jam> so only on exit.
<fwereade> jam, cool
<jam> fwereade: well domain-object-centricty means I can't reuse it for WatchAPIVersion because you don't call Upgrader.Watch.
<jam> But I don't really see why it needs to happen in loop() anyway, which would mean I could pull that small bit out and into either a different newDomainNotifyWatcher, or something of the sort.
<jam> fwereade: what is the syntax for go channel receives. If you do "_, ok := <-c.Watcher.Changes()" but there is nothing in the channel, won't that still return ok = True?
<jam> sorry, I mean it will return, but with ok= False
<jam> fwereade: I'm trying to use your NotifyWatcherC code for the API stuff, but it is failing because it is getting an ok=false result. And I'm trying to figure out why it shouldn't return at all.
<TheMue> ouch
<TheMue> upgrade from 1.10 to trunk terminates all instances
<jam> TheMue: it is supposed to restart the agents, but it is killing the AMI instances?
<jam> that doesn't sound quite right :)
<TheMue> jam: yes, the instances are terminating :(
<jam> TheMue: could it be "the agents don't seem to be alive, so let me kill the instances" ?
<TheMue> jam: dunno
<TheMue> jam: during trunk to trunk it worked, with upgrading the agents
<jam> TheMue: go question. When does "foo, ok := <-chan" return false for ok, only when chan is closed?
<TheMue> jam: imho yes, passing a blocked but open channel needs a select with a default
<TheMue> jam: will take a look
<TheMue> jam: http://golang.org/ref/spec#Receive_operator => when closed or empty
<TheMue> jam: eh, closed and (!) empty
<jam> TheMue: well closed *and* empty, not closed *or* empty
<TheMue> jam: yes, what I corrected
<jam> TheMue: yeah. The issue is that I'm seeing the channel be closed, but it should still be alive and waiting for more stuff.
<jam> so I'm trying to sort that out.
<fwereade> jam, sorry, was eating
<TheMue> jam: where?
<fwereade> jam, paste me maybe?
<TheMue> jam: foo, ok := <-chan blocks, ok is only false if the chan is closed
<jam> fwereade: currently neck deep in it, and thinking the api.Watcher code wasn't sending the fields in the right location, causing the channel to become immediately killed.
<TheMue> jam: but a select with a default allows to pass the receiving when there's nothing in the channel
<jam> right
<jam> TheMue: thanks. Confirms that the channel really is closed, and I need to dig into why
<fwereade> jam, possibly resource lifetimes somehow? I think the resource registry kills stuff if the connection is closed?
<jam> fwereade: from what I see in the DEBUG from json codec, I'm not seeing the NotifyWatcherId sent across the wire, which means it has no clue what thing I'm trying to watch.
<jam> and thus closes the local side because of the error it go
<jam> got
<fwereade> jam, that sounds like it'd do it :)
<jam> fwereade: the commonLoop code says "if I get NotFound or Stopped from any api call, kill the local session"
<fwereade> jam, kill the watcher, right? that does sound correct
<jam> fwereade: found it. I was passing a parameter that was locally declared, instead of the attribute of the struct. Which meant it was passing "" as the Id, which meant it wasn't getting put on the wire.
<fwereade> jam, heh, bad luck
<jam> :w
<fwereade> bbiab
<jam> fwereade: something to consider. NotifyWatcher("id").Next() is a root level function, and is not bulk. Should we instead have NotifyWatcher().Next(["id1", "id2']) or is that wrong because we want the block forever sort of functionality.
<jam> to be honest, it scares me how many Watchers end up running for a single entity because of the layering.
<jam> A lot of <-in => out <- transitions
<fwereade> jam, yeah, I know what you mean
<fwereade> jam, I am uncertain about bulk ops there -- do we return when all of them have sent? I guess we'd have to, but is that useful?
<fwereade> jam, I'm less worried about lots of channels/goroutines
<fwereade> jam, thousands and thousands of those *ought* to be fine
<jam> fwereade: yeah, the block-on-one means we probably don't want bulk. Though it is the sort of one-round-trip per each thing you are watching. But we sort of *want* those to block.
<fwereade> jam, although... maintaining *state* for all those watchers on the server side *does* bother me
<jam> fwereade: but on another note. I have an api.NewNotifyWatcher() that can take a NotifyWatcherResult and turn it into a NotifyWatcher.
<fwereade> jam, sweet
<jam> fwereade: but the question is. Should you call WatchAPIVersion()=>result; NewNotifyWatcher(result)
<jam> or
<jam> should client.Upgrader().WatchAPIVersion() => NotifyWatcher
<jam> fwereade: I like the later, but run into import cycles.
<jam> because I have to import "api" in api/upgrader
<fwereade> jam, damn,I was just about to say definitely the latter
<jam> fwereade: that is really what I wanted, too
<fwereade> jam, api/watcher package?
<jam> fwereade: I can move the api code into api/watcher?
<jam> yeah
<jam> *sigh*
<fwereade> jam,+1
<jam> how many watcher.go/watcher packages will we end up with ? :)
<jam> maybe as many as we have state
<jam> and testing
<fwereade> jam, it's a lesser evil than the monster packages in which everything is friends with everything else
<fwereade> jam, kinda like python except no strong convention for "don't touch this"
<jam> fwereade: :). The other nice thing is that api.NotifyWatcher conforms to state.NotifyWatcher (they are the same definition), which means state/testing/NotifyWatcherC works even for API watchers.
<fwereade> jam, awesome
<jam> It is a bit odd that it does stuff like state.FullSync() but hey, that just makes sure the api triggers, right?
<fwereade> jam, yeah
<fwereade> jam, ffs, MachineAgentGetMachinesResults?
<fwereade> jam, (not you, just general bitching)
<mgz_> is that an imperative?
<mgz_> should it have OrElse on the end?
<jam> fwereade: it is a bit of a mix because you are going from extreme namespacing of go, and then putting everything into one file for the API so everything gets explict namespacing.
<jam> and the bulk logic means we end up with the struct that is one
<jam> and the struct that traps that one with an error
<jam> and the one that wraps that into an array
<fwereade> jam, yeah, but it's only in one package because hurf durf small packages are bad :/
<jam> fwereade: well, I'm running into troubles pulling out Watcher, because State/ErrCode/CodeStopped are all defined in api
<jam> api.ErrCode
<jam> so you can't use api.* in any subdir
<jam> it seems a bit of a misfeature that you have to have api/params
<jam> rather than api.Param to be used in an api.Foo.Something
<jam> I like not having circular imports
<fwereade> jam, yeah, +1
<jam> but I don't quite understand where the circle is.
<fwereade> jam, it just means that if you have people who think small packages are bad you have to put *everything* in onepackage
<fwereade> jam, and then it's impossible to factor anything out
<jam> fwereade: but why is it that launchpad.net/something/foo can't import launchpad.net/something ?
<fwereade> jam, it can
<mgz_> you may just also have circular import issues?
<fwereade> jam, it's just some type that someone or other thought didn't deserve a package
<fwereade> jam, and now you get to search for it
<fwereade> jam, a thought: should those bits maybe go in params? that's the giant package that's intended to hold things relevant to both sides of the api
<jam> mgz_: well I moved the stuff out, but AllWatcher wants direct access to Client who wants direct access to AllWatcher
<jam> so I had to move that one back
<fwereade> jam, not that that is itself a good solution
<jam> but it turnsout I ended up circular
<jam> fwereade: I moved NotifyWatcher the interface into params
<jam> which I'm hoping is enough. But yeah, ErrCode? Maybe.
<jam> For now, I think I sorted out the circle
<fwereade> jam, cool
<jam> fwereade: though I'll note
<jam> upgrader can't import api
<jam> because api.State.Upgrader() is a function
<jam> so it needs access to return upgrader stuff
<jam> so that is probably the source of most loops
<jam> helper-functions on an api.* object, that need access to api/*/* stuff
<jam> ugh. upgrader can't import watcher because watcher imports api and api imports upgrader because of api.State.Upgrader()
<jam> so I'm back to moving api.ErrCode and api.Code* into api.params.
<mgz_> I also found refactoring inside of api lots of fun :)
 * fwereade is going through similarly rage-inducing crap himself
<jam> fwereade: "Can we rely on resources.StopAll to clean things up?" yes, but I'd like to assert that we can do a clean Stop() in the code, and leave the StopAll to ensure the test suites stay clean.
<jam> is that ok to land then?
<jam> put another way, AssertStop is used to fail the test if we don't get a clean (error free) Stop9)
<jam> StopAll is used to ensure the next test will not fail just because this one did.
<fwereade> jam, yeah, sgtm
<mgz_> so, the ~juju team has dave, kapil and gustavo as admins, one of them needs to create a golang ppa
<jam> mgz_: https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.80lo482fb2s9gkfk4o8r4e70ho if you can make it
<jam> mgz_:  I also think fwereade should be added to admins.
<mgz_> I'm making it over jamespage's shoulder :)
<mgz_> jam: adding fwereade sounds sensible, but also requires an admin... or the owner
<jam> mgz_: I added you to the weekly call, so it should be in your calendar now.
<jam> mgz_: Yeah, we need one of dave niemeyer etc to add fwereade as an Admin of the ~juju group. We just have to find them when they are online.
<niemeyer> I'm here
<niemeyer> fwereade is now an admin
<jam> niemeyer: thanks !
<fwereade> niemeyer, cheers :)
<niemeyer> jam: np
<jam> mgz_: I think fwereade is in that meeting as well, so you can tell him to set up the PPA :)
<mgz_> it's already over :)
<mgz_> fwereade: can you please add a golang ppa to ~juju, thanks!
<fwereade> mgz_, probably, but I lack context, have been focusing elsewhere
<mgz_> fwereade: it involves clicking some buttons on https://code.launchpad.net/~juju
<fwereade> mgz_, does https://launchpad.net/~juju/+archive/golang look like what you need?
<mgz_> thanks!
<mgz_> okay, copied in the binaries and added dep from devel to golang
<mgz_> so, ppa will build on 1.1.1 next time.
<mgz_> so... what makes mgo.DialWithInfo hang, without ever calling the dial function...
<mgz_> answer: giving it a hostname that does not resolve
<mgz_> give it an ip it can't connect to instead (like 0.0.0.0) and it loops trying to connect instead
<fwereade> jam, btw, I'm wondering a bit about AgentTools
<fwereade> jam, what's the advantage of having all those fields vs packing them all into the normal string form?
<fwereade> jam, not saying it's bad, just kinda wondering
<jam> fwereade: because you don't have to then parse the string form to pull out the actual integers you need elsewhere?
<fwereade> jam, parsing a string seems like less hassle than sending all those extra bytes every time but I guess it's debatable
<jam> fwereade: code we have to write vs parsing we get for "free". I agree a simple string could be good. I don't really care. JSON.Unmarshal did the work for me so I don't have to see the bytes on the wire :)
<fwereade> jam, fair enough, I have more important things to worry about than mindlessly tweaking that anyway :)
<jam> mgz, fwereade: If you feel like reviewing: https://codereview.appspot.com/10939043/ is the refactoring of watchers into their own subpackage
<fwereade> jam, I'd love to, the urge to set fire to things is only growing over here
<fwereade> jam, it seems like everything is entwined with everything else but nothing uses anything resembling a common convention
<fwereade> jam,reviewed
<jam> fwereade: the out := w.out thing
<jam> fwereade: the issue is that it actually triggers double out
<jam> Because the watcher on the server side has the initial report to give
<jam> and you are adding one on the local side.
<jam> the original statement was "Watch calls Next" but I have no indication that that was ever true.
<jam> AFAICT there weren't any tests of the original behavior
 * thumper is prepared for another day talking to himself
<ahasenack> thumper: do you usually have a team mate in your timezone?
<thumper> ahasenack: wallyworld is normally working, and only two hours out
<thumper> dave cheney is often around but pretty quiet
<thumper> I really should hire another NZer just for the company
<ahasenack> :)
<wallyworld> thumper: you feeling lonely? awww.
<thumper> wallyworld: you are on holiday right?
<ahasenack> funny the "normally working" remark :)
<wallyworld> yeah. just poked my nose in to see what's happening
<wallyworld> gotta do painting and house stuff today. rather be working :-(
<davecheney> i appologise for my outburst last night
<davecheney> sorry, i'm just so dang frustrated
<thumper> davecheney: which outburst? i thought you were reasonably measured
<thumper> you certainly didn't leave any psychic scars or nothing :-)
<thumper> davecheney: would you be supportive of an upload-tools that doesn't build them?
<thumper> davecheney: I wrote myself a small script
<thumper> to effectively find the executable path
#juju-dev 2013-07-05
<davecheney> thumper: sure, wallyworld and I want to always include the tools in the deb
<ahasenack> do the relation-list and relation-ids commands trigger a network call? Or does the unit have that information already locally?
<davecheney> so every bootstrap is essentially upload tools
<thumper> davecheney: well, jujud is in the deb
<thumper> I checked
<thumper> davecheney: I think I may do this in parts
<davecheney> wallyworld: and I want to kill the idea of a public bucket
<thumper> davecheney: effectively do the local provider this was, and we can test out the idea
 * thumper nods
<davecheney> thumper: you're the boss (literally)
<thumper> davecheney: however it means uploading 12 meg every time you want to start a new juju environent
<thumper> davecheney: speaking of boss-like things, how about we schedule a regular weekly meeting?
<davecheney> 1, it's not 12mb
<davecheney> its 4 at most
<davecheney> 2, it's only when we bootstrap an envrionment
<ahasenack> and juju upgrade-juju
<davecheney> i don't careif upload tools is the size of the raring iso
<davecheney> it's not a common operation
<thumper> heh
<thumper> well jujud is 14meg on my machine, not looked at a gzip version though
<davecheney> thumper: upload tools says its ~ 4mb last time I looked
<davecheney> but my point stands, i don't care how large it is
<davecheney> it is not a common opeation
 * thumper breaks up some of the local provider work into bits for review
 * thumper is listening to Vilify by Device, very catchy
<davecheney> has anyone tried to run the goamz/s3 tests recently ?
<davecheney> thumper: aaah, http://paste.ubuntu.com/5845459/
<davecheney> ^ this is what happens on go 1.0.2-2 (raring)
<thumper> oh?
<thumper> no, not tried it
<davecheney> will fail on raring
<davecheney> will pass on go 1.1+
<davecheney> i've been trying to hack around the 1.0.2 http problems
<davecheney> and I've chased it this far
<davecheney> https://bugs.launchpad.net/goamz/+bug/1189873
<_mup_> Bug #1189873: Tests fail on tip <goamz:New> <https://launchpad.net/bugs/1189873>
<davecheney> ^ mis reported
<thumper> well, that is frustrating
<thumper> was hoping for a clever way to wrap code in a test
<thumper> but reflect pancis
<thumper> saying unexported function called
<thumper> which is right
<thumper> but I was hoping for testing ...
<thumper> davecheney: thanks for the ParseCIDR
<thumper> I missed that when reading the docs
<davecheney> thumper: np, i had to read them like 3 times to find the bugger
<davecheney> i knew it was in there because we use something similar in the go.net/ipv{4,6} packages
<davecheney> otherewise LGTM
 * thumper goes to make a coffee
<Guest68473> fark
 * thumper tries to work out why I'm failing at creating test directories
<fwereade> jam, fwiw, "watch calls next" should be true
<fwereade> jam, unless you can think of a reason not to do it that way?
<fwereade> jam, well, not exactly
<fwereade> jam, but "watch result includes first event" should certainly be true
<fwereade> jam, and hence out should start off switched on, to correspond with that event
<jam> fwereade: the current code doesn't work like that. So it would be redoing all the watches that we have. The current work is Watch returns a watcher, which you call next on
<TheMue> morning
<TheMue> upgrading to 13.04 seems to be no good idea
<TheMue> :(
<fwereade> jam, ok, well, that sucks and wastes bandwidth
<fwereade> jam, please ifx
<jam> fwereade: so NotifyWatchResult should include the change? Or we know it is a no-op so we swallow the initial event and then trigger the initial event locally?
<rvba> Hi guys, could I please get a second review of https://codereview.appspot.com/10959043/? (original MP, approved by Jeroen, is here: https://codereview.appspot.com/10957043/).
<jam> rvba: commented https://codereview.appspot.com/10959043/
<rvba> jam: ta
<jam> fwereade: api-watchers has been updated for Machine.Watch(). It still asserts that we get 1 initial change, but the server side consumes the local one, and the client side produces its own.
<jam> rvba: https://code.launchpad.net/~jameinel/juju-core/set-agent-version/+merge/173175 is pretty trivial if you are up for a quick review
<rvba> jam: approved
<jam> thx
<jam> mgz: https://code.launchpad.net/~jameinel/juju-core/set-agent-version/+merge/173175 if you are around
<jam> TheMue: ^^
<TheMue> jam: you've got a +1
<jamespage> mgz, those 1.1.1 package appear to be missing runtime/cgo
<jamespage> hmm - the build does something different in PPA
<mgz> jamespage: hmmm
<Guest28536> freenode ate my nick
<jamespage> mgz, its a problem with the cross compilation
<jamespage> runtime/cgo.a only gets built on the 'native' platform I think
<jamespage> so only i386 gets it
<jamespage> bah
<mgz> hm, so the repackaging is breaking us
<jamespage> yep
<jamespage> I'm looking now
<jamespage> mgz, grrr
<mgz> jamespage: how hard would it be to build 1.1.1 with pre-debian-changes packaging, that was used for 1.0?
<mgz> seems otherwise we're somewhat dependent on either fixing ourselves or getting the debian maintainer to fix the build process
<jamespage> mgz, I'll look
<jamespage> mgz, blurg - I really hate this cross compile stuff its doing
<jamespage> mgz, I think your plan is probably a good one
<mgz> jamespage: looks like there's working 1.1 in testing? that also predates the cross compilation stuff right?
<mgz> does the maintainer have his work in a branch anywhere? I wonder what the history of his changes is.
<mgz> yup he does, will have a look as well.
<jamespage> it does - the 1.1.1 is the latest
<jamespage> 1.1-2 is the first one with the cross compile stuff
<jamespage> mgz, sorry - I missed this because I locally built the package on amd64 including the arch all packages
 * jamespage sighs
<jamespage> let me see if I can pull together a 1.1.1 without cross compile
<jamespage> I'll also raise a bug back to debian as well
<jamespage> mgz, hold the line - I had an idea when submitting the bug report.
<mgz> ooo :)
<mgz> rvba: second lgtmed on your branch
<rvba> mgz: third even 'caused Jeroen also reviewed it :)
<rvba> 'cause*
<rvba> mgz: ta
<jamespage> mgz, can I suggest that you delete the packages from the PPA for the time being
<jamespage> they are a load of fud right now
<mgz> sure
<mgz> done.
<jamespage> mgz, OK - I have some new ones building that don't cross compile
<jamespage> and I've reported back to debian
<jamespage> mgz, all done - https://launchpad.net/~james-page/+archive/golang-backports/+packages
<mgz> thanks james!
<mgz> I'll copy those across.
<jamespage> mgz, ack - lemme know how that works out for you
<benji> bac: I'll do the second review for you.
<benji> that was what I was going to suggest initially until I realized the pattern was repeated
#juju-dev 2013-07-07
<fwereade> jam, sounds good, thanks very much, I'll be on later tonight for reviews etc
<jam> fwereade: api-watcher has been updated with your requests, I'm a bit blocked on upgrader-api-client-watcher because it doesn't seem to be firing the very low level Mongo watcher
<jam> fwereade: And I'm working on a NotifyWorker which is all the Worker logic around looping/waiting on Tomb/etc
<jam> which lets you write a worker in terms of "trigger this when an event comes in" rather than re-implementing all the Wait/Kill/Stop/loop logic.
<jam> I started working on Upgrader, and realized a lot of this logic was very generic.
<jam> I hope you had a good time at the wedding.
<jam> fwereade: ping?
<thumper> wallyworld: you working today?
<wallyworld> yep
<thumper> wallyworld: wouldn't mind a catch up call
<thumper> also I need some help with a sounding board
<wallyworld> agreed. give me a few minutes
<thumper> ack
 * thumper takes the dog outside for 5 minutes of chasing a ball
<thumper> wallyworld: back
<wallyworld> ok, almost ready
<thumper> wallyworld: quick, put some pants on
<wallyworld> thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
#juju-dev 2014-06-30
<wallyworld> thumper: dave around today?
<thumper> wallyworld: yeah
<wallyworld> thumper: i'm hoping he can look at bug 1335328
 * thumper looks at _mup_
<wallyworld> it's a follow up from work done last week to fix a windows issue
<wallyworld> he did the fix, but curtis says might still be an issue there of somne sort
<thumper> hmm... I don't think that davecheney has a test setup to be able to run the tests
<thumper> do we have a machine he can use?
<thumper> for windows that is
<wallyworld> not sure, he ssemed to be able to do the original fix, thought he may be able to follow up
<wallyworld> but i can also poke the cloud base guys via nate's squad
<davecheney> wallyworld: all I did was looked at where "unknown" was being set as the series
<davecheney> and tried to fix that
<wallyworld> davecheney: ok, np. the cloud vase guys should fix it since they introduced it
<davecheney> wallyworld: ok,
<davecheney> osversion.go is all fucked up
<davecheney> bunch of logic in thre that is only called from on operating system
<wallyworld> yeah :-( i'm pissed it didn't even compile at first
<davecheney>         com.Commands = `(gwmi Win32_OperatingSystem).Name.Split('|')[0]`
<davecheney>         out, _ := exec.RunCommands(com)
<davecheney>         if out.Code != 0 {
<davecheney>                 return "unknown"
<davecheney>         }
<wallyworld> :-(
<davecheney> ^ so if gwmi is not installed, and they don't check the error
<davecheney> then give up and say it's unknown
<wallyworld> nate was going to follow up last week
<wallyworld> not sure of the status and he is away this week
<wallyworld> not sure how t fark it got past review
<davecheney> wallyworld: thumper so, what do you want me to do ?
<davecheney> debug it via trial and error ?
<davecheney> ^ i'm fine with this
<wallyworld> davecheney: i'll follow up with nate's team
<davecheney> wallyworld: that blocks me for today
<wallyworld> if you are blocked and can fix that would be great :-)
<davecheney> understood
<thumper> what is gwmi?
<wallyworld> i won't get to talk to anyone east coast us till much later this evening
<wallyworld> nfi
<thumper> is that powershell?
<davecheney> y
<thumper> why are they ignoring the error? which I'm assuming is in the _
<davecheney> hulk smash
 * thumper shakes his head
<rick_h_> davecheney: do you just need a windows key?
<rick_h_> davecheney: I know alexisb was asking about getting some people on the MSDN side of things last week
<rick_h_> davecheney: but I can get you a key if you need one
<davecheney> rick_h_: thanks, lets see what happens today
<rick_h_> davecheney: k
<axw> waigani: https://github.com/juju/juju/pull/182#issuecomment-47480573 -- merge failed, please don't set bug Fix Committed until it has
<axw> otherwise we may lose track of it
<wallyworld> Caxw: hiya, i don't think your fix for replicaset startup (using Direct: true) has landed in 1.20 yet?
<axw> wallyworld: I backported something... can't remember which something. I'll check
<waigani> axw: right, sorry about that
<axw> wallyworld: nope, not in 1.20. I'll backport now
<wallyworld> axw: ta, i was looking at CI and local provider upgrade still intermittent
<wallyworld> and then i checked the commits
<axw> wallyworld: did you see the azure bug I was working on Friday evening? I had put it against 1.20, cos it's a pretty bad first impression of the azure provider
<axw> it's not new though
<axw> AFAICT anyway
<wallyworld> axw: yup, and i agree it should be worked on regardless of any misgivings in the email to the dev list :-)
<axw> wallyworld: what email?
<wallyworld> axw: ah, just went to team leads, it said that "This issue is more than 6 months old. I am not inclined to divert efforts to fix regressions." from curtis
<wallyworld> but i think if we can get a fix in place and it is low risk we should, since we will be highlighting all these other azure improvements
<wallyworld> and so people can be expected to try out azure provider
<wallyworld> and we don't want them to hit this bug
<axw> ok
<wallyworld> well, that's imo anyway
<axw> wallyworld: so, one possible (kinda big, but I think low risk) way to fix it is to disable apt-get upgrade
<axw> it also makes bootstrap significantly faster, at the expense of not having up-to-date packages
<wallyworld> hmm, that would then be inconsistent with other providers and i do think we'd want latest packages
<axw> wallyworld: I meant across the board
<axw> it's a bit arbitrary what we upgrade to, so I just wonder about the value
<axw> as opposed to just taking what the server team have released
<wallyworld> hmmm. i can see the point
<wallyworld> but we can't decide such things
<wallyworld> there would be pros and cons
<davecheney> wallyworld: thumper
<wallyworld> if we can make the current solution work that would be the preference for 1.20
<davecheney> i'm going to change version/osVersion() to return a string, error
<davecheney> then all the places it returns an error
<davecheney> i will wrap it in a mustOsVersion function
<axw> wallyworld: sure, I will keep looking to see what's the deal. also, I'm OCR today so gotta take time out from fixing things
<davecheney> it is clear that juju cannot operate if it doesn't know the series
<davecheney> so we cannot continue at that point
<wallyworld> axw: SURE, NP
<wallyworld> bah
<wallyworld> sorry capslock fail
<axw> :)
<thumper> davecheney: how is that really changing anything?
<thumper> I guess it is more idiomatic
<davecheney> thumper: we'll know where the unknown is coming from
<davecheney> rather than just being a string "unknown"
 * thumper nods
<thumper> fair enough
<davecheney> that propogates through the app until it finally hits something that tries to use it and fucks out
<wallyworld> is it possible to catch the errors instead of panicing?
<davecheney> wallyworld: not in the places osVersion is called
<davecheney> sorry, not in all the places
<wallyworld> ok
<davecheney> so you'd have two forms
<davecheney> osVersion => string, error
<davecheney> mustOsVersion => string or panic
<wallyworld> not being familiar with the code, hard to say, but 1 way is always preferable, but if not better to panic than let an impossible value propagate
<davecheney> wallyworld: -EDOUBLENEGATIVE
<wallyworld> did i leave out a comma
<davecheney> wallyworld: it wasn't clear
<davecheney> are you for panic'ing or not
<wallyworld> prefer 1 way of doing things, but if that's not possible, then i guess a panic is ok since it prevents impossible value being propagated
<davecheney> func macOSXSeriesFromKernelVersion(getKernelVersion kernelVersionFunc) string {
<davecheney>         majorVersion, err := kernelToMajor(getKernelVersion)
<davecheney> look at this !>?>!
<davecheney>         if err != nil {
<davecheney>                 logger.Infof("unable to determine OS version: %v", err)
<davecheney>                 return "unknown"
<wallyworld> sigh
<wallyworld> how the fark did this get past review
<davecheney> so, unknown is being used as a sentinal for error
<davecheney> but it happens to be the same type as the valid value
<davecheney> so fits throught the hole and leaks
<davecheney> func (*CurrentSuite) TestCurrentSeries(c *gc.C) {
<davecheney>         s := version.Current.Series
<davecheney>         if s == "unknown" {
<davecheney>                 s = "n/a"
<davecheney>         }
<davecheney> more evidence that "unknown" is used as a sentinal for error
<axw> menn0: before I land, can you please see my reply on https://github.com/juju/juju/pull/188
<axw> menn0: if you've got a suggestion on how to improve that, I'm happy to incorporate
<menn0> axw: I was just looking at it now
<menn0> axw: give me 2 mins
<axw> sure
<axw> ta
<menn0> axw: I don't quite understand why it's more difficult to do the mongo setup/upgrade work from Run() instead of inside the state worker
<axw> menn0: the state worker is started indirectly
<menn0> sure the mongo setup work can be done can be done just before the first StartWorker call in Run()
<menn0> surely even
<axw> there's a "state starter" worker, which starts the state worker when it knows it's a state server
<menn0> axw: ok, right. it's getting clearer to me now
<axw> menn0: it could, but it'll involve checking for state server info, if we don't have it connecting to the API
<menn0> axw: so a jujud can theoretically become at state server any time?
<axw> theoretically
<menn0> ok I get it then.
<axw> there was talk about upgrading non-state servers to state servers
<axw> we haven't done that yet
<menn0> what you've done makes more sense now.
<axw> okey dokey
 * menn0 checks the PR one more time
<wallyworld> axw: you land the work on both 1.20 and trunk, right
<axw> wallyworld: yes I will do
<wallyworld> great, once all the 1.20 fixes in the area of upgrades are landed, i'll see if i can run the upgrade job on CI by hand
<wallyworld> to get a feel for if it will be happy
<menn0> axw, wallyworld: the PR looks ok to me now that I understand the way the state worker is started
<wallyworld> \o/
<axw> menn0: cheers
<menn0> axw, wallyworld: I have been manually doing what the test that was failing in CI was doing  (well with a little script)
<menn0> axw, wallyworld: I'm happy to test it again once it lands.
<axw> waigani: are you still working on https://github.com/juju/juju/pull/66 ? would you please put "WIP" in the title if it's not ready for review?
<menn0> failing test even ...
<axw> menn0: thanks
<wallyworld> and it's been failing for you too?
<menn0> wallyworld: sporadically yes (it's a race after all)
<wallyworld> yeah. cool. just checking it *was* failing at least sometimes
<axw> davecheney: https://github.com/juju/juju/pull/156   <- is this ready to land?
<menn0> wallyworld: I was never able to test the exact scenario because my machine-0 is trusty but thumper has given me a great tip about how to test with the local provider on canonistack (which gives you all precise machines)
<wallyworld> ok
<davecheney> yes, i believe so
<davecheney> tim and william have resolved their differences
<davecheney> it's waiting for the 1.20 trunk to sabalise before I merge more difficult to backport changes
<axw> ok
<wallyworld> menn0: did you log into a canonistack instance and run a local provider env from there? or was there some other magic involved?
<waigani> axw: done. also added comment explaining that I'm waiting for the identity stuff to be sorted.
<axw> waigani: thanks
<menn0> wallyworld: no I have been testing locally so far but will test with a local provider on a canonistack instance once this PR lands
<wallyworld> ok
<menn0> (that was thumper's trick)
<axw> waigani: you have failing tests in your branch if you didn't realise
<waigani> axw: on PR 182? I've already fixed it
<axw> waigani: not according to the bot
<axw> http://juju-ci.vapour.ws:8080/job/github-merge-juju/289/consoleFull
<axw> there's a bunch of the usual mongo failures after your ones in cmd/juju
<waigani> axw: okay, on it
<thumper> Anyone else seen this test failure in state?  export_test.go:58:
<thumper> c.Assert(err, gc.IsNil)
<thumper> ... value *errors.errorString = &errors.errorString{s:"cannot create log collection: local error: bad record MAC"} ("cannot create log collection: local error: bad record MAC")
<thumper>  s.ConnSuite.SetUpTest(c) fails
<davecheney> mac relates to the tls handshake between mongodb and juju
<thumper> seems intermittent
<thumper> race condition?
<axw> I've heard in the past that there's a problem with the mongo 2.4 TLS support, and that's fixed in 2.6
<axw> we have seen that error occasionally, I think it used to be worse
<thumper> wallyworld: https://github.com/juju/juju/pull/194
<thumper> axw: ok
<davecheney> the hell
<davecheney> odessa(~/src/github.com/juju/juju/version) % go test
<davecheney> # github.com/juju/juju/version
<davecheney> import cycle not allowed in test
<davecheney> package github.com/juju/juju/version (test) imports github.com/juju/juju/testing imports github.com/juju/juju/environs/config imports github.com/juju/juju/version
<davecheney> FAIL	github.com/juju/juju/version [setup failed]
<davecheney> test's for this package don't even pass on darwin at the moment
<wallyworld> thumper: looking
<wallyworld> +1
<thumper> wallyworld: does the merge command work there, or manual
<wallyworld> works
<davecheney> uh, what the f
<davecheney> juju/version tests don't pass at all on osx
<davecheney> thumper: OMG
<davecheney> i know how this happened
<davecheney> someone started to use version.Current in cmd/juju
<davecheney> so that meant version.Current.Series had to make sense on any _client_ platofmr
<davecheney> https://github.com/juju/juju/pull/195
<davecheney>                 reg := regexp.MustCompile("^" + key))
<davecheney>                 match := reg.MatchString(series)
<davecheney> the award for the most egregious use of regex
<thumper> davecheney: wha???
<thumper> that makes no sense
<thumper> why?
<davecheney> strins.HasPrefix(series, key) anyone ?
<axw> davecheney: key doesn't contain pattern characters?
<davecheney> axw: no idea
<davecheney> can't run the tests
<davecheney> well, i subtituted osversion_windows for osversion_linux and the tests pass
<axw> I mean, HasPrefix is only equivalent if key doesn't have any meta-chars
<davecheney> var windowsVersions = map[string]string{ "Microsoft Hyper-V Server 2012 R2": "win2012hvr2", "Microsoft Hyper-V Server 2012":    "win2012hv", "Microsoft Windows Server 2012 R2": "win2012r2", "Microsoft Windows Server 2012":    "win2012", "Windows Storage Server 2012 R2":   "win2012r2", "Windows Storage Server 2012":      "win2012",
<davecheney> they aren't regexes
<davecheney> the original author just used the wrong hammer
<axw> okey dokey
 * thumper afk taking kids to ice skating
<thumper> bbl
<wallyworld> axw: jeez, not having much luck with session closed errors :-(
<axw> indeed
<axw> driving me crazy
<wallyworld> we gotta fix those, maybe we can spike on it next week
<axw> yup, sounds like a plan
<wallyworld> or this week if we get time after 1.20 goes out
<davecheney> wallyworld: axw how can I go from a commit, to the review that supports that commit ?
<davecheney> ie, given a hash, how can I find the PR for that hash
<wallyworld> hmmm, not sure off hand
<davecheney> wallyworld: you're probably not going to like the answer
<wallyworld> which is?
<davecheney> you can't
<wallyworld> wtf
<davecheney> wallyworld: https://github.com/juju/juju/commit/f1e95e6507a30fab8a31508f46bfd70753ef452a#diff-0d404a754ae93c99bdaa41896be9ce3e
<wallyworld> why is github so popular if it is missing so many key festures
<davecheney> i cannot find the PR for this commit
<davecheney> wallyworld: unit testing isn't popular in PHP
<davecheney> they don't miss what they don't know
<wallyworld> sigh
<davecheney> wallyworld: can we make the bot insert the link to the PR in the commit message
<wallyworld> we can
<davecheney> hmm, maybe I just need to find hte "merge commit"
<axw> davecheney: yeah, follow the parents up
<davecheney> https://github.com/juju/juju/commits/master/version/osversion_windows.go
<axw> then the PR for the merge
<axw> or.. hmm
<axw> that didn't work
<davecheney> nup
<davecheney> i cannot find who reviewed this file
<davecheney> https://github.com/juju/juju/commits/master/version/osversion_windows.go
<axw> davecheney: https://github.com/juju/juju/pull/95
<axw> I think
<davecheney> so, when github does the merge you get
<davecheney> https://github.com/juju/errors/commit/6b882ebdb3eb178615c864192a2c1b4502ed86c4
<davecheney> when our bot does it
<davecheney> we get no record
<davecheney> oh the irony
<davecheney> https://github.com/juju/juju/pull/95#discussion_r14192953
<axw> there's plenty of those merge commits in the log
<axw> from the bot
<davecheney> nate spotted the problem 5 days ago
<davecheney> but the OP never came back to followup
<jam1> morning dimitern
<dimitern> morning jam
<voidspace> morning all
<dimitern> hey voidspace
<dimitern> voidspace, we should have a quick chat to bring you up-to-speed with the current networking / ipv6 work
<voidspace> dimitern: yes, let me get coffee etc first and I'll ping you
<dimitern> voidspace, sure, no rush
<voidspace> dimitern: thanks :-)
<TheMue> morning
<TheMue> jam: ping
<voidspace> dimitern: ok, hangout?
<dimitern> voidspace, just a sec
<voidspace> dimitern: no problem
<TheMue> jam: no need to pong back anymore, already got it
<axw> wallyworld: finally found out the secret sauce to get azure to bootstrap with upgrades
<axw> wallyworld: I measured the time for a bootstrap with/without upgrade, apt-get upgrade added 6 minutes
<wallyworld> 6 minutes
<axw> I'll propose my fix and mail the list about making upgrade optional and off by default
<wallyworld> wow
<axw> also want to test apt-get using eatmydata
<axw> that may make it more reasonable
<wallyworld> ok
<wallyworld> i wonder if we can deploy an apt cache to azure
<wallyworld> or mirror
<axw> wallyworld: I believe there is a mirror already
<axw> cloud-init configures apt mirrors
<mgz> 6 minutes... doing what mostly?
<axw> mgz: that's timed from before "apt-get upgrade" to after
<axw> so... whatever apt-get upgrade is doing
<mgz> I really don't think not upgrading is an option..
<axw> why?
<mgz> we have security fixes for a reason
<axw> mgz: but we don't continue upgrading after it's provisioned, so it just seems so arbitrary to do it at that point
<axw> mgz: if people want to keep it secure, then there should be something doing upgrades on a regular basis
<mgz> yeah, and we don't reboot for kernel either
<axw> not just once and then that's it
<axw> anyway, I'll test with eatmydata, maybe it won't be so bad
<wallyworld> axw: mgz: can we start the standup now?
<wallyworld> axw: standup?
<axw> wallyworld: sorry brt
<jamespage> jam: around? just getting to looking at mongodb/juju-mongodb -> 2.6.x
<axw> wallyworld: the azure virtual network thing may have been coincidental
<axw> it's not happening now
<wallyworld> ah
<wallyworld> maybe see how it goes over the next day or so
<axw> yep
<axw> could someone please review https://github.com/juju/juju/pull/196
<axw> resolves a 1.20 issue
<dimitern> axw, reviewed
<axw> thanks dimitern
 * axw comes back later to handhold the bot
<axw> wallyworld: I might just change it back anyway, so we at least don't regress
<wallyworld> rightio
<voidspace> dimitern: ping
<voidspace> dimitern: the "COntainer Addressability in EC2" section of the "Juju Networking Support Changelog and Roadmap" doc
<voidspace> dimitern: says: Found a working procedure to spin up LXC containers, allocate a private IP from the host using EC2 API,
<voidspace> dimitern: why are we using LXC on EC2?
<dimitern> voidspace, we need addressable containers everywhere basically, EC2 is the first step
<voidspace> dimitern: why do we need containers?
<voidspace> dimitern: I mean, isn't EC2 essentially already a container
<dimitern> voidspace, for higher density deployments
<voidspace> dimitern: I understand the need for addressability
<voidspace> dimitern: heh, containers within containers
<dimitern> voidspace, no, EC2 instances are more like KVM machines than LXC containers
<voidspace> dimitern: so they are containers...
<voidspace> dimitern: ok, and containers on EC2 is primarily a networking issue?
<voidspace> dimitern: I'm wondering why it's bundled with the networking story
<voidspace> seems like a separate issue - unless the *primary* problem of "nested containers" is addressability
<dimitern> voidspace, it is a networking issue - we can't get cloud-local ips for containers without additional work
<voidspace> dimitern: ok, cool
<voidspace> thanks
<voidspace> so we use the host api to get a cloud local address for the contained container
<voidspace> and providers need to support this
<dimitern> voidspace, yes, if the provider supports addressable containers, it needs to implement AllocateAddress, so we can get an extra private ip for an instance, which we later assign to the container on that instance
<voidspace> cool
<fwereade> dimitern, quick check: when we're adding the implicitly pre-existing networks to the model, will we be assuming that services require juju-public (if it exists) along with juju-private (which they have to have to communicate with the state servers)?
<perrito666> voidspace: hey, welcome back
<dimitern> fwereade, right, juju-public and juju-private will be created automatically post-bootstrap, and all instances will be implicitly on them, regardless what other networks might be specified
<voidspace> perrito666: hey, hi
<voidspace> perrito666: it was a nice relaxing time away - so I'm actually happy to be back
<voidspace> perrito666: mostly just because I'm happy...
<voidspace> perrito666: how were things?
<fwereade> dimitern, juju-private is definitely required for all machines/services
<fwereade> dimitern, juju-public, if it exists, should probably be required for state servers and services -- at least by default
<dimitern> fwereade, yes, but it won't be part of the requested networks lists, it will just be assumed it is
<fwereade> dimitern, hmm, that feels special-casey
<dimitern> fwereade, it is pretty special :)
<fwereade> dimitern, not sure it's special enough
<fwereade> dimitern, juju-private, yes
<dimitern> fwereade, yeah
<fwereade> dimitern, juju-public (1) might not even exist and (2) might not be wanted for a number of services
<fwereade> dimitern, even for the state server, potentially
<voidspace> jam: chrome just crashed - sorry!
<dimitern> fwereade, but since that's only important at the time expose was called, it should be fine
<fwereade> dimitern, I think if it does exist juju-public should be the default for new machines/services, but I suspect that if we're being explicit about required networks we should not automatically tack on juju-public
<dimitern> fwereade, why not?
<fwereade> dimitern, ^juju-public seems like a very reasonable thing to ask for (eg) a super-secret db server
<fwereade> dimitern, and if juju-public is always assumed that's an immediate contradiction
<wwitzel3> morning, brb, updates want me to restart
<dimitern> fwereade, if juju-public is available at all, we can use it when needed (during expose), for any service, right?
<dimitern> fwereade, it won't get configured specifically
<voidspace> jam: lost connection!
<dimitern> fwereade, until we need it
<voidspace> jam: but no, that ticket was dropped
<voidspace> jam: it should be deleted
<voidspace> sorry
<fwereade> dimitern, I'm worried that being *unable* to say "don't allow this service on the public network" is a problem
<jam1> voidspace: deleted
<voidspace> thanks
<voidspace> jam1: I have no in progress tasks
<wwitzel3> welcome back voidspace
<fwereade> dimitern, and given that that network may or may not exist I think we should avoid special-casing it too much
<voidspace> wwitzel3: hey, hi
<dimitern> fwereade, let's think about this a bit
<fwereade> dimitern, making it a default *if not otherwise specified*, but requiring juju-public explicitly if you also ask for other networks, feels more like what we need
<fwereade> dimitern, go for it
<dimitern> fwereade, in ec2 any machine is on the public network, and you can't restrict this with the default vpc setup
<fwereade> dimitern, I'm more thinking about maasy environments
<fwereade> dimitern, if the provider has no machines not on the public network, then provisioning will fail, and hopefully we can clearly explain why
<dimitern> fwereade, we can still say deploy --constraints networks=^juju-public
<fwereade> dimitern, how can that work if juju-public is always implicitly a required network? everything with ^juju-public will fail
<rick_h_> fwereade: rogpeppe call time?
<perrito666> does anyone know where --version is being registered?
<fwereade> dimitern, if it's a required network *by default*, that can either be explicitly unspecified with `--network=` or (maybe better?) handled by the cli client such that ^juju-public doesn't send that, we might do better
<rogpeppe> rick_h_: ah yes
<fwereade> rick_h_, balls sorry
<fwereade> rick_h_, omw
<dimitern> fwereade, implicitly in the sense they're not part of instance selection criteria explicitly, unless explicitly specified
<dimitern> fwereade, i.e. trying --constraints networks=^juju-private will fail on the juju side, but networks=juju-private,^juju-public will be ok, and passed to the provider
<fwereade> dimitern, I thought --networks didn't take ^
<dimitern> fwereade, i'm talking about constraints, since that's the way now to exclude networks
<tasdomas`> is there some pattern when operations on state are retried (with state.run(...)) and when they are not?
<wallyworld> fwereade: andrew reviewed this and i fixed issues, you may want to take a final look https://github.com/juju/juju/pull/185 cool if you don't have time
<fwereade> wallyworld, I will try, for what that's worth :/
<fwereade> tasdomas`, in general we'd expect them to be retried, is there something paticular yu're looking at?
<fwereade> dimitern, sorry, meeting took over my brain
<fwereade> dimitern, my point is simply that if juju-public is implicitly always a required network for anything, you can't exclude it with constraints because that creates a contradiction
<dimitern> fwereade, let's say it's not required, but assumed to be there, and you can still specify it with a negative constraint to try to get a machine without it
<fwereade> dimitern, I'm fine imposing that on juju-private, but not on juju-public, because everything *has* to have juju-private access (derail: manual provider? is juju-private really juju-public? arrgh) but there are use cases in which even the possibility of juju-public access is contraindicated
<fwereade> dimitern, to assume makes an ass of u and me -- *defaults* are fine, but I'm really worried about having it treated specially internally
<dimitern> fwereade, re manual - juju-private should be using the same subnet the machine was added with
<dimitern> fwereade, and there might be a different public one
<fwereade> dimitern, I would be much happier with the CLI being responsible for inserting juju-public into the API call when appropriate, and making it explicit at every possible level beyond that -- the user doesn't have to care, but I would really like it if the API required you to say what you mean and mean what you say
<dimitern> fwereade, by special treatment I mean 3 things: 1) cannot be removed, 2) refcount is ignored, 3) assumed to be there when missing in the requested networks lists (but can be specified there explicitly as well)
<fwereade> dimitern, (1) is about as much special treatment as I'm willing to deal with
<dimitern> fwereade, (1) implies (2)
<fwereade> dimitern, it might just mean it's created with a refcount of 1, instead of 0, thus preventing if from being killed; and all the rest of the code works exactly the same
<fwereade> dimitern, doing (2)-style stuff will spread through state
<fwereade> dimitern, *someone* will fuck it up sooner or later
<dimitern> fwereade, well, we have IsDefault=true as well, which might short-circuit some checks for juju-private
 * dimitern needs to go out for 1h
<fwereade> dimitern, (another derail: IsDefault still bugs me, because it's kinda hard to prevent two things thnking they're default)
<dimitern> fwereade, ttyl, sorry
<fwereade> dimitern, ping me when you're back please :)
<fwereade> dimitern, take care
<dimitern> fwereade, sure ;)
<tasdomas`> fwereade, ok, thanks - was simply looking for precedent and it seemed like AddUnit in state/service.go was not being re-run
<wwitzel3> voidspace: ping
<bac> hi mgz
<mgz> bac: hey
<voidspace> wwitzel3: pong
<wwitzel3> voidspace: up for a hangout, could use a rubber duck and potentially active assistance :)
<voidspace> wwitzel3: happy to hangout briefly  and be a rubber duck - about to go on lunch after that though :-)
<wwitzel3> voidspace: thanks, heading to moonstone
<voidspace> wwitzel3: cool
<mgz> wwitzel3: I thought the term was teddy bear, not rubber duck :)
<wwitzel3> mgz: I've always known it as rubber duck debugging
<wwitzel3> mgz: but teddy bear sounds reasonable too
<voidspace> mgz: yeah, rubber-ducking is the term I know
<mgz> aa, cultral differences :)
<voidspace> wikipedia agrees with wwitzel3 and me
<voidspace> http://en.wikipedia.org/wiki/Rubber_duck_debugging
<voidspace> although it does suggest "talk to the bear" as an alternative
<fwereade> tasdomas`, having taken a quick look, I think the AddUnit thing represents an assumption that addUnitOps doesn't return ops that can fail for any reason other than the service no longer being alive
 * voidspace lunches
<fwereade> tasdomas`, I am at least 80% sure that assumption still holds
<fwereade> tasdomas`, but it's a lot harder to be sure now that addUnitOps has been factored out
<TheMue> jam: jam1: ping
<TheMue> jam1: jam: would you take a look at https://github.com/TheMue/juju/tree/api-endpoints-public-private-address/cmd/juju and here endpoint.go and its test?
<jam1> TheMue: const endpointDoc = `Returns a list of the API servers formatted as host:portDefault output format returns an api server per line.
<jam1> needs updating
<jam1> TheMue: I don't think we want to repeat the Start/End private lists here
<jam1> if we want to do that filtering, we can reuse it from network
<jam1> though I think we don't actually want to do that here.
<jam1> TheMue: so my thought was that we just return the first API address in the list
<jam1> as that is the one that Juju successfully connected to.
<jam1> TheMue: if you feel more strongly that we should be determining what addresses to connect to, then we should find a way to share the code with our existing implementation
<jam1> TheMue: see "network.isIPv4PrivateNetworkAddress"
<TheMue> jam1: the addresses returned by the API are ordered so the the first one is enough? would be more simple, yes
<TheMue> jam1: ah, and havenât seen the network test function
<jam1> TheMue: so we probably need to document that we're relying on the behavior, but I implemented code so that explicitly the IP address that we connected to last is always sorted to the beginning of the list
<TheMue> jam1: ok, so the change would be taking the first address, doc that we rely on that and change the doc string that we only return one address?
<TheMue> jam1: thatâs even simpler then :)
<TheMue> jam1: at least it helped a bit to get into networking
<jam1> TheMue: I believe so. "state/api/state.go Login()" calls addAddress which calls slideAddressToFront for the address that we successfully connected to.
<TheMue> jam1: nice behavior. only became insecure because of the slice of strings which made me thought it has no special order. dunno why.
<TheMue> jam1: eh, the command is called api-endpoints. so always returning only one looks a bit strange. the filename states, that it once has been singular, has it?
<jam1> TheMue: I believe in older versions it was singular, you'll have to do some spelunking into the 1.18 and 1.16 code bases to figure it all out. But it used to connect to the Environ directly, and report the single DNSName (I think?) of the state server that it found doing a lookup of the instance id found in bootstrap-state in provider storage.
<TheMue> jam1: just started to dig in the history. but I wonât rename it back as it now used this way.
<jam1> TheMue: well, I think the only consumer of it was probably assuming it returned a single value
<jam1> as I *think* we changed the behavior in 1.18 and kapil filed bugs about it not working the way he wanted.
<TheMue> jam1: ah, august last year
<bac> morning sinzui
<sinzui> hi bac
 * fwereade failing to think properly, going for a short walk
<axw> TheMue: there's already code in network/address.go for categorising IP addresses, too.
<axw> TheMue: if you pass an IP address into network.NewAddress with ScopeUnknown, it'll check the private network ranges
<wwitzel3> woo got my test stubs compiling and passing .. I feel like getting the suite setup with the right data and intefaces is always the biggest part of the battle
<axw> TheMue: sorry, just saw jam1 made the same comment
<TheMue> axw: yes, but still thanks for the hint
<TheMue> axw: itâs now unneeded in this case as I learned, but talked today about a possible additional command for listing (and filtering) the addresses together with more information
<axw> ok
<mattyw> axw, I'm just reviewing https://github.com/juju/juju/pull/197 <- It's my first time reviewing core code - and I'm not very familiar with the azure stuff, it looks fine to me but you might like to get someone more familiar with azure to double check
<axw> mattyw: thanks
<axw> and I'll add a reference to the doc
<TheMue> jam1: simplified it (aka stripping all curious ideas of first approach away) ;)
<mattyw> axw, shouldn't you be asleep?
<axw> mattyw: it's not yet 10pm, I don't go to sleep that early :)
<mattyw> axw, oh right  - you must be western Australia?
<axw> yup
<axw> UTC+8
<jam1> TheMue: "we rely on the fact that the returned API endoint always has the last address we connected to as the first address" perhaps?
<jam1> TheMue: and second to that, I think we want a test where "info" has more than one value (if we can manage that) so that we can see that it is actually doing the right thing.
<jam1> I have the feeling we'd really like a simple helper that runs the command and grabs the output rather than putting that into each test caes.
<jam1> we might also need a test where we haven't connected to the state already?
<TheMue> jam1: ok, text change is simple. but info with more than one value? hmm, have to check how we can to this
<perrito666> wwitzel3: voidspace I will not make it to the stdup, I am on the sprint, sorry
<perrito666> btw, where is eric?
<axw> sinzui: the summary you just changed 1316185 to isn't right. it happens in azure with the release stream, but does not happen with the daily stream. but it's not just the stream that's the problem it's a combination of things
<axw> at the end of the day it's how long apt-get upgrade takes
<wwitzel3> perrito666: voidspace is on sapphire's standup anyway, he is working on the networking stuff
<alexisb> wwitzel3, so sad you are all alone
<wwitzel3> I wallow in it, the sadness
<sinzui> axw, sorry I will fix the summary
<mbruzek> Hi guys, I need to search for and/or open a bug against juju-core.  I know you moved the code to github, are the bugs still kept in launchpad?
<axw> sinzui: nps. I changed it already, feel free to change again
<rogpeppe> fwereade, wallyworld: i'm just wondering why we keep both md5 and sha256 hashes for the storage blobs?
<mbruzek> disregard my question, read it in the topic.
<katco> hi everyone, i'm katherine/katie :) today's my first day on the juju-core team. going through some administrative setup at the moment, but wanted to pop in and say hello!
<mbruzek> welcome Katie!
<ericsnow> katco: welcome!
<perrito666> katco: welcome
<mgz> hi!
<katco> thanks all :)
<TheMue> katco: heya, nice to have you now in our team. welcome and enjoy your new job.
<rogpeppe> katco: hiya and welcome to Canonical! i saw your blog post about joining and enjoyed it... i recognised your name from somewhere (possibly comments on gustavo's posts?)
<jcw4> welcome katco :)
<dimitern> hey katco and welcome!
<katco> rogpeppe: quite possibly! i enjoy gustavo's posts
<rogpeppe> katco: me too
<perrito666> the "only refresh video when this tab is active" hangout policy is going to give me a hearth attack one of these days
<dpb1> 1.19.4: anyone seen this error? https://pastebin.canonical.com/112696/  (intermittent).
<rogpeppe> fwereade, rick_h_, wallyworld: this is the kind of thing i had in mind for blob storage: http://paste.ubuntu.com/7726779/
<rogpeppe> fwereade: i think it could work pretty well. no need to ref count - we can just garbage collect occasionally.
<jam1> katco: welcome to the team!
<katco> jam1: ty!
<wwitzel3> katco: welcome
<katco> wwitzel3: ty as well :)
 * katco learning the joys of sl
<TheMue> jam1: short info, w/o an API connection we currently only return nothing. Iâll change it to an error message, ok?
 * TheMue is afk for a moment, switching car back from the garage
<alexisb> katco, welcome!
<katco> alexisb: thank you, and hello again!
<jam1> TheMue: I thought that the "refresh" logic would have connected to the state server to ensure we have addresses if there was none already cached.
<jam1> certainly if we don't have an address and can't connect, that sounds like an error state
<TheMue> jam1: maybe my test is to naive here. Iâve closed APIConn of the test to see how the command execution behaves
<wwitzel3> So the caller.Call code (http://paste.ubuntu.com/7726982/) is panicing from a nil pointer reference. It happens in Call, it never makes it to the apiserver method. I'm sure I'm doing something completely wrong, I just have no idea what.
<jam1> wwitzel3: most likely the caller you are passing into NewFacade is nil
<wwitzel3> jam1: when I check caller for nil it isn't nil and the printed value is http://paste.ubuntu.com/7727026/
<jam1> wwitzel3: can you paste the traceback?
<jam1> (panic)
<wwitzel3> yep
<wwitzel3> jam1: think I found it, looks like a call to api.st.EnvironConfig is causing it
<wwitzel3> It helps if I actually set the state in the EnvironmentAPI struct.
<perrito666> is the bot only set up for juju/juju ?
<perrito666> I just $$merge$$d on juju/utils and nothing happens, and looking into the history of the repo merges are by rogpeppe
<rogpeppe> perrito666: yeah, the 'bot is only set up for juju/juju
<rogpeppe> perrito666: you just have to do the merge
<perrito666> rogpeppe: using the gh large green button or via command line?
 * perrito666 does not want to break the repo
<rogpeppe> perrito666: green button
<perrito666> rogpeppe: thank you
<perrito666> I tested the branch by hand just in case
<perrito666> and I read the other day that github was nice enough to implement unmerge
<voidspace> Right, Krav Maga time
<voidspace> see you all tomorrow
<voidspace> EOD
<ericsnow> voidspace: bye
<ChrisW1> so this is where all the cool kids hang out :-)
 * ChrisW1 waves to thumper, men0 and voidspace
<katco> gah make install-dependencies hosed my go v1.3
<katco> what version is the project utilizing, and should it work in 1.3?
<ericsnow> katco: FWIW I'm running 1.2.1 (system install)
<ericsnow> katco: no idea on 1.3
<katco> i know there were some performance improvements in 1.3. newbie question: how does the team evaluate migration to new releases?
<perrito666> katco: iirc 1.2
<katco> ericsnow: perrito666: ty
 * katco is now wondering how difficult it might be to juggle multiple versions of go
<ericsnow> katco: I just started a few weeks ago so don't count on me to be a deep resource :)
<ericsnow> katco: yet
<wwitzel3> katco: we are kind of restricted by what is distributed with LTS releases.
<wwitzel3> at least that is my understanding, I am sure someone has a better more indepth explanation of the actual process or migration to the latest release
<katco> ericsnow: well you have a few weeks on me ;)
<katco> wwitzel3: i use gustavo niemeyer's excellent godeb to grab new versions. i understand if that's not tenable for the project; just curious!
<katco> hm. i'm trying to go get code.google.com/p/go.tools/cmd/vet, but i don't have write access to goroot. is there a better solution than to grant my user account access to goroot?
<perrito666> goroot is not something on ~ I assume
<katco> perrito666: i'm following the CONTRIBUTING.md, and when i ran make install-dependencies, it grabbed the go dist from ubuntu proper
<katco> currently sitting under /usr
<katco> /usr/lib/go
<katco> i can probably just overwrite it with gustavo's godeb, but i wasn't sure if that was a good solution. i'm assuming i'll be doing make install-dependencies in the future
<mattyw> It's probably not the best answer but I gave up on that a while ago. I just download the binary from golang.org
<perrito666> katco: mm, I set GOPATH to ~/gocode and in my case GOROOT is not set
<ericsnow> katco: your GOPATH is set to something you own?
<katco> ericsnow: it is... it's using gotooldir since this is in go.tools
<katco> which is the thing under /usr/lib/go
<katco> it sounds like maybe what i should do is just install my own version of go... do we run make install-dependencies repeatedly? or is that like a one-timer?
<mattyw> A one time thing I think
<mattyw> I've got my path setup so my go binary is the first thing it finds. So anything that changes underneath is ignored
<perrito666> katco: in my experience onetimer (that is ~3months)
<katco> perfect :)
<katco> mattyw: well, i use godeb which uninstalls ubuntu's version, and make install-dependencies does the same
<katco> so they would be warring =/
<mattyw> There was something weird with old packages of go that would try to put packages in /usr/lib irrespective of gopath
<katco> i asked over in #go-nuts, and they said it's because it comes from go.tools that it will use go env |grep -i gotooldir
<katco> which points to /usr/lib/...
<katco> i'll see if godeb behaves better
<katco> ty team :)
<katco> it just occurred to me that if i switch back to 1.3 i'll get debugging working again too
<katco> fyi, gustavo's godeb installation works quite nicely
<katco> saves time on setup too!
<perrito666> ok eod
<katco> tc perrito666 ty for the help!
<perrito666> cuall tomorrow, cheers
<katco> in scripts/, should these refer to local directory, or hard-coded to github.com/juju/juju?
<katco> also, off of a fresh go get -u, these scripts return 3 errors for me
<mattyw> Have you run godeps?
<katco> mattyw: i have not
<katco> i'm following: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
<mattyw> godeps -u dependencies.tsv I think is the command
<mattyw> It sets everything to the correct version
<katco> ty i'll try that... should the CONTRIBUTING.md be updated? or is this just implied
<katco> ?
<ericsnow> katco: it should already be there
<ericsnow> katco: see the "Dependency management" section
<katco> ericsnow: oy. sorry... i swear i just did a find on the page =/
<ericsnow> katco: no worries :)
<mattyw> Although it's just occurred to me that I haven't setup the pre commit hook
<katco> i'm still receiving a build error in trunk: # github.com/juju/juju/state
<katco> ../../juju/juju/state/action.go:86: too many arguments in call to names.NewActionTag
<thumper> katco: have you run godeps?
<thumper> katco: we have a system so trunk is always buildable
<katco> thumper: i have
<thumper> katco: let me look
<katco> i'm sure i'm doing something wrong
<katco> did a go get -u github.com/juju/juju; go build ./...
<bodie_> you want to do juju/juju/...
<bodie_> then run godeps
<bodie_> then try building
<bodie_> (... in the go get step)
<katco> ah i bet that's it
<thumper> yeah
<katco> (get taking longer :))
<thumper> katco: pretty sure the godeps instructions are in the contributing file
<katco> thumper: they are, thank you
<thumper> np
<katco> yay, building!
<katco> ok, now my other question is why are the scripts in my fork building the trunk for error checking?
<thumper> um... wat?
<katco> (assuming i am wrong again) if i look at github.com/katco-/juju/scripts/pre-push.bash
<thumper> wallyworld, sinzui: interesting data point, last night bootstrapping ec2 m3.medium, I got timeout failure during jujud bootstrap with mongo replica set not coming up
<thumper> one time out of three
<katco> the last line is: go build github.com/juju/juju/...
<katco> i am wondering if that should be "go build ../..."?
<thumper> nah...
<thumper> that's fine
<thumper> it was probably that the godeps step hasn't been added there
<thumper> and it probably should be
<sinzui> thumper, I have seen that too. The 5 failures listed here pertain to replicaset http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/
<thumper> sinzui: any idea why it is flakey?
<bodie_> katco, if you go build ./... in juju, and the deps aren't built, it should also build them
<bodie_> :)
<thumper> sinzui: or is it likely to be "you are using an old mongo, please upgrade"
<sinzui> thumper, does trusty have an old mongo?
<thumper> sinzui: we are using juju-mongodb which is 2.4
<katco> maybe i'm resting on a bad assumption; isn't that line designed to check to see if the branch you're currently hacking on builds?
<thumper> katco: yes
<katco> hm. is my setup wrong? should i be working out of the github.com/juju dir?
<bodie_> why?
<katco> i think i'm missing something. if go build github.com/juju/juju is designed to test my current working set, and i'm modifying github.com/katco-/juju, i am missing how it fulfills its purpose
<mattyw> It needs to be juju/juju
<bodie_> ah, what you want to do is actually clone your personal repo to $GOPATH/github.com/juju/juju
<katco> ahhh ok!
<bodie_> I think this is all in CONTRIBUTING though
<katco> gosh i'm sorry. i suppose i need to go back through and read this more carefully
<bodie_> I had many of the same questions, heh
<katco> thanks for the help
<bodie_> np :)
<thumper> sinzui: what is up with the lander?  I see lots of rejections. Is there a common failure?
<sinzui> all are PANIC session closed thumper .  A bad test is blocking everyone's work
<thumper> fark
<sinzui> And it is happening with got test and got test -p 2
 * thumper sighs
<thumper> how did it get in
<thumper> ?
 * thumper runs tests locally to see if he can reproduce
<sinzui> thumper, it only has to pass intermittently to get in.
<thumper> sinzui: is it always the apiserver code?
<sinzui> thumper, Is it possible for the joyent provider to disable the default bootstrap timeout of 10 minutes? That is to say, I have killed procs that are 23 hours old. Bootstrap didn't give up
<sinzui> thumper, I think it is...I have never seen it to be any other case and it did appear with API a few weeks ago
 * thumper takes a wild stab in the dark and points at the presense code
<wallyworld> rogpeppe1: we use both hashes because william insisted on it :-) originally it was just md5 or sha256
<wallyworld> thumper: sinzui: we have been living with the intermittent failures till now since they were, well, vey intermittent. now it seems there's a much more serious issue we'll need to try anf fix asap
 * thumper nods
<thumper> wallyworld: I'm guessing it happens more under load
<wallyworld> part of the issue is the folks fixing it didn;t write the original code nor are mongo experts
<thumper> wallyworld: I don't see it much at all with my i7, and ssd
<wallyworld> me either
<thumper> I remember having to run tests while having other code in a compile loop to put my machine under load
<thumper> (in another project)
<wallyworld> thumper: the cloud on which the tests are run also seems to affect it somewhat, so it does seem to be a timing issue of some sort
<thumper> yeah
<thumper> I'm looking at the presense code now
 * thumper recoils
<thumper> type Presencer
<thumper> aarrggghhh....
<wallyworld> yep, i hate those names
<wallyworld> katco: meeting?
<katco> wallyworld: apologies... setting up canonical g+
<bodie_> anyone familiar with the uniter_test Steps in worker/uniter?
<wallyworld> np :-)
<katco> wallyworld: and again apologies for noise. we brilliantly scheduled air duct cleaning before i knew my start-date
<wallyworld> lol
<wallyworld> my laptop fan is very noisy
<thumper> wallyworld: I think I have found it
 * thumper double checks
<wallyworld> thumper: otp with katco
<thumper> hmm... maybe not
<katco> wallyworld: katherine.cox-buday@canonical.com
<katco> wallyworld: i'm so sorry i can't hear anything
<wallyworld> no worries
<katco> wallyworld: i muted you out of compassion ;)
<katco> i think they may be done with this section of the house momentarily
<wallyworld> that's what people say to me too
<katco> LOL
<bodie_> they sensed the frustration.. lol
<thumper> ugh....
<thumper> katco: welcome, just worked out who you were
<thumper> I think I have found a leak in some of my tests...
<bodie_> https://github.com/juju/juju/pull/199
<bodie_> any and all review would be appreciated, WIP
<bodie_> (Action running on unit)
<katco> thumper: thank you!
<ericsnow> do we use /etc/init/juju-db.conf anywhere?  (we are currently backing it up)
<sinzui> ericsnow, that is the upstart script to keep the service alive when the machine reboots
<ericsnow> sinzui: what creates it?
<sinzui> ericsnow, I onlt know from what I observe in QA. I think the act of bootstrapping creates both /etc/init/juju-db.conf and /etc/init/jujud-machine-0.conf
<ericsnow> sinzui: okay, thanks
<sinzui> ericsnow, issuing  kill -SIGABRT <pid> will terminate jujud and remove both upstart scripts
<wallyworld> wwitzel3: looking at branch now. just saw first line. be forewarned - me and thumper detest the apparent Go idiom of adding "er" to nouns to make stupid interface names :-P
<wallyworld> the worst case in our code base was/is Addresserer
<wallyworld> or something like that
<wallyworld> InstanceTyper isn't too bad though :-)
<wwitzel3> wallyworld: yeah thumper just talked about that in the Oynx standup .. I only did it because I thought I was supposed to :) .. I also think it is stupid
<wallyworld> :-)
 * wallyworld vomits
<wallyworld> wwitzel3: "capabilityer"
<wallyworld> lol
<wallyworld> that's gotta go
<thumper> haha
<mbruzek> Hiya thumper do you have a minute?
<thumper> mbruzek: ah... yeah
<mbruzek> I got an error that tvansteenburgh (lets call him Tim2) has also found.
<mbruzek> http://pastebin.ubuntu.com/7728552/
<thumper> wallyworld: it looks like I don't leak in the test like I thought, no idea why they are in the panic log of the tests...
<wallyworld> thumper: np, thanks for looking. we'll look today and try and sort it out
<thumper> mbruzek: what architecture
<mbruzek> We are both getting our deployments to fail on apt-get install  commands.  I spoke with Ben Howard about this and I understand it might be due to stale meta-data
<mbruzek> Tim2 is getting his on x86, but I am getting this same problem on Power systems.
<thumper> mbruzek: is samba ported to power? could be stale metadata
<thumper> looks like it should be there but isn't
<mbruzek> Once I ssh to the nagios/0 unit and run sudo apt-get update everything works fine.
<thumper> mbruzek: perhaps the install hook should do an update before trying to install
<mbruzek> thumper, I considered that, but I got this problem on a few charms.
<wallyworld> wwitzel3: looks solid. i don't think the client api needs to marshal the result to json though - that is done by the rpc layer if we just define a struct in params.go to hold the result
<thumper> I bet it is the local provider right?
<mbruzek> thumper,  yes on both architectures.
<bigjools> thumper: can you comment on this please? I think it's really a juju bug https://bugs.launchpad.net/maas/+bug/1335179
<_mup_> Bug #1335179: deploying containers to maas environment breaks with nic renaming <oil> <MAAS:Incomplete> <https://launchpad.net/bugs/1335179>
<thumper> mbruzek: right, in order to make machines boot faster, juju doesn't do apt-get update/upgrade when the machines are started any more
<wallyworld> wwitzel3: also, it would be ideal if this were a few branches - 1 for provider refactor, 1 for client calling code etc
<thumper> mbruzek: so deploying on to normal other machines, you wouldn't need the update
<thumper> as juju has done it already
<thumper> but the local hasn't
<thumper> and is likely stale
<mbruzek> thumper, how recently was this changed?
<thumper> months ago
<thumper> but only becomes apparent as new packages are put on the archives
<thumper> to make it stale
<wallyworld> wwitzel3: but git sucks for pipelines cf bzr so if you need to leave it all in one branch we can managed that
<thumper> it should probably be best practice for charms to do an update before installing packages
<thumper> as they can't be sure they are on a new up to date machine
 * thumper clicks on bigjools's bug
<mbruzek> marcoceppi, claims that breaks idepotentcy.  If you install today and apt-get update is called on config-changed several days later you could get a different (incompat) version.
<mbruzek> thumper, Is there a way to enable the apt-get update in cloud-init through juju ?
<mbruzek> I haven't tested all the charms, but I am guessing this is not isolated to 1 or 2 charms.
<thumper> mbruzek: the local provider explicitly doesn't
<thumper> mbruzek: ha, that is laughable, you don't get idempotency with juju charms
<thumper> mbruzek: you never will unless you use version pinning for everything you depend on
<thumper> sorry, but I'll argue with marcoceppi if I have to
<mbruzek> thumper, aside from that issue, what happens if we find that *many* charms have to be "re-written" to work around this issue?
<thumper> bigjools: you were right, juju bug not maas
<bigjools> thumper: ok thank you, can you retarget? :)
<thumper> mbruzek: then it should be documented as charm best practice
<thumper> bigjools: added bug target already
<bigjools> thumper: cool ta
#juju-dev 2014-07-01
<wwitzel3> wallyworld: ok, will fixup the er's .. I can probably do it as two branches, I will look in to that. As for the results, I already define a params.go to hold the result, so I can just store the value that I am marshalling in there instead of manually marshalling it and the RPC layer will do that for me?
<wallyworld> wwitzel3: i believe so yes
<wallyworld> the gui makes other api calls which just return the structs
<wallyworld> wwitzel3: don't waste time on 2 branches if it's too difficult to split out. bigger branches can be harder to land though since one bit might be ok but other bits may need fixes and the ok bit can't land separately
<wallyworld> wwitzel3: also, don't forget to add SupportedArchitectures to the results
<wwitzel3> wallyworld: I actually removed it, since it is send along with each instanceType
<wwitzel3> sent
<wallyworld> we also need to handle that some providers can not supply InstanceTypes but do have SupportedAchitectures etc
<wallyworld> oh, let me look
<wallyworld> wwitzel3: i think we need supported arches as an explicit field since otherwise the caller will have to iterate over the instance types and pull out the arches, also not all providers will suport returning instance types but will be able to supply supported arches
<wwitzel3> wallyworld: which ones? I didn't see that, it is easy to re-add them as their own top level key in the map
<wallyworld> manual provider for example
<wallyworld> maas also
<wallyworld> the supported arches value will be used to guide the user in creating vlid constraints with arch=blah
<wwitzel3> ahh ok
<wwitzel3> should I still include it with the instanceType data?
<wallyworld> no, it is a separate concept
<wallyworld> each provider has a SupportedArchitecures() api
<wwitzel3> wallyworld: right, I just notice that InstanceType had an Arches field and it was the same type as the return value of SupportedArchitectures()
<wallyworld> wwitzel3: yes, that's right. for ec2 (only i think), instances can run on i386 or amd64. i think for all other providers instance types run on one arch
<wallyworld> so we record for individual instance types what arch(es) that instance type can run on
<wwitzel3> wallyworld: ok, so that needs to be specific to the instance, not the provider level SupportedArchitectures()
<wallyworld> no, it's at the provider level
<wallyworld> the supported rches for the provider comes from reading the simplestreams image metadata
<wallyworld> and adding together all the arches listed
<wallyworld> so that the system can disallow arch=foo constraints for arches for which there is no available image
<wwitzel3> wallyworld: right and that is different than the supported arches for an instance
<wallyworld> wwitzel3: yes, so when an image is chosen, it needs to be matched up with an instance type and the arches also need to match there too
<wwitzel3> wallyworld: right, so really what I am doing now in the API InstanceType.Arches = provider.SupportedArchiectures() is wrong, I need to move supported up to its own field and only populate Arches from the specific provider instance/package/flavor response
<thumper> wallyworld: found one leak
<wallyworld> wwitzel3: so when the user says mem=64G arch=i386, the matching finds an i386 image from simplestreams and then looks at all the instance types which can provid 64G which can run on i386
<wallyworld> wwitzel3: you don't really need all the instance type data - just the valid names
<wallyworld> wwitzel3: the gui only cares about knowing what instance type names are valid
<wwitzel3> wallyworld: oh, ok, so I'll just drop it from the results then and move supportedArchiectures up to its own field
<wallyworld> i guess we could return all the instance type data
<wallyworld> not just the names
<wallyworld> but names is all that's needed for now
<wallyworld> and regardless, yes, we do need supported aches as top level field
<wwitzel3> wallyworld: sounds good
<wallyworld> wwitzel3: since we have api versioning, let's start with just names, and add stuff later if needed
<wwitzel3> wallyworld: also if you have any suggestions of where I should look to create a proper testing env to exercise this code that would be helpful.
<thumper> maybe not...
<thumper> geez
<wwitzel3> wallyworld: well I already have all the other stuff in there, but I can remove it if you prefer
<wallyworld> wwitzel3: i'm wary of yagni
<wallyworld> and the extra testing, maintenance etc for stuff thats not used
<wallyworld> wwitzel3: which bit specifically do you need help testing? the client calls?
<wallyworld> thumper: be with you in a sec
<wwitzel3> wallyworld: yes, starting from state/api .. the env I am creating is throwing nil pointer exceptions because it doesn't have the InstanceTypes method or AvailabilityZones methods .. but I've added them to the dummy provider ..
<wallyworld> wwitzel3: i normally add an assertion that a struct implements an interface so i get a compile time error if i haven't got the right methods eg var _ environs.EnvironProvider = (*environProvider)(nil)
<wwitzel3> wallyworld: https://github.com/wwitzel3/juju/commit/e1598a5300cd20c4c23c02e09952d1b6136fdad3 here is my broken test if that helps
<wallyworld> the above says that the environProvider struct implements the EnvironProvider interface
<wallyworld> and it won't compile if it doesn't
<wallyworld> we have a bunch of those in the various providers
<wwitzel3> wallyworld: ok
<wallyworld> since there's several interfaces that can be implemented
<wallyworld> wwitzel3: dummy provider has these already
<wallyworld> var _ imagemetadata.SupportsCustomSources = (*environ)(nil)
<wallyworld> var _ tools.SupportsCustomSources = (*environ)(nil)
<wallyworld> var _ environs.Environ = (*environ)(nil)
<wallyworld> i can't see trivially what's wrong with your implementation
<wwitzel3> wallyworld: ok, thanks, I'll keep poking at it
<wallyworld> wwitzel3: thank you. let me know how you go
<wwitzel3> wallyworld: your tip help, added common.EnvironCapabilities like you mentioned and it revealed that the dummy provider wasn't properly implementing the interface
<wallyworld> cool :-)
<wwitzel3> wallyworld: I guess now I actually have to write some tests that assert something useful
<wwitzel3> bugger :P
<wallyworld> lol yeah
<thumper> wallyworld: chat when you have a minute
<wallyworld> thumper: sure, 2 mins
<davecheney> https://github.com/juju/juju/pull/195
<davecheney> i am blocked on this review
<thumper> wallyworld: https://github.com/juju/juju/pull/201
<wallyworld> thumper: https://plus.google.com/hangouts/_/canonical.com/tanzanite-daily
<axw> wallyworld: gonna spend some time today looking into test failures
<axw> clearly something is very broken
<wallyworld> axw: hey, yes please, i was going to ask you to do that. thumper already has one fix landing https://github.com/juju/juju/pull/201
<axw> cool
<menn0> axw: I'm just testing that precise upgrades fix now
<axw> menn0: cool, thanks
<davecheney> grr, version package
<wallyworld> axw: also, don't forget to backport stuff to the 1.20 branch eg i think the ssh timeout fix was proposed for master only
<davecheney> wallyworld: should i move version.SeriesVersion so it is only visible when compiled on linux ?
<axw> wallyworld: I've been waiting for them to merge into master first. I guess I'd better do it now before I forget
<wallyworld> axw: np :-)
<wallyworld> davecheney: it's needed on other clients too
<wallyworld> to set up ubuntu workloads using custom image metadata
<davecheney> wallyworld: that is a problem
<davecheney> how can I run it on osx ?
<davecheney> fuckit
<davecheney> i'll just remove that comment
<wallyworld> davecheney: see my comment?
<davecheney> yup
<wallyworld> it can run
<davecheney> i'll just remove my comment on that function and back away
<axw> ;)
<wallyworld> why not just make the trivial change i suggested?
<wallyworld> then it can run on other clients
<davecheney> looked harder than just backing out a comment I wrote that was a mistake
<davecheney> my comment was in error
<davecheney> i have deleted it
<wallyworld> sure, but it seems like there's a legitimate problem there that is trivially fixable
<wallyworld> so lets just fix it
<davecheney> wallyworld: i'll fix it in a followu
<wallyworld> ok
<davecheney> the goal is to fix 1.20
<wallyworld> i didn't think this was broken in 1.20
<davecheney> wallyworld: i am only going on the reports I have been given
<wallyworld> the 1.20 branch was forked of master before this change?
<davecheney> i cannot validate the problem or the fix myself
<wallyworld> i could be wrong
<wallyworld> let me check
<menn0> axw: did this make it in to 1.20 as well? https://github.com/juju/juju/pull/188
<menn0> axw: my manual upgrade test worked fine btw
<axw> menn0: sweet. not yet, I've just created a PR and sent it to the bot now
<menn0> axw: great, just making sure
<axw> menn0: thanks for testing
<wallyworld> davecheney: 1.20 was forked for trunk right before that os_version change that broke stuff
<wallyworld> so any fixes just need to go to trunk
<wallyworld> axw: once stuff lands in 1.20, mark the bugs as fix committed as well
<wallyworld> i think there are 2 branches for bug 1334273
<axw> wallyworld: will do
<_mup_> Bug #1334273: Upgrades of precise localhost fail <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged by axwalk> <juju-core 1.20:Triaged by axwalk> <https://launchpad.net/bugs/1334273>
<axw> wallyworld: yep, there's one more coming for 1.20
<menn0> axw: I've tested the 1.18.4 to 1.19.5 upgrade on precise 3 times now and all looks well
<wallyworld> \o/
<axw> menn0: awesome
<davecheney> wallyworld: i don't understand
<wallyworld> how can i help?
<davecheney> wallyworld: dunno, does 1.20 cli work on windows ?
<davecheney> if so, job done
<wallyworld> it should i think since the landings to trunk which broke things happened after 1.20 was forked
<wallyworld> but
<wallyworld> even on 1.20, if SUpportedSeries is called on bootstrap, it will fail
<davecheney> wallyworld: the bug i have is 1.20 cli doesn't work on windows
<davecheney> i cannot validate this muself
<davecheney> only go on the bug report I have
<davecheney> and at the moment, things are getting less clear by the second
<wallyworld> hmmm. i don't know about that then. perhpas that bug was raised before the decision was made to branch 1.20 off an earlier rev from master
<wallyworld> we'd need to check with curtis
<davecheney> sinzui: ping ?
<wallyworld> davecheney: what bug number?
<davecheney> lp # 1334493
<_mup_> Bug #1334493: Cannot compile/exec win client <regression> <windows> <juju-core:Fix Committed by dave-cheney> <https://launchpad.net/bugs/1334493>
<wallyworld> davecheney: that bug is not marked as affecting 1.20
<wallyworld> it was taken off 1.20 on the 28th
<davecheney> wallyworld: mate all I can tell you is what is in the bug
<wallyworld> i'm guessing that's when the 1.20 branch was cut off an earlier rev before that bug was introduced
<davecheney> somethigns broken
<davecheney> i fixed something
<davecheney> maybe it helped
<davecheney> the bug was introduced in https://github.com/juju/juju/pull/95/files
<wallyworld> davecheney: sure, but look at the affected series - 1.20 was removed
<davecheney> which was 17 days ago
 * thumper has father in law drop in for a quick visit
<davecheney> thumper: is that a euphamism for something ?
<lifeless> boom tish
<wallyworld> davecheney: 1.20 was forked before that rev from what i can tell, which is why the bug was changed to no longer affecting it
<davecheney> 1.20 was forked on the 15th of June ?
<davecheney> really ?
<wallyworld> no
<wallyworld> last common rev was merging pull reuqest 160
<wallyworld> i think your date is a bit out
<wallyworld> pr 160 was 5 days ago
<davecheney> wallyworld: oh
<davecheney> you are right
<davecheney> i am sorry
<wallyworld> np
<davecheney> i was lookig at the first comment on that PR
<davecheney> not when it finally merged
<davecheney> so
<davecheney> ok
<davecheney> so 1.20 isn't broken and trunk isn't blocked then
<wallyworld> so, i *think* that bug was originally raised as affecting 1.20, and then retracted
<wallyworld> yes, 1.20 is good, trunk not blocked
<davecheney> phew
 * wallyworld is not 100% sure the issue is fixed on trunk, but seems to be
<wallyworld> with the pr to be merged
<davecheney> ok, here's the plan
<davecheney> i'll merge this one
<davecheney> then i have a followup waiting on it that adds more tests
<wallyworld> ok
<davecheney> we can keep the fun going there
<davecheney> deal ?
<wallyworld> deal, thanks :-)
<davecheney> \o/
<wallyworld> sorry for confusion
<davecheney> nope
<davecheney> it was my fault
<wallyworld> np
<thumper> wallyworld: I guess my branch didn't fix the panic
<thumper> wallyworld: sorry...
<wallyworld> thumper: hey, thanks for trying. you did a lot of good fixes regardless
<thumper> oh fark...
 * thumper had an annoying thought
<thumper> menn0: are you around to chat?
<menn0> thumper: yep
<menn0> thumper: hang out?
<thumper> menn0: yeah
<menn0> thumper: https://plus.google.com/hangouts/_/gy36zsk3j2lx4ffgfvotsvzxmya
<wallyworld> thumper: did you foresee a charm's resources directory on disk being a flat list of files?
<wallyworld> i'd think we'd want a dir heirarchy
<thumper> wallyworld: yes...
<wallyworld> hmmm
<thumper> it was strongly suggested that the dir be flat by the time a charm hook is using it
<wallyworld> by whom? our fearless leader?
<wallyworld> thumper: also, there seem to be devel and stable streams. but what about charm revisions? would we have a stream for each revision, or namespace the resources under each stream by revision?
<wallyworld> axw: do my eyes deceive me, your branch landed
<axw> wow, first attempt
<thumper> wallyworld: charm revisions are independent of stream revisions
<thumper> wallyworld: the full charm version would then be "charm revision - stream - stream revision" tuple
<thumper> all mashed together into a string
<thumper> that was the idea anyway
<davechen1y> umm
<davechen1y> https://github.com/juju/juju/pull/195
<davechen1y> the bot ate my merge requst
<wallyworld> looks like our landing instance might have gone down
<wallyworld> it was processing a pr and got interrupted
<axw> weird, mine too
<wallyworld> hmmm, and now the lander says no pull requests to merge
<axw> wallyworld: it thinks it's still processing them
<axw> gotta add a "Build failed: whatever" message
<wallyworld> i'll poke around and see if i can find out where it keeps its in progress queue
<axw> wallyworld: it's dumb, it just checks for "Status: merge request accepted." and then a "Build failed:"
<wallyworld> oh wait, i see what you're saying
<wallyworld> sigh
<axw> I think what we should do is add a link to the Jenkins job, so the the lander can periodically check the status of the jobs it thinks are running
<wallyworld> yep, let's talk to martin about it
<axw> atm we just get a link to the job type, but not the actual run
<axw> until it fails anyway
<davechen1y> so, should i $$merge$$ again ?
<axw> davechen1y: already done
<davechen1y> thanks mate
<davechen1y> can someone kill this job
<davechen1y> http://juju-ci.vapour.ws:8080/job/github-merge-juju/310/console
<davechen1y> it's not going to pass
<wallyworld> gooone
<davechen1y> today is giving me the shits
<wallyworld> yeah :-(
<davechen1y> win12
<axw> wallyworld: https://github.com/juju/juju/pull/205
<wallyworld> looking
<davechen1y> # github.com/juju/juju/state
<davechen1y> state/action.go:86: too many arguments in call to names.NewActionTag
<davechen1y> state/state.go:1389: tag.UnitTag undefined (type names.ActionTag has no field or method UnitTag)
<davechen1y> state/state.go:1390: tag.Sequence undefined (type names.ActionTag has no field or method Sequence)
<davechen1y> is anyone seeing this on master ?
<davechen1y> yes, i've run godeps
<axw> davechen1y: I was before I ran godeps
 * axw tries again
<davechen1y> lucky(~/src/github.com/juju/juju) % godeps -u dependencies.tsv
<davechen1y> "/home/dfc/src/github.com/juju/names" now at b2e06a0ab1c09f138853d1ef6b11f94ca9f7b675
<davechen1y> commit 780947ad0e66382af782c65eec6b86796409f0c7
<davechen1y> Author: Roger Peppe <rogpeppe@gmail.com>
<davechen1y> Date:   Thu Jun 26 15:46:34 2014 +0100
<davechen1y> use earlier names dependency
<davechen1y> umm
<davechen1y> why ?
<axw> no problems here
<davechen1y> axw: what sha do you have for juju/names ?
<axw> b2e06a0ab1c09f138853d1ef6b11f94ca9f7b675
<davechen1y> ta
<davechen1y> oh fuck
<davechen1y> godeps is broken
<davechen1y> lucky(~/src/github.com/juju/juju) % godeps -u dependencies.tsv
<davechen1y> "/home/dfc/src/github.com/juju/names" now at b2e06a0ab1c09f138853d1ef6b11f94ca9f7b675
<davechen1y> lucky(~/src/github.com/juju/names) % git log | head -n2
<davechen1y> commit d6e9f06b936da18e4feeef3e788bf0dde0cc2d99
<davechen1y> Merge: 01e6ac7 f52c443
<davechen1y> greap, godeps doens't work
<davechen1y> great, that's fucking great
<davechen1y> now the new version of godeps
<davechen1y> lies
<davechen1y> rather than telling you it can't find that rev
<axw> hmm. I'm sure it failed for me last time I didn't specify -f
<davechen1y> à² â­â®à² 
<davechen1y> axw: i recently upraded to rog's new version
<davechen1y> imma gonna downgrade again
<axw> davechen1y: yeah I'm on the new version too
<davechen1y> it didn't work for me
<axw> unless there' a new new version
<davechen1y> it kept saying "i've updated"
<davechen1y> but it didn't
<davechen1y> see above
<davechen1y> shit .
<davechen1y> axw: https://github.com/juju/juju/pull/206
<davechen1y> https://github.com/juju/loggo/pull/2
<davechen1y> there are SO MANY races in the apiserver package
<mattyw> morning all
<axw> davechen1y: sorry went to pick up my daughter. looking now
<axw> davechen1y: does the detector pick them up? didn't find any last time I ran it
<axw> mattyw: morning
<mattyw> axw, thanks for taking a look at my branch - sorry about putting the wrong bug link
<mattyw> A few minutes before I wrote that I commented on the wrong bug in lp as well
<axw> mattyw: that's ok, I figured it out from the commit description :)
<davechen1y> axw: it does, if you're persistant enough
<davechen1y> http://paste.ubuntu.com/7730028/
<axw> davechen1y: ah, thanks
<davechen1y> PR's for both in play
<axw> sweet
<voidspace> morning all
<mattyw> morning
<davechen1y> axw: shit
<davechen1y> that race is worse than I thought
<axw> davechen1y: which one?
<vladk> dimitern: ping
<dimitern> vladk, pong
<davechen1y> axw: the one on the loggo/TestLogWriter
<davechen1y> axw: i'm fixing it now
<axw> davechen1y: ah, I see.
<axw> hrm, thought I fixed that.. maybe it was a similar case
<vladk> dimitern: I wrote a test for WatchInterfaces API client, It gives a 5 sec delay between state modification and notify signal
<vladk> dimitern: test is working fast on API server, but with delays on API client
<davechen1y> axw: i cna't see a way we can assert that the TestLogWriter is single threaded
<axw> davechen1y: perhaps just call loggo.RemoveWriter before ranging over tw.Log
<davechen1y> axw: fuck it, i've gone and made tw.Log a function that returns a copy of writer.Log
<axw> okey dokey
<dimitern> vladk, probably the statetesting code used for the watcher need tweaking a bit - can i have a look?
<davechen1y> if it's worth doing; it's worth over doing
<axw> less band-aid-ish
<axw> sgtm
<davechen1y> axw: PTAL
<davechen1y> this will need some work to integrate into juju and other callers
<fwereade> vladk, look for BackingState and StartSync it once you're sure there's a notification waiting
<fwereade> vladk, (even if that's not *directly* applicable, the point is that the *State that's driving the api server needs to be synced -- and that's not necessarily the *State you're usually manipulating in the tests)
<dimitern> fwereade, statetesting does that internally for the Assert methods
<dimitern> ..IIRC
<fwereade> dimitern, indeed, but it's not necessarily using the right *State
<fwereade> dimitern, and if you're using the wrong one you'll see those 5s delays
<dimitern> fwereade, right
<davechen1y> ttps://bugs.launchpad.net/juju-core/+bug/1336180
<_mup_> Bug #1336180: state/apiserver: yet more data races <juju-core:In Progress by dave-cheney> <https://launchpad.net/bugs/1336180>
<dimitern> fwereade, vladk, it uses c.State.StartSync()
<fwereade> dimitern, vladk: so it *should* just be a matter of starting it with s.BackingState, if that's accessible; and figuring out how to set one up if it's not
<vladk> dimitern, fwereade: https://github.com/juju/juju/pull/207
<dimitern> vladk, line 278 in networker_test.go - use s.BackingState instead of s.State for NewNotifyWatcherC
<dimitern> (and in other similar cases)
<TheMue> morning
<TheMue> *yawn*
<vladk> dimitern: thanks, that works, could you review my PR
<dimitern> vladk, will do in a bit
<voidspace> dimitern: so a network interface always has a subnet (in the juju model)
<voidspace> dimitern: what's the default subnet?
<voidspace> dimitern: and why do we reference count networks?
<dimitern> voidspace, sorry, in a call, will get back to you a bit later
<voidspace> dimitern: no problem
 * fwereade bbiab
<mattyw> is juju-bot on holiday today?
<dimitern> voidspace, back
<dimitern> voidspace, so there are two default networks - juju-private and juju-public (if available)
<dimitern> voidspace, they are discovered and created at bootstrap time, if the provider supports that
<dimitern> voidspace, we use refcounts for networks, because they can be referenced by services and/or machines (i.e. they are considered in-use, when the refcount>0)
<dimitern> voidspace, removing networks in use is not allowed; refcounts are used as a simple sanity check on the same doc as the network, as opposed to checking multiple documents in other collections
<mattyw> axw, are you still awake/ working?
<axw> mattyw: I am here
<axw> the bot is not on holiday, it's just a bit sick
<axw> mattyw: which PR are you trying to land?
<mattyw> axw, https://github.com/juju/juju/pull/108
<mattyw> axw, but I was going to ask you about this one: https://github.com/juju/juju/pull/198/
<dimitern> vladk, reviewed
<axw> mattyw: nfi why it didn't pick that up...
<axw> mattyw: ask away
<mattyw> axw, just wanted to make sure I understand your feedback properly
<mattyw> axw, do you mean if you specifiy add-machine -n you shouldn't be able to specify lxc:2 as well?
<axw> mattyw: right
<axw> mattyw: just like with "juju deploy", which doesn't allow you to do --to and -n together
<mattyw> axw, deploy uses the UnitCommandBase stuff for all of that, I did wonder if I should be using something generic to provide the -n flag, but I figured it probably wouldn't be worth it, I guess I should just implement the same logic in AddMachineCommand.Init?
<axw> mattyw: yeah I think so
<mattyw> axw, also I wasn't sure if I should just be sending a list of items to the existing AddMachine api call - or making a new api that would take a NumMachine int, do you have an opinion either way?
<TheMue> one small command change for review: https://github.com/juju/juju/pull/208
<axw> mattyw: I think a list makes sense
<voidspace> dimitern: thanks
<voidspace> dimitern: but, I was asking specifically about subnets
<voidspace> dimitern: every network must have a subnet
<dimitern> voidspace, yes
<voidspace> dimitern: so what is the "default subnet"?
<dimitern> voidspace, a subnet of the default network
<voidspace> dimitern: specifically
<voidspace> dimitern: what will the netmask be
<voidspace> dimitern: how do we determine it
<dimitern> voidspace, the provider will implement ListNetworks() and/or ListSubnets(), depending on what's supported, and tell us
<voidspace> dimitern: heh, so for local provider then
<dimitern> voidspace, in network.BasicInfo struct used as result will have an IsDefault field
<voidspace> dimitern: what does the implementation of ListSubnets do? or what if the provider doesn't support subnets
<voidspace> dimitern: what will we use as the default
<dimitern> voidspace, local and manual are special (yet undefined fully wrt networking)
<voidspace> dimitern: I just wonder if the concept of "you have to have a subnet" really reflects reality
<voidspace> dimitern: and for refcounts, it seems to be the case that we want refcounts in order to destroy networks
<dimitern> voidspace, there are SupportsNetworks() and there will be SupportsSubnets() as well, which each provider implements to tell juju what it can handle, and we call ListSubnets/Networks or both accordingly
<voidspace> dimitern: i.e. know when they are not references
<voidspace> dimitern: (sure, but as a network *must* have a subnet I wonder what we do if the provider doesn't support subnets - what is "the default")
<dimitern> voidspace, read the doc :)
<voidspace> dimitern: why do we need to destroy networks? as they're abstract concepts, what's the cost in just leaving them around
<voidspace> dimitern: I am!
<voidspace> dimitern: these are questions that don't *appear* to be easily answered
<dimitern> voidspace, when the provider does not support subnets, but supports networks, we simulate a subnet by splitting the network.BasicInfo into a network + subnet
<voidspace> dimitern: right, I'm asking what the subnet part is
<voidspace> dimitern: it's quite likely that my understanding of the basic concept is flawed
<dimitern> voidspace, CIDR + VLANTag (optional) + AvailabilityZone (if applicable) + ProviderId (if applicable) + IsDefault
<dimitern> voidspace, sorry, not the last thing
<voidspace> dimitern: but doesn't a subnet mask off part of the ip range
<dimitern> voidspace, a network does not specify a CIDR range, it's a collection of subnets with a name
<voidspace> dimitern: so do we simulate it by having a 0.0.0.0 netmask
<dimitern> voidspace, sure, for example 172.20.0.0/16
<voidspace> dimitern: so a network from a provider comes with *a subnet* as part of the specification
<dimitern> voidspace, if the provider does not support subnets, only networks, and what we get from the provider contains 0.0.0.0/0 as CIDR, that's the "catch-all" case - everything goes
<voidspace> dimitern: "not supporting subnets" just means we can't create new subnets, but there will always be a default
<voidspace> dimitern: ok, fair enough
<dimitern> voidspace, take MAAS as an example
<voidspace> dimitern: ok
<dimitern> voidspace, it supports networks, which have a label, CIDR, VLANTag and list of connected MACs
<dimitern> voidspace, so even if subnets are not supported, we have all the info we need from the network to create a subnet for it
<voidspace> dimitern: ok, cool
<dimitern> (not supported as "there's no such api-accessible entity for juju to handle)
<voidspace> dimitern: much appreciated, thanks
<dimitern> (effectively, there will always be some subnet involved, but we might not be able to know which, if the provider does not tell us - like manual and local)
<dimitern> voidspace, np, glad you're asking the right questions :) i'll update the model doc some more today, including some clarifications around default networks, as discussed with fwereade
<voidspace> great
<jam1> voidspace: so to put it from my view, (just in case), we model it as having a subnet, even if that subnet just matches the whole network
<voidspace> jam1: right - that specifically wasn't clear (to me) from the doc. That in order to match our model we might create a subnet that "just matches the whole network"
<voidspace> jam1: I guess it's implied...
<fwereade> voidspace, we refcount networks so we can know when to delete them
<dimitern> voidspace, jam1, vladk, TheMue, I'm sorry I might miss the standup due to an unexpected minor emergency, will join later if it's still going
<fwereade> voidspace, when we *can* delete them, rather
<voidspace> fwereade: right, I wonder why we want to delete them
<fwereade> voidspace, if they can be added, we should be able to remove them, I think
<TheMue> dimitern: ok, hope itâs not to bad
<TheMue> too
<jam1> dimitern: np, take care of your stuff
<jam1> voidspace: dimitern: I have the feeling it was in an earlier draft...? I thought I had read it in the subnet section.
<voidspace> fwereade: in general I suppose I agree, refcounting can be a fair amount of work/hassle to get right
<voidspace> jam1: I will read again (just gone back for a reread anyway)
<fwereade> voidspace, refcounting *is* a hassle
<voidspace> jam1: maybe I just missed it
<voidspace> fwereade: :-)
<jam1> voidspace: I don't see it in my quick searching.
<fwereade> voidspace, but peculiarities of the mgo/txn model mean that it's the only tool we really have
<jam1> Probably worth adding to the subnet/network sections somehow. As EC2 doesn't really have a Network model, just subnets, and MaaS doesn't have Subnets, just a Network.
<jam1> speaking of which, TheMue, voidspace, vladk: standup?
<fwereade> voidspace, in particular, we can only do asserts against specific documents
<fwereade> voidspace, so there's no way to assert that "no service uses this network", for example
<voidspace> fwereade: right
<TheMue> jam1: coming, only quick jump to the bath ;)
<voidspace> oh for a relational query I guess...
<jam1> TheMue: ??
<fwereade> voidspace, well we can do queries just fine
<fwereade> voidspace, but we can't use them in txn asserts
<mattyw> axw, don't suppose you're still around?
<voidspace> fwereade: ah, I see
<perrito666> gsamfira: ping?
<gsamfira> hey
<perrito666> sorry I got here a bit late, are you in today?
<gsamfira> yup, but It will be a short day for me.
<gsamfira> I'm in the hangout
<perrito666> gsamfira: william and I are there too and we dont see you
<perrito666> :)
<gsamfira> hmm
<gsamfira> can you give me the link?
<perrito666> certainly
<perrito666> https://plus.google.com/hangouts/_/canonical.com/cloudbase?authuser=3
<axw> fwereade: can you confirm that we no longer need git in juju? we can remove it from our cloud-config?
<axw> (I just deployed ubuntu to azure without git installed, and it worked... not sure what else I'd need to test)
<ahasenack> axw: doesn't juju bootstrap install it?
<axw> ahasenack: it does, I want to remove it
<axw> and more importantly, not require it in windows bootstrap
<ahasenack> axw: while you wait for an answer, try an experiment. In a deployed unit, remove git, make a silly change to the charm and run juju upgrade-charm
<ahasenack> axw: or, go to /var/lib/juju/.../..../(don't remember)/charm, see if it's a git repo
<axw> ahasenack: thanks
<axw> I'll try that
<vladk> dimitern: I fixed your notices in https://github.com/juju/juju/pull/207
<dimitern> vladk, cheers, looking
<dimitern> vladk, LGTM
<vladk> dimitern: thanks
<jam1> TheMue: proposal reviewed
<TheMue> jam1: thx
<TheMue> jam1: yeah, will add a follow-up for those tests
<dimitern> fwereade, g+?
<mattyw> does anyone know what juju-bot hates me? https://github.com/juju/juju/pull/108
<perrito666> mattyw: well he seems to be hating axw too
<sinzui> mattyw, perrito666 That looks like it was caused by my attempt to move testing to its dedicated server
<sinzui> I am requeuing the tests
<katco> hello team :)
<wwitzel3> morning katco
<perrito666> hey, are we having stdup?
<katco> is that a question for me?
<sinzui> mattyw, your PR isn't among the ones that got rejected by the git-merge-juju job
<mattyw> sinzui, afaik it's not even attempted to land yet
<wwitzel3> perrito666: yes :)
<mattyw> sinzui, juju-bot has certainly never told me it accepted a request to merge
<sinzui> mattyw, I see you are a public member of the juju org, which is enough for the bot to know your $$merge$$ is good
<mattyw> sinzui, it certainly worked before
<sinzui> I see axwalk also tried to intercede.
<sinzui> mgz, ^ the bot hates mattyw. Can you broker a peace?
<mattyw> no treaty - just an armistice is ok
<mgz> teh bot is in an unhappy place
<mgz> we also have a massive queue, which is partly because nothing has eben lading, but if I get the switch to your dedicated job done sinzui that'll be sorted at least
<sinzui> mgz, I think we need to configure git on that machine to.
<sinzui> maybe you have
<mgz> sinzui: yeah, I need to do some sample runs to check
<sinzui> mgz, have you started lxc containers instead of ami instanced? I am very keen to get to it?
<mgz> I've been trying it out, but just locally
<sinzui> mgz, I can add lxc support to run-unit-tests within the next 24 hours. Do you intend to use clone?
<mgz> I'd really like to
<sinzui> mgz, I gave up hunting for a utopic AMI, so I switch the utopic unit tests to run directly on the utopic slave. I worry that I will have janitorial duties until something like lxc is available
<mgz> hmmm
<sinzui> mgz, I will add command support for lxc, setup and teardown. I doubt I can help in the creation the the template or change the test suite to like lxc envs
<sinzui> mgz, and you want test ./... || test -p  2./... ?
<mgz> sinzui: I think we need it for now, but it's not helping much today...
<sinzui> mgz, not many branches pass when -p 2 is needed. I thought fixing the "panic session closed" bug would make -p 2 better
<wwitzel3> ericsnow, perrito666: https://github.com/wwitzel3/juju/compare/013-environment-info-api
<katco> small milestone; got some charms deployed locally! :)
<katco> however, it seemed to take a long time for wordpress to start (10ish minutes). is that normal?
<mgz> katco: with the local provider? probably, it may well be faster for you second time
<katco> mgz: does jujud do any sort of caching of charms?
<mgz> it does, but it was the lxc setup I was thinking of
<katco> ahhh
<katco> thank you :)
<voidspace> jam1: ping
<jam1> voidspace: not usually when I'm around, but I happen to be today, what can i help you with?
<voidspace> jam1: I thought I'd give it a try... you seem to work about 18hours a day usually
<jam1> voidspace: :)
<voidspace> jam1: you suggested that to change mongo to use ipv6 in our test suite that testing/mgo.go would be a place to start
<jam1> that was my thought, yes
<voidspace> jam1: this is now a thin wrapper around gitjujutesting/mgo.go (or whatever it's called - horrible package name)
<voidspace> jam1: it *starts* mongo, but it's open.go that handles the connection
<voidspace> jam1: how did you have in mind changing the connection just for tests?
<voidspace> jam1: where you thinking of binding to :: specifically (I'm hoping we don't need to do that and mongo will allow either - but I need to check)
<jam1> voidspace: So it looks like (as you notice) the old github.com/juju/juju/testing got pulled out into github.com/juju/testing/ but there is still the mgo.go file, they did alreayd remove --bind_ip
<jam1> but they are'nt passing '--ipv6' for mongo
<voidspace> jam1: I thought it just used inst.run() to start it... I obviously need to look better
<jam1> voidspace: thati s where it passes the args
<jam1> MgoInstance.run needs to pass "--ipv6"
<voidspace> jam1: gah, ok
<voidspace> jam1: sorry, being dumb
<jam1> voidspace: http://docs.mongodb.org/manual/reference/program/mongo/#cmdoption--ipv6
<voidspace> yeah, I've added that in the actual code and the tests all pass
<jam1> voidspace: presumably as long as we do that, mongo will be happy to start and bind to both networks
<voidspace> yeah, I need to specifically test that
<voidspace> jam1: for some reason I thought inst.run() called our standard code for starting mongo
<jam1> voidspace: the other bit is that mongo seems to report "mongod:PORTNUM" for output and we wait to see that.
<voidspace> not sure why I thought that...
<jam1> voidspace: I could see why it you'd think so, certainly it would make more sense if it was shared code
<mgz> alexisb: you vanished
 * perrito666 notices that he should get food before the football game starts or he will not have food until after
<katco> perrito666: which game?
<perrito666> katco: apparently my country (ARG) against.. some other country :p
<katco> haha
<TheMue> perrito666: SWI, directly south to GER (which won yesterday)
<perrito666> katco: that produces eigher a) food places closing or b) cook spitting into my food
<katco> good luck to them :)
<ericsnow> katco, perrito666: obviously perrito666 is a real patriot ;)
<katco> haha
<perrito666> TheMue: I know where SWI its, I did not know that its the team against ARG
<katco> i'm recording the US v Belgium game
<TheMue> perrito666: imho ARG will do it, but it wonât be simple
<perrito666> ericsnow: I pay taxes and have the flag on flag day, I dont mind that much about sports
<perrito666> TheMue: well our politicians will have problems, bc they have their hart in ARG but their money in SWI
<TheMue> katco: there USA will win, the second GER team in this championchip *lol*
<ericsnow> perrito666: next you'll tell me you don't tango ;)
<katco> TheMue: i haven't heard it put like that lol. it's true!
<TheMue> perrito666: thatâs a problem of many politicians (and industrials)
<katco> i hope they win
<perrito666> ericsnow: I dont, requires far more motor ability than I have
<ericsnow> perrito666: eh, I don't dance well either
 * ericsnow doesn't like where this conversation is heading
 * TheMue has to admit he absolutely failed when learning tango once in the past
 * katco often wonders if she's the only lady with no dancing skills whatsoever
<perrito666> ericsnow: assuming all Argentinans know how to dance tango is like assuming every oriental person knows martial arts
<perrito666> katco: oh no, my wife and I cannot put one step together
<TheMue> katco: no, my wife neither
<perrito666> lol
<TheMue> perrito666: h5
<katco> lol :D
<ericsnow> perrito666: so true
<ericsnow> katco: alas, my wife has a degree in dance
<katco> ericsnow: oh how neat :)
<perrito666> ericsnow: I lack practically all required skills to be Argentinian.
<mgz> perrito666: you have the funny tea drink thing skilz right?
<wwitzel3> haha
<perrito666> mgz: I do :p
<wwitzel3> that's all you need
<ericsnow> perrito666: ah, but you have mate so it's okay :)
<mgz> you'll need to do a demo next week
<perrito666> mgz: I usually prefer not to go trough the hassle of explaining frontier authorities what is that green herb I carry and why is there a metallic tube on my baggage
<mgz> :D
<ericsnow> mgz: amazon carries everything you need: http://www.amazon.com/Taragui-Yerba-Mate-Bombilla-Leather/dp/B007V650EM/ref=sr_1_1?ie=UTF8&qid=1404226489&sr=8-1&keywords=mate+cup
<perrito666> ericsnow: with a bit overprice :p but yes
<perrito666> you also need a thermos
<perrito666> or something that keeps water hot
<ericsnow> perrito666: :)
<rogpeppe1> fwereade: have you got a link to a doc for the specification for charm resources/blobs, by any chance,?
<rogpeppe1> jam1, mgz, voidspace, wwitzel3: ^
<rogpeppe1> i've *heard* about the "streams" stuff, but i don't think i've seen it written down
<voidspace> rogpeppe1: afraid not, sorry
<rogpeppe1> voidspace: thanks
<ericsnow> speaking of blobs, we have 2 (soon 3) API client methods that deal with sending/receiving binary blobs over RPC...
<ericsnow> do we anticipate more need for supporting that for more methods?
<ericsnow> (should we consider adding support for binary data to our RPC implementation?)
<rogpeppe1> ericsnow: with potentially large binary blobs, we generally tend to avoid RPC and use REST-style
<rogpeppe1> ericsnow: which methods are you thinking of there?
<ericsnow> AddLocalCharm and UploadTools
<ericsnow> and soon Backup
<ericsnow> and Restore
<rogpeppe1> AddLocalCharm doesn't use RPC
<rogpeppe1> ericsnow: i haven't looked at UploadTools, but I hope it's similar to AddLocalCharm
<rogpeppe1> ericsnow: and Backup and Restore should be similar
<ericsnow> rogpeppe1:  it is basically copy-and-paste
<ericsnow> rogpeppe1: right
<rogpeppe1> ericsnow: well, there might be some common code that can be abstracted
<ericsnow> for Backup I've factored the boilerplate into a common package
<ericsnow> rogpeppe1: I plan on refactoring the other two methods to use it
<rogpeppe1> ericsnow: i'm surprised there was much boilerplate, actually
<rogpeppe1> ericsnow: have you got a link to your proposed common package?
<ericsnow> rogpeppe1: there was enough that wholesale copy-and-paste was happening
<ericsnow> rogpeppe1: https://github.com/juju/juju/pull/200
<ericsnow> rogpeppe1: I called it RPC because it basically it...it just doesn't use our RPC implementation nor does it do JSON RPC
<rogpeppe1> ericsnow: it's really just a REST request, right?
<ericsnow> rogpeppe1: I wouldn't say REST.  In each case it's a POST to a URL whose location ends with the method name
<ericsnow> rogpeppe1: args are handled via URL values
<rogpeppe1> ericsnow: just about anything can be considered REST if it does a POST :-)
<ericsnow> rogpeppe1: :)
<ericsnow> rogpeppe1: it's basically a form
<rogpeppe1> ericsnow: yeah
<rogpeppe1> ericsnow: BTW if you're implementing exported methods in a package, each exported function should a) deserve to be exported and b) have a doc comment describing what it does
<ericsnow> rogpeppe1: good to know (I'll fix that)
<rogpeppe1> ericsnow: i agree that that's useful boilerplate to abstract out
<ericsnow> rogpeppe1: you mean in export_test.go?
<rogpeppe1> ericsnow: no, export_test.go is an exception in lots of respects :-)
<rogpeppe1> ericsnow: i'm looking at UnpackJSON
<ericsnow> rogpeppe1: ah, got it
<rogpeppe1> ericsnow: i'm not entirely sure about the form of the package there. let me think for a few moments.
<rogpeppe1> ericsnow: do we not use a standard error struct type for all error returns?
<ericsnow> rogpeppe1: not that I saw (I may have missed it)
<ericsnow> rogpeppe1: you mean why did I make ErrorResult instead of using params.Error?
<rogpeppe1> ericsnow: yeah
<ericsnow> rogpeppe1: it was for testing
<rogpeppe1> ericsnow: i think it should be easy enough to test without that
<ericsnow> rogpeppe1: the interface allowed using the method rather that relying on the struct member (which is inconsistently an error or a string in various results types)
<rogpeppe1> ericsnow: i'd suggest something like this: http://paste.ubuntu.com/7732030/
<ericsnow> rogpeppe1: since it only mattered for the raw RPC calls, I figured ErrorResult was more appropriate in the rawrpc package than in params/apierror.go
 * ericsnow takes a look
<ericsnow> rogpeppe1: FYI, my background is heavily Python with a little C; I first wrote my first Go code around a month ago so pointers on idiomatic approaches is *always* appreciated :)
<rogpeppe1> ericsnow: np
<ericsnow> rogpeppe1: as to that code you pasted, are you suggesting that we use an approach like that to handle the errors in the unmarshalled results?
<rogpeppe1> ericsnow: the point of that function, as i see it, is to take out the boilerplate involved in parsing the error result from http requests to the API
<ericsnow> rogpeppe1: right, and that was my intention with UnpackJSON as well
<rogpeppe1> ericsnow: how about something like this: http://paste.ubuntu.com/7732104/
<ericsnow> rogpeppe1: I like that
<rogpeppe1> ericsnow: cool
<rogpeppe1> ericsnow: i'd also add a doc comment to the Doer, BTW.
<rogpeppe1> ericsnow: something like: // Do makes an HTTP request. It is implemented by *http.Client, for example.
<ericsnow> rogpeppe1: this does put certain constraints on the response, right?
<ericsnow> rogpeppe1: yeah
<ericsnow> rogpeppe1: result, rather
<rogpeppe1> ericsnow: sure - it means we need to use a consistent error type for all error responses
<rogpeppe1> ericsnow: but that seems like a good thing to me
<ericsnow> rogpeppe1: I'm on board with that :)
<ericsnow> rogpeppe1: I swear the hardest thing we do in this industry is finding the balance between doing things the best way and getting things done (in the cases where you don't have the resources for both)
<rogpeppe1> ericsnow: yeah
<rogpeppe1> ericsnow: the other hardest thing we do is coping with the inevitable creeping complexity that comes from doing too much of the latter without enough of the former :-)
<rogpeppe1> ericsnow: not that your case was an example of that though, i hasten to add
<ericsnow> rogpeppe1: :)
<ericsnow> rogpeppe1: I'll readily admit that I tend toward the latter but over time have become more cognizant of the realities of a world of limited resources and immediate needs :p
<rogpeppe1> ericsnow: i *hope* you mean tend towards the former :-)
<rogpeppe1> ericsnow: well, i guess "getting things done" is an admirable attribute too
<ericsnow> rogpeppe1: oh, yeah :)
<rogpeppe1> ericsnow: and one which i could do with more of :-)
<ericsnow> rogpeppe1: I'm glad we have a mix of both in this world
<voidspace> rogpeppe1: ping
<rogpeppe1> voidspace: sprong
<voidspace> rogpeppe1: :-)
<voidspace> rogpeppe1: can you tell me where in the code we store the replicaset (mongo) addresses
<voidspace> rogpeppe: and where those addresses are created
<voidspace> I've tried following a few trails but I thought you'd likely know pretty quickly
<rogpeppe> client side or agent side?
<voidspace> rogpeppe: agent side
<voidspace> rogpeppe: client side shouldn't have them, right? just api server addresses
<rogpeppe> voidspace: the primary source of info is in the state. APIAddresses
<rogpeppe> voidspace: oh yeah
<rogpeppe> voidspace: sorry, i was thinking of api addresses
<voidspace> rogpeppe: I want the mongo addresses not api addresses
<voidspace> right
<voidspace> rogpeppe: I'm experimenting with having mongo use ipv6
<voidspace> rogpeppe: so I want to tweak the way we create those addresses
<voidspace> rogpeppe: it looks like adding the "--ipv6" flag is sufficient to allow us to connect with ipv6, whilst remaining compatible with our existing code
<rogpeppe> voidspace: cool
<rogpeppe> voidspace: i'd hope so
<rogpeppe> voidspace: state.Machine has a MongoHostPorts method
<rogpeppe> oh no it doesn't
<rogpeppe> voidspace: ah
<mfoord> rogpeppe: sorry, if you replied to me then I didn't see it - my connection was dropped
<rogpeppe> mfoord: what was the last thing you saw me say?
<mfoord> <rogpeppe> voidspace: sorry, i was thinking of api addresses
<rogpeppe> mfoord: so we get the mongo addresses by adding the configuration's StatePort to the machine addresses
<mfoord> rogpeppe: right, I remember that being the case
<mfoord> rogpeppe: where do we do that?
<rogpeppe> mfoord: that's not ideal - i would prefer it if a machine could choose its own mongo port
<rogpeppe> mfoord: in worker/peergrouper
<mfoord> (we have the same problem with rsyslog)
<rogpeppe> mfoord: see worker/peergrouper/shim.go:/MongoHostPorts
<mfoord> cool
<mfoord> rogpeppe: thanks
<mfoord> defining methods on machineShim before we define machineShim is confusing
<mfoord> if only briefly
<rogpeppe> mfoord: yeah, it should be declared earlier
<voidspace> so if I hardcode that to use ::1 then everything still seems to work
<voidspace> I need to verify this address is actually being used directly though
<katco> i just ran into this gem: unit-wordpress-0: 2014-07-01 18:07:02 INFO juju-log db:2: We are now single, ALL THE SINGLE UNITS ALL THE SINGLE UNITS
<katco> kudos to whomever :)
<perrito666> lol, I guess you could bzr blame that
<ericsnow> voidspace: so I'm guessing their upgrading your internet right now :)
<perrito666> ericsnow: indeed, he looks taller
<perrito666> :p
<ericsnow> mfoord: nice internet you have there :)
<mfoord> ericsnow: yeah, horrible
<mfoord> and now... EOD
<mfoord> g'night all
<TheMue> so, added https://github.com/juju/juju/pull/211 as final PR for today
 * TheMue waves
<bac> jamespage: ping
<mattyw> sinzui, mgz ping?
<sinzui> hi mattyw
<mattyw> sinzui, I'm not sure if I'm reading this right but it looks like my branch test failed but still landed? http://juju-ci.vapour.ws:8080/job/github-merge-juju/332/console
<sinzui> mattyw, It did
<sinzui> mattyw, The test suite is soooo bad that the running will try the tests as we think they should run, and fail over to a run with just two procs. Your branch passed the second try
<mattyw> sinzui, well that's *good* news I guess
<mattyw> thanks
<mattyw> as long as the landing is working to plan
<sinzui> mattyw, yes, your branch is not being failed because someone else landed a brittle test
<mattyw> sinzui, sweet
<mattyw> well - thats officially a day then
<mattyw> night all
<thumper> morning folks
<katco> howdy thumper
<thumper> katco: morning, how's the learning going?
<katco> good, thanks for asking :) having a lot of fun
<katco> working on a brilliant charm right now. it's going to revolutionize the way we say hello to the world.
<alexisb> thumper, speaking of fun, this video totally reminds me of Jesse: https://www.youtube.com/watch?v=HYupUy7wiIU
<alexisb> :)
 * katco has a very dry sense of humor
<thumper> katco: hah :-)
<thumper> alexisb: youtube hates me "an error occurred"
<thumper> alexisb: but I can guess what it is about :-)
<alexisb> o, you have to watch it, it is so fitting
 * alexisb waits for jesse to show up online
<katco> alexisb: i hope this person is still here next week :)
<alexisb> :)
<alexisb> katco, wallyworld will have to fill you in on the back story next week
<katco> hehe ok
 * wallyworld clicks the video
 * wallyworld wallyworld can't stop laughing
<wallyworld> alexisb: you are evil
<alexisb> :)
<ChrisW1> can I come program in Go yet? me and python are no longer friends :-/
<ChrisW1> well, specifically, me, Jenkins and running python jobs are no longer friends
<thumper> haha
<thumper> ChrisW1: is that a whingy pom I hear?
<ChrisW1> sea of red: http://jenkins.simplistix.co.uk/
<thumper> ChrisW1: what are you doing to it?
<thumper> ChrisW1: and three isn't really a sea
<ChrisW1> http://jenkins.simplistix.co.uk/job/testfixtures-virtualenv/
<ChrisW1> spot the pattern
<thumper> ChrisW1: you'll have to tell me because I'm not going to go through it all hoping to see a pattern
<thumper> still trying to go through my 200 odd emails
<ChrisW1> there is no pattern
<thumper> although to be honest, I spent the first six months of programming Go being very angry at it
<thumper> coming from python
<thumper> I think I have calmed down a lot now though
<ChrisW1> you? angry? nah, don't buy it
<ChrisW1> could never ever imagine that...
<thumper> heh
<ChrisW1> if I had hair I would be pulling it out right now
<thumper> you could grow it longer just for the pleasure of pulling it out
 * ChrisW1 wonders if menn0 is up yet?
<menn0> ChrisW1: yep :)
<thumper> menn0: careful, I think he may be in a complaining mood
 * thumper pokes ChrisW1 with a long stick and runs away
<menn0> he he
<menn0> ChrisW1: so what brings you to these parts? :)
<ChrisW1> my fault, attempting to support a package on 3 x os and 4 x python versions
<ChrisW1> menn0: oh, no reason...
<ChrisW1> how's nz?
<thumper> very cold today
<thumper> weather forecast is for 15-20cm of snow today
<thumper> which is a lot for us
<thumper> and likely to close schools
<ChrisW1> that'd be a lot for the uk too!"
<thumper> however right now, it is just cold ~3Â°C and dry
<menn0> that would bring the UK to a stand-still :)
<thumper> I'm missing sunny
<thumper> no.. not what I meant, missing summer
<thumper> warmth
<thumper> and sun
<alexisb> thumper, it is 34 C here today
<alexisb> hottest day of the year so far
<thumper> :-(
<alexisb> and I think I would rather have snow
<ChrisW1> yeah, pretty toasty here too
<ChrisW1> great weather for debugging weird on top of weird
<alexisb> heh
<uru-away> cmars: thanks for the info. gonna read the paper 2nd time tomorrow morning with a fresh brain, and try to deduce the number of interactions, as per their design and as section 7 somehow shows their efficiency, there shouldn't be an issue for scaling
<thumper> ChrisW1: I normally find a drink helps in the evening to lower the frustration levels
<thumper> aim for the Ballmer peak: http://xkcd.com/323/
<thumper> menn0: fwiw, I agree on the facade approach
<thumper> menn0: if things go wrong, we want the user to be able to ssh in at least
<thumper> and if we remove the api altogether, we can't do that easily
<menn0> thumper: did you see the email I just sent?
<thumper> yeah
<thumper> just agreeing with you
<thumper> finally through email backlog
<menn0> you said "facade approach" and what I'm suggesting is actually not quite using facades - although the work done for facades has made it a lot easier
<thumper> now I get about 25 minutes before the next meeting
 * thumper sighs
<thumper> menn0: well, whatever you said makes sense, let's look at the implementation :-)
<thumper> sinzui: where is the jub page for the landing bot?
<rick_h__> thumper: github.com/juju/jenkins-github-lander
<thumper> sinzui: I'm curious to see if recent landings have improved the intermittent failure issue
<thumper> it looks like it has
<rick_h__> oh, diff bot :)
<sinzui> thumper, http://juju-ci.vapour.ws:8080/job/github-merge-juju/
<thumper> sinzui: cheers
<sinzui> thumper, There was a misadventure 8 hours ago
<sinzui> thumper, I tried to move the job to the dedicated slave, but I don't think git was setup.
<thumper> sinzui: well five passes in a row is more than we have seen in some time
<sinzui> thumper, so I requeued the job to my favour, all 1.20 jobs first
<sinzui> thumper, mgz was also working on it the running
 * thumper nods
<sinzui> I just landed lxc support to the run-unit-tests script. I hope that will help mgz
<thumper> cmars: with you shortly, just making a pot of tea for my sick wife
<thumper> :)
<sinzui> wallyworld, I am concerned about 1.20. http://juju-ci.vapour.ws:8080/ shows the restore tests failing. I just changed one test to HP after it reached its final 3 tries. Either our restore code has spontaneously combusted in both branch or ec2 has changed. I don't wan't to say https://bugs.launchpad.net/juju-core/+bug/1336104 also affect 1.20
<_mup_> Bug #1336104: cannot restore bootstrap machine: cannot get public address of bootstrap machine <backup-restore> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1336104>
<sinzui> wallyworld, I was hoping to start the 1.20 release with a blessed revision in an hour
<wallyworld> sinzui: ok, will look. i was hoping we were good to release as well :-(
<wallyworld> sinzui: can you clarify - do you think this affects 1.20 also?
<sinzui> This is 1.20 that is failing right now in a similar way
<wallyworld> :-(
<sinzui> wallyworld, none of the recent commits seem to be a cause
<wallyworld> and it is running now against hp cloud ?
<wallyworld> in case it's an ec2 issue?
<sinzui> wallyworld, I stopped running the functional test on HP at the start of June. This is the first time I am trying them with the new regions
<wallyworld> ok
<wallyworld> sinzui: was the bootstrap timeout config attribute you are using typed in as "bootstrap-timeout"
<sinzui> wallyworld, I tried this with all joyent encs
<sinzui> bootstrap-timeout: 600
<sinzui> I now have a job that kills any joyent proc older than i hour
<wallyworld> hmmm, ok. that looks correct, so might be an issue
<sinzui> wallyworld, 1.20.0 is soooo much better than 1.18.0. Since I am not killing the 1.20.0 versions of juju  I favour fixing this issue in 1.20.1
<wallyworld> sounds good
<wallyworld> sinzui: my first look into the restore code shows no recent changes in the part that is failing
<sinzui> Hp just started its restore http://juju-ci.vapour.ws:8080/job/functional-backup-restore/1050/console
<sinzui> 20 minutes and I hope for a pass
<sinzui> The other restore test just switched to Hp
<wallyworld> sinzui: the error seems to indicate the mongo db is empty, and further back in the console log i see "Restore failed:" but with no additional information
<sinzui> :(
<sinzui> wallyworld, the HP run failed with "no reachable servers" this might be caused by Hp...but the error is still in juju-restore :( http://juju-ci.vapour.ws:8080/job/functional-backup-restore/1050/
 * sinzui moves the test back to aws
<wallyworld> hmmmm
<wallyworld> we this kinda sucks
<wallyworld> sinzui: i think "Restore failed:" is printed by the ci script
<sinzui> yes
<wallyworld> i wonder why it is not logging an error?
<sinzui> wallyworld, the test prints "Restore Failed" then the error that was sent to stderr
<wallyworld> which appears to be nothing :-(
<sinzui> wallyworld, message about the lock is nothing? http://juju-ci.vapour.ws:8080/job/functional-backup-restore/1049/console
<wallyworld> sinzui: didn't see that. that is a problem
<wallyworld> so 2 things are running apt
<sinzui> wallyworld, I have seen that several times. The problem with the test is there is so much setup that we see failures getting to HA or  restore dies early with a huge glob of text http://juju-ci.vapour.ws:8080/job/functional-backup-restore/1048/console
<wallyworld> maybe a manual test is required
<wallyworld> we'll also look into the rev where it first started failing
<wallyworld> sinzui: how hard would it be to re-run a test with the previous rev to 7f77fc1
<wallyworld> just  to get another data point
#juju-dev 2014-07-02
<davecheney> rick_h__: ping
<davecheney> did you get my email about winblows ?
<rick_h__> davecheney: yes, sorry. Meant to ping alexis on it and see if she moved forward before I sent it over
<rick_h__> davecheney: let me check my email for getting at the msdn stuff.
<davecheney> rick_h__: thanks
<davecheney> i've got as far as I can without being able to test locally
<sinzui> davecheney, I ca start a win instance from snapshot used to start the win-build-server
<rick_h__> davecheney: see pm
<sinzui> wallyworld, rerunning an older revision is easy, but it take 4 hours now that we test so much and don't have the slaves doing their own builds
<wallyworld> sinzui: ok, np
<sinzui> wallyworld, But I don't see any reason to test master until 1.20 is good So I will start the test
<sinzui> wallyworld, The build is started. We are about 2.5 hours from when the function*restore tests will run
<wallyworld> sinzui: i'm manually testing restore, not done it before, ran into problem: i took a backup, then destoryed my env, then restored. i fails saying it can't re-bootstrap without a control bucket :-(
<wallyworld> so it seems it wants stuff from the jenv file which no longer exists
<sinzui> wallyworld, I have not seen that before
<wallyworld> [master]ian@wallyworld:~/juju/go/src/github.com/juju/juju$ juju-restore juju-backup-20140702-1042.tgz
<wallyworld> extracted credentials from backup file
<wallyworld> re-bootstrapping environment
<wallyworld> error: cannot re-bootstrap environment: control-bucket: expected string, got nothing
<sinzui> wallyworld, what kind of env are you testing with?
<wallyworld> amazon
<wallyworld> maybe i needed to keep the jenv file
<sinzui> wallyworld, CI doesn't set control-bucket for any env :(
<wallyworld> sinzui: i think doing destroy-environment after the backup was a mistake
<sinzui> ...and unittests and win-build-installer are now playing
<wallyworld> but it seems unfortunate we can't fully restore from that situation
<sinzui> wallyworld, well, yes...
<sinzui> wallyworld, use the console to kill the instance
<wallyworld> sinzui: cause you know, restore is meant to recover from stuff going away
<sinzui> wallyworld, that will simulate a state-sever failure
<wallyworld> i should be able to hand over the backup tar gz to someone and they should be able to restore
<sinzui> wallyworld, and you need on service up to verify that the service learns about the new state-server
<sinzui> one service i mean no on server
<wallyworld> hmmm. true for running a test. but in general, restore should be able to habdle a full restore from nothing
<sinzui> wallyworld, I don't think so. the control-bucket is only removed by destroy-env...that is human fault
<wallyworld> sure, but here it failed because there was no jenv to read the control buvket from
<wallyworld> requiring some artifacts to still be up for a restore to be successful implies restore is broken
<sinzui> wallyworld, your test isn't valid. the case is for when hardware fails, or the like when canonistack loses a machine
<sinzui> that is the scenario fwereade outlined to me
<wallyworld> there's no reason why restore can recognise there's no control bucket and recreate it and redeploy the charms listed in state
<wallyworld> imagine if hard drive or data backup worked that same way
<sinzui> wallyworld, possibly, but to test what was written and given to customers, we just simulate a bootstrap node failure by terminating the instance using the provider's tools
<wallyworld> "sorry, restore can't copy your stuff back from tape because you no longer have your original login details to your pc that was destroyed"
<wallyworld> understood, i was just using restore how i thought it should work
<wallyworld> and got disappointed
<wallyworld> it's not what i would accept as a customer
<wallyworld> axw: hiya, i landed your 1.20 keep alive branch. landings still quite problematic
<axw> wallyworld: thanks. yeah :(
<wallyworld> but a bunch did go through last night
<axw> it seemed marginally better after some of hte fixes landed, but could just be my bias
<wallyworld> we still have the could of root cause issues i think
<wallyworld> couple
<axw> wallyworld: is it okay if I modify the unit test job to create a tmpfs and use that for $TMPDIR?
<wallyworld> sure
<wallyworld> i also want to fix the root cause issues as well
<wallyworld> axw: could i ask you to take a quick look to ensure we think the bootstrap-timeout option still works. it seems with CI joyent tests, joyent wasn't bootstrapping due to that 1.18 bug but the sessions weren't being closed after 10 minutes
<axw> wallyworld: ok
<axw> there was a problem with the timeout option originally, it never took effect I think
<axw> got fixed somewhere along the way. I'll verify in a bit
<wallyworld> thanks
<wallyworld> sinzui: i get the same restore "cannot connect to bootstrap instance: EOF" error in my manual test on 1.19.5 :-(
<sinzui> :(
<wallyworld> the instance is there and i can ssh to it
<wallyworld> i'll see what else might be happening
<axw> wallyworld: 2014-07-02 01:28:44 ERROR juju.provider.common bootstrap.go:119 bootstrap failed: waited for 30s without being able to connect
<axw> Stopping instance...
<axw> (it works)
<wallyworld> axw: ok, thanks. sinzui ^^^^^
<wallyworld> not sure why timeout was failing for joyent
<axw> that was on ec2
<axw> wallyworld: was it 1.18?
<wallyworld> may have been
<wallyworld> was there a fix post 1.18?
<axw> bootstrap-timeout used to be busted
<axw> not sure when it was fixed
<wallyworld> ok, we'll ascribe the issue to that then :-)
<axw> wallyworld: not sure if you're aware of this yet: #1271144
<_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider <cloud-installer> <landscape> <local-provider> <lxc> <maas> <regression> <juju-core:Fix Released by axwalk> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Trusty):Confirmed> <https://launchpad.net/bugs/1271144>
<axw> we fixed that a while ago, but there's a problem with maas assuming that the interface is eth0
<wallyworld> hadn't seen that
<axw> well, sorry, the maas provider
<wallyworld> so maas is broken for 1.20?
<axw> it's the same now as it is in trusty
<axw> I don't *think* that particular bug is new
<axw> wallyworld: I don't think we need to fix it for 1.20 necessarily, just letting you know it exists because it's had some activity
<wallyworld> thanks, we'll target for 1.20.1
<wallyworld> sinzui: hacking the restore code to just pick up from the bit where it attempts to connect to the newly started replacement bootstrap instance worked the second time through. so it looks like a mongo startup issue related to timing. i can put the connect bit of code in a retry loop
<sinzui> :) you are a hero
<wallyworld> i'll target the bug to 1.20 also
<sinzui> wallyworld, Do I dare take master our of testing to make 1.20 the only priority
<wallyworld> sinzui: i would :-)
<wallyworld> just for today
 * sinzui does
<axw> davecheney: are you updating juju to the new loggo? if not, I can
 * thumper needs to think things through, so going to walk the dog
<davecheney> axw: https://github.com/juju/juju/pull/212
<davecheney> jynx!
<davecheney> sorry, took a whlie to run all the tests
<axw> cool
<davecheney> axw: say the words, SAY THEM!
<axw> luks gud
<axw> davecheney: reviewed
<davecheney> ermehgerd, wreeevu
<wallyworld> sinzui: there are a few possibilities where the restore is falling over, i have to track down the place and then i can fix. not as obvious where to put the retry as i first hoped.
<sinzui> :/
<wwitzel3> when writing tests for apis .. if the state/api tests execute the code paths in state/apiserver .. do I need to copy and paste those tests minus the caller? what is the stance on that?
<wwitzel3> I have unit tests for the methods internal to state/apiserver , but the method we expose to state/api (GetCapabilities) is being fully executed by the tests in state/api.
<wallyworld> sinzui: well, i know the top level api call, but one part of the implementation does retry, and there's a section that doesn't. i'll have a fix soon i hope
<wallyworld> wwitzel3: our api tests are not really complete - i believe the client tests involve calling all the way through to a functioning server
<wallyworld> the apiserver tests are a subset
<wallyworld> i just follow what others have done when i add tests there
<wallyworld> wwitzel3: i think from memory the apiserver tests have full coverage, and the client tests just check that it's all wired up
<wallyworld> so they just run a few representative calls
<wwitzel3> wallyworld: ok, well then I will move my state/api assertions in to state/apiserver and then have the state/api test just ensure it is all wired up correctly.
<wallyworld> wwitzel3: yeah, i think so. see what say keymanager does for example
<wallyworld> it's sorta crap, but it was how it was all done originally
<wallyworld> people just didn't stub out properly
<wallyworld> the the pattern has been cargo culted over and over :-(
<wwitzel3> I've been cargo culting for the last 3 months .. sorry
<wwitzel3> I'm new, I don't know what to do!
<wwitzel3> just got done looking at the keymanager example
<wwitzel3> I will adjust accordingly
<wwitzel3> thanks :)
<waigani> https://labix.org - security certificate has expired
<davecheney> whups
<wallyworld> wwitzel3: cargo culting reference wasn't meant for you - it's a reflection of the poor state of the original tests
<wallyworld> i've done the same thing in that section of code
<axw> wallyworld: wow, that tmpfs change I made had quite an impact on the time taken to run the state package tests
<wallyworld> yeah?
<axw> 325s down to 120s
<wallyworld> wow
<axw> those disks are slow as
<wallyworld> must be :-(
<axw> it's meant to have SSDs
<wallyworld> i use a ramfs for my tmpfs cause i got 16G
<wallyworld> fast
<wallyworld> i don't want to wear out my ssd
 * axw nods
<axw> woot, ran all the tests in 19 mins and passed first go
<wallyworld> axw: if they pass 10 times in a row..... that will be a nice surprise
<wallyworld> regardless, there's still race conditions to fix :-(
<axw> wallyworld: that's shaved 8 minutes off the last successful first-time run
<axw> yeah
<axw> I am looking at all the races now
<wallyworld> and when we get nailed up instance, goodbye to another 4-8 minutes
<lifeless> even SSDs are slow if they have to actually do IO
<axw> sure, but the difference on my laptop's SSD and tmpfs is about 30s in this test, not 2 minutes
<lifeless> ah
<davecheney> https://github.com/juju/juju/pull/213
<davecheney> ^ another state related fix
<davecheney> actually related to the footgun that is suite.TearDownTest
<davecheney> oh fuck
<davecheney> the branch is mixed in with my loggo change
<davecheney> the change is in ïï state/initialize_test.go
<davecheney> if you want to review
<davecheney> i'll repropose it after the bot has landed my previous branch
<axw> looking
<axw> davecheney: this is where rebase is handy. "git rebase -i master" and delete the loggo commit line
<davecheney> axw: hmm
<davecheney> i tried
<davecheney> but failed
<davecheney> the commits came back :*
<axw> mmkay. I never had any problems with it so I don't know what to suggest
<davecheney> axw: i'm batting 0.00 with git rebase
<thumper> oh man...
<thumper> head is spinning with auth shit
 * axw calls victory over the lander
<axw> 3 in a row passed first time, 19m 17m and 17m
<davecheney> axw: i remain unconvinced
<davecheney> i suspect there is more pain in there
<wallyworld> great :-) those were the times we saw when this was all first set up - it has degraded over time since :-(
<thumper> speaking of shit,  antipathy.nonserviam.net/utilities/shit  <== beware, perl
<davecheney> basically any time mongo shits itself coming up
<davecheney> the test explodes in a blame misdirecting way
<thumper> show image in terminal
<thumper> saw it last nigh
<thumper> t
<axw> davecheney: there are still problems, but I reckon it's due to slowness
<thumper> pretty interesting
<thumper> someone should write it in go
<thumper> it could be called "go shit"
<davecheney> go is
 * thumper chuckles
<thumper> sfw - examples imgur.com/a/kmOhv#0
<davecheney> thumper: ha, fool me trice
<wallyworld> sinzui: so i have a working solution. i tried to push the retry logic down to the root cause failure (login), but the underlying connection got closed underneath so i had to move it up higher. will propose and land in 1.20. took a while to get it right due to the iteration time
<wallyworld> only took one retry loop before it connected
<davecheney> https://github.com/juju/juju/graphs/commit-activity
<davecheney> ^ this is what a sick commit bot looks like
<wallyworld> sinzui: ah bollocks, it failed in a different place right near the end of the restore. ffs
<wallyworld> might be spurious, will retry
 * thumper out to collect daughter, back shortly
<axw> wallyworld: woohoo, now the github merge failures are back
<wallyworld> \o/
<axw> can't win
<axw> bbs picking up my daughter
<davecheney> bloody helll
<davecheney> juju/testing/mgo.go
<davecheney> how many panics are there in there !?!?
<jcw4> davecheney: local tests? The last build failure seemed to be a merge issue...
<davecheney> jcw4: this problem goes deeper than the last test faliure
<davecheney> senopsys
<davecheney> if mongo shits itself coming up
<davecheney> the test helper will panic in one of a dozen different ways
<davecheney> the panic is captured by the testing suite
<davecheney> which then goes to tear down the test
<davecheney> that usually generates a far more fatal panic
<jcw4> blech
<jcw4> davecheney: and mongo failing on startup is random?
<davecheney> jcw4: random as clockwork
<jcw4> haha
<jcw4> but... but... mongodb is network scale
<davecheney> it's significantly less stable since we combined replica sets and tls into an unhoyly offspring
<jcw4> or something like that
<jcw4> hmm
<davecheney> wallyworld: axw http://paste.ubuntu.com/7734835/
<davecheney> openstack tests fail reguarly for me
<davecheney> complain they can't find tools and crap themselves
<jcw4> davecheney: what are the address type warnings about ipv6?
<jcw4> davecheney: seems possibly related to not finding resources on 127.0.0.1
<jcw4> (ipv4)
<davecheney> our tests leak shitloads of pingers
<davecheney> http://paste.ubuntu.com/7734318/
<davecheney> jcw4: no idea
<thumper> davecheney: got a minute to chat?
<thumper> davecheney: particularly about tests and pingers
<davecheney> thumper: sure, send me a hangout link
<davecheney> i'll go upstairs
<thumper> kk
<thumper> davecheney: https://plus.google.com/hangouts/_/canonical.com/testing
<wallyworld> davecheney: what changes were made before those tests were run?
<davecheney> wallyworld: not sure I follow
<davecheney> i think those leaky pingers have been ther for a while
<davecheney> i think thye are leaking out of the mongodb driver
<wallyworld> davecheney: i mean the tools errors
<davecheney> oh
<jcw4> PTAL: https://github.com/juju/juju/pull/216
<davecheney> sorry, i'll try to capture more errors
<wallyworld> ok
<davecheney> it doens't happen consistently
<wallyworld> \o/
<davecheney> and when I run the tests in a loop i usually find another failure
<davecheney> which distracts me
<davecheney> for example, http://paste.ubuntu.com/7734852/
<jcw4> jam: since you'll be on before me tomorrow: https://github.com/juju/juju/pull/216 :)
<jam> jcw4:  ?
<jcw4> on call reviewer :)
<jam> k
<jcw4> jam: pretty straightforward
<jcw4> jam: what timezone are you?  I thought you were closer to GMT?
<jam> jcw4: UTC + 4
<jam> I'm in Dubai
<jcw4> jam: Ah! that's the second time I've forgotten that
<jam> jcw4: well it is 20+ people to keep track of :)
<jcw4> jam: I told fwereade a couple weeks ago I chatted with you late at night 'cause I thought you were down under
<jcw4> jam: and I was embarrased to learn you were in dubai; now I know it's just that you're up bright and early
<jam> jcw4: in your defense, I don't keep to a very strict 8-hours-a-day work schedule. so I *might* show up at random times
<jam> my dog usually wakes me up for a walk at about 5:30-6am
<jcw4> jam: :) that's too early.  well I'm UTC-7 so I'm off to bed myself
<jam> and my family was away for a week recently, which led to a bit more work times.
<jam> jcw4: rest well, it is quite late for you
<jcw4> yep, my self imposed bedtime is 30 minutes ago
<jcw4> :)
<davecheney> wallyworld: http://paste.ubuntu.com/7735005/
<wallyworld> davecheney: ok, that appears to be a test failure due to c.Check(info2, gc.DeepEquals, info) - what happens on failure is all the debug log stuff gets shown. simplestreams debug logs what happens as it looks on the search path for metadata, and sometimes there's nothing there so it logs it for diagnostic purposes
<wallyworld> so it appears to not be an issue so much
<davecheney> hmm
<davecheney> and it's upset because the test bound to 127.10.0.1
<davecheney> not 127.0.0.1
<wallyworld> i'm not sure why that happened without looking into it
<davecheney> mkay
<wallyworld> axw: bot is a lot happier now that /tmp is not on those slow disks
<axw> yeah :)
<axw> so much blue
<wallyworld> buys us time to nail the remaining intermittent errors
<wallyworld> cause running on a slow disk should not break the tests :-)
<davecheney> yup
<davecheney> cloud is always gonna be slow
<davecheney> that's what it does
<axw> indeed, really do need to get to the bottom of it
<jam> for the well motivated: https://github.com/juju/juju/pull/218 and https://github.com/jameinel/juju/pull/4
<jam> dimitern: fwereade: ^^
<wallyworld> axw: did the race detector find those races you fixed?
<axw> wallyworld: yes
<wallyworld> jeez, there's a lot of them
<axw> indeed :)
<wallyworld> we need to set up a CI job
<wallyworld> cause we won't pick them all up at review time
<axw> agreed
<axw> wallyworld: all I did was "go test -race ./..."
<wallyworld> takes along time though right?
<axw> not particularly long
<axw> I didn't time it
<wallyworld> i still think a job will be helpful
<jam> morning dimitern
<dimitern> morning jam
<dimitern> jam, i'm looking at your PRs
<jam> thx
<jam> dimitern: and thanks for fixing the edit of the networking spec
<dimitern> jam, np, i should've done that initially
<jam> dimitern: hard to realize when you're own editing of it works just fine :)
<dimitern> :D
<jam> vladk: thanks for reviewing https://github.com/juju/juju/pull/211, one point of note. When you finish a review, it is good to give a summary comment on the whole thing. That way we know that you are done reviewing, and we know whether you are giving it an overall LGTM or whether it is something that needs to come back for another review.
<TheMue> morning
<TheMue> jam: vladk: thx for review, good comments
<voidspace> morning all
<jam> morning TheMue and voidspace
 * jam needs to go get food
<dimitern> jam, both reviewed
<axw> dimitern: does the coming network stuff need bridge-utils? I'm just tidying up our cloud-init, wondering if it can be removed for non-maas
<dimitern> axw, we should leave it to the networker to install that and the vlan package as needed, but let's leave it for now until it does?
<axw> dimitern: ok, will leave it there for now
<dimitern> axw, cheers
<dimitern> axw, if you're changing cloudinit anyway, perhaps add a TODO about dropping bridge-utils and letting the networker install it as neede\
<dimitern> d
<axw> sure
<axw> there's a bug about it, I'll add a comment and ref to that
<dimitern> axw, awesome
<dimitern> axw, btw is the relation addresses work on hold pending approval?
<axw> dimitern: yes. I did a more modest change to trigger config-changed on address change, but relation addresses are on hold for now
<dimitern> axw, right, ok
<axw> needs some more discussion and/or arm twisting
<axw> :)
<dimitern> :) tell me about it
<mgz> axw: want to do mini standup?
<axw> mgz: sure, brt
<dimitern> we've been going over the model back and forth for the past 3 weeks, but at least we're now into minor implementation details mostly
<voidspace> jam: so I've finally managed to find the right place to hardcode the ipv6 mongo address
<voidspace> jam: and I can get a connection to mongo on [::1]:37017 working fine
<voidspace> jam: which I think validates that mongo works ok locally with ipv6
<voidspace> jam: and from his reading of the mongo codebase vladk thinks that we should be fine with both ipv4 and ipv6 connections to the same mongo(s) if we need it
<dimitern> voidspace, great news!
<jam> voidspace: sounds good, indeed.
<menn0> voidspace: ping?
<TheMue> jam: youâve got another part I can support network coding?
<voidspace> menn0: pong
<jam> dimitern: I think I've addressed all of your requests on https://github.com/juju/juju/pull/218 if you want to give it another quick pass.
<dimitern> jam, cheers, will look in a bit
<jam> TheMue: I don't think I quite understand? Just wanting more work to do ?
<jam> TheMue: we'll talk about it in 15 min anyway, so I'm going to just go make coffee and see you guys there.
<TheMue> jam: ok
<vladk> voidspace, dimitern, jam, TheMue: here is my investigations on replicaset with IPv6
<vladk> https://docs.google.com/a/canonical.com/document/d/1mfLSIUAV5V7_uj3oxBDIGxlT5jPOKIXsWlmyO6pa23Y/edit?usp=sharing
<TheMue> *click*
<dimitern> vladk, thanks for sharing!
<TheMue> vladk: interesting notation when setting addr and port. go would dislike it
<dimitern> jam, standup? also - your PR is ready to land I think
<fwereade> axw, ping
<rogpeppe> mgz: i'm going to update godeps. worth watching the 'bot to check that it doesn't fall over
<jam1> wallyworld: mgz: http://juju-ci.vapour.ws:8080/job/github-merge-juju/324/console failed because the script couldn't be found: /tmp/hudson6827171313236674227.sh: line 121: /home/ubuntu/jenkins-github-lander/bin/lander-merge-result: No such file or directory
<mgz> rogpeppe, jam1: that was too fast, right? :)
<jam1> mgz: too fast?
<rogpeppe> mgz: i think so
<mgz> to blame rog :)
<jam1> mgz: it failed a long while ago
<jam1> mgz: so yes, not rog's fault
<rogpeppe> mgz: i don't think it had even merged by the time that message came here
<rogpeppe> phew :-)
<mgz> yeah, it's yesterday. I wasn't fiddling with it then, but someone may have been
<mgz> would just try rerunning it, stuff has landed since then.
<axw> fwereade: pong. getting kids to bed and dinner on. I will bbl
<fwereade> axw, no worries, but if you have some time I would appreciate your thoughts on https://github.com/juju/juju/pull/189/files -- you've been in there a lot more recently than I have
<fwereade> axw, I think I'm saying things that are roughly sane but your oversight would be good
<axw> fwereade: nps, will take a look later
<wwitzel3> so I noticed there was state/policy.go and inside there is an interface EnvironCapabilities. So I should probably extend that to have the InstanceTypes and AvailabilityZones (it already has SupportedArchitectures) instead of defining my own interface (which was also called EnvironCapabilities). If I do that, I get an import cycle with state since I need to in include it in the apiserver code to use this interface, but it is also included 
<wwitzel3> do I move the interface to its own package under state? do I move the interface out of state and use the one I've defined in provider?
<wwitzel3> do I just have two different, but very similar interfaces?
<wwitzel3> I feel like state is the wrong place for this interface anyway. It made sense to me existing in provider/common.
<wwitzel3> so I'm leaning towards just moving it there, since the interface itself is only used by providers anyway (afaict)
<wwitzel3> looks like it is used by state in a few places, hrmph
<jam> vladk: yay, your patch landed this time
<vladk> jam: hooray
<TheMue> jam: back from lunch, shall I grab one coding task from our planning lane?
<jam> TheMue: so, we can have you (a) try to pair with voidspace on what he's doing with ipv6 and mongo
<jam> (b) have you look at fixing the firewall rules for providers to disallow external DB access
<voidspace> jam: TheMue: the first part of that is trivial and will be done soon
<voidspace> jam: TheMue: when I come back from lunch we could pair on the peergrouper stuff
<jam> voidspace: yeah, I expect 'âipv6' to be easy enough. IT is more about pairing for replica set and peergrouper
<voidspace> sounds good
<jam> voidspace: though if you put that up for review for TheMue to look at before you go to lunch, he can approve it by the time you get back :)
<voidspace> cool
<TheMue> jam: voidspace: ok
<voidspace> :-)
<TheMue> sounds good
<jam> TheMue: if you have some time free now, getting developer docs on using API versioning is probably quite worthwhile while it is fresh in our memories
<TheMue> jam: yes, Iâm currently looking into your changes and the doc to see where we differ from the old API
<TheMue> jam: just digging in PR 218
<TheMue> jam: would btw like two APICall() versions, one like now with explicit version and using BestFacadeVersion(), and another one doing that implicitely
<TheMue> jam: APICallBestFacade()
<TheMue> jam: but thatâs only convenience ;)
<jam> TheMue: so we have FacadeCaller that provides the second form
<jam> along with BestAPIVersion for things that need to check compatibility
<jam> which I would expect most poeple would use
<jam> since they *also* just want to use calls on a single facade
<TheMue> jam: oh, not yet found it, nice
<dimitern> jam, how about instead of 1 suite, with methods to start ipv4/ipv6/both servers, instead to have 3 separate suites, that do each one separately at SetUpTest ?
<voidspace> jam: so in testing/mgo.go we hardcode the address to localhost:port (MgoInstance.addr)
<voidspace> jam: ah, no problem forget that
<jam> dimitern: its possible, however I would think that you would have both kinds of tests in one file, and it might be more obvious to have them next to eachother.
<dimitern> jam, because it's really not that easy to reason with MgoSuite and make it *not* start mongod in SetUpTest and assert it was closed in TearDownTest
<voidspace> jam: I just want to test I can *connect* to it with ipv6
<jam> jam: "localhost" isn't a problem, right?
<jam> 127.0.0.1 would be
<voidspace> jam: no, it's fine - I was confusing starting the mongo instance and connecting to it
<jam> dimitern: I would be happy enough to have us split out Mongo testing from API Server testing.
<voidspace> having started it I just want to test connecting to it
<jam> what we probably care the most about at this layer is API Server testing
<voidspace> I thought I wanted to change the way it was started
<dimitern> jam, the problem is we can't start an API server without a connected backing state.State
<jam> dimitern: I'm just thinking that if I was writing tests, I would probably write: "TestIPv6APIServer()" and then "TestDualStackServer", etc.
<jam> Which *could* be separate Suites, but it wouldn't be as obvious (I think)
<jam> alternatively, we have a test mixin
<jam> (so a common set of tests that get run with each base suite)
<dimitern> jam, I'll think about it some more
<jam> dimitern: so I'm less stuck on Mongo must be connected to the same way as the API server.
<jam> if it is easier to tease them apart for testing.
<dimitern> jam, at least i found out a smaller prereq i'll propose shortly - the api server needs to take Addrs []string (or []network.HostPort, but I'd rather not bind these two) and listen on all given EPs, not just one
<jam> dimitern: I think that's better, though I wonder if we want to just pass ":Port" and have it bind to all ?
<dimitern> jam, that's better actually and simpler
<jam> dimitern: well, I'm looking into the Python 'socket' code, and you can't just do that, at least.
<jam> dimitern: at least in python, when you declare a socket, you have to specify AF_INET or AF_INET6
<jam> and then sock.bind(('0.0.0.0': 12345)) vs sock.bind('::', 12345, 0, 0))
<jam> (bind takes 4 args vs 2)
<jam> dimitern: http://golang.org/pkg/net/#Listen
<jam> dimitern: says that it must be "tcp" "tcp4" or "tcp6"
<jam> maybe "tcp" will give us both?
<dimitern> jam, right, we need "tcp" and "tcp6" and 2 Listen() calls
<dimitern> jam, I'll do some experiments
<jam> dimitern: well if we need 2 Listen calls, then we probably need 2 Listener objects, and if we want to support dual stack, then the inner select needs to select on both of them.
<voidspace> I get LOG messages "connection accepted", followed by a "no reachable servers" error
<voidspace> does the "connection accepted" log message mean that we *did connect*, or is it possible that the "no reachable servers" message is genuine
<voidspace> dimitern: ping ^^^
<dimitern> voidspace, I think it means you connected to one of the mongos, but it itself couldn't reach the other replica set members perhaps?
<dimitern> rogpeppe will know better I guess ^^
<jam> dimitern: I did some web searching, everything looks like you need 2 sockets to do it right.
<voidspace> dimitern: this is testing/mgo.go
<voidspace> so there's no replicaset
<jam> voidspace: the log message "connection accepted" just means TLS connected. I think we still need to Login, etc. after that.
<voidspace> jam: so mongo accepted the connection but login failed - something like that
<voidspace> This is how I'm constructing the connection: http://pastebin.ubuntu.com/7736622/
<voidspace> essentially: info.Addrs = []string{fmt.Sprintf("[::1]:%s", testing.MgoServer.Port())}
<voidspace> let me try with 127.0.0.1 to make sure it can possibly work
<jam> voidspace: I forget the exact circumstances, but I've seen us go into a tight loop with 1000s of lines of "connection accepted"â¦. yeah, if it was accepted, why aren't you doing anythingâ¦ :)
<voidspace> heh, no that fails
<voidspace> so the test construction is bad, nothing to do with ipv6
<voidspace> hah, it was my python knowledge that was causing it to fail
<voidspace> dimitern: jam: %s is not the way to interpolate an int into a string with Sprintf ...
<voidspace> when I use %v the test passes
<voidspace> and without the ipv6 flag the test fails
<voidspace> ship it
<dimitern> :D
<voidspace> TheMue: https://github.com/juju/testing/pull/17
<dimitern> jam, it actually works with Listen("tcp", ":54321") - the same listener accepts both 4 and 6 connections
<voidspace> TheMue: https://github.com/juju/juju/pull/221
<TheMue> voidspace: looking
<TheMue> voidspace: just to be sure, when adding âipv6 mongo only additionally enables ipv6, but still ipv4 in parallel, doesnât it?
<voidspace> TheMue: that's correct - and the rest of the test suite works
<TheMue> voidspace: fine
<TheMue> voidspace: so the fist LGTM has been easy  ;)
<TheMue> voidspace: and the second one too
<jam> dimitern "tcp" sounds good. I was trying to trace through the code to see if it would work, but didn't get to the root of it.
<jam> dimitern: I'm off until our call
<dimitern> jam, ok
<voidspace> TheMue: thanks
<voidspace> I'm going on lunch
<jam> voidspace, TheMue: so we need to do the same thing for github.com/juju/testing
<jam> since that sets up our MgoTestSuite
<voidspace> jam: I had pull requests for both
<voidspace> jam: and both reviewed
<voidspace> jam: probably need to bump revision in dependencies.tsv - but we're not yet *depending* on that
 * voidspace really goes on lunch
<sinzui> abentley, wallyworld jam fwereade I am manually re-running the two failed restore function tests 1 just passed. I think the feature is brittle, but better than 1.18. I hope to start a release in an hour
<jam> sinzui: would this be 1.19.5 or would we be jumping to 1.20?
<jam> I personaly would like to go the "dev release becomes stable with only version.go changes" but I realize we're close on time.
<sinzui> jam I am releasing 1.20.0 from the 1.20 branch
<sinzui> jam Once I do that, I will change master to be 1.20-alpha1
<jam> sinzui: I realize that, just that we have a fair number of code changes since 1.19.4
<jam> sinzui: I think master becomes 1.21-alpha1
<sinzui> jam, master has not passes in a week, so I am not inclined to attempt a 1.19.5. The plan last week was to only merge the safe and stable changes into 1.20
<jam> sinzui: you would do 1.19.5 as a pre-release for 1.20 from the 1.20 branch
<jam> I would certainly not do a 1.19.5 from master
<jam> sinzui: I think *master* is already not a 1.20 branch, but a 1.21-pre branch
<sinzui> yep
<jam> sinzui: my point is that at one point in time, we wanted to have a stable release be *exactly the same code* as a dev release, except for the version.go line.
<jam> and while we've been doing 'stable' patches to 1.19.4, that is still patches from the last dev release.
<sinzui> We created the 1.20 branch our of desperation. I didn't do it until it was clear that was the only way to get a release out
<sinzui> jam. I think we need a policy change to get to "only the version is different". When we have a regression, we stop the line and everyone  fixes it
<jam> sinzui: we can just do the release you want to do, but call it 1.19.5, and when we're happy it really is stable we do 1.20 with no other changes.
<sinzui> jam, master always has multiple regressions, and I think devs are building on top of the broken code
<sinzui> jam, release 1.19.5 today, the 1.20 tomorrow?
<jam> sinzui: given the timeframe, I'm not sure if it is actually worthwhile. If we were giving it 1 week then I think there would be genuine benefit for a stable release.
<jam> sinzui: as for getting into a bi-weekly release cadence for dev releases, we've talked about whether we have to split of each one for stabilization. We have a track record that says we need to.
<jam> anyway, I really need to go, but hopefully the release happens, it sounds good.
<dimitern> voidspace, vladk|offline, TheMue, a minor PR to enable and test the apiserver listens on ipv4+ipv6 - https://github.com/juju/juju/pull/224/
<dimitern> rogpeppe, you might be interested as well ^^
<rogpeppe> dimitern: thanks
<katco> are there any sort of architectural diagrams for juju?
<katco> to help identify subsystems, etc.?
<ericsnow> katco: try https://github.com/juju/juju/tree/master/doc
<katco> ty, sir!
<ericsnow> katco: more text than diagrams though
<katco> it's a start :)
<TheMue> dimitern: looking
<dimitern> TheMue, cheers
<voidspace> dimitern: that looks great
<TheMue> dimiterm: so far here too, but now 1:1 with alexisb
<dimitern> voidspace, yeah, it turned out simpler than I expected
<dimitern> TheMue, np
<voidspace> mgz: no merge bot on juju/testing ?
<TheMue> dimitern: LGTM by my side too
<dimitern> TheMue, thanks!
<ericsnow> voidspace, wwitzel3, perrito666: standup?
<perrito666> ericsnow: I am in a rather unhappy place right now, I would say that you go on without me, there are no changes since our last standup on my side
<ericsnow> perrito666: :(  Do you need a break to come visit us in the land of the living?
<perrito666> ericsnow: I currently am 200km from my usual workplace, I am working at a friends house for the day, I had to travel to get a certificate that entitles my wife to drive my car (yes, you read that correctly)
<ericsnow> perrito666: good luck
<perrito666> ericsnow: oh I got the required paper, it took me 5 min :p
<perrito666> its the 200km part that bugs me
<perrito666> I need to do this for every person I want to authorize to drive my car
<perrito666> and now there is also a kid crying next to me :p
<wwitzel3> ericsnow: not sure why my highlight doesn't work when it is in a list with other names, but just saw this.
<wwitzel3> ericsnow: I just got out of the tosca meeting 5 minutes ago, you still want to do standup?
<ericsnow> wwitzel3: I wouldn't mind
<wwitzel3> ericsnow: meet you there
<voidspace> ericsnow: not me
<wwitzel3> also fwereade I sent you that branch to look at
<voidspace> ericsnow: I don't like you lot these days
<wwitzel3> lol
<ericsnow> lol
<wwitzel3> ericsnow: in moonstone
<katco> interesting, i see a lot of mutexes in the logging framework. isn't the idiomatic way to do synchronization in go message passing?
<perrito666> voidspace: you do not like us now that you have better internet, you have changed
<voidspace> hah, I wish my internet was better
<voidspace> perrito666: it's still horrible :-/
<voidspace> I've complained to the ISP now anyway
<perrito666> voidspace: its a good thing you dont have to spend a week locked with us :p
<perrito666> voidspace: they said new, not better
<voidspace> hah
<voidspace> TheMue: you up for / available for pairing?
<voidspace> dimitern: ping
<TheMue> voidspace: now again, had been afk for giving my wife a helping hand in the garden ;)
<voidspace> TheMue: cool :-)
<voidspace> TheMue: there are three tickets we could plausibly work on
<voidspace> TheMue: peergrouper IPv6 testing - but I think that one is better waiting for the test suite that dimitern is working on
<voidspace> TheMue: Have tests for Mongo in IPv6 replicaSet tests
<voidspace> TheMue: Client: juju/api.go Don't drop IPv6 addresses
<voidspace> TheMue: I get the feeling that jam would prioritise "Have tests for Mongo in IPv6 replicaSet tests" slightly higher
<voidspace> TheMue: but there is no additional description in the card
<TheMue> voidspace: ack
<TheMue> voidspace: yeah, cards often have only the title ;)
<voidspace> TheMue: I guess the most important thing is that members of a replicaset can talk to each other over ipv6
<mbruzek> I am using the local provider.  I deleted the /var/cache/lxc/cloud-trusty/ubuntu*cloudimg*.tar.gz, destroyed and re-bootstrapped.  I don't see a new image in that directory, but juju "deploys".  I thought juju would download a new image.
<voidspace> and possibly in "dual stack" scenarios, but I think we're going to (initially at least) require that all HA state servers be on either ipv6 or ipv4 (so no mixed environments)
<voidspace> TheMue: on the other hand, the other ticket "Client: juju/api.go Don't drop IPv6 addresses" seems nice and straightforward
<voidspace> TheMue: although I think we can't actually use that until we can connect to the api server with ipv6
<TheMue> voidspace: sounds logical. even if it may be possible it alway can lead to hassle
<TheMue> voidspace: exactly, thatâs a dependency
<TheMue> voidspace: so the order would be replicaSet, no dropping in api and finally peergrouper
<voidspace> TheMue: cool
<voidspace> TheMue: hangout?
<TheMue> voidspace: can do, mom, have to fetch headset
<mgz> did you just refer to voidspace as mom? I've clearly missed something TheMue
<TheMue> mgz: hehe, no
<voidspace> that's what I thought
<TheMue> mgz: mom or mom pls is simply for âone moment please"
<voidspace> mgz: hey, for juju/testing do I need to manually approve the merge
<TheMue> mgz: how would you abbreviate it?
<mgz> voidspace: sorry, missed that question earlier - yeah, for anything where github gives you the option of manually merging, you need to run the tests yourself and hit that button on the page
<mgz> I'm planning to start switching stuff over shortly, but atm it's only a few projects that are landing bot controlled
<voidspace> ok, cool
<voidspace> mgz: thanks
<TheMue> voidspace: so, calling you in hangout ;)
<TheMue> voidspace: hmm, doesnât work. taking the saphire hangout? https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<voidspace> TheMue: I'm there
<TheMue> voidspace: lost you
<TheMue> ;)
 * TheMue lost connection
<TheMue> voidspace: Iâve got to step out, will ping you tomorrow morning
<voidspace> TheMue: ok, sorry for the delay
<katco> would anyone have some time to answer some questions about the logging systems?
<sinzui> alexisb, I just sent an email about the 1.20.0 release. I need to eat. Perhaps you want to talk in about 30 minutes about it
<alexisb> sinzui, I will be out for a bit for lunch, but can ping  you whne i am back
 * alexisb goes an dlooks at email
<hazmat> dimitern, what's the status on container addressability?
<dimitern> hazmat, it's on hold since ipv6 gained priority
<hazmat> dimitern, ic, thanks
<mfoord> grrr, new phone arrived today
<mfoord> DOA
<mfoord> :-/
<dimitern> hazmat, btw why does the deployer still connect to state directly? (somebody mentioned it today)
<hazmat> dimitern, it doesn't
<hazmat> dimitern, you mean juju deployer or unit deployer in juju?
<dimitern> hazmat, juju deployer
<hazmat> dimitern, it doesn't connect to mongo... it primarily uses the api or cli.
<dimitern> hazmat, we'll be closing the mongo port 37017 in 1.20.x soon
<hazmat> dimitern, there's a separate tool .. juju db inspector that does
<dimitern> hazmat, ah, ok then, that's fine
<hazmat> dimitern, primarily the value there (state inspection with db inspector) is being able to look at unit relation data
<dimitern> hazmat, right
<dimitern> hazmat, if it's just that, why not use juju run relation-get ...
<hazmat> dimitern, good question ;-) .. amulet goes through all kinds of tricks to try and do just that (inserting proxy charms and subordinates) for charm testing. prolly cause it predates juju run
<hazmat> marcoceppi, ^
<dimitern> :) i see
<marcoceppi> Oh, it predates the idea of there even being a juju run
<marcoceppi> dimitern: also, juju run relation-get requires you know do several other runs to get relation, relation-id, list of units, etc
<marcoceppi> but juju-run is a "good enough" alternative for sure
<dimitern> marcoceppi, you can run a script that does all that in one juju run call
<marcoceppi> dimitern: you could, and I guess the unit subordinates could install that script
 * marcoceppi wanders off to contemplate this
<dimitern> marcoceppi, yeah, or you can just juju scp it :)
<mbruzek> I am getting an error in Juju  panic: runtime error: invalid memory address or nil pointer dereference
<hazmat> mbruzek, file a bug with the traceback from the machine log
<mbruzek> Thanks hazmat I will do that.  Is there anything else they would need?
<hazmat> mbruzek, juju status output for some context might help..
<katco> i'm having trouble figuring out where juju instantiates log files. can anyone give me a pointer?
<sinzui> perrito666, anyone help
<sinzui> http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/
<perrito666> katco: look for DefaultLogDir
<katco> perrito666: ty
<perrito666> sinzui: going
<sinzui> ^ The job fails for 1.20, but we haven't landed related changes to it
<sinzui> I have amassed a lot of test results, but not consistent failure to say what is wrong
 * perrito666 uses a lot ofadjectives 
<perrito666> sinzui: ... odd as hell
<perrito666> says jenkins taht this broke at https://github.com/juju/juju/commit/e7f77fc1
<sinzui> perrito666, that is master, not 1.20
<sinzui> perrito666, commit 9ece6097 could be what broke the test
<perrito666> sinzui: I just clicked on the link you gave me and then the first failing one
<sinzui> jenkins doesn't understand branches. It is a moron
<sinzui> perrito666, This commit is first failure in 1.20 https://github.com/juju/juju/commit/9ece6097f4b21db8e934885ff9cb1373afa579f4
<perrito666> oh Isee
<sinzui> I suspect cloud issues rather than code changed, but it does indicate brittleness.
<sinzui> perrito666, I am starting a conversation about releasing 1.20.0 without support for this test
<perrito666> sinzui: I dont have the setup for that test at hand
<perrito666> It does look like restore is taking a lot
<perrito666> I am really hoping it is only that
<sinzui> perrito666, setup takes longer. I am updating the test to work with modern HP. I am 30 minutes into it without achieving HA
<perrito666> :|
<perrito666> sinzui: I really need to EOD today but Ill be back later (I need to take 3h bus ride)
<sinzui> perrito666, Thank you for your time
<perrito666> so if you throw in more data I will be glad to take a look
<perrito666> C U ALL
<perrito666> bye
<JoshStrobl> Hey guys, I'm having issues with deploying my charm locally (it sits in /home/vagrant/charms/trusty/). I exported JUJU_REPOSITORY as /home/vagrant/charms and deploy with juju deploy local:trusty/metis however the log (.juju/local/log/unit-metis-0.log) claims the install file does not exist (it does in the metis/hooks). The charm proceeds to stay in a dying state after that (I have to destroy the machine and then service in
<JoshStrobl> order to try again). Any tips? Full unit log at http://paste.ubuntu.com/7738369/
<sinzui> lazypower, mbruzek ^ Do you have any experience with JoshStrobl's issue?
<lazypower> looking now
<lazypower> hey JoshStrobl o/
<JoshStrobl> hey lazypower o/
<mbruzek> Hi JoshStrobl is this a local charm ?
<JoshStrobl> Yes.
<sinzui> JoshStrobl, the file is exec able? 777?
<lazypower> thats interesting... the log leads me to believe the hooks weren't copied over.
<sinzui> for 755
<JoshStrobl> Yes, all the files in hooks are executable
<mbruzek> JoshStrobl, have you checked in a branch to bzr yet?
<mbruzek> JoshStrobl, Do you have some time to share you screen on G+?
<JoshStrobl> mbruzek: I have an existing branch that is out of date. My work takes place via Git and GitHub and the charm will be residing on Launchpad.
<JoshStrobl> mbruzek: Sure thing, let me get my mic set up.
<mbruzek> https://plus.google.com/hangouts/_/canonical.com/juju-solutions
<JoshStrobl> mbruzek: It'll be a few minutes :)
<JoshStrobl> mbruzek: gotta install the plugin :D
<mbruzek> no worries.
<JoshStrobl> mbruzek: the link says the party is over
<mbruzek> JoshStrobl, I am in the room right now
<JoshStrobl> still says it after refreshing :\
<lazypower> JoshStrobl: you may need to clse out of chrome/firefox and restart it, the plugin is notoriously terribad at first time installation.
<JoshStrobl> https://github.com/StroblIndustries/Metis/tree/experimental
<alexisb> sinzui, I responded to your mail, but I am also happy to chat if you like
<sinzui> alexisb, Thank you. I am happy for the leads to speak up.
 * JoshStrobl looks at Microsoft and curses out loud. Then opens up gEdit.
<mbruzek> JoshStrobl, looks like dos2unix would help you out there Josh.
<lazypower> sinzui: found the issue - it was windows line endings in character encodings.
<lazypower> FYI - one more thing we need to be aware of as our story with windows users grows.
<sinzui> hmm
<lazypower> (josh, you're a pioneer using windows line endings in linux.)
<JoshStrobl> I would like to say I'm proud of that, but I'm not.
<JoshStrobl> I don't even know how that happened...
<lazypower> id dint know gedit had that as an option myself
<sinzui> lazypower, maybe charm proof could assist us
<JoshStrobl> I blame gEdit...because you know, it is totally never the developers fault /s
<lazypower> but its nice to know we support the desktop interop
<lazypower> sinzui: really good idea. i'll file a bug
<JoshStrobl> lazypower: ping me the launchpad bug when it's up, I'll mark myself as affected
<sinzui> lazypower, There was a file in juju core's win script that had a single win ling ending in it. IT was maddening to find.
<lazypower> https://bugs.launchpad.net/charm-tools/+bug/1336936
<_mup_> Bug #1336936: Charm proof to detect character encoding <Juju Charm Tools:New> <https://launchpad.net/bugs/1336936>
<JoshStrobl> lazypower: thanks
<lazypower> sinzui: wow - epic. a single line?
<lazypower> how does that even happen?
<lazypower> smallest broken merge, ever.
<sinzui> yeah, how does that happen?
<JoshStrobl> You guys saved me several hours and probably a few euro at the pub. You guys rock.
<lazypower> JoshStrobl: we aim to please. tell your friends about us.
<JoshStrobl> lazypower: Will do.
<JoshStrobl> Oh and by the way, the dos2unix tool works flawlessly. I'd recommending making note of that tool in the docs for Winderps users. I was able to just do dos2unix * in the hooks directory and it converted all the scripts to unix "format".
<wwitzel3> fwereade: ping
<davechen1y> wallyworld__: http://paste.ubuntu.com/7739086/
<davechen1y> more problems with the openstack provider
<davechen1y> wallyworld__: gah, sorry, here is the real eror
<davechen1y> http://paste.ubuntu.com/7739090/
<davechen1y> bug report coming
<katco> wallyworld__: hey another question, looking at this comment. it says that the default for rsyslog is 0640; is that sufficient, or do we want to exclude the group as well?
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1336980
<_mup_> Bug #1336980: provider/openstack: map ordering issue in tests <juju-core:New> <https://launchpad.net/bugs/1336980>
<davechen1y> spot the bug
<katco> wallyworld__: ah, and i remembered my other question. open to the room as well: is there a faster way to recreate the log-files in /var/log than to destroy-environment and bootstrap a new one?
<wallyworld__> katco: on a call, will respond soon
<katco> wallyworld__: no worries and no rush. thank you, sir!
<wallyworld__> katco: sorry, off call now. today is my meeting day, lots of them. using juju proper, there's no faster way that i know of. you could though change the rsyslog conf file and stop and restart rsyslog (deleing the all machine log in between) to see any permissions changes take effect
#juju-dev 2014-07-03
<menn0> wallyworld__: ping?
<sinzui> Oh fab, CI thinks trunk is bzr because the first 8 chars of the hash are numbers
<wallyworld> lol
<wallyworld> :-(
<menn0> wallyworld: do you have time for a quick chat about gridfs?
<mwhudson> hahaha
<wwitzel3> someone have time to hangout, I need an ear to bend about the approach of this refactoring fwereade has suggested to me.
<wallyworld__> thumper-afk: meeting? when you get back?
<wallyworld__> axw: you had any breakthroughs on the session closed errors etc?
<axw> wallyworld__: nope
<wallyworld__> it will probably be something simple once the cause is found
<wallyworld__> axw: so you checking that precise cloud init supports the new apt feature?
<axw> wallyworld__: I have checked it works with cloud-init, I'm just checking the sshinit bit works on precise too
<axw> no reason for it not to, but I should be thorough
<wallyworld__> great, thank you
<wallyworld__> just checking you aren't stuck for stuff to do
<wallyworld__> the address change stuff still wip i assume
<axw> wallyworld__: well, not actually working on that atm. I want to get some more agreement first. I did finish the unit config-change bit
<wallyworld__> np, do you need me to poke william?
<axw> wallyworld__: need some more discussion with hazmat I think
<wallyworld__> ok. the next largish chunk of work is to replace http storage. but i'd like to see if we can get the tests sorted first
<axw> okey dokey
<wallyworld__> worth spending some time on the tests as it will have a big affect on team velocity plus we will learn lessons that can be shared and used
<axw> wallyworld__: I think you said perrito666 was working on separating StateInfo from storage?
<axw> I think that will be a prereq to get it to work
<axw> sure
<wallyworld__> yeah, there's supposed to be a new api or some such - that's what william told me
<wallyworld__> so we can do the http stuff and also replace cloud storage
<wallyworld__> for tools, charms
<wallyworld__> but i also have to move the storage stuff to a separate repo
<wallyworld__> but i want martin to get the lander sorted out first
<wallyworld__> i'll check the StateInfo progress also
<katco> wallyworld__: unit tests pass; doing empirical testing now, and should have a pull request contingent on that
<perrito666> wallyworld__: axwI am not working on such feature
<wallyworld__> katco: great :-D
<perrito666> wallyworld__: axw not that I can remember
<axw> perrito666: ah ok. maybe someone else
<wallyworld__> perrito666: william indicated there would be an api to allow state server addresses to be found without having to reply on a file stored in environment storage
<axw> katco: hello! you're working rather late aren't you?
<wallyworld__> maybe it wasn't you? i thought i was but i could be wrong
<katco> axw: i am :p but i'm interested. i want to get this change in so i have a clean plate tomorrow. i won't make a habit of it ;)
<katco> i also got distracted by my stupid addiction to food.
<waigani> axw: do you have an example of an error path releasing resources? I know you and davecheney have been working on it recently. What's the correct and incorrect way now?
<perrito666> wallyworld__: mm, I am about to sleep now but if you could email me that It would be greatly appreciated we might be only having misscomunication due to the fact that  should be sleeping
<wallyworld__> ok :-)
<wallyworld__> good night
<perrito666> wallyworld__: tx
<davecheney> today in "Dave waits for the build bot": listening to podcasts and filing bugs :(
<axw> waigani: I just meant make sure files and such are closed when a function exits
<waigani> ah right
<axw> "defer f.Close()" usually
<waigani> sure
<davecheney> github.com/juju/juju/juju/testing/conn.go
<davecheney> my god, who thought that was a good idea
 * katco pulls up a seat next to davecheney. ah, bootstrapping juju machine agent. a fascinating show.
<wallyworld__> katco: well, you'll have 2 clean plates - one the food was on the the other your todo list :-)
 * davecheney ages visibly waiting for juju bootstrap
<axw> davecheney: you should disable apt-get upgrade... oh wait.. :)
 * davecheney grins, morbidly
<waigani> it's like a magic spell - you have write say 'juju' at least three times for it to work ;)
<axw> wallyworld__: bootstrapping precise works with eatmydata
<davecheney> hmm, https://bugs.launchpad.net/juju-core/+bug/1337038
<_mup_> Bug #1337038: cmd/juju: map ordering test failure <juju-core:New> <https://launchpad.net/bugs/1337038>
<wallyworld__> axw: \o/
<davecheney>  i wonder how this happened
<axw> wallyworld__: or rather, it works despite eatmydata not being installed
<axw> by default
<davecheney> http://img3.wikia.nocookie.net/__cb20140108021302/villains/images/2/27/Beetlejuice.jpg
<katco> wallyworld__: i suppose i should assign this bug to myself on launchpad?
<wallyworld__> katco: yes, sorry i should have mentioned that
<axw> I'm tempted to write a program to transform the tests so that it randomise everything that isn't guaranteed to be deterministic
<katco> wallyworld__: no worries... i just wasn't sure what the workflow was
<wallyworld__> katco: and before we moved to github, it would be marked as fix commited automatically after the branch  merged but now we need to do it manually
<wallyworld__> axw: or upgrade Go to use the new map implementation :-)
<katco> wallyworld__: ew bummer. maybe we can do a jenkins or github trigger to update it. i assume launchpad has an api?
<wallyworld__> katco: yeah, it's on the "do this to make things nicer once the core stuff works" list
<katco> wallyworld__: should i flag this fix for a milestone? or is that someone elses purview?
<katco> wallyworld__: gotcha. i think i have a slide in my presentation that says something along the lines of, "your iteration is the only thing that will happen again and again. making it better has multiplicative returns"
<wallyworld__> katco: normally the bug would be assigned a milestone, usually "next-stable-release", and then moved to the correct actual milestone one the release number milestone gtes created
<katco> wallyworld__: ok, i'll do that
<wallyworld__> katco:  someone would normally do that, but i got distracted as I just picked out some simple bugs for you that were not on the radar so to speak
<katco> wallyworld__: oh ok. np. thanks for the bugs :)
<wallyworld__> anytime, i have *lots* more :-)
<katco> gee, sorry. i only fix 1 bug per team. (cough)
<katco> ;)
<axw> wallyworld__: I think we should remove the second "go test" from the lander now
<axw> it's just holding up the queue now
<wallyworld__> axw: i'm inclined to agree, but i think we can (and do) still get spurious failures on full parallelisation?
<axw> wallyworld__: I've seen it once since I made my change
<axw> wallyworld__: I think that's low enough rate to get people to resubmit
<wallyworld__> true, and if there's a real failure, it will report quicker
<axw> right
<wallyworld__> makes it harder to now if we've fixed the race too :-)
<wallyworld__> know
<axw> heh. I'll see if I can reproduce the bugs in a VM with slower I/O
<wallyworld__> axw: martin should be calling the bog standard script from the release tools repo - but i think he still needs to switch over. i'll get him to turn off retry when he does that today/tonight
<axw> cool
<wallyworld__> katco: the logging stuff - loggo comes with a default stderr writer registered. the various agents are configured to run via upstart, and have their stdout/err directed to a log file - see juju/upstart/service.go
<wallyworld__> so that's how the log calls get stuff to a log file
<katco> aha!
<katco> wallyworld__: thank you!
<wallyworld__> katco: so, next step is to figure out how to tell upstart how to create the file with different permissions
<sinzui> wallyworld__, If I read this run correctly, only 2 tests fail in lxc with -p 2
<wallyworld__> that i do not know off hand
<wallyworld__> sinzui: which run?
<sinzui> wallyworld__, looks like 1.20 at f325c87bd1dc92ac58bdc347568a6d901b607172
<wallyworld__> sinzui: with andrew's change to use tmpfs, tests are now very reliable. so more may fail in lxc due to slower i/o as it seems slow i/o has a repeatable negative impact on the tests
<wallyworld__> sinzui: you mean that the above revision looks like it is good for release as 1.20?
<waigani> davecheney, menn0: thanks for your input :)
<sinzui> wallyworld__, that log claims to be the 1.20 we were testing all day
<menn0> waigani: no problems. that list might well help me.
<waigani> nice!
<sinzui> wallyworld__, I see a new round of tests started with master. I can run the lxc version of the test with this run
<wallyworld__> sinzui: can you point me at the log toy refer to?
<wallyworld__> ok
<katco> wallyworld__: ok, i think i've submitted a pull request. what would i paste here to get a review?
<wwitzel3> so I have a package in environs that contains a bunch of interfaces and struct all related to exposing parts of the environ to state. Right now I have that package named "hackage" .. obviously that won't work, looking for suggestions.
<wallyworld__> katco: you can reasonably expect the on call reviewer to pick it up. but you can also paste the pull request url here and beg offer $$$$ for a review. i only accept $100 bills
<katco> rofl
<katco> well here it is: https://github.com/juju/juju/pull/232
 * menn0 thinks wallyworld__ hates him ... :)
<katco> i expect that i have done something wrong
<katco> so let me know :p
<sinzui> wallyworld__, This the log I was reading: http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1115/consoleText
<wallyworld__> katco: you for getting something..... ?
<katco> oh right
<wallyworld__> menn0: why?
 * katco hands wallyworld__ a $100 bill and a wet trout
<menn0> I've been ping and PMing you all day
<menn0> wallyworld__: ^^
<menn0> wallyworld__: but no response
 * menn0 puts on big sad puppy dog eyes
<wallyworld__> menn0: sorry, i often miss private pings because i don't hear the notification and your nic is off my screen, and also my connecton for irc has been flakey :-(
<wallyworld__> sorry :-(
<katco> oh wow davecheney is all over that. thanks :)
<wallyworld__> menn0: also you didn't give me money like katco just did
<menn0> wallyworld__: so that's what it takes these days...
<katco> psst, menn0, it was monopoly money. he doesn't notice!
<menn0> katco: thanks for the tip. I wonder if he takes dogecoin?
<katco> LOL
<wwitzel3> menn0: also, he told me he hates you
<wwitzel3> :P
<menn0> wwitzel3: I KNEW it!
<wwitzel3> menn0: hey wanna help me name something? :)
<menn0> wwitzel3: ummm sure
 * menn0 wonders if this is a trap
<wallyworld__> wwitzel3: i hate you too :-)
<wwitzel3> menn0: see about comment .. I have a package currently called hackage in environs that contains interfaces and a struct that is used to represent information needed about an environ to state.
<wwitzel3> s/about/above
<wallyworld__> sinzui: that's not a bad test run for being inside lxc - only a few things to fix :-)
<katco> ok so now i've commented with $$merge$$, and jenkins will pick that up and perform a build and then merge if it's clean?
<wallyworld__> katco: yep
<wwitzel3> wallyworld__: haha, well at least I know you feel something! :P
<katco> nice! which build am i interested in?
<wallyworld__> wwitzel3: there's a line there but this is a family channel
<wwitzel3> wallyworld__: hah
<wallyworld__> katco: http://juju-ci.vapour.ws:8080/job/github-merge-juju/
 * menn0 thinks
<wallyworld__> katco: but the queue is full of other jobs right now
<katco> wallyworld__: ty. how long does it usually take the worker to pick that up? assuming workers are free
<wallyworld__> katco: we are moving the landing job to it's own slave soon
<katco> cool
<wallyworld__> katco: you will see an email within a minute
<axw> katco: you need to make your juju membership public on github
<wallyworld__> if the queue is not blocked
<axw> otherwise the bot ignores your comment
<wallyworld__> oh yeah, that too
<axw> katco: https://github.com/orgs/juju/members
<rick_h__> wallyworld__: whatever happened to cake being the official offering?
<wallyworld__> rick_h__: cake can't buy love
<wallyworld__> $$$$ can
<rick_h__> wallyworld__: thought back in the LP days cake was the offering for things, sad to see that sell out and go all $$
<menn0> wwitzel3: what kind of stuff about environs is being exposed to state?
<wallyworld__> rick_h__: indeed. but these here are crazy time. new world order. survival of the fittest
<rick_h__> hah
<katco> axw: ok thanks, i've done that
<wwitzel3> menn0: ConfigValidator, PrecheckerInstance, EnvironCapability, and InstananceDistributor .. state combines them all under a Policy interface to represent a given environ.
<wallyworld__> katco: your job is now pending
<menn0> wwitzel3: environ_policy or environ_state_policy?
<menn0> wwitzel3: environ_state?
<menn0> wwitzel3: not that great I realise...
<wwitzel3> menn0: yeah, was thinking something along those lines, environs already has a statepolicy which does some of the marshalling of the data, so I was thinking of creating an environ_state and moving that under along with the current "hackage" stuff.
<wwitzel3> menn0: but then, I hate to use state again anywhere, lol
<axw> wwitzel3: are there new bits in hackage, or are you just moving existing things?
<menn0> wwitzel3: yeah - it sounds reasonable (based on my limited understanding on what you're doing)
<wwitzel3> axw: just moving things so that environs no long depends on state
<axw> ok
<axw> environs/policy?
<wwitzel3> axw: I was running in to some import cycle issues when implementing the EnvironmentAPI and fwereade pointed out this would be good chance to sever that dep which really isn't needed.
<katco> wallyworld__: so say this fails for some reason, what is the workflow?
<wallyworld__> katco: you fix the failure, push, and type $$merge$$ again
<wwitzel3> axw: hrmm, yeah that actually makes sense since it is the environ policy and the whole point is that is doesn't care about state.
<wallyworld__> katco: if it's a suprious failure in the bot, just type $$merge$$
<wwitzel3> axw: I guess I thinking about it too much
<axw> wwitzel3: yup. it's just a way for things to hook into environment behaviour
<rick_h__> wallyworld__: dont' you all have to remove the 'merge request accepted' comment in github?
<katco> wallyworld__: so i should be very interested in the results of this job, as it's on me to fix the merge? is the merge gated? will it still merge if the build fails?
<wallyworld__> rick_h__: we don't / haven't been
<rick_h__> wallyworld__: and the extra $$merge$$ should do nothing. :/
<wwitzel3> menn0, axw: thanks, I will go with environs/policy and people can suggest alternatives during review if they so desire :)
<wallyworld__> katco: merge is gated, yes
<katco> great
<rick_h__> ummm, ok. That's interesting
<wallyworld__> katco: won't merge untl the tests pass
<wallyworld__> rick_h__: why?
<menn0> wwitzel3: sounds ok to me
<katco> i was interested that the tests take so long. is it b/c it's tied into mongo?
<rick_h__> wallyworld__: because that's the way I wrote it to work. Extra $$merge$$ aren't supposed to do anything
<rick_h__> wow, you guys are crazy, 35 running pull requests
<axw> wwitzel3: SGTM. I *think* you just want to move the interfaces in there, and leave the statepolicy.go (impl) stuff where it is
<axw> wwitzel3: does that sound right?
<wallyworld__> rick_h__: seems to work for us :-)
<rick_h__> wallyworld__: yea interesting. Trying to figure out why. lol
<axw> wwitzel3: just so the state and environs packages have a common interface to reference
<axw> without depending on one another
<rick_h__> wallyworld__: heh so it works by accident fyi. The idea was that the bot checks if there's 'merge request accepted' comment and if so, it doesn't rerun the merge job. https://github.com/juju/juju/pull/224
<wwitzel3> axw: yeah, I realized that looking at it, you're right.
<rick_h__> wallyworld__: so the way to rerun is supposed to be to remove that 'merge request accepted' comment.
<wallyworld__> rick_h__: lol ok
<rick_h__> wallyworld__: glad it's working for you, I'll have to make sure not to fix that 'bug' :)
<wallyworld__> rick_h__: it's now a feature :-)
<rick_h__> hah, extra added feature
<katco> curious why my job doesn't have any text on it
<davecheney> https://github.com/juju/juju/pull/233
<davecheney> axw: thanks for the review
<davecheney> the rabbit hole just keeps going
<axw> davecheney: nps
<katco> yay i landed my first change :)
<katco> thank you for the help everyone!
<davecheney> katco: and you didn't break the build
<davecheney> nor did you delete the whole CI infrastructure
<davecheney> (long story)
<katco> there's still time! i can make another change!
<davecheney> so, thumbs up!
<katco> give me a chance!
<rick_h__> davecheney: lol
<sinzui> We can put CI back in a couple hours, all that ci machines can be deploy with juju
<sinzui> This is the 3rd ci because canonistack lost the first 2
<rick_h__> sinzui: yea, we have some sublte steps. The lander, system deps, etc are manual still
<rick_h__> sinzui: though we're going to work on automating it more.
<rick_h__> sinzui: but we had a new team member wipe out CI on his frist day on accident
<rick_h__> sinzui: so it's the nice story going around
<sinzui> rick_h__, :)
<thumper> wallyworld: sorry, have been having a sick day and away
<thumper> thought I might have come back after lunch
<thumper> but still not feeling so shit hot
<thumper> so I'm going to sign off
<thumper> and see how I am tomorrow
<thumper> wallyworld: perhaps we can chat tomorrow?
<sinzui> rick_h__, there are 14 machines in ci 3's env, but the machine count is 53. I have lost 40  machines in the last 3 months
<rick_h__> sinzui: ouch
<rick_h__> sinzui: we're up to 4 in one env now, but only because of the ec2/co-locating limitation now
<wallyworld> thumper: sure np. i'm off tomorrow. the main thing was the resources stuff. but you can reply to the email and we have a tentative meeting next week with rick_h__ and friends
<rick_h__> bwuhahaha, how can I ruin more of thumper's days?
<wallyworld> katco: sorry, was on another call
<wallyworld> katco: you can click the console output link to see the job text
<katco> wallyworld: np. it landed
<sinzui> davecheney, Maybe you want to look into this issue soon, or at least advise someone about how to fix it https://bugs.launchpad.net/juju-core/+bug/1337063
<katco> yeah i had stood up jenkins at my last shop :)
<wallyworld> katco: \o/ yay, you are now *officially* a juju-core team member :-P
<katco> woohoo!
<rick_h__> lol congrats katco
<katco> now to grok more so i can contribute more difficult changes
<wallyworld> rick_h__: or should that be commisserations :-)
<katco> haha
<rick_h__> wallyworld: not sure what kind of crappy medal you all hand out to the new folks :P
<katco> nah we will do great things together.
<wallyworld> ah, the newbies are always so optimistic :-)
<rick_h__> katco: what TZ are you?
<katco> alexisb told me i get $100 for each commit? is that right?
<katco> rick_h__: GMT-6
<davecheney> sinzui: we have two options
<davecheney> 1. roll back that change
<wallyworld> katco: yep, here you go .... $100
<rick_h__> katco: oh get out of here
<katco> woo!
<davecheney> 2. fork the ssh/terminal package
<rick_h__> katco: don't be like wallyworld and I working at night.
<sinzui> yuck for 2
<wallyworld> rick_h__: it's not my night yet :-)
<wwitzel3> rick_h__: haha, was just going to say, I know what TZ you're in :P
<katco> lol, i just wanted to get that 1st change in while wallyworld was on
<rick_h__> wallyworld: yea, but I'll see you in my morning your night and we know it :P
<wallyworld> lol
<rick_h__> wwitzel3: some of us don't know any better any more, but katco has time yet to get on the right path
<wallyworld> last night i had a night off :-) drinking with friends :-)
<rick_h__> wallyworld: woot! I'm going into the woods for the holiday. No cell coverage
<rick_h__> wallyworld: only a 'clubhouse' with 500kbs wifi connection to the world
<wallyworld> rick_h__: enjoy that. fireworks in the forrest not so good tough
<rick_h__> wallyworld: there's a lake they set them off over
<wallyworld> rick_h__: 500kbps. party likes it's 2001 :-)
<rick_h__> hoping to get some nice pics with my new camera gear
<wwitzel3> rick_h__: nice, I'm going to shoot toxic powdered metal in to the sky after lighting it on fire.
 * wallyworld loves photography
<rick_h__> wwitzel3: woot!
<wallyworld> rick_h__: what gear you got?
<rick_h__> wallyworld: yea, my new hobby, having fun
<rick_h__> wallyworld: pany gx7 micro 4/3 with a suite of lenses, mefoto tripid, etc
<wwitzel3> he uses iPhone + Instagram
<wallyworld> lol
<rick_h__> https://www.flickr.com/photos/7508761@N03/
<rick_h__> lol
<rick_h__> no apple allowed!
<wallyworld> rick_h__: nice. i got a nikkon D7000 with nice wide angle, a 70-300 tele, and 35mm prime
<wallyworld> rick_h__: those portraits are nice
<wwitzel3> I have Sony aSomething or other with 3 lenes .. and I use my phone for all my pictures :/
<wallyworld> wwitzel3: rotrl
<rick_h__> wallyworld: yea, learning and practicing
<rick_h__> wwitzel3: heh, that's why I went with micro 4/3. It's smaller and closer to something I can carry around
<wallyworld> rick_h__: just no naked selfies, PLEASE
<rick_h__> though with my 100-300 lens (200-600 effective) it's a bit big
<wwitzel3> rick_h__: yeah, I like that form factor, will probably sell my full size and try it out.
<rick_h__> https://www.flickr.com/photos/7508761@N03/14497325923/ the boy with a 45mm oly prime I got. I just focused on the wrong eye for this pic :/
<wwitzel3> rick_h__, wallyworld: the only thing I really use it for is doing portraits, I have a fixed focal length lense.
<wwitzel3> "How do you zoom out?" .. "With your feet"
<rick_h__> https://www.flickr.com/photos/7508761@N03/14423103076/
<wallyworld> wwitzel3: yep, i here you. i use my 35mm prime as my main lens
<wallyworld> hear
<rick_h__> heh, ok I need to close up shop and go to bed at some point, have fun all.
<wallyworld> rick_h__: see ya
<wwitzel3> rick_h__: ttyl
<rick_h__> wallyworld: thanks for the notes/docs, and so forth. Will look forward to causing each other work soon :)
<wallyworld> rick_h__: yeah, right back at ya
<wallyworld> rick_h__: i really want to porgess this stuff :-)
<wallyworld> progress
<wallyworld> axw: if we want to see lots of spurious failures, look at the output of the job to run tests inside lxc that sinzui set up eg http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1116/console
<wallyworld> and 1115 before that etc
<sinzui> wallyworld, yeah
<sinzui> I was just pondering a --safe-retry switch to just run tests with -p2, and do it twice
<wallyworld> if we make makes that job happy, our test suite will indeed rock
<axw> wallyworld: ok
<axw> looking...
<axw> yuck :(
<wallyworld> sinzui: not a bad idea. we are considering turning off retry option for landing tests now that they seem a lot more reliable running with tmpfs
<wallyworld> axw: yeah, shows how far we've got to go
<wallyworld> because we do have ambitions of running the tests isolated in lxc
<sinzui> wallyworld, I don't know what your considering. I try tests 4 times with all procs. I was thinking of trying 2 times with only 2 procs. It might be faster on average
<wallyworld> sinzui: for the landing tests to gate commits to trunk, we have been running once and then again with -p 2 if the first run failed. now the tests are more reliable, we are looking to turn off the retry option and just fail the run
<sinzui> wallyworld, My samples of those tests shows that -p 2 was making them pass most of the time, just run with -p 2
<wwitzel3> wallyworld, axw: https://github.com/juju/juju/pull/234 .. I'm off for the night, but any feedback would be great.
<sinzui> well, I will set that up in some parallel testing to get so better data
<wwitzel3> wallyworld: the Environment API implmentation is "done", but I'll want to get #234 in first, since I've re-worked it branched off that.
<wallyworld> sinzui: that's a fair bit slower, and since axw switched to tmpfs, we have had maybe 1 spurious falure out of several runs
<axw> wwitzel3: no worries, will take a look a bit later.
<sinzui> That would be nice wallyworld
<wallyworld> wwitzel3: looking, thank you
<wwitzel3> wallyworld: so once I get #234 merged, I'll get the EnvironCapability API stuff up for review.
<wallyworld> great :-)
<wallyworld> sinzui: the tmpfs change shows how fragile our tests are and that we have work to do
<wallyworld> but for now, it has helped the landing tests be more reliable
<davecheney> wallyworld: axw nice one
<davecheney> the bot is landing changes in 10 minutes
<davecheney> well, it runs the tests in 10 minutes
<davecheney> setup is still a few minutes
<davecheney> but it is significantly better than a few days ago
<wallyworld> davecheney: set up will disappear "soon" also
<wallyworld> davecheney: and using tmpfs marks our poor tests/race conditions, but gives us scope to fix without holding people up
<wallyworld> masks
<davecheney> wallyworld: i always mount /tmp with a ramfr
<davecheney> wallyworld: i always mount /tmp with a ramfs
<davecheney> i don't think it's an invalid setup
<wallyworld> davecheney: slow i/o should not cause tests to fail in a racey way
<wallyworld> the setup is valid but the tests ares till broken
<wallyworld> s/broken/suboptimal
<wallyworld> davecheney: and there's lots of failures running the tests inside an lxc container
<wallyworld> due to the same/similar root causes
<wallyworld> axw: nice doc
<axw> wallyworld: thanks
<axw> is that addition of supported providers ok?
<axw> for automatic spread
<wallyworld> axw: yep, +1. thanks
<jcw4> PTAL https://github.com/juju/juju/pull/216
<rogpeppe> ha, i've just seen this: https://godoc.org/github.com/dropbox/godropbox/errors#Wrap
<wallyworld__> jam1: so we currently use a mechanism at bootstrap time to save the inst id of the bootstrap machine of cloud storage ie bootstrap.SaveState bootstrap.LoadState etc. Do we still need that with all the api and login etc changes since that was all done?
<wallyworld__> s/of cloud storage/in cloud storage
<wallyworld__> axw: agree existing tests are shitty. sadly i think if we truly want to fix all the races we'll need to touch a lot more of them
<wallyworld__> s/touch/rethink
<axw> yeah :/
<axw> I cna't see a way to do it without major changes
<wallyworld__> understood :-(
<wallyworld__> might be a chance to blaze th trail
<TheMue> morning
<wallyworld__> Guten Morgen
<axw> wallyworld__: we *could* get rid of the provider-state file from storage (with some minor updates to bootstrap?), but if the addresses change and the client does not have any valid addresses it has no way to get back in
<TheMue> wallyworld__: hehe, yes o/
<wallyworld__> axw: agreed. i had heard mention though we were working around that somehow
<wallyworld__> that's what i'm not sure about the status of
<axw> ok
<wallyworld__> i'm not sure how though as if we don't know the address, how do we discover the new one
<wallyworld__> will be impossible t get rid of cloud storage without figuring this out
<axw> wallyworld__: for the CLI, there's options, but I don't know about agents
<axw> wallyworld__: for the CLI we could tag instances and query via the provider interface
<wallyworld__> axw: yeah, that did occur to me also. not sure how portable it would be
<axw> wallyworld__: for agents, we could do something horrible like push the addresses to each of the agents via SSH
<axw> (from the state server)
<wallyworld__> juju run new-addresses :-)
<axw> yeah that'd work I guess
<wallyworld__> i was not really serious :-)
<wallyworld__> but it could be something at the correct level of abstraction
<davecheney> axw: EUREKA!
<davecheney> i've caught mgo doing something stupic
<axw> davecheney: ?!
<davecheney> stupid
<axw> ooh
<davecheney> http://paste.ubuntu.com/7740699/
<axw> buh
<davecheney> the mgo pinger, v2/mgo/server.go
<davecheney> has a loop
<wallyworld__> davecheney: don't you mean "something else"
<mattyw> morning folks
<davecheney> which is supposed to exit the pinger if there is an error
<wallyworld__> oh you mean the driver, not mongo itself
<davecheney> except it is very selective about the thigns it consisders and error
<davecheney> thos prints 'pinger discarded'
<davecheney> are all things the pinger things are _not_ errors
<davecheney> and so stays alive, probing a dead ass mongo db over and over again
<axw> interesting
<axw> so that's why we have so many goroutines lying about?
<davecheney> yup
<davecheney> especially in the tests
<wallyworld__> davecheney: nice pickup, well done
<axw> do you think it has anything to do with "session already closed"?
<davecheney> axw: it is at least related
<davecheney> although probbably not the direct cause
<davecheney> ther is other dodgy shit happening, for sure
<dimitern> mgz, wallyworld__, what instance type are we using for the github lander bot?
<axw> m3.xlarge
<dimitern> nice!
<wallyworld__> yup
<davecheney> dimitern: an m3 xlarge is roughly 80% of the speed of my two year old x220
<dimitern> I've just seen the console log with the tests - it takes 80s to run the joyent tests - it takes like 650s on my machine
<davecheney> this cloud thing isn't good value
<wallyworld__> davecheney: you going to email gustavo?
<davecheney> wallyworld__: when I have something concrete
<wallyworld__> ok
<axw> davecheney: it *should* break out of the loop when the mongoServer is closed
<davecheney> axw: yup
<davecheney> and it probably did a long time ago
<davecheney> but i suspect there are paths that can return an error aside from errServerClosed [sic]
<davecheney> especially when we mix in timeouts, tls and your own custom dialer functions
<axw> davecheney: ah right, it doesn't check that flag in the other error condition
<axw> doh
<davecheney> axw: insert sad trombone
<davecheney> axw: its on my list of things to glare at
<axw> goodo
 * axw glares at other flaky tests
<davecheney> axw: at the moment I am composing a manifesto entitled "teardownTest considered harmful"
<davecheney> i want to replace all our teardown logic with cleanupSuite style logic
<davecheney> ie, somehign like
<davecheney> st, err := state.Open(...)
<davecheney> c.Assert(err, gc.IsNil)
<davecheney> s.State = st
<davecheney> s.DeferTest(func( ...))
<davecheney> or even
<davecheney> s.DeferTest(s.State.Close())
<dimitern> jam1, hey, i was thinking - now that the apiserver listens by default on ipv4 and ipv6, do we need the test suite at all?
<axw> davecheney: SGTM, but we need to be careful about mixing the two. I've had to fix things where a cleanup happened after a teardown but should have come before
<davecheney> axw: yup
<davecheney> ordering will continue to be an issue
<davecheney> at the moment, as a generalisation all the teardown stuite / test stuff is written expecting the setup to succeed
<davecheney> which makes sense
<davecheney> what does a TearDownTest do ?
<davecheney> it tries it's hardest to undo everything setup test did
<davecheney> but there is a communication issue here
<davecheney> for every action that setup test / suite does
<davecheney> we need to signal somehow to teardown that the action succeeded, not exploded
<davecheney> so I think a pattern that looks like a test or suite scoped defer makes more sense than the current way teardown works
<dimitern> hey davecheney - any progress on adding the on call reviewer to the calendar?
<davecheney> dimitern: none whatsoever
<davecheney> i've looked at the spreadsheet a few times
<davecheney> but the care factor is very low
<davecheney> hmm
<davecheney> it's thurstday today
<dimitern> right :)
<davecheney> which means' i'm going to have to own up to not doing it ...
<davecheney> still, tim too like three months to not do something on his action list
<davecheney> i think I should be ok
<davecheney> axw: pinger discarded error: dial tcp 0.1.2.3:1234: invalid argument
<davecheney> this one is very concerning
<davecheney> that says that mgo is starting a pinger before the first db connections has been opened
<davecheney> so it's going to sit there
<davecheney> trying to dial, and will never get errServerClosed, becuase the server will never be opened ...
<axw> :/
<davecheney> i think i can open a bug on that basis
<davecheney> https://codereview.appspot.com/101670043/
<davecheney> these two constants are side a pain the backside
<voidspace> morning all
<mattyw> axw, still awake?
<axw> mattyw: otp
<mattyw> axw, ok no problem, I'll just keep typing and you can response whenever is good
<mattyw> axw, just wanted to check I understood your feeback. For -n 1 just returning the error is fine. for -n > 1 we should just return the error (failed to create n machines). And then the second part is make sure all error messages go to stderr
<voidspace> hmmm... it looks like initiating a replicaset with ipv6 ip address (rather than hostname) fails
<voidspace> trying with ipv4 ip address
<axw> mattyw: at the moment the single error case just returns the error. the multi-error case prints *and* returns the error. I think we should be consistent between single and multi
<axw> mattyw: so actually probably the best thing to do is to create an error that will look nice when printed by the cmd code
<axw> (for the multi error case)
<axw> and not print them in there at all
<axw> mattyw: make sense?
<axw> atm the multi-error case will print twice: once in the addmachine.go code, and once in the cmd code
<axw> (because an error was returned)
<mattyw> axw, I think I understand. In both cases don't print, just contruct a nice error and return it. In the single error case it's fine as it is. In multiple errors contruct an error that joins all the errors that happened
<axw> mattyw: yup
<mattyw> axw, got it, thanks for the feedback
<axw> nps
<voidspace> jam1: I seem to be bumping into this with ipv6 replicaset configuration
<voidspace> jam1: https://jira.mongodb.org/browse/SERVER-11664
<voidspace> jam1: I get the error in this bug report when I create a replica set with ipv6 addresses
<voidspace> jam1: "couldn't initiate : can't find self in the replset config my port"
<voidspace> it says resolved
<voidspace> the report is against 2.4.8, Trusty has 2.4.9
<jam1> voidspace: that bug says it is a dupe of : https://jira.mongodb.org/browse/SERVER-5436
<voidspace> indeed
<voidspace> which is unresolved
<voidspace> even if you disambiguate the ipv6 address ([::1]:port) it serializes it in an ambiguous form it seems
<jam1> voidspace: the thing is https://jira.mongodb.org/browse/SERVER-5436 says ::1:PORT is bad, but it should be using [::1]:PORT which is not ambiguous
<voidspace> that's what I'm using
<voidspace> right
<jam1> voidspace: so what are the actual values that you're setting?
<voidspace> [::1]:port
<voidspace> where the port comes from the MgoInstance
<voidspace> fmt.Sprintf("[::1]:%v", inst.Port())
<voidspace> and that code works fine for creating and dialling a mongo instance
<voidspace> it's just the replicaset config that fails
<jam1> voidspace: sure, the bug for https://jira.mongodb.org/browse/SERVER-11664 is saying that it can't find its own address in your replicaset config, so we have to figure out what it thinks its own address is.
<jam1> voidspace: ugh... https://jira.mongodb.org/browse/SERVER-9612
<jam1> "Backport: No"
<jam1> "Fix Versions: 2.7 desired"
<voidspace> :-/
<TheMue> voidspace: jam1: shit
<jam1> voidspace: TheMue: this is why we investigate if Mongo *actually* supports ipv6 :)
<TheMue> jam1: but with the hope to get a better result :D
<voidspace> maybe this is why they disable it by default
<jam1> voidspace: https://jira.mongodb.org/browse/SERVER-5436 also says "Fix Versions: 2.7"
<jam1> so not even 2.6 has the fix... ?
<jam1> vladk: you've poked around the mongo source code, can you confirm if things might be better in 2.6?
<voidspace> jam1: 5436 is unresolved anyway
<voidspace> jam1: so not fixed yet
<jam1> voidspace: same for https://jira.mongodb.org/browse/SERVER-9612
<jam1> now, we don't use "mongos" in our setup (I believe)
<jam1> TheMue: this is the kind of Port/Address parsing that is broken in IPv6 that I was worried we were doing in *our* code, looks like we aren't but Mongo is.
<voidspace> jam1: we could use /etc/hosts and hostnames...
<TheMue> jam1: so weâve done our homework ;)
<voidspace> coffee
<mwhudson> jam1: there is no mongos in juju-mongodb so i hope you don't try to use it :)
<voidspace> mwhudson: mongo serialises ipv6 addresses in a format it can't then parse...
<TheMue> jam1: when testing the go funcs I first stumbled with addresses like ::1:12345 too and got an error returned
<mwhudson> voidspace: yeah, sounds like fun
<voidspace> mwhudson: yep :-)
<jam1> voidspace: well "can't parse correctly" it parses it, just gets the wrong answer :)
<vladk> voidspace: I have tested replicaset, I didn't use brackets in host string and specified port: host: "fd00::30:27017". It worked.
<TheMue> vladk: aha? *wonder*
<voidspace> vladk: I could try getting the address of this machine instead of ::1
<voidspace> just trying ::1:port
<voidspace> not looking good so far (either the test passes quickly or I have to wait for the timeout to see the error)
<voidspace> so getting coffee
<vladk> voidspace: see my yesterday doc: https://docs.google.com/a/canonical.com/document/d/1mfLSIUAV5V7_uj3oxBDIGxlT5jPOKIXsWlmyO6pa23Y/edit
<voidspace> vladk: ok, so your rs.initiate call works
<voidspace> vladk: that's where in the code it's dying for me
<voidspace> ok, so with "::1:port" it fails for a very different reason that might be fixable
<voidspace> &mgo.QueryError{Code:13144, Message:"exception: need most members up to reconfigure, not ok : ::1:40577", Assertion:false}
<voidspace> jam1: so the specific bug is that it always treats the last :port as :port
<voidspace> jam1: so long as we're *always* specifying a port (which we are) I think we avoid that bug
<voidspace> jam1: *and* they don't like the square brackets syntax
<voidspace> jam1: so we might be ok
<jam1> voidspace: so (a) we have to be giving external addresses, because the other hosts have to be able to see this one, right?
<jam1> and then we can't use [::]:port because when it looks for self it usesf ::1:port syntax
<jam1> and string compare
<jam1> voidspace: well https://jira.mongodb.org/browse/SERVER-9612 says 'mongos' will treat everything after the *first* : as a port, but we don't directly use mongos
<voidspace> jam1: what do you mean by " so (a) we have to be giving external addresses, because the other hosts have to be able to see this one, right?"
<jam1> voidspace: "we can't use ::1" (a loopback address),
<voidspace> jam1: ah right, yeah - but that's not a problem in practise
<TheMue> voidspace: and in tests?
<jam1> (13:36:00) voidspace: &mgo.QueryError{Code:13144, Message:"exception: need most members up to reconfigure, not ok : ::1:40577", Assertion:false}
<voidspace> TheMue: failing for a different reason now that I haven't worked out yet - but it looks hopeful
<jam1> looks like we are trying to reconfigure
<jam1> but don't have quorum
<voidspace> jam1: that is when we remove a member, which is a reconfigure
<voidspace> jam1: but that same code passes when using "localhost:port", it's the ipv6 version that raises that error
<jam1> voidspace: so probably if you were getting that error, we just hadn't reached stability yet
<TheMue> voidspace: did you pushed your current code to your GH? so that I can also see it?
<voidspace> TheMue: not yet I can
<jam1> voidspace: are you sure it isn't just a timing thing?
<TheMue> voidspace: thx
<voidspace> jam1: it's just a copy paste - may well be a timing error
<voidspace> jam1: this is a new failure reason - furthest I've got!
<jam1> voidspace: "most members up" certainly looks timing related. :)
<voidspace> jam1: and it's this bug that says that mongo will always parse the address with last part as port
<voidspace> jam1: https://jira.mongodb.org/browse/SERVER-5436
<voidspace> jam1: the mongos is a red herring for us I think
<voidspace> jam1: just "yet another mongo ipv6 parsing bug"
<voidspace> cool, so it's probably not a dealbreaker which I thought it was
<jam1> voidspace: https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/hostandport.cpp looks to just be doing "string.rfind(':')"
<jam1> so yeah, as long as we always supply port (which we do) it should be ok
<voidspace> TheMue: https://github.com/voidspace/juju/tree/replicaset-ipv6
<voidspace> TheMue: voidspace/juju/replicaset-ipv6
 * voidspace *really* goes for coffee
<TheMue> voidspace: thanks, just had to finish a mail. Iâm fighting in parallel with the fussiness to get docs online. :D
<jam1> voidspace: I'm curious, what is ipv6 specific about: dialAndTestInitiateIPv6
<TheMue> jam1: not using the test root instance and passing an address
<TheMue> jam1: in the test itself a new server as root is created
<jam1> TheMue: I still don't see what is *ipv6* related about that code
<axw> wallyworld__: http://paste.ubuntu.com/7741178/   :(
<TheMue> jam1: we yesterday discussed if then later weâll parameterize this test to run once for IPv4 only and once for IPv6 addresses
<wallyworld__> looking
<TheMue> jam1: so far only building ::1:port as address
<wallyworld__> axw: is that with trunk?
<axw> wallyworld__: yep
<wallyworld__> :-(
<axw> wallyworld__: oh wait. I did make a modification... *possibly* related
<TheMue> jam1: IMHO simply to allow testing without touching the current TestAddRemoveSet
<axw> wallyworld__: I'll let you know if I repro on trunk
<axw> for now, ignore me
<wallyworld__> ok :-)
<jam1> TheMue: fwiw, I'd rather see the functions collapsed into ones that take a root (which might be self.root) rather than duplicated.
<jam1> TheMue: similarly, if the only difference for TestAddRemoveSetIPv6 is that we are using "::1" as addresses, that sounds like something that could be pulled into common code.
<TheMue> jam1: as I wrote above, thatâs the goal. this code is simply a intermediate test bed
<TheMue> jam1: it shall be combined later
<jam1> TheMue: ah, I missed that line, hard to catch everything with a couple distractions and other conversations going on :)
<TheMue> jam1: yeah, know that feeling. multiple discussion here and in parallel via mail while digging in own code or docs. sadly we havenât implemented internal goroutines
<TheMue> jam1: regarding the docs it seems to be not simple to place them on j.u.c. the web team already wanted them on help.u.c and is also planning a docs.u.c
<jam1> TheMue: we have 2 eyes, right? we should be able to follow at least 2 conversations at the same time.
<TheMue> jam1: nick is already frustrated. Iâm happy that at least GH renders markdown so that we can point interested users there
<TheMue> jam1: *lol* just imagined how the eyes look (like in comics) when trying that :D
<wallyworld__> c7z: mgz: meeting?
<davecheney> i thought there was a team meeting at 8 tongiht ?
<davecheney> that is, now
<wallyworld__> davecheney: not today
<davecheney> or is that only once every blue moon
<c7z> wallyworld__: thanks
<wallyworld__> davecheney: this week it's at 5am for us
<wallyworld__> it rotate over 3 slots
<davecheney> um, yeah, nope
<davecheney> have fun at your leadership cabal
<davecheney> voidspace: did i read that mongo can't listen on ipv6 in repl mode ?
<TheMue> davecheney: it seems more to be a problem with the address notation and also with localhost
<davecheney> hmmm
<TheMue> davecheney: voidspace is currently investigating
<TheMue> davecheney: they cannot parse [::1]:port
<TheMue> davecheney: fixed with 2.7
<jam1> davecheney: it appears to be able to listen, but it does'nt support [] syntax for disambiguating :
<jam1> TheMue: actually, not fixed yet
<jam1> but *if* fixed, not until 2.7
<TheMue> jam1: ok, thought 2.7 is available at least as developer release
<davecheney> crap
<jam1> TheMue: I just checked out the github source and it isn't fixed there
<davecheney> trusty ships with 2.4
<TheMue> jam1: *hmpf*
<davecheney> so we'll be back to shipping things via the cloud archive again
<jam1> TheMue: so the issue is that we have to use ":dead:beef:17017" and just always specify :PORT at the end
<mwhudson> 2.7 is the unstable release series
<mwhudson> (of mongo)
<TheMue> jam1: but this also works with 2.4.*
<mwhudson> so you guys won't get to use any fix until 2.8 is released
<TheMue> jam1: ?
<davecheney> jam1: that isn't a valid ipv6 address, http://play.golang.org/p/mtv1LPeghP
<mwhudson> (not that it seems this bug actually matters to you guys)
<TheMue> davecheney: not? ;)
<jam1> davecheney: no, what I typed was not valid, just psuedocode
<davecheney> i think it needs some more [ ] 's
<davecheney> http://play.golang.org/p/YRQ47sr6fB
<davecheney> from memory
<jam1> davecheney: so the issue is... we can write it correctly in our code as http://play.golang.org/
<jam1> sorry: http://play.golang.org/p/srNH2QbtR3
<jam1> davecheney: but when we configure the replicaset information
<jam1> mongo actually trnsforms [::1]:17017 into ::1:17017 internally
<jam1> and looks to see if it knows about the addresses you are passing in.
<jam1> so when we tell mongo about other mongod's, we have to give it the "invalid" form
<davecheney> that's pants
<jam1> we still dial [::1]:17017
<davecheney> yeah
<perrito666> good morning juju people
<davecheney> o/
<jam1> morning perrito666
<voidspace> perrito666: morning
<voidspace> jam1: note about your comments earlier
<voidspace> jam1: I *really* wasn't intending to leave the ipv6 tests as just copy-pasted versions of the original
<voidspace> jam1: I started with copy-pasta so I could tinker with just the ipv6 version before re-combining them
<jam1> voidspace: I understand, I was just looking at it and going... there doesn't seem to be anything ipv6 in here.
<voidspace> jam1: TheMue asked me to push what I had so far, so I did...
<voidspace> jam1: both the test and the inititiate function can be collapsed back together and parameterised
<jam1> I have to say, my proficiency reading C++ has gone down significantly in 8 years of working only in python and go :)
<voidspace> heh, not really a surprise
<jam1> all those mysterious namespaced functions
<jam1> where is this "host()" defined that you are calling :)
<voidspace> my C++ skills are as sharp as they've ever been :-)
<TheMue> voidspace: yes, your pushed branch helps me to get better into the discussion
<voidspace> TheMue: good, it's just not a finished article
<TheMue> voidspace: my C++ skills too, below 0
<voidspace> :-)
<voidspace> TheMue: I hope I've fixed it now - just waiting for test
<TheMue> voidspace: great
<voidspace> we'll see
<vladk> dimitern: does it make sense? https://github.com/juju/juju/pull/237
<jam1> vladk: dimitern: TheMue: voidspace: standup
<TheMue> jam1: oh, almost forgotten, in vladks PR
<jam1> vladk: poke ?
<vladk> jam1: just a second
<davecheney> http://juju-ci.vapour.ws:8080/job/github-merge-juju/367
<davecheney> did the jenkins machine go away ?
<c7z> davecheney: looking
<c7z> davecheney: looks fine to me, just has test build failure:
<c7z> # github.com/juju/juju/state/apiserver_test state/apiserver/server_test.go:138: cannot use stm.Tag().String() (type string) as type names.MachineTag in function argument state/apiserver/server_test.go:150: cannot use stm.Tag().String() (type string) as type names.MachineTag in function argument FAIL	github.com/juju/juju/state/apiserver [build failed]
<davecheney> ok, i'll fix that
<davecheney> i cna't reach the build machine atm
<davecheney> oh well
<davecheney> it's after stumps anyway
<c7z> davecheney: can you access it by IP? 54.86.142.177
<wwitzel3> hola
<voidspace> wwitzel3: morning
<TheMue> wwitzel3: o/
<wwitzel3> voidspace, TheMue: morning
<wwitzel3> jam1: you have a bit to chat about your review comments on #234 (removing the state dep from environs)
<wwitzel3> jam1: mainly, I believe you .. I'm just not sure how to go about doing that :)
<alexisb> jam1, ping
<jam1> alexisb: just finishing up our standup, brt
<voidspace> jam1: just got the ipv6 replicaset test passing, will refactor and submit PR
<voidspace> jam1: just FYI...
<TheMue> voidspace: \o/ also here again
<voidspace> :-)
<jam1> wwitzel3: so it is a route that we've wanted to go, and I can at least outline it for you.
<jam1> but basically, we've already done all the work to know what address the bootstrap machine has to ssh into it and set itup.
<jam1> if the last step of bootstrap was to connect to the API using the address that we already know about
<jam1> then I think we could drop all of the fallback code, and simplify a lot of stuff.
<TheMue> voidspace: iâm available for next chat in a few moments, just moving into the garden, weather is too fine
<voidspace> TheMue: sure
<TheMue> voidspace: so, sitting on the veranda
<TheMue>  voidspace ;)
<TheMue> voidspace: if Iâm right weâve got two cards left
<TheMue> voidspace: peer grouper, dummy privider, and oh, lxc templates. is it new or did I missed that one?
<wallyworld__> jam1: wanna come back to team leads hangout?
<voidspace> TheMue: we missed discussing that yesterday
<voidspace> TheMue: that sounds like a fun one to pick up
<voidspace> TheMue: I'm going to finish refactoring this test, submit a PR and then go on lunch
<voidspace> TheMue: and then sync up with you
<TheMue> voidspace: sounds like a plan o/
<voidspace> cool
<bodie_> morning all
<wwitzel3> morning bodie_
<jam1> wwitzel3: so it looks like wallyworld__ also has a stake in fixing the state.Info stuff (he wants to get rid of the bootstrap-state file because of complexities wrt in-environment storage{)
<jam1> so I just had a chat with him, and he's going to put it on the agenda for the sprint next week.
<wallyworld__> wwitzel3: we can do it together :-)
<voidspace> TheMue: https://github.com/juju/juju/pull/238
<TheMue> voidspace: *click*
<voidspace> :-)
<TheMue> voidspace: LGTM, nice idea with the address handling
<voidspace> TheMue: cool, thanks
<voidspace> TheMue: what would you call it instead of getAddr?
<TheMue> voidspace: simply address
<voidspace> TheMue: I agree in general "get" is unnecessary for getter methods - but this isn't a getter method
<voidspace> TheMue: heh, I think that's less descriptive
<TheMue> voidspace: serverAddress
<voidspace> but matter of taste I guess
<voidspace> that's not bad
<TheMue> voidspace: Iâm afk for a few moment, then we can have our chat
<voidspace> TheMue: I'm about to go on lunch - so after that I'll catch up with you
<voidspace> TheMue: dang, I get a test failure so not merging yet
<voidspace> TheMue: the *non* ipv6 variant fails
<sinzui> jam, cmars: I would like your opinion in the "Options for releasing 1.20.0 which is stalled" thread in your email.
<cmars> sinzui, looking now
<cmars> sinzui, i'm +1 for "release HA as an 'experimental tech preview'"
<sinzui> cmars, I think you mean restoration of HA state-server is experimental
<cmars> sinzui, my mistake, yes, backup/restore
<wwitzel3> wallyworld__: sounds good :)
<fwereade> wwitzel3, ping
<wwitzel3> fwereade: pong
<fwereade> wwitzel3, LoadState/SaveState -- complexity/ugliness?
<wallyworld__> fwereade: i'm off to bed, can you discuss with jam1 also
<fwereade> wallyworld__, maybe -- jam1, to what is wallyworld__ alluding? 1.20?
<wallyworld__> fwereade: he indicated that only the client needs it, and we can modify bootstrao to cahce addresss so we don't need the stte file
<fwereade> wallyworld__, ah, ok, I see
<wallyworld__> fwereade: i'm talking about the load/save state stuff
<fwereade> jam, I am kinda -1 on that: ISTM that LoadState/SaveState work perfectly, and I don't see how we're having to do any extra work to maintain the ability to look up an environment from scratch without a cached address
<fwereade> jam, cos addresses *do* change
<wwitzel3> fwereade: to answer your question .. no idea, haven't looked
<fwereade> jam, if we're really making things *that* much simpler/cleaner by dropping the feature I could maybe be swayed
<fwereade> wwitzel3, ah, there was a mail claiming you were having trouble with LoadState/SaveState in the environ/state dependency-munging
<voidspace> TheMue: I'm going to look at this after lunch, I need a break
<fwereade> wwitzel3, AFAICS we should keep those funcs, and keep on using them internally to discover state server addresses in the providers that have storage
<fwereade> wwitzel3, the really nasty stuff around those -- the flagrant layering violations by which we had jujud of all things depending on them -- is I think gone already
<wwitzel3> fwereade: well, I didn't make any effort to refactor them? Maybe that was the issue :)
<voidspace> TheMue: actually, I seem to have fixed it :-o
<fwereade> wwitzel3, so they're just a common chunk of code, useful for providers that implement storage, and unless they're actively causing trouble we should just leave them alone
<fwereade> wwitzel3, the only refactoring required AFAIK is making the state-file path *either* private *or* a param
<fwereade> wwitzel3, although I think I'd favour private
<fwereade> wwitzel3, and even that is totally orthogonal to what you're actually doing anyway
<wwitzel3> fwereade: I'm completely lost atm and feel like i've miss a piece of this converstaion somewhere.
<wwitzel3> sorry :/
<voidspace> on that note
 * voidspace really goes on lunch
<wwitzel3> does the LoadState/SaveState stuff related to the comments about StateInfo on the review?
<wallyworld__> fwereade: the issue as i understood it was it complicated removing state as a dependency of environ due to shared use of the state.Info, and if Load/SaveState were gone, that dependency would go with it
<fwereade> wwitzel3, I don;t think you need to worry, I can fight it out with jam in-thread :)
<fwereade> wallyworld__, I think Load/SaveState are irrelevant
<wwitzel3> fwereade: it probably doesn't help I haven't checked my email yet
<fwereade> wallyworld__, they're an implementation detail
<wwitzel3> I've only read the review comments.
<fwereade> wallyworld__, the StateInfo method usually uses those under the hood
<wallyworld__> wwitzel3: jam mentioned that removing load/save state would make your refactoring easier in a review comment
<wallyworld__> if i recall recorrectly
<wwitzel3> wallyworld__: ok, I was going to follow-up on that comment because I had no idea what the "fallback code" was.
<fwereade> wallyworld__, jam: is it really in any way hard/complex to have an environs.Environ be able to return the addresses of its state servers?
<wwitzel3> wallyworld__: so if the fallback code is Load/Save State, and that is related to the Info struct, then I'm mostly caught up I think.
<fwereade> wallyworld__, jam: we tell the environ when it's starting a state server
<TheMue> voidspace: great that itâs fixed and enjoy your lunch
<wallyworld__> wwitzel3: as i understand it yes
<wwitzel3> wallyworld__: thanks, sometimes I just need my hand held
<fwereade> wallyworld__, jam: is it so much to ask that it record which ones are state servers, for the convenience of the bootstrap users?
<wallyworld__> wwitzel3: me too, it make me feel safe :-)
<wwitzel3> :)
<fwereade> wallyworld__, jam: to be fair, we would occasionally want to update it in an ideal world, when a state server gets demoted
<wallyworld__> fwereade: i think the issue is not that we ask the environ to do it, but that it not use cloud storage for it
<wallyworld__> if we can break that link, things become simpler
<fwereade> wallyworld__, jam: we have provider storage already implemented in all these cases, though
<fwereade> wallyworld__, jam: I don't think so
<fwereade> wallyworld__, jam: asking the Environ for the storage inside the state server becomes incoherent, it's true
<fwereade> wallyworld__, jam: but that's independenyt
<wallyworld__> fwereade: it's implemented now, but new providers without storage are difficult
<wallyworld__> and the use case is - clients need to connect, the last api address they had doesn't work, where do they get another from to try
<fwereade> wallyworld__, jam: the environ's responsible for knowing what its state servers are -- I don't really believe we actually have any providers that don't allow *some* way of tagging the state servers
<wallyworld__> if we properly cached the addresses in jenv, then we don't need to query state file
<wallyworld__> we save the last connected one, but not the others
<wallyworld__> it's about the client connecting, not the environ knowing
<wallyworld__> ideally there would be no provider code in the client
<fwereade> wallyworld__, how do you propose one bootstraps a new state server? I really don't think we want a separate tool for that...
<fwereade> wallyworld__, I agree we want better caching
<wallyworld__> yeah bootstrap needs provider code
<wallyworld__> but would be nice to minimise it
<fwereade> wallyworld__, but I don't yet see a good reason to drop the fallback code -- we would hopefully hardly ever need it, it's true
<wallyworld__> if we drop it, it makes it easier to divorce state from environ, and remove need for provider storage
<fwereade> wallyworld__, completely disagree
<wallyworld__> we can use env blob storage instead
<wallyworld__> see wwitzel3's branch and jam's comment
<fwereade> wallyworld__, we can and will always use env blob storage for everything -- but if you internally implement the environ Storage interface, you can use it with L/SState and the fallback stuff continues to Just Work
<fwereade> wallyworld__, that particular file happens to be in "env" storage, but it's not really for the env's use at all, it's for the client's -- and I don't see how the env storage change needs to actually impact it
<wallyworld__> that was my original thought but jam was quite certain we should or could drop it
<wallyworld__> fwereade: ah because
<wallyworld__> the client needs to access the api to get the blob storage
<wallyworld__> but it uses the state file to get the api to connect to
<wallyworld__> s/api/address
<wallyworld__> catch 22
<fwereade> wallyworld__, the client shouldn't need to use the blob storage directly, should it?
<wallyworld__> no, that's the point
<wallyworld__> the client needs state file if address it has doesn't work
<wallyworld__> it currently talks to cloud storage directly to get it
<fwereade> wallyworld__, and the *client* will not need any direct knowledge of the state file either -- because an environ doesn't *have* to use that mechanism in the first place
<wallyworld__> if we move state file to blob storage, client can't get to it
<wallyworld__> when it needs to
<fwereade> wallyworld__, we certainly shouldn't do that
<fwereade> wallyworld__, the state file is an *detail* of certain provider *implementations*
<wallyworld__> which the client uses directly when needed because the whol epoint it that there's no api to connect to
<wallyworld__> because the address the client has is not working
<fwereade> wallyworld__, sorry, I'm keeping you up, but I am happy to continue arguing this out if you're really of a mind to...
<fwereade> wallyworld__, I feel like we're talking past each other though
<wallyworld__> fwereade: should we take this toa hangout?
<fwereade> wallyworld__, if you're free, let's
<fwereade> wallyworld__, tanzanite?
<wallyworld__> https://plus.google.com/hangouts/_/canonical.com/tanzanite-daily
<perrito666> niemeyer: hey, are you around?
<niemeyer> perrito666: I am
<niemeyer> perrito666: In a call, though
<jamespage__> dimitern, fwereade?
<wwitzel3> perrito666, ericsnow: I'm running a bit behind on standup, be there shortly (in another call)
<jamespage__> coming :-) ?
<niemeyer> perrito666: What's up? Will be with you soon
<dimitern> jamespage__, sorry, brt
<fwereade> jamespage__, hell, other meeting running over
<ericsnow> wwitzel3: np
<perrito666> niemeyer: ouch, I was tying to lure you into another call for a moment :p
<TheMue> voidspace: sh.., TestAddRemoveSetIPv6 is failing /o\
<TheMue> voidspace: âcouldn't initiate : can't find self in the replset config my port: 35060â
<c7z> rick_h__: (or a delegee) I've got a a bunch of jenkins-github-lander changes to land, first one up here: <https://github.com/juju/jenkins-github-lander/pull/13/files>
<voidspace> TheMue: how annoying
<voidspace> TheMue: passes for me :-/
<voidspace> TheMue: it may be a problem running on a slower machine perhaps
<rogpeppe> fwereade: is it possible to have a charm resource that's not associated with a particular series?
<voidspace> TheMue: it takes two minutes to run, but it passes consistently for me
<TheMue> voidspace: strange
<TheMue> voidspace: I hate timing problems
<TheMue> voidspace: is there a way to define a different retry behavior?
<voidspace> TheMue: trying again in case it's spurious
<voidspace> TheMue: the other possibility is that this is precise. *Or* it's a machine without an ipv6 stack.
<voidspace> TheMue: this is the first ipv6 dependent test in juju-core, right?
<TheMue> voidspace: thatâs what I thought first too, the missing IPv6
<voidspace> TheMue: ah
<TheMue> voidspace: yep
<voidspace> TheMue: I didn't bump the gittesting revision number in dependencies.tsv
<voidspace> that will be the problem
<voidspace> grabbing coffee then fixing
<TheMue> voidspace: hehe, when itâs that simple than itâs fine
<fwereade> rogpeppe, I think a resource is always acssociated with a specific charm, and last I heard we were pretty solidly committed to having a single charm be a single series
<fwereade> rogpeppe, so yes, but it's implicit rather than explicit
<fwereade> rogpeppe, er, so, the answer to your posed question is actually *no*
<fwereade> rogpeppe, but there's no explicit association between a resource and a series, it's implicit in the association between a resource and a charm
<rogpeppe> fwereade: so there's an association with a resource and a series because you can't specify a resource without specifying a fully qualified charm name including the series, right?
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: specifically, it would be nice to know if this looks sane: https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc/edit  (search for "resources")
<perrito666> niemeyer: what I needed is for you to talk a moment with gsamfira about adding a few things to gocheck to make it more windows friendly, so let us know if you have a moment so we can talk about the patch he proposes
<jcw4> hi fwereade; jam1 had a great comment on https://github.com/juju/juju/pull/216 and I'd like to get your thoughts... you'd need to look at the diff though since I changed it in response to your review yesterday.
<fwereade> rogpeppe, jcw4, I'm queuing tabs for you both, hope I will pop enough from my stack to get to them soon
<rogpeppe> fwereade: ta!
<jcw4> fwereade: lol, thanks :)
<mfoord> TheMue: ok, updated dependency and resolved resulting conflict (!?!)
<mfoord> TheMue: waiting on the bot - I think it's probably running the old revision again unfortunately
<TheMue> mfoord: doesnât it always starts from zero, so retrieving all dependencies based on the dependencies file?
<mfoord> TheMue: I mean that I initially thought the problem was a spurious timing related one
<mfoord> TheMue: so I added another $$merge$$ comment which the bot picked up
<mfoord> TheMue: so I think it's running tests from before I updated the dependencies
<TheMue> mfoord: ah, ok
<mfoord> TheMue: so I need to wait for that to fail so I can retry the merge a third (and hopefully final) time
<mfoord> TheMue: did you start looking at lxc templates?
<TheMue> mfoord: the latest one had a panic during build?
<TheMue> mfoord: only a short look, mostly Iâm writing on the API spec
<mfoord> ah, ok
<TheMue> mfoord: but we can talk about, my brain needs a little distraction from the API stuff
<mfoord> TheMue: I don't know what the panic is about, but the previous test failed again for the same reason
<mfoord> and that at least is fixed now
<mfoord> TheMue: ok, let's talk in two minutes
<fwereade> rogpeppe, the api proposal is slightly difficult for me to map onto the action of juju publish -- is there another doc that covers that? if not, I think that needs to be defined before we can reasonably judge an api proposal
<mfoord> TheMue: ok, I'm ready - hangout?
<rogpeppe> fwereade: juju publish is, I believe, just the action of POSTing a new charm to the store, right?
<fwereade> rogpeppe, I think it also needs to do resources
<fwereade> rogpeppe, either charm+resources, or charm alone, or resources alone
<rogpeppe> fwereade: they're independent things then?
<katco> is there a reason that there's one function in this file all by its lonesome? github.com/juju/juju/upstart/service.go. can i roll this into upstart.go?
<fwereade> rogpeppe, and we need to figure out how we update the (charm-rev, resources-rev) pairs that define the "current" version of a charm(+resources)
<rogpeppe> fwereade: so they have two independent endpoints (/archive and /resources)
<rogpeppe> fwereade: the version is updated automatically and returned in the post response
<rogpeppe> fwereade: at least, that's the current plan - perhaps there's a reason that's not good?
<fwereade> rogpeppe, doesn't a resources revision refer to a list of N files?
<sinzui> katco, what TZ are you in. I saw you at my midnight last night, and now I see you at my Noon
<katco> sinzui: GMT -6. little known fact, i am actually a robot.
<rogpeppe> fwereade: yes, but the revision is incremented any time one of those files is uploaded
<rogpeppe> fwereade: so the result is the same, i *think*
<fwereade> rogpeppe, I don't think that makes sense
<rogpeppe> katco: aren't we all
<katco> :p
<katco> beep boop
<fwereade> rogpeppe, if two files need to match, and we inc rev every time one is uploaded, we end up with a whole bunch of broken resource-stream revisions
<rogpeppe> fwereade: i'm not sure what you mean by "two files need to match"
<fwereade> rogpeppe, ok, even simpler
<sinzui> katco, wgrant was suspected of being a robot until we discovered we couldn't put him into an N-1 configuration
<fwereade> rogpeppe, one version of a charm defines resources a, b, c; another defines d, e
<sinzui> Sleep gives you cancer anyway.
<katco> sinzui: lol
<fwereade> rogpeppe, how does the POST approach work?
<rogpeppe> fwereade: resources? streams? filenames?
<rogpeppe> fwereade: i thought resources weren't associated with a specific version of a charm?
<fwereade> rogpeppe, sorry, just a mo
<katco> process question: if i merged a partial-fix in under a branch, should i do the rest of the work in a different branch, or in the same branch w/ a new PR?
<c7z> katco: new branch
<c7z> well, depends exactly what you mean by partial
<c7z> but if it's landed, you should just take a new checkout of trunk (including that change) for your followup
<katco> c7z: specifics: log perms are wrong. i fixed 1 class of log, working on remaining class.
<katco> c7z: but the bug is for all log perms
<mfoord> TheMue: http://containerops.org/2013/11/19/lxc-networking/
<katco> c7z: it has landed, but i can just rebase the branch from trunk. the naming nomenclature i'm using lends itself to doing the remaining work in this same branch, but i wasn't sure if there were downsidexz
<katco> *downsides
<c7z> you want a new pr, so it's easiest with a fresh branch
<katco> c7z: ok, ty!
<sinzui> wwitzel3, perrito666 : Do either of you have a moment to review https://github.com/juju/juju/pull/240
<c7z> state/api/client.go:// TODO(axw) 2014-04-11 #XXX
<c7z> ace :)
<niemeyer> perrito666: Hi
<niemeyer> perrito666: Sure
<niemeyer> perrito666: Any time
<jrwren> juju local mongodb grows to 6.5GB rather fast, how much does a tiny juju local need?
<niemeyer> jrwren: I suppose the usual flags for reducing pre-allocatoin are not being used?
<niemeyer> jrwren: --smallfiles --noprealloc etc
<jrwren> those are used.
<niemeyer> jrwren: How come it grows to 6.5G then?
<jrwren> that is what I'm asking :)
<niemeyer> jrwren: Should be easy to see what's inside the database
<fwereade> rogpeppe, sorry, meeting is taking a while :/
<rogpeppe> fwereade: np
<rogpeppe> fwereade: although i will be stopping soon
<wwitzel3> sinzui: LGTM
<perrito666> niemeyer: do you have a moment now to jump into a hangout?
<niemeyer> perrito666: Yep
<perrito666> niemeyer: https://plus.google.com/hangouts/_/canonical.com/cloudbase?authuser=3
<perrito666> lemme know if it does not work I will issue an invite
<sinzui> thank you wwitzel3
<niemeyer> perrito666:
<niemeyer> "This party is over..."
<perrito666> mm hangout lies a lot like that
<niemeyer> Have never seen that one..
<perrito666> do I invite you to your canonical email?
<niemeyer> perrito666: Ahh, it's the authuser part
<niemeyer> perrito666: That's your user.. the link isn't valid for me.. fixed it by hand
<fwereade> rogpeppe, hmm, on rereading that mail it's about *next* week, so we're not meeting about resources this evening as I was expecting
<fwereade> rogpeppe, I'm going to have to drop off very shortly myself
<rogpeppe> fwereade: ha
<rogpeppe> fwereade: we're chatting in a hangout if you wanted a quick chat
<fwereade> rogpeppe, but mainly I am still not understanding how we can do the resource POSTing
<rogpeppe> fwereade: but i imagine you're pooped :-)
<rogpeppe> fwereade: yeah, i'm pretty fuzzy over the whole thing now myself
<fwereade> rogpeppe, I'm fine but I will not be popular if I'm online for more than 10 mins
<rogpeppe> :-)
<fwereade> rogpeppe, what hangout?
<rogpeppe> fwereade: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<jcw4> c7z, mgz http://juju-ci.vapour.ws:8080/job/github-merge-juju/373/console ? InvalidInstanceID?
<c7z> looking
<c7z> seems like ec2 flakiness
<perrito666> :q
<jcw4> just $$merge$$ again?
<perrito666> sorry, wrong window
<jcw4> :)
<c7z> I've hit rebuild there
<jcw4> c7z: ta
<jcw4> mgz: that worked, thanks!
<menn0> anyone joining the core team meeting?
 * perrito666 has been connected to some form of hangout the whole day
<fwereade> wwitzel3, katco: https://plus.google.com/hangouts/_/canonical.com/juju-core-team?authuser=1
<alexisb> wwitzel3, katco ^^^
<fwereade> mgz, it's probably late for you?
<katco> alexisb: sorry, i'm in! is there an invite or something i need to be added to?
<alexisb> katco, yes, let me get you added
<katco> alexisb: ty :)
<alexisb> cmars, just fyi, we are having a team call if you are available
<alexisb> I assume your team is done for the day
<perrito666> fwereade: you seem to have frozen
<fwereade> cmars, ping
<alexisb> anyone know if thumper is going to be online today?
<alexisb> menn0, waigani ^^
<waigani> alexisb: morning :)
<menn0> alexisb: he was sick yesterday so not sure
<mfoord> g'night all
<alexisb> morning waigani
<alexisb> btw, did you see the video link I posted the other day?
<alexisb> the one that reminded me of you
<perrito666> could someone PTAL https://github.com/juju/testing/pull/18 ?
<bac> sinzui: your release notes for 1.20 are amazingly thorough and informative.  thanks!
<sinzui> bac: thank you
<perrito666> sinzui: you do know that we eventually will build you a monument and worship it before each release for our tests to pass, right?
<sinzui> perrito666, Ice cream will be fine
<perrito666> sinzui: given that I am about 15kkm from you I think a monument is much easier than sending you ice cream
<sinzui> perrito666, :)
<sinzui> I have a similar problem getting Aussie pies delivered to my house in the US
<alexisb> alrighty all, I am off for a long weekend
<jcw4> have fun alexisb
<alexisb> see everyone on monday!
<wwitzel3> have a good one alexisb
<alexisb> those in the US enjoy your 4th!
<wwitzel3> alexisb_vac: thanks you too
<katco> alexisb_vac: ditto :)
<jrwren> to where does a charm install? I want to make sure my hook changes were deployed correctly
<katco> can anyone help me understand what this means? "godeps: "/home/kate/workspace/go/src/github.com/juju/cmd" is not clean; will not update"
<katco> when running godeps -u dependencies.tsv
<katco> i did a go clean, didn't seem to help
<jcw4> katco: do you have changes in the juju/cmd repository?
<katco>  jcw4: i do not
<jcw4> hmm; if you go to /home/kate/workspace/go/src/github.com/juju/cmd and do a straight git pull -u ?
<katco> oh jees... i see my error.
<katco> i was looking at juju/juju/cmd, not juju/cmd
<katco> that gets just a bit confusing at times :p
<jcw4> katco: ah... that's easy to do
<katco> ty for your help jcw4 :)
<jcw4> katco: yw :)
<stokachu> in the api, what are the watchers used for? just a general overview
<jcw4> stokachu: in general watchers watch for changes to collections in the stateserver
<jcw4> stokachu: and send events to the consumers of the watchers
<stokachu> jcw4, ah ok
<stokachu> ive got another question about the ServiceDeploy api, there is a ServiceName and CharmUrl. is CharmUrl a requirement?
<jcw4> stokachu: I don't know much about that
<stokachu> ok
<jcw4> thumper: o/
<thumper> morning jcw4
<stokachu> it looks like i can't just call ServiceDeploy(ServiceName='wordpress')
<stokachu> i have to give it a charmurl
<jcw4> stokachu: yeah, looking at the code it seems like any kind of deployment does need the CharmUrl
<stokachu> im guessing just doing 'juju deploy wordpress' has some checking for setting that if isn't provided
<stokachu> haven't checked
<jcw4> stokachu: hmm; the name CharmUrl only appears in 3 non-test files, and they all seem to just assume it's set
<stokachu> interesting
<stokachu> the only complication i see with having to set the url everytime is that you're forced to pick either trusty or precise. some cases i just want it to deploy the latest charm
<stokachu> which is the behavior of 'juju deploy X'
<stokachu> im also not sure what the point of ServiceName is wrt ServiceDeploy if we require a charmurl
<stokachu> {"RequestId":4,"Error":"charm url must include revision","Response":{}}
<stokachu> if i pass 'cs:trusty/juju-gui' as the CharmUrl thats the response i get back
<jcw4> stokachu: I'm afraid most of my experience with juju is in the state back-end, not at all with charms :-/
<stokachu> thats cool
<jcw4> stokachu: github.com/juju/charm/url.go around line 102 shows the url parsing
<jcw4> stokachu: looks like you can use local: instead of cs: for the schema possibly
<stokachu> yea thats for deploy from a local repo
<jcw4> stokachu: fwiw the revision seems to be set in the url by appending -<revision number> to the name
<stokachu> yea that works but how do i find the revision via the api?
<stokachu> or do i have to search the charmstore?
<jcw4> stokachu: oh, I see; I thought you were authoring a charm
<stokachu> im querying the juju api to try and deploy one currently
<jcw4> stokachu: right you did say something to that effect earlier on
<jcw4> stokachu: are you trying to deploy it programatically or using `juju deploy`
<stokachu> programatically
<jcw4> stokachu: and you're wanting to find the right charm url in your code rather than having it supplied by a user?
<stokachu> yea
<stokachu> so my routine basically is deploy(charm, dictionary_of_settings)
<stokachu> containg ToMachineSpec etc
<jcw4> and 'charm' is a user friendly name, supplied by a user somehow, but not including the charm url
<stokachu> yea so like deploy('mysql')
<stokachu> would in turn call ServiceDeploy
<jcw4> stokachu: okay; so looking at the tests for ServiceDeploy it's clear the charm url is required and must be fully specified including revision.
<jcw4> stokachu: so you'd need to find how to query the charm store, given a friendly name and get back a charm url
<jcw4> stokachu: resolving possibly many results
<stokachu> ok that works
<stokachu> jcw4, im curious how just calling juju deploy mysql works then
<stokachu> i thought it used the same api
<jcw4> stokachu: it does... juju/cmd/juju/common.go around line 58 is where it starts resolving the common name to a charm url
<stokachu> ok reading that now
<jcw4> stokachu: it populates things like series from the environment
<stokachu> i see the resolveCharmUrl but i dont see how it resolves the revision
<jcw4> stokachu: ah, there is a ResolveCharms method on the apiserver Client too
<jcw4> resolveCharmUrl uses that
<jcw4> and the apiserver/client defers that resolving to an implementor of the Repository interface
<jcw4> which I can't find an implementor in the juju repo
<jcw4> stokachu: but conceptually it seems to figure out an apropriate repostitory to query and then that repository returns a URL
<stokachu> ok i think i understand the workflow now
<stokachu> jcw4, thanks :)
<jcw4> stokachu: yw... one last comment; this seems helpful: http://juju-docs.readthedocs.org/en/latest/internals/charm-store.html#charm-revisions
<stokachu> ah looks like there is some sort of REST within the charmstore i could utilize
<davecheney> it's 8:30, about 10c in my house and i'm weargin hobo gloves -- #beautiful sydney
<thumper> davecheney, waigani, menn0: it is the last day of the school term and my daughter has a guitar solo in assembly (starts in about 7 minutes)
<thumper> I may be late for the standup
<menn0> thumper: no probs. That doesn't sound like something you should miss.
<waigani> thumper: nice. My girl has a dance performance this afternoon!
<davecheney> thumper: lets skip standup today then
<davecheney> i'm fixing bugs
<thumper> ok, I'm fine with that
<davecheney> thumper: is writing documents and hating himself
 * thumper is looking at docs and trying to stay sane
<thumper> heh
<davecheney> menn0: is blocked on schema upgrades
<davecheney> and waigani is doing reviews
<davecheney> ta-da: 15 second standup (tm)
<waigani> ha
<menn0> :)
<menn0> davecheney: I'm not actually blocked so much now but yes, am definitely working on schema upgrade related stuff.
<menn0> davecheney: what are you doing?
<menn0> davecheney: never mind. I just saw.
 * menn0 needs more coffee
<menn0> or less blood in my coffeestream ...
<menn0> davecheney, thumper: I went to this morning's core team meeting. It was good but I can't think of anything that came up that's particularly relevant or that you don't already know.
<menn0> davecheney, thumper, waigani: one other thing ... I'll be in Brisbane next week and will be working from there on Tues, Wednesday and Friday.
<waigani> menn0: nice!
<waigani> menn0: you could work at wallyworld's ;)
<menn0> that was the plan originally and I had that lined up but then he ended up having to go to the sprint in Boston
<menn0> I may be catching up with him the following Monday (leaving Brisneyland on the 15th). he gets back that day. I'm going to meet bigjools at any rate.
<davecheney> menn0: oh, you'll enjoy that
<davecheney> thumper: menn0 waigani alos, but set of ppc64 bugs is growin
<davecheney> i have 3 atm
<davecheney> 1 waiting on the upstream
<davecheney> 1 waiting on the reporter for more informatoin
<davecheney> i can't remember the status of the third
<davecheney> i guess axw and wallyworld are on a plane now ?
<thumper> well that went on longer than expected
<davecheney> thumper: wanna stand up
<davecheney> seeing as you're still standing
<thumper>  davecheney: probably not until saturday
<thumper> davecheney: standup hangout
<davecheney> mkay
#juju-dev 2014-07-04
<davecheney> thumper: http://stackoverflow.com/questions/7222062/mongodb-composite-key
<jcw4> davecheney, thumper wow... that looks very intriguing
<thumper> jcw4: yeah, I'm going to write an email to juju-dev about keys in multi-environment servers
<thumper> I'd like agreement and consistency before we dive head-first into schema changes
<jcw4> +1
<davecheney> thumper: oh, I thought we were all going to propose out champion
<davecheney> then fight it out, thunderdome style
<davecheney> oh wait
<davecheney> that would be a bad idea
<jcw4> mad max did come from down under didn't he?
<davecheney> http://upload.wikimedia.org/wikipedia/commons/9/9d/07._Mad_Max_Car_at_Silverton_Hotel,_Silverton,_NSW,_07.07.2007.jpg
<davecheney> last of the V8 interceptors
<jcw4> sweet... I've been through that town dozens of times and never saw that
<jcw4> not
<thumper> davecheney: I love that car
<katco> hmm... why am i staring down a variable named x if i'm not dealing with a coordinate system...
<thumper> looks awesome
<thumper> katco: haha, +1 on making it mean something
<katco> it is now named fishAndChips
<katco> (or configKeyValues... one or the other)
<jcw4> katco: like schrodingers cat?
<katco> well, it's definitely one or the other :)
<jcw4> hehe
<stokachu> does the Machiner api expose http://godoc.org/github.com/juju/juju/state#Machine?
<stokachu> btw, im working on a python3 api client for juju https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py
<stokachu> now trying to figure out the api requests for accessing the Machine data
<stokachu> or maybe api call to pull http://godoc.org/github.com/juju/juju/state/api#MachineStatus
<thumper> stokachu: only the client api end points are callable by non-agents
<thumper> stokachu: what is it you are really trying to do?
<davecheney> 17 minutew to land a change
<davecheney> NOICE
<thumper> davecheney: \o/
<davecheney> a grand improvement from this time last week
<stokachu> thumper, want to access the machine data without having to call juju status
<davecheney> o/ axw and wallyworld
<thumper> stokachu: I don't think we allow that
<axw> davecheney: howdy
<stokachu> thumper, b/c no code exists or some other reason?
<axw> davecheney: yeah, I wish I made that change ages ago :/
<axw> I think the fastest I've seen so far is 16m. It should be considerably faster again when we have a dedicated instance for the lander
<stokachu> our cloud-installer relies on calling out to juju <cmd> and i want to remove all that in favor of the api
<stokachu> like i do with maas
<thumper> stokachu: it think it was more to do with security
<thumper> stokachu: so we didn't expose things to people who don't need them
<stokachu> so if i file a bug will it get closed wontfix?
<thumper> not if there is a clear and useful need for it
<thumper> and it doesn't expose places where we can get screwed up
<stokachu> if you're just exposing mostly read only it should be ok right?
<stokachu> and its already exposed in juju status so we could just mimic that
<stokachu> besides there is an api call to forcedestroy machines so i think you couldnt do worse than that :)
<thumper> stokachu: could you not just use the status API?
<thumper> why do you need another one?
<stokachu> thumper, the status api only returns machine_id: {InstanceId}
<stokachu> our cloud-installer requires information that isn't exposed by the api
<axw> stokachu: you want to get machine status? http://godoc.org/github.com/juju/juju/state/api#Client.Status ?
<stokachu> {"RequestId":2,"Response":{"Machines":{"0":{"InstanceId":"localhost"},"1":{"InstanceId":"adam-local-machine-1"},"2":{"InstanceId":"adam-local-machine-2"},"3":{"InstanceId":"adam-local-machine-3"}}}}
<stokachu> thats all thats returned from the Status api call
<axw> huh
<axw> stokachu: what version of juju?
<stokachu> 1.18.4
<axw> menn0: ^^ does this have anything to do with the FullStatus changes?
<axw> I think there may be some fallback code for 1.18
<thumper> stokachu: that just seems wrong
<stokachu> theres a LegacyStatus call
<thumper> status definitely returns more than that
<thumper> godoc.org/github.com/juju/juju/state/api#MachineStatus
<stokachu> https://github.com/battlemidget/cloud-installer/blob/patch-split-core-logic/cloudinstall/juju/client.py#L80-L83
<stokachu> thats the request parameters i use
<axw> stokachu: I think you actually want to call "FullStatus" from 1.18+
<stokachu> lemme try that
<axw> it's hidden by the API
<thumper> https://github.com/juju/juju/blob/master/state/api/client.go#L145
<thumper> line 157 shows "FullStatus" being called
<stokachu> axw, calling FullStatus works
<thumper> \o/
<stokachu> should Status call that in later versions I guess?
<axw> cool
<stokachu> or is FullStatus in process of being documented
<axw> stokachu: in the Go code it does: the client method is called Status, but it calls FullStatus under the hood
<stokachu> was that introduced after 1.18.x?
<stokachu> just trying to understand why calling Status failed
<stokachu> well failed to pull FullStatus
<stokachu> i see where its called in the latest api code
<axw> we don't have versioning (yet) on APIs, so if the structure of the parameters becomes incompatible we have to change the API name
<stokachu> ah ok
<stokachu> thumper, yea this was what i was looking for
<axw> stokachu: so it was actually introduced as a stub in 1.16, but I think full functionality didn't arrive till 1.18
<stokachu> gotcha
<stokachu> func (c *Client) Status() (api.LegacyStatus, error) { < - this api.LegacyStatus why it doesn't show the FullStatus properly?
<axw> stokachu: I don't really recall whether that was all it ever had, or if it was purposefully hobbled. We used to go directly to mongo to get the status of entities, but I can't remember what part the API had
<stokachu> ok cool
<waigani> you don't need to explicitly call setupsuite on an embedded suite if you only have one right?
<thumper> waigani: correct
<waigani> thumper: thanks
<waigani> what are some examples of jujuconnsuite being overused/wrongly used?
<waigani> menn0: ^?
<menn0> waigani: I believe there's some suites that don't actually use an API connection but still embed JujuConnSuite (probably due to copy and paste)
<menn0> waigani: there's also a bunch of suites that should be mocking the API instead of using a real API connection
<waigani> menn0: ah right, thanks
<waigani> when testing ops on docs, should that be mocked or not (that sounds like a bad Dr Seuss rhyme)?
<bigjools> a bunch of NUCs with SSDs actually makes deployment with juju and maas quite painless
<davecheney> waigani: wallyworld axw thumper https://github.com/juju/testing/pull/19
<davecheney> small cleanups for the testing package
<thumper> davecheney: given that you are always telling us not to throw away the err...
<thumper> why are you?
<davecheney> i can't be bothered extending that massive if condition
<davecheney> someone else can later if they want
<thumper> axw: is the environment name for machine placement actually every checked?
<axw> thumper: I forget. it's mainly there for future usage
<axw> I'll check
<thumper> hmm...
<thumper> I'm trying to hide the EnvName from the environment command
<thumper> so I can allow passing of everything through command line or environment
<thumper> so may not have a name referring to something on disk
<axw> thumper: it is checked in apiserver/client.Client.addOneMachine
<axw> thumper: why do you want to hide EnvName?
<axw> I don't quite understand
<thumper> because env name is getting confused
<thumper> it isn't really the env name at all
<thumper> but a local alias to an environment uuid/username pair
<thumper> in order to support better scripting
<axw> right
<thumper> we want to be able to have a script define an environment
<thumper> a set of env vars
<thumper> that the juju commands can just use
<thumper> so the machine that the script is run on
 * axw nods
<thumper> doesn't need the cached environment connection files
<thumper> so...
<thumper> EnvName may well be blank
<thumper> so in a prep branch
<thumper> I'm trying to hide it
<axw> ok
<thumper> and provide functions to get a client api
<thumper> and other bits where it is used
<thumper> it is surprising how much data creep there is
<axw> thumper: I *guess* the placement scope should be translated from environment name (alias) to uuid+username then
<thumper> if you have something public, people will use it
<axw> heh :)
<axw> and use it in unexpected ways
<thumper> right
<thumper> axw: uuid would probably be sufficient
<axw> yeah I guess, user is implied
 * thumper nods
<thumper> axw: actually, there is a problem with this code...
<thumper> axw: if I rename my connection file
<thumper> axw: this won't work
<thumper> axw: because it will say "invalid environment name"
<axw> yeah... that will need to change if we're not requiring the .jenv to be there
<thumper> axw: also if I just rename my jenv file
<thumper> my local aliase won't match the environment name
<thumper> oh man
<thumper> so much for being a quick and easy branch
<thumper> fucking tenticles everywhere
<axw> thumper: I thought we were going to have a command to create a .jenv file from connection settings?
<thumper> we probably are
<thumper> but if I specify everything on the environment
<thumper> I don't want it touching the file system
<axw> fair enough
<thumper> coffee time
<TheMue> morning
<voidspace> morning
<TheMue> voidspace: morning
<dimitern> TheMue, voidspace, hey
<dimitern> I'd love a review on this https://github.com/juju/juju/pull/243/
<urulama> the parsing of environment.yaml fails if there is a line with a tab ('\t') but without entry of attributes. looked at LP for such bug and couldn't find one. using juju 1.19.4
<urulama> let me know if this is not reported yet
<TheMue> dimitern: *click*
<dimitern> urulama, so is it valid yaml?
<dimitern> TheMue, ta
<urulama> dimitern: yes, replacing tabs with spaces worked
<urulama> dimitern: the parsing only fails if there are tabs as prefixes to attributes
<dimitern> urulama, using tabs in a yaml file is forbidden
<dimitern> urulama, http://www.yaml.org/faq.html
<urulama> dimitern: yes, however, imagine user with an editor that automatically ads tabs ...
<dimitern> urulama, I'm not saying it can't happen, but this is like saying "invalid html should still show up correctly" :)
<dimitern> urulama, what's the error you're getting?
<urulama> dimitern: not saying it's a bug, maybe a "usability error" ... maybe adding "don't use tabs" in description could help a bit
<urulama> dimitern: it's simply "ERROR: couldn't read the environment"
<dimitern> urulama, right, I agree it's a usability issue and please, file a bug for it, so we can keep it in mind
<urulama> dimitern: ok
<rogpeppe> urulama: yaml is a ridiculous format :-)
<dimitern> mgz, hey
<dimitern> mgz, is goose still on launchpad ?
<TheMue> dimitern: youâve got a review
<TheMue> voidspace: still troubles merging the replica set test?
<dimitern> TheMue, thanks
<TheMue> dimitern: itâs nice to see how IPv6 soaks into the code (hope I took the correct verb)
<dimitern> TheMue, yeah :)
<voidspace> TheMue: yep
<voidspace> mgz: ping
<perrito666> morning
<voidspace> perrito666: morning
<voidspace> mgz: https://github.com/juju/juju/pull/238
<voidspace> mgz: this got a "merge request accepted" 18 hours ago but hasn't been run
<voidspace> mgz: meanwhile other ones have
<mgz> voidspace: looking
<mgz> voidspace: see job 371
<mgz> ec2 fell over, I'll requeue on the bot
<voidspace> ah, I did have a look to see if it ran
<voidspace> I must have missed that
<voidspace> mgz: ah, but it was marked as failure - the bot didn't see it though?
<voidspace> "
<voidspace> InvalidInstanceID.NotFound: The instance ID 'i-7444355f' does not exist"
<mgz> yeah, made teh job fall over in such a waay as it didn't get to the reporting back step
<voidspace> wwitzel3: ping for when you're around
<voidspace> wwitzel3: and fully caffinated
<voidspace> dimitern: TheMue: I'll be five minutes late to stdup - sorry
<dimitern> voidspace, no worries
<dimitern> vladk, standup?
<ChrisW> how do standups work when everyone's remote?
<perrito666> I would greatly appreciate a second look at https://github.com/juju/testing/pull/18
<perrito666> ChrisW: hangout
<TheMue> voidspace: it failed again, really strange
<TheMue> perrito666: will take a look in a few moments, just have to change place (too warm on the verranda)
<perrito666> TheMue: 1st world problems :p
<TheMue> hehe, indeed
<voidspace> TheMue: yep, they look completely unrelated though
<voidspace> TheMue: I tried again locally and everything passes
<TheMue> voidspace: so there seems to be something different on the ec2 hosts
<mgz> voidspace: looks like the run's tests failed, but the pr should be back in a sane state now
<voidspace> TheMue: mgz: yeah, I've tried again in the hope that it's spurious
<mgz> that one of the failures is in a new test (..BothIPv4AndIPv6) isn't encouraging
<ChrisW> juju-gui totally written in JS?
<mgz> looks like new flakiness
<frankban> ChrisW: yes, it uses a Python server when deployed using the Juju GUI charm, which enables some additional features (like bundle deployments) but the core application is client-side JS
<ChrisW> fascinating :-) Interesting to see that most of the juju-gui team appear to be ex plone/zope people :-)
<frankban> ChrisW: :-) it used to be like that, but now we have some great JS guys in the team
<TheMue> perrito666: review done, with a minor comment.
<perrito666> TheMue: thank you very much
<TheMue> perrito666: yw
<ChrisW> heh, you saying plone/zope guys aren't great with JS? ;-)
<TheMue> voidspace: yay, it merged
<voidspace> awsome
<voidspace> TheMue: at last :-)
<TheMue> voidspace: somehow strange that it had so much troubles. if it would be a failing test, and always the same, then the problem can easily be located
<TheMue> voidspace: but it looks absolutely strange here, once even a panic during build
<frankban> hi all, it seems 1.20 inadvertently changed the structure returned by the mega-watcher for machines. please see bug 1337831. Even if the quickstart fix should be easy enough, it's worth noting this seems to be an accidental change to the public API
<_mup_> Bug #1337831: Quickstart crashes when used with juju 1.20 <juju-quickstart:In Progress by frankban> <https://launchpad.net/bugs/1337831>
<frankban> fwereade: ^^^
<rogpeppe> fwereade: shall we have that chat some time?
<perrito666> people anyone would like to take a second look to https://github.com/juju/utils/pull/4 before I merge it? It has only been reviewed by me
<TheMue> perrito666: *click*
<perrito666> TheMue: you are the on call reviewer and I am making your day hell?
<perrito666> uh, I am on call reivewer
<perrito666> :p
<perrito666> its a good thing I have been reviewing since I got up
<TheMue> *lol*
<bodie_> morning all
<bodie_> blam blam 'murca
<katco> good morning all :)
<katco> i came across a curious few lines. should this panic be removed? c.Assert(scripts[0].line, gc.Matches, pats[0].line, gc.Commentf("line %d", scripts[0].index))
<katco> 				panic("unreachable")
<perrito666> katco: morning, isnt today a holiday for you?
<katco> perrito666: it is
<katco> but i want this change in before boston so i don't lose that velocity. i'm almost done. really should have finished it yesterday
<katco> plus coding is what i do for fun :)
<katco> i promise i'm not this much of a workaholic... i just like to do deep dives to get going. i hope i'm not giving a bad impression =/
<jcw4> katco: you're on probation... too much of this workaholic stuff and BAM
<jcw4> :)
<katco> lol
<TheMue> katco: morning
<katco> no really, back when i was a lead i actively discouraged this kind of thing.
<katco> but i don't like staying new for too long ;p
<katco> TheMue: good morning :)
<jcw4> katco: +1
<TheMue> katco: those unreachable-panics are from earlier times, when Go wanted a return (or panic). today it detects when a code is unreachable.
<TheMue> katco: so IMHO they can be removed
<katco> TheMue: ahh! ok that makes a lot more sense
<katco> gosh... changing upstart config files just breaks all kinds of tests
<katco> spending more time fixing the tests than the bug
<perrito666> that is true for almost anything in juju
<perrito666> I am still fixing ripples from 2 lines I changed on agent
<katco> hmm... i have been watching with great interest discussions about what level of testing is sane, and how not impact architecture just for the sake of testing
<TheMue> so, preparing for football, Iâm off
<rogpeppe> katco: that's a very interesting subject
<rogpeppe> katco: it's something i struggle with all the time
<katco> rogpeppe: i really think so. testing has kind of crept in and become this thing you automatically do
<katco> rogpeppe: as always, have to find the middle way :)
<rogpeppe> katco: i think that 100% testing is often a necessity in dynamically typed languages, but i think can be overkill in a statically type lang
<rogpeppe> katco: i personally don't mind leaving "obviously trivial" pieces of code untested, particularly when the impact of failure will be obvious when the code is actually run
<rogpeppe> katco: but then again, i have also had my share of places where those pieces of code were actually wrong in some way
<katco> rogpeppe: yeah, same here
<rogpeppe> katco: the classic example is: func SomeValue() string {return "some value"}; then the test is func TestSomeValue(c *gc.C) {c.Assert(pkg.SomeValue(), gc.Equals, "some value")}
<rogpeppe> katco: is that test really worth writing?
<katco> i would say no on that one :)
<rogpeppe> katco: it's a slippery slope :-)
<katco> i operate on the philosophy that tests reduce velocity, so they need to be on trial
<katco> but yes, definitely a slipperly slope
<katco> i also operate on the philosophy that smart devs are smart, and we should rely on their good judgement and not make uniform statements like, "all code should be tested" :)
<rogpeppe> katco: i agree entirely. i love tests of tricky code, but the tests in juju are also a real burden we are constantly having to bear
<katco> i have spent the last day trying to understand a test... i don't know, i know i'm new, but that seems like an issue
<bodie_> heheh...  there are some really hairy ones
<katco> this particular one sets up a giant string, then there's a function that splits it on newlines, loops over the newlines, and performs regex escaping magic
<katco> about drove me batty! :p
<bodie_> check out worker/uniter/uniter_test.go.... that's where I've been poking around for a week or two
<bodie_> I've never seen anything quite like it
<katco> lol
<katco> should tests be more complicated than the code they're testing?
<katco> interesting question
<bodie_> there's a cost/benefit between ease of test creation, vs simple extendability if you're testing a very featureful package, I think
<bodie_> that uniter test is a great example, because while it looks huge, and weird, and complicated at first glance, it makes it very simple to add new tests as sequences of steps
<katco> yeah, i see the benefit of that angle
<bodie_> and, there are tons of tests in it (which is itself probably not a great thing)
<katco> i suppose in that case a few comments explaining the framework would go a long way
<bodie_> yes... lol
<katco> well this is very interesting. i don't feel quite as dumb as i did yesterday ;)
<katco> having said that... i think i'm _finally_ ready to land this change
<katco> and then i can get on with my holiday! :p
<bodie_> it was a bit of a ramp up for me as well, but somehow the illusion of complexity keeps dissolving into clear simplicity as I keep digging
<bodie_> I'm not sure whether to blame Go or the smart people writing this code :)
<katco> go does seem to force me towards good simple code. it's one of the reasons i love it
<perrito666> katco: usually that is the programmers skill, I have yet to see a language that forces people into writing good code
<katco> perrito666: i definitely agree. but i have hit brick walls in go, and a week later i realize it's because there's a much simpler way. i.e.: i was fighting the language
<katco> ok here we go... 2nd PR: https://github.com/juju/juju/pull/245
<katco> definitely appreciate feedback on this one
<perrito666> katco: did you do the autosquash part before submitting this?
<katco> perrito666: no i forgot... i thought about going back, but the documentation says "optionally"
<katco> i can definitely go back and do it if you like
<perrito666> katco: hey, if it says optionally, who am I to say something :p
<katco> perrito666: lol i really don't mind. i plan on doing it in the future. i just want to land this thing!
<katco> perrito666: happy to discuss in addition to the comment i just made. just lmk. i think it's a relatively safe change.
<katco> perrito666: i have to step away for a bit. please lmk if/when i can land this so i can sign off for the weekend!
<katco> bbiab
<perrito666> katco: ok, with context now, it seems fine, if you want to get another review from someone here even better if not, go ahead and merge it, I trust you ran all the tests :)
<jcw4> perrito666, katco I scanned through and it LGTM too
<jcw4> I can add a comment if wanted
<rogpeppe> fwereade: are you done yet, or time for a little more resources discussion?
<fwereade> rogpeppe, let's, but gimme 5 mins
<rogpeppe> fwereade: sure
<katco> perrito666: jcw4: tyvm; i did run through all the tests. landing now
<mgz> katco: you're being a guinea pig for me, don't be alarmed by spam on or pr
<katco> mgz: haha ok
<katco> keep in mind that after this lands i'm outta here!
<mgz> katco: ideally, you won't see anything, so it should be fine :)
<mgz> jsut futzing with the landing job
<katco> mgz: sure, sure! i've heard that before! ;)
<katco> pro tip: vivaldi's "summer" makes anticipating the build result much more exciting
<jcw4> katco: not The Ride of the Valkyrie's ?
<katco> rofl
<mgz> hm, labix.org seems to be being not super-reliable
<katco> summer is more dynamic... will it build? it will! or will it?? (bites nails)
<jcw4> hehe
<katco> mgz: his cert expired
<mgz> ah, thanks
<katco> workflow question: supposing this lands successfully, do i mark the bug on launchpad as "Fix Committed"?
<mgz> katco: yup
<katco> hallelujia i'm done with this change! lol
<katco> alright all, i will see you fine people next week!
<jcw4> happy 4th!
<katco> same!
<mgz> katco: see you next week :)
<mfoord> g'night all
<mfoord> some of you I'll see on Monday
<bac> fwereade_: you around?
<fwereade_> bac, kinda sorta
<fwereade_> bac, what can I do for you?
<bac> fwereade_: should be quick.  can you explain ian's point in the last comment at https://bugs.launchpad.net/juju-core/+bug/1316174
<_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
<bac> fwereade_: on precise i have installed juju-core and juju-local.  i expect that to be sufficient but i cannot bootstrap an lxc environment due to this bug.
<fwereade_> bac, I think he's saying "we will fix this by checking whether the user can get the right version of mongodb and fail before getting that far", and I hope it also implies "we will explain what the problem is and how to resolve it in the error message""
<bac> fwereade_: is there a work-around?
<fwereade_> bac, I'm not immediately sure, I'm afraid, but I had *thought* that installing juju-local should be sufficient
<bac> fwereade_: ok.  i'm trying to qa juju-quickstart and it is currently broken on precise.  i'll update the bug with questions for ian.  thanks for your time past eod.
<fwereade_> bac, i suspect that https://bugs.launchpad.net/juju-core/+bug/1289316 and https://bugs.launchpad.net/juju-core/+bug/1290890 are also relevant, but I don't have enough context to know what';s really going on
<_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1289316>
<_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise <ci> <deploy> <precise> <regression> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1290890>
<fwereade_> wwitzel3, ^^
#juju-dev 2014-07-05
<jcw4> Any lonely souls wanna do a code review? https://github.com/juju/names/pull/12
<katco> anyone around? need some help with configuring an email client =/
#juju-dev 2014-07-06
<thumper> waigani: morning
<waigani> thumper: morning
<thumper> waigani: https://plus.google.com/hangouts/_/g7oraq255eaz4jgtkfbtptrcm4a?authuser=1&hl=en
<waigani> thumper: I have to login with other account - 5min
<thumper> waigani: I could just invite the other you
<waigani> thumper: in
<waigani> thumper: can't hear you?
<thumper> ah, couldn't hear you either
<waigani> thumper: I'm doing a restart hang on
<thumper> ok
<mwhudson> ubuntu@linaro-test:~$ juju version
<mwhudson> 1.18.1-trusty-armhf
<mwhudson> this is on a arm64 system
<thumper> hm...
 * mwhudson upgrades to 1.20
<mwhudson> $ juju version
<mwhudson> 1.20.0-trusty-arm64
<mwhudson> ok that's better
<thumper> mwhudson: what did you do?
<mwhudson> deploying a local charm still doesn't work though
<mwhudson> thumper: added the juju/stable ppa and updated
<thumper> mwhudson: I've deployed local charms
<mwhudson> i'm sure some people ahve :)
<thumper> can you pastebin the directory layout and the command, and output?
<mwhudson> thumper: are you in #juju?
<thumper> yeah
<mwhudson> scroll up a bit? :)
<thumper> mwhudson: how is your git?
<mwhudson> thumper: passable, fairly uneven
<thumper> mwhudson: do you know how to merge changes from another branch but not the actual revisions?
<thumper> bonus points for interactive merge
<mwhudson> thumper: no
<thumper> ok
 * thumper does some git hunting
<mwhudson> i guess you can do the merge and reset --soft the merge commit out?
<mwhudson> or is it just reset
<mwhudson> then commit the changes again
<thumper> git merge --squash
<thumper> this may be the heart of my new pipeline work
<thumper> since I can't interactively merge
<thumper> I think I'll merge everything
<thumper> then revert some things
<thumper> or stash
<thumper> is git stash linked to a branch?
#juju-dev 2015-06-29
<menn0> thumper: the next fix for bug 1468994: http://reviews.vapour.ws/r/2042/
<mup> Bug #1468994: leadership settings documents written out without env-uuid field <juju-core:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1468994>
<menn0> thumper: also, not sure if this relevant to what you're looking at: https://bugs.launchpad.net/juju-core/+bug/1457225/comments/9
<thumper> don't think that is related to this current issue
<menn0> thumper: k
<thumper> davecheney: I don't suppose there is a way for a function in Go to annotate the call stack?
<thumper> davecheney: that would be so handly when analysing panics
<davecheney> thumper: no, sorry, there is not
<davecheney> i did see one tool published
<davecheney> but I cannot rememver it's name at the moment
<davecheney> it didn't annotate stack traces
<thumper> oh well
<davecheney> but it did do some kind of analysis/grouping
<thumper> davecheney: \o/
<thumper> I have a panic with the workers showing restarting
 * thumper digs
<davecheney> thumper: paste ?
<thumper> sure...
 * thumper finds the start
<thumper> davecheney: http://paste.ubuntu.com/11791044/
<thumper> davecheney: it is even one of the tests known to cause issues
<thumper> davecheney: line 301 is the a.Stop call from the test (pretty sure)
<davecheney> oww, this  paste is hurting my machine
<thumper> line 347 shows a worker has said it started after everyone had been killed
<davecheney> is this the "did not reach expected state" ?
<thumper> line 255 also looks weird
<davecheney> the line ofhte output ?
<thumper> davecheney: I think it is the case of the goroutine not fully starting before being told to stop
<davecheney> or another line ?
<thumper> 355 sorry
<thumper> davecheney: pretty sure this is all due to timing around the workers that had been asked to start haven't fully started
<thumper> davecheney: and then told to die
<thumper> and they all get confused
 * thumper digs into timing a bit more
<davecheney> how are workers told to stop ?
 * thumper rages
<thumper> davecheney: remember when I said that this would be due to a worker finishing with a non-fatal error?
<thumper> look at line 579
<davecheney> uh h
<davecheney> uh oh
<davecheney> i htink i even logged an issue about that permission deined error
<thumper> and another...
<davecheney> asking, why does it do this
<thumper> 616 - 619
<thumper> NFI
<thumper> test isolation failure
<thumper> where it shouldn't be looking at /var/lib/juju
<thumper> however, that isn't the only problem
<davecheney> isFatal is passed into the runner
<davecheney> so there is no knowing that it considers fatal
<thumper> I'm prepared to bet money that this is another case of multiple unexpected issues causing problems with each other
 * thumper digs more
<davecheney> i'd back that
<thumper> I'm so happy to get this logging...
<davecheney> so, i see lots of start "worker"
<davecheney> but no corresponding stopped "worker"
<davecheney> thumper
<davecheney> how does killWorker work ?
<thumper> you should see killing and exited
<thumper> killing is the request to kill it
<davecheney> info.worker.Kill() isn't plumbed through to the worker
<thumper> and exited when it is done
<davecheney> it's not passed to start()
<thumper> it is all a bit convoluted
<davecheney> thumper: hangout call ?
<thumper> gimmie a few minutes... in the middle of something
<davecheney> i can see a case where the started worker's kill channel will not be hooked up correctly
<davecheney> ie, the kill signal is delivered to the previous invocation of the worker
<thumper> davecheney: 1:1
<davecheney>                         workerInfo.worker = nil
<davecheney>                         go runner.runWorker(workerInfo.restartDelay, info.id, workerInfo.start)
<davecheney>                         workerInfo.restartDelay = RestartDelay
<davecheney>                                 } else {
<davecheney>                                         logger.Errorf("exited %q: %v", info.id, info.err)
<davecheney>                                         workerInfo.worker = nil
<davecheney>                                 }
<davecheney> thumper, menn0 https://github.com/juju/juju/pull/2668
<menn0> davecheney: thumper has lost power at home
<menn0> davecheney: looking
<davecheney> shtter
<menn0> davecheney: I don't completely understand this change
<davecheney> menn0: hangout ?
<menn0> davecheney: AFAICS killAll is only called when the runner's tomb is dying
<davecheney> correct
<davecheney> it's hard to explain in irc
<davecheney> it's taken thumper and I all morning
<menn0> davecheney: ok standup hangout
<thumper> power is back
<thumper> menn0, davecheney: I found something very interesting
<thumper> api worker starts: upgrader, upgrade-steps, and api-post-upgrade
<thumper> however when the kill order is given
<thumper> we see:
<thumper> killing upgrader
<thumper> killing api-post-upgrade
<thumper> ugh
<thumper> just worked out that the upgrade-steps have just finished
<thumper> however
<thumper> even though we say killing api-post-upgrade
<thumper> it doesn't kill any of it's workers
<thumper> menn0: standup hangout?
<thumper> menn0, davecheney: logging for 1.24 http://reviews.vapour.ws/r/2045/
<thumper> haven't been able to reproduce the panic yet with this logging in
<thumper> but still running tests
<menn0> thumper: reviewed, just some small suggestions
<thumper> k
<davecheney> thumper: looking
<thumper> davecheney: sok, menn0 reviewed
<thumper> davecheney: however with this logging, can't reproduce the error
<davecheney> thumper: http://paste.ubuntu.com/11791616/
<davecheney> run it under the stress
<davecheney> copy that to ~/stress.bash
<davecheney> cd $PATH
<davecheney> bash ~/stress.bash
<menn0> thumper: with that you might be to reproduce the bug more quickly by just running one of the tests that is known to trigger the issue instead of all the tests (maybe?)
<thumper> ok
 * thumper stresses the tst
<thumper> davecheney: even with the stress script running just the upgrade suite, it isn't failing
<davecheney> shitter
<thumper> 25 times in a row it is good now
 * thumper tries the entire package
<thumper> I think I have it again
<thumper> but we are no further than we were before...
<thumper> can't tell... waiting for CI to throw it up
 * thumper is done
<dimitern> jam, are you around for our 1:1?
<jam> dimitern: just trying to connect now
<jam> dimitern: I think google's creds need me to login again, but it isn't giving me the window
<dimitern> jam, ok
<mup> Bug #1453096 opened: Machine agent state changes not included in the mega-watcher <cloud-installer> <landscape> <juju-core:New> <juju-gui:Triaged> <https://launchpad.net/bugs/1453096>
<dimitern> dooferlad, TheMue, PTAL http://reviews.vapour.ws/r/2049/
<katco> ericsnow: standup
<mup> Bug #1469731 opened: Leader should probably change when removing unit <juju-core:New> <https://launchpad.net/bugs/1469731>
<wwitzel3> katco: you enjoyed canceling those, I can tell
<katco> wwitzel3: haha
<katco> wwitzel3: i always enjoy canceling meetings ;)
<mup> Bug #1469777 opened: juju-local falsely claimed to be missing <ci> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1469777>
<mup> Bug #1469799 opened: Agent tests fail with no output <ci> <ppc64el> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1469799>
<mup> Bug #1469799 changed: Agent tests fail with no output <ci> <ppc64el> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1469799>
<mup> Bug #1469799 opened: Agent tests fail with no output <ci> <ppc64el> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1469799>
<mup> Bug #1469807 opened: ListSuite.TestOutputFormats fails on Windows <ci> <test-failure> <windows> <juju-core:Incomplete> <https://launchpad.net/bugs/1469807>
<mup> Bug #1469807 changed: ListSuite.TestOutputFormats fails on Windows <ci> <test-failure> <windows> <juju-core:Incomplete> <juju-core net-cli:Triaged> <https://launchpad.net/bugs/1469807>
<mup> Bug #1469807 opened: ListSuite.TestOutputFormats fails on Windows <ci> <test-failure> <windows> <juju-core:Incomplete> <juju-core net-cli:Triaged> <https://launchpad.net/bugs/1469807>
<katco> ericsnow: got time to chat about the api server abstractions? wwitzel3 natefinch welcome as well
<ericsnow> katco: sure
<katco> ericsnow: moonstone
<mup> Bug #1469844 opened: Juju bootstrap fails with nonce mis-match error <bootstrap> <ci> <intermittent-failure> <maas-provider> <juju-core:New> <juju-core devices-api-maas:New> <juju-core feature-proc-mgmt:New> <https://launchpad.net/bugs/1469844>
<katco> natefinch: hey do you have a branch i can look at for the server methods? i need to see how you're using the api server as an example for how to generalize my stuff
<katco> jam: hey you around for a pretty simple question about registering facades?
<natefinch> katco: yeah
<jam> katco: what's up?
<katco> jam: here: https://github.com/juju/juju/blob/master/apiserver/common/registry.go#L126
<katco> jam: is there any reason newFunc couldn't be of type func(*state.State, *common.Resources, common.Authorizer) (interface{}, error)?
<jam> katco: so this isn't the code as I wrote it, so I'll have to figure out why it isn't
<jam> someone added the "ForFeature" versions, and changed something.
<natefinch> katco: sorta rough still and in the middle of it, so it doesn't compile, but the code pretty much makes sense: https://github.com/natefinch/juju/blob/proc-server-api/process/api/server/server.go   and https://github.com/natefinch/juju/blob/proc-server-api/process/api/server-args.go
<katco> jam: natefinch no worries at all. the stuff i'm looking for is hand-wavey anyway
<jam> katco: I remember now
<jam> concrete return types
<jam> katco: specifically, our NewFoo() functions returns *Type objects, and we reflect on that Type to determine the API
<katco> jam: can't we cast the interface to the concrete type using reflection?
<jam> katco: you can't pass a function that returns a concete type to an interface that says it returns interface{}
<katco> jam: sorry, i meant have the functions go ahead and return interface{}, but where the type of that interface is important, discover its true type via reflection
<jam> katco: http://play.golang.org/p/XjucCOijN9
<jam> katco: we can't do registration time lookup for the signature of the API, (we have to actually call it)
<jam> katco: but more than that
<jam> if you want to test NewFoo
<jam> you really want a Foo there
<jam> now we can rewrite all of the tests to use NewFoo().(Foo)
<katco> jam: well the tests are hte easy problem, right? yeah what you just said
<katco> jam: don't want to take too much of your time after-hours... we're just fiddling with that area of the code and thought it might make more sense to be concrete about the function type. if i can get the reflection to work out, are you opposed to that approach?
<jam> katco: so there is RegisterFacade which takes the exact thing you were asking
<jam> but it also requires you to pass in a reflect.Type
<katco> jam: ah so there is
<jam> katco: IMO its really nice to just be able to have a normal NewFoo() function
<jam> and then be able to Register(NewFoo)
<jam> and both NewFoo acts like other NewFoo functions (returning a Foo) and it has the type that you need to register, so you don't have to import reflect into all of your packages.
<katco> jam: the only issue is that we've taken a (potential -- if the reflection bit works out) compile-time error and made it runtime
<jam> katco: how do you mean a compile time error? because you're changing the signature into interface{}
<jam> which means it has no signature
<jam> so the thing you *actually* care about
<jam> which is that you got the right type when you call it
<jam> is only determined *when it is called*
<jam> katco: with this way, you find out during Register()
<jam> which happens during init()
<jam> which means that every juju process finds out really fast
<katco> jam: so, iirc, the rpc stuff expects a type of interface{} anyway, so it can reflect and find the methods, etc.
<katco> jam: it's the registration that requires the specific signature, right?
<jam> katco: its the registration that allows a Type which it will then use to expose the API and it confirms at actual call type that the object conforms to the concrete Type that was registered.
<katco> jam: so the bit i'm thinking we can still do that, even if the factory methods returned an interface
<katco> jam: oops s/the bit//
<jam> so there is an 'interface{}' level under the covers, but it means that the infrastucture helps you DTRT (I think)
<jam> katco: so you can certainly do it, and use RegisterFactory instead of RegisterStandardFactory
<katco> jam: i'm wondering if you can do it w/o passing in the reflect.Type as well
<jam> katco: how do you know what methods will be available in order to define the API?
<katco> jam: i'd have to do some research, but my gut says yes. this code says someone else did the research and said no however ;)
<jam> katco: so the original code was all static analysis
<katco> jam: i'm thinking you can reflect on an interface{}, get its real type, and then do as we do now
<jam> we had 1 top level type that exposed lots of GetFoo() Type methods
<jam> katco: you could decide that you can call any method you like from the API and we'll call the function and then late tell you "the object we created doesn't support the method you wanted"
<katco> jam: that's what we have no anyway isn't it? the api layer just uses strings to call methods?
<jam> katco: it rejects the requests before calling the factory
<katco> jam: ah i see, so the type isn't constructed before failing
<jam> katco: *object* here
<katco> jam: well, hows this: its not critical to what i'm working on. but if i find some time, i'll do some experiments, and if i think its headed in a beneficial direction given what points you've raised, i'll submit a pr and we can shoot holes in it
<katco> s/its/it's/
<wwitzel3> katco: I'm back if you still want to chat
<katco> natefinch: ty... so how you're using state hasn't really been addressed yet?
<katco> wwitzel3: ty, ericsnow and i talked. think i'm good for now
<natefinch> katco: you mean like passing in an interface?  No, I hadn't written that yet, but you can probably figure it out by looking at the commented out functions that call state functions which ericsnow is writing.
<katco> ericsnow: natefinch: can we hop in moonstone rq? i want to run an approach by you. wwitzel3 you are welcome too
<natefinch> katco: seems like the RegisterStandardFacade function should be in charge of that... it's already passing in state. It could instead pass in an interface
<ericsnow> katco: k
<natefinch> katco: sure...  I have to go in 25 minutes, though, have a quick errand to run.
<thumper> mramm2: weren't we going to have a chat about now?
<wwitzel3> ericsnow: ping if you're around
<ericsnow> wwitzel3: sure
<mbruzek1> is the juju-dev@lists.ubuntu.com a private or public email list?
<mbruzek1> nevermind it looks public to me
<mbruzek1> https://lists.ubuntu.com/archives/juju-dev/2015-June/thread.html
<mup> Bug #1437445 changed: worker/uniter: FAIL: util_test.go:665: "never reached desired status" <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1437445>
<katco> anastasiamac: running just a little late. brt
<anastasiamac> katco: nps
<sinzui> thumper: ppc64el is retesting with a cap on procs
<thumper> sinzui: I read that as "crap on procs"
<sinzui> :)
<sinzui> thumper: also, maybe we can get the mem increaed to 16 for this one instance
<thumper> sinzui: is the power test running?
<thumper> sinzui: how's it going?
#juju-dev 2015-06-30
<thumper> davecheney: ping
<davecheney> thumper: ack
<thumper> davecheney: hangout to talk about sigquit and logs?
<davecheney> sure
<thumper> davecheney: 1:1 hangout?
<davecheney> sure
<sinzui> thumper-afk: the power test failed. My hack to run subpackages is wrong. I need to try again.
<davecheney> thumper-afk: got the basics working
<davecheney> thumper-afk: lucky(~/src/github.com/juju/juju/state) % ./state.test
<davecheney> ^\exiting with signal: quit
<davecheney> lucky(~/src/github.com/juju/juju/state) % ./state.test
<davecheney> ^Cexiting with signal: interrupt
<davecheney> menn0, thumper-afk https://github.com/juju/juju/pull/2675
<thumper> davecheney: ta
 * thumper looks
<davecheney> let me know if it looks sane
<davecheney> i did a bit of testing with the sample function supplied
<davecheney> i can hook and unhook functions
<davecheney> s/functions/signals
<thumper> davecheney: hangout?
<davecheney> thumper: two secs
<davecheney> gotta change computers
<davecheney> thumper: i'm in the 1:1
<thumper> http://reviews.vapour.ws/r/2053/
<thumper> davecheney: ^^
 * thumper is running out
<thumper> if you are happy, please add $$merge$$ bits
<thumper> cheers
<natefinch> Good god, I just wrote 300 lines of ridiculously tedious code just so we have copies of our business logic structs in the API.  And now I have to go write tests for this crap.
<mwhudson> fatal error: runtime: stack split at bad time
<mwhudson> i think i have annoyed the go gods
<mwhudson> (this is on arm64 though)
<davecheney> mwhudson: excuse me, is not a good time for a stack split ?
<davecheney> thumper-afk: LGTM
<davecheney> probably will end up dumping more than we except
<davecheney> but we can always disable ti again
<mwhudson> davecheney: https://github.com/golang/go/issues/11482
<_thumper_> hmm...
<_thumper_> for some reason the nick thumper is temporarily unavailable
 * _thumper_ needs to work out who to ping
<_thumper_> sinzui: I've landed a tweak for the upgrade tests so if they timeout and get killed, we dump the logs
<_thumper_> sinzui: so we can debug the ci failures
<_thumper_> sinzui: how soon is the next ci run for 1.24?
<thumper> and now we wait
<thumper> o/ dimitern
<davecheney> thumper: looks like your change landed
<thumper> davecheney: yep, on 1.24 and master
<thumper> hopefully the next ci test run will give us more logging
<thumper> davecheney: actually I wonder if I can reproduce now...
<thumper> davecheney: as the timing is different between -check.vv and what we have done
<dimitern> thumper, hey
<thumper> .vv causes lots of I/O sync
 * thumper goes to poke the power machine
<davecheney> thumper: all that io flushing to disk will generate a lot of scheduler churn
<thumper> agreed
<davecheney> what was straight line code will weave through the scheduler
<davecheney> \o/ butterfly wings
<davecheney> with that said
<davecheney> it is rare that making a program _more_ concurrent increases it's stability
<thumper> hmm... it appears to be passing individually
 * thumper tries with the whole suite
 * thumper sighs
<thumper> still seems to be passing
<thumper> bah humbug
<thumper> davecheney: I love yours stress test script
<davecheney> that thing broke so many people's dreams
<thumper> davecheney: I think we should probably commit that into the tree somewhere
<thumper> :)
<davecheney> i've been using it for years
<davecheney> for some reason GOMAXPROCS=42 (no shit)
<thumper> so much better that a bash for loop
<davecheney> always caused a set of tests to segfacult
<thumper> haha
<thumper> that is freaking hilarious
<davecheney> 42 insn't a prime
<davecheney> but 7 is one of it's factors
<davecheney> and that is a prime
<davecheney> so that's something
<thumper> pffft
<thumper> the suite has passed heaps, then failed with mongo not coming up
 * thumper retries
<thumper> davecheney: just noticed that the stress script stops when a test fails
<thumper> nice
<davecheney> it's designed for tests that take seconds (cough)
<davecheney> so if it didn't stop, you may not notice the failure
<thumper> ffs
 * thumper walks away again
<thumper> dinner time
<fwereade> ashipika, ping
<fwereade> ashipika, was wondering if you needed any clarification re http://reviews.vapour.ws/r/1933/ -- in particular my suggestion that it feels like an operation?
<ashipika> fwereade: hey.. yes.. some clarification would help.. :)
<fwereade> ashipika, ok, so, we've got to the point where pretty much everythiong the uniter *does* is encapsulated in an operation
<fwereade> ashipika, see uniter/operation
<ashipika> fwereade:  *looking*
<fwereade> ashipika, the idea being that the modes can decide what needs to be done
<fwereade> ashipika, but *how* those things are done is determined elsewhere
<fwereade> ashipika, it's not 100% clean, particularly the entanglement of operation state with operation definition
<fwereade> ashipika, but at first blush it looked like a plausible way to keep the flushing details out of the modes
<ashipika> fwereade: ok.. i'll have a look at operations and if i have any questions i'll come back to you.. but from what you've said i can see how this could be a good fit for an operation
<fwereade> ashipika, (...and I hold out hopes that we'll be able to change the modes into something more isolated and comprehensible, but every little bit of extra complexity in there works against that)
<fwereade> ashipika, ok, cool
<thumper> fwereade: hey, I'd like a chat if you have a few minutes
<fwereade> thumper, sure
<mattyw> fwereade, jam if one of you has 2 minutes I have a hopefully trivial request
<fwereade> mattyw, oops sorry!
<fwereade> mattyw, what can I do for you?
<fwereade> axw, btw, if you're on: I'm missing a bit of context around the session-handling in state/tools.go (and a little bit in state/images.go, but that's simpler)
<fwereade> axw, possibly what I'm confused about is the underlying reasons for the differences between the two?
<axw> fwereade: I'll need to refresh state, one minute
<axw> fwereade: I think I just realised I could do it a better way when I did the second one (image metadata), and never went back to clean up tools storage
<axw> fwereade: AFAIR, the uses of ToolsStorage only keep ahold of it for a brief time, so the session won't become stale
<axw> fwereade: but it would be better to just Copy and dispose inside the method call
<rogpeppe> axw: hiya
<axw> rogpeppe: ahoy
<rogpeppe> axw: have you had anything to do with the juju user support, by any chance?
<axw> rogpeppe: none
<rogpeppe> axw: ah, ok.
<rogpeppe> axw: darn
<rogpeppe> axw: :)
<axw> rogpeppe: I think thumper
<rogpeppe> axw: he's never online when i am :-(
<axw> yeah :/
<rogpeppe> axw: i *think* this is meant to work: http://paste.ubuntu.com/11798402/
<axw> rogpeppe: "juju switch" doesn't seem right
<axw> rogpeppe: that's always been for switching environments...
<rogpeppe> axw: i thought that a jenv file represented an environment
<rogpeppe> axw: (and some creds to access that environment)
<axw> rogpeppe: ah, I see. hrm. I guess it's validating against environments.yaml? not really sure
<rogpeppe> axw: looks like configstore list is broken somehow
<rogpeppe> axw: ha
<rogpeppe> axw: "juju user add" writes the .jenv file to the current directory, it seems
<axw> rogpeppe: heh :)
<TheMue> hmpf, three disconnects in a few minutes
<TheMue> hangout
<dooferlad> omw
<fwereade> axw, still around?
<axw> fwereade: hey, what's up?
<fwereade> axw, was wondering about Unit.findCleanMachineQuery and its returned closer
<fwereade> axw, it's seeming like a good idea to pass the closee in, and keep that all happening at one level
<fwereade> axw, any objections?
 * axw looks
<axw> fwereade: pass the closee in? pass what closee in to what? how about change findCleanMachineQuery to take a *machineDoc, and execute the query directly?
<fwereade> axw, one client wants .One and one wants .All, I think
<axw> fwereade: ah, didn't see hte other one.
<fwereade> axw, but if the two clients each did their own newDB, passed that in, and closed it themselves, it might be sane?
<axw> fwereade: oh I see. that sounds fine to me
<fwereade> axw, cool, thanks, sorry mangled english in original question :)
<axw> nps
<fwereade> dammit, I'm not sure that makes that much sense actually, at least not without inappropriate application of secret knowledge :/
<fwereade> axw, hmm. how would it be if we just made it return terms, and made the client get the machines collection itself? what's the worst that could happen re copied sessions there? we already know it's potenntially inaccurate; coudl it get apppreciably worse?
<axw> fwereade: sounds reasonable, but how would you do the container check bit?
<axw> fwereade: or the instance-data bit for that matter
<axw> sounds like it'd get a bit messy
<axw> seems like
<fwereade> axw, I *think* it's less messy to just copy the session inside fCMQ for the container and instanceData checks
<fwereade> axw, and defer those closes in a sane scope
<fwereade> axw, and then, separately, let the clients use their own session copies to actually grab the machine, and defer *those* closes in a sane scope
<fwereade> axw, given that the transactions are themselves probably running in their *own* session I don't think things will get worse
<ericsnow> fwereade: thanks for the reviews
<axw> fwereade: yeah, I think that'd be fine.
<fwereade> axw, cool
<fwereade> ericsnow, hope they help :)
<fwereade> axw, ok, looking back at tools.go
<fwereade> axw, does tools storage depend on any per-environment features? or can I just create a plain txn runner?
<axw> fwereade: it doesn't have env-specific metadata, though it possibly should
<fwereade> axw, that said I probably ought to give it an env-aware runner anyway
<fwereade> axw, if it doesn't touch env bits it makes no difference having it
<fwereade> axw, if it does, *not* having it makes a big difference
<axw> fwereade: yep. I think it'd be best to pass one in if possible, to avoid later surprise
<axw> fwereade: what are you doing anyway?
<axw> w.r.t. tools storage
<fwereade> axw, getting angry about raw DB access all over the place and trying to make it impossible
<fwereade> axw, or at least *harder* to do without knowing you're being bad
<axw> fwereade: heh :)  sounds good
<ericsnow> fwereade: you have some time to talk about state?
 * perrito666 is suddenly held in a very strange position in front of his computer by a back contracture
<fwereade> ericsnow, sure, but probably best on irc right now
<natefinch> ericsnow: where were you thinking the APIClient implementation would live?
<natefinch> ericsnow: process/api/client  I assume
<ericsnow> natefinch: right
<natefinch> ericsnow: hmm.. problematic to write the client code without the endpoint args available
<ericsnow> natefinch: why wouldn't they be available?
<natefinch> ericsnow: can you or wwitzel3 do a quick review on the server code I PR'd?  It's super simple code.  It will probably need some tweaks once your state branch lands, but only super minimal things (like status is a string instead of a struct, etc)
<ericsnow> natefinch: already did :)
<mup> Bug #1470150 opened: CentOS fails to bootstrap using juju 1.24 <bootstrap> <centos> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1470150>
<natefinch> ericsnow: huh, weird, wonder where that email went.  Maybe I archived it by accident.  Anyway, thanks!  I'll work on that,.
<ericsnow> natefinch: cool
<natefinch> ericsnow: LOL "TestUnregisterTransaction"   .... this is what I get for writing tests during standup ;)
<ericsnow> natefinch: :)
<natefinch> I hate it when I delete code and it makes my coverage percentage go down :/
<natefinch> that was well-tested useless code
<sinzui> ericsnow: natefinch katco : I need help with the go test command line. I want to omit githubm.com/juju/juju/cmd/jujud from the test run (just that packge and below). I tried -run, but is donât match on path
<sinzui> github.com/juju/juju/cmd/jujud I mean
<katco> sinzui: i don't think go test or gocheck have an exclusion flag
<natefinch> sinzui: omission is not really supported, AFAIK
<katco> sinzui: you just have to test only the things you care about (i.e. all the import paths)
<natefinch> sinzui:  you'll have to do some CLI hacking.  You can do go list github.com/juju/juju to get a list of all the packages and then just run go test manually over each one except jujud
<sinzui> katco: natefinch I was afraid of that. I can contrive a way to test subpackages, but is gets ugly
<natefinch> it's not actually horrible, since you're still using the go tool to get the list of packages
<sinzui> natefinch: yeah, that is how I disccovered that juju/juju/cmd will fail, but running the subpackages by itself themselves will pass
<natefinch> sinzui: I remember seeing something like that a while back.  probably a cleanup issue or something
<sinzui> natefinch: oh is there a way to ask go test to give me a list of all the packages it finds? I could re-order such as list to that the problem ppc package it tested first
<katco> sinzui: go list github.com/juju/juju/... |grep -v github.com/juju/juju/cmd/jujud |xargs go test
<natefinch> sinzui: go list creates the same list that go test would
<sinzui> :)
<sinzui> natefinch: thank you. This looks promising
<natefinch> ^^ katco too
<abentley> sinzui or jog: I have two branches for review, one a prerequisite of the other: https://code.launchpad.net/~abentley/workspace-runner/s3-script/+merge/263383 https://code.launchpad.net/~abentley/workspace-runner/s3-artifacts/+merge/263384
<bogdanteleaga> how can I test an unexported implementation of an interface? currently I'm using export_test and for a function I instantiate the type and call the method. Is there a better way?
<jog> abentley, I'll take a look
<abentley> jog: Thanks.
<fwereade> axw, if you're awake you shouldn't be, but in case you are: why is image metadata in the images DB, but tools metadata in the juju db?
<natefinch> fwereade: do we require comments on every exported field on an exported struct?
<katco> ericsnow: hey, sorry, finally rolling back onto api server abstraction.
<katco> ericsnow: i took a look at what other apiserver facades were doing to see if we could extract some commonality, but it doesn't look like there is any.
<ericsnow> katco: np
<katco> ericsnow:  given we're just going to be using the standard RegisterFacade, and composing an adapter in components/all/process.go... what is the abstraction bit?
<ericsnow> katco: I do think we should add RegisterHookContextFacade
<abentley> jog, sinzui: So I get two reviews for the first branch and no reviews for the second?  Is that how it is?
<katco> ericsnow: i haven't found anything that would make that unique
<ericsnow> katco: it takes care of auth
<jog> abentley, sorry on a call
<sinzui> abentley: I am doing the second. I am just distracted
<katco> ericsnow: well, different facades use auth in different ways
<abentley> jog, sinzui: No worries.
<ericsnow> katco: context hook facades (i.e. uniter) only use auth in 1 way
<katco> ericsnow: so this entire card turns out to be creating a RegisterHookContextFacade, calling AuthUnitAgent, and that's it?
<ericsnow> katco: basically RegisterHookContextFacade would take care of most of the stuff that is in newUniterBaseAPI (in apiserver/uniter/uniter_base.go)
<katco> ericsnow: there's actually not much in there aside from constructing some closures for the uniter
<fwereade> natefinch, ...not *necessarily*, but I have been finding that forcing myself to document every field has generally led only to good things
<natefinch> fwereade: kk... I find that usually the field is pretty obvious and the comment is redundant, and just makes the struct harder to read.  Howeever, occasionally it has made a better name for the field more obvious.
<natefinch> fwereade: and of course, sometimes a field name can't encompass all the info you need about the field
<fwereade> natefinch, yeah
<perrito666> natefinch: nonsense, unles your attribute has a very java like long descriptive name, a doc is always a good thing
<fwereade> natefinch, I do still kinda believe in my heart that every comment is a sign the code is insufficiently clear, but I don't think that's *actually* as helpful as I wish it were :)
<fwereade> natefinch, perrito666: and, to be fair, I would say that while java-style naming has its squickiness, I think it's more a consequence of trying to retain clarity on large projects with lots of people working on them; and that juju has, for a while, been big enough that every little bit of bludgeoning obviousness helps
<natefinch> perrito666: I'm with fwereade - if the name isn't clear enough, that's a problem with the code.  Comments are nice, but they shouldn't be everything... and I think that if you need to call out something about a specific field, it's actually more appropriate to do it on the comment for the struct itself.
<natefinch> perrito666, fwereade - it's like comments on a function - you don't comment every arg... if an argument is non-obvious, spell it out in the comment for the function.  Most of the time, most arguments and fields should be obvious, and the comments on them reflect that:  "ID is the unique id of the foo"
<perrito666> natefinch: data structures cannot be all that expressive by themselves
<fwereade> perrito666, natefinch: the strongest argument against comments, ofc, is that they lie, and we're not immune to that
<fwereade> perrito666, I dunno, what's that quote
 * fwereade goes hunting
<perrito666> fwereade: poor translation from spanish
<natefinch> fwereade: actually, I think that the problem with comments on fields and arguments is that they're so often useless, that if one is actually USEFUL, no one will read it because they'll assume it's useless.
<fwereade> natefinch, perrito666: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I wonât usually need your flowcharts; theyâll be obvious."
<natefinch> perrito666: I agree that comments aren't bad themselves.... but by requiring them on the vast majority of fields that *are* obvious..... you then can't see the forest for the trees
<perrito666> natefinch: many times our structures have fields that represent something that makes sense to someone that knows a lot about juju only, and that doesnt mean that the name is unclear, only that the struct has some baggage, and given the size of the project, a comment helps there
<fwereade> natefinch, perrito666: again, more usually true in theory than in practice, because people write run=bbish data structures just as much as they write rubbish code
<TheMue> type thisStructContainsInformationAboutFilesMatchingAGivenCriteria struct { thisIsTheNameOfTheFileThatMatchedTheCriteria string ... }
<natefinch> TheMue: so you've written java?
<TheMue> natefinch: one, in my dark past hours. but even then not so long identifiers
<fwereade> natefinch, perrito666, TheMue: the trouble is that there often *is* more meaning than can be packed into a name
<fwereade> natefinch, perrito666, TheMue: consider the Life fields in state
<fwereade> natefinch, perrito666, TheMue: they're *loaded* with subtle meaning, but everything has its own Life field
<natefinch> Well, for that, I think that either a comment on the struct itself, or perhaps an exception to the no-comments-on-fields rule is fine.  But for the vast majority of cases, the comment on a field is just noise.
<TheMue> fwereade: yes, where I still like comments is (a) in describing behavior, not meaning, and (b) as a kind of optical separator. with highlighting quickly blocks are identifyable
<natefinch> for example: https://github.com/juju/juju/blob/master/apiserver/params/actions.go#L54
<fwereade> natefinch, perrito666, TheMue: where do we document them? I write quite a lot of useful stuff in the doc directory, and I've tried to make a point of telling everyone to read them when they join, but...
<fwereade> sorry, s/write/wrote/ -- I have suffered some degree of disillusionment
<natefinch> no comments on fields... aside from the difference between Message and Status, all the fields are pretty damn obvious, and a comment is not going to help anyone.
<perrito666> I am not all that clear, how does he know that the action is going to be completed? :p
<natefinch> perrito666: that information should be on the struct itself or the function that uses it... not on the field.
<perrito666> ok ok, I give up, there is a level of obviousness
<natefinch> it also comes down to how it looks in godoc.  Field comments are in plaintext, struct and function comments are able to be styled and are therefore a lot easier to read
<natefinch> for example: https://godoc.org/github.com/juju/deputy#Deputy
<natefinch> This might be the exception to the rule, since the fields are basically 100% of what the package is about.  but even so, it's kind of hard to read.
<fwereade> natefinch, yeah, like so many things it's a matter of taste and judgment
<natefinch> yep
<perrito666> natefinch: Errors is a poor name for that field :p
<fwereade> natefinch, fwiw, I'm trying to factor some stuff into one place for state, and I've ended up with this type: http://paste.ubuntu.com/11800862/
<fwereade> natefinch, overcommented? perhaps
<fwereade> natefinch, but *useless* comments? I hope not
<fwereade> natefinch, and I don't know where to put them if not the struct iitself
<natefinch> perrito666: not when used in the code: d := deputy.Deputy{ Errors: deputy.FromStderr }
<natefinch> fwereade: I think this is like my deputy example, where there's a lot of subtlety in the fields.  Maybe this is a good use for field comments... but then again, it's really hard for me to even see what fields exist in the struct because of all the comments.  The comments might do just as well living in the struct comment, and leave the body of the struct easier to read.  I dunno.
<fwereade> natefinch, yeah -- it's not great, but AFAICS documenting the structs is less awful than any other approach
<natefinch> fwereade: maybe for your struct, short comments per field and longer comments in the struct comment is warranted.
<perrito666> natefinch: this is close to derive in an editor war
<natefinch> perrito666: is derive an editor?
<mup> Bug #1455623 opened: TestPingCalledOnceOnlyForSeveralWorkers fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1455623>
<perrito666> lets suppose I want to do something for command line like juju deploy --flag foo=afoo bar=abar beh=beh, what would be the better syntax? (or does gnuflag support multiple --flag?
<perrito666> natefinch: was that a joke? I am unsure
<natefinch> perrito666: not a joke.  I could google for it, I suppose
<waigani> fwereade: thanks for email. I replied but I'm not sure if it sent, my client is playing up (can't see it in sent box), did you get it?
<perrito666> lool
<perrito666> natefinch: apparently some of my english is outdated
<perrito666> says the dict
<perrito666> archaic :  bring
<natefinch> heh
<natefinch> perrito666: sorry, the way it was used, it sounded like derive was an editor.... I never know what wacky editors people use.  if sublime can be an editor, why not derive?  :)  Sorry for the misunderstanding.
<perrito666> derive was an old math sofware for windows 3.1
<natefinch> perrito666: make flag work like constraints --constraints "foo=bar baz=bat"
<perrito666> ah, that is nice, thx
<mup> Bug #1470220 opened: Juju-deployer incorrectly reporting errors in juju 1.24.0 environment <juju-core:New> <juju-deployer:New> <juju-gui:New> <https://launchpad.net/bugs/1470220>
<fwereade> waigani, yeah, I saw it, thanks for the quick response
<waigani> fwereade: ah phew. np.
<natefinch> ericsnow: you mentioned I should also add the code for registering this in component/all/process.go ... but I'm not really sure what that code should look like.
<ericsnow> natefinch: take a look at what's there already; it should be similar
<katco> natefinch: http://pastebin.ubuntu.com/11801171/
<ericsnow> natefinch: basically a call to RegisterStandardFacade (or whatever) in registerHookContext
<natefinch> katco, ericsnow: thanks :)
<ericsnow> natefinch: could you take another look at http://reviews.vapour.ws/r/1996/?
<ericsnow> natefinch: I'd really like to get that landed
<ericsnow> natefinch: looks like your conversion helpers (API2Proc, etc.) did not make it into your latest patch
<natefinch> ericsnow: doh, yeah, new file. Stupid git
<ericsnow> natefinch: I figured :)
<natefinch> ericsnow: http://reviews.vapour.ws/r/2061/diff/2-3/
<ericsnow> natefinch: doc comments on API helpers...
<ericsnow> natefinch: otherwise looks good :)
<natefinch> ericsnow: ahh yeah, had to export them so now have to comment them, damn
<ericsnow> natefinch: yeah, sorry
<sinzui> thumper: this is the only issue unique to wily and vivid. fixing https://bugs.launchpad.net/juju-core/+bug/1468349 will grealy increase chances of a pass
<mup> Bug #1468349: discoverySuite.TestDiscoverServiceLocalHost: invalid series for wily and vivid <test-failure> <unit-tests> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1468349>
<thumper> sinzui: cheers
<thumper> sinzui: I can replicate the singular intermittent failure locally
 * thumper is on it
<thumper> sinzui: I have a fix for the singular worker
<sinzui> \o/
<thumper> thanks to davecheney's stress script
<thumper> weird time.Timer behaviour, but fix works
<thumper> waigani_, cherylj: http://reviews.vapour.ws/r/2066/diff/#
<thumper> as on call reviewers :)
<thumper> note: the interval := PingInterval call is probably not strictly necessary, but I did it initially when the calls were separated, and I wanted to make sure the value wasn't changing outside that go routine
<thumper> so it only used the local value
<thumper> it wasn't changing, but the isolation is still there
 * thumper thinks
 * thumper removes it
<thumper> menn0: http://reviews.vapour.ws/r/2066/diff/#
<menn0> thumper: looking
<thumper> cheers
 * menn0 is glad to have something to distract him from the woeful situation he is looking at
<waigani_> thumper: I'm assuming you manually tested the fix and the intermittent failures are gone?
<thumper> waigani_: sure as eggs
<waigani_> thumper: lgtm
<mwhudson> davecheney: hey, have you tried to build/run juju with the go arm64 port yet?
#juju-dev 2015-07-01
<davecheney> mwhudson: nope
<davecheney> well i tried to run the tests a while back
<davecheney> but a cavelcade of blocking issues have meant I haven't looked at arm64 for going on 6 weeks
<mwhudson> fair enough
<davecheney> thumper: sorry i missed the standup
<davecheney> there are two main races remaining
<davecheney> one the cert update worker, which I don't think I can fix
<davecheney> and a race counting outstanding connections in the api server
<davecheney> which I think I can fix
<davecheney> as I'm going to be travelling for the next three weeks, i'd like to talk to you about how to fix the cert update worker
<davecheney> it's a big job
<davecheney> when I say fix, it needs to be rewritten
<mup> Bug #1470297 opened: worker/uniter/storage: data race in test <juju-core:New> <https://launchpad.net/bugs/1470297>
<menn0> thumper: ok I have managed to eventually reproduce 1469199 by doing some very nasty things to mongodb
<thumper> oh?
<menn0> hang on
<menn0> thumper: http://paste.ubuntu.com/11802709/
<menn0> that's the script that does it
<menn0> the env that triggered the bug report only has one state server
<menn0> but mongodb briefly went from PRIMARY to SECONDARY and back again in 1 sec
<menn0> after a little playing around I found that any change to the replicaset config causes the primary to drop to secondary for a bit
<menn0> that script keeps causing that to happen
<menn0> most of the time Juju handles the mongodb disconnect as it should
<menn0> until it doesn't
<menn0> I now have an env which is in the same state as described in the bug
<menn0> no API server running
<menn0> the api worker is continually trying to get a connection but failing
<menn0> I actually think it's the state worker which is stuck/brokeen
<menn0> possibly related:
<menn0> 2015-07-01 03:20:57 DEBUG juju.mongo open.go:122 TLS handshake failed: tls: first record does not look like a TLS handshake
<menn0> 2015-07-01 03:20:57 DEBUG juju.mongo open.go:122 TLS handshake failed: local error: unexpected message
<menn0> that happened shortly before things went bad
<menn0> might be a red herring though
 * menn0 goes to instrument the state and apiserver workers
<thumper> could be...
<thumper> but then again...
<thumper> menn0: have you dropped the idea of internally catching and retrying the 'bad record MAC'?
<menn0> thumper: I'm not sure if that's the root cause here so I'm not focussing on that at the moment
<thumper> ok
<davecheney> thumper: http://paste.ubuntu.com/11802397/
<davecheney> current status
<davecheney> some failures when run under -race
<thumper> davecheney: did you want to have a chat?
<davecheney> nah
<davecheney> i'm working on the apirserver race
<davecheney> we'll talk tomorrow about the cert updater issue
<thumper> ok
<thumper> davecheney: I noticed a few other failures in that listing that don't look racy
<thumper> davecheney: like the runner_test.go:134: runnerSuite.TestOneWorkerStartWhenStopping one
<thumper> I might poke that with a stick
<davecheney> yes, that is what I mean by some failures
<thumper> and this one: FAIL: ssh_gocrypto_test.go:137: SSHGoCryptoCommandSuite.TestCommand
<davecheney> i shold have said "-race triggers some other unrelated filaures"
<davecheney> SHUT
<davecheney> SHIT
<davecheney> that is supposed to be fixed
<thumper> which?
<davecheney> oh, ignore
<thumper> and is it just with -race?
<davecheney> i fixed a differernt issue with that package
<davecheney> that is a straight up failure
<thumper> kk
 * thumper fetches his pointy stick
<thumper> :-(
<thumper> davecheney: when I run utils/ssh with -race I get a race
<davecheney> pasetbin ?
<davecheney> there was one race that needed the update to gocheck
<davecheney> is there another one ?
<thumper> ah... I may not have the latest
<thumper> I'm in the 1.24 branch
<davecheney> should I backport the gocheck dep fix ?
<davecheney> can't hurt
<davecheney> we'll be stick with 1.24 for a while
<thumper> davecheney: http://paste.ubuntu.com/11802877/
<thumper> davecheney: that is with the gocheck fix as far as I can tell
<davecheney> ok
<davecheney> i've seen that one before
<davecheney> it doesn't happened every time
<thumper> davecheney: I went into the gopkg.in/check.v1 dir, and did git pull origin v1
<davecheney> i'll put it on the list
<thumper> davecheney: I'm using go 1.4.2
<menn0> thumper: this is a proper heisenbug... I can't trigger it when I add extra logging
<thumper> yay... NOT
<davecheney> thumper: https://github.com/juju/juju/pull/2694
<davecheney> i wont submit this one til roger signs off on it
 * thumper looks
<davecheney> tbh, i'm not 100% on the description of the fix
<davecheney> but the race was 100% reproducible before
<davecheney> and now it is not
<thumper> davecheney: how does this change anything?
<thumper> I don't get it
<davecheney> so, there is a difference between waiting on Dying
<davecheney> and waiting on Dead
<davecheney> Dying happens when you use tomb.Kill
<davecheney> Dead happens when someone calles tomb.Done
<davecheney> so there is a window where some waiting on the tomb, on tomb.Done are still running
<davecheney> also
<davecheney> tbh, I cannot explain it fully
<davecheney> but the logic now is straight forward
<davecheney> we only start the defer chain when the listener is shutdown
<thumper> I would have thought that the wait group will be executed first (LIFO)
<davecheney> ???
<thumper> defer srv.wg.Wait() // wait for any outstanding requests to complete.
<davecheney> it will be, then tomb.done
<thumper> right
<davecheney> but somehow the http server is accepting a final request
<davecheney> i cannot explain how
<davecheney> but in this new form, the listener is 100% closed before calling wg.Wait()
<thumper> seems weird, but ok
<davecheney> anyway, i want roger to have a look at it
<thumper> agreed
<davecheney> thumper: https://canonical.leankit.com/Boards/View/115065967/115808142
<davecheney> what do you want to do with this card ?
 * thumper looks
<thumper> I think we can remove it
<thumper> having found a different way to deal with it
<davecheney> how do we record time for a card that was not landed
<davecheney> how do we record time for a card that was not landed ?
<davecheney> also, what's going on with the in review column
<davecheney> there is more work there than in progress
<thumper> davecheney: we don't care about recording time for a card not landed
<davecheney> fairy'nuff
 * thumper found a real race in the runner code
<thumper> which only raised it's ugly head in the -race test runs
 * thumper is submitting
<thumper> this *may* be the cause of the timeout we were seeing on ppc
<thumper> no... don't thinkso
<davecheney> runner code ?
<davecheney> a data race
<davecheney> or a change in timing ?
<thumper> http://reviews.vapour.ws/r/2073/diff/#
<thumper> timing change
<thumper> but not when dying
<thumper> calling start worker, then stop worker real quick
<thumper> will not stop the worker
<thumper> because the worker hasn't told the runner it has started
<davecheney> right
<davecheney> that is because there is a nil info.Worker field
<davecheney> ship that shit
<davecheney> that code needs a shotgun rennovation
<mup> Bug #1470345 opened: provider/local: test failure <juju-core:New> <https://launchpad.net/bugs/1470345>
<mup> Bug #1470345 changed: provider/local: test failure <juju-core:New> <https://launchpad.net/bugs/1470345>
<mup> Bug #1470345 opened: provider/local: test failure <juju-core:New> <https://launchpad.net/bugs/1470345>
 * dimitern TIL: given func f1(strings ...string); f1([]string(nil)...) works just as well as f1([]string{}...)
<mattyw> gsamfira, ping?
<gsamfira> mattyw: pong
<voidspace> dimitern: ping
<fwereade> jam, standup?
<mattyw> gsamfira, hey there, I'm just doing a code review (not yours) but there's a suggestion of something that might break windows, so I wanted your thoughts: http://reviews.vapour.ws/r/2030/diff/#
<gsamfira> mattyw: looking
<gsamfira> mattyw: Should be fine as far as I can tell.
<gsamfira> mattyw: should be easy to test if there are any doubts. GOOS=windows go install github.com/juju/juju/...
<mattyw> gsamfira, does it look like a reasonable thing to do in windows?
<gsamfira> mattyw: I can not promise that errors will be the same in this scenario on both windows and Linux. So while it will probably not error out, you might not catch the error you are expecting.
<gsamfira> mattyw: also, debuglog is not yet supported on windows.
<mattyw> gsamfira, ah ok
<gsamfira> mattyw: it relies on tmux and ssh, both of which are missing from windows :)
<mattyw> gsamfira, good point, tmux is the thing I miss most
<mattyw> gsamfira, thanks for your help
<gsamfira> mattyw: my pleasure :)
<dimitern> TheMue, hey
<TheMue> dimitern: yup
<dimitern> TheMue, here's a sketch of what I think is needed - http://paste.ubuntu.com/11803914/
<dimitern> TheMue, feel free to modify/simplify it, but it should include all the relevant pieces
<dimitern> fwereade, have a look if you can whether I missed something? ^^
<fwereade> dimitern, sure
<TheMue> dimitern: looks indeed similar to my IPAddressWatcher
<TheMue> dimitern: only missing the generic part and having a concrete one instead
<TheMue> dimitern: nice
<dimitern> TheMue, cool
<fwereade> dimitern, strong +1 to :190
<dimitern> fwereade, cheers
<fwereade> dimitern, TheMue: otherwise looks sane to me
<dimitern> TheMue, fwereade, in that case the api client-side will treat both EntityWatcher and StringsWatcher apiserver facades the same
<dimitern> (save for the used facade name)
<fwereade> dimitern, I think they *are* pretty much the same though -- it's just that an EntityWatcher makes more generally helpful guarantees about the semantic content of its values
<fwereade> dimitern, the one quibble is whether the client-side one should be returning actual parsed tags
<TheMue> yep, more than just *any* string
<TheMue> fwereade: would expect it (parsed tags)
<fwereade> TheMue, dimitern: yeah
<fwereade> TheMue, dimitern: it would be a shame to copy-paste the client-side strings watcher just for that though -- please avoid duplication where you can
<dimitern> fwereade, agreed
<TheMue> fwereade: hey, that's HA by redundancy
<fwereade> LOL
<dimitern> fwereade, that's a fair point, but if we return []names.Tag we can't reuse the client-side strings watcher proxy
<fwereade> dimitern, TheMue: yeah -- and it may be that golang effectively just forces us to copy-paste anyway
<dimitern> TheMue, tags are serialized as []string in params, that's intentional as in other cases, but the client-side could very well convert them to []names.Tag
<fwereade> dimitern, TheMue: but please see what you can do :)
<dimitern> fwereade, sure
<TheMue> dimitern: yes, paring on client side would have been my approach. I like to keep the wire protocol as simple as possible
<TheMue> s/paring/parsing/
<dimitern> TheMue, +1
<fwereade> does anyone know if there's a time when we'd call state.Open *without* knowing the environment and state server uuids?
<fwereade> because there's this really bloody inconvenient bit where we call .StateServingInfo somewhere inside Open, and use it to fill in missing fields
 * TheMue is afk, lunchtime
<fwereade> and I'd like to pass it in from outside, but this branch is a monster already, so if anyone knows why it's a bad idea before I start, please tell me :-/
<fwereade> but, for now, lunch sounds good :)
<dimitern> fwereade, AFAIK for backwards compatibility with older versions
<dimitern> fwereade, but that shouldn't make the interface awkward to use and test IMO
<mattyw> fwereade, 2 minutes?
<mattyw> bogdanteleaga, is this still needed? https://github.com/juju/charm/pull/47
<bogdanteleaga> mattyw: nope, they seem to be already updated
<bogdanteleaga> mattyw: somehow :)
<mattyw> bogdanteleaga, magic :)
<voidspace> dimitern: generating devices from a template isn't too hard
<voidspace> dimitern: https://code.launchpad.net/~mfoord/gomaasapi/devices/+merge/263370
<voidspace> dimitern: see newDeviceHandler
<voidspace> dimitern: little bit of work needed on that (generating a proper system id), but should be plain sailing from here
<dimitern> voidspace, awesome!
<mattyw> fwereade, sorry do you have 2 minutes?
<tasdomas> fwereade, ping?
<dimitern> voidspace, ping
<voidspace> dimitern: pong
<mup> Bug #1455623 changed: TestPingCalledOnceOnlyForSeveralWorkers fails <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released by thumper> <juju-core 1.23:Won't Fix> <juju-core 1.24:Fix Released by thumper> <https://launchpad.net/bugs/1455623>
<dimitern> voidspace, did you manage to sort out your issue with maas 1.9 ?
<voidspace> dimitern: no, still talking to Raphael about it
<voidspace> dimitern: a migration got changed in the daily builds
<voidspace> dimitern: which screwed things up
<voidspace> dimitern: we're on step 5 of trying to sort it out
<dimitern> voidspace, I see
<dimitern> voidspace, I hope it works then :)
<voidspace> me too :-/
<mup> Bug #1463910 changed: Upgrade tests timeout on ppc64 <ci> <gccgo> <intermittent-failure> <regression> <juju-core:Fix Released by thumper> <juju-core 1.24:Fix Released by thumper> <https://launchpad.net/bugs/1463910>
<mup> Bug #1470526 opened: Juju bootstrap with local provider fails on precise <juju-core:New> <https://launchpad.net/bugs/1470526>
<katco> ericsnow: meeting
<ericsnow> katco: just when I thought it was safe to go back in the water :)
<katco> ericsnow: haha sorry =/
<katco> ericsnow: you have 2 ship its
<ericsnow> katco: thanks!
<katco> ericsnow: i'm going to place a card on our kanban to ensure we revisit the state stuff
<katco> ericsnow: we don't want that to fall off our radar
<ericsnow> katco: good idea
<katco> ericsnow: also: http://reviews.vapour.ws/r/2075/
<ericsnow> katco: I'll take a look
<mup> Bug #1470601 opened:  UniterSuite.TestLeadership fails on windows <blocker> <ci> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1470601>
<natefinch> ericsnow: you around?
<ericsnow> natefinch: yep
<natefinch> ericsnow: I noticed that the ListProcesses state method (as I last saw it) is effectively a bulk call into state... but it doesn't seem to have a way to return multiple errors.  How will it handle getting called with a mix of valid and invalid IDs, for instance?
<ericsnow> natefinch: it just returns the ones it found
<ericsnow> natefinch: it's up to the caller to sort that out
<ericsnow> natefinch: FYI, I've already fixed that up in my "adjustments" patch
<wwitzel3> ericsnow: so if i propose my branch again the feature branch, will the RB review be made for me?
<wwitzel3> s/again/against
<ericsnow> wwitzel3: yep
<wwitzel3> ericsnow: I need to add a few more, but no reason it can't be up for review while I take care of that.
<ericsnow> wwitzel3: k
<wwitzel3> tests that is
<wwitzel3> well maybe I do, I don't know
<wwitzel3> I think I'm actually exercising all of the client paths .. oh error paths, I need to do those
<wwitzel3> ok, yeah
<wwitzel3> good talk
<ericsnow> wwitzel3: :)
<mup> Bug #1470220 changed: Juju-deployer incorrectly reporting errors in juju 1.24.0 environment <juju-core:New> <juju-deployer:New> <juju-gui:New> <https://launchpad.net/bugs/1470220>
<wwitzel3> natefinch: ping
<wwitzel3> natefinch: the card I was doing, the API client abstractions, is the card you are doing :)
<wwitzel3> natefinch: I think we just copied too many of the server cards
<natefinch> wwitzel3: oops!
<wwitzel3> natefinch: my branch is up, I just have to add one more method and a couple tests, but the PR is up
<natefinch> wwitzel3: I'll take a look and see if I have anything to add
<natefinch> wwitzel3: that looks great, and pretty much just what I was doing.
<wwitzel3> natefinch: actually I can ask you, I didn't see a stand alone Status on the API server side?
<wwitzel3> natefinch: I am assuming ListProcess is filling that role?
<natefinch> wwitzel3: I was just exposing what ericsnow had in state... I think list process is the thing, though maybe we want a shortcut for a brief status message
<ericsnow> natefinch, wwitzel3: yeah, we might want that
<ericsnow> natefinch, wwitzel3: we can tackle that when we add support to juju status
<natefinch> ericsnow: is your state work merged into the feature branch?
<ericsnow> natefinch: not yet
<ericsnow> natefinch: multi-environment stuff is killing me
<natefinch> ericsnow: is there anything I can do to help?
<ericsnow> natefinch: I don't think so
<ericsnow> natefinch: I've almost got it
<natefinch> ericsnow: awesome
<thumper> bogdanteleaga: ping
<bogdanteleaga> thumper: pong
<thumper> bogdanteleaga: hey there
<thumper> "2015-07-01 17:27:20 WARNING utils.featureflag flags_windows.go:34 Failed to open juju registry key HKLM:\\SOFTWARE\\juju-core; feature flags not enabled\n"
<thumper> I don't think we should emit warnings if the registry key isn't there
<thumper> is there a difference  between non existent and can't open?
<bogdanteleaga> yes
<thumper> bogdanteleaga: this made master fail CI BTW
<bogdanteleaga> I got a fix for it though
<thumper> awesome
<bogdanteleaga> here you go https://github.com/juju/juju/pull/2699
<bogdanteleaga> thumper: since you're here a fast review wouldn't hurt :p
<thumper> bogdanteleaga: looking now
<thumper> bogdanteleaga: shipit
<bogdanteleaga> thumper: cool, thanks
<thumper> bogdanteleaga: np
<thumper> sinzui: I'm assuming the upgrade testing for 1.24.2 all went well?
<sinzui> thumper: sorry? I donât know which testing that is
<thumper> sinzui: didn't you say that you were going to make sure that the proposed release goes through additional CI testing around upgrades?
<sinzui> thumper: yes, I did the 1.22.6 -> 1.24.2
<thumper> cool
<thumper> I was so happy to finally see that bless come through yesterday evening
<bogdanteleaga> sinzui: I tried doing an upgrade from 1.25 to 1.26 using zip for 1.26 and metadata taken from simplestreams on a webserver set up by me; can you think of anything else I should test?
<sinzui> bogdanteleaga: 1.24.x -> .1.26.x. I expect a message that there are no candidates (no crash) also, we need to bootstrap juju 1.18.1 and 1.20.11 and confirm they do not choke on streams with zips
<natefinch> wwitzel3: got you a review on the client stuff. There's a couple pretty important changes that need to be made.
<wwitzel3> natefinch: thanks, the second comment, not sure what you mean? Isn't it up to the caller to inspect the results for errors?
<wwitzel3> natefinch: oh, I see what i did, heh
<wwitzel3> I stipped them out beofre the caller gets a chance to act on them
<natefinch> yeah, I think we can just return the API objects that the API calls return.. maybe stripped of an extraneous containing struct (like if the struct is just holding a slice of something)
<natefinch> ahh hmm.... error in the code   ProcessResults  should not have an Error value itself
<natefinch> or maybe ericsnow added that on purpose
<natefinch> though I kind of thought that was what the error return from the API call was for
<ericsnow> natefinch: yeah, I added that on purpose
<wwitzel3> natefinch: ProcessResult or ProcessResults?
<ericsnow> my understanding is that the error return is more for errors in the machinery, not in the handling logic of the request
<natefinch> ericsnow: other bulk calls don't seem to have an Error on the top level result
<ericsnow> natefinch: k
<natefinch> I have to go make dinner, but I'll be on later.
<fwereade> thumper, I'm here if you're free
<thumper> fwereade: otp now, release call
<fwereade> thumper, np, ping me when you're free, I may or may not be around :)
<davechen1y> thumper: there at lots of calls to os.Exit(2) inside cmd/go
<davechen1y> the error could be coming from there
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1470601
<mup> Bug #1470601:  UniterSuite.TestLeadership fails on windows <blocker> <ci> <regression> <unit-tests> <juju-core:Fix Committed by bteleaga> <https://launchpad.net/bugs/1470601>
<davechen1y> how long until the build is unblocked ?
<katco> wwitzel3: meeting
<perrito666> anastasiamac:  axw I am going to bail today the context switch would be really expensive today
<anastasiamac> perrito666: nps :D could u send a briefing email? tyvm :D
<perrito666> anastasiamac: I will
<anastasiamac> perrito666: \o/ have fun!
<perrito666> anastasiamac: I actually am having fun :) txx
 * perrito666 is having the fun of finally cracking a problem
<perrito666> completely unrelated question, is anyone using vim and a decent buffer switcher
<wwitzel3> katco: shoot, sorry
<wwitzel3> katco: still going?
<wwitzel3> katco: sorry, I'm sure the plan was "Wayne will do everything" since I wasn't there .. I deserve that
<ericsnow> wwitzel3: FYI, I'm merging the state patch right now
<wwitzel3> ericsnow: good deal
<axw> wwitzel3: you'll be manning the booth by yourself wed-fri, we'll do the rest
<axw> ;)
<wwitzel3> axw: haha
<wwitzel3> axw: yeah, I finished a meeting for the dockercon wrapup doc, and in my brain, that was my late meeting, so I ran to the store
<wwitzel3> just completely spaced
<axw> wwitzel3: nps, otp, will fill you in later
<wwitzel3> axw: thanks
<thumper> sinzui: we have a problem: http://data.vapour.ws/juju-ci/products/version-2844/kvm-deploy-trusty-amd64/build-1206/consoleText
<thumper> sinzui: there are conflict markers in the main CI branch code
<sinzui> thumper: we have just fixed it and and queued the retest
<thumper> sinzui: cool
<sinzui> thumper: and it is just on the kvm-slave
<thumper> sinzui: I was trying to get a jump on looking at master CI :)
<mgz> thumper: yeah, my bad, I forgot I needed to revert a hack before doing the real landing
<thumper> ha
<thumper> np
<cherylj> wwitzel3: we are putting the hardware requirements for the demo on you, though.  So if we need any systems, monitors, etc, get that info to alexisb by tomorrow.
<alexisb> heh thumper you really want to see that bless :)
<thumper> oh ye
<thumper> s
#juju-dev 2015-07-02
<wwitzel3> cherylj: thanks
<wwitzel3> alexisb: a large monitor would make it easier to show people, but that isn't even a must have
<wwitzel3> I'll be spinning up everything on EC2 a day ahead of time as a backup, like on a cooking show :)
 * perrito666 imagines a souschef removing the running command from wwitzel3 and bringing a fully deployed stack while putting the other on the fridge
<anastasiamac> perrito666: :D making a meal out of juju :))
<natefinch> evening all
<natefinch> ericsnow, wwitzel3: either of you around?
<wwitzel3> natefinch: omw
<mup> Bug #1470601 changed:  UniterSuite.TestLeadership fails on windows <blocker> <ci> <regression> <unit-tests> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1470601>
<mgz> master is blessed.
<menn0> mgz, thumper, davechen1y : \o/
<menn0> thumper: i'm pretty sure I've found out the reason for the stuck state servers
<menn0> thumper: when do mgo.DialWithInfo and don't specify a timeout, and mongodb isn't there, it hangs forever
<menn0> thumper: there's 2 places in juju where we don't specify a timeout
<menn0> thumper: state.ForEnviron() is one :)
<mup> Bug #1470714 opened: Ubuntu downloads are non-obvious <juju-core:New> <https://launchpad.net/bugs/1470714>
<tasdomas> hi
<tasdomas> menn0, ping?
<tasdomas> davechen1y, ping?
<davechen1y> tasdomas: ack
<tasdomas> davechen1y, sorry to be bothering you past your EOD
<tasdomas> davechen1y, as I understand it, service-related commands in cmd/juju have been moved to cmd/juju/service, but in master, cmd/juju/get.go still exists - is there a reason for that?
<davechen1y> tasdomas: sorry, i don't thin ki can help
<davechen1y> i've no idea what happened there
<tasdomas> davechen1y, thanks anyway - I emailed Cheryl with my question
<davechen1y> ok
<fwereade> TheMue, what was the thinking behind putting that panic in multiEnvRunner.updateOps?
<TheMue> fwereade: eh, need the context, could you point me to file and line?
<fwereade> TheMue, txns.go, not sure line because I'm looking at a merge conflict
<fwereade> TheMue, but it looks like it's a problem with updateStruct that's being addressed one level up and dirtying up the updateOps logic
<TheMue> fwereade: aha
<TheMue> fwereade: I first time got aware of this multiEnvRunner with the info of automatic setting of env-uuid and prefixing of _id
<fwereade> TheMue, I'm well aware of the problem and the context, I'm just asking why you changed updateOps and not updateStruct
<TheMue> fwereade: did I?
<fwereade> TheMue, because it *seems* wrong -- all the other panics are generated in the updateSpecificThing methods, and the updateOps method has a couple of its own responsibilities
<fwereade> TheMue, heh, maybe you didn't even -- I just knew you'd been bumping up against this problem and assumed it was you
<TheMue> fwereade: when I found it regarding the IPAddress unique field and we discussed about it I afterwards dropped it and set both explicit in addIPAddress
<TheMue> fwereade: hehe, yes, because we found it "interesting" how the txn modifies the passed doc w/o returning it
<voidspace> dimitern: https://code.launchpad.net/~mfoord/gomaasapi/devices/+merge/263370
<dimitern> voidspace, how about op=claim_sticky_ip ?
<voidspace> dimitern: oh yes, need to implement that
<voidspace> dimitern: ten minutes work
<voidspace> dimitern: :-)
<voidspace> dimitern: thanks
<dimitern> voidspace, np :)
<voidspace> dimitern: (I'll do no error checking, just add it to the device object)
<voidspace> dimitern: I burned an hour yesterday on an obscure bug
<dimitern> voidspace, that sounds good - you've got a review
<voidspace> dimitern: I was writing a byte array (the json result) to the response
<voidspace> dimitern: and that works without error and the gomaasapi Parse function will consume it
<voidspace> dimitern: I was just getting a null object in Parse
<voidspace> dimitern: took me ages to work out why...
<dimitern> voidspace, hmm really?
<dimitern> voidspace, what was it?
<voidspace> dimitern: you need to pass a string to response.Write
<voidspace> dimitern: a byte array "works" but does the wrong thing
<voidspace> dimitern: it sends a literal "[1 33 42...]" as the response
<voidspace> dimitern: which of course is invalid json
<voidspace> dimitern: and Parse consumes it happily and swallows the json syntax error
<dimitern> voidspace, ah! good catch
<voidspace> well, I had failing tests thankfully
<dimitern> voidspace, strictly speaking I think response.Write takes an io.Writer
<voidspace> dimitern: yeah, logging would be good
<voidspace> dimitern: ah, it's fmt.Fprint(w, something)
<voidspace> dimitern: and something can be a []byte or string
<voidspace> dimitern: and []byte does the wrong thing altogether...
<voidspace> dimitern: can't see an inline comment
<dimitern> voidspace, right, yeah []byte(..).String() is not what you might expect
<voidspace> whereas string([]byte) does the right thing
<dimitern> voidspace, it's on line 157 about the deviceTemplate
<voidspace> dimitern: I can't see it
<voidspace> is it draft?
<voidspace> dimitern: ah, I see it
<voidspace> dimitern: a text/template would be more code, right?
<voidspace> I could switch to that
<dimitern> voidspace, yeah - I think it will be nicer
<voidspace> dimitern: ok
<voidspace> dimitern: I'll add DELETE and claim_sticky_ip first and then do that
<voidspace> there maybe other review comments by then
<dimitern> voidspace, cheers
<voidspace> dimitern: gomaasapi doesn't have logging
<dimitern> voidspace, too bad - then ignore my comment about it -  I don't insist on it
<tasdomas> fwereade, ping?
<voidspace> wwitzel3: ping for when you're around
<voidspace> dimitern: so I need to modify the JSONObject in place
<voidspace> dimitern: currently JSONObject is effectively read only
<voidspace> dimitern: I only need to modify an array, so I'll be adding SetArray to match GetArray
<voidspace> dimitern: ok?
<dimitern> voidspace, if it works, fine, but I'll like to have a final look when done
<voidspace> dimitern: it will work fine
<voidspace> dimitern: obviously ;-)
<voidspace> dimitern: just make JSONObject a bit asymmetrical
<voidspace> dimitern: read only except for arrays
<voidspace> dimitern: otherwise I can serialise, do text manipulation and deserialize again
<voidspace> dimitern: which seems worse...
<voidspace> dimitern: or I can make a private function for use by the test server only as JSONObject is publiic
<voidspace> that's maybe better
<voidspace> so as not to change the public api
<dimitern> voidspace, that sounds better I think
<voidspace> dimitern: cool
<voidspace> dimitern: although extending JSONObject to make it fully bi-directional and breaking it out into it's own library would be cool
<mup> Bug #1470820 opened: Remove github.com/gabriel-samfira/sys/windows once go 1.4 lands <juju-core:New> <https://launchpad.net/bugs/1470820>
<dimitern> voidspace, TheMue, please take a look - http://reviews.vapour.ws/r/2088/ - AddSubnets apiserver method
<TheMue> dimitern: yup
<dimitern> TheMue, ta
<TheMue> dimitern: quick wish outside the review, I prefer identifier abbreviated as ID, not Id
<TheMue> dimitern: so it would be SebnetProviderID
<dimitern> TheMue, I know, but Id seems to be more common in our code; we should change all of them separately though
<TheMue> dimitern: we already have a mix, eg katco also uses ID
<dimitern> TheMue, I'm not saying we only use Id, just that it's more common
<TheMue> dimitern: time to change it :D viva le upper-case
<dimitern> TheMue, :) let's not do it now please
<TheMue> dimitern: hehe, ok, Ok, OK, oK *rofl*
 * TheMue seems to have a melted brain *lol*
<dimitern> TheMue, :)
<TheMue> dimitern: why all those implementations of GoStringer? we haven'd used it so much in the passed.
<dimitern> TheMue, because I found it easier while writing tests and debugging to see that instead of (0xdeadbeef, ..)
<TheMue> dimitern: oh, come on, 0xdeadbeef is so good read- and understandable
<dimitern> :D
<TheMue> dimitern: but yeah, good argument
<TheMue> dimitern: phew, you cache is a number. but almost through
<voidspace> TheMue: dimitern: I prefer Id :-p
<voidspace> TheMue: dimitern: ID is not an acronym it's an abbreviation
<voidspace> so only the first letter should be capitalised
<voidspace> if we do reach a consensus I'll stick to it
<voidspace> but I think it should be Id
<TheMue> voidspace: AllocatableIpLow? info.Cidr?
<voidspace> TheMue: IP is an acronym, so is CIDR
<voidspace> TheMue: hence the distinction
<voidspace> so those should be uppercase if they aren't
<dimitern> I couldn't give so much importance to the case of a single letter :P
<voidspace> dimitern: probably the best attitude, I only have a slight preference for correctness
<TheMue> dimitern: it's not the case, it's consistency
<voidspace> so let's settle on correctness then
<TheMue> dimitern: unlike in python where I often found MyWildType.do_this.strconv()
<voidspace> that looks right for Python
<voidspace> consistent with pep8
<voidspace> ah, except for the debate about when to use underscores and when to concatenate
<voidspace> fair enough
<voidspace> although I still think that looks fine :-)
<TheMue> to me it simply looks ugly and inconsistent (which says nothing about the language itself). but I simply like it more consistent, it's better readable, eye/brain don't have to do many context switches
 * TheMue still dreams of the wonderful consistent smalltalk sources, sadly this lang is so bad in concurrency *sigh*
<TheMue> dimitern: you've got a review
<wwitzel3> ericsnow: ping
<dimitern> TheMue, thanks!
<TheMue> dimitern: np
<katco`> natefinch: standup
<rogpeppe1> looks like there's no OCR in this hemisphere today. would anyone be able to take a look at this, please? http://reviews.vapour.ws/r/2089/
<perrito666> rogpeppe1: ah beautiful change, ill take a look although I am not sure I am able to +2 it
<rogpeppe1> perrito666: thanks. more eyes the better :)
<mup> Bug #1470876 opened: Deploy --to zone=<name> <landscape> <juju-core:New> <https://launchpad.net/bugs/1470876>
<voidspace> wwitzel3: ping
<dimitern> voidspace, TheMue, PTAL -  http://reviews.vapour.ws/r/2090/ - another, much smaller review, this time fixing the subnet add CLI command
<TheMue> dimitern: ok
<dimitern> TheMue, thanks
<katco> ericsnow: can you help me understand why the hook context facade might want to know about the unit{ tag}?
<ericsnow> katco: the unit is intrinsic to hook contexts
<katco> ericsnow: so the wpm facade is an exception?
<ericsnow> katco: not at all
<katco> ericsnow: where is the wpm facade using the unit tag?
<ericsnow> katco: rather we can provide the unit at the facade level rather than requiring each API method to require passing the unit tag
<katco> ericsnow: ah ok. we have the cardinality wrong atm?
<ericsnow> katco: I think so
<katco> ericsnow: k, ty for the tutelage. making the change
<perrito666> rogpeppe1: got my review
<ericsnow> katco: thanks!
<rogpeppe1> perrito666: ta!
<katco> ericsnow: i'm going to propose we use the id. it will be a looser coupling if we're just dealing with strings. agree?
<ericsnow> katco: keeping the tag would probably be better
<katco> ericsnow: so importing juju/names in components is ok?
<ericsnow> katco: if we pass the unit itself it may save us a bit of work too
<ericsnow> katco: I think so
<ericsnow> katco: it's info rather than machinery
<katco> ericsnow: i would really prefer we not do state.Unit as that will couple all components to state
<katco> ericsnow: or rather, encourage it. i suppose they should be using interfaces
<ericsnow> katco: oh, right; we'd have to make that work via interfaces
<rogpeppe1> perrito666: i find myself unable to reply to your comments - the text box for the reply isn't showing (might be a Chrome issue)
<katco> ericsnow: actually, reversal. we're already passing in *state.State, this is the same.
<katco> ericsnow: i'll pass in the unit
<perrito666> rogpeppe1: ah that happens sometimes it is exxtremely annoying
<rogpeppe1> perrito666: know of a workaround?
<perrito666> rogpeppe1: I just hard refrehs a couple of times
<perrito666> refresh*
<rogpeppe1> perrito666: tried that
<perrito666> tried yelling at the screen?
<perrito666> works sometimes
<ericsnow> katco: yeah, at that level it would make sense to just go with *state.Unit
<ericsnow> katco: then we adapt it in component/all
<perrito666> rogpeppe1: I think perhaps some js library is failing to load
<perrito666> but I keep forgetting to check
<rogpeppe1> perrito666: it seems that i can do it if i reply inline in the full diff
<katco> ericsnow: yeah exactly. we'll just have to encourage people to decouple at that point. this shouldn't be hard since that's the entire point of that package
<perrito666> rogpeppe1: ah, good tip
<ericsnow> katco: again, directory structure FTW :)
<perrito666> rogpeppe1: and you are going to do another PR for the ProxySSHKey? :p
<rogpeppe1> perrito666: i think it should probably be all the config attributes
<rogpeppe1> perrito666: and i'm not entirely convinced it's my responsibility to pay of that tech debt :)
<rogpeppe1> s/of that/off that/
<perrito666> I have never been able to pull that argument succesfuly :p
<wwitzel3> voidspace: pong
<katco> ericsnow: changes pushed. review if you please, sir.
<ericsnow> katco: will do
<katco> ericsnow: looks like process.go had an issue. not sure
<ericsnow> katco: you may need to merge/rebase onto the feature branch
<katco> ericsnow: ah k lemme do that rq
<rogpeppe1> cherylj: thanks v much for doing some QA on my branch
<cherylj> rogpeppe1: np :)  I've been in the multi environment stuff recently, so I thought I should take a look
<rogpeppe1> cherylj: do you know any way of listing all the multi environments so that i can destroy them prior to destroying the local env?
<cherylj> rogpeppe1: they will show up in juju switch -l.  There's a command coming in a feature branch that will show you the environments for a particular system (aka bootstrap env)
<rogpeppe1> cherylj: that would be useful. juju switch -l shows me all the dud .jenv files i have lying around too :)
<cherylj> rogpeppe1:  yeah, that is a pain.  There's a new juju supercommand called system that will let you list envs for a particular system, and do other system-y things
<rogpeppe1> cherylj: cool
<rogpeppe1> cherylj: i've replicated your issue. thanks v much again for trying it out. I should have done the same.
<cherylj> rogpeppe1: np :)
<katco> ericsnow: k sorry, had to grapple with git a bit. review updated
<ericsnow> katco: np
<ericsnow> katco: basically ship-it (one small detail to address)
<ericsnow> katco: thanks for doing that
<katco> ericsnow: ah gotcha. i think i tried passing in state before rebasing and (of course) they methods weren't there :p
<ericsnow> katco: I had meant to update that bit in my state patch, but apparently forgot
<katco> ericsnow: "State does not implement server.State (wrong type for UnitProcesses method)"
<katco> ericsnow: i'll leave that to you
<ericsnow> katco: k
<ericsnow> katco: yeah, just leave that bit the way you have it and I'll put up a patch to fix it
<katco> ericsnow: blah. i really butchered the commit history for this branch. i borked that rebase.
<ericsnow> katco: I really wish Go would be smarter about compatible types in function signatures
<katco> ericsnow: is it a {co|contra}variance problem?
<ericsnow> katco: only as it relates to strictly equivalent types (e.g. interfaces, maybe even some typedefs)
<ericsnow> katco: I'm not even talking about implicit type coercion
<katco> ericsnow: in my experience, that's one of those things that get added to statically typed languages as they mature
<ericsnow> katco: right
<katco> ericsnow: just a priorities thing
<ericsnow> katco: it's on my list of Go things that could happen some day
<katco> ericsnow: :) i still want to see that spreadsheet!
<ericsnow> katco: I'll share that with you at some point :)
<rogpeppe1> cherylj: i've pushed a fix for that issue - it seems to work ok for me now
<rogpeppe1> anyone prepared to +2 this? http://reviews.vapour.ws/r/2089/
<katco> i have no idea why the build bot thinks gofmt is sad: http://juju-ci.vapour.ws:8080/job/github-merge-juju/3877/consoleFull#-2049291403f64d1c3f-da20-4160-a70c-0ccd218b227e
<mgz> katco: looking
<katco> mgz: entirely possible i'm missing something, but gofmt -s -w ./process.go produces no changes on my machine
<mgz> katco: what go version?
<katco> mgz: 1.3.3
<mgz> bot uses 1.2.1
<mgz> so, go fmt may have changed its mind
<katco> mgz: bleh... i'll have to install v1.2.1
<katco> mgz: looks like i can only get go 1.2.2
<mgz> I may be able to just spot it, sec
<mgz> that HookContextAPI{ /* st */ } is ood
<mgz> katco: I'll fetch your branch and give you the gofmt diff
<katco> mgz: ty... working on getting 1.2.2 installed too
<mgz> katco: ah, also, `go fmt` passes
<mgz> but the line we use in verify.bash does not
<rogpeppe1> katco: i usually just install Go from source - it's dead easy and makes it straightforward to play with any go version you likre
<rogpeppe1> like
<katco> rogpeppe1: that's what i have done
<katco> rogpeppe1: â11:21> ls ~/.local/ |grep go
<katco> go
<katco> go1.2.2.linux-amd64
<katco> go1.3.3.linux-amd64
<katco> go1.4.0.linux-amd64
<katco> rogpeppe1: where go is a symlink to 1.3.3
<rogpeppe1> katco: ah, i have a slightly different approach
<mgz> katco: it's dumb, http://paste.ubuntu.com/11810901
<rogpeppe1> katco:
<rogpeppe1> % cat $h/bin/go-release
<rogpeppe1> #!/usr/bin/env rc
<rogpeppe1> GOROOT=$home/go-release
<rogpeppe1> path=($GOROOT/bin $path)
<rogpeppe1> $*
<mgz> katco: `go fmt` does not do that, but `gofmt component/all/process.go` does
<katco> mgz: lol... oy... i will have to use an editor that does not run go fmt when i save ;)
<katco> is it evil that i'm using vi in a terminal in emacs?
<mgz> `go fmt` doesn't seem to care either way
<mgz> katco: no, it's not evil, it's great that emacs gives you a usable text editor
<katco> mgz: lol! well played sir!
<katco> mgz: HA! oh god... so i can't push because MY gofmt is sad
<mgz> ehehe
<katco> mgz: oyyyy
<mgz> just remove the dumb inline comment?
<katco> mgz: good idea.
<katco> rogpeppe1: looks like same thing, just fiddling with env instead of paths?
<rogpeppe1> katco: i guess - i'm not sure what your things are actually doing
<katco> rogpeppe1: i have all my envars pointing to ~/.local/go, and that's just a symlink to the version i want to use
<katco> rogpeppe1: so to flip versions, i just point the symlink elsewhere
<katco> rogpeppe1: it looks to me like you just flip the envar
<rogpeppe1> katco: yeah
<rogpeppe1> katco: i actually like your solution
<katco> rogpeppe1: it's how os x does things as well
<rogpeppe1> katco: although it would be kinda nice if $GOPATH/pkg was specific to the version too
<katco> rogpeppe1: yes, that is an annoyance when flipping versions
<katco> rogpeppe1: i end up just deleting that
<rogpeppe1> katco: i often move it out of the way and then back again.
<katco> rogpeppe1: you could get overly complicated and i guess point $GOPATH/pkg to ~/.local/go/user-pkg
<rogpeppe1> katco: that's an interesting idea, yes
<katco> rogpeppe1: ty for your comments on gorkin btw
<rogpeppe1> katco: np - i'm sorry i didn't look at it for more than a minute or so :)
<katco> rogpeppe1: no worries at all. i'm presenting that at gophercon in a lightning talk
<rogpeppe1> katco: i do feel quite strongly about the import . thing though - it's commonly used by people trying to get the "feel" of a ruby DSL, but really doesn't feel nice in Go
<natefinch> ericsnow: I'd love to see what your workflow is like. You commit like 20x as often as I do :)  re: https://github.com/juju/juju/pull/2674
<rogpeppe1> katco: (FWIW we used to use import . for gocheck too, but changed to using gc and I think it's a definite improvement in readability)
<rogpeppe1> katco: am jealous of you going to gophercon
<rogpeppe1> katco: i couldn't quite bring myself to spend all that cash
<katco> rogpeppe1: i think we have an extra ticket
<rogpeppe1> katco: really?
<ericsnow> natefinch: I try to keep my changes small
<ericsnow> natefinch: too many times I've been bitten by getting pieces done, breaking them when working on the next piece, and not being able to get back to the point where it was working
<katco> rogpeppe1: yeah, talk to alexisb
<rogpeppe1> katco: we're sponsoring it?
<katco> rogpeppe1: yes
<rogpeppe1> katco: woah....
<katco> rogpeppe1: i'm speaking as well
<rogpeppe1> katco: great!
<rogpeppe1> katco: yeah, i saw that AFAIR
<katco> rogpeppe1: re: the import . thing, i like that when what you're trying to accomplish is supposed to feel like an extension to the language
<katco> rogpeppe1: but i know it's not idiomatic
<katco> rogpeppe1: for examples, i claim a pass, and people can do whatever they want when they use it ;)
<rogpeppe1> katco: i really think it's worth trying to make it feel idiomatic
<rogpeppe1> katco: and Go doesn't have language extensions :)
<katco> rogpeppe1: the import "." isn't requisite to utilizing the lib, people can do w/e they want
<katco> rogpeppe1: but it keeps my examples clear
<natefinch> ericsnow: yeah, totally get that
<natefinch> rogpeppe1: you should go to gophercon.  I wish I could go, but already scheduled a vacation for next week before they announced the date.  Super super jealous of those that can go, especially since I couldn't go last year either.  Hopefully next year, when we don't have any kids under 1yo
<ericsnow> natefinch: the small-commits approach also helps tell the story of how your thinking progressed over the course of the branch :)
<natefinch> ericsnow: yep
<rogpeppe1> natefinch: i'm gonna try to go
<natefinch> wwitzel3: in your api client code, is there any reason not to just return the struct, rather than an interface?
<wwitzel3> natefinch: because that struct should never be created without using the constructor
<wwitzel3> natefinch: and I've never regretted using an interface, but I have regetted using a struct for a return :)
<katco> wwitzel3: fwiw, i have not been convinced why returning a struct is better yet, but that is what idiomatic go suggests. brad fitzpatrick and andrew gerrand did some live coding and that came up as a pet peeve: i.e. "just return the struct"
<katco> wwitzel3: i think it probably has something to do with the fact that go has duck-typing, so conversions should happen in that manner, but i don't know if it takes into consideration the issues you bring up
<wwitzel3> katco: even in a case when you never want that struct instansitated without using the constructor? that seems counter to the point of public and private
<natefinch> wwitzel3: I don't know, if you see a constructor, it's usually pretty obvious that you shouldn't just create the struct yourself.  In theory you can always make it return an interface later if needed, but initially, that extra interface just complects the package API.... it also adds a red herring, making me think there might be something different returned sometimes.
<ericsnow> katco: not that long ago I heard davechen1y say "in functions take interfaces and return structs"
<katco> ericsnow: yeah, basically
<katco> wwitzel3: yeah i know. i agree. i haven't thought through that yet. i'd love to get that point clarified
<mattyw> ericsnow, are you still available for reviewboard advice?
<natefinch> Be conservative in what you [return], be liberal in what you accept from others
<ericsnow> mattyw: depends on what you need <wink>
<mattyw> ericsnow, this http://reviews.vapour.ws/r/2091/ just doesn't seem to be working in rb at all, you can see in github that it's basically moving loads of files
<mattyw> ericsnow, any advice on how I can resolve this?
<katco> wwitzel3: maybe it has something to do with: you don't know how your type will be used, and the more specific you are, the more flexible your callers can be
<ericsnow> mattyw: what isn't working in RB?
<wwitzel3> katco: isn't that what an interface is? a contract for how your type will be used?
<katco> wwitzel3: e.g. if i return interface Foo, i can only use it as a Foo. but if i return struct Bar, i can pass Bar into all the things that take interfaces that look like Bar
<mattyw> ericsnow, well loads of files it just shows me an errors (for the files that have gone) and for the new files it just display all the code, what's actually happened is those file were moved
<ericsnow> mattyw: deleted (moved) files show up with an error (and say "deleted" in the file list)
<ericsnow> mattyw: yep, that's how RB works (unfortunately)
<ericsnow> mattyw: in this case I'd just point folks to the PR
<ericsnow> mattyw: it's not like you made any semantic changes
<mattyw> ericsnow, ok will do thanks
<katco> wwitzel3: it's a valid question i think. idiomatic go says return structs. i just don't know why.
<ericsnow> mattyw: cool
<wwitzel3> katco: isn't that what a closure is for? you encapsulate things in a manner so you can easily pass them within your API without having to implement someone elses?
<mattyw> ericsnow, just thought it was worth checking, in case there was any git-foo I was missing
<mattyw> git-fu rather
<natefinch> wwitzel3: if you have to write a closure, you've already lost
<ericsnow> mattyw: no worries
<katco> wwitzel3: i'm not sure i understand the closure comment. interfaces would be dealing with methods
<katco> natefinch: that is a rather inflammatory statement :p
<ericsnow> mattyw: it would be nice if RB handles moves (and deletes) better
<natefinch> katco: in general, a closure means "someone screwed up their API and now I have to fix it with this gross hack"
<wwitzel3> katco: right, but you were saying how if you run the interface vs. a struct, the struct can be passed to anything that accepts an interface that it implements
<katco> natefinch: that is absolutely wrong
<natefinch> katco: let's discuss after the demo ;)
<ericsnow> mattyw: that patch doesn't have semantic changes, right?
<katco> wwitzel3: right, i don't think you can solve that with a closure as closures are functions, and interfaces deal with methods on a struct
<ericsnow> mattyw: if not, totally LGTM
<wwitzel3> katco: no, I am saying your API which accepts interfaces, could accept closures.
<natefinch> wwitzel3: gave you a shipit on the client... there were a couple comments, but they're not critical
<wwitzel3> katco: creating isolation of the foreign API
<natefinch> wwitzel3: i.e. ok to do after the demo (or tell me I'm full of it and "Drop" them ;)
<wwitzel3> natefinch: thank you :), taking a look
<mattyw> ericsnow, if you want to take a look at the two commits https://github.com/juju/juju/pull/2713 you will see minor things
<ericsnow> mattyw: yeah, that's the only difference I noticed so LGTM
<katco> ericsnow: wwitzel3: natefinch: api server abstraction finally landed
<wwitzel3> \o/
<ericsnow> katco: yeah, just saw :)
<katco> that took forever
<katco> i think i hit every branch of the CI issues tree on the way down
<ericsnow> katco: I'll have a patch up shortly that fixes the UnitProcesses issue
<katco> ericsnow: sweet
<ericsnow> katco: http://reviews.vapour.ws/r/2092/
<katco> ericsnow: tal
<ericsnow> katco: ta
<katco> ericsnow: just reading through this, we should put some thought into another name for "State" within components at some point
<ericsnow> katco: agreed
<katco> wwitzel3: natefinch: can someone else review this as well? i'm bumping into a meeting, and i'd like another +1
<wwitzel3> katco: yep, I will as soon as I address my changes from the rebase
<natefinch> katco: looking
<katco> ericsnow: i'm scared. this is all understandable by understanding the individual parts.
<katco> ericsnow: i need the comfort of the rats nest i've become accustomed to.
<ericsnow> katco: if you like that's what I can work on next week <wink>
<natefinch> ericsnow: I don't understand how that API can work
<ericsnow> natefinch: the unit is intrinsic to the hook context
<ericsnow> natefinch: so you don't need the unit to be identified for each API request
<natefinch> ericsnow: also means you *can't* query processes for other units
<wwitzel3> natefinch: if you can give the client stuff another glance, since I updated it for the renames that happened in server-args
<ericsnow> natefinch: is that something we would do in a hook context?
<natefinch> ericsnow: I have no idea :)   I guess we can always change it later.
<ericsnow> natefinch: yeah, adding support for that use case would be almost trivial
<ericsnow> natefinch: (strictly additive)
<katco> ericsnow: natefinch: possible counter-example: leadership. leaders may request operations for other units?
<ericsnow> katco: worth looking into (I'm not super familiar with unit leadership)
<katco> ericsnow: fwereade was mentioning at one point that a service could elect a leader which may then perform operations for the entire service
<ericsnow> katco: do we support that for other components (e.g. storage)?
<natefinch> I say we leave it as is for now.  It's nice not to have to specify the unit when the unit should be obvious.  If we later want to add the ability to specify the unit, we can do so easily.
<katco> ericsnow: really not sure
<ericsnow> natefinch: agreed
<ericsnow> katco: I'll create a card for the open question
<katco> ericsnow: good idea
<natefinch> I'm guessing we'll need to be able to specify the unit... but not for the demo :)
<ericsnow> natefinch: I expect such functionality will not be part of the hook context API
<natefinch> ericsnow: perhaps not
<natefinch> I'm a little curious why we need two APIs, but not concerned about it right now
<natefinch> (or rather why it seems like we might need more than one)
<ericsnow> natefinch: eventually we will have at least 3
<ericsnow> natefinch: (hook context, worker, public)
<natefinch> ericsnow: seems like they won't differ significantrly
<ericsnow> natefinch: probably not
<ericsnow> natefinch: but the differences will be subtle
<natefinch> ericsnow: those are the worst kinds of differences
<ericsnow> natefinch: when we add the others we can look into the best approach (merged or separate)
<natefinch> ericsnow: yep
<wwitzel3> dang
<wwitzel3> I was hoping your stuff wouldn't merge ericsnow , so then you'd have to fix the conflicts
<ericsnow> wwitzel3: mwahaha
<ericsnow> wwitzel3: I realized that after my patch was queued up
<ericsnow> wwitzel3: sorry
<wwitzel3> natefinch mentioned on my review so I hurried to merge but you got in like a minute before me, lol
<natefinch> haha
<ericsnow> wwitzel3: I was thinking to myself "eets a race" (from the movie "Rat Race")
<wwitzel3> :)
<hallblazzar> WARNING juju.replicaset replicaset.go:98 Initiate: fetching replication status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)
<hallblazzar> does anyone got this error when run  "juju bootstrap -e maas"?
<katco> ericsnow: hey, have time to meet now?
<ericsnow> sure
<katco> ericsnow: out 1:1
<wwitzel3> katco: ping
<wwitzel3> katco: in the client constructor for leadership you take in the facade and the caller seperately, do you just pass in st for both?
<natefinch> guys, I gotta run. We still need to pack for our trip... I don't think there's much more I can help with at this point anyway, unless you want someone to throw under the bus for a quick rubber stamp ship it.
<natefinch> wwitzel3: katco, ericsnow ^^
<ericsnow> natefinch: have a great time :)
<wwitzel3> natefinch: thanks again, have a good time
<natefinch> thanks!
<mup> Bug #1471004 opened: apiserver/storageprovisioner unit test fails on ppc64 <juju-core:New> <https://launchpad.net/bugs/1471004>
<mup> Bug #1471004 changed: apiserver/storageprovisioner unit test fails on ppc64 <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1471004>
<mup> Bug #1471004 opened: apiserver/storageprovisioner unit test fails on ppc64 <juju-core:New> <https://launchpad.net/bugs/1471004>
<mup> Bug #1471030 opened: github.com/juju/juju/cmd/juju tests timeout on ppc64 <ci> <ppc64el> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1471030>
<thumper> menn0: ping
<menn0> thumper: pong
<thumper> menn0: do you have some time to talk through this upgrade issue?
<menn0> thumper: yup. standup hangout
<mwhudson> davechen1y: do you know much about cmd/internal/obj/arm ?
<mwhudson> like, what is Prog.Scond
<mwhudson> i guess it's the arm conditional execution bits?
<mwhudson> ah yes
<axw> perrito666: sorry I think you were saying something as I left
<perrito666> axw: no, I bg noise
<axw> ok
<axw> perrito666: sounded like someone jumping up and down on a squeaky bed
<perrito666> axw: eliptical walking machine
<axw> :)
<perrito666> I hate it
<perrito666> :p
<perrito666> I have oiled every possible piece of that thing and still makes noise
#juju-dev 2015-07-03
<davechen1y> mwhudson: yes scond is the putative condition bits for arm instructions
<davechen1y> the s is silent
<mwhudson> heh
<mwhudson> 5g is ... something
<mwhudson> oops, not that any more
<menn0> thumper: how are you getting on with that bug?
<menn0> davechen1y: we should talk about the certupdater before my EOD
<davechen1y> menn0: how about now ?
<davechen1y> thumper: https://docs.google.com/document/d/1UPYcjMHV2YEHNAVjMWQAh2Htj-pPl2Bt0_POBGLQURE/edit
<davechen1y> so, this sprint we had a dedicaed bug squad
<davechen1y> and the number of bugs fixed went down ...
<davechen1y> i'm not sure that is the result that was intended
<mwhudson> urgh, the 32 bit arm abi is less nice than the 64 bit one
<davechen1y> when you say "less nice"
<davechen1y> to you mean lemon juice is "less nice" than wine
<davechen1y> menn0: want to talk in the standup hangout ?
<mwhudson> davechen1y: well, i wouldn't say the 64 bit one is comparable to wine
<menn0> davechen1y: sounds good
<davechen1y> why is tim still in the standup
<davechen1y> thumper: why are you still in this hangout ?
<thumper> davechen1y: the bugs fixed went down over the second iteration, which wasn't this one, but the last one
<thumper> menn0: just back
<thumper> menn0: also thinking, that despite our best efforts and analysys, we may still have some weird conditions where workers are not being shut down
<thumper> menn0: this would explain a number of cases...
<thumper> menn0: although, if the pinger is getting stuck, that would explain one or two
<davechen1y> menn0: // Accept waits for and returns the next connection to the listener.
<davechen1y> func (cl *changeCertListener) Accept() (c net.Conn, err error) { cl.m.Lock() defer cl.m.Unlock()
<menn0> thumper: a worker getting stuck would explain a lot of things
<thumper> menn0: we are seeing it on the ppc64 tests still, and some of the unit agents didn't restart...
<thumper> I'm looking at one that didn't now
<menn0> thumper: ok
<menn0> davechen1y: looking at the code for tls.NewListener
<menn0> davechen1y: i now remember what my plan was
<thumper> definitely a bug in the unit agent
<thumper> at 11:00:23 most workers die for shutdown
<thumper> these two lines are next to each other
<thumper> 2015-07-02 11:00:23 DEBUG juju.worker runner.go:242 killing "rsyslog"
<thumper> 2015-07-02 11:00:25 INFO juju.worker runner.go:261 start "rsyslog"
<thumper> 2
<thumper> then we can see that jujuc commands are being fired
<menn0> davechen1y: i was thinking that instead of wrapping a tls.Listener we should copy the tiny amount of code from it and integrate it into certChangeListener
<thumper> config-changed hook being fired
<menn0> certChangeListener could have an extra method to swap out the config
<menn0> and the config would need to be protected by a lock
<menn0> thumper: ok so something ain't dying
<thumper> bingo
<menn0> thumper: the unit agent has few workers so it shouldn't be hard to figure out which
<thumper> the uniter is running the config-changed hook
<menn0> thumper: but this doesn't necessarily explain the upgrade issue we were looking at
<thumper> no...
<thumper> that is most likely something else too
<menn0> thumper: although they could be caused by a related change
 * thumper nods
<thumper> oh fuck...
 * menn0 waits for good/bad news
<thumper> well...
<thumper> this is one problem
<thumper> when the apiservers come back on line
<thumper> the unit agent connects
<thumper> one of the first thing that fires is config-changed
<thumper> even though it probably didn't
<thumper> now while the config-changed hook is being fired
<thumper> we get told to upgrade
<thumper> everything dies
<thumper> except the uniter
<thumper> which carries on for a while
<thumper> then doesn't stop
<thumper> the uniter is told to die...
<thumper> can't tell if it actually does
<thumper> certainly doesn't finish
<thumper> the agent doesn't restart
<menn0> right
<thumper> seems to happen on a subset of units
<thumper> certainly most restart
<thumper> this screams race somewhere
<menn0> thumper: this is probably what caused all those config-changed hook errors.
<thumper> and may well be the cause of these other problems
<thumper> I have to dig in a little...
<menn0> b/c the unit agent doesn't shut down the API connection so the apiserver doesn't stop
<thumper> to work that one out
 * menn0 is going to check if this could be the cause of the other bug he's looking at
<thumper> yeah... all seems closely related
<menn0> i might make the uniter intentional hang to simulate and see what happens when an upgrade is requested
<davechen1y> ,menn0 so
<davechen1y> the approach I discussed on the call has one drawback
<davechen1y> using that lock where I said
<davechen1y> means the cert update worker will _block_ until one connetion is received by the apiserver
<davechen1y> i'm not sure how much of a problem this will be in practice
<menn0> davechen1y: it is a problem b/c it will prevent the agent from shutting down if there's been no connections received
<davechen1y> nope, that will be fine
<davechen1y> because we run the http.Server in a goroutine
<davechen1y> and signal to it by closing hte underlyning tcp socket
<menn0> davechen1y: ok, as long as you're sure
<davechen1y> i'm not sure of anything anymore
<davechen1y> that's why i run the race detector
<davechen1y> i'll see how the patch shapes up
<davechen1y> we can debate it on reviewboard
<menn0> thumper: so a stuck uniter doesn't prevent the the state server from upgrading, but it does prevent the unit agent from upgrading (expected)
<menn0> davechen1y: sounds good
<thumper> menn0: yes...
 * thumper goes to make some notes on the bug
<davechen1y> thumper: http://paste.ubuntu.com/11813756/
<davechen1y> new race
<davechen1y> :(
<thumper> :(
<thumper> wat?
<thumper> really new?
<mwhudson> fire up your engines!
<davechen1y> i think so
<thumper> previous write by: sync.(*Mutex).Lock()
<thumper> fucking what?
<thumper> davechen1y: if a pointer is used as a bool check
<thumper> nil doesn't count as true does it?
<thumper> pointer / interface
<thumper> oh...
<thumper> damn it
<thumper> it is a switch
<thumper> meh
<davechen1y> github.com/juju/juju/environs/configstore.(*memInfo).clone()
<davechen1y> in code review
<davechen1y> _anything_ with a clone method gets a hairy eyeball
<davechen1y> it's a smell
<thumper> menn0: mysql-hacluster/0 did not upgrade because the config-changed hook did not complete
<menn0> thumper: ok so that's one problem
<menn0> thumper: do you think it's a uniter bug or a problem with the hook it's running?
<thumper> that one is the underlying hook AFAICT
<menn0> thumper: or perhaps the hook is running a tool which calls back to juju?
<thumper> but all that code is handled by the uniter itself
<thumper> so we'd see it
<menn0> thumper: so I figured out why we saw those api blocked / "upgrade in progress" log messages
<menn0> thumper: it's due to some new stuff that ian added
<menn0> thumper: it'll do that until the upgrader has done its first check for a new version
<menn0> thumper: so that we don't allow API requests when the agent is about to restart
<menn0> thumper: the message is a little confusing though
<thumper> ah...
<thumper> is that how we manage to have the apiserver not too busy that second time up?
<thumper> so it can restart?
<menn0> could be
<thumper> that would actually explain it
<menn0> have you tried to verify that the apiserver actually can get stuck
<menn0> ?
<thumper> just bootstrapping an environment
<menn0> cool
<thumper> I have figured that none of the code around this has changed
<thumper> so I'm using 1.24.2 for better logging
<thumper> and just using the juju upgrade-juju --upload-tools so it increments the buildnumber
<thumper> ERROR while stopping machine agent: exec ["stop" "--system" "juju-agent-tim-testlocal"]: exit status 1 (stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist)
<thumper> boo hiss
<menn0> yeah that happens all the time in my trusty VM
<davechen1y> thumper: menn0 https://github.com/juju/juju/pull/2716
<davechen1y> for debate
 * menn0 looks
<davechen1y> this is the smallest possible change i can make
<menn0> davechen1y: I don't think this is enough
<menn0> davechen1y: if you look at crypto/tls you can see that Conn ends up with the the Config
<menn0> davechen1y: and it uses it beyond Accept
<menn0> davechen1y: so if anything changes the config after it could get a surprise
<menn0> davechen1y: oh I see... it's not so bad because Handshake is also blocked by the lock
<menn0> davechen1y: but that's kind of a hack
<menn0> davechen1y: do you mind if I put up a counter-PR?
<menn0> i'm thinking we don't use tls.Listener at all
<davechen1y> menn0: sure
<menn0> davechen1y: almost done :)
<menn0> davechen1y: do you happen to know a test that failed the race detector
<davechen1y> go test -race ./cmd/jujud/agent
<davechen1y> litmus test
<davechen1y> thumper: what's the story with getting a voting race test ?
<davechen1y> thumper:  menn0 have to run out to the bank to get greenbacks for next week
<menn0> davechen1y: i'm just pushing this PR now
<thumper> davechen1y: flick of a switch when we are at zero
<davechen1y> thumper: so there is a non voting test at the moment ?
<davechen1y> how can I see the results that it sees today ?
<thumper> davechen1y: correct
 * thumper looks
<menn0> davechen1y: https://github.com/juju/juju/pull/2717
<menn0> davechen1y: with this approach each connect gets it own tls.Config
<thumper> davechen1y: http://reports.vapour.ws/releases/2847/job/run-unit-tests-race/attempt/150
<menn0> davechen1y: so there's no way the cert updates can affect existing connections
<menn0> davechen1y: also: there's no need for the lock to be held the whole time
<menn0> davechen1y: (until the first connection)
<menn0> davechen1y: do you understand why processCertChanges wanted to always hold the lock?
<menn0> davechen1y: that seems like a serious bug
<thumper> menn0: looks fine to me...
<thumper> menn0: I'm assuming it works
<menn0> thumper: tests pass .... haven't tried to use it
<menn0> thumper, davechen1y: so ales made added a nasty bug a few days ago
<thumper> oh?
<menn0> thumper, davechen1y: look at rev c147767de940cd07db3330ac3a19f9f3547d4be1
<thumper> menn0: c'mon, post a link to the revision at least
<menn0> thumper, davechen1y: https://github.com/juju/juju/commit/c147767de940cd07db3330ac3a19f9f3547d4be1
<menn0> with that in place i'm surprise the apiserver even works in master
<thumper> because the lock is already held?
<menn0> yep
<menn0> just checking now
<menn0> thumper: well I have no idea how that works
<menn0> thumper: but everything seems ok
<thumper> what type of lock is it?
<menn0> sync.Mutex
<thumper> perhaps because process change is never being caleld
<menn0> thumper: i've put log messages in and I can see that it is
<thumper> ?!?
<thumper> i thought that would have deadlocked
<menn0> same!
<menn0> thumper: it does deadlock
<thumper> umm...
<thumper> you said that you see the lgos
<thumper> logs
<menn0> thumper: I just added more logs
<thumper> you put the logs before the lock didn't you?
<menn0> thumper: the cert update goes to happen and then it gets stuck b/c it can't get the lock again
<menn0> thumper: the api server keeps working b/c Handshake isn't even called on changeCertConn (which is the other place the lock is grabbed)
<menn0> thumper: so there is no need for changeCertConn to even exist
<menn0> thumper: my PR gets rid of changeCertConn anyway
<thumper> menn0: care to explain to me how your change works to fix things
<thumper> ?
<menn0> thumper: sure
<menn0> thumper: so it means that each connection ends up with a private copy of the tls.Config
<menn0> thumper: so that when the certificate is updated, it doesn't affect existing connections
<menn0> thumper: and new connections see the new config with the updated cert
<thumper> well that makes sense
<menn0> thumper: there's no race because the tls.Config's aren't being shared
<thumper> shipit
<menn0> thumper: ok cool
<thumper> I'm not getting to a reproduction step here.
<menn0> thumper: just updating the commit message
<thumper> and my brain is fuzzed
<thumper> and it is friday
<menn0> thumper: i've had very little success with these bugs myself
<menn0> thumper: they are so hard to repro
 * thumper nods
<thumper> have a good weekend folks
<menn0> thumper: debug level logs with the extra logging you added would help a lot
<thumper> davechen1y: safe travels
<thumper> menn0: yeah...
<thumper> there are several extra places we should add logging ...
<menn0> davechen1y: thumper is happy but I'd appreciate your feedback on this: http://reviews.vapour.ws/r/2095/
<menn0> davechen1y: i'm EOD now but will leave IRC up and check back later
<davechen1y> menn0: kk
<davechen1y> menn0: ship it, that's excellent
<mup> Bug #1471138 opened: destroy-environment should be able to destroy all sub-environments <juju-core:New> <https://launchpad.net/bugs/1471138>
<menn0> davechen1y: sweet thanks
 * fwereade bbiab
<rogpeppe1> ha, has anyone realised that we don't allow single-character user names
<rogpeppe1> ?
<rogpeppe1> i wonder if that was deliberate
<perrito666> TheMue: hb
<dimitern> perrito666, he's off today
<perrito666> well he'll read that when he returns hopefuly
<dimitern> :)
<fwereade> perrito666, do you need unblocking on http://reviews.vapour.ws/r/1851/ ?
<perrito666> fwereade: mm, why is that still open? let me check
<dimitern> 2015-07-03 13:19:53 ERROR juju.cmd supercommand.go:430 tools upload failed: 400 ({"Tools":null,"DisableSSLHostnameVerification":false,"Error":{"Message":"cannot get environment config: invalid series \"wily\"","Code":""}})
<dimitern> are going to have to deal with such issues on *every* ubuntu release?
<perrito666> dimitern: yes
<perrito666> at least based in historical data
<dimitern> :(
<dimitern> tgif at least
<perrito666> fwereade: I was under the impression that it had been merged, perhas it was merged to previous versions, Ill address that next week (most, if not all, your comments make sense)
<mup> Bug #1471231 opened: debugLogDBIntSuite teardown fails <ci> <unit-tests> <juju-core:Incomplete> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1471231>
<mup> Bug #1471237 opened: Mongo causes juju to fail: bad record MAC <mongodb> <reliability> <juju-core:Triaged> <mongodb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1471237>
<mup> Bug #1471241 opened: RelationSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1471241>
<fwereade> perrito666, and also, can I help at all with http://reviews.vapour.ws/r/1979/ ?
<perrito666> fwereade: not really, I have to go all over that again and submit another patch but I really dont want to context switch now it has been a terrible week for me in terms of the task at hand
<fwereade> perrito666, no worries at all, just checking in
<fwereade> perrito666, when you get back to it just let me know if anything needs clarification
<mup> Bug #1471241 changed: RelationSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1471241>
<mup> Bug #1471242 opened: juju upgrade-juju to 1.24.2 fails with "invalid series: willy" <juju-core:New> <https://launchpad.net/bugs/1471242>
<voidspace> dimitern: http://reviews.vapour.ws/r/2097/
<dimitern> voidspace, awesome! LGTM
<voidspace> dimitern: wow, that was quick
<voidspace> dimitern: thanks
<dimitern> voidspace, well, it's also friday :)
<rogpeppe1> wwitzel3: ping
<mup> Bug #1471308 opened: TestOpenStateWorksForJobManageEnviron fails intermittently on windows <ci> <intermittent-failure> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1471308>
 * fwereade is finally happy enough with http://reviews.vapour.ws/r/2078/ and would very much appreciate reviews
<mup> Bug #1471332 opened: Upgrade fails on windows machines <ci> <upgrade-juju> <windows> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1471332>
<fwereade> gaah
<fwereade> I'm inside state
<perrito666> fwereade: how did you get inside it?
 * perrito666 takes a crowbar and goes to the rescue
<fwereade> what's the quickest cleanest way to either find out what machine I'm running on, or otherwise come up with another stable id that effectively maps to that
<fwereade> ?
<mgz> fwereade: I'm like 20 mins in to reading your giant branch
<fwereade> mgz, sorry it's so big but there was a lot to untangle
<fwereade> mgz, I'm pretty sure it's there now though
<mgz> yeaj, it's all pretty sane so far at least
<fwereade> mgz, cool
<fwereade> mgz, I pushed a much better description recently fwiw
<fwereade> mgz, not sure if 20 mins ago or not
<fwereade> mgz, probably more actually
<perrito666> fwereade: where are you exactly?
<perrito666> fwereade: to answer to your question
<fwereade> perrito666, I'm in a state method which I want to set up the presence watcher and lease/leadership stuff
<fwereade> perrito666, my lease client needs a unique id for the machine it's running on
<perrito666> I see
<fwereade> perrito666, deriving it from current state server id would be great
<fwereade> perrito666, but, heh, how do we know which we are?
<fwereade> perrito666, if I weren't inside state I could pass it in via agent config
<fwereade> perrito666, but that really has no place in state
<perrito666> fwereade: State{}.serverTag I think
<fwereade> perrito666, I'm pretty sure that's the environ the state server's running in
<fwereade> perrito666, but not unique to a particular machine
<perrito666> look at IsStateServer
#juju-dev 2015-07-04
 * fwereade hates import cycles
#juju-dev 2015-07-05
<thumper> storage_test.go:147:
<thumper>     c.Assert(info, jc.DeepEquals, expect)
<thumper> ... obtained state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
<thumper> ... expected state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
<thumper> ... mismatch at .ReadOnly: unequal; obtained true; expected true
<thumper> WTH?
<fwereade> menn0, offhand, why does envStateCollection reject bson.M queries?
 * menn0 has to look at the code
<thumper> fwereade: did you see that error above?
<fwereade> menn0, I think it's just a "nobody uses bsom.M queries" unless you know different
<fwereade> thumper, huh
<fwereade> thumper, that's ...interesting :/
<thumper> yeah...
<menn0> fwereade: I /think/ it was that they weren't being used so YAGNI
<fwereade> menn0, cool
<menn0> fwereade: there's no technical reason they couldn't be supported
<fwereade> menn0, yeah, I've already written it :)
<menn0> fwereade: map based queries are slightly finicky/dangerous anyway
<menn0> fwereade: b/c of field ordering
<fwereade> menn0, just thought I'd better check there wasn't a good reason
<fwereade> menn0, hmm, can it subtly change complex queries?
<menn0> fwereade: more that a query might not used a query if the field order in the query doesn't match
<fwereade> menn0, I've tended to use bson.D out of habit, but .Ms are often that tiny bit cleaner to write so I've started using them a bit
<menn0> fwereade: might not use an INDEX
<fwereade> menn0, ahhhhh
<menn0> sorry... haven't had my second coffee
<menn0> I agree .M's are much nicer to write and read
<menn0> you just have to be a little more careful
<fwereade> menn0, anyway, I did not know that, can you point me to an example/doc/something?
<fwereade> menn0, apart from anythinng else this likely means I've been writing my .Ds in a dumb order, because I don;t know what a good one is
<menn0> fwereade: sorry, ignore what I said about indexes
<menn0> fwereade: i'm being dumb
<menn0> fwereade: i'm was misremembering this: http://devblog.me/wtf-mongo (first section)
<menn0> fwereade: .M's are only really a problem if you're trying to exactly match a embedded document
<menn0> fwereade: which we rarely/never do
<fwereade> menn0, ah, ok, cool
<menn0> fwereade: so using .M's is almost always fine
<fwereade> menn0, I suppose I also don't know how it handles repeated names, so a conversion from D to M could be fun if they were significant
<menn0> fwereade: do we do that?
<fwereade> menn0, not as far as I'm aware, but I do the opposite in the M-handling because it seemed most conveniennt (and should be safe ;))
<menn0> fwereade: yep, sure
 * menn0 slinks away to make another coffee
<fwereade> menn0, waigani, thumper: by the way I have a question on http://reviews.vapour.ws/r/2078/ that you might collectively know the answer to
<fwereade> namely how exactly should cleanupsC interact with env destruction?
<menn0> fwereade: cleanupsC was removed at runtime? that rings a slight bell, and also sounds like a terrible idea
<fwereade> menn0, it was pretty clearly accidental
<fwereade> menn0, foo := multiEnvCollections; foo.Remove(cleaupsC)
<fwereade> menn0, can't even remember if it was in code or in test
<menn0> fwereade: that does ring a bell
<fwereade> menn0, either way I raged momentarily and moved on ;)
 * menn0 checks for that code
<fwereade> menn0, it's somewhere in the red in that review, I'm pretty sure
<menn0> fwereade: found it. it's in a test.
<menn0> fwereade: oh... and in implementation
<fwereade> ha :(
<menn0> there was a func which returned a copy of the multiEnvCollections but without cleanupsC
<menn0> / newEnvAliveColls returns a copy of multiEnvCollections minus cleanupsC.
<menn0> / This set is used to check if a txn needs to assert that there is a live
<menn0> / environment be inserting docs.
<menn0> func newEnvAliveColls() set.Strings {
<menn0> 	e := set.NewStrings(multiEnvCollections.Values()...)
<menn0> 	e.Remove(cleanupsC)
<menn0> 	return e
<menn0> }
<fwereade> that's the one
<fwereade> d} and move on, deal with the fallout later :)
<menn0> it was used to decided whether or not to the assertion for env aliveness should be added to a txn.Op
<fwereade> oh wait that one's ok
<menn0> for cleanupsC it shouldn't I guess
<fwereade> yeah I have a similarly vague understanding of maybe why we might want to do that sometimes but I'm very vague
<fwereade> I think it's ok to insert into cleanups when an env is dyinng
<fwereade> menn0, but I don't see why we should preserve cleanups when we nuke env docs
<fwereade> menn0, that was either happening or I briefly hallucinated it was happening
 * fwereade is if nothing else a reliable narrator </straight-face?
<menn0> fwereade: it seems like what you've done with ignoreInsertRestrictions covers that previous case
<menn0> fwereade: (although I would consider calling it something like allowInsertWhenEnvNotAlive)
<menn0> fwereade: i'm not sure about this either. I haven't done much with cleanups. waigani, cherylj and thumper probably know more than me.
<menn0> fwereade: where do you see code that preserves cleanups when an env is nuked?
 * thumper was reading scroll back
<thumper> I'm not fully caught up yet
<waigani> menn0, fwereade: cleanupsC is part of the muliEnvCollections set - so it gets removed along with the others - as the last step of destroying an environment
<thumper> school hols, and the girls are wanting to play with my new star realms deck
<thumper> a little time teaching them the rules may mean many hours of freedom
<waigani> haha
<fwereade> thumper, nice :)
<fwereade> thumper, menn0: it's quite possible all I saw was that it wasn't immediately certain whether the removal code in the test would run before or after any other tests that might depend on its presence or otherwise
<thumper> wallyworld: we should chat when you have a minute or two
<wallyworld> thumper: sure, give me 5?
<thumper> ack
<wallyworld> thumper: 1:1?
<thumper> yep, there shortly, just writing something
<waigani> thumper: your bool problem, is the struct being written to/read from mongo?
<waigani> thumper: from the mgo docs: "Bools are converted to numeric types as 1 or 0 - Numeric types are converted to bools as true if not 0 or false otherwise"
<waigani> thumper: maybe ppc stores the bools in a weird way
<waigani> fwereade: ping
#juju-dev 2016-07-04
<mup> Bug #1598707 opened: juju use many DEPRECATED apis ,is there new juju version using the latest api? <juju-core:New> <https://launchpad.net/bugs/1598707>
<mup> Bug #1598708 opened: juju use many DEPRECATED apis ,is there new juju version using the latest api? <juju-core:New> <https://launchpad.net/bugs/1598708>
<hoenir> https://bugs.launchpad.net/juju-core/+bug/1598206 I'm currently on the latest commit on master and it builds just fine, anyone have some idea on how to reproduce this bug?
<mup> Bug #1598206: lxc/lxd/shared/util_linux.go sys/types.h: No such file or directory <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1598206>
<hoenir> why would this break in the first place?
<hoenir> hmm it is because the pkg is still currently builds under sys1.2?
<mup> Bug #1598729 opened:  trusty juju 1.25.5 HA - non bootstrap state nodes don't seem to work <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1598729>
<mup> Bug #1598752 opened: Juju-deploy fails: Juju cannot bootstrap because no tools are available for your environment <juju-core:New> <https://launchpad.net/bugs/1598752>
<mup> Bug #1598752 changed: Juju-deploy fails: Juju cannot bootstrap because no tools are available for your environment <juju-core:Invalid> <https://launchpad.net/bugs/1598752>
<mup> Bug #1598729 changed:  trusty juju 1.25.5 HA - non bootstrap state nodes don't seem to work <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1598729>
<mup> Bug #1598729 opened:  trusty juju 1.25.5 HA - non bootstrap state nodes don't seem to work <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1598729>
<mup> Bug #1598729 changed:  trusty juju 1.25.5 HA - non bootstrap state nodes don't seem to work <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1598729>
<mup> Bug #1598752 opened: Juju-deploy fails: Juju cannot bootstrap because no tools are available for your environment <juju-core:Incomplete> <https://launchpad.net/bugs/1598752>
<mup> Bug #1598752 changed: Juju-deploy fails: Juju cannot bootstrap because no tools are available for your environment <juju-core:Incomplete> <https://launchpad.net/bugs/1598752>
<mup> Bug #1598752 opened: Juju-deploy fails: Juju cannot bootstrap because no tools are available for your environment <juju-core:Incomplete> <https://launchpad.net/bugs/1598752>
<mup> Bug #1598897 opened: juju status relations that only differ by name collapsed in tabular output <juju-core:New> <https://launchpad.net/bugs/1598897>
<mup> Bug #1598964 opened: juju run command failing <juju-core:New> <https://launchpad.net/bugs/1598964>
#juju-dev 2016-07-05
<mup> Bug #1588095 opened: help for juju run-action refers to commands that don't exist <juju-core:New> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1588095>
<mup> Bug #1599129 opened: run action against a non-existant unit gives confusing error <juju-core:New> <https://launchpad.net/bugs/1599129>
<mup> Bug #1588095 changed: help for juju run-action refers to commands that don't exist <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1588095>
<mup> Bug #1599129 changed: run action against a non-existant unit gives confusing error <juju-core:New> <https://launchpad.net/bugs/1599129>
<mup> Bug #1588095 opened: help for juju run-action refers to commands that don't exist <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1588095>
<mup> Bug #1599129 opened: run action against a non-existant unit gives confusing error <juju-core:New> <https://launchpad.net/bugs/1599129>
<fwereade> katco, just wanted to check in and make sure you understand the problems with http://reviews.vapour.ws/r/5201/
<fwereade> katco, or rather, with http://reviews.vapour.ws/r/5089/
<mup> Bug #1586057 changed: Race in github.com/juju/juju/container/lxc <ci> <lxc> <race-condition> <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1586057>
<katco> fwereade: yes, i see the problem, thanks. would you prefer i pass state (e.g. startTime) into the observer functions?
<kwmonroe> hey dooferlad - nice dive into bug 1594924!  i got a bit lost between your last 2 comments though.. do you think it's DES or the growing mongo that is the larger culprit?  i ask because it sounds like removing des might be easy -- "fixing" mongo might be hard.
<mup> Bug #1594924: resource-get is painfully slow <2.0> <resources> <juju-core:Triaged by dooferlad> <https://launchpad.net/bugs/1594924>
<dooferlad> kwmonroe: DES is a big slowdown
<dooferlad> kwmonroe: mongo is insignificant vs 3DES
<dooferlad> kwmonroe: but mongo is quite a lot slower than the network.
<kwmonroe> good to hear dooferlad -- thanks for the info
<mup> Bug #1550074 changed: ec2/ebs: ListVolumes should not return root volumes <ec2-provider> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1550074>
<mup> Bug #1550819 changed: TestAddLocalCharmUnauthorized mismatch <2.0-count> <go1.5> <go1.6> <intermittent-failure> <wily> <xenial> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1550819>
<mup> Bug #1579002 changed: state: uses too many mgo sockets in loops <juju-core:Fix Released by rogpeppe> <https://launchpad.net/bugs/1579002>
<stokachu> cherylj: hey could you see about getting an update for https://bugs.launchpad.net/juju-core/+bug/1593828
<mup> Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828>
<thumper> jam: still around?
<cherylj> stokachu: sure.  I know it was discussed last week at our team sprint
<stokachu> cherylj: thanks!
<cherylj> perrito666: could you review fwereade's PR:  http://reviews.vapour.ws/r/5207/
<mgz> bug 1596493
<mup> Bug #1596493: github.comjuju/juju/apiserver package: unattributed test failure <blocker> <ci> <regression> <test-failure> <unit-tests> <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1596493>
<mgz> bug 1598272
<mup> Bug #1598272: LogStreamIntSuite.TestFullRequest sometimes fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1598272>
<mgz> ^whoopsie cherylj, maybe same bug?
<fwereade> mgz, most likely, yes
<fwereade> mgz, there's nothing that guarantees the failure will happen after the test finisheds
<fwereade> mgz, cherylj: yeah, it's the same
<katco> fwereade: hey, did you see my response here and in email?
<bdx> openstack-peeps: in setting up image-metadata for a private cloud, does juju support to multiple products in the index.json?
<bdx> e.g. http://paste.ubuntu.com/18574625/
<bdx> here's my com.ubuntu.cloud-released-imagemetadata.json -> http://paste.ubuntu.com/18574800/
<bdx> I feel like I'm on the right track, just wondering if there is anything in Juju preventing this?
<mup> Bug #1599269 opened: Can't redeploy local charms that have changed <juju-core:New> <https://launchpad.net/bugs/1599269>
<mup> Bug #1599272 opened: ERROR retrieving SSH host keys for ...: keys not found <juju-core:New> <https://launchpad.net/bugs/1599272>
<cherylj> katco: would you be able to review http://reviews.vapour.ws/r/5207 ?
<katco> cherylj: sure
<cherylj> mwhudson: ping?
<mwhudson> cherylj: hi
<cherylj> hey hey mwhudson
<cherylj> mwhudson: wondering if I could pick your brain regarding bug 1598206
<mup> Bug #1598206: lxc/lxd/shared/util_linux.go sys/types.h: No such file or directory <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1598206>
 * mwhudson blinks
<cherylj> mwhudson: we're seeing that error when trying to run unit tests on ppc64el, but building the agents succeeded without any error
<cherylj> and I have no clue where to start :/
<mwhudson> that doesn't sound like it makes a great deal of sense on the face of it
<cherylj> yeah
<cherylj> I think sinzui rebooted the host and tried again, but got the same error
<mwhudson> cherylj: well that header should come from libc6-dev which is suuuuurely installed?
<cherylj> mwhudson: let me see if I can access the host
<mwhudson> yeah, i don't think this is going to be fixable without some host-level poking
<cherylj> mgz: do I need to use a jump host to get to the ppc machine?
<mgz> cherylj: yeah, you need to go through our canonistack thing
<mgz> or have the vpn on
<cherylj> I am on the vpn, but it's just hanging trying to get to 10.245.67.133
<mgz> ...stilson-07 at least doesn't have build tools installed, which stilson are we building on...
<mwhudson> cherylj: hm, maybe you don't have access to that network, i can try to ssh to that ip
<mwhudson> (and fail to login, of course, but it's not hanging)
<mgz> sudo apt-get install libc6-dev on stilson-05 is giving me packages to install
<mgz> do we have some missing deps in our golang packaging?
<mgz> it has newest golang-go at 2:1.6-1ubuntu4
<mwhudson> uh that's not newest
<mwhudson> but not in a relevant way here i think
<mgz> cherylj: remember you can find all our jumphost rules by looking at jenkins:~/.ssh/config on ci master
<cherylj> mgz: one day I will...
<mgz> okay, running update
<cherylj> ;)
<mgz> mwhudson: still tells me it's the latest
<mwhudson> mgz: looks like gcc-5 only recommends, not depends libc6-dev
<mwhudson> mgz: oh, right, mixing up versions!
<mwhudson> mgz: golang-1.6-go should be 1.6.2-0ubuntu5~16.04
<mwhudson> mgz: but this is irrelevant really :)
<mwhudson> mgz: are recommends turned off in the apt config?
<mgz> mwhudson: so, I want to install libc6-dev for now, anything else?
<mgz> mwhudson: yeah, that's the version
<mwhudson> mgz: dunno, start with that?
<cherylj> heh
<mgz> cherylj: rebuilding last xenial-ppc64el job
<mgz> mwhudson: it might be the juju makefile?
<mgz> mwhudson: yeah, has --no-install-recommends
<mwhudson> mgz: hm yeah
<mwhudson> mgz: i guess that should install libc6-dev too then!
<mgz> mwhudson: so I guess we file a bug against juju to not do that... sometimes?
<mgz> or yeah
<mgz> or just adapt the existing one
<mup> Bug #1599315 opened: LXD no longer gets correct network in JUJU beta11 and MAAS2rc1 <juju-core:New> <https://launchpad.net/bugs/1599315>
#juju-dev 2016-07-06
<mup> Bug #1599402 opened: read-only users: unauthorized access to read-only functionalities <juju-core:New> <https://launchpad.net/bugs/1599402>
<mup> Bug #1599503 opened: Cannot upgrade charm if storage is modified, even if the service doesn't use said storage <juju-core:New> <https://launchpad.net/bugs/1599503>
<mup> Bug #1599507 opened: juju status show blank for public name for one machine. <juju-core:New> <https://launchpad.net/bugs/1599507>
<mgz> dooferlad: bug 1450729
<mup> Bug #1450729: juju should be able to use nodes acquired by the same user in MAAS <cloud-installer> <deploy> <landscape> <maas-provider> <juju-core:Triaged> <MAAS:Opinion> <https://launchpad.net/bugs/1450729>
<mup> Bug #1599507 changed: juju status show blank for public name for one machine. <juju-core:New> <OPNFV:New> <https://launchpad.net/bugs/1599507>
<aisrael> cherylj: Could you take a new look at https://bugs.launchpad.net/juju-core/+bug/1287665? We ran into this issue during customer meetings last week in Madrid.
<mup> Bug #1287665: Export bundle without juju GUI <canonical-is> <deployer> <sts-support> <juju-core:Triaged> <juju-deployer:New> <https://launchpad.net/bugs/1287665>
<cherylj> aisrael: sure
<cherylj> aisrael: we are already fully booked for 2.1 and the remaining 2.0 work.  We can put this on a wish list, but I wouldn't be optimistic about getting it any time soon :(
<aisrael> cherylj: ack, thanks for looking
<cherylj> aisrael: just fyi - it's already on the "feature request" list:  https://github.com/juju/juju/wiki/Feature-Requests
<aisrael> cherylj: excellent, thanks!
<cherylj> aisrael: the idea is that we would look there for features when we make our plans, but we were already overcommitted for 2.1
<aisrael> cherylj: Understood. I'll check juju-bundlizer to see if that can be updated to work with the new API in the meantime
<aisrael> deployerizer, rather
<mup> Bug #1599315 changed: LXD no longer gets correct network in JUJU beta11 and MAAS2rc1 <network> <juju-core:Invalid> <https://launchpad.net/bugs/1599315>
<marcoceppi> aisrael: it might be worth renaming deployerizer to something like `juju get-bundle` to make it clearer what it's doing?
<marcoceppi> cherylj: I also noticed that the hook-tool descriptions are out of date as of beta11, they still reference "service"
<rick_h_> but 'deployerizer' is so cool! It seems like a james bond weapon.
<aisrael> marcoceppi: ack, I agree. I kept typing it as bundlizer because name =/= functionality
<cherylj> marcoceppi: oh, thanks for finding that.  Want to open a bug, or should I?
<marcoceppi> cherylj: https://bugs.launchpad.net/juju-core/+bug/1599570
<mup> Bug #1599570: hook-tool help messages still reference service <juju-core:New> <https://launchpad.net/bugs/1599570>
<cherylj> there ya go
<cherylj> thanks :)
<mup> Bug #1599570 opened: hook-tool help messages still reference service <juju-core:New> <https://launchpad.net/bugs/1599570>
<mup> Bug #1599612 opened: remove-application has unexpected output with subordinate units <juju-core:New> <https://launchpad.net/bugs/1599612>
<mup> Bug #1573020 changed: upgrade-charm --path does not recognize dot <juju-release-support> <upgrade-charm> <juju-core:Triaged> <https://launchpad.net/bugs/1573020>
<mup> Bug #1576346 changed: upgrade-charm with a local charm fails with trailing slash <juju-release-support> <papercut> <upgrade-charm> <juju-core:Triaged> <https://launchpad.net/bugs/1576346>
#juju-dev 2016-07-07
<dimitern> morning
 * dimitern waves at dooferlad
<dimitern> frobware, jam, fwereade: standup?
<mup> Bug #1599779 opened: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
<frobware> dimitern, dooferlad: http://reviews.vapour.ws/r/5212/ when you have some time
<dimitern> frobware: ack, added to my list
<dimitern> frobware: reviewed
<frobware> dimitern: thanks
<frobware> mgz: you about?
<frobware> dimitern: does my comment about the dependency stack up (for you)?
<dimitern> frobware: looking
<dimitern> frobware: +1
<frobware> dimitern: ty
 * dimitern steps out for a while
<mgz> frobware: yo, how can I help?
<frobware> mgz: I landed a change for https://github.com/juju/juju/pull/5769
<frobware> mgz: I wanted to verify that your packaging/building would now be OK
<mgz> frobware: thanks, I can back out the change I made for the beta10 packaging
 * dimitern is back
<frobware> dimitern: care to HO for a minute?
<dimitern> frobware: sure, the 1:1 ?
<frobware> ok
<dimitern> omw
<mup> Bug #1596597 changed: JUJU Beta 10 VLAN config in ENI not adding 'auto iface' <network> <juju-core:Invalid by frobware> <https://launchpad.net/bugs/1596597>
<mup> Bug #1599886 opened: apt-mirror does not override security.ubuntu.com <juju-core:New> <https://launchpad.net/bugs/1599886>
<cherylj> katco: ping?
<katco> cherylj: hey pong... have a meeting in 10
<cherylj> katco: k, will find some time on your calendar for later
<katco> cherylj: sounds good!
<babbageclunk> Hey katco, thanks for your reviews - still working through them, but can you look at my changes on http://reviews.vapour.ws/r/5209 when you get a chance?
<katco> babbageclunk: sure thing
<babbageclunk> Also, do you think I could use unicode â¦ instead of ...?
<babbageclunk> katco: cheers!
<katco> babbageclunk: just responded about that :)
<frobware> babbageclunk: keep it simple, IMO.
<babbageclunk> katco, frobware: yeah, I thought so - figured I'd check just in case.
<katco> babbageclunk: did you rebase this or something? i think i see the sorter creeping in from the other PR?
<babbageclunk> Oops - might have used the wrong parent branch - this one's chained off another one. Sorry, will fix.
<katco> cherylj: no one came for the standup if you want to meet now
<babbageclunk> katco: sorry - if you want to see the change from when you reviewed it before compare revisions 2 and 4. Is there a better way to do this than push and then use rbt to determine the parent branch?
<katco> babbageclunk: mmm... if there is it's probably not worth it. there might be something with rbt you could do
<katco> babbageclunk: lgtm. thanks for all the prs
<babbageclunk> katco: :)
<cherylj> hey katco - can you still meet now?
<katco> cherylj: sure
<katco> cherylj: hey while you're in there, can you remove the panic @152?
<cherylj> oh yes
<cherylj> panics are evil
<cherylj> I will gladly remove one
<katco> cherylj: they're not evil, they're just misunderstood :)
<cherylj> lol
<katco> cherylj: plot twist: this bug is being caused by that panic being handled somewhere silently
<cherylj> urg
<cherylj> that would be awful
<cherylj> katco: could you take a look at this question?  https://bugs.launchpad.net/juju-core/+bug/1597941/comments/4
<mup> Bug #1597941: juju2.0beta10: websockets API usability Application Deploy failure to inform of required addCharm pre-requisite <2.0> <conjure> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1597941>
<cherylj> I was just the messenger :/
<katco> cherylj: i have no idea why it was deprecated unfortunately. do you know who did that work?
<mup> Bug #1596597 opened: JUJU Beta 10 VLAN config in ENI not adding 'auto iface' <network> <juju-core:Incomplete by frobware> <https://launchpad.net/bugs/1596597>
<mup> Bug #1599905 opened: rfc5424 standard has a non-free license <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1599905>
<cherylj> katco: no clue :(  It was just a message I relayed from Alexis
<cherylj> Maybe thumper / wallyworld will know
<cherylj> I can send them an email
<mup> Bug #1599972 opened: juju2 beta11 unable to parse PORT during a maas bootstrap <conjure> <juju-core:New> <https://launchpad.net/bugs/1599972>
<mup> Bug #1586116 changed: GCE bootstraps but fails to provision <gce-provider> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1586116>
 * redir made it home
<mup> Bug #1600054 opened: Running generate-image twice with separate virt-types overwrites rather than appends <v-pil> <juju-core:New> <https://launchpad.net/bugs/1600054>
#juju-dev 2016-07-08
<mup> Bug #1600061 opened: Expect multi-region MAAS clouds <juju-core:New> <https://launchpad.net/bugs/1600061>
<mup> Bug #1600063 opened: Remove the local: from cloud listing <juju-core:New> <https://launchpad.net/bugs/1600063>
<mup> Bug #1587739 changed: rackspace,vsphere: firewalling in HA setup is broken <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1587739>
<mup> Bug #1587739 opened: rackspace,vsphere: firewalling in HA setup is broken <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1587739>
<mup> Bug #1587739 changed: rackspace,vsphere: firewalling in HA setup is broken <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1587739>
<babbageclunk> hey dimitern, could you take another look at http://reviews.vapour.ws/r/5161/ please?
<dimitern> babbageclunk, dooferlad: a tiny review fixing bug 1598164 - http://reviews.vapour.ws/r/5215/) please, take a look
<mup> Bug #1598164: [aws] adding a machine post-bootstrap on the controller model closes of api port in controller security group <add-machine> <addressability> <ec2-provider> <tech-debt> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1598164>
<dimitern> babbageclunk: *click*
<babbageclunk> dimitern: ha ha, swap you - looking now
<dimitern> babbageclunk: have you seen such an elaborate explanation for a 2 line fix? :D
<dimitern> babbageclunk: ha, that looks familiar ;) I'll give it a manual test now
<babbageclunk> dimitern: quite a twisty tale!
<dimitern> babbageclunk: yeah, one of those you tell over campfire at night LOL
 * babbageclunk waves. :(
<dimitern> babbageclunk: I meant mine :)
<babbageclunk> dimitern: Yeah, that's what I was talking about too!
<dimitern> babbageclunk: however reading fwereade's comments it seems we don't need the hook tool at all?
<babbageclunk> dimitern: yours LGTM
<dimitern> babbageclunk: ta!
<babbageclunk> dimitern: Only the get one - we still need the set.
<dimitern> babbageclunk: ah, now it makes more sense, yeah
<dimitern> babbageclunk: got a link to that modified postgresql charm?
<babbageclunk> dimitern: Hmm, no - I could push it somewhere.
<babbageclunk> dimitern: But would you be happy enough with `juju run --unit blah/0 "application-version-set yay"`?
<dooferlad> dimitern, babbageclunk: http://reviews.vapour.ws/r/5213/ and http://reviews.vapour.ws/r/5214/ are both small and high impact if you could take a look
<dimitern> dooferlad: certainly, adding them to my list
<babbageclunk> dooferlad: Think I can do them both in 2 mins?
<dimitern> babbageclunk: ok, so should work with an unmodified ubuntu charm then?
<dooferlad> babbageclunk: probably
<babbageclunk> dimitern: yup
<dimitern> dooferlad: oh alright :)
<dimitern> dooferlad: I'll swap those 2 for my tiny one
<dooferlad> dimitern: you are on
<babbageclunk> dimitern: I can quickly fork and push the charm anyway - it's nicer to see it working properly.
<dimitern> dooferlad: http://reviews.vapour.ws/r/5215/
<babbageclunk> dimitern's one is small but perfectly formed
<dimitern> babbageclunk: that's better - it makes it reusable for CI as well
<babbageclunk> dimitern: ok
<babbageclunk> anyway, lets talk about this in video!
<babbageclunk> *let's
<dimitern> babbageclunk: beware though, if you haven't used the charm tools before to publish a charm, you'll need to both push it on LP and then grant everyone read access, otherwise only you'll see it on jujucharms.com/u/babbageclunk
<dimitern> omw
<dimitern> babbageclunk: ping
<babbageclunk> dimitern: hi
<babbageclunk> dimitern: ?
<dimitern> babbageclunk: I'm trying to live test your branch
<dimitern> babbageclunk: on lxd I deployed 3 ubuntu units and tried juju run --unit ubuntu/X -- 'application-version-set Y'
<babbageclunk> dimitern: ok
<dimitern> babbageclunk: should I be seeing what I set somewhere? I can't..
<babbageclunk> dimitern: There's another change to add version to the tabular status, but it's not landed. Can you see it on juju status --format yaml?
<dimitern> babbageclunk: ah, yeah - I can see it now, sorry
<babbageclunk> dimitern: awesome
<babbageclunk> dimitern: Just working out how to create (the equivalent of) a pull request on bzr+launchpad.
<dimitern> babbageclunk: you can just push a local bzr branch to lp:~user/+junk/name IIRC
<dimitern> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
<babbageclunk> dimitern: thanks
<mup> Bug #1600221 opened: "juju ssh" et al. should recommend add-ssh-key on auth failure <juju-core:Triaged> <https://launchpad.net/bugs/1600221>
<mup> Bug #1598358 opened: [juju beta10] With MAAS, node allocated but never told to deploy. <oil> <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1598358>
<mup> Bug #1600237 opened: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys <juju-ci-tools:New> <juju-core:New> <https://launchpad.net/bugs/1600237>
<mup> Bug #1600237 changed: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys <juju-ci-tools:New> <juju-core:New> <https://launchpad.net/bugs/1600237>
<mup> Bug #1600237 opened: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys <juju-ci-tools:New> <juju-core:New> <https://launchpad.net/bugs/1600237>
<mup> Bug #1600257 opened: The tab completion on juju yeilds KeyError: 'services' <juju-core:New> <https://launchpad.net/bugs/1600257>
<mbruzek> Hello balloons can I bother you for a minute?
<mbruzek> balloons: Do you know where the tab completion code is for Juju? Regarding: https://bugs.launchpad.net/juju-core/+bug/1600257
<mup> Bug #1600257: The tab completion on juju yeilds KeyError: 'services' <juju-core:New> <https://launchpad.net/bugs/1600257>
<balloons> mbruzek, yes I know where the code is
<mbruzek> balloons: I found it in etc/bash_completion.d/
<balloons> mbruzek, that's an interesting bug. Right, that's the installed location
<balloons> mbruzek, it stems from https://github.com/juju/juju/tree/41eb73708fa1f86c337cf60d10c2c9f3b2b004f7/etc/bash_completion.d
<balloons> you should be able to propose any fixes against one of those files
<mbruzek> balloons: This is strange. I see the bash_completion file in juju-core (master) does not contain the word "services" but the one on my system does.
<mbruzek> balloons: Perhaps it is resolved and just not released in beta11 yet?
<babbageclunk> mbruzek: I think I was talking to you in the wrong channel :)
<babbageclunk> mbruzek: or is your problem that installing the newer beta doesn't update the completions?
<mbruzek> babbageclunk: I just wanted to help fix this problem, but it looks OK in master
<babbageclunk> mbruzek: Yeah, I tried the same thing a little while ago and realised it was already fixed. :)
<mbruzek> great
<mbruzek> I will stand down.
<balloons> I'm curious why you aren't seeing the fix in beta11
<mbruzek> babbageclunk: I see 3 files in /etc/bash_completion.d/ juju2, juju-core, and juju-core2. I don't see the corresponding files in the code tree in github. There must be some rule to copy those?
<balloons> my expectation was it would be there
<balloons> mbruzek, yes the packaging code lives in a bzr brnach
<mbruzek> http://pastebin.ubuntu.com/18798379/
<babbageclunk> mbruzek: Hmm - maybe the wrong one is being found? Possibly one of them was renamed at some point, and so the old file has been orphaned in bash_completion.d?
<mbruzek> babbageclunk: I just compared the three files, the only difference is juju-core2 has #!/bin/bash on line 1
<babbageclunk> mbruzek: but they all still refer to services?
<babbageclunk> mbruzek: This is in /etc/bash_completion.d?
<mbruzek> babbageclunk: Yes, and I see the file in master does not have any references to "services"
<mbruzek> babbageclunk: Correct on my system, xenial 16.04
<babbageclunk> mbruzek: Do you install juju from ppa, or are you building it yourself?
<mbruzek> ppa
<babbageclunk> Ok, in that case it sounds like there is still a bug with how the installer sets up completions.
<babbageclunk> When you got beta11 it should have included updating the bash_completion.d files.
<balloons> http://bazaar.launchpad.net/~juju-qa/juju-release-tools/packaging-juju2-default/view/head:/debian/rules
<jcastro> I still don't have working completion
<balloons> I touched those rules last :-)
<mbruzek> babbageclunk:  ballooons:  Could you point me to the packaging branch on bzr so I could have a look?
<mup> Bug # opened: 1600296, 1600300, 1600301, 1600302
<mbruzek> ahh I see the link above
<jcastro> fyi I just reinstalled juju-2.0 from the ppa in xenial and I don't have anything juju related in /etc/bash_completion.d
<mbruzek> Line 52 installs the file to /usr/share/bash-completion/completions/ but I was checking /etc/bash_completion.d/ directory.
<mbruzek> I checked my system, I have juju-2.0 and juju-version in /usr/share/bash-completion/completions/
<babbageclunk> Weird. I've got working completion, but mine's built from source and is installed from the makefile target (install-etc) whicn puts the files in /etc/bash_completion.d
<balloons> mbruzek, if you have the files in the right place, sourcing the directory should make tab completion work
<mbruzek> balloons: is it possible this file used to install in /etc/bash_completion.d/ directory ? I may have old ones left over, but it seems to be favoring the /etc/bash_completion.d/ directory rather than the one in /usr/share/bash-completion/completions/
<balloons> mbruzek, it has changed a bit -- both the location and file name -- and the fact there are 2 files now
<mbruzek> http://bazaar.launchpad.net/~juju-qa/juju-release-tools/packaging-juju2-default/revision/127
<mbruzek> balloons: What should be done about the old files? I have juju2 and juju-core and juju-core2 which all appear to be the same file. Should the packaging clean up the old ones? Or is that an exercise left to the user?
<mup> Bug #1600311 opened: Juju 2.0 Bootstrap Fails on Ubuntu Trusty Power machine. <juju-core:New> <https://launchpad.net/bugs/1600311>
<balloons> mgz, opinions on old files ^^?
<mgz> ...dpkg should handle it
<balloons> mbruzek, for the ppa stuff, I would generally say it's just life. However for the archive, we shouldn't be leaving a mess. And since we depend on the ppa so heavily an argument could be made there as well to hold oneself to a higher standard.
<mgz> mbruzek: which packages own which files?
<mbruzek> mgz how can I tell that?
<mbruzek> I just updated the bug: https://bugs.launchpad.net/juju-core/+bug/1600257
<mup> Bug #1600257: The tab completion on juju yeilds KeyError: 'services' <juju-core:New> <https://launchpad.net/bugs/1600257>
<mbruzek> It seems like my system favors the files in /etc/bash_completion.d/
<balloons> mbruzek, you can use apt-file to check
<mgz> mbruzek: `dpkg -S completions/juju` or similar
<mgz> whatver the new dir we put it in is called
<mgz> mbruzek: `dpkg -S bash_completion.d/juju` for the old location as you seem to have those
<mbruzek> mgz: http://pastebin.ubuntu.com/18804873/
<mgz> balloons: did we not make a conflicts/replaces on juju-core2?
<mgz> we want juju2 and juju-core2 deaded if any new packages are installed
<balloons> mgz, my concern above came from the fact we have the ppa packaging and the archive packaging
<mbruzek> http://pastebin.ubuntu.com/18805007/
<mgz> juju-core2 is superdead though right?
<mbruzek> That now includes the new files.
<mgz> mbruzek: yeah, so it's a bad mix of ppa and archive
<mgz> mbruzek: we should do a better job of sanity
<mgz> mbruzek: I'd appreciate a bug against juju ini ubuntu for this
<mgz> -ini+in
<mbruzek> mgz: OK. I am happy to help, is my juju-core bug not sufficient? You want me to open this on ubuntu?
<mgz> mbruzek: oh, you had one?
<mbruzek> https://launchpad.net/bugs/1600257
<mup> Bug #1600257: The tab completion on juju yeilds KeyError: 'services' <juju-core:New> <https://launchpad.net/bugs/1600257>
<mgz> that's fine, I shall just also affects distro/package to it
<mgz> and you misspelt yields :P
<balloons> and yea juju-core2 is super dead
<balloons> but clearly still lives!
<mbruzek> ack
<mbruzek> balloons: I think all three files in /etc/bash_completion.d/ are "dead" from what I read in the current packaging
<mgz> mbruzek: that should be correct
<mgz> mbruzek: if you purge juju2 and juju-core2 do you still see the symptom?
<mgz> mbruzek: thanks for poking this
<mbruzek> Glad to help and if there is some code that needs to change I can sling some bash
<mbruzek> mgz: I will delete the files after my standup.
<mbruzek> eta 10 mins
<mgz> mbruzek: aha, now that's an offer
<mbruzek> mgz: I was digging into this because I thought it was something I could fix
<mbruzek> mgz: It *is* but I don't know if you or balloons will let me fix it
<mbruzek> trust is earned, not sure if I have achieved it yet.
<balloons> I would happily let someone unleash magic on bash completion. I've got it working on my box, but it hasn't translated to others.
<mbruzek> mgz: balloons: I am done with meeting. I can purge the files in /etc/bash_completion.d/ now. Any objections? Is there anything else you want to see before I do that?
<mgz> mbruzek: nope, go for it
<mbruzek> Done. mgz: I have new information. My old terminals still get the Traceback, and a new terminal does not tab complete.
<mbruzek> I understand why on the old terminals, but thew new on does not seem to be getting the new /usr/share/bash_completion/completions directory
<mgz> okay, so we're back to the mystery of why some systems don't do anything with the file we add to the completions dir
<mgz> mbruzek: hack-copy it to the old /etc location and see if that then completes in a new term? my guess is it will
<mbruzek> mgz: Correct that works in my system.
<mgz> okay, well I wish this stuff was documented like... anywhere
<mbruzek> mgz: My system was 15.04 and was upgraded to xenial 16.04 . Would that have anything to do with this?
<mbruzek> I tried to trace this from .bashrc to /usr/share/bash-completion/bash_completion let me inspect bash_completion more closely
<mgz> mbruzek: it may, but really the upgrade should be transparent
<mbruzek> mgz: I only mentioned that because the configuration files may have been from the old system, I think 15.04 was systemd also
<mgz> yeah, and the defaulting to the old location makes more sense for a post-upgrade system
<mbruzek> mgz: /usr/share/bash-completion/bash_completion
<mbruzek> mgz: http://paste.ubuntu.com/18808058/
<mbruzek> Can you compare that against your file? I see on line 43 it sets the backwards compat completion dir.
<mgz> mbruzek: yeah, same on a fresh xenial system (and in fact on trusty), all claim RELEASE: 2.1
<mgz> just having the concept of a compat dir is no problem provided it does actually look in the new place
<mbruzek> mgz: I was not able to get tab completion when only juju-2.0 was in the new location...
<mgz> mbruzek: on either juju<TAB> or juju-2.0<TAB> right? that's what's we've had reported before
<mbruzek> mgz: Actually it was "juju ssh kuber<TAB>"
<mgz> I'm not sure how we're meant to register completions under the new scheme, what we're doing (sticking in dir) doesn't seem enough
<mbruzek> so it is using the ssh completion,
<mbruzek> I can try juju-2.0 ssh kuber<TAB> if you like
<mgz> yeah, I expect it's the same as would be juju s<TAB> but...
<mbruzek> mgz: I am seeing a very strange behavior. I can do "juju-2.0 ssh kuber<TAB>" and THEN "juju ssh kuber<TAB>".  HOWEVER, if I start a new terminal "juju ssh kuber<TAB>" that does not work until I try juju-2.0
<mgz> okay, well that seems like fun
<mbruzek> mgz: My current theory is "juju" does not alias to "juju-2.0" (which is the name of the completions file) until I use juju-2.0 first.
<mgz> that does seem likely
<mbruzek> let me symlink juju -> juju-2.0 and see if that helps
<mgz> mbruzek: new thing to try, move the file in completions/ dir to 'juju' and see if new terminal then lets you juju s<TAB> immediately
<mbruzek> bingo!
<mbruzek> mgz: The symbolic link worked?
<mgz> okay, so the fancy mechanism does only load files based on the root path, then once it's loaded everything works
<mgz> so... humph
<mbruzek> ! I meant the punctuation !
<mgz> interrobang
<mbruzek> mgz: Do you agree with the symbolic link fix? Or would the name "juju" collide with the 1.25 version in packaging?
<mbruzek> mgz: and or balloons: Here is my solution for your consideration:  https://code.launchpad.net/~mbruzek/juju-release-tools/packaging-juju2-default/+merge/299600
<mgz> mbruzek: well, I guess the issue is are we okay with the script being executed twice
<mgz> under different names
<balloons> mbruzek, whoa that MP is insane.. target is off :-)
<balloons> so mbruzek, the file needs to be named juju right? And it works with 1.x and 2.x?
<balloons> if yes, we should change the upstream sourcew
<mbruzek> balloons: I didn't test this with juju 1.x
<mbruzek> balloons: what should the target be?
<balloons> it needs to work with both
<balloons> or perhaps better said; we need tab completion for both, and any change cannot break either
<mbruzek> balloons: agreed...
<mbruzek> balloons: perhaps we need to do further investigation into why juju-2.0 is not loading for "juju ssh kuber<TAB>"
#juju-dev 2016-07-09
<mup> Bug #1600404 opened: virt-type constraint for openstack provider is ignored <v-pil> <juju-core:New> <https://launchpad.net/bugs/1600404>
<mup> Bug #1600404 changed: virt-type constraint for openstack provider is ignored <v-pil> <juju-core:New> <https://launchpad.net/bugs/1600404>
<mup> Bug #1600404 opened: virt-type constraint for openstack provider is ignored <v-pil> <juju-core:New> <https://launchpad.net/bugs/1600404>
<mup> Bug #1600453 opened: Show controller instances in 'juju controllers' <juju-core:New> <https://launchpad.net/bugs/1600453>
<mup> Bug #1600515 opened: Clean up bootstrap message for 2.0 <juju-core:New> <https://launchpad.net/bugs/1600515>
<mup> Bug #1600523 opened: Support controller: instead of -c controller for commands <juju-core:New> <https://launchpad.net/bugs/1600523>
#juju-dev 2016-07-10
<mup> Bug #1600539 opened: diskmanager block device list should be sorted to avoid continual "block devices changed"  <sts> <juju-core:New> <https://launchpad.net/bugs/1600539>
<mup> Bug #1600546 opened: lxd subnet setup by juju will interfere with openstack instance traffic <sts> <juju-core:New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>
<mup> Bug #1532186 changed: lxd container creation fails semi - regularly <2.0-count> <juju-release-support> <lxc> <juju-core:Expired> <https://launchpad.net/bugs/1532186>
<mup> Bug #1600559 opened: agents should ignore invalid API host ports response <addressability> <agent> <api> <juju-core:Triaged> <https://launchpad.net/bugs/1600559>
<mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:New> <https://launchpad.net/bugs/1600600>
<axw> wallyworld: heya. I did initially remove authorized-keys from FakeConfig, but it broke too many things. lots of tests use that to pass into Bootstrap, which still requires it
<wallyworld> yeah, was afraid that may be the case
<axw> the fact that so many tests use Bootstrap is an ongoing problem :(
<axw> wallyworld: ok for me to drop?
<wallyworld> sure
 * redir has landed at gophercon
<redir> off to register.
#juju-dev 2017-07-03
<axw> thumper: hey, FYI I'm online today - taking tomorrow off instead
<babbageclunk> axw: standup then? ;)
<axw> babbageclunk: oh sorry! I didn't know you were on today
<axw> babbageclunk: I'm here if you really do want to standup, but for me it's just: working on upgrades
<babbageclunk> axw: :) externalreality and I had a brief chat, but no need - I'm chasing a bug with my sub-sub relation thing and he's working on getting details of run actions earlier to determine whether to take the machine lock.
<axw> babbageclunk: okey dokey, thanks
<thumper> menn0: is there a way to force a mongo election between peers?
<menn0> thumper: you can be fiddling with the member priorities
<thumper>  https://bugs.launchpad.net/juju/+bug/1701275
<mup> Bug #1701275: [2.2.1] juju-agent loses connection to controller and doesn't retry to connect <cpe> <cpe-sa> <juju:Triaged> <https://launchpad.net/bugs/1701275>
<thumper> looks like the agents disconnect during an election
<thumper> and don't reconnect
<menn0> thumper: we've seen that occasionally. it seems like a dep engine bug to me.
<thumper> yeah...
<thumper> we saw that on the customer site too
<menn0> thumper: the dep engine stops trying after a while
<thumper> where agents had disconnected
<thumper> and didn't reconnect
<menn0> thumper: perhaps due to manifold returning the wrong thing
<thumper> not sure...
<thumper> I may read through the dep engine code and see if anything leaps out
<menn0> thumper: I have some old logs from jam for a system he had where it happened
<menn0> on his machine
<thumper> hmm...
<menn0> thumper: do you have the tail end of the logs for an agent that got "stuck"
<menn0> ?
<thumper> not off hand
<thumper> they are all in warning+ mode
<axw> thumper: 1:1?
<menn0> babbageclunk: I'm seeing failures in TestSplitLogsCollection. Looks like the bit that looks for the "ns not found" error isn't working on my machine for some reason
<menn0> babbageclunk: is this a known thing?
<babbageclunk> menn0: not by me!
<menn0> babbageclunk: the QueryError Code is coming back as 0 despite the message being the expected "ns found found"
<babbageclunk> menn0: maybe a mongo version difference?
<menn0> babbageclunk: must be, although I can see that the tests are using our officially packaged mongodb 3.2 package
<menn0> babbageclunk: should we be worried that this is in a released version?
<menn0> (I don't know if it is)
<babbageclunk> It definitely is - it was done for 2.2.0, I think.
<babbageclunk> menn0: is it failing consistently for you?
<menn0> babbageclunk: yes
<menn0> babbageclunk: I have a fix which uses the error code /or/ the message
<menn0> babbageclunk: looks like this is in 2.2
<babbageclunk> menn0: So is my machine using the wrong mongo version for tests?
<menn0> babbageclunk: possibly. there's a number of fallbacks
<menn0> babbageclunk: run the state tests and do: ps ax | grep mongo
<babbageclunk> It's using the juju-mongo32 mongod - that reports that it's 3.2.12
<menn0> babbageclunk: hmmm same for me
<menn0> how strange
<babbageclunk> menn0: hmm
<babbageclunk> git version ef3e1bc78e997f0d9f22f45aeb1d8e3b6ac14a14 (just in case)
<babbageclunk> menn0: so, that's weird. Different versions of mgo?
<menn0> babbageclunk: i'm at f2b6f6c
<babbageclunk> menn0: I'm working on a branch off 2.2 at the moment
<babbageclunk> menn0: same git hash for mgo
<babbageclunk> curiouser and curiouser
<menn0> babbageclunk: hang on... I may have been running the tests remotely on a different machine
 * menn0 checks
<menn0> babbageclunk: i've got it
<menn0> babbageclunk: it's my "workhorse" machine
<babbageclunk> menn0: And what's that running?
<menn0> babbageclunk: the official mongo 3.2 it would appear :/
<menn0> babbageclunk: but that's where it's failing
<menn0> i'll dig some more
<babbageclunk> ok
<menn0> babbageclunk: this machine has mongodb 3.2, 2.6 and 2.4 installed
<babbageclunk> menn0: Which one's the test picking?
<menn0> babbageclunk: still trying to figure that out
<menn0> babbageclunk: it's 2.6.10
<menn0> babbageclunk: which is odd given the test code is supposed to prefer the 3.2 installation
<menn0> babbageclunk: the problem with this upgrade step will be that it could fail on trusty controllers
<menn0> which still use 2.4 IIRC
<babbageclunk> menn0: But that's only a problem if we were upgrading controllers to 2 from 1.25 in-place, isn't it?
<menn0> babbageclunk: no
<menn0> babbageclunk: if you bootstrap a 2.x controller on trusty I believe it still uses mongo 2.4
<babbageclunk> menn0: Ah, right
<babbageclunk> menn0: Wouldn't that be a pretty odd thing to do?
<babbageclunk> menn0: I guess we support it though.
<menn0> babbageclunk: yes, unless you wanted to run some trusty only charms on the controller
<thumper> menn0: so ideas on forcing a leader election in mongo without restarting juju?
<babbageclunk> menn0: It sounds like your fix will correct it anyway.
<menn0> babbageclunk: yes it will but it's already in 2.2.1
<menn0> babbageclunk: I guess it only fails the second time the upgrade step is attempted. is that right?
<babbageclunk> menn0: oh, right - because the first time the logs collection is there?
<thumper> axw: did you say that the metrics gathering now all uses the state pool?
<thumper> axw: in 2.2?
<axw> thumper: on the 2.2 branch, yes. the second fix I was talking about landed last week
<thumper> axw: cool. I'll see if that fixes my issue here
<menn0> thumper: connect using the mongo shell and give the current leader a priority of 0
<menn0> thumper: rs.conf() show the current configuration
<thumper> I'm thinking of writing a 'juju-fetch' plugin that just does 'git fetch'
<menn0> thumper: this is helpful: https://docs.mongodb.com/manual/tutorial/force-member-to-be-primary/
<thumper> menn0: thanks
<menn0> babbageclunk: so the chances of hitting the problem are fairly slim but not 0. a re-run of the upgrade step could happen when any upgrade step fails and the upgrade is retried.
<menn0> babbageclunk: i'll file a bug and get the fix in
<menn0> babbageclunk: i've confirmed it works for 2.4
<menn0> babbageclunk: I didn't even know you had done this work to split out log collections :)
<babbageclunk> menn0: You mean if another upgrade step fails after this one succeeds, right? I did the state work, thumper did the upgrade step.
<menn0> babbageclunk: I should have known :)
<menn0> babbageclunk: just to be sure, I just confirmed that we still use 2.4 on trusty
<babbageclunk> menn0: nice one.
<menn0> babbageclunk or thumper: https://github.com/juju/juju/pull/7588
<babbageclunk> menn0: looking
<thumper> menn0: so... I got that logs deserialization error
<thumper> went and looked in the DB
<thumper> there is no entry with a missing TAG
<thumper> so...
<thumper> it looks like the oplog tailer is returning an empty value sometimes
<thumper> when it shouldn't
<menn0> thumper: were you looking for docs with an empty tag, or a missing tag?
<thumper> ah... empty
<thumper> how do I say missing?
<thumper> nm
<menn0> thumper: https://stackoverflow.com/questions/8567469/mongodb-find-a-document-by-non-existence-of-a-field
<thumper> db.logs["ac97e810-63f3-49b1-89dd-ea7f32e6e5d4"].find({n:{$exists:false}}).count()
<thumper> 0
<thumper> neither empty nor missing
<thumper> menn0: the error is being emitted every five minutes
<thumper> seems very exact
<menn0> thumper: it could also be that the field is the wrong type, so that it gets deserialised to "" because the db type doesn't match the struct type
<menn0> thumper: where is the error being emitted?
<menn0> thumper: when deal with broken txn metadata i've seen fields with nil values that are confusingly deserialised
<thumper> menn0: db.logs["ac97e810-63f3-49b1-89dd-ea7f32e6e5d4"].find({n:{$not: {$type: "string"}}}).count()
<thumper> 0
<thumper> not not a string either
<thumper> menn0: the error is emitted in the controller model, which happens to be the one I'm tailing
<menn0> thumper: nice query
<thumper> I recall the oplog query code has a reconnect on timeout
<thumper> I'm wondering if that is emitting something bad by mistake
<thumper> it goes back to look for values of the current time slice
<thumper> but what if the logs are quiet
<thumper> and there isn't one?
<thumper> perhaps that's the use case
<menn0> thumper: that seems likely
 * menn0 looks at the code
 * thumper goes back to finding his other bug
<menn0> thumper: seems the default cursor timeout is 10mins
<thumper> this is happening every 5 minutes on the nose
<menn0> thumper: i'm seeing other sources which say 5 mins
<menn0> digging
 * thumper is getting a bunch of unit agents connected before he forces a mongo election
<menn0> thumper: so it turns out the oplog tailer uses a timeout of 1s so that it can be interrupted
<menn0> thumper: but there's also the concept of cursor invalidation and we might be running into that
<thumper> hmm..
<menn0> thumper: i've added logging and have left debug-log running
<thumper> I'm curious to see if you see the same error message every 5m
<menn0> what does the message look like?
<menn0> thumper: ^^
<thumper> machine-1: 17:29:11 WARNING juju.state deserialization failed (possible DB corruption), while parsing entity tag: "" is not a valid tag
<thumper> I'm trying option two
<thumper> stopping all api server agents
<thumper> while leaving all unit agents running
<thumper> will go away for a few hours
<thumper> and bring them up again
<thumper> that seems to mirror some of the failure cases
<thumper> back later folks
<babbageclunk> thumper: 1:1? (Sorry, was slow to see the reminder)
<thumper> coming
#juju-dev 2017-07-04
<babbageclunk> externalreality: around for standup?
<externalreality> babbageclunk, I sorry was in the kitchen and totally lost track.
<babbageclunk> externalreality: no worries, it was pretty low key.
<babbageclunk> externalreality: did you make progress on your action change?
<externalreality> babbageclunk, I was making track but @thumper gave me an idea that I hadn't thought of which makes the code a lot simpler.
<externalreality> Let the uniter grab the machine lock and then when it finds out that it doesn't need the lock, it simply releases it.
<externalreality> wtf didn't I think of that
<externalreality> I was attempting to restructure the code so that the uniter had knowledge of whether or not it needed the machine lock earlier
<externalreality> the former suggestion is indeed much easier and works well
<babbageclunk> externalreality: oh, nice
<babbageclunk> menn0, thumper: could someone take a look at this? https://github.com/juju/juju/pull/7590
<babbageclunk> It's not the full fix for the sub-sub thing, but it fixes the part that I broke in the first change.
 * babbageclunk goes for a run while it's nice and sunny.
<menn0> babbageclunk: looking
<babbageclunk> menn0: thanks!
<blahdeblah> Quick Q: If I run "juju config myapp --file path/to/myconfig.yaml" and myconfig.yaml only contains values for 1 config option and myapp has 10, will it wipe out the other 9, or just ignore them and set the 1?
<blahdeblah> The docs on this aren't clear
<menn0> blahdeblah: it just updates the configuration mentioned in the yaml file
<menn0> blahdeblah: the others are left alone
<menn0> I just tried it to be sure
<blahdeblah> sweet - thanks menn0
<menn0> babbageclunk: done
<babbageclunk> menn0: cheers
<babbageclunk> menn0: damn, I meant to have a discussion about whether we should be squashing commits before merging at the sprint. Do you know whether there's a consensus there?
<menn0> babbageclunk: I'm pretty sure there will be widespread disagreement
<babbageclunk> :(
<menn0> babbageclunk: FWIW, I prefer a small number of logic commits per PR (something like 1 to 5), where each has a proper commit message
<menn0> logical
<menn0> I tend to do some squashing and commit message rewording before proposing a PR
<menn0> my pet hate is seeing stupid commit messages that just say "now works" or "addressed review comments". it really sucks when you run into them while trying to diagnose an issue.
<babbageclunk> menn0: I tend not to do the squashing until after review - otherwise you sometimes get someone saying "actually, could you split that one change out into a separate PR" and find that you've already squashed it.
<mup> Bug #1702236 opened: Juju 1.25.10 is running hooks prior to additional network interfaces being up <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1702236>
<babbageclunk> Morning everyone!
<thumper> morning]
<babbageclunk> menn0, thumper: I felt bad about skipping a flaky test so I fixed another one: https://github.com/juju/juju/pull/7596
#juju-dev 2017-07-05
<blahdeblah> Morning!  Any update on 2.2.2 release date?
<axw> burton-aus externalreality: standup?
<burton-aus> axw just in
<axw> thumper: what are the blockers for 2.2.2? I think #1700451 should be
<mup> Bug #1700451: Upgrade from 2.1.x to 2.2.1 blocked by missing Azure resources <canonical-is> <upgrade-juju> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1700451>
<axw> oh maybe there's tags...
<axw> hm nope
<babbageclunk> blahdeblah: not sure - thumper?
<axw> babbageclunk: I don't understand why you've used that expression for the wait time in WaitAdvance. why not just use coretesting.ShortWait?
<babbageclunk> axw: Hmm, I thought I had tried it but now I'm not sure. Hang on, I'm trying it again now.
<axw> babbageclunk: that test was already pretty confusing
<babbageclunk> axw: yeah - I tried rewriting it to be simpler, but it needs a test clock to be advanced (and so a goroutine) otherwise it just hangs.
<axw> babbageclunk: I think we want to: WaitAdvance(<10ms, coretesting.ShortWait, 1), then show that listener.count is still zero, then WaitAdvance(enough-to-reach-10ms, coretesting.LongWait, 1)
<axw> babbageclunk: there's a testing.AutoAdvancingClock that you could use, but it'll involve rewriting all the tests in that file to pass in a clock to testListener I think... or using an auto advancing clock in all the tests, which might not be better
<axw> it starts getting a bit too closely tied to the implementation tho
<babbageclunk> axw: Oh, just reread your question - I thought you were talking about the first argument to WaitAdvance, but you were talking about the second argument? The amount to advance the clock?
<axw> babbageclunk: yes
<axw> babbageclunk: no wait...
<axw> babbageclunk: the amount of wall clock time to wait
<babbageclunk> axw: ok, right.
<axw> babbageclunk: (in the inner loop of WaitAvance)
<babbageclunk> I'll try what you're suggesting.
<babbageclunk> axw: No, if we advance the clock by short wait, it's over the min pause threshold, so there's a chance that the pause will complete, and the test fails with "pause returned too soon"
<axw> babbageclunk: I don't understand that - teh amount of time waited by WaitAdvance is independent of the amount advanced?
<babbageclunk> yes
<babbageclunk> the first's wallclock time, the second is simulated time.
<babbageclunk> They're two independent but confusing axes.
<axw> babbageclunk: isn't it the other way around? https://github.com/juju/testing/blob/master/clock.go#L118  -- d is first, which is the amount of time we advance the clock (simulated time)
<babbageclunk> axw: Gah, you're right! I had misread that.
<axw> babbageclunk: :)  I always have to check the order, never can remember
<thumper> hey
 * thumper looks
<babbageclunk> axw: That's why the results were so confusing when I was doing it. Ok, your way makes sense then. Trying it now.
<thumper> axw: how is the separation of model upgrades from controller upgrades going?
<axw> thumper: the upgrade bits are separated, I'm onto the next bit, which is blocking logins to the models before they're upgraded
<thumper> axw: ok, cool
<axw> thumper: and I've hit a snag, need to synchronise the controllers. prob won't be done till tomorrow now
<thumper> axw: wouldn't it just be looking at the value in the model doc and blocking if not expected?
<axw> thumper: sorta. only one controller machine gets an Environ (singular worker), so we either make them all get one, or use something other than the environ version to synchronise on. they all need to agree on a value to check for
<axw> thumper: I'm leaning towards the latter atm, to avoid unintended uses of environs in multiple controller machines
<thumper> axw: we are storing the environ version in the model doc though right? can't we synchronize on that?
<axw> thumper: yes, but only after they've upgraded, and the ones that don't have the Environ don't know what version it'll go to
<babbageclunk> axw: Thanks for the sanity checking! That is much clearer, I think.
<axw> thumper: and we have to block them all until the upgrades are done
<axw> babbageclunk: cool, np
<thumper> axw: hmm... so just need to work out what to sync on then...
<axw> thumper: I was just going to use the controller version
<thumper> couldn't there just be a registry of expected environ versions based on provider that the apiserver has?
<thumper> it won't change between controllers
<axw> thumper: yeah, could do. I could just make the EnvironProvider return the upgrade ops / version. I'll look into that
<thumper> as it will be fixed for any compiled code
<axw> thumper: that should work alright. that's the easy bit anyway :)
 * thumper nods
<axw> thumper: tech board?
<thumper> coming
<babbageclunk> thumper: If I want to add a new field to a uniter params struct, I guess that means adding a new version to the uniter API?
<babbageclunk> thumper: or can I get away without that?
<thumper> it depends
<thumper> I know that the pyjuju library before would have issues if we changed things
<babbageclunk> thumper: ok - I don't think it's hard to do anyway.
<babbageclunk> axw: updated that test fix. Take another look if you get a moment? https://github.com/juju/juju/pull/7596
<axw> babbageclunk: just saw, and LGTMd
<axw> babbageclunk: thanks
<babbageclunk> thanks!
<rogpeppe> jam: hiya
<rogpeppe> jam: there's a goose review here that you might want to take a look at https://github.com/go-goose/goose/pull/51
<jam> rogpeppe: looking
<rogpeppe> jam: thanks
<jam> rogpeppe: reviewed
<rogpeppe> jam: tyvm
<rogpeppe> jam: "I'm a little concerned that just dropping the ErrUnexpectedEOF may work for a particular client, but not for all."
<rogpeppe> jam: do you mean for a particular server there?
<rogpeppe> jam: BTW, do you know what version of Go we can assume for the swift code?
<jam> rogpeppe: so looking up an etag and getting a read seeker seemed disconnected, so it seemed like you could call one without having the other. Further, do all Openstack implementations that we operate against support ETAG?
<jam> rogpeppe: 'go version for swift code' ? Juju itself is I think 1.8 only now, are you wondering about other consumers of goose?
<rogpeppe> jam: yeah, i'm wondering about other goose consumers
<jam> rogpeppe: tbh I don't know other goose consumers. it isn't a project I've kept close ties with, or heard a lot of noise about people using it.
<rogpeppe> jam: i would hope that all Openstack implementations support Etag as the API is derived from S3 and that supports it (also, the API docs describe it and don't say it's optional)
<rogpeppe> jam: i suspect no-one else uses it. i'm going to assume Go1.8.
<rogpeppe> jam: i guess it depends what semantics we expect from a file that changes underfoot (if a server doesn't support Etag and If-Match). I think that getting an error when reading the file is probably OK.
<rogpeppe> jam: are you minded to approve the PR?
<rogpeppe> jam: FWIW I'm planning on waiting for jrwren to approve it because he was the one that wrote the ErrUnexpectedEOF logic and might have some info we don't
<rogpeppe> jam: here's another goose review for your delight and delectation - this one is a performance enhancement: https://github.com/go-goose/goose/pull/52
#juju-dev 2017-07-06
<axw> thumper: how'd last night go?
<thumper> axw: pretty good, all things considered
<thumper> just one small fubar, but audience didn't notice
<axw> thumper: cool :)
<axw> thumper: can you please take a look at https://github.com/juju/description/pull/16 again? updated to use an int now. and if you have time, https://github.com/juju/juju/pull/7599
<thumper> yep
<junaidali> :q
<blahdeblah>  /j #howdoiquitvim :-)
<junaidali> blahdeblah: lol, mosh was stuck
<thumper> babbageclunk: can I get you to take a look at axw's two PRs for upgrades?
<babbageclunk> thumper: sure
<babbageclunk> thumper: 7599 and 7602?
<thumper> yes
<thumper> babbageclunk, menn0, standup?
<babbageclunk> thumper: sorry
#juju-dev 2017-07-07
<babbageclunk> axw: reviewed #7599
<axw> babbageclunk: thanks
<babbageclunk> axw: Ooh, I hadn't seen how big #7602 was!
<axw> babbageclunk: sorry :( ignore the first commit. and I split it into multiple commits to help. I can split into multiple PRs if you like
<babbageclunk> axw: Thanks - I'll go by commit, that'll definitely help!
<babbageclunk> axw: yay, first two commits done already! :)
<axw> babbageclunk: :p
<babbageclunk> axw: (hmm, rereading, those exclamation points sound sarcastic but weren't meant to - the separate commits look much more manageable for reals.)
<axw> babbageclunk: no worries, I didn't read any sarcasm
<babbageclunk> good, just checking
 * babbageclunk goes for a wee run
<axw> babbageclunk: so it's https://bugs.launchpad.net/juju/+bug/1696509 that I'm picking up? what's the current status?
<mup> Bug #1696509: status-history-pruner fails under load <adrastea> <performance> <pruning> <statuseshistory> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1696509>
<axw> babbageclunk: oh I see you have a PR up, so I just need to test it?
<babbageclunk> axw: that's right - basically what I was planning to do was... actually, shall we do a hangout?
<axw> babbageclunk: okey dokey, see you in standuo
<axw> p
<axw> babbageclunk: a team
<blahdeblah> axw: Are the commits you recently made on https://bugs.launchpad.net/juju/+bug/1700451 a full fix or WIP?
<mup> Bug #1700451: Upgrade from 2.1.x to 2.2.1 blocked by missing Azure resources <canonical-is> <upgrade-juju> <juju:In Progress by axwalk> <https://launchpad.net/bugs/1700451>
<axw> blahdeblah: they're the full fix for 2.2.2, only part of it has landed though. the main commits are still being reviewed
<blahdeblah> cool - thanks
<blahdeblah> axw: But the plan is that they'll be included in 2.2.2?
<axw> blahdeblah: yes, definitely
<blahdeblah> awesome
<babbageclunk> axw: reviewed!
<axw> babbageclunk: tyvm
<axw> babbageclunk: I've got 10 agents pounding the controller with status updates, and it's not really making a dent in the status history. I think it'll be much quicker, and just as illustrative, to write a standalone benchmark program. sound reasonable to you?
<babbageclunk> axw: Do you mean something that just inserts lots of records into the DB directly?
<axw> babbageclunk: yep, then runs PruneStatusHistory
<babbageclunk> axw: I've done a bit of that already by increasing the number of rows the tests insert
<babbageclunk> axw: I think one of the main things jam was interested in was that the pruner is running in a realistic-ish context.
<babbageclunk> axw: What about something that just primes the status history with a lot of records, and then lets pruning run in the controller (with inserts happening around it)?
<axw> babbageclunk: can do.
<babbageclunk> axw: thanks man
<thumper> axw: do you remember how the juju log forwarding works?
<axw> thumper: from agents to controller, or from controller to syslog?
<thumper> the latter
<axw> thumper: only roughly, why?
<thumper> bug 1657724
<mup> Bug #1657724: Juju2 should have the option to feed logs into rsyslog <canonical-bootstack> <juju:New> <https://launchpad.net/bugs/1657724>
<thumper> I'm trying to see if it is documented in our docs anywhere
<axw> thumper: I'm hesitant to encourage its use, but I'll comment on the bug with the config needed
<thumper> yeah, I get that
<thumper> axw: perhaps say it is a relatively new feature with not a lot of robust testing
<thumper> and if they would like to help test, that'd be awesome :)
<axw> thumper: sure
<babbageclunk> menn0: still around? last minute quick review? https://github.com/juju/juju/pull/7604
<babbageclunk> axw: hmm, he might not be - could you take a look if you get a moment? ^
<axw> babbageclunk: yup
<babbageclunk> axw: ta
<axw> babbageclunk: LGTM. I have a branch which does a few more (namely DestroyModel), but it's in a messy state. will probably wait till after 2.2.2 now
<jamespage> hmm - anyone know when we might expect artful tools to appear in the streams for juju agent binaries?
<rogpeppe> jam: you might want to take a look at https://github.com/go-goose/goose/pull/53 which makes it more efficient for us to layer zip file (or other seek-requiring functionality) on top of swift: https://github.com/go-goose/goose/pull/53
<jam> rogpeppe: weekend for me today
<rogpeppe> jam: ah, ok, np
<wpk> $ juju add-subnet  --help
<wpk> Usage: juju add-subnet [options] <CIDR>|<provider-id> <space> [<zone1> <zone2> ...]
<wpk> (...)
<wpk> Details:
<wpk> (...) Unlike "juju add-subnet", this command does not create a new subnet, so it
<wpk> is supported on a wider variety of clouds (where SDN features are not
<wpk> available, e.g. MAAS).
<wpk> that doesn't sound right
#juju-dev 2017-07-08
<mup> Bug #1597318 changed: xenial containers on trusty host need lxc packages from trusty-backports <cdo-qa-blocker> <landscape> <sts> <juju:Invalid> <juju-core:Expired> <juju-core 1.25:Expired> <https://launchpad.net/bugs/1597318>
#juju-dev 2017-07-09
<mwhudson> axw: i see google people working on gollvm, wasn't that your baby originally?
#juju-dev 2018-07-05
<janiferge> juju status
<thumper> morning team
<thumper> ugh... wrong channel again
<hml> thumper: when will we remove this one?
<hml> when can I stop watching it?
<thumper> hml: you can stop watching it now
<thumper> very hard to stop IRC channels
#juju-dev 2018-07-06
<externalreality> Is there anyone about @ this (late?) hour to give a little charm v6 PR a look see:
<externalreality> https://github.com/juju/charm/pull/251
