#juju-dev 2013-01-07
<fwereade_> TheMue, heyhey
<fwereade_> TheMue, happy new year :)
<TheMue> fwereade_: Heyhey, good morning and a happy new year too :D
<rogpeppe> morning all
<fwereade_> rogpeppe, heyhey
<rogpeppe> fwereade_: yo!
<rogpeppe> fwereade_: how's tricks?
<fwereade_> rogpeppe, good thanks, and you? nice hols?
<rogpeppe> fwereade_: lovely thanks.
<rogpeppe> fwereade_: had a nice time playing with new camera...
<fwereade_> rogpeppe, I saw some of your photos, very nice indeed
<rogpeppe> fwereade_: they're even nicer in full resolution
<fwereade_> rogpeppe, I bet :)
<TheMue> rogpeppe: Heya
<rogpeppe> TheMue: hiya!
<rogpeppe> TheMue: good hols?
<TheMue> rogpeppe: The camera may be nice, but the distilleries on Skye would have interested me more. :D
<TheMue> rogpeppe: Yep, but too short. So 52 weeks per year would be fine. ;)
<rogpeppe> TheMue: there's only one distillery, and it's not so interesting after you've been around it a couple of times
<TheMue> rogpeppe: Only Talisker, thought there are more. Hmm, ok, good to know.
<TheMue> rogpeppe: I bought a new camera too, but a smaller one. The Panasonic LX7. It's fast and the lens is very light intense (do you say so?).
<rogpeppe> TheMue: i think we'd probably say the lens was fast.
<fwereade_> jam, thanks for the reviews :)
<jam> fwereade_: happy to. Sorry they didn't come through before the break.
<fwereade_> jam, np at all :)
<fwereade_> jam, some nice easy merges are a great way to start the week
<rogpeppe> fwereade_: i'm just having a look at some of your CLs. you must've had a lot of spare time over xmas!
<fwereade_> rogpeppe, most of them are really tiny trivial ones I did in the first day or so to get my mind off the lifecycle/subordinate bits :)
<fwereade_> rogpeppe, since then I've had several days of actual work :)
<fwereade_> rogpeppe, ah, sorry, totally missed your suggestion in deploy
<rogpeppe> fwereade_: i've only just made it :-)
<rogpeppe> fwereade_: although i think i might have made it before actually
<fwereade_> rogpeppe, I'll probably propose a trivial for that later today then
<fwereade_> rogpeppe, tyvm for all the reviews
<rogpeppe> fwereade_: more on their way :-)
<fwereade_> rogpeppe, awesome :D
<fwereade_> rogpeppe, just about to repropose machine-death-restrictions, but the main change is in the comments
<rogpeppe> fwereade_: am just about to publish some comments on that
<fwereade_> rogpeppe, I'll wait for you then
<rogpeppe> fwereade_: done
<fwereade_> rogpeppe, without the JobManageEnviron restriction, how do you suggest we avoid killing that machine? I'm stronly -1 on special-casing machine 0
<fwereade_> rogpeppe, if and when we add a mechanism by which machines can change their jobs, this may need some gentle tweaking, I agree
<rogpeppe> fwereade_: we could leave the restriction in for the time being, i suppose
<rogpeppe> fwereade_: i'm not really thinking about machines changing their jobs
<rogpeppe> fwereade_: but about being able to add new machines that also manage the environment
<rogpeppe> fwereade_: if you do that, you'll never be able to remove them currently
<fwereade_> rogpeppe, agreed -- I think my attitude applies just the same though
<fwereade_> rogpeppe, at the moment there's no way to do that; when there is, we may need to tweak it
<rogpeppe> fwereade_: that sounds reasonable. how about adding a comment to that effect?
<fwereade_> rogpeppe, sgtm
<fwereade_> rogpeppe, now, re retries
<jam> mgz: poke
<fwereade_> rogpeppe, I don't think it's very nice to tell the user that a machine's in use when we know it isn't
<rogpeppe> fwereade_: well, it was in use when they tried to remove it...
<fwereade_> rogpeppe, we don't know that
<fwereade_> rogpeppe, we could easily have screwed something up ;p
<rogpeppe> fwereade_: yeah we do, because that's the only way the transaction can fail, no?
<fwereade_> rogpeppe, at the moment it is
<fwereade_> rogpeppe, that's my point :)
<rogpeppe> fwereade_: i don't think it's worth optimising error messages for "will probably never happen" cases
<fwereade_> rogpeppe, there's precedent
<rogpeppe> fwereade_: when we're giving a bad error message for a "might well happen" case
<fwereade_> rogpeppe, machine assignments flipping N times with perfectly evil timing?
<fwereade_> rogpeppe, I think it's already a probably-never-happen case
<rogpeppe> fwereade_: i don't like the precedent set by the retry
<rogpeppe> fwereade_: if something has failed, let it fail.
<fwereade_> rogpeppe, hm, I'd seen it as a standard and necessary technique
<rogpeppe> fwereade_: as you've pointed out, it's not sufficient. and i don't think it's necessary either.
<rogpeppe> fwereade_: if something else is tweaking machine assignment concurrently, then there's every likelihood that the machine destroy should fail
<fwereade_> rogpeppe, the technique is already used in Relation.Destroy and RelationUnit.LeaveScope
<rogpeppe> fwereade_: and it seems perfectly reasonable that it should
<fwereade_> rogpeppe, IMO if we can't tell why it failed we should treat it somewhat seriously instead of making something up
<rogpeppe> fwereade_: we know that it must fail because of one of the two asserts
<rogpeppe> fwereade_: we rely on our transaction system working like that
<fwereade_> rogpeppe, right, so if it must have failed for one of two reasons -- neither of which apply -- we should just pretend that one of them did?
<rogpeppe> fwereade_: we know that one of them *did* apply
<rogpeppe> fwereade_: we just don't know which one any more
<fwereade_> rogpeppe, alternative perspective then -- if we know that neither applies now, why should we make the user retry the command instead of just doing it ourselves?
<rogpeppe> fwereade_: because the user must be prepared to retry the command anyway
<fwereade_> rogpeppe, why do we have attemptStrategy then?
<rogpeppe> fwereade_: that's a totally different thing
 * fwereade_ raises an eyebrow
<rogpeppe> fwereade_: that's about eventual consistency
<rogpeppe> fwereade_: and network availability
<fwereade_> rogpeppe, why don't we just make the user keep trying the same command?
<rogpeppe> fwereade_: because in those cases, it's *normal* for the some attempts to fail.
<rogpeppe> s/the some/some/
<fwereade_> rogpeppe, this is exactly the sort of race for which we built a great big pile of infrastructure -- aren't these conditions also "normal"?
<rogpeppe> fwereade_: i don't think so. what we're talking about in this CL is a genuine race condition
<fwereade_> rogpeppe, I've got an old verity stob quote playing back in my mind...
<rogpeppe> fwereade_: whereas what we're guarding against with attemptStrategy is just slow propagation and dodgy networks
<fwereade_> The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user.
<rogpeppe> fwereade_: meant ironically, presumably?
<fwereade_> rogpeppe, indeed so
<rogpeppe> fwereade_: see also: fail fast :-)
<fwereade_> rogpeppe, we do fail fast
<rogpeppe> fwereade_: this retry stuff is not failing fast
<fwereade_> rogpeppe, this is just for handling rare, but perfectly normal and predictable, cases
<fwereade_> rogpeppe, er, yes it is
<fwereade_> rogpeppe, we only retry when we don't know what went wrong and we have a reasonable expectation that a second attempt will work
<rogpeppe> fwereade_: i think we're adding unnecessary complexity to give the user a good error message in a very rare case
<fwereade_> rogpeppe, the "complexity" I see is, er, a for loop
<fwereade_> rogpeppe, that doesn't seem like such a great cost to pay for a bit of user-friendliness...
<rogpeppe> fwereade_: it's one (well, three, if you include Relation.Destroy and RelationUnit.LeaveScope) more moving part and an arbitrary heuristic.
<rogpeppe> fwereade_: i'd prefer to leave as many "probably"s out of the code as possible
<rogpeppe> fwereade_: in this case, we have a genuine race conflict, and it seems reasonable that we should tell the user about it as soon as possible (they might not *want* to destroy the machine if someone else is jiggling with it)
<rogpeppe> fwereade_: and the error message that happens if the improbable happens is not right. the state is not inconsistent, just something unlikely happened.
<fwereade_> rogpeppe, the error message is "machine <id> cannot become <state>: please contact..."
<rogpeppe> fwereade_: oh sorry, i was looking at RelationUnit.LeaveScope
<rogpeppe> fwereade_: i think the error message should be "machine is in use"
<rogpeppe> fwereade_: because it was.
<fwereade_> rogpeppe, that error message in that place is a lie
<fwereade_> rogpeppe, and we know it's a lie
<rogpeppe> fwereade_: "machine was in use" :-)
<fwereade_> rogpeppe, otherwise we would not rech that place
<rogpeppe> fwereade_: it wasn't a lie a millisecond ago
<fwereade_> rogpeppe, we have exactly as much information indicating that it's a lie as we have indicating it's the truth
<fwereade_> rogpeppe, we actually *do not know*
<rogpeppe> fwereade_: that's because it's in an indeterminate state. but the reason we're *failing* is because the machine is in use
<rogpeppe> fwereade_: we're just trying to add a little more information to help the user in the most common case.
<fwereade_> rogpeppe, what?
<fwereade_> rogpeppe, this is already a vanishingly rare case
<fwereade_> rogpeppe, to trigger it the machine has to have a unit removed/added/removed, with very specific timing
<rogpeppe> fwereade_: i don't really mind about the error message in the highly unlikely case that someone adds a machine in the ms between executing the transaction and checking afterwards.
<rogpeppe> fwereade_: agreed
<fwereade_> rogpeppe, we already get sensible error messages in the common cases
<rogpeppe> fwereade_: so why bother iterating, if it's already so rare?
<fwereade_> rogpeppe, because the basic case, in which the unit removal races with the machine change, is perfectly reasonable and expected
<fwereade_> rogpeppe, not retrying at all is just rude
<fwereade_> rogpeppe, refusing to tell the user why, or making up a reason why, is IMO bad
<fwereade_> rogpeppe, hence we should try to diagnose the failure
<rogpeppe> fwereade_: i don't think someone should be destroying a machine if they haven't removed its units first
<fwereade_> rogpeppe, if it seems that the expected race condition is in play, retrying is again the friendly thing to do
<fwereade_> rogpeppe, right, and if they do that we tell them why it didn't work...
<rogpeppe> fwereade_: sure, and that will happen even if we don't retry.
<rogpeppe> fwereade_: the only time the retry will happen is if someone removes the last unit, then adds another one immediately.
<fwereade_> rogpeppe, no
<rogpeppe> fwereade_: hmm, rather
<rogpeppe> fwereade_: adds a unit, then removes it immediately
<fwereade_> rogpeppe, there will be multiple admins at some stage, right?
<rogpeppe> fwereade_: sure. but if they're stepping on one another's toes, i think the (*very* occasional) not-so-informative error message is fine.
<rogpeppe> fwereade_: "machine in use" still tells them something useful
<rogpeppe> fwereade_: and given that the jobs for a machine can't change currently, we may as well say "machine has assigned units", because that's the only way a race can happen
<rogpeppe> fwereade_: and i know it wasn't true the last time we looked, but it's still the reason why we're failing
<fwereade_> rogpeppe, it's one of two reasons we currently know about
<fwereade_> rogpeppe, and you're arguing awfully hard against, again a fricking for loop
<fwereade_> rogpeppe, is it actually unclear?
<fwereade_> rogpeppe, are you saying that I'm guarding against something that can't happen?
<rogpeppe> fwereade_: i think "machine %s cannot become dead: please contact juju-dev@..." is unclear.
<rogpeppe> fwereade_: i'm saying you're guarding against something that is already extremely unlikely.
<rogpeppe> fwereade_: and that doesn't add much value even then
<fwereade_> rogpeppe, let me be clear -- it is that retrying adds no value?
<rogpeppe> fwereade_: yeah
<fwereade_> rogpeppe, so every juju client needs to implement their own retry logic?
<rogpeppe> fwereade_: no, i imagine that if you try to destroy a machine that someone else is meddling with, the juju client would fail and that would be fine.
<TheMue> fwereade_: Do you have some more informations about the test failure Dave detected? I checked it and get the same failing UnitSuite.TestChangePasswordChanging in cmd/jujud/ w/ and w/o the rejected firewaller change (and that should also have no influence).
<fwereade_> rogpeppe, IMO it's not fine to fail to do something valid and lie about the reason
<fwereade_> TheMue, huh, weird -- I'm afraid I don't though :(
<rogpeppe> fwereade_: we don't have to lie about the reason. we can just make the reason less specific
<TheMue> fwereade_: OK, have to talk to Dave then.
<fwereade_> rogpeppe, "can't be bothered, maybe try again?"
<rogpeppe> fwereade_: "someone else is meddling. give 'em a kick!"
<rogpeppe> fwereade_: i think we're trying too hard to give a perfect error message in extreme corner cases.
<fwereade_> rogpeppe, look, you are simultaneously arguing that my error message is bad and that I'm trying too hard to give a good one
<rogpeppe> fwereade_: the "machine %s cannot become dead: " message is bad because it doesn't say what the reason was (we know it must be one of two reasons, otherwise we wouldn't have got ErrAborted)
<fwereade_> rogpeppe, the reason is because in that case we do not know the reason
<rogpeppe> fwereade_: in fact currently, we *do* know the reason
<rogpeppe> fwereade_: because the jobs assigned to a machine cannot change after it's created
<rogpeppe> fwereade_: so we know that it can only have failed because a unit was there but has now been removed.
<fwereade_> rogpeppe, no... if we hit that case the only explanation is so vanishingly unlikely that we should be treating "we analyzed this wrong" with as much weight
<fwereade_> rogpeppe, hence the suggestion to escalate
<fwereade_> rogpeppe, if I bumped the retries to 3, would that make the tradeoff clearer?
<rogpeppe> fwereade_: no, i think 2 is more than enough.
<rogpeppe> fwereade_: ok, i won't argue this further. i think it's unnecessary code, but it doesn't actively harm anything. i would avoid the "please contact" error message though.
<fwereade_> rogpeppe, if it bothers you that much, can I ask you to take it up with niemeyer? I don't want to do something arbitrarily different from what we agreed in the Relation.Destroy case
<rogpeppe> fwereade_: i suppose Relation.Destroy gives precedent. i missed that at the time.
<rogpeppe> fwereade_: (i think the error message in that case is similarly dubious)
<fwereade_> rogpeppe, I definitely had a big "gaah wtf this is horrible" moment when I first did that, but I've come to terms with it -- we *think* that neither case should ever happen, but if it does we want to know about it
<rogpeppe> fwereade_: what do you think "corrupt state" might mean, BTW, in this context?
<fwereade_> rogpeppe, I'm at least partly inclined to prefer something like "excessive contention" but that doesn't really feel so helpful either
<rogpeppe> fwereade_: excessive contention is much better
<fwereade_> rogpeppe, well, either the code doesn't match the data or that data doesn't match the code
<fwereade_> rogpeppe, the actual style of contention itself is so pathological, though, that I don't think it covers the situation adequately
<rogpeppe> fwereade_: i dunno. if someone is really thrashing the state (probably deliberately), then it may happen
<fwereade_> rogpeppe, which is why I'm starting to feel that I should go from 2 to 3 :)
<rogpeppe> fwereade_: and in that case, it's nice for the error message to reflect what we really believe is happening
<rogpeppe> fwereade_: honestly, 2 is just fine. contention in that case could already be deemed to be excessive.
<fwereade_> rogpeppe, suggestion -- I'll open a bug saying "contact juju-dev@ is unhelpful", or something, and assign it to niemeyer
<fwereade_> rogpeppe, it's not that I don't appreciate your perspective, it's just that it's his form of words that broke us out of a similar discussion a while ago :)
<rogpeppe> fwereade_: if someone removes, adds and removes a unit in quick succession, at the same time someone is removing a machine, i think that could be judged as excessive.
<rogpeppe> fwereade_: fair enough.
<fwereade_> rogpeppe, cool, thanks
<fwereade_> rogpeppe, the thing about turning 2 into 3 is that it makes the ugly error less likely to come up
<rogpeppe> fwereade_: i just don't like "shouldn't happen" - because it's perfectly ok for it to happen, just somewhat unlikely.
<rogpeppe> fwereade_: i'll bet you 50 quid it will never ever come up for real.
<rogpeppe> fwereade_: even with 2.
<fwereade_> rogpeppe, that's why it was 2 to begin with -- I actually don't expect it to happen
<fwereade_> rogpeppe, but I have rarely been poorly served by upgrading my paranoia ;p
<fwereade_> rogpeppe, and I guess I'm iffy about the mismatch between 5 for Relation.Destroy and 2 for Machine.EnsureDying
<fwereade_> rogpeppe, although, that said, the expected number of contending clients is very different
<rogpeppe> fwereade_: that seems like a reasonable reason for the difference
<fwereade_> rogpeppe, and finally... maybe "has unit %q assigned"? the suggested "to it" feels a touch inelegant
<rogpeppe> fwereade_: though i do think that the loop in Relation.Destroy is qualititatively different from the loop in Machine.EnsureDying
<rogpeppe> "machine 2 cannot become Dying: unit wordpress/0 is assigned to it" seemed like it might read ok to me
<fwereade_> rogpeppe, ok, fair enough
<fwereade_> rogpeppe, I'd be interested in your thoughts re differences, above, though
<rogpeppe> fwereade_: the loop in Relation.Destroy is because we can't remove the relation in one transaction
<rogpeppe> fwereade_: so we're forced to iterate
<rogpeppe> fwereade_: the loop in Machine.EnsureDying is just to give a nicer error message
<rogpeppe> fwereade_: in a relatively unlikely case
<fwereade_> rogpeppe, I disagree with your statement re Relation.Destroy (unless you're talking about the cleanup ops, in which case I don't understand the relevance)
<rogpeppe> fwereade_: unless i've misunderstood the code, we can't run the removeOps in the same txn as setting the relation to dying
<rogpeppe> fwereade_: and that's the reason for the loop AFAICS
<fwereade_> rogpeppe, we either run removeOps or we set to Dying
<fwereade_> rogpeppe, we loop because the conditions that determine which we should do can change underneath us
<rogpeppe> fwereade_: we run removeOps, *then* set to Dying, no?
<fwereade_> rogpeppe, no
<fwereade_> we set to dying if we can't remove it
<rogpeppe> fwereade_: ah, i see, i'd missed that.
<fwereade_> rogpeppe, we need to do something similar with services, but I haven't got to that yet
<rogpeppe> fwereade_: in which case, i'm not sure i see the reason for the loop at all
<fwereade_> rogpeppe, because you think we should just tell the user we couldn't do it?
<rogpeppe> fwereade_: ah, i do see. it's because you can't decide which set of operations to do without looking at the state first.
<fwereade_> rogpeppe, yeah, sorry I wasn't clear
<rogpeppe> fwereade_: so my original statement is true - we can't remove the relation in one transaction
<rogpeppe> fwereade_: we have to find the number of units, then apply an operation.
<rogpeppe> fwereade_: so i still think that makes for a qualititive difference between Relation.Destroy and Machine.EnsureDying
<fwereade_> rogpeppe, ok, I agree there, I'm just not sure that affects my views :)
<rogpeppe> fwereade_: for me, it leaves the loop in Relation.Destroy as necessary, but doesn't necessarily make the loop in EnsureDying necessary, as it's only about changing an error message in an unlikely situation. but i've said that already :-)
<mgz> to go install the current juju-core I need to cp exp/cookiejar from upstream go, for code.google.com/p/go.net - is that expected?
<mgz> I'm not sure what requires that, is there an easy way of chasing the import chain backwards?
<mgz> hm, seems juju-core only wants the websocket package, and nothing actually uses publicsuffix which has the import, but maybe install just wants to do the lot?
<mgz> and the test suite hangs at the same point for me every time...
<mgz> http://paste.ubuntu.com/1506413/
<mgz> probably a dep change or something, will check
<mgz> ...nothing obvious
<Aram> hello everybody.
<TheMue> Hi Aram
<rogpeppe> Aram: hiya
<fwereade_> Aram, heyhey
<fwereade_> rogpeppe, reproposed https://codereview.appspot.com/7005047
<Aram> how do I see this new kanban new age thing?
<Aram> ok, found it.
<Aram> meh
<rogpeppe> fwereade_: ping
<fwereade_> rogpeppe, pong
<rogpeppe> fwereade_: was just looking at https://codereview.appspot.com/7035060/diff/7001/worker/uniter/modes.go?column_width=90
<fwereade_> rogpeppe, ok
<rogpeppe> fwereade_: and wondering about the way that ModeTerminating waits to be able to call EnsureDead
<fwereade_> rogpeppe, it was the only way that crossed my mind -- if you have a better one, I'm all ears
<rogpeppe> fwereade_: is there anything in the state docs that says that a unit watcher gets a change when the number of subordinates changes?
<fwereade_> rogpeppe, heh, probably not
<rogpeppe> fwereade_: i can see that it *does*, but it seems a little... dubious
<rogpeppe> fwereade_: if there was a method on Unit that returned the subordinate names (or the subordinate count), it might be more understandable
<fwereade_> rogpeppe, hmm, maybe the count is the way to go
<rogpeppe> fwereade_: alternatively (and possibly in addition) perhaps the watcher should enumerate all the things that can cause a change.
<fwereade_> rogpeppe, yeah, changing the first without the second still doesn't address your point
<fwereade_> tricky
<rogpeppe> fwereade_: yeah, though if you have the second without the first, it does seem odd that you can watch something and not be able to query for it directly.
<fwereade_> rogpeppe, yeah -- and my issue with the second is that it seems a bit odd to exhaustively list them -- seems like the sort of doc that'll go out of date really quickly and thus cause more confusion than it solves
<rogpeppe> fwereade_: but there are some things you can't watch for, i think, and it's not obvious which ones
<fwereade_> rogpeppe, Unit.WaitAffairsInOrder() ;p
<rogpeppe> fwereade_: i'm happy with SubordinateCount
<rogpeppe> fwereade_: or even Subordinates() []string
<rogpeppe> fwereade_: it might be something that will go out of date quickly, but it's also important information that you need to know if you want to use the API
<fwereade_> rogpeppe, yeah
<rogpeppe> fwereade_: perhaps we could document it in the individual methods themselves.
<fwereade_> rogpeppe, hmm, that's a nice idea
<rogpeppe> fwereade_: "calling this method may trigger a unit watcher change"
<fwereade_> rogpeppe, I've just got one more to merge, then I was about to eat lunch -- I'll ponder while I wait
<rogpeppe> fwereade_: k
<fwereade_> rogpeppe, ah, I was thinking the other way round
<rogpeppe> fwereade_: well, me too
<rogpeppe> fwereade_: and perhaps it's better on the getter
<fwereade_> rogpeppe, needs a clear forms of words either way, and describing it's easier on the setter
<fwereade_> rogpeppe, I will cogitate
<rogpeppe> fwereade_: the problem with my above suggestion is there isn't necessarily a clear relationship between mutating method and the thing that changes
<rogpeppe> fwereade_: "This result of this method may be watched for" ? or something like that.
<fwereade_> rogpeppe, maybe it's easier to exhaustively describe the things that *don't* interact with watches
 * fwereade_ is not actually sure what those are
<rogpeppe> fwereade_: some things are immutable
<rogpeppe> fwereade_: e.g. IsPrincipal
<fwereade_> rogpeppe, yeah
<rogpeppe> fwereade_: and IsAlive requires a different watcher
<fwereade_> rogpeppe, the Agent one? yeah, that should be made clear
<fwereade_> bah
<fwereade_> rogpeppe, ok, really having lunch now, bbiab
<rogpeppe> fwereade_: enjoy!
<fwereade_> cheers
<rogpeppe> fwereade_: ping
<fwereade_> rogpeppe, pong
<rogpeppe> fwereade_: i'm looking at TestSubordinateDying in https://codereview.appspot.com/7030061/diff/1/worker/uniter/uniter_test.go
<fwereade_> rogpeppe, go on
<fwereade_> rogpeppe, (horrid, ain;t it)
<rogpeppe> fwereade_: the test code looks somewhat intricate. why can't you just use AddTestingCharm?
<fwereade_> rogpeppe, because AddTestingCharm doesn't add something you can actually download, does it?
<rogpeppe> fwereade_: hmm. maybe it should.
<fwereade_> rogpeppe, seems like a bit of a heavyweight solution to me
<rogpeppe> fwereade_: at the least, i think the code to make a charm available for download could be factored into a different function.
<rogpeppe> fwereade_: it wasn't clear to me that that was the sole purpose of that block of code
<fwereade_> rogpeppe, IIRC it's more different to the other code that does that than it looks
<fwereade_> rogpeppe, 3 or 4 params to save 15 lines just once feels a bit borderlin
<rogpeppe> fwereade_: what are the params?
<rogpeppe> fwereade_: one other thing: why ClonedDir and not just Dir?
<fwereade_> rogpeppe, hmm, charm, base charm url, and revision, I think -- with additional subtle unclarity re revision, based on the other use, I think... but, hmm, maybe I could drop that
<fwereade_> rogpeppe, because I don't believe it's ever actually valid to use Dir -- I'd rather copy a few files to a tmpfs than run the risk of accidentally overwriting something in the source tree
<rogpeppe> fwereade_: you're worried that Bundle might overwrite something?
<rogpeppe> fwereade_: i think this kind of usage is exactly why we have Dir
<fwereade_> rogpeppe, I guess it is only used there, but my habit is never to use it -- not really defensible I guess
<rogpeppe> fwereade_: AFAICS there's only a need for a single parameter - the *charm.Dir
<fwereade_> rogpeppe, that is because I imagine you're not looking at the createCharm type elsewhere in that file
<fwereade_> rogpeppe, which was the original source of that block
<fwereade_> rogpeppe, it certainly doesn't seem sensible to factor that block out of this test only for the use of this test
<rogpeppe> fwereade_: to me, it's a big block of code that is only tangientally related to the main function of the test. and it has an easily defined name and purpose, so putting it in its own function seems to make sense.
<rogpeppe> fwereade_: i have to look very hard to see what stuff defined in that block is used outside it
<rogpeppe> fwereade_: whereas a simple "serveCharm" function would make both the purpose of the block and its side effects obvious
<fwereade_> rogpeppe, and collide with the serveCharm type used both in that test and elsewhere -- similarly if we call it createCharm
<fwereade_> rogpeppe, if we make it a step called createSubordinateCharm then people will start assuming it's safe to use it in other tests
<fwereade_> rogpeppe, which it is most decidedly not
<fwereade_> rogpeppe, that's the primary reason I have a separate test case in the first place
<fwereade_> rogpeppe, because the assumption that the charm is not subordinate is baked into basically everything else in that file
<fwereade_> rogpeppe, I agree we'll have to factor it out if and when a subordinate uniter develops any other behaviour differences
<fwereade_> rogpeppe, but for now segregating it all neatly in a single scope seems best to me
<rogpeppe> fwereade_: i'm just saying that i found that test quite hard to read, and i'm trying to find a way to make it easier.
<fwereade_> rogpeppe, I'm not actually trying to contradict you, sorry if I'm being short with you -- I'm just condensing my own frustrating experiences with it into a few minutes of IRC
<fwereade_> rogpeppe, I was actually over the moon when I got that behaviour tested in "only" 150 lines of new code
<fwereade_> rogpeppe, I was expecting to have to gut the whole thing and reassemble it with fewer assumptions :)
<rogpeppe> fwereade_: the code in createCharm.step looks almost identical to the code in TestSubordinateCharmDying to me
<rogpeppe> fwereade_: surely there's a function you can factor out there?
<fwereade_> rogpeppe, yes, it's quite similar
<rogpeppe> fwereade_: i don't see any significant difference
<fwereade_> rogpeppe, maybe the bundle/hash step, I guess
<rogpeppe> fwereade_: AFAICS they both do the same bundling and hashing. i'm probably missing something though.
<rogpeppe> fwereade_: the only difference i can see is that createCharm does a SetDiskRevision
<rogpeppe> fwereade_: i'd be much happier if that reasonably intricate code existed in one function only.
<fwereade_> rogpeppe, so, 10 lines of code with no branches or actual complexity... this is, it is true, exactly the sort of thing I would once have factored out without a second thought
<fwereade_> rogpeppe, however I have learned, painfully, that if I do things like that on this team I have to justify my decisions in tedious detail
<rogpeppe> fwereade_: for me, in this case, it's a no-brainer
<fwereade_> rogpeppe, and I have history of being told not to factor out bundling/hashing functionality
<rogpeppe> fwereade_: it's not adding to any public API
<rogpeppe> fwereade_: and the code is almost identical in both cases (and it's 9 steps that are hard to remember and easy to get wrong)
<rogpeppe> fwereade_: i think it's non-controversial
<mramm> rogpeppe: fwereade_: Aram: TheMue: you guys up for the kanban review meeting?
<rogpeppe> fwereade_: also, this code isn't strongly related to the tests - it's more closely tied to the charm server requirements.
<TheMue> mramm: I'm ready
<rogpeppe> mramm: i am
<mramm> the google hangout is in the calendar invite
<fwereade_> rogpeppe, it's 8 lines AFAICT
<fwereade_> rogpeppe, can we please not bring the charm serving into it? the bundling/hashing really is of a part, the url we happen to serve from is IMO not
<rogpeppe> fwereade_: so it's just coincidence both those chunks of code do almost exactly the same thing?
<Aram> if only G+ worked
<Aram> can't hear a damn thing
<Aram> I wish hangouts didn't peg my CPUs.
<fwereade_> rogpeppe, on reflection, fwiw, I think I'm ok with an uploadCharm func that includes bundle/hash/add-to-ctx.charms, only needs a small tweak
<rogpeppe> right, that's me for the day
<rogpeppe> g'night all!
<mramm>  https://juju.ubuntu.com/ <--- Check out the new fancy juju video
#juju-dev 2013-01-08
<TheMue> Morning
<rogpeppe> mornin' all
<TheMue> rogpeppe: Hiya
<TheMue> rogpeppe: ping
<rogpeppe> TheMue: pong
<TheMue> rogpeppe: Maybe you can help me localizing an error.
<rogpeppe> TheMue: glad to help if i can
<TheMue> rogpeppe: You know about the rollback of my firewaller change by Dave? It lead to a hanging test in cmd/jujud
<rogpeppe> TheMue: i'd seen that go past, yes
<TheMue> rogpeppe: It is the MachineSuite.TestProvisionerFirewaller.
<TheMue> rogpeppe: So I loked at it with gocheck.vv.
<TheMue> rogpeppe: One moment, will paste the log.
<TheMue> rogpeppe: http://paste.ubuntu.com/1509166/
<rogpeppe> *click*
<TheMue> rogpeppe: You'll see from line 66 that there's a loop. And that will time out after 5 minutes.
<fwereade> rogpeppe, TheMue: heh, I was just needing to write some tests there myself and getting depressed about the can't-sync issue
<TheMue> rogpeppe: The firewaller tests themselves pass fine.
<fwereade> TheMue, ah, that weirdness is fixed in one of my current CLs
<TheMue> fwereade: Oh!
<TheMue> fwereade: *hug*
<rogpeppe> fwereade: which particular weirdness is that? and what was the fix?
<fwereade> TheMue, well, ok, some of the weirdness
<fwereade> rogpeppe, the lack of a sane environment in which to run and the whining about tools
<rogpeppe> fwereade: sorry, i'm feeling stupid - how does that tally with TheMue's issue above?
<fwereade> TheMue, rogpeppe: yeah, I'm probably wrong -- I think I was looking at the wrong bit of the log
<TheMue> fwereade: From reading the test itself I found now problem regarding the firewaller. Funnily the test passes before I merge the firewaller change. Afterwards it looks like in the paste.
<rogpeppe> fwereade: it looks like the crux is that it's getting unauthorized access
<TheMue> rogpeppe: Exactly.
<rogpeppe> TheMue: have you tried putting in printfs that print when the password is being changed, and what password is being connected with?
<rogpeppe> TheMue: that might help narrow down the issue
<fwereade> dimitern, heyhey, are you back in town?
<TheMue> rogpeppe: Inside the test there's no obvious change, but I'll add statements to see where it may happen.
<dimitern> fwereade: hey :) yeah - landed early this morning
<fwereade> dimitern, ah cool
<rogpeppe> TheMue: that's worth doing i think - put the printfs in the relevant state functions
<rogpeppe> dimitern: yo!
<fwereade> dimitern, nice hols?
<dimitern> fwereade: oh yeah! much needed as well
<dimitern> fwereade: yours?
<fwereade> dimitern, yeah, very peaceful, was really nice having nico and rie over for xmas
<fwereade> dimitern, we've still got another duck in the freezer, I'll let you know when I can be bothered to cook it ;p
<dimitern> fwereade: cool :) beers later?
<fwereade> dimitern, sgtm, I'll figure out cath's movements and let you know
<TheMue> rogpeppe: Interesting, the failure differs. Just had a different simple test fail, and now again the hanging process due to unauthorized access. :(
<rogpeppe> TheMue: the failure differs after you've added the printfs? or just it differs from run to run?
<TheMue> rogpeppe: From run to run.
<rogpeppe> TheMue: what did the new failure look like?
<fwereade> rogpeppe, TheMue: a suggestion: the runOnce methods should *take* a *State, and then we get to do an end-run around the deployer-testing nonsense; the machiner-testing nonsense I'm about to hit; probably uniter-testing weirdness I don't remember
<fwereade> rogpeppe, TheMue: ...and as a bonus it is somewhat likely we'll be able to write a firewaller/provisioner test I can understand ;p
<rogpeppe> fwereade: i'm looking at that stuff right now as well :-)
<rogpeppe> fwereade: what difference would passing a state to runOnce make?
<TheMue> rogpeppe: The hanging looks like before, otherwise I get one unautherized, but afterwards the opening of the port fails.
<TheMue> fwereade: So, I have a problem following you. :/
<fwereade> rogpeppe, IMO the fact that we can't touch the state used in the workers without serious gymnastics makes everything harder
<rogpeppe> TheMue: i'm afraid i can't really help without more information. you'll just have to dive in and work out what's going on
<rogpeppe> fwereade: how does changing the signature of runOnce help there?
<fwereade> rogpeppe, that it gives us a point at which we can sanely hook a test in
<rogpeppe> fwereade: personally, i was thinking of adding a var openState func(*state.Info) (*state.State, error)
<rogpeppe> fwereade: global
<rogpeppe> fwereade: i'm not sure i want tests to know about runOnce
<fwereade> rogpeppe, the tests know everything anyway, except the things they need to know
<rogpeppe> fwereade: lol
<fwereade> rogpeppe, I must say I really am finding them hard to work with :/
<rogpeppe> fwereade: the idea is that the test is minimal, because all the real testing is done in the worker packages themselves, and in jujud we only need to verify that the right components have been joined up correctly
<rogpeppe> fwereade: if we call runOnce directly, we aren't verifying that Run will actually do the right thing
<fwereade> rogpeppe, so maybe we should test them both?
<rogpeppe> fwereade: you're principally concerned about the sync issue here, right?
<fwereade> rogpeppe, the sync issue is one thing
<fwereade> rogpeppe, the fact that there's duplication between the two agents also concerns me
<fwereade> rogpeppe, the dancing around with passwords is hard to follow, and should clearly be common
<rogpeppe> fwereade: i had that factored out originally, but was persuaded not to do that
<fwereade> rogpeppe, I can well believe it :/
<rogpeppe> fwereade: and... it's only four lines of code
<rogpeppe> fwereade: i'm not sure it's that hard to follow
<fwereade> rogpeppe, trust me, it is hard to follow
<rogpeppe> 	if passwordChanged != "" {
<rogpeppe> 		if err := m.SetPassword(a.Conf.StateInfo.Password); err != nil {
<rogpeppe> oops
<fwereade> rogpeppe, there is no justification I can see for smearing the password-handling across openState and 2 spearate clients
<rogpeppe> that's new
<rogpeppe> fwereade: you can't set the password before you've retrieved the relevant entity from the state
<rogpeppe> fwereade: so you'd need to pass in a function to do that
<fwereade> rogpeppe, or maybe we could have a sane state API
<rogpeppe> fwereade: and if you do that (i did, before) the code ends up just as difficult to understant
<rogpeppe> d
<fwereade> rogpeppe, we have this ridiculous groupthink lie that "agents aren't a concept that exists in state"
<rogpeppe> fwereade: i started with a different API too.
<fwereade> rogpeppe, SetAgentPassword(entityName, password string)
<rogpeppe> fwereade: what happens if the entity doesn't exist?
<rogpeppe> fwereade: (FWIW that was my original design)
<fwereade> rogpeppe, state can figure that out trivially
<fwereade> rogpeppe, I believe you :(
<fwereade> rogpeppe, this is the trouble
<rogpeppe> fwereade: i'm reluctant to change this stuff now - it was hammered out at some length, and it's not too bad as is, i think
<rogpeppe> fwereade: apart from the code-readability issue, what does it help with?
<fwereade> rogpeppe, it gets us one step closer to treating the two agents the same
<fwereade> rogpeppe, maybe this is just a pipe dream of mine
<rogpeppe> fwereade: i think it's reasonable to have different code for both agents - they're independent entities
<fwereade> rogpeppe, the only thing that should be different is the list of workers
<fwereade> rogpeppe, everything else is exactly the same, but we duplicate it imperfectly because niemeyer insists
<fwereade> rogpeppe, and so I get really grumpy whenever I have to work around there
<fwereade> rogpeppe, because there *is* a good design, and it's probably pretty close to a combination of the things that you and I both tried to do early on, but we've been forbidden to do that
<fwereade> rogpeppe, a thought -- if you find it easy to work in that area
<rogpeppe> fwereade: i dunno - i'm not sure that making the two agents be exactly the same except for the tasks the run is necessarily right. the current design gives us leeway to make them significantly different if we want without significant code disruption, and i think that's a useful freedom.
<rogpeppe> s/the run/they run/
<fwereade> rogpeppe, honestly, it feels to me like being different from python just for the sake of it
<fwereade> rogpeppe, the python stuff was just fine, once yu scraped away the layers of twisted caking it
<fwereade> rogpeppe, (to be clear: the very specific idea of having "agent" functionality distinct from the actual agents themselves)
<fwereade> rogpeppe, it lets you, eg, test the Run code without dicking around with the details of what the individual agents happen to want to do in runOnce
<fwereade> rogpeppe, but let us stipulate that for some reason I am irrational here
<rogpeppe> fwereade: ? we can do that, can't we?
<rogpeppe> fwereade: isn't testing the Run code what we do currently?
<fwereade> rogpeppe, by unreliable side-effect of the action of runOnce, yes
<rogpeppe> fwereade: ah, you mean the Run code without runOnce
<rogpeppe> fwereade: we could do that, actually, without too much hassle, if we wanted
<rogpeppe> fwereade: the Run code is more-or-less identical for both
<fwereade> rogpeppe, well, not really, because we duplicate Run for each agent
<fwereade> rogpeppe, yeah
<fwereade> rogpeppe, so there's nothing common except by coincidence
<rogpeppe> fwereade: we could have a function: func Run(once RunOncer) error
<rogpeppe> fwereade: no coincidence - i try to keep them as similar as possible so i can look at them side by side and see that they're the same
<rogpeppe> fwereade: maybe func RunLoop
<fwereade> rogpeppe, yeah, I guess that could work, but it still feels like it's primarily dictated by the arbitrary "these 2 bits of code that are the same must be duplicated because we might one day want to change them" constraint
<fwereade> rogpeppe, we factor another little common bit out, great
<fwereade> rogpeppe, and we now have another, slightly simpler structure, that is duplicated across the agents
<fwereade> rogpeppe, but, let me take a step sideways for a moment
<fwereade> rogpeppe, I am pleased that you find jujud easy to deal with, because I surely do not
<fwereade> rogpeppe, if I cut back what I'm doing and just propose a Machiner
<fwereade> rogpeppe, and assign to you a bug for integrating it and testing it
<fwereade> rogpeppe, I will shut up about it
<fwereade> rogpeppe, until next time ;p
<rogpeppe> fwereade: i'm not saying i find it *easy* to deal with :-)
<rogpeppe> fwereade: but the concerns you've voiced don't map well to the difficulties i have with it
<rogpeppe> fwereade: http://paste.ubuntu.com/1509259/ ?
<rogpeppe> fwereade: oops http://paste.ubuntu.com/1509261/
<fwereade> rogpeppe, that would, I agree, be a step forward
<rogpeppe> fwereade: func (st *State) Entity(entityName string) Entity; type Entity interface {everything that entities have in common}
<rogpeppe> sorry, func (st *State) Entity(entityName string) (Entity, error) of course
<fwereade> rogpeppe, I would *probably* love that, but I think it's a non-starter because niemeyer doesn't believe in agents
<rogpeppe> fwereade: i don't see anything about agents there
<fwereade> rogpeppe, yeah, but it's actually all about agents
<rogpeppe> fwereade: that's the trick :-)
<fwereade> rogpeppe, only the entities with agents have "entity names"
<mramm> mgz, jam, dimitern: I was able to add all of you to the juju core kanban board
<mgz> mramm: ace, thanks
<fwereade> rogpeppe, everything else just has names (as do the ones with agents too ofc)
<dimitern> mramm: cool, 10x
<mramm> mgz, jam, dimitern: I added ian too, and you should be able to see everything now
<fwereade> rogpeppe, IMO there is something badly wrong when we have entities, that have names, but EntityName means something entirely different
<dimitern> mramm: I can see it yeah
<rogpeppe> fwereade: yeah, i think we're using the word "entity" wrong
<mramm> jam: I didn't realize I could make that change since I had admin on that board, so thanks
<fwereade> rogpeppe, and the only reason we're doing it is because we're not allowed to mention agents :(
 * dimitern => lunch
<fwereade> rogpeppe, despite the existence of a bunch of agent methods already
<mramm> rogpeppe, fwereade, TheMue: you all should be able to see the blue kanban board now too
<fwereade> mramm, so I can; thanks
<TheMue> mramm: Thx
<fwereade> rogpeppe, however, I don't think I am engaging in anything constructive here :( if you can see a way past my mental blockage I will be very happy
<rogpeppe> fwereade: i'm having a go
<fwereade> rogpeppe, I think for now I will just do the Machiner and forget about integration, at least I will accomplish something :)
 * fwereade lunches
<jam> mramm: no problem, thanks for adding us to juju-core
<TheMue> Lunchtime
<jam> mgz, fwereade, TheMue, Aram, rogpeppe, dimitern: are we meeting at https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7# ?
<rogpeppe> jam: i believe we are
<mgz> okay
<jam> mramm: https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7#
<dimitern> ping
 * mramm gets some breakfast -- will be back soon
<rogpeppe> lunch
<rogpeppe> back
<rogpeppe> fwereade:  https://codereview.appspot.com/7071051
<fwereade> rogpeppe, looking
<rogpeppe> fwereade: of course, it's a law of nature that the overall line count goes up, even though we're removing duplicated code :-(
<rogpeppe> fwereade: i think it's nicer though
<rogpeppe> pwd
<fwereade> rogpeppe, from what I've seen so far the clarity is worth it -- and I think it's a step towards an actual reduction one day
<fwereade> rogpeppe, LGTM
<rogpeppe> fwereade: thanks
<rogpeppe> Aram, TheMue, jam, mgz, dimitern: any chance of a second opinion? https://codereview.appspot.com/7071051
 * dimitern looking
<TheMue> *click*
<dimitern> rogpeppe: LGTM - nice and simpler
<rogpeppe> dimitern: thanks
<rogpeppe> dimitern: would you mind replying with your LGTM to the CL, please?
<rogpeppe> dimitern: (i see a blank reply, which i surmise might've been intended to contain something :-])
<dimitern> rogpeppe: hmmm I did enter the LGTM but let me see what went wrong
<dimitern> rogpeppe: done
<fwereade> rogpeppe, dimitern: https://codereview.appspot.com/7069055 is hopefully also trivial
<dimitern> all sorts of crazy stuff is happening with my machine today :(
<rogpeppe> dimitern: thanks. will submit assuming TheMue thinks it's ok.
<rogpeppe> fwereade: looking
<TheMue> rogpeppe: Just sent my LGTM. ;)
<rogpeppe> TheMue: ta!
<fwereade> this is totally irrelevant but utterly awesome:
<fwereade> I see you driving / round town with the girl I love / and I'm like "HAIKU"
<rogpeppe> fwereade: ignoring that :-] i'm not sure that "machiner" is a great name for the code you've put into worker/machiner
<rogpeppe> fwereade: is the plan to expand it, or is the "wait for dying, make dead" thing its full extent?
<fwereade> rogpeppe, well, yeah, it's an awful name, but it's one I thought we had consensus on
<fwereade> rogpeppe, not sure yet
<fwereade> rogpeppe, no *current* plans
<fwereade> rogpeppe, it may or may not end up handling, say, authorized-keys
<rogpeppe> fwereade: for me, "machiner" is what the machine agent does, but that code's only a small part of that
<dimitern> fwereade: looking
<fwereade> rogpeppe, but I think that's probably a different worker's job
<fwereade> rogpeppe, strongly disagree
<fwereade> rogpeppe, the machine agent has always had provisioner and firewaller and suchlike
<fwereade> rogpeppe, the machiner is for the stuff that's directly relevant to a *state.Machine
<fwereade> rogpeppe, or at least that was the logic I inferred
<dimitern> fwereade: done - I like these short CLs
<rogpeppe> fwereade: yes, those are workers within the machine agent
<fwereade> rogpeppe, agreed... machiner and machine agent distinguish the stuff-for-dealing-with-the-machine from the process-that-runs-on-the-machine-and-deals-with-all-sorts-of-things
<rogpeppe> "mr.tomb.Kill(mr.loop())" - i think you should tell Mr Tomb to play nicely with Mr Loop :-)
<fwereade> rogpeppe, haha
<fwereade> rogpeppe, (do you have a better name than machiner? I picked it because (1) AIUI it was already agreed and (2) it saved me inventing a worse name ;))
<rogpeppe> fwereade: i was just wondering about "lifecycler"
<fwereade> rogpeppe, hmm, I think it's have to be MachineLifecycler
<fwereade> rogpeppe, which is a bit icky
<rogpeppe> fwereade: unless it was generic
<rogpeppe> fwereade: which might not be too hard, especially given that the agent types now have "Entity" methods
<fwereade> rogpeppe, but it won;t be, because the machine's handling of lifecycle issues is rather different to that of the uniter, which is the thing responsible for unit lifecycle
<rogpeppe> fwereade: yeah, that is a pity
<fwereade> rogpeppe, I think that trying to split that stuff out of the uniter is a very bad idea
<rogpeppe> fwereade: i'm sure that's true
<rogpeppe> fwereade: that reminds me: have you seen this? http://1.bp.blogspot.com/-OHqQoQLJPQA/UOqyvDiHdjI/AAAAAAAAAeM/u_TJ1vXkTjw/s1600/what-the-british-say.jpg
<fwereade> rogpeppe, IMO it maintains symetry and something close-enough to clarity given what already exists
<fwereade> rogpeppe, yeah, love it
<rogpeppe> fwereade: shouldn't this code wait for the deployer to kill the units before setting the machine to dead?
<rogpeppe> fwereade: ah, but perhaps we can assume that the machine can't be set to dying while there are still units around
<rogpeppe> fwereade: if so, that deserves a comment
<TheMue> rogpeppe: Just merged your latest changed, instead of a hanging loop I now get a panic.
<fwereade> TheMue, that sounds liek progress to me :)
<rogpeppe> lol
<rogpeppe> TheMue: what's the panic?
<fwereade> rogpeppe, but, yeah, that is the case; I'm a touch reluctant to comment things that should be clear from a reasonable understanding of state.Machine, mainly because it's just one more place to re-comment as and when that detail changes
<fwereade> rogpeppe, but I don't feel that strongly
<TheMue> rogpeppe: One moment, will paste it. It's again in the TestProvisionerFirewaller
<TheMue> rogpeppe: http://paste.ubuntu.com/1509698/
<rogpeppe> fwereade: just a single line before EnsureDead should suffice: // It's OK to set the Machine to dead because it can't be set to dying unless it has no units.
<fwereade> rogpeppe, fair enough
<rogpeppe> TheMue: could you push a branch so i can have a look?
<TheMue> rogpeppe: It's during the second run of the Changes() loop, after the first one has an IsNotFound().
<TheMue> rogpeppe: Yep, I'll let my printlns in.
<fwereade> kanban review meeting btw
<fwereade> https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083#
<TheMue> rogpeppe: it's @ lp:~themue/juju-core/007-firewaller-integration
<fwereade> rogpeppe, https://codereview.appspot.com/7035060/ https://codereview.appspot.com/7028049/ https://codereview.appspot.com/7030061/ and the one linked above... https://codereview.appspot.com/7069055
<fwereade> TheMue, the 1st and 3rd of those want for an additional reviewer, if you're of a mind
<TheMue> fwereade: one moment, meeting
<TheMue> fwereade: Back again, so now looking
<rogpeppe> fwereade: all reviewed, i think
<fwereade> rogpeppe, tyvm
<TheMue> rogpeppe: Any idea on the panic?
<rogpeppe> TheMue: ah, sorry, i'd been elsewhere, will have a look
<TheMue> rogpeppe: np, had been elswhere too. ;)
<rogpeppe> TheMue: well, i've found why it's panicing, but it won't help you...
<TheMue> rogpeppe: As long as it allows me to continue error searching. ;)
<rogpeppe> TheMue: BTW for debugging messages, it's usually better to use log.Printf (or c.Logf) rather than println - that way it fits into the usual gocheck logs
<TheMue> rogpeppe: But you miss them w/o at least gocheck.v. And sometime I want to reduce those messages and only have a first narrowing. ;)
<rogpeppe> TheMue: grep is your friend :-)
<TheMue> rogpeppe: They all will be removed before pushing it.
<TheMue> rogpeppe: There are many ways to reach the same goal.
<rogpeppe> TheMue: i think i've found your problem
<TheMue> rogpeppe: I'm listening.
<rogpeppe> TheMue: yup, it's a one line fix
<TheMue> rogpeppe: Great
<rogpeppe> TheMue: the problem is that the machine that's added by TestProvisionerFirewaller doesn't have an instance id
<rogpeppe> TheMue: so the provisioner tries to provision it
<rogpeppe> TheMue: but it's already been provisioned (and the password changed) so we've got two places changing the same password
<rogpeppe> TheMue: (you should've followed my suggestion to print out the passwords :-])
<TheMue> rogpeppe: I wouldn't have been able to interpret that output because I'm not in that mimik.
<rogpeppe> TheMue: adding a SetInstanceId in machine_test.go after the st.AddMachine in addMachine fixes the problem
<TheMue> rogpeppe: Wonderful, thx.
<TheMue> rogpeppe: Yeah, now everything is green.
<fwereade> rogpeppe, re state already having fetched the machine, I don't trust the client not to reuse the machine on another goroutine
<fwereade> rogpeppe, sane/acceptable?
<rogpeppe> fwereade: i think it's ok to pass ownership to the machiner in this case
<rogpeppe> fwereade: hmm, this is where we really want a Clone method
<fwereade> rogpeppe, yeah, indeed, that would make everythig perfectly explicit
<rogpeppe> fwereade: i think we should do it.
<fwereade> rogpeppe, in the meantime I think I prefer habitually telling other goroutines about ids rather than entities
<rogpeppe> fwereade: NewMachiner isn't a goroutine, it's a function
<fwereade> rogpeppe, can I make it a separate CL? no point doing it if I don't actually trawl the codebase for places it'd be useful...
<rogpeppe> fwereade: yeah, i guess
<TheMue> rogpeppe: Btw, both TestChangePasswordChanging still fail.
<rogpeppe> TheMue: fail how?
<rogpeppe> TheMue: in trunk?
<TheMue> rogpeppe: http://paste.ubuntu.com/1510037/
<TheMue> rogpeppe: Will test trunk, one moment.
<rogpeppe> TheMue: the tests work ok for me in trunk
<fwereade> rogpeppe, btw, sorry, I forgot to propose https://codereview.appspot.com/7030061 again :(
<fwereade> rogpeppe, should be trivial now
<TheMue> rogpeppe: Strange, in my trunk  MachineSuite.TestParseUnknown panics.
<rogpeppe> TheMue: it passes for me
<rogpeppe> TheMue: as does the TestChangePasswordChanging tests
<TheMue> rogpeppe: I'll pull a clean trunk.
<rogpeppe> interesting, the jujud tests take 20.941s against tip (ish) and 41.8s against go 1.0.2
<hazmat> fwereade, re previous discussion on charms and relation names. my concern is that this is a change being made which breaks dozens of charms with no benefit since the charms are logically self-consistent, its juju thats imposing the implicit relation which is not addressable by the charm anyways. so in that respect there is no conflict. ie what's the scenario where this is a problem. else this is just breakage for purity.
<fwereade> hazmat, it opens the door to relations that cannot be expressed unambiguously
<fwereade> hazmat, you can't specify a relation over juju-info between two charms that add their own juju-info relations
<fwereade> hazmat, rare but real; just like the run-wrong-hooks problem
<hazmat> fwereade, the implicit is always over provide not on require. we match on interface names not on relation names. the implicit provide is not addressable
 * hazmat tries to restate for clarity
<fwereade> hazmat, `juju add-relation foo:juju-info bar:juju-info` -- if both define their own juju-infos in addition to the implicit ones, what relation are we trying to create?
<hazmat> fwereade, its forbidden to provide juju-info
<hazmat> so its quite explicit in that case
<fwereade> hazmat, everything provides juju-info...
<TheMue> rogpeppe: Now a fresh trunk, doing a go test -gocheck.v in cmd/jujud shows no panic now but lets the password changes fail. :/
<hazmat> fwereade, exactly.. and its only the providing side that we need to restrict
<robbiew> I'm all for open dialogue , but maybe a hangout would improve communication on this subject ;)
<rogpeppe> TheMue: the password changes tests are in state, no?
<fwereade> hazmat, in the example above, both are requires
<TheMue> rogpeppe: No, all in cmd/jujud
<fwereade> hazmat, what should that command do?
<fwereade> hazmat, if it's ok for charms to have require relations named juju-info, and both charms do, that command is ambiguous
<fwereade> hazmat, I know it's breakage; I know it's annoying; but I believe that it is *already* broken
<rogpeppe> TheMue: ah yes. it all passes for me.
<TheMue> rogpeppe: In a fresh pulled trunk?
<rogpeppe> TheMue: yes
<TheMue> rogpeppe: Hmm, I'm using go 1.0.3. And you?
<rogpeppe> TheMue: tip and 1.0.2
<rogpeppe> TheMue: i'll try against 1.0.3, but i don't think it'll make a difference
<TheMue> rogpeppe: No, I don't think so too. Maybe I have to update mgo.
<rogpeppe> TheMue: possibly - i just tried that
<rogpeppe> TheMue: if it still fails then, try printing out the passwords that are being set, and the password and entity name being used to connect to the state.
<hazmat> fwereade, that's pretty convincing from a purity perspective. in practice its quite odd, akin to a subordinate with a subordinate relation.
<TheMue> rogpeppe: Uuugh, ok, but have to find out where I have to do that so that it makes sense.
<rogpeppe> TheMue: see the SetPassword methods in state, and the state.Open function
<hazmat> ie. its only already broken if its already broken ;-)
<fwereade> hazmat, I agree it's a bit odd, but I still have a small part of my brain that wants to charm some sort of automated penetration testing tool (consuming juju-info for private-address), and I think that opens the door
<rogpeppe> fwereade: you've got a LGTM
<hazmat> fwereade, and why would that be a problem?
<hazmat> fwereade, because its non subordinate attaching to subordinate?
<hazmat> via juju-info
<hazmat> the typical non subordinate juju-info usage i use for examples is a dns provider for units
<fwereade> hazmat, even better then -- my point is that once we have someone using implicit juju-info globally we're in danger of hitting that case in practice
<hazmat> fwereade, we can disallow it explicitly for non subordinates without hosing the extant charms
<fwereade> hazmat, that's two explicit workarounds now... I'm not convinced that this is a better way forward than a staged migration to something that works without hacks
<hazmat> the only charms we can fix are those that are owned by charmers..
<fwereade> hazmat, incidentally, what's the situation re charm upgrade sanity in pyjuju?
<hazmat> the rest die or we fork forward
<fwereade> hazmat, eg if v2 of a charm no longer has relation foo
<fwereade> hazmat, sorry derail
<fwereade> hazmat, can I point you to the docs, all the same?
<fwereade> hazmat, https://juju.ubuntu.com/docs/implicit-relations.html
<hazmat> fwereade, the relation would still be extant
<fwereade> hazmat, "Implicit relationships are named in the reserved the juju-* namespace."
<hazmat> fwereade, i'm aware of the docs and the intent, again my concern is breaking dozens of charms
<fwereade> hazmat, and my concern is that layering on the special cases will end up hurting us more in the long run
<hazmat> fwereade, the docs btw also provide an example of what your saying should be illegal, look at the rsyslog metadata
<fwereade> hazmat, I think that's invalidated by the preceding "The charm author should not declare the juju-info relation and is provided here only as an example."
<hazmat> fwereade, your taking that out of context.. provides vs. requires
<hazmat> fwereade, the rsyslog metadata is in the next section
<hazmat> fwereade, the problem is isn't with declaring the provides juju-info.. that
<hazmat> that's not allowed anywhere.
<fwereade> hazmat, that's not how I read it -- but, yeah, maybe arguing from the authority of these docs either way is somewhat weak :)
 * rogpeppe is off for the night. see y'all tomorrow.
<fwereade> gn rogpeppe
<fwereade> hazmat, I feel we're at something of an impasse... we each understand the other's perspective but still think our own should win ;p
<hazmat> fwereade, i'm okay with losing, as long as we figure the way and resources to work  forward on the charms
<hazmat> fwereade,  otoh i don't see the two workarounds offered as inherently problematic given the special case nature where this is an issue
<hazmat> fwereade, are you up for tabling till niemeyer can chime in?
<fwereade> hazmat, yeah, absolutely
<fwereade> hazmat, I'm doubtless overvaluing code clarity vs charmer convenience to some degree, but I can't tell how much ;)
<fwereade> hazmat, perhaps because I don't have a clear picture of just how much inconvenience it will cause
<hazmat> fwereade, its not a charmer convenience, its breaking working software..
<fwereade> hazmat, I think we can find a path that doesn't break anything so long as the charms provide a sane upgrade path
<fwereade> hazmat, and I favour that primarily because it gives us a way to consign the difficulty to the dustbin of history, rather than carrying it forward forever -- but, yeah, consider it shelved :)
<hazmat> fwereade, cool
<hazmat> does anybody know a good full text search lib for go.. not finding much by way of googling for such
#juju-dev 2013-01-09
<fwereade> TheMue, rogpeppe1, mornings
<TheMue> fwereade: Hiya
<fwereade> TheMue, rogpeppe1: I have a philosophical uncertainty, perhaps one of you can explain why we distinguish between dead and not found
<TheMue> fwereade: In a fresh pulled trunk, is go test in .../cmd/jujud working for you?
<TheMue> fwereade: Dead IMHO already has existed while not found may not be yet there.
<fwereade> TheMue, it was last night, let me doublt check
<TheMue> fwereade: Thx
<TheMue> fwereade: I pulled a fresh one too due to remaining errors and have those errors with the password changing there too.
<fwereade> TheMue, but I don't see what the justification *is* for distinguishing those cases
<fwereade> TheMue, still works for me :(
<fwereade> TheMue, take remove-unit
<fwereade> TheMue, if a unit is Dying/Dead it's fine to "remove" it again
<TheMue> fwereade: Hmm, strange. Standard mongo or a special one?
<fwereade> TheMue, but there's a specific point at which that becomes invalid
<rogpeppe1> fwereade: morning
<fwereade> TheMue, I think I'm using the usual special mongo -- is there maybe a more-recently built one that you have but I don't?
<TheMue> rogpeppe1: Heyhey
<fwereade> rogpeppe1, heyhey
<rogpeppe1> fwereade: do you think we should return not found when something's dead?
<TheMue> fwereade: That may be the reason.
<TheMue> fwereade: *gnarf* I can't remember where to get the special one.
<rogpeppe1> TheMue: the URL is in environs/cloudinit/cloudinit.go :-)
<fwereade> rogpeppe1, heh... the trouble is, not *always*... but the number of cases in which we do want to return dead enitities is vanishingly small
<TheMue> rogpeppe1: Well hidden documentation. ;)
<rogpeppe1> fwereade: when *do* we want to return dead entities?
<fwereade> rogpeppe1, deployers are responsible for removing dead units; provisioners are responsible for removing dead machines
<fwereade> rogpeppe1, I *think* that's an exhaustive list
<rogpeppe1> fwereade: well, those are two reasons we *do* need to distinguish between dead and not found...
<fwereade> rogpeppe1, they seem to me to be very special cases
<rogpeppe1> fwereade: what do you think we should do in the other cases?
<fwereade> rogpeppe1, the trouble is that I don't know
<fwereade> rogpeppe1, but remove-unit is making me a bit suspicious
<fwereade> rogpeppe1, why is it ok to remove a Dying or Dead unit, but not one that doesn't exist?
<rogpeppe1> fwereade: i'd be happy if we did the same thing for a dead unit as we do for a unit that doesn't exist
<rogpeppe1> fwereade: you're just implementing remove-unit, i presume
<fwereade> rogpeppe1, looking at it in order to disallow direct subordinate removal, yeah
<rogpeppe1> fwereade: you mean destroy-unit, presumably :-)
<fwereade> rogpeppe1, yeah ;p
<fwereade> rogpeppe1, so, ok, why allow removal of Dying units?
<rogpeppe1> fwereade: the issue, i suppose, is that if you don't distinguish the cases, you can do destroy-unit dsknslv/345 and it'll work
<fwereade> rogpeppe1, ISTM that "each entity may only be destroyed once" makes sense
<fwereade> rogpeppe1, in which case Dying should also be disallowed
<rogpeppe1> fwereade: that would be reasonable too, i suppose
<fwereade> rogpeppe1, *or* that destroy-unit should be seen as almost declarative -- "I require that no unit name burble/123 exist -- make it so"
<rogpeppe1> fwereade: i wouldn't mind a different error message when killing a dying unit vs killing a dead or removed unit though
<fwereade> rogpeppe1, if no so named unit exists, nbd, why complain?
<rogpeppe1> fwereade: yeah, they're both reasonable approaches
<fwereade> rogpeppe1, but we're kinda mixing them :(
<rogpeppe1> fwereade: yes, i agree that's probably wrong
<rogpeppe1> fwereade: the problem is if you make a typo trying to remove a unit - you won't get told if you get it wrong.
<rogpeppe1> fwereade: (with the declarative approach)
<fwereade> rogpeppe1, yeah... but with the other approach a perfectly sensible destroy request can be borked by a parallel destroy request for just one of the units you're trying to destroy
<rogpeppe1> fwereade: yes, but perhaps that's as ok as it is when removing files
<fwereade> rogpeppe1, mmmaybe :)
<rogpeppe1> fwereade: pity we've already got --force and it means something different, otherwise we could have -f mean "don't complain if it's already gone" like rm
<fwereade> rogpeppe1, yeah, I think you're right
<fwereade> rogpeppe1, actually we *don't* have --force yet
<rogpeppe1> fwereade: but we will
<fwereade> rogpeppe1, yeah, but it doesn'thave a named already baked into reality, so we're a lot more free to tweak it now ;p
<rogpeppe1> fwereade: doesn't the python version have --force?
<fwereade> rogpeppe1, hm, I didn't think it did
<fwereade> rogpeppe1, I think python just removes the node and hopes the unit agent can pick up the pieces
<rogpeppe1> fwereade: maybe it doesn't. but anyway, we know roughly what semantics we want from --force, i think, and just silencing not-found errors isn't as useful...
<fwereade> rogpeppe1, if we do everything right, --force will not be useful at all
<rogpeppe1> fwereade: isn't the point of --force that it can work if a node is isolated or hung up and can't take itself down?
<fwereade> rogpeppe1, the point of --force is to decref refs that are not being decced due to hopelessly broken code, I think
<rogpeppe1> fwereade: that's what i mean
<fwereade> rogpeppe1, if the node is isolated it will not respond to being Dead any better or worse than it will to Dying
<fwereade> rogpeppe1, ah, probably, sorry
<rogpeppe1> fwereade: "hopelessly broken" might be "i poured some water on the machine"
<rogpeppe1> fwereade: but anyway, that's a much more useful semantic than ignoring not-found errors
<TheMue> rogpeppe1: Found that I already had downloaded the special mongo, but seem to have been interrupted when installing it. I still had the original package.
<fwereade> rogpeppe1, if it's just that the hardware is a smoking crater, we can handle that
<rogpeppe1> fwereade: really? how do we do that?
<fwereade> rogpeppe1, assuming the provider knows about it, the PA will redeploy the unit to a fresh instance
<rogpeppe1> fwereade: really? how does it know when it's appropriate to do that?
<fwereade> rogpeppe1, when there's no actual instance for a machine with an instance id set
<fwereade> rogpeppe1, doesn't it?
<rogpeppe1> fwereade: the instance may well be still around
<rogpeppe1> fwereade: depends on the failure mode
<TheMue> rogpeppe1: Could you send me your init script for mongod? Would be faster. ;)
<rogpeppe1> TheMue: my init script?
<fwereade> rogpeppe1, yeah, but its ability to cause trouble is strictly curtailed by the fact that the PA will set a new password
<TheMue> rogpeppe1: Or how do you start mongod locally?
<fwereade> rogpeppe1, (btw what happens if your password changes mid-connection? do you get kicked off?)
<fwereade> rogpeppe1, (I presume not)
<fwereade> rogpeppe1, (hmm)
<rogpeppe1> TheMue: the test suite starts mongod
<fwereade> TheMue, I just have the fancy mongo in ~/bin and have that at the front of my $PATH
<rogpeppe1> fwereade: i don't think you do get kicked off, though i remember having that question before and i can't quite remember for sure the answer
<fwereade> rogpeppe1, ah! you don't I'm sure
<fwereade> rogpeppe1, we set new passwords in jujud and just keep going
<fwereade> rogpeppe1, haven't spotted even long-running agents falling over as a result
<fwereade> rogpeppe1, bah
<rogpeppe1> fwereade: anyway, the question is how the provisioner can tell that a unit is borked when the provider can't tell that
<fwereade> rogpeppe1, that said, that's something that can be handled by the API I guess
<TheMue> rogpeppe1: Ah, interesting, because I didn't had that, only the standard mongo running by the standard init script at boot time (may be the cause for the troubles too). And the test suit never complained.
<rogpeppe1> TheMue: the test suite always starts its own mongod
<fwereade> rogpeppe1, it does indeed depend on the failure mode
<rogpeppe1> TheMue: it runs it from your $PATH
<rogpeppe1> fwereade: so that's the common use case i see for destroy-unit --force
<TheMue> rogpeppe1: Yes, and it doesn't cares if it is the special version or not.
<rogpeppe1> TheMue: it can't tell
<rogpeppe1> TheMue: (maybe it should actually - it could probably find out)
<fwereade> rogpeppe1, forgive my slowness this morning... please describe a specific use case that you are thinking of
<fwereade> rogpeppe1, or restated -- "what classes of borkenness we are concerned with re --force"?
<TheMue> rogpeppe1: Yes, so one reminder to me to finish started installations. ;)
<rogpeppe1> fwereade: some machine hangs up (a common enough occurrence if my laptop is anything to go by). the provider can't tell this has happened, so the deployer can't, so we need destroy-unit --force, no?
<fwereade> rogpeppe1, hmm, if a machine hangs up I think that's a job for destroy-machine --force, and some tricky questions re reqssignment of units
<fwereade> rogpeppe1, maybe it's ok to require manual forced unit removal before allowing the forced machine removal? not sure
<rogpeppe1> fwereade: hmm, yes. i dunno.
<rogpeppe1> fwereade: i think destroy-machine --force should probably do all it can to remove everything on the machine and the machine itself
<rogpeppe1> fwereade: maybe don't need destroy-unit --force
<fwereade> rogpeppe1, yeah that sounds sane actually
<fwereade> rogpeppe1, at least while we don't have any control over unit assignment
<rogpeppe1> fwereade: i'm not sure about the whole idea of reassigning units tbh
<fwereade> rogpeppe1, yeah, nor am I
<fwereade> rogpeppe1, ok, I think we're off in the weeds
<rogpeppe1> fwereade: yup!
<fwereade> rogpeppe1, I'm going to start complaining about destruction of anything non-alive
<rogpeppe1> fwereade: sounds good
<fwereade> rogpeppe1, that's the closest match to python behaviour
<fwereade> rogpeppe1, now I come to think of it :) ^^
<fwereade> rogpeppe1, thanks :)
<jam> rogpeppe1: /wave
<rogpeppe1> jam: yo
<rogpeppe1> jam: shall we?
<jam> rogpeppe1: I think martin also wanted to sit in, and I don't see him around yet.
<jam> (which is a bit surprising, but maybe we'll see him shortly)
<rogpeppe1> jam: ah yes, that's worth doing
<jam> weird, I see w7z disconnect 3 hours ago, but nothing about things reconnecting. So we might as well have our chat. Let me set up a hangout
<rogpeppe1> anyone else fancy talking about go package versioning?
<jam> rogpeppe1, dimitern https://plus.google.com/hangouts/_/472c54386502b014c99e35ebd97a6b172f13c02b?authuser=2&hl=en#
<jam> though dimitern is grabbing some food for 15 min
<jam> so we can take it slow :)
<TheMue> rogpeppe1: I'm getting crazy! *grmplfx*
<TheMue> rogpeppe1: Now I removed the standard mongo and installed the special mongo in the hope that it may be one reason.
<dimitern> jam, rogpeppe1: I'm ready - joininh
<TheMue> rogpeppe1: First test run afterwards, Machine password change passed, but Unit failed.
<TheMue> rogpeppe1: Second run, Machine failed, Unit passed.
<TheMue> rogpeppe1: Third run, both failed. *aaaaaaaaaaaaaargh*
<TheMue> rogpeppe1: And all on a fresh pulled trunk (808).
 * TheMue loves those kind of errors.
<TheMue> rogpeppe1: Even more strange, when MachineSuite.TestChangePasswordChanging fails there are two different asserts from run to run while UnitSuite.TestChangePasswordChanging always fails at the same point (in bootstrap_test.go, like one of the two MachineSuite failures).
<rogpeppe1> TheMue: on a call
<jam> mgz: https://plus.google.com/hangouts/_/472c54386502b014c99e35ebd97a6b172f13c02b?authuser=2&hl=en#
<TheMue> rogpeppe1: ok
<jam> if you want to chat about the versioning stuff.
<mgz> jam, ta
<TheMue> rogpeppe1: and I now know which one. ;)
<fwereade> aw, bugger, I thought it was weird that Unit.EnsureDying didn't need changes... of course it does
<jam> mgz: where did you go?
<rogpeppe1> TheMue: you're sure that you're using the proper version of mgo
<rogpeppe1> ?
<mgz> didn't run upstairs quite fast enough :)
<TheMue> rogpeppe1: Now yes, because I removed the original one I once had installed with apt.
<TheMue> rogpeppe1: I'm especially wondering about this non-deterministic behavior.
<rogpeppe1> TheMue: you've checked with the which command, yes?
<rogpeppe1> TheMue: that does seem odd, right enough
<rogpeppe1> TheMue: could you paste an error log from when the tests fail?
<TheMue> rogpeppe1: yep, and there is only the version i just fetched with wget from the localtion in cloudinit.
<TheMue> rogpeppe1: sure, one moment.
<rogpeppe1> TheMue: sounds like the problem isn't with mgo then... probably :-)
<TheMue> rogpeppe1: hehe, mongo as source has been my hope, but no
<rogpeppe1> TheMue: it's weird that nobody else seems to be able to reproduce the same problems
<TheMue> rogpeppe1: and it's no side effect of my changes, they are in a different branch and i'm here testing on fresh pulled trunks to just get rid of those errors
<TheMue> rogpeppe1: maybe the reason is in my environment as i'm running it in a vm
<rogpeppe1> TheMue: i'm wondering about that
<TheMue> rogpeppe1: http://paste.ubuntu.com/1512321/
<TheMue> rogpeppe1: here both fail the same way. i'll try to reproduce the other failure for the MachineSuite
<fwereade> rogpeppe1, quick sanity check: I was planning to make unit.EnsureDying cause the subordinates to become Dying too, but that's actually annoyingly complex
<fwereade> rogpeppe1, I think it's smarter to add to the uniter filter such that subordinates keep a watch on their principal and set themselves to Dyingwhen it becomes Dying
<fwereade> rogpeppe1, with the caveat that I am not thinking about remove-unit --force at this time
<fwereade> rogpeppe1, sane?
<rogpeppe1> fwereade: i think that seems reasonable
<rogpeppe1> TheMue: could you change the places in the code i suggested yesterday to print out the passwords when connecting and changing them?
<TheMue> rogpeppe1: the other one is http://paste.ubuntu.com/1512325/
<TheMue> rogpeppe1: yep
<fwereade> rogpeppe1, actually, better yet: principal sets its own subordinates to Dying once it knows it's Dying
<rogpeppe1> fwereade: yes, that's better.
<rogpeppe1> fwereade: and works nicely in the face of crashes
<fwereade> rogpeppe1, yep -- cool, thanks
<TheMue> rogpeppe1: http://paste.ubuntu.com/1512352/ now has debug statements for the password setting in it
<fwereade> rogpeppe1, TheMue: https://codereview.appspot.com/7058061
<TheMue> fwereade: *click*
<rogpeppe1> TheMue: could you also add a debug statement in State.Open saying what entity name and password are being connected with?
<TheMue> rogpeppe1: will change it, the pw is already in
<TheMue> rogpeppe1: eh, entity name?
<rogpeppe1> TheMue: info.EntityName
<TheMue> rogpeppe1: oh, yes, missed it.
<TheMue> rogpeppe1: this time i also had again the different machine fail -> http://paste.ubuntu.com/1512362/
<mgz> jam: put the bucket for mongo things in the readme as well as you suggested, want to double check it and approve the mp?
<mgz> or the rietveld version of the same...
<jam> mgz: I'm not seeing the MP
<jam> nm, I think I saw it
<jam> mgz: btw, you need to run 'lbox propose' again to update the reitveld data, you can't just 'bzr push' to launchpad.
<jam> (lbox propose will do the push for you, if you only want 1 step)
<mgz> ran it without -cr
<mgz> let
<mgz> 's see what happens...
<mgz> 403... wonder if I just tyoped the password
<mgz> nope, worked fine with same creds re-ran with -cr
<mgz> joyous.
<TheMue> fwereade: you've got a lgtm
<rogpeppe1> TheMue: try putting this log statement after the ReadFile in the openState function in cmd/jujud/agent.go
<rogpeppe1> log.Printf("agent open state, initial password %q; password in file: %q",  conf.InitialPassword, data)
<TheMue> rogpeppe1: ok
<rogpeppe1> TheMue: it looks like the agent isn't changing the password as it should be, and i'm not sure why
<TheMue> rogpeppe1: hehe, this time machine worked, but unit still failed: http://paste.ubuntu.com/1512425/ (changed it from printf to debug btw).
<rogpeppe1> TheMue: which is the line that i suggested above?
<rogpeppe1> TheMue: or isn't it showing up?
<TheMue> rogpeppe1: oh, seen it in a first run. will repeat it.
<rogpeppe1> TheMue: (i'm not sure what you mean by changing from printf to debug)
<TheMue> rogpeppe1: only that i used Debugf instead of Printf
<TheMue> rogpeppe1: http://paste.ubuntu.com/1512450/
<TheMue> rogpeppe1: wife just called me to lunch, back in a few moments
<TheMue> rogpeppe1: so, back again
<rogpeppe1> TheMue: try this branch and see what it prints: lp:~rogpeppe/+junk/jujud-debug
<TheMue> rogpeppe1: ok, will do
<rogpeppe1> TheMue: (it works fine on my machine, but i'm presuming it'll fail on yours)
<TheMue> rogpeppe1: and i sadly think you're right :)
<rogpeppe1> TheMue: that's good, actually. at least the bug is reproducible
<TheMue> rogpeppe1: here we are, as expected: http://paste.ubuntu.com/1512566/
<rogpeppe1> TheMue: that's a bit bizarre - i don't see any of the printfs from within openState in agent.go
<TheMue> rogpeppe1: that "agent open state, initial â¦"?
<rogpeppe1> TheMue: yes
<rogpeppe1> TheMue: i don't see that in the log output, but i'd expect to
<rogpeppe1> TheMue: have you tried removing the pkg directory from the gopath root and rebuilding? i'm starting to suspect some kind of build anomaly
<TheMue> rogpeppe1: took a look, found it in the source.
<TheMue> rogpeppe1: will do
<TheMue> rogpeppe1: but it shows me the recompilation each time
<rogpeppe1> TheMue: yeah, i dunno.
<rogpeppe1> TheMue: but i can't understand why i wouldn't see those log messages
<TheMue> rogpeppe1: so, next run, removed it and also looked into /tmp
<rogpeppe1> TheMue: what's the value of your $GOPATH, and what's your current directory?
<TheMue> rogpeppe1: look, first and second run are different, and i changed nothing inbetween => http://paste.ubuntu.com/1512599/
<TheMue> rogpeppe1: and here are path, dir and command => http://paste.ubuntu.com/1512608/
<rogpeppe1> TheMue: try pulling and running again
<rogpeppe1> TheMue: same branch
<rogpeppe1> TheMue: (i'm pretty sure i've found the problem and the fix)
<TheMue> rogpeppe1: ok
<TheMue> rogpeppe1: *thumbsPress*
<rogpeppe1> TheMue: i thought we'd fixed this issue ages ago - perhaps the branch never got through to completion
<TheMue> rogpeppe1: for true { hug(rogpeppe1); }
<rogpeppe1> TheMue: cool
<TheMue> rogpeppe1: three times, no failure!
<rogpeppe1> TheMue: i'll submit a CL
<TheMue> rogpeppe1: great, you're a fantastic guy
<TheMue> rogpeppe1: ah, the old version of the for loop may cause that runOnce() is never called?
<rogpeppe1> TheMue: yup
<rogpeppe1> TheMue: because the tomb is killed before we get to the loop. (that's the racy bit)
<TheMue> rogpeppe1: that's itchy :D
<rogpeppe1> TheMue: it's not a race that matters for anything other than the tests...
<TheMue> rogpeppe1: interesting that it happened only here
<rogpeppe1> TheMue: yeah, that'll be because of your VM
<TheMue> rogpeppe1: so thankfully to Daves reject of my Firewaller change i stumbled over it ;)
<rogpeppe1> TheMue: i'm surprised you weren't seeing the issue before - it's nothing new.
<rogpeppe1> TheMue, fwereade: https://codereview.appspot.com/7067056
<TheMue> rogpeppe1: i have to admit that i'm not very often run the whole suites. but now i'll do it more.
<rogpeppe1> TheMue: you should always run the whole suite :-)
<rogpeppe1> TheMue: and the live tests too, if what you're doing might impact them
<TheMue> rogpeppe1: sure
<fwereade> rogpeppe1, click; but, whoops, late:
 * fwereade => lunch
<fwereade> rogpeppe1, dimitern: if either of you are interested, https://codereview.appspot.com/7058061/ is up
 * dimitern looking
<fwereade> rogpeppe1, dimitern: and I think https://codereview.appspot.com/7065061 may be trivial
<dimitern> fwereade: done
<dimitern> fwereade: that's the same CL
<dimitern> fwereade: oops, i'm blind :) sorry
<fwereade> dimitern, ;p
<fwereade> mramm, may I skip the kanban meeting? I need to keep half an eye on laura for a bit,I suspect it will become complex
<fwereade> mramm, I will update my cards right now ;)
<mramm>  fwereade: that's fine
<dimitern> fwereade: the other one is done as well
<mramm> you sent a status update e-mail, and updated the cards -- I think that is sufficent!
<fwereade> dimitern, <3
<dimitern> mramm: I want to pop in to the kanban meeting to listen
<mramm> dimitern: sure.   I'll send you the hangout invite...
<fwereade> mramm, cheers
<dimitern> mramm: 10x
<fwereade> dimitern, concur trivial on the latest?
<dimitern> fwereade:  708061 ?
<dimitern> that's 758061
<dimitern> aaagr 7058061 :)
<dimitern> fwereade: it still looks good and trivial to me
<fwereade> dimitern, cheers
<TheMue> rogpeppe1: your hint with the password is good. it is changed twice on a machine, but the opening of the entity is done with the first one. so i'll now find out where it is set the first time and where the second time.
<fwereade> rogpeppe1, TheMue, dimitern: https://codereview.appspot.com/7063055 is basically trivial I think
<rogpeppe1> fwereade: reviewed
<fwereade> rogpeppe1, tyvm
<TheMue> rogpeppe1: may you help me with some stack output? i now have found how a machine pw is set twice, but the older one shall be used.
<rogpeppe1> TheMue: sure. do you want my little function?
<TheMue> rogpeppe1: I first sho you my output, maybe it's enough for you, otherwise yes, thank you.
<TheMue> rogpeppe1: http://paste.ubuntu.com/1513480/
<TheMue> rogpeppe1: interesting are lines 1, 46 and 61. first set and used correctly, then set again, but then still try to use the former pw.
<rogpeppe1> can you push the branch that this happens on, please? (so i can see the code the stack trace is referring to)
<rogpeppe1> TheMue: ^
<TheMue> rogpeppe1: sure
<TheMue> rogpeppe1: here it is lp:~themue/+junk/firewaller-integration
<rogpeppe1> TheMue: it looks like it's the same instance id problem to me
<TheMue> rogpeppe1: huh, the instance id is set (i hope i haven't looked into the wrong version).
<rogpeppe1> TheMue: the problem is at line 46
<rogpeppe1> TheMue: it's setting machine 0's password
<TheMue> rogpeppe1: yes
<rogpeppe1> TheMue: and if you look at the stack, that's happening within Provisioner.processMachines - startMachines(pending)
<rogpeppe1> TheMue: and pending can only be added to if the machines have no instance id
<rogpeppe1> TheMue: hmm, i wonder if there's a race here. perhaps you're adding a machine while the provisioner is active.
<rogpeppe1> TheMue: you could use InjectMachine
<fwereade> rogpeppe1, I don;t think there's a mystery -- if the machine doesn't have an instance ID the provisioner is justified in provisioning one for it
<fwereade> rogpeppe1, regardless of the fact that the provisioner is actually running on that machine
<rogpeppe1> fwereade: we are setting an instance id for the machine, immediately after adding it.
<TheMue> fwereade: but we're settign it
<rogpeppe1> TheMue: i think you should use State.InjectMachine
<rogpeppe1> TheMue: which doesn't have the same add-then-set race possibility, so the provisioner can't grab it
<TheMue> rogpeppe1: i'll take a look
<fwereade> rogpeppe1, TheMue: if you're setting it before starting the provisioner that surely indicates a provisioner bug?
<rogpeppe1> fwereade: yes
<rogpeppe1> fwereade: but i'm not sure that's the case
<fwereade> rogpeppe1, ah ok
<TheMue> rogpeppe1: huh, it seems that setting the id has gone when pulling it. *gnarf*
<TheMue> rogpeppe1: just compared it to my backuped code.
<TheMue> rogpeppe1: aaaaaaargh, please don't listen to me anymore. i'm wearing sackcloth and ashes. *sigh*
<rogpeppe1> TheMue: found the problem?
<TheMue> rogpeppe1: mixed up my branches.
<fwereade> rogpeppe1, I have a thought that may be crack
<TheMue> rogpeppe1: yes, it has been the instance id, as you said. but i looked before into the saved branch. so i have been sure it is in.
<fwereade> rogpeppe1, one of the things that is getting me down about removing AUST entirely is the hassle of having to set a unit address before a RelationUnit can enter scope
<rogpeppe1> TheMue: nonetheless, it might be sensible to use InjectMachine
<TheMue> rogpeppe1: no i set it again properly in addMachine() and everything is fine.
<rogpeppe1> fwereade: AUST?
<fwereade> rogpeppe1, AddUnitSubordinateTo
<TheMue> *rofl*
<rogpeppe1> fwereade: of course, sory
<rogpeppe1> r
<fwereade> rogpeppe1, and ISTM that it might be defensible to have EnterScope(setting map[string]interface{}) error
<fwereade> rogpeppe1, but the intended semantics take a bit of thought
<rogpeppe1> fwereade: what would it do?
<fwereade> rogpeppe1, iff a scope document is created, overwrite the settings doc with the contents of the supplied settings
<fwereade> rogpeppe1, (or create it)
<fwereade> rogpeppe1, (that is the proposal, anyway; other schemes make make sense)
<fwereade> rogpeppe1, doing this saves about 100 lines in the tests, because I can just do EnterScope(nil) where I had EnterScope ;p ;p
<hazmat> fwereade, are there any vol manage docs extant?
<fwereade> hazmat, nothing
<hazmat> fwereade, ack, just fielding some questions from ops
<fwereade> hazmat, crap -- the plan was always that niemeyer and I would sit down and hash something out... well, round about now, but it's pushed back by an unknown amount
<rogpeppe1> fwereade: why is it a particular hassle to set a unit address?
<fwereade> rogpeppe1, it's 2 lines of code that is totally irrelevant to the purpose of the test, repeated all over the place
<fwereade> rogpeppe1, at best it's irritating, at worst it's confusing
<hazmat> fwereade, mramm so its likely on the at risk for moving past 13.04 re vol?
<TheMue> interesting, now i've got no more hanging code and in 9 of 10 runs it passes (the one test function), but then one assert fails.
<hazmat> fwereade, no worries, just trying to get clarity about what we're ack is on the roadmap for 13.04
<hazmat> we're acking
<fwereade> hazmat, I think a definitive answer to that will emerge during the austin sprint
<mramm> fwereade: hazmat: we will probably have to trim the 13.04 list somewhere
<mramm> fwereade: hazmat: we will probably have to trim the 13.04 list and austin is where we decide exactly where we trim
<rogpeppe1> fwereade: so your idea is that EnterScope would change the unit's settings?
<mramm> fwereade: hazmat: and perhaps how we re-allocate resources to best meet our goals
<fwereade> rogpeppe1, no -- just the relation unit settings, as it already does
<fwereade> rogpeppe1, my proposal leads it in a slightly less crackful direction
<fwereade> rogpeppe1, ATM, first enter scope will set private-address and never touch it again
<fwereade> rogpeppe1, with this change a fresh entry to scope (ie returning after leaving) will clear outdated settings
<rogpeppe1> fwereade: i'm afraid i'm not entirely clear on the relationship between unit settings (is there such a thing) and relation unit settings
<fwereade> rogpeppe1, ah ok -- I thought you meant "contents of the unit doc itself"
<rogpeppe1> fwereade: ah, i think i see.
<fwereade> rogpeppe1, yes, units only have "settings" in the context of a relation
<rogpeppe1> fwereade: you want to make private-address less special
<fwereade> rogpeppe1, yes -- it's still special, but its specialness should happen in uniter instead of in state
<rogpeppe1> fwereade: and provide a general facility to have settings that are available immediately a relation is created
<fwereade> rogpeppe1, exactly
<rogpeppe1> fwereade: emphatic +1 to that
<fwereade> rogpeppe1, sweet, tyvm
<rogpeppe1> fwereade: because we may very well provide other settings that are always available, in the future
<fwereade> rogpeppe1, indeed so
<rogpeppe1> fwereade: just a thought, looking at the code:
<rogpeppe1> fwereade: isn't it a bit potentially problematic, in EnterScope, that we do readSettings, then add an op that asserts docMissing only if that's true?
<rogpeppe1> s/that's true/they weren't found/
<rogpeppe1> fwereade: do relation settings persist from leaving a scope to entering a scope again?
<fwereade> rogpeppe1, I think they shouldn't
<fwereade> rogpeppe1, but they currently do
<rogpeppe1> fwereade: ah
<fwereade> rogpeppe1, there's no actual facility for re-entering scope ATM
<fwereade> rogpeppe1, but I have rough agreement with niemeyer that there's no good reason to forbid it
<rogpeppe1> fwereade: in that case the logic should be simpler - just create the doc with the right settings
<fwereade> rogpeppe1, *however*, if the unit is re-entering any settings from the previous bunch of hooks should, I think, be presumed to be invalid
<rogpeppe1> fwereade: surely the settings should be removed when leaving the scope?
<allenap> mramm: Hi there, can Red Squad (allenap, rvb, julian-edwards, jtv) join the ~juju team?
<fwereade> rogpeppe1, the wrinkle is that a unit that has ever entered a scope must retain *some* settings forever
<rogpeppe1> fwereade: orly?
<rogpeppe1> fwereade: which ones?
<fwereade> rogpeppe1, yeah -- any other unit might be running late on hook processing and have a perfectly legitimate reference to that unit according to its own timeline
<fwereade> rogpeppe1, if it doesn't have cached settings, it will want to get them
<fwereade> rogpeppe1, (to be explicit, the ones it must retain are the latest known legitimate settings)
<rogpeppe1> fwereade: is there such a thing as an illegitimate setting?
<fwereade> rogpeppe1, yes: IMO, once we re-enter scope, old settings are illegitimate
<fwereade> rogpeppe1, say you create a new random password on relation-joined
<fwereade> rogpeppe1, when we enter, we're expecting to run a relation-joined, and it seems much better not to have a bad value lying around: it makes it much harder for the units on the other side
<rogpeppe1> fwereade: so you want to overwrite any existing settings, creating the doc if necessary
<fwereade> rogpeppe1, yes -- if and only if I'm also creating the scope doc that txn
<fwereade> rogpeppe1, otherwise we assume that the hooks will handle whatever changes need to be made
<fwereade> rogpeppe1, still sounding sane?
<rogpeppe1> fwereade: sounds reasonable, although i don't understand all the implications
<rogpeppe1> fwereade: assuming it's not too hard to do in a transaction
<fwereade> rogpeppe1, I don't think it's any more complex than the existing EnterScope, just different
<rogpeppe1> fwereade: cool
 * rogpeppe1 is off for the night. nght all.
<hazmat> robbiew, forwarded you an email that was a cause to the thread on the juju list (which i'm also writing up a reply to)
<davecheney> mramm: ping
<mramm> davecheney: pong
<fwereade> davecheney, ping
<fwereade> ha
<davecheney> mramm: g+ or skype ?
<fwereade> davecheney or mramm: very briefly, is there a way I can get a list of the bugs fixed in juju-core since the last release?
<mramm> davecheney: I'm in the G+ but I don't mind skype
<davecheney> fwereade: i looked at the 1.9.6 milestone, nothing useful there
<fwereade> davecheney, likewise -- I guess I should have been retargeting my bugs to that as I did them
<fwereade> davecheney, I'll try to be cleverer
<davecheney> fwereade: bzr log after rev 796 will be the best solution
<davecheney> mramm: g+ sucks balls
<davecheney> you are never online for me
<mramm> hmm
<davecheney> is there another mark ramm I dont' know about ?
<mramm> well, there is mark canonical ramm-christensen
<mramm> the hangout I'm in is https://plus.google.com/hangouts/_/8135680b0c8e4091160281dd5651402e2bec7133
<mramm> which is linked in the meeting
<davecheney> that one invites the wrong dave cheney
<davecheney> screw it, skype is easier
<davecheney> fwereade: will do release notes this morning and send them to you
<fwereade> davecheney, I'm noting subordinate state down for you
<fwereade> davecheney, I just wanted to check whether I'd done anything else worth mentioning
<davecheney> you can explain what works and what doesn't work
<fwereade> davecheney, sent; let me know if it needs clarification, I'm not sleeping *quite* yet
<davecheney> fwereade: thank you
<davecheney> dont' worry, i'll do the release over the weekend so there is no rush
<fwereade> davecheney, offhand, do you know how to express "completely replace the contents of this document" in mgo/txn?
#juju-dev 2013-01-10
<jam> dang, just missed fwereade
<rogpeppe1> jam: surely he wasn't up all night?
<rogpeppe1> jam: morning, BTW!
<jam> well he disconnected ~1.5hrs ago, just about 15 min before I went looking for him.
<jam> hi fwereade
<jam> hi rogpeppe1
<TheMue> btw, morning all
<jam> apparently I keep scaring fwereade away :0
<mgz> :)
<fwereade> jam, hey, sorry :)
<fwereade> jam, didn't even realise I was disconnected
<fwereade> jam, what can I do for you?
<fwereade> TheMue, rogpeppe1: heyhey
<rogpeppe1> fwereade: heya
<jam> fwereade: I was noticing you had a patch that landed with only 1 review. I'm guessing that was because you felt it was trivial. But I just wanted to check with you.
<jam> (My personal feeling is that requiring 2 +1's is too much, but I'd rather other people feel the pain of it to understand why I feel that way :)
<TheMue> rogpeppe1: your stack trace hint has been good, thank you. so i yesterday evening have been able to place those on the right locations and this morning i analyzed the output. and i found a pattern when the test fails and could fix it in the firewaller.
<fwereade> jam, yeah, that's right, confirmed trivial in IRC
<TheMue> rogpeppe1: now i'm doing some more tests, but it looks good.
<rogpeppe1> TheMue: glad to hear it
<fwereade> jam, I though I said trivial in the CL description
<TheMue> fwereade: heya
<jam> fwereade: you did mention that. It wasn't immediately clear what that meant. (I haven't heard it discussed that trivial patches only need 1 review.)
<fwereade> jam, I'm not sure it's written down anywhere but it's been part of the team culture since I joined, I think
<rogpeppe1> fwereade: tbh i think that particular CL was verging on the non-trivial (it's not usual to put substantial code blocks in export_test.go) but given where it was going, i don't mind.
<fwereade> rogpeppe1, ah, sorry -- I'm working to remove the need for that even now
<fwereade> rogpeppe1, although really I should be more release-focused, hmm
<rogpeppe1> fwereade: cool, thought so
<TheMue> so, back, sorry for being afk. while we talked about the sleeping troubles with young children yesterday the troubles simetimes grow with the age. our are now almost 17 and 19 and have troubles with school and job. *sigh*
<fwereade> rogpeppe1, https://codereview.appspot.com/7058061 addressed
<rogpeppe1> fwereade: reviewed
<fwereade> rogpeppe1, thanks
<fwereade> morning Aram
<Aram> hey there.
<rogpeppe1> fwereade: trivial: https://codereview.appspot.com/7064064
<fwereade> rogpeppe1, LGTM, concur trivial
<rogpeppe1> fwereade: ta
<rogpeppe1> fwereade: Aram: could you register with gravatar? it would be nice to be able to see kanban card ownership at a glance.
<Aram> rogpeppe1, but I did.
<Aram> I don't know why it's now showing,
<rogpeppe1> Aram: with your canonical email addr, presumably
<Aram> yes
<rogpeppe1> Aram: ah! i just needed to reload
<rogpeppe1> Aram: thanks
<rogpeppe1> fwereade: just you to go :-)
<fwereade> rogpeppe1, blech, ok ;p
<fwereade> rogpeppe1, I can't see myself yet but I think I've done it
<rogpeppe1> fwereade: i imagine there's some caching to time out before we see it
<fwereade> rogpeppe1, so I would imagine
<fwereade> rogpeppe1, TheMue, Aram: https://codereview.appspot.com/7062062 -- principal Uniter sets subordinates to Dying when the principal is Dying
<TheMue> *click*
<jam> mgz: poke for standup
<mgz> did wonder at 11 if we were doing one :)
<jam> mgz: yeah, I was on an hour ago, but we were meant to do it now.
<rogpeppe1> fwereade: reviewed
<mgz> ah, yeah, had mentioned bumping but calendar was still old time
<fwereade> rogpeppe1, TheMue: cool, thanks
 * fwereade ->lunch
<jam> mgz: at one point you said that we don't need listings for public buckets, but the code we are trying to share with ec2 wants to list all the tools it has available, and 'pick the best', which is why we do need .rlistings
<jam> for the public location.
<rogpeppe1> fwereade: initial stab at agent package: https://codereview.appspot.com/7064066
<rogpeppe1> other reviews also appreciated, please
<TheMue> rogpeppe1: done
<rogpeppe1> TheMue: thanks
<TheMue> rogpeppe1: yw
<fwereade> rogpeppe1, why json not yaml? I thought yaml was the project standard for data files, regardless of personal taste
<fwereade> rogpeppe1, everything else looks good though
<rogpeppe1> fwereade: yaml doesn't cope well with []byte
<rogpeppe1> fwereade: i could change CACert to be string everywhere, i suppose
<rogpeppe1> fwereade: although that has its own issues (the standard crypto packages use []byte for certificates and keys)
<fwereade> rogpeppe1, ok, that's reasonable but deserves a comment -- but also, remind me why we went with a single file?
<TheMue> fwereade, rogpeppe1: a review with only two lines https://codereview.appspot.com/7068059/ (read the text, the firewaller is the change which alread had two LGTMs but then has been rejected by Dave. line 272 is the new one).
<fwereade> rogpeppe1, I don't think you should change the cert type
<rogpeppe1> fwereade: it's much less code, easier to expand to include more options, and having a single "agent.conf" file seems to me to be a good thing for debugging and general non-clutteredness
<rogpeppe1> s/more options/more fields/
<TheMue> fwereade, rogpeppe1: and i would ask one of you to run the whole tests, i've got one language error because my system is germen and the compared text is expected tobe english. ;)
<fwereade> rogpeppe1, ok, I guess tasks that need to change it can return ErrConfChangeReady, like we do with ErrUpgradeReady
<fwereade> TheMue, can you not fix it with LC_LOCALE or something?
<rogpeppe1> TheMue: the compared text from what?
<rogpeppe1> fwereade: i'd imagined having an api that enables changing it in a safe way (with a mutex lock)
<TheMue> rogpeppe1: one moment, will look for the name of test
<fwereade> TheMue,     os.Setenv("LC_ALL", "en_US") fixes language weirdness in the git tests, I believe
<TheMue> fwereade: you, would be an idea
<TheMue> s/you/yes
<rogpeppe1> fwereade: it's not difficult to do, and it's only owned by one running program, so there's no issue with concurrent changes from outside
<TheMue> fwereade: the test is btw not mine, it's one where an external tool is called.
<rogpeppe1> TheMue: which tool?
<fwereade> rogpeppe1, true -- feels like it subtly works against task independence but not enough to really bug me badly
<rogpeppe1> fwereade: i don't think it needs to
<rogpeppe1> fwereade: each task can still make independent changes
<fwereade> rogpeppe1, will be able to, once api is in place
<rogpeppe1> fwereade: sure
<rogpeppe1> :-)
<fwereade> rogpeppe1, but LGTM
<rogpeppe1> fwereade: thanks
<rogpeppe1> fwereade: will add a comment
<fwereade> rogpeppe1, cheers
<TheMue> rogpeppe1: it's bzr in lpad_test.go:16: StoreSuite.TestPublishCharmDistro
<TheMue> rogpeppe1: nothing wild, the printed text in german matches to the expected english one. but the test fails. ;)
<fwereade> TheMue, also LGTM assuming those are the only changes from before
<TheMue> fwereade: yes, only addMachine() with instance id and treating ErrNoInstances correect.
<TheMue> fwereade: there has been another race due to my usage of a vm, but that has been fixed by roger (thanks again)
<fwereade> TheMue, was that the InjectMachine? I saw that, thanks
<TheMue> fwereade: that has been after a hint of roger. but he also had a CL.
<TheMue> fwereade: it's in since yesterday.
<fwereade> TheMue, ok, thanks
 * rogpeppe1 is away for a bit of lunch. back in 30 mins.
<mgz> jam: yup, discovered that when reviewing the branch, it's a change in the go version due to wanting to give out executables
<rogpeppe1> back
<TheMue> rogpeppe: any chance to look into my review?
<rogpeppe> TheMue: i will do in a little bit, just been in a meeting, and am looking at something else currently
<TheMue> rogpeppe: ok, np
<rogpeppe> TheMue: reviewed
<TheMue> rogpeppe: just seen, thx
<TheMue> rogpeppe: and the idea of the double proposal is good
<rogpeppe> TheMue: kanban meeting?
<TheMue> rogpeppe: afaik yes
<rogpeppe> TheMue: https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083
<fwereade> rogpeppe, TheMue: https://codereview.appspot.com/7073056/ addresses the most critical remaining subordinates problem - I'm about to verify it live, but feel hopeful, and would appreciate reviews
<TheMue> fwereade: *click*
<TheMue> fwereade: oh, that is the one i already reviewed ;)
<fwereade> TheMue, <3
<rogpeppe> fwereade: reviewed
<fwereade> rogpeppe, tyvm
<fwereade> rogpeppe, yeah, it works :)
<rogpeppe> fwereade: yay!
<rogpeppe> fwereade: that presumably increases the number of charms we're compatible with by a significant amount
<fwereade> rogpeppe, almost better than expected -- a failed relation-broken hook in rsyslog-forwarder is keeping its principal unit alive
<fwereade> I am suspicious about this:
<fwereade> 2013/01/10 16:40:35 JUJU worker/uniter: HOOK /var/lib/juju/agents/unit-rsyslog-forwarder-0/charm/hooks/syslog-relation-broken: 5: /var/lib/juju/agents/unit-rsyslog-forwarder-0/charm/hooks/syslog-relation-broken: JUJU_REMOTE_UNIT: parameter not set
<fwereade> rogpeppe, can you think why JUJU_REMOTE_UNIT would be expected or needed in a -broken hook?
<rogpeppe> fwereade: no
<rogpeppe> fwereade: perhaps it's expected to be the last unit that left the relation?
<fwereade> rogpeppe, heh, maybe, that's pretty crackful if so
<fwereade> rogpeppe, there's no guarantee there's been another unit in scope
<fwereade> rogpeppe, but, yay, it all works -- resolving the error caused the subordinate to shut down smoothly, the principal recalled and removed it, the principal set itself to dead and the machine recalled and removed it
<fwereade> rogpeppe, ...and when I destroyed the relation, the subordinate attached to the other unit shut itself down neatly too
<rogpeppe> fwereade: why would you get a relation-broken if another unit hasn't been in scope?
<rogpeppe> (sorry, someone came to the door, just back)
<fwereade> rogpeppe, because relation-broken is the last thing that happens before a unit leaves a relation -- no more and no less
<fwereade> rogpeppe, if we had a relation-forged hook that was guaranteed to run first, relation-broken would be its counterpart
<rogpeppe> fwereade: ah, in which case JUJU_REMOTE_UNIT in that context is definitely crack
<fwereade> rogpeppe, yeah, I just wonder why the charm uses it
<rogpeppe> fwereade: have you had a look?
<fwereade> rogpeppe, just did -- it's getting the service name from it :)
<rogpeppe> fwereade: presumably there's an easier way of doing that...
<fwereade> rogpeppe, or is it? actually I don;t know wtf it's doing
<fwereade> rogpeppe, more to the point I want to find out why it would work in python
<rogpeppe> fwereade: yeah
<fwereade> rogpeppe, TheMue: almost trivial before I stop: https://codereview.appspot.com/7080043
<TheMue> fwereade: *click*
<rogpeppe> fwereade: LGTM
<TheMue> fwereade: ^
<fwereade> rogpeppe, TheMue: cheers guys
<TheMue> fwereade: yw
<rogpeppe> end of day hereg'night all.
<rogpeppe> ha
<rogpeppe> g'night all
#juju-dev 2013-01-11
<bigjools> why is the only place to get the required version of Mongo in an ec2 bucket?  Even worse, a binary coming over an unencrypted connection.
<davecheney> bigjools: we're open to suggestions
<bigjools> davecheney: I need to understand why it's there before I can make a meaningful suggestion, but PPAs spring to mind
<davecheney> i can't answer the PPA question
<davecheney> the reason we user our own version of mongo is we need 2.2.0
<davecheney> which isn't in LTS
<davecheney> and we also need TLS enabled, which isn't in any published version that we could find
<bigjools> davecheney: where is the source?  I am happy to get it in a PPA
<bigjools> (assuming you meant there's a diff for TLS?)
<davecheney> not, just a compile option
<bigjools> ok
<davecheney> bigjools: lets take this to the juju-dev / canonical-juju mailing list
<davecheney> gustavo needs to be involved, but is not online in this timezone
<bigjools> I had better join them :)
<bigjools> I will stick it in a PPA for my own use anyway, and it can be re-used if people see fit
<davecheney> any juju devs in the house
<davecheney> trunk is super broken
<davecheney> i am trying to confirm it isn't a local problem
<davecheney> never mind, it was a problem with my machine
<TheMue> *: morning
<rogpeppe1> davecheney, fwereade_, TheMue: morning!
<TheMue> rogpeppe1: hiya
<fwereade_> rogpeppe1, davecheney, TheMue: heyhey
<TheMue> fwereade_: hiya 2
<fwereade_> actually just popping out for a croissant
<fwereade_> bbiab
 * rogpeppe1 learned how to make croissants over new year
<fwereade_> ooh, nice
<TheMue> rogpeppe1: so we know what we'll get during the next meeting?
<rogpeppe1> TheMue: only if there's an oven and lots of butter!
<TheMue> rogpeppe1: i'll try to organize it :)
<TheMue> rogpeppe1: butter should be no problem, but the oven ...
<aram> hello.
<rogpeppe1> aram: hiya
<TheMue> aram: hi
<jam> bigjools: one reason to use a binary rather than a ppa, is because installing mongod starts the service running, rather than just having a binary that gets started and stopped by the test suite.
<jam> (though I imagine the *real* reason is just people not being familiar with PPAs)
<bigjools> jam: and configuration
<bigjools> anyway I have one in a PPA that does the trick
<bigjools> I didn't say where, but it's here: ppa:julian-edwards/mongodb
<fwereade_> rogpeppe1, TheMue: https://codereview.appspot.com/7091043/ is trivial and important; https://codereview.appspot.com/7092044/ is slightly more involved and slightly less likely to break the average user's deployment but still good to have for 1.9.6
<fwereade_> rogpeppe1, TheMue: https://codereview.appspot.com/7058073/ is strictly less important but still a nice-to-have-agreement-on so I feel ok about progressing with the AUST removal
<rogpeppe1> fwereade_: so, did you decide that the charm you found using JUJU_REMOTE_UNIT in a relation-broken hook isn't crackful after all?
<TheMue> fwereade_: *click*
<fwereade_> rogpeppe1, it's crack IMO
<rogpeppe1> fwereade_: or is this just a backward-compatibility sop?
<fwereade_> rogpeppe1, but python sets it to "" rather than leaving it unset
<fwereade_> rogpeppe1, exactly
<rogpeppe1> fwereade_: ah, i see, so that charm would've failed to get the svc name anyway
<fwereade_> rogpeppe1, and it doesn't actually use it anyway
<rogpeppe1> fwereade_: but at least the env var test would succeed
<fwereade_> rogpeppe1, yeah
<fwereade_> rogpeppe1, both suggested ones verified against actual charms on actual instances
<rogpeppe1> fwereade_: LGTM for that one
<fwereade_> rogpeppe1, cheers
<TheMue> lunchtime
<TheMue> fwereade_: first lgtm is in, second one looks good so far too, but i have to continue after lunch
<fwereade_> TheMue, cool, thanks
<fwereade_> rogpeppe1, I think https://codereview.appspot.com/7094043 is trivial
<rogpeppe1> fwereade_: i'm still trying to absorb 7092044...
<fwereade_> rogpeppe1, no worries -- sorry, I seem to be channelling a firehose this week :/
<rogpeppe1> fwereade_: i think you've got two LGTMs for 7094043 already, no?
<fwereade_> rogpeppe1, that's 1043
<rogpeppe1> fwereade_: oh yeah. too darn similar, thouse numbers
<fwereade_> rogpeppe1, yeah, most unhelpful :)
<rogpeppe1> fwereade_: all but  https://codereview.appspot.com/7058073/ reviewed
<fwereade_> rogpeppe1, awesome, thanks
<rogpeppe1> fwereade_: i'm gonna leave that for a little bit if you don't mind, i'm not quite up to it currently, and i'm wanting to push the agent stuff forward
<fwereade_> rogpeppe1, yeah, np, it's definitely lower priority
<rogpeppe1> bloody hell, cmd/jujud tests pass with flags removed. that took a while.
<fwereade_> me cheers at rogpeppe1
 * fwereade_ cheers at rogpeppe1
<rogpeppe1> fwereade_: i'm afraid the CL might be a bit of a monster though. there's so much circularity, it's difficult to break up.
 * fwereade_ braces himself ;)
<rogpeppe1> fwereade_: i'm fairly happy with the way it's turning out though. definitely feels like an improvement
<fwereade_> rogpeppe1, awesome
<rogpeppe1> fwereade_: then again, i've though that before and... :-|
<dimitern> fwereade_, rogpeppe1 - can you have a look https://codereview.appspot.com/7073060/
<fwereade_> rogpeppe1, heh, yeah
<fwereade_> dimitern, *click*
<rogpeppe1> dimitern: looking
<rogpeppe1> dimitern: reviewed
<dimitern> rogpeppe1: tyvm
<dimitern> fwereade_: I saw yours as well - thanks
<fwereade_> dimitern, np, yw
<rogpeppe1> fwereade_: ping
<fwereade_> rogpeppe1, pong
<rogpeppe1> fwereade_: just want to confirm something that i think is wrong currently
<rogpeppe1> fwereade_: in deployer/simple.go, DeployUnit doesn't seem to pass the --data-dir argument to the unit agent
<rogpeppe1> fwereade_: am i missing something, or is it only working by luck
<rogpeppe1> ?
<fwereade_> rogpeppe1, ha, does it not? it probably should, let me check
<fwereade_> rogpeppe1, yeah, it's crack, fix please :)
<rogpeppe1> fwereade_: will be fixed with all the other changes
<fwereade_> rogpeppe1, <3
<fwereade_> rogpeppe1,  have comments on https://codereview.appspot.com/7094043/ and https://codereview.appspot.com/7092044/ -- but finish your branch first ;)
<rogpeppe1> fwereade_: replied to one
<fwereade_> rogpeppe, replied to that :)
<rogpeppe> fwereade_: LGTM
<fwereade_> rogpeppe, do you think it qualifies as trivial?
<rogpeppe> fwereade_: not quite. after all, i had to think about it quite carefully. better wait for another pair of eyes.
<fwereade_> rogpeppe, true enough -- thanks :)
<rogpeppe> fwereade_: another question around deployer/simple.go: we pass the --log-file flag in, but we set upstart.Conf.Out to the same file - is there any point in doing the former when we've got the latter?
<fwereade_> rogpeppe, meh, probably not
<fwereade_> rogpeppe, dropping it will make life simpler, won't it
<rogpeppe> fwereade_: i'd like to lose as many flags as possible
<fwereade_> rogpeppe, +1
<rogpeppe> fwereade_: the only dubious one left is --debug
<fwereade_> rogpeppe, hmm
<fwereade_> rogpeppe, I think I'd like to leave it in, but turn off the state subpackage debug spam
<rogpeppe> fwereade_: at some point in the future it would be nice to be able to enable/disable it dynamically.
<fwereade_> rogpeppe, was just composing that message ;p
<rogpeppe> fwereade_: at which point we don't really want it as a flag
<rogpeppe> fwereade_: or maybe we do, for the initial debug state
<fwereade_> rogpeppe, I think starting in that mode and then dropping to a quieter level once that's detected is saner
<rogpeppe> fwereade_: yeah, probably
<fwereade_> TheMue, thanks for the review -- did you see the followup with only a single delaying hook check? I think it strikes a decent balance.
<TheMue> fwereade_: will take a look
<TheMue> fwereade_: ah, ok, see the change. like it.
<fwereade_> TheMue, cool, thanks
<TheMue> fwereade_: but now i'm fighting through the larger one. ;)
<rogpeppe> lunching
<dimitern> rogpeppe, fwereade_- when you have time, please - https://codereview.appspot.com/7073060
<dimitern> i fixed suggestions & answered questions
<rogpeppe> back
<rogpeppe> dimitern: looking
<dimitern> rogpeppe: 10x
<fwereade_> rogpeppe, how long do you think it's reasonable to wait for a dying subordinate to be removed?
<rogpeppe> fwereade_: indefinitely?
<fwereade_> rogpeppe, I guess...
<rogpeppe> fwereade_: then it can be force-removed if necessary
<fwereade_> rogpeppe, it's not like complaining is going to make the situation any better, I suppose ;p
<rogpeppe> fwereade_: indeed
<fwereade_> rogpeppe, yeah, sgtm
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: thank you!
<dimitern> fwereade_: would you take a look please - https://codereview.appspot.com/7073060 - I tried to answer your questions
<fwereade_> dimitern, I asked a followup just above
<fwereade_>  dimitern, I'm not following https://codereview.appspot.com/7073060/diff/1/testservices/novaservice/service_http.go#newcode523
<fwereade_>  dimitern, you got the group name right out of the request
<fwereade_>  dimitern, surely it could be handled at any stage?
<dimitern> fwereade_: you mean I should check for it in advance?
<fwereade_> dimitern, it seems strange to me to create the server and *then* fail when checking the security groups
<dimitern> fwereade_: yeah, put like this it's indeed strange (even though OS does it similarly), I'll rearrange it
<fwereade_> dimitern, well, if OS creates the server, we should copy that
<fwereade_> dimitern, does it really though? I thought SGs were set at instance create time and unchangeable after that -- it that OS or just EC2?
<dimitern> fwereade_: looking at both responses and nova source things are not clear, but I'll do it as it makes sense
<fwereade_> dimitern, cheers
<dimitern> fwereade_: take a look now is it better https://codereview.appspot.com/7073060
<dimitern> rogpeppe: as well ^^ (just in case I misunderstood something)
<rogpeppe> dimitern: LGTM
<TheMue> so, telephone support for my brother done, he wants to install ubuntu ;)
<dimitern> rogpeppe: cheers!
<fwereade_> dimitern, LGTM modulo one set of comments, let me know what you think
<dimitern> fwereade_: thanks, looking
<dimitern> fwereade_: yeah, the duplication is ugly, but wasn't sure how to fix it best
<dimitern> fwereade_: I think I did it better now - https://codereview.appspot.com/7073060
<fwereade_> dimitern, LGTM
<dimitern> fwereade_: sweet! 10x
<fwereade_> dimitern, yw :)
<fwereade_> dimitern, https://codereview.appspot.com/7094043/ is pretty small if you have a mo after merging
<dimitern> fwereade_: sure - just 2 mins and I'm on it
<aram> I'm going to get my batch of rasberry pi's.
<aram> back in an hour or so.
<dimitern> aram: cool, happy hacking :)
<dimitern> fwereade_: LGTM
<fwereade_> aram, nice, enjoy
<fwereade_> dimitern, awesome, tyvm
<rogpeppe> all live tests pass, phew
<rogpeppe> not all at once though - we need to sort out our reliability
<rogpeppe> i've just discovered this old CL that i never got another review on
<rogpeppe> https://codereview.appspot.com/6963050/
<rogpeppe> please could someone other than william give me another review
<rogpeppe> aram, TheMue, jam, mgz: ^
<TheMue> rogpeppe: *click*
<rogpeppe> TheMue: thanks
<TheMue> rogpeppe: +1
<rogpeppe> TheMue: thank you!
<TheMue> rogpeppe: yw, the whole script generation and testing isn't simple.
<rogpeppe> TheMue: yeah. i prefer being able to see the generated script in the tests now. at least i can eyeball it for problems, even if we can't run it in the tests.
<TheMue> rogpeppe: absolutely. i needed some time to understand the generation. now i atleast can see the expected result immediatelly.
<rogpeppe> fwereade_, TheMue: here's the beast: https://codereview.appspot.com/7102043
<TheMue> rogpeppe: uuuh
<rogpeppe> TheMue: sorry for the size - i have no idea how i can break it down
<TheMue> rogpeppe: no problem, but i'll review it over the weekend. our younger daughter and i will drive to the cinema to watch "life of pi in a few moments.
<rogpeppe> TheMue: ah, enjoy. i've heard at least one good report.
<rogpeppe> dimitern: if you fancy a challenging review: https://codereview.appspot.com/7102043 :-)
<TheMue> rogpeppe: yes, and what i've seen so far looked also good.
<rogpeppe> TheMue: i enjoyed the book
<dimitern> rogpeppe: i'm on it\
<rogpeppe> dimitern: thanks!
<TheMue> so everyone have a nice weekend.
<rogpeppe> TheMue: and you.
<dimitern> rogpeppe: reviewed
<rogpeppe> dimitern: you're a lovely man
<dimitern> rogpeppe: I keep forgetting to use 'm' to reply when there are comments, rather than reply and then publish :)
<rogpeppe> dimitern: :-)
<fwereade_> rogpeppe, thanks, I'll take a look
<rogpeppe> fwereade_: that would be great.
<rogpeppe> fwereade_: it would make my week if i could get it submitted this evening :-)
<fwereade_> rogpeppe, LGTM :)
<rogpeppe> fwereade_: really, wa hay!
<fwereade_> rogpeppe, assuming you;ve run it live ;p
<rogpeppe> fwereade_: i have
<fwereade_> rogpeppe, then I'm happy :)
<rogpeppe> fwereade_: i get no more failures than the ones we're regularly getting in trunk anyway
<fwereade_> rogpeppe, heh
<rogpeppe> fwereade_: TestBootstrapWithDefaultSeries is failing every time for me in trunk, live.
<rogpeppe> fwereade_: but not if i run it on its own
<fwereade_> rogpeppe, hum, that is bad
<dimitern> fwereade_: I didn't get that - you replied to my review on https://codereview.appspot.com/7102043/ - are you saying +1 on all my comments?
<fwereade_> dimitern, I was only feeling strongly +1 about the one I badged, the others I guess I'm +0 on but I don't feel strongly enough to actually chime in
<fwereade_> rogpeppe, dimitern: if either of you fancies https://codereview.appspot.com/7094045 it would be cool, but it is getting pretty EODy
<rogpeppe> fwereade_: you didn't publish your comments BTW
<dimitern> fwereade_: I'll take a look at yours
<fwereade_> rogpeppe, dimitern: ah, sorry, I am clearly codereview-impaired today
<fwereade_> but rogpeppe, ignore that one in favour of checking my response to https://codereview.appspot.com/7092044/
<dimitern> fwereade_: LGTM - nice and short
<dimitern> fwereade_: btw I managed to fix my machine finally (I hope) - it needed a good dusting and cleaning - that brought the temp -30 deg. down :) and no longer lags terribly
<fwereade_> dimitern, ha
<fwereade_> dimitern, excellent news anyway :)
<dimitern> :) yeah
<mgz> bringing the temp to -30 deg would be impressive
<mgz> though perhaps would make using the laptop a little hard...
<dimitern> mgz: well, according to sensors - it was running most of the time +80 on both cores, which is high (90 is critical), now it's down to 40-50!
<mgz> erk. sounds similar to the issues jamespage had, which also required som pretty heavy dust busting
<mgz> graphics card getting used more in newer version probably contributed something to general overheating.
<dimitern> mgz: it's strange it needed that, because I dusted it like 5-6 months ago
<dimitern> but i guess even the small amount of gruel accumulated on the fins of the heat sink was enough
<dimitern> mgz: how's public URLs going? I've run out of things to do - good it's EOD :)
<mgz> going to land shortly
<dimitern> mgz: it seems I missed the daily standup somehow - I was there on time (12 UTC), john and mark were there, but nobody talked to me and after staying there an hour, I left :)
<mgz> basically Ian's branches are fine I think, so have just tweaked slightly and will land the two together and send note
<rogpeppe> i'm done for the day. have a great weekend, all!
<rogpeppe> fwereade_: thanks in particular for that timely review!
<dimitern> rogpeppe: g'nite and happy weekend
<dimitern> mgz: cool, so any progress on the versioning discussion/doc?
<mgz> jam wrote up a few things
<mgz> ^on the standup, we generally don't do fri as it's not a UAE work day, but I should have got on mumble and said hi to you this morning probably as we've generally done that
<mgz> was just having 'fun' trying to get canonistack to behave at the time...
<dimitern> mgz: but we're still not applying anything to the workflow
<dimitern> mgz: I see
<mgz> not yet
<mgz> apart from simultanious landing and note to mailing list, which is my plan
<dimitern> ok
#juju-dev 2014-01-06
<wallyworld_> thumper: i forwarded an email
<wallyworld_> but you will need a previous one where the creds were sent
<wallyworld_> i think you should have received both of those emails
<thumper> probably
<thumper> probably ignored them too
<wallyworld_> lol
<wallyworld_> so, i just source the creds and can then ssh in to that ip address
<wallyworld_> then you can bzr pull the new rev as needed for ehatever source tree
<wallyworld_> the bot uses a cron job to wake up every minute
<davecheney> is the bot still alive
<davecheney> has canonistack eaten that machine ?
<thumper> davecheney: the bot is still there
<thumper> it failed to merge my branch
<thumper> because I use an updated crypto
<thumper> lunchbreak means going to the supermarket with kids - always fun...
<axw> hey thumper, wallyworld_ - welcome back
<wallyworld_> hi. wish i could say it's good to be back :-)
<wallyworld_> you were back last week?
<axw> yup
<wallyworld_> would have been quiet
<axw> yeah it was
<axw> fortunately my stuff took long enough that it didn't need reviews yet :)
<wallyworld_> :-)
<wallyworld_> soooo hot here today. may need to jump in the pool at some point to cool off. we had record breaking temperatures over the weekend. 44 degrees
<axw> ouch
<wallyworld_> almost as bad today
<axw> gonna be 39 here
<axw> I thought that was bad
<thumper> it is 18Â°C here
<wallyworld_> we get it worse cause the hot air blows from west to east
<wallyworld_> wish it were 18 here
<axw> I could do 18
<axw> thumper: are you waiting for another review on the ssh stuff?
<thumper> axw: nah, I think it is all good
<axw> I intend to use your GenerateKey function in an MP of mine
<thumper> just need to hack the bot
<axw> cool
<axw> bot's broken?
<thumper> just dependencies
<bigjools> wallyworld_: only record breaking temps if you believe the shite in the paper
<wallyworld_> bigjools: you saying the paper makes up the recorded temps?
<bigjools> it misquotes
 * bigjools finds a reference
<wallyworld_> you need to take off your tin foil hat
<wallyworld_> it has cooked your brain with the heat
<bigjools> not wearing one, just papers like to sell papers so they dramatise
<bigjools> talking about clamitous weather is known to sell more
<bigjools> calamitous even
<wallyworld_> well the temp on sat was about 4, right?
<wallyworld_> 44
<bigjools> was 46 here
<wallyworld_> so what's the issue?
<wallyworld_> that's what the paper reported
<bigjools> "record breaking"
<wallyworld_> well it was
<bigjools> nope
<wallyworld_> when was it hotter
<bigjools> ...
<bigjools> when did measurements start?
<wallyworld_> several years ago it was 41 or 42
<wallyworld_> 1800s
<wallyworld_> don't tell me you are going to be a pedant and say it may have been hotter 600000000000 years ago
<bigjools> sigh
<thumper> axw: I've logged into the bot and updated go.crypto
<thumper> axw: attempting to land again
<axw> thumper: thanks
<axw> thumper: how come dependencies.tsv didn't do it?
<axw> or did you not update that file?
<thumper> axw: apparently the bot doesn't update based on that yet
<thumper> so I'm told
<axw> oh
<thumper> I assumed it did
<axw> just the LP recipe I guess
<thumper> wallyworld_: where is the tarmac log on that machine?
<wallyworld_> thumper: ~tarmac/logs i think
<thumper> wow, doesn't log much useful
<thumper> can see it is merging my code though
<thumper> and done
<wallyworld_> \o/
 * thumper is done for the day
<thumper> see y'all tomorrow
<rogpeppe> mornin' all
<TheMue> heya and happy new year
<jam> hi rogpeppe and TheMue
<rogpeppe> jam, TheMue: hiya
<rogpeppe> and happy new year to you too
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Bugs: 2 Critical, 205 High - https://bugs.launchpad.net/juju-core/
<mgz> morning!
<jam> morning mgz, just finishing up my 1:1 with rogpeppe, will chat with you in a sec
<mgz> jam, sure
<jam> mgz: I'm ready
<mgz> jam: mumble?
<jam> certainly, I'm there
<mgz> almost
<jam> well, I had been there, maybe it gets angry if you sit in an empty channel
<jam> see you guys in the standup in a sec, just grabbing a coffee
<jam> mgz: any idea how to recursively delete s3 buckets? The web interface requires you to empty buckets before you can delete them, but we have 50 "test" buckets that are left over
<mgz> euca2ools should have something
<mgz> hm, or maybe not, maybe you need the s3 command
<jam> mgz: there is s3nukem http://robertlathanh.com/2010/07/s3nukem-delete-large-amazon-s3-buckets/
<mgz> funny name
<jam> mgz: adapted from s3nuke, but in a nice way :)
<rogpeppe> natefinch: ha! it's another transient error - i retried and it succeeds after 2 seconds of returning that error...
<rogpeppe> jam: s3cmd supports recursive removal
<rogpeppe> jam: i seem to remember writing something to do concurrent recursive removal, but maybe i just piped the output of s3cmd into my concurrent xargs program
<rogpeppe> jam: should juju 1.17.0 status work correctly against a 1.16.3 environment?
<mgz> rogpeppe: it should fall back to reading the db
<rogpeppe> mgz: it doesn't appear to be working
<mgz> rogpeppe: so, if the db is compatible (we make sureit is...) it should be okay?
<mgz> rogpeppe: can you tell if it's trying the api and failing... then?
<rogpeppe> mgz: i just got a report that showed this status: http://hastebin.com/hudipomama.txt
<mgz> that pastebin is much better for my silly detatched irc thing
<mgz> shame it needs js...
<mgz> well, that's pretty facinating
<rogpeppe> mgz: yeah, that's what i thought
<mgz> I assume you don't really have lots of machines? I wonder what all the ds are
<rogpeppe> mgz: that's not my status, it's from a real installation
<rogpeppe> mgz: they were using juju-devel ppa, not juju stable
<mgz> ah, so maybe the machines are semi-accurate
<rogpeppe> mgz: i think so
<mgz> but the state connection apparent;y didn't work at all
<mgz> just the get machines from the ec2 api bit
<mgz> when I hack-tested this, when we added the fallback, this all worked
<rogpeppe> hmm
<mgz> but of course, that's not what landed, and dimiter may well have not tested that, I know I didn't
<mgz> rogpeppe: can you get them to file a bug?
<rogpeppe> mgz: will do
<rogpeppe> mgz: just to check: there should be no probs upgrading from 1.16.3 to 1.16.5, right?
<mgz> I have not heard of any, and certainly that's our general minor version promise is
<mgz> the bump past 1.16.3 is rougher than normal though
<mgz> we added various things that wouldn't normally make a minor release, but not anything that should mess with upgrades really
<sinzui> looks like dependencies.tsv is invalid again http://162.213.35.54:8080/job/prepare-new-version/745/console
<mgz> sinzui: it does indeed
<mgz> I'll land a fix
<mgz> blame is tim, r2182
<rogpeppe> natefinch: i'm never seeing the instances get out of StartupState. looks like getStatus is returning the state in "state", not "myState".
<rogpeppe> natefinch: it'd be good to have a test for that in the replicaset package
<rogpeppe> natefinch: ah, it's actually as documented
<natefinch> rogpeppe: which is documented?
<rogpeppe> natefinch: the fact that the state is returned in "state", not "myState"
<natefinch> rogpeppe: weird, wonder where I got "myState" from
<rogpeppe> natefinch: i've fixed that, but run straight into another problem - that the two secondaries never move out of "UNKNOWN" state
<rogpeppe> natefinch: you didn't read far enough down the page :-)
<natefinch> rogpeppe: those documentation pages are pretty long at times ;)
<rogpeppe> natefinch: myState is the field used for the state of the server you're talking to
<rogpeppe> natefinch: it seems my secondaries are never managing to connect to the primary
<natefinch> rogpeppe: hmm weird
<rogpeppe> natefinch: it might be something to do with the localhost issue, i suppose
<rogpeppe> natefinch: whatever that issue might be...
<natefinch> rogpeppe: arg, possibly.  sigh.
<natefinch> rogpeppe: I should have tested the mystate vs. state thing, but I had been intentionally trying not to test mongo itself, assuming that if I gave it commands it accepts, it would do the right thing.
<rogpeppe> natefinch: it did :-)
<rogpeppe> natefinch: unfortunately StateupState == 0
<mramm2> rogpeppe: mgz: you guys around?
<rogpeppe> mramm2: i am
<mramm2> sabdfl is looking to setup a sprint at bluefin end of january
<mramm2> we are going to have 5 MAAS clusters in a box ready for testing then
<mramm2> and will be developing a set of demo's that the sales engineers can use for deploying openstack
<mramm2> and then solutions on top of openstack using those maas clusters
<mramm2> and sabdfl would like juju core representation
<rogpeppe> mramm2: bluefin?
<rogpeppe> mramm: bluefin?
<mgz> mramm: I'm here too
<mramm> 12:01 mramm has left IRC (Ping timeout: 240 seconds)
<mramm> 12:01 mramm2: we are going to have 5 MAAS clusters in a box ready for testing then
<mramm> 12:02 mramm2: and will be developing a set of demo's that the sales engineers can use for deploying openstack
<mramm> 12:02 mramm2: and then solutions on top of openstack using those maas clusters
<mramm> 12:02 mramm2: and sabdfl would like juju core representation
<mramm> yep
<mramm> bluefin
<rogpeppe> mramm: sorry, what's bluefin?
<mgz> representation at bluefin, I assume
<mgz> rather than in a hangout or something
<mramm> yep
<rogpeppe> bluefin's a company?
<sinzui> rogpeppe, our head office
<mramm> it's the location of our offices
<mgz> rogpeppe has first refusal, given I've been down recently, but it's an easy trip for me
<rogpeppe> ah!
<mgz> rogpeppe: worth going if you've not been before
<mramm> rogpeppe is my preferred choice too
<rogpeppe> i'd be happy to do it
<mramm> unless you both want to go ;)
<rogpeppe> but mgz has lots more MAAS experience than me
<mramm> rogpeppe: I'll add you to the list
<mramm> rogpeppe: that is true
<rogpeppe> (i have never used MAAS)
<mgz> nah, I have some specific maas knowledge that's probably not relevent here
<mramm> but we should have a MAAS team member there too
<rogpeppe> my openstack-fu is similarly limited
<rogpeppe> but i'm fine in juju-core-land :-)
<rogpeppe> mramm: do you know the actual dates?
<rogpeppe> i'd quite like the opportunity to spend a bit more time around openstack stuff, actually
<rogpeppe> natefinch: found the problem with the UNKNOWN thing - it takes 10s before the secondaries connect
<rogpeppe> natefinch: my problem now is that the secondaries never seem to get out of STARTUP2STATE
<natefinch> rogpeppe: ahh hmm ok.
<natefinch> rogpeppe: we're not exactly speeding up the tests here ;)
<rogpeppe> natefinch: indeed not
<rogpeppe> natefinch: ah, found the problem, i think
<rogpeppe> 2014/01/06 17:26:03 mongod:57236: Mon Jan  6 17:26:03.817 [conn4] key file must be used to log in with internal user
<natefinch> rogpeppe: hmm... I didn't think you needed any authentication if you're connecting from localhost
<rogpeppe> natefinch: i think it must be different for peers
<rogpeppe> natefinch: bingo!
<natefinch> rogpeppe: what did you find?
<rogpeppe> natefinch: that was the reason, and now that i've done that, i've finally seen a  [PRIMARY SECONDARY SECONDARY] status...
<natefinch> well good
<rogpeppe> natefinch: it took about 30s from starting to wait for sync, to fully synced (that's with an empty db), and about 42 seconds from no-servers-running
<natefinch> rogpeppe: ug
<rogpeppe> natefinch: this is not the fastest sync in the world :-)
<natefinch> rogpeppe: 30s to sync no data is pretty bad ;)
<natefinch> rogpeppe: on localhost no less
<rogpeppe> natefinch: for the record, here's the log of what was going on during that time: http://paste.ubuntu.com/6704366/
<natefinch> rogpeppe: wonder if this has anything to do with it: "noprealloc may hurt performance in many applications"  honestly, I wouldn't think anything coudl hurt performance that badly with empty DBs on localhost
<rogpeppe> natefinch: i agree - i don't think noprealloc could harm anything here
<rogpeppe> natefinch: no data on an SSD
<natefinch> rogpeppe: does it matter if it's an SSD if no data is there?   (there's a profound question question ;)
<rogpeppe> natefinch: well, it might be doing *something* in that 30 seconds....
<rogpeppe> natefinch: i'm thinking that the 30s might be due to the 10s heartbeart
<rogpeppe> natefinch: 3 heartbeats for the status to propagate around the system
<rogpeppe> niemeyer: happy new year!
<rogpeppe> niemeyer: i'd like to confirm something about mgo, if you have a moment at some point
<niemeyer> rogpeppe: Heya
<niemeyer> rogpeppe: Thanks, and happy new year :)
<niemeyer> rogpeppe: Shoot
<rogpeppe> niemeyer: if i've performed an operation on a Session, it it possible that the session changes to use a different server at some point in the future (without doing anything explicit, such as SetMode) ?
<rogpeppe> niemeyer: from my current experiments, it seems like that doesn't happen, but i'd like to be sure
<niemeyer> rogpeppe: Depends on the current mode of the session.. if on Strong mode, no
<niemeyer> (Strong is the default, FWIW)
<rogpeppe> niemeyer: so if it's in Monotonic, it may switch without any explicit intervention?
<niemeyer> rogpeppe: If it's Monotonic, it will switch deterministically on writes
<rogpeppe> niemeyer: currently, i seem to get an EOF error even in Monotonic mode, but perhaps that might resolve itself if I keep trying
<niemeyer> rogpeppe: From a slave to the master
<niemeyer> rogpeppe: (that's the whole point of Monotonic)
<rogpeppe> niemeyer: ah, but not if a primary goes down and is replaced by another one?
<niemeyer> rogpeppe: If besides the primary that was the single server alive, then surely it'll break as suggested
<niemeyer> rogpeppe: After it fails, it will not switch
<rogpeppe> niemeyer: in this case there were two secondaries
<niemeyer> rogpeppe: Or even reconnected without an ack from the code
<niemeyer> reconnect
<rogpeppe> niemeyer: but that's good to know
<niemeyer> rogpeppe: In that case the behavior depends on whether the session was already hooked to the master
<rogpeppe> niemeyer: my current plan is to make the single-instance workers (provisioner, firewaller, etc) move with the mongo master
<niemeyer> rogpeppe: If the session was hooked to the mater, and the connection drops due to a server shutdown, you'll get an EOF
<rogpeppe> niemeyer: that's the behaviour I want to rely on
<niemeyer> rogpeppe: That EOF will not go away until: a) THe session is Closed, discarded, and re-created b) The session is Refresh'ed
<niemeyer> rogpeppe: You want to rely on the fact the error doesn't go away?
<rogpeppe> niemeyer: if that happens, we'll redial and run the workers if we are on the same machine as the mongo primary
<niemeyer> rogpeppe:  You don't have to redial.. just Refresh the session at the control point
<rogpeppe> niemeyer: i want to rely on the fact that if the primary gets reelected, that we're guaranteed to get an error so that we know for sure that we've not got two "single-instance" workers running at the same time
<rogpeppe> niemeyer: that's useful to know, thanks
<niemeyer> rogpeppe: You'll not get an error if a primary gets re-elected and the session was not hooked to it
<rogpeppe> niemeyer: for those workers' connection to the State, i'd use a direct connection in strong mode
<niemeyer> rogpeppe: E.g. a Monotonic session that got no writes will be hooked to a slave, assuming one is available
<niemeyer> rogpeppe: That session has no reason to error out if the primary shifts
<rogpeppe> niemeyer: it will get an error though, right?
<niemeyer> rogpeppe: Hmm.. these two last sentences contradict each other.. :)
<rogpeppe> niemeyer: so it'll be difficult to avoid (say) an API call failing because the primary shifts
<niemeyer> rogpeppe: It will NOT error out if the primary shifts, because it was connected to a slave.. it doesn't care about the fact the primary went through trouble
<rogpeppe> niemeyer: ah, but if it happens to be connected to the primary, then it will error out, right?
<niemeyer> rogpeppe: It really depends on how you're structuring the code.. let me give an example
<rogpeppe> niemeyer: so i guess it's down to chance
<niemeyer> rogpeppe: Let's say you have an http server that creates a new session to handle each request
<niemeyer> rogpeppe: Now, the primary just broke down, but there were no requests being serve
<niemeyer> d
<niemeyer> rogpeppe: Then, the primary gets re-elected..
<niemeyer> rogpeppe: The driver picks up the new master, resyncs, and keeps things up
<niemeyer> rogpeppe: Finally, the http server gets a new request to handle
<niemeyer> rogpeppe: and runs Copy on a master session, creating a new session to handle this specific request
<niemeyer> rogpeppe: This new request will not error out..
<niemeyer> rogpeppe: As it was a fresh session to a working server
<rogpeppe> niemeyer: ok
<niemeyer> rogpeppe: It's not down to chance, any more than a TCP connection breaking due to a temporary outage on the packet path is down to chance
<rogpeppe> niemeyer: (that doesn't apply easily to our case, because we've got very long-lived http requests)
<niemeyer> rogpeppe: If there is a long-living session that is active (was used, not refreshed), the error will surface
<niemeyer> rogpeppe: It doesn't pretend that things are sane when they're not
<rogpeppe> niemeyer: ok
<niemeyer> rogpeppe: No need for the direct mode for that, btw
<rogpeppe> niemeyer: apart from the fact that Refresh presumably uses more up-to-date info for the server addresses, is there a significant difference between using Dial and using Refresh?
<niemeyer> rogpeppe: Oh yeah
<niemeyer> rogpeppe: Dial creates an entire new cluster
<niemeyer> rogpeppe: Syncing up with every server of the replica set to figure their state and sanity
<niemeyer> rogpeppe: Refresh is very lightweight
<rogpeppe> niemeyer: ok, that's good to know
<niemeyer> rogpeppe: It just cleans the session state and moves sockets back to the pool, assuming they're in a sane state
<rogpeppe> niemeyer: can I rely on the fact that err==io.EOF implies that the server has gone down and a Refresh could clean it up?
<niemeyer> rogpeppe: No.. EOF means socket-level EOF
<niemeyer> rogpeppe: Whatever the reason why that happened
<rogpeppe> niemeyer: ah, ok. is there a decent way of telling that the server has gone away and i need to refresh?
<niemeyer> rogpeppe: But you can always refresh on errors
<niemeyer> rogpeppe: and once/if the server works again, the new session will behave properly again
<niemeyer> rogpeppe: IOW, no reason to reconnect
<niemeyer> s/reconnect/redial/
<niemeyer> rogpeppe: In fact, you can always refresh at the control point
<niemeyer> rogpeppe: With errors or not
<rogpeppe> niemeyer: after every API call?
<niemeyer> rogpeppe: No.. by control point I mean the place where the code falls back to on every iteration
<niemeyer> rogpeppe: For example, if there was a loop, it might be refreshed on every iteration of the loop to get rid of already acknowledged errors
<niemeyer> rogpeppe: If it's an http request, it might refresh before every Accept (although that doesn't quite fit, since there would be multiple requests on any realistic server)
<niemeyer> rogpeppe: Rarely in an application it would be okay to assume errors didn't happen, mid-logic
<rogpeppe> niemeyer: i'm not quite sure how that would map to our code structure
<rogpeppe> niemeyer: the main loop is in the rpc package, reading requests from the websocket and invoking methods
<niemeyer> rogpeppe: What happens if an error happens in the middle of a request from the client being handled?
<rogpeppe> niemeyer: the error gets returned to the client
<niemeyer> rogpeppe: Okay, and I assume each client has its own session to the server?
<rogpeppe> niemeyer: yes
<niemeyer> rogpeppe: Okay, so you might Refresh before starting to handle a new RPC, for example
<rogpeppe> niemeyer: it's a bit of a bad spot for us currently - we don't ever redial or refresh the connection for API requests
<rogpeppe> niemeyer: ok, so Refresh really is that (<0.1ms) light weight?
<niemeyer> rogpeppe: Yeah
<niemeyer> rogpeppe: It's literally clean the session and put socket back in the pool
<niemeyer> rogpeppe: mem-ops only
<rogpeppe> niemeyer: cool
<rogpeppe> niemeyer: so it doesn't matter if lots of ops call it concurrently whenever they like
<niemeyer> rogpeppe: Yep, no problem
<niemeyer> rogpeppe: Note that if you have multiple goroutines using a single session in a way that they might potentially call Refresh concurrently, that's not quite okay
<rogpeppe> niemeyer: oh
<niemeyer> rogpeppe: As they might be cleaning up errors from each other that ought to be acted upon
<niemeyer> rogpeppe: That's why I asked whether each client has its own session
<rogpeppe> niemeyer: (that's definitely the case for us, as *state.State holds a single *mgo.Session)
<rogpeppe> niemeyer: ah, i misunderstood session there
<rogpeppe> niemeyer: even if each client had its own session, it still wouldn't be ok, as one client can have many concurrent calls
<niemeyer> rogpeppe: It's fine to use sessions concurrently, but if there's a fatal error in a session that is being concurrently used, the correct behavior is to let all goroutines see such error, as whatever they were doing got interrupted
<rogpeppe> niemeyer: i'm not sure i quite see how one Refresh might "clean up" an error from another
<rogpeppe> niemeyer: won't whatever they were doing be locked to a particular socket (during that operation), and therefore draw the correct error anyway?
<niemeyer> rogpeppe: If such a concurrently used session gets Refresh calls while other goroutines are using it, such a fatal error may be incorrectly swiped under the carpet
<niemeyer> rogpeppe: I don't get your previous points
<niemeyer> rogpeppe: If a single session is used concurrently, it's a single session
<niemeyer> rogpeppe: If that single session sees a fatal error in its underlying socket, it's the same socket (assuming Strong or Monotonic modes)
<niemeyer> rogpeppe: for all code using it
<rogpeppe> niemeyer: don't operations do Session.acquireSocket before doing something?
<niemeyer> rogpeppe: That in itself is irrelevant
<niemeyer> rogpeppe: A session gets a socket associated with it
<niemeyer> rogpeppe: Assuming Strong or Monotonic mode
<niemeyer> rogpeppe: There's no magic.. if such a session gets an error while it has an associated socket, and it's being concurrently used, all the concurrent users should observe the fault
<rogpeppe> niemeyer: could you expand on why we want that to be the case?
<niemeyer> rogpeppe: Sure
<niemeyer> rogpeppe: Imagine the perspective of any of the concurrent users of the session
<niemeyer> rogpeppe: When a session is re-established, it won't necessarily be to the same server
<rogpeppe> niemeyer: ah, so for Monotonic mode, we might suddently skip events in the log?
<niemeyer> rogpeppe: and depending on the mode, it may even walk history backwards (master socket becoming slave socket)
<rogpeppe> niemeyer: that doesn't apply in Strong mode, presumably?
<rogpeppe> niemeyer: ah, i guess it can
<rogpeppe> niemeyer: unless Wmode==Majority
<niemeyer> rogpeppe: That's irrelevant
<niemeyer> rogpeppe: This just means a writer won't consider the write successful until it reaches a majority
<niemeyer> rogpeppe: This point in time can easily happen without a particular slave reader observing the data
<rogpeppe> niemeyer: is it possible that one of the ones that wasn't part of that majority is elected primary?
<rogpeppe> niemeyer: (i thought the election process took into account up-to-dateness)
<niemeyer> rogpeppe: Again, that's a separate problem
<niemeyer> rogpeppe: We're talking about someone that is actively *reading from a slave*
<niemeyer> rogpeppe: It doesn't matter who the master is
<rogpeppe> niemeyer: i thouht that couldn't happen in Strong mode
<niemeyer> <niemeyer> rogpeppe: and depending on the mode, it may even walk history backwards (master socket becoming slave socket)
<niemeyer> rogpeppe: I did say "depending on the mod"
<niemeyer> mode
<rogpeppe> [19:03:56] <rogpeppe> niemeyer: that doesn't apply in Strong mode, presumably?
<niemeyer> rogpeppe: Ah, sorry, okay
<niemeyer> rogpeppe: It can *still* happen
<niemeyer> rogpeppe: If a failure happens before the majority was reached
<rogpeppe> niemeyer: ah
<niemeyer> rogpeppe: Of course, we're getting into very unlikely events
<rogpeppe> niemeyer: indeed, but it's nice to have some idea of these things
<niemeyer> rogpeppe: As the re-election will still attempt to elect the most up-to-date server, despite majority concerns
<rogpeppe> niemeyer: i wonder if a reasonable approach might be to Copy the session for each RPC call
<niemeyer> rogpeppe: That sounds fine
<niemeyer> rogpeppe: Easier to reason about too
<rogpeppe> niemeyer: presumably there's no need to Refresh such a copy?
<niemeyer> rogpeppe: No, as it's being Closed after the RPC is handled
<niemeyer> rogpeppe: The session is buried, and the (good) resources go back to the pool
<rogpeppe> niemeyer: ok, that's useful, thanks
<niemeyer> rogpeppe: My pleasure
<niemeyer> rogpeppe: I'll head off to a coffee break
<rogpeppe> niemeyer: i shall head to supper
<niemeyer> Still on holiday this week, btw
<niemeyer> Should send a note
<rogpeppe> niemeyer: ah, well, thanks a lot for the chat!
<niemeyer> rogpeppe: Glad to chat
<rogpeppe> niemeyer: FYI I tried Refreshing the session after an error, but I can't get it to work - it seems to try connecting to the old primary and never trying the old secondaries
<rogpeppe> niemeyer: (when i was redialling with all the peer addresses, it worked)
<thumper> o/
#juju-dev 2014-01-07
<thumper> wallyworld: ping
<wallyworld> wot
<thumper> wallyworld: hangout?
<wallyworld> ok
<thumper> https://plus.google.com/hangouts/_/72cpj771u1klaslrripsbvshss?hl=en
<thumper> wallyworld: ?^^
 * thumper is trying to work out the least shitty way to do something
<thumper> there doesn't seem to be a clean way to get the machine agent data dir from the api server client
<thumper> since this is needed to get the ssh identity file location...
<thumper> I could pass the *agent.Config through about 4 layers
<thumper> or...
<thumper> oh, we
<thumper> ew
<thumper> I could use a global :-)
<thumper> axw, wallyworld, davecheney: opinions?
<wallyworld> noooo. not a global
<thumper> pass the agent config pointer?
<wallyworld> could we attach it as a stuct attr somewhere/
<wallyworld> ?
<thumper> it'll need to go machine agent -> api server -> root -> api
<thumper> wallyworld: it is the three or four somewheres...
<wallyworld> i know there are other places where agent.Config is passed around
<wallyworld> so doing it that way at least is consistent
<thumper> yeah...
<wallyworld> maybe see how it is done elsewhere?
<thumper> wallyworld: it is passed into the worker
<thumper> but it is normally only one level deep
<thumper> the api server is somewhat nested
<wallyworld> ah ok. i couldn't recall how it was used
<wallyworld> what about adding it to the state struct of whatever
<axw> thumper: I wonder if the key should end up getting plonked in the client key dir that I'm introducing, which will automatically get picked up by utils/ssh
<wallyworld> not sure, just hand waving
<thumper> axw: but the key is on the state server, not the local machine
<thumper> axw: two very different ssh bits
<axw> thumper: the client key dir can be changed. it doesn't have to be ~/.juju/ssh
<axw> just a thought, not necessarily a good one
<thumper> axw: yeah, but I don't know which directory it is
<thumper> that is the problem :)
<axw> thumper: at startup?
<thumper> axw: well the machine agent knows, but that information isn't passed down to the api server client yet
<thumper> just trying to work out how to get it down there...
<thumper> I think just adding the param is a good start
<thumper> better to store a single pointer to an already created structure
<thumper> than to pass down a string
<axw> right, but the machine agent can initialise the client key dir to be whatever it knows about, and then when the api server uses utils/ssh, it'll get picked up. maybe I don't understand correctly
<thumper> ah... wat? how does utils/ssh pick up the client key dir?
<thumper> axw: currently we write the generated private key into $datadir/system-identity
<axw> thumper: it's a global, unique per process thing
<thumper> wallyworld: there ya go, use a global :)
<axw> heh
<wallyworld> :-)
<axw> normally I wouldn't advocate, but in this case it seemed cleanest. hasn't been reviewed yet though :)
 * thumper avoids the global
<thumper> and dances through the apiserver weirdness
 * thumper throws in the towel for today
<thumper> I'm pretty sure I have a way forward now...
<thumper> at least
<thumper> night all
<wallyworld_> jam: i'm about to head out tonight to a function, so will miss the stand up. i've got about 4 pipes in progress, but none ready to propose yet
<jam> wallyworld_: k, anything you want to summarize for the group?
<wallyworld_> i've been adding a bunch of instrafstructure for the charm update work, api service pieces, and splitting it all up, plus refoactoring further the charm store interface and test mock
<wallyworld_> jam: also,i've had no feedback from martin on that bug and mp we discussed, i'm keen to hear something from hiom about that
 * wallyworld_ runs away
<rogpeppe> mornin' all
<mgz> I may be a few mins late for the standup, but I should be around for it
<jam> rogpeppe: I think you asked about the fireworks in Dubai: http://www.youtube.com/watch?v=Oo1JwImshw8&list=WLD47DA262F88F1497
<jam> Its a better view than I had, since a lot of it is from above so you get to see the palm shape
<rogpeppe> jam: thanks
<rogpeppe> jam: that's quite a lot of fireworks...
<jam> indeed
<jam> where we were, we only saw the primary palm island on edge.
<jam> so a couple low shots is what it looked like to uss
<jam> welcome natefinch, how did you get here in the end ?
<jam> rogpeppe: do you know if that was 1.16.3 against a 1.17 server, or a 1.17 against a 1.16.3 server?
<natefinch> jam: ip address... something must be wonky with my DNS
<rogpeppe> jam: the latter
<jam> It doesn't reproduce for me just yet, but it looks like my /usr/bin/juju got updated over the vacaiton
<jam> sudo apt-get install juju-core=1.16.3-0ubuntu0.13.10.1~ctools0
<jam> and now 'juju status' using 1.17 looks as described
<jam> mgz: http://paste.ubuntu.com/6708528/
<jam> mgz: ^^
<mgz> jam: ta
<jam> mgz:  but I also see it after doing "juju upgrade-juju -e local --upload-tools" with juju 1.16.5
<mgz> okay, so it's probably not fixed for them
<jam> mgz: well "its fixed" was that they reverted to the 1.16.5 client, I bet
<jam> mgz: but you're going to file the bug, right, or shall I do it and assign it to you ?
<jam> its certainly considered a critical bug that juju status in the 1.17 series is incompatible with the 1.16 series, just like add-machine, etc.
<jam> I'm currently finishing add-machine
<jam> we removed a struct I was using :(
<mgz> jam: if you could file it, I will assign to me
<jam> mgz: https://bugs.launchpad.net/juju-core/+bug/1266734
<_mup_> Bug #1266734: juju status incompatible in 1.17.0 against 1.16 <compatibility> <juju-core:Triaged by gz> <https://launchpad.net/bugs/1266734>
<jam> that's a bug in _mup_, Triaged by gz
<jam> I assigned it to you, and it is triaged, but it certainly isn't triaged *by* you :)
<jam> _mup_: make me a sandwich
<jam> ah, mup doesn't respond to pokes anymore :(
<mgz> :(
<jam> axw: I'm getting "environment is no longer alive" trying to add a machine to a 1.16 system.
<jam> Did we mess up the default value for environment life?
<jam> mgz: ^^ that *might* be a hint as to what is going wrong? If juju 1.17 is saying "oh this env is dying, I won't probe any deeper", or something like that
<axw> jam: I had tested when there was no life in the document... but it does sound like it points to that
<jam> axw: it is the assertAliveOp()
<jam> after debugging some more
<jam> axw: Life() still returns Alive
<jam> because 0 is the default value
<jam> which is the enum Alive
<jam> but assertAliveOp() asserts that "life == 0" when it "== nil)"
<mgz> ha
<axw> jam: yeah, I thought it was working in the db level too. sounds like I messed up my testing
<axw> sorry
<jam> mgz: sounds like unrelated to status
<mgz> yeah, that's what I was coming to with adding logging in status here
<jam> axw: well, I created a bug and assigned it to you already :)
<axw> thanks, will get onto it in the morning
<jam> https://bugs.launchpad.net/juju-core/+bug/1266748
<_mup_> Bug #1266748: Environments.Life() in juju-1.17.0 incompatible with juju-1.16.* <compatibility> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1266748>
<mgz> everyone can triage it!
<jam> mgz: more importantly *I* can make anyone triage it :)
<mgz> I'll try a hack fix and see if that make status happy
<jam> axw: ugh, and your latest change to auth keys also conflicts with the changes to add machine... sigh
<jam> guess I'll look more tomorrow
<jam> I refactored that code so it operated in a "poll for information, then set that information"
<jam> rather than interleaving it
<jam> (so that when we go to set it via the API we can fallback to directly setting it in the DB)
<jam> axw: note, what is your compatibility with 1.16 here with the ssh keys stuff?
<axw> jam: I thought it was polling first to be honest - there were some late changes when merging with rogpeppe's updates, maybe it got broken around then. will have to investigate some more later
<axw> umm
<axw> jam: are you referring to the CL I put up today?
<jam> axw: you just landed code today that breaks my patch for bug #1253631
<_mup_> Bug #1253631: juju add-machine in trunk is incompatible with 1.16 <compatibility> <regression> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1253631>
<jam> when I mean "poll", I just mean, gather up the information we need to send in the add-machine request and do all the gathering before we start talking to the db.
<axw> yeah, I thought that was being done
 * axw looks at what he merged today
<jam> axw: I created a new function "gatherMachineParams" that did all of the NewUUID, ParseIP, hostAddresses, checkProvisioned, etc
<jam> and Arch, and etc
<jam> it was a bit interleaved in the function before
<jam> anyway, I can sort it out
<axw> jam: ah, sorry
<jam> just one more time that this stuff got broken (ian did it last time by getting rid of State.AddMachine)
<axw> jam: as for 1.16 compat, the stuff I've done is all client side so far
<jam> axw: I just need to get this landed so it is on everyone else to keep it working :)
<jam> axw: sure, but changing where SSH keys are found is going to break if someone uses 1.17 and then 1.16, right?
<jam> axw: InitUbuntuUser sounds a bit "mutating state" while we are "gathering information" (might be necessary, I'm not sure exactly yet)
<axw> jam: sorry, I don't understand. if they use 1.17 and then 1.16...?
<jam> axw: from what I can tell, if I use 1.17 client in a 1.16 environment, and do "juju add-machine" it is going to set up that machine in a way that 1.16 may not understand
<axw> jam: all that InitUbuntuUser does is ensures that ubuntu exists on the machine, and if not creates it and makes it a passwordless sudoer
<axw> so that's not going to break anything older - this is only done at add-machine/bootstrap time anyway
<axw> the CL I put up today is about using additional keys from the client side; the additional public keys are added to authorized-keys in the env config
<axw> so no changes needed on the server side there either
<axw> jam: I realised what happened with my testing. The assertion used to be !dead, then it got changed during review
<axw> and I didn't retest
<rogpeppe> natefinch: i've been wondering about IP address changes with respect to replica sets
<rogpeppe> natefinch: do you know how we can deal with that?
<rogpeppe> natefinch: (at the moment i don't think it's possible to change the IP address of a member, right?)
<rogpeppe> natefinch: ping?
<natefinch> rogpeppe: here now
<rogpeppe> natefinch: what do you think of the above?
<natefinch> rogpeppe: I don't think you can change the ip address, but you can remove and re-add
<rogpeppe> natefinch: you *should* be able to change the ip address, at least according to this: https://groups.google.com/forum/#!topic/mongodb-user/_EUC63MJfQA
<rogpeppe> natefinch: unless i'm misinterpreting
<nate_finch> rogpeppe: sorry, stupid USB ethernet adapter keeps making my computer hang up.  Didn't see anything after what I posted
<rogpeppe> [14:46:58] <rogpeppe> natefinch: you *should* be able to change the ip address, at least according to this: https://groups.google.com/forum/#!topic/mongodb-user/_EUC63MJfQA
<rogpeppe> [14:47:07] <rogpeppe> natefinch: unless i'm misinterpreting
<nate_finch> rogpeppe: you're right.  I thought I had seen somewhere that you oculdn't change the host on a member, but maybe I'm thinking of something else. Looks like you can: http://docs.mongodb.org/manual/tutorial/change-hostnames-in-a-replica-set/
<rogpeppe> nate_finch: i think that means, unfortunately, that our current strategy of keying by address is not valid
<rogpeppe> nate_finch: jam also brought up the point that it would probably be better if we didn't denormalise the replica set voting info
<rogpeppe> nate_finch: which means, i think, that we want to be able to map from replicaset Members to *state.Machine
<rogpeppe> nate_finch: i think we can probably use the tagging functionality for that
<rogpeppe> nate_finch: we'd associate a tag holding the machine id with the replica set member
<nate_finch> rogpeppe: so, there is a problem with replicaset.Set, if you modify the address of a member, yes.   I thought I had mostly copied that function from the javascript code, but maybe there's a subtle difference.  I can double check.
<nate_finch> rogpeppe: I'm not sure what you mean by denormalizing the voting info
<rogpeppe> nate_finch: do the ids have to be strictly numbered from zero?
<nate_finch> rogpeppe: I don't believe so, I was just following the way the javascript code works.
<nate_finch> rogpeppe: so you want the id to be the same as the machine id?
<rogpeppe> nate_finch: i'm not sure if that's a good idea
<rogpeppe> nate_finch: but we could provide access to the Tags functionality
<rogpeppe> nate_finch: and state something like: if the id is greater than zero, it is treated as explicitly set
<rogpeppe> nate_finch: otherwise it will be automatically generated
<rogpeppe> nate_finch: then a client of the package can inspect the tags and determine which members match, according to the tags, and when updating, it can reuse the original indexes for previously existing members
<rogpeppe> nate_finch: does that make some kind of sense?
<nate_finch> rogpeppe: what are we gaining?  Just being able to figure out what replica member corresponds to what machine, if its address changes?
<rogpeppe> nate_finch: it means we can use the replicaset member list as the canonical source of what machines are voting
<rogpeppe> nate_finch: rather than needing to trust that state reflects that correctly
<nate_finch> rogpeppe: definitely using the information in the replicaset member list as the canonical source of who is voting is the way to go, since it *is* the canonical source :)  However, I'm trying to figure out when the host name in the member list would be wrong, and how this would help in that situation.  obviously if the hostname is wrong in mongo, then that member isn't voting anyway, right?
<rogpeppe> nate_finch: consider what will happen if a machine's address changes. the address updater will change the machine's address in state, and we will need to change the appropriate replica set member to reflect the new address
<rogpeppe> nate_finch: that member can't vote while it has the wrong address, but it's still a valid member (it's analagous to a network error cutting off that machine, i think)
<nate_finch> rogpeppe: can't that just be another thing the address updater does, change it in the replica config?
<rogpeppe> nate_finch: i don't want two things both changing the replica config
<rogpeppe> nate_finch: seems like a recipe for race conditions
<nate_finch> rogpeppe: hmm.. true.  I'm just not a fan of having things out of sync like that.
<rogpeppe> nate_finch: well, it's just one part of the address propagation
<rogpeppe> nate_finch: the machine's address was out of date for a while too
<nate_finch> rogpeppe: I'm not averse to having the machine id be the replica id.  That's not a terrible solution, though maybe tags are more flexible in case of weird edge cases
<rogpeppe> nate_finch: i don't want to tie us to having integer machine ids
<nate_finch> rogpeppe: ahh, as opposed to random strings?
<nate_finch> "random"  = arbitrary
<rogpeppe> nate_finch: yeah
<natefinch> rogpeppe: good point.
<natefinch> rogpeppe: I don't know that tags is the right solution.  Couldn't we just add a value to the machine document in state to hold replica set member id?
<rogpeppe> natefinch: using tags seems like a direct reflection of what we want to do
<rogpeppe> natefinch: the other way around isn't so clearly correct to me
<rogpeppe> natefinch: because the replica set must be updated independently from the machine doc
<rogpeppe> natefinch: so there's a potential for things to get out of step
<rogpeppe> natefinch: what are your reservations about using tags here?
<natefinch> rogpeppe: tags are human-readable information used for selecting machines.  I don't think replica set id is really anything anyone will ever want to see in tags.
<rogpeppe> natefinch: i don't think it's incompatible with that
<rogpeppe> natefinch: { "juju-machine-id": "12" }
<rogpeppe> natefinch: they don't look like they're for human-readable info to me, BTW
<rogpeppe> natefinch: mostly it looks like they're used for write- and read-concern configuration
<rogpeppe> natefinch: http://docs.mongodb.org/manual/tutorial/configure-replica-set-tag-sets/
<natefinch> rogpeppe: crap, we were talking about different things.  I thought you meant tags in state on the machine docs
<natefinch> rogpeppe: yes, that sounds fine
<rogpeppe> natefinch: ah, cool
<rogpeppe> natefinch: sorry for the misunderstanding
<rogpeppe> natefinch: i'd forgotten state.Machine had tags :-)
<natefinch> rogpeppe: haha no big deal
<mattyw> fwereade, we should probably have a chat this week about the next stage of user ids in juju
<rogpeppe> natefinch: would you be able to move forward with that?
<rogpeppe> natefinch: or i could if you're otherwise busy
<natefinch> rogpeppe: I can do that.
<rogpeppe> natefinch: thanks!
<rogpeppe> natefinch: just to be clear, i'm thinking of this:
<rogpeppe> // Set changes the current set of replica set members.  Members will have their
<rogpeppe> // ids set automatically if they are zero.
<rogpeppe> abentley: and a change to a Tags field to Member
<rogpeppe> oops
<rogpeppe> s/abentley/natefinch/
<abentley> rogpeppe: That's good, 'cause I had no clue...
<rogpeppe> abentley: :-)
<natefinch> rogpeppe: yep, sounds good
<rogpeppe> natefinch: and the automatic ids we'd choose would start from 1, not 0
<natefinch> rogpeppe: right
<fwereade> mattyw, for sure
<fwereade> mattyw, I'm sprinting today and flying tomorrow
<mattyw> fwereade, no problem, shall I put something in the diary for thursday or friday or would you prefer to wait till next week?
<fwereade> mattyw, if I come online tomorrow pm before you go, grab me -- otherwise it may have to be thursday
<fwereade> mattyw, let's do thursday, it's a meetingy day for me anyway
<mattyw> fwereade, ok cool - I'll put something in the diary
<mattyw> fwereade, thanks very much
<fwereade> mattyw, a pleasure, sorry it can't be sooner
<mattyw> fwereade, not at all - I have plenty to do in the meantime
<fwereade> mattyw, cool
 * rogpeppe grabs a late lunch
<rogpeppe> natefinch: important thing i've just noticed, (from http://docs.mongodb.org/manual/tutorial/configure-replica-set-tag-sets/) the type of the Tags field should be map[string]string
<rogpeppe> natefinch: do you have a strong idea as to what we should do if we find extra members in the peer set that don't correspond to machines?
<natefinch> rogpeppe: yeah, I was making the Tags map[string]string .    Not sure what to do if we find extra members.   Honestly, I think if we just ignore that condition it'll basically take care of itself, which is to say, normally we'll just ignore them, if the normal process is <get config> <change node in config> <set config>
<rogpeppe> natefinch: it's not quite that straightforward
<rogpeppe> natefinch: for the time being i'm just going to return an error if there extra members
<rogpeppe> natefinch: i've added a TODO comment with various options
<natefinch> rogpeppe: that's probably fine... it shouldn't really ever happen unless people go messing with the replicaset by hand, in which case, not mucking with it is probably the right thign to do
<rogpeppe> yeah
<rogpeppe> natefinch: BTW i just wanted the replica set id from the CurrentStatus results - it's not there and not documented, but it appears in the actual results
<rogpeppe> natefinch: do you think it's reasonable to add it as a field in the Status type?
<natefinch> rogpeppe: sure, no harm
<rogpeppe> natefinch: one mo, i'll just check that it is the expected id
<natefinch> rogpeppe: probably we should just export a ReplicaSetStatus struct that includes the data from replSetGetStatus
<rogpeppe> natefinch: isn't that what Status is?
<natefinch> rogpeppe: status just returns the members right now
<natefinch> rogpeppe: the member statuses that is
<rogpeppe> natefinch: ah yes
<natefinch> rogpeppe: brb diaper
<rogpeppe> natefinch: i don't care much at the moment
<natefinch> (not mine ;)
<natefinch> rogpeppe: back
<rogpeppe> natefinch: confirmed that _id is the replica set id
<rogpeppe> natefinch: i thought it was strange that it wasn't there, otherwise there's no way of cross-correlating statuses with members
<rogpeppe> natefinch: unless you assume that there's a one-to-one correspondence in the arrays, but that's not documented either
<natefinch> rogpeppe: you mean between the members and their statuses in replSetGetStatus?  I presume there's a 1:1 relationship.  I'd be surprised if there were not
<rogpeppe> natefinch: i would too, but i can't find anything that documents that fact
<rogpeppe> natefinch: and the fact that we can't fetch them both at the same time makes me naturally wary
<rogpeppe> natefinch: so given that the _id field is provided, i'd rather latch onto that
<natefinch> rogpeppe: that's fine
 * rogpeppe is done for the day
<rogpeppe> g'night all
<natefinch> rogpeppe: g'night
<thumper> morning folks
<thumper> o/ natefinch
<thumper> natefinch: care for a catch up call?
<natefinch> thumper: sorry, just got surprise acquisition of the kids for a bit.  When my wife gets back, I'll be able to catch up, but kind of occupied at the moment, unfortunately
<thumper> natefinch: np
<natefinch> thumper: still want to catch up?
<thumper> natefinch: yeah
<thumper> natefinch: https://plus.google.com/hangouts/_/7acpicc4tp7juqvoctqj0i9qb4?hl=en
<thumper> natefinch: you have frozen
 * thumper goes to tell the dog to be quiet...
<thumper> decisions... decisions...
<thumper> do I hook up my crazy shit and try it
<thumper> or write more tests first
<thumper> ...
<thumper> davecheney: you around?
#juju-dev 2014-01-08
<thumper> davecheney: got a  golang question
<thumper> davecheney: I have a slice of structures back from the api client
<thumper> davecheney: and I want to serialize these out using either json or yaml
<thumper> but I want some of the fields to be omitted if empty or zero
<thumper> but I don't want to annotate the structure in the api
<thumper> as it doesn't care about serialization
<thumper> how can I handle this sanely?
<davecheney> ...
<davecheney> thumper: as i understand it, you use a tag on the struct
<davecheney> if you don't want to do that, then maybe write something that takes the struct, and returns a map
<thumper> but I don't want to annotate the struct
<thumper> hmm...
<davecheney> so you can elide the fields you don't want to seralise
<davecheney> why don't you want to annotate the struct
<davecheney> that is like saying 'i want to drive to town', but I don't want to use a car
<thumper> because I think it is messy and detracts from the intent
<davecheney> ok then
<thumper> but if it is the simplest way, I'll just leave a mess
<davecheney> but then you can't complain that this isn't super easy
<thumper> I just think it would be nice for golang to support decoupling this
<davecheney> write a function that takes the struct and returns a map with the fields you want to jsonise
 * thumper vomits a little into his mouth
 * thumper goes to annotate the struct
<davecheney> thumper: why are you complainin
<thumper> davecheney: actually...
<davecheney> the json package suppors exactly what you want to do
<davecheney> but you don't want to use it
<thumper> davecheney: how does the default serialization handle embedded structs?
<davecheney> and this is somehow the json package's fault ?
<davecheney> thumper: from memory, as if they were collapsed into the main struct
<thumper> hmm...
 * thumper writes a function
<thumper> I think it is cleaner
<davecheney> afaik it is like a depth first traversal
<davecheney> type t struct { a int; b int; C; d int }
<davecheney> order goes
<davecheney> a, b, C.something, C.something else, d
<davecheney> a, b and d sohuld be upper case in that example
 * thumper nods
<thumper> ahh poo
<thumper> wallyworld_: your authentication worker is killing my local provider
<wallyworld_> really?
<wallyworld_> in what way?
<thumper> wallyworld_: http://paste.ubuntu.com/6712278/
<thumper> wallyworld_: I don't have an ubuntu user
<wallyworld_> whereas nodes in the cloud do
<thumper> aye
<wallyworld_> bollocks
<wallyworld_> hmmm
<thumper> I wonder if we should just skip it for machine 0 on the local provider
<thumper> local provider is a little special for machine 0
<wallyworld_> easiest solution for now
 * thumper nods
<thumper> care to work something up with that?
<wallyworld_> i've got a bunch of stuff in progess
<thumper> I'm debugging my run stuff
<thumper> ..
<wallyworld_> just a sec, door knock
<thumper> hmm
<wallyworld_> thumper: can it wait till tomorrow? or is it blocking you?
<thumper> wallyworld_: it doesn't appear to be blocking
<thumper> so I'm just going to hide those error messages for now
<wallyworld_> ok, but if it does need attention before tomorrow, let me know
<thumper> I've hacked up a branch ti not start it, as hiding the errors wasn't going to cut it
<thumper> how can I easily poke (as in read) the internal mongo state?
<axw> for what purpose?
<wallyworld_> you can get at the various collections off the state object, and query those directly
<thumper> from a shell, I want to poke into the mongo db to read bits
<axw> thumper: mongo --ssl -u admin -p <admin-secret> localhost:37017/admin
<axw> then "use juju"
<thumper> hmm... auth fails
<thumper> I tried the admin secret from the environments file
<thumper> this is for the local provider
<axw> from .jenv?
<thumper> no
<axw> .jenv is what gets used, would be best to check that they're the same
<axw> tho I thought it got carried over
<thumper> axw: it is the same...
<axw> hmk
<thumper> oh go...
 * thumper sighs
 * thumper gets bitten by variable capture of anonymous function inside a loop
<jam> mgz: poke
<bac> morning jcastro
<bac> jcastro: adding a couple of bullets is easy. you got the text?  would rather do this just once.
<jcastro> yeah
<jcastro> it's what I sent to the list earlier this week
<jcastro> let me find it
<jcastro> https://lists.ubuntu.com/archives/juju/2014-January/003347.html
<bac> jcastro: thanks.  will do it right now.
<jcastro> ok
<dstroppa> merge proposal for Joyent Provider: https://code.launchpad.net/~dstroppa/juju-core/joyent-provider-storage/+merge/200851
<dstroppa> and https://codereview.appspot.com/49050044/
<mgz> this one does depend on the new gojoyent library, if I could get someone else to have a look at that mp as well that'd be really great
<natefinch> Someone needs to write a DeepDiff for use in tests instead of DeepEquals.  Expected: <wall of text>  Obtained: <very slightly different wall of text> is unhelpful.  :/
<mgz> :)
<natefinch> wonder if it would work to just pipe the output of deep equals into a textual diff
<jcastro> hi guys
<jcastro> http://pastebin.ubuntu.com/6716390/
<jcastro> I have set default-series: precise for this environment
<jcastro> and it seems to ignore it? In addition to the error
<natefinch> jcastro: sorry, have been heads-down... did you figure anything out?
<jcastro> I found AWS works. :)
<natefinch> jcastro: local is tricky
<jcastro> natefinch, ok I was just debating whether to file a bug
<jcastro> or if you guys knew it was broken in trusty already
 * rogpeppe is done
<rogpeppe> g'night all
<natefinch> rogpeppe: time for a very quick question?
<natefinch> morning thumper
<thumper> morning
<thumper> oops
<thumper> left my amazon environment up last night
<thumper> only four machines
<thumper> natefinch: do you know if fwereade is back at work?
<natefinch> thumper: travelling today I bevieve
<natefinch> thumper: did you hear about my $2000 AWS bill for last month?
<thumper> no...
<thumper> ouch
<thumper> what happened there?
<natefinch> thumper: was twiddling with AWS Web gui, since I was having trouble getting juju to bring up the instance type I wanted.  Don't rmemeber why, but I was in US-West when I normally do stuff in US-East
<natefinch> thumper: left up a large dedicated instance all month (dedicated evidently means $2 / hour)
<natefinch> thumper: because it was in West, and I normally look at east, I didn't even see it
<thumper> damn
<natefinch> thumper: Called Amazon, luckily they were really nice about it, saw I didn't access it all month and after a couple days told me they'd waive the fee
<thumper> nice
<natefinch> thumper:  Found out there's some nice notifications you can set up to email you if it looks like you're going over a certain amount for your monthly bill.  I set that right up, let me tell you.
<thumper> natefinch: can you please email that to the juju-dev list?
<thumper> I'd like to know
<natefinch> thumper: sure ting
<natefinch> thumper: had actually thought I should, but got bogged down in other things.  Definitely a good thing to keep us from similar infractions.
 * thumper nods
<jcastro> hey thumper
<jcastro> http://pastebin.ubuntu.com/6716390/
<thumper> hi jcastro
<jcastro> I can't get local working on trusty.
<thumper> ?!
<jcastro> I know right!
<marcoceppi_> jcastro: installing edge os releases? y u no compile juju from trunk
<thumper> jcastro: can you run lxc-ls yourself?
<thumper> o/ marcoceppi_
<jcastro> thumper, ah, no I can't, so probably an lxc problem
<marcoceppi_> \o thumper
<jcastro> that just manifests in juju?
 * thumper nods
<thumper> jcastro: we just use the lxc command line
<jcastro> ack
<thumper> if they aren't working, we are screwed
<jcastro> I'll go hunt down someone on server
<thumper> kk
<thumper> you know who to chase?
<marcoceppi_> serge?
<thumper> aye
<thumper> he'd be my first target :)
<thumper> jcastro: perhaps I should upgrade to trusty?
<thumper> with saucy, no devs were running it until just before release
<thumper> so issues came late
<natefinch> thumper: it's a good point.   Roger's on Trusty, but I think that's it AFAIK
<jcastro> yeah so we were just discussing this in our call
<jcastro> thumper, also
<jcastro> it looks like it tried to spawn a trusty image even though I set series in environments.yaml as precise
<thumper> jcastro: machine 0 is your machine
<thumper> and not a container
<thumper> the host
<jcastro> oh, right, the bootstrap is always the host os!
<thumper> jcastro: did you sudo bootstrap?
<jcastro> yeah
<jcastro> oh dude, did non-needing-sudo-bootstrap land and I not know about it?
<thumper> no
 * thumper thinks
<thumper> jcastro: I'm thinking...
<rogpeppe> natefinch: what was your question?
<thumper> jcastro: perhaps the behaviour changed
<thumper> jcastro: luckily now we have status doing everything in the api server
<thumper> in the past, it was doing some of the processing locally
<thumper> so status would try to iterate...
<natefinch> rogpeppe: you had secondaries stuck in StartupState2, I'm seeing that now... how did you fix it?
<thumper> jcastro: try this for me: sudu juju status
 * thumper wonders if that'll work
<jcastro> thumper, ok give me a few minutes, accidentally bootstrapped into AWS
<thumper> jcastro: also, can I get you to try with trunk?
<jcastro> ok so sudo juju status works
<jcastro> thumper, is there a guide/instructions for how to build trunk?
<thumper> jcastro: I'm guessing that lxc-ls used to work on saucy without sudo
<thumper> jcastro: but in trusty it doesn't
<jcastro> that seems so
<thumper> natefinch: do you know if the 1.17 dev build contains the status in api?
<thumper> jcastro: which juju version?
<jcastro> 1.16.5-trusty-amd64
<thumper> jcastro: can you try the 1.17 version from the ppa?
<thumper> saves building it
<natefinch> thumper: I was pretty sure status was pretty recently done, so I would expect not?  But I forget
<thumper> natefinch: I think dimiter got it in before christmas
<thumper> and 1.17 was released after taht
<jcastro> thumper, I can, should I wait to see what stgraber has to say about lxc-ls?
<thumper> jcastro: I'm 91% certain this is the issue
<jcastro> ok
<jcastro> Going for it
<natefinch> thumper: releases are for people who actually use juju.  As a developer, I try to be above such things. ;)
<thumper> natefinch: obviously I build trunk too :)
<rogpeppe> natefinch: if you wait, it goes from StartUp2 to Recovering and then to Secondary
<rogpeppe> natefinch: takes about 30s for me
<jcastro> jorge@jilldactyl:~$ sudo juju bootstrap
<jcastro> ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused
<natefinch> rogpeppe: hmm.... waited 120 seconds, figured that would probably do it.  maybe I'm doing someting wrong
<rogpeppe> natefinch: did you add the keyfile stuff?
<natefinch> rogpeppe: oh yeah... no, I did not
<natefinch> rogpeppe: remind me what that is again?  my brain is pretty fried
<rogpeppe> natefinch: it can be worth changing the mongo instance stuff so that it logs messages printed by mongo
<natefinch> rogpeppe: probably, yeah
<jcastro> thumper, serge and stgraber confirm you need sudo for lxc-ls
<jcastro> but now I get this crazy connection refused business
<thumper> jcastro: really nice of them to let us know that they are changing behaviour...
<thumper> at least trunk works...
<natefinch> rogpeppe: ahh - you mean make them all use the same ssl keyFile?
<rogpeppe> natefinch: here's some diffs: http://paste.ubuntu.com/6717106/
<jcastro> thumper, hey so I think we dodged a bullet, other than me wasting an hour
<rogpeppe> natefinch: yeah
<jcastro> thumper, aka maybe some of you guys should start testing on trusty?
<rogpeppe> right, i'm not here :-)
<thumper> jcastro: I'll bring it up at the meeting tonight
<jcastro> thumper, final release is 99 days, so 3 months "feels" right imo
<jcastro> way better than 2 cycles ago. :)
<thumper> jcastro: what do you mean "feels" right?
<thumper> jcastro: as in, start using trusty?
<jcastro> yeah
<jcastro> thumper, your 91% is correct
<jcastro> with 1.17 it works fine
<jcastro> sinzui, is 1.17 going into trusty or one after that?
<sinzui> jcastro, we are trying to avoid putting unstable juju into trusty. trusty users can subscribe to the devel ppa
<jcastro> ok
<jcastro> but local is broken with 1.16.5 in trusty
<sinzui> Lots more is broken in 1.17.0...it doesn't work with existing 1.16.5 deployments
<jcastro> heh, awesome
<sinzui> jcastro, 1.18 will be available in a few weeks, this Month
<jcastro> ok
<jcastro> I'll send a warning to the list
<jcastro> this really only effects people testing during the audit
<sinzui> jcastro, how is 1.16.5 on trusty?
<jcastro> I didn't get past the status
<jcastro> sinzui, I'll ask for feedback while I am at it!
<sinzui> jcastro, It works for me. It did this morning and it does for me now
<thumper> sinzui: what version of juju are you running?
<jcastro> http://pastebin.ubuntu.com/6716390/
<jcastro> you don't get that?
<sinzui> 1.16.5 and 1.17.0 I switch through out the day as needed
<sinzui> I have been on trusty Since November
<jcastro> are you up to date today?
<sinzui> jcastro, No I don't
<sinzui> jcastro, in fact http://pastebin.ubuntu.com/6717232/ status is the same as running it with sudo, which wan't true under saucy
<sinzui> I can see the machines with trusty+1.16.5
<jcastro> huh, so what just happened to me then
<sinzui> jcastro, do you need to do the dance of checking that the /var/lib/lxc/* is sane, that cloud-init images are fresh, and that the juju local dir is sane? I still need to manually remove lxc container from time to time because destroy-env doesn't
<jcastro> huh, cloud image is from 5 december
<jcastro> I'll keep an eye out wrt. clean up though
<jcastro> I thought we had fixed that
<thumper> I thought we had too
<jcastro> thumper, ooh, forcing me to explicitly mention the environment before I destroy is very nice
<natefinch> jcastro: I did that.  Glad you like it :)
<thumper> jcastro: less likely to destroy production now :)
<jcastro> well done!
<jcastro> I also like the switch mention
<jcastro> amazon -> local
<jcastro> that's nice too
 * natefinch is going to name his production environment DONT_DESTROY_ME____SERIOUSLY
<jcastro> IF_ITS_FRIDAY_DO_NOT_TOUCH
<natefinch> lol
<marcoceppi_> hey, where do you guys install lbox from?
<thumper> amrwe build it :-)
<thumper> marcoceppi_: we build it
<marcoceppi_> thumper: cool adding /usr/lib/go/bin to my path now
<jcastro> thumper, a "how to build and run juju from source" page on the docs wouldn't be a bad idea
<thumper> jcastro: sounds like a good idea
 * thumper wishes for list comprehension in golang again
<marcoceppi_> thumper: for plugins, if I run `juju help charm proof` will juju pass the additional arguments to the plugin in addition to the --help flag?
<jcastro> thumper, that was a snarky way of assigning something to you. :p
 * thumper dodges that bullet
<thumper> marcoceppi_: no, I don't think so
<marcoceppi_> thumper: cool, jw
<marcoceppi_> How do you guys log in with your @canonical.com addresses to codereview from lbox? I keep getting authentication denied
<thumper> um...
<thumper> marcoceppi_: do you have the email address you are trying linked with your launchpad account?
<thumper> marcoceppi_: at some stage I had a real password on that email address stored with google
<thumper> and that is what I use to authenticate
<thumper> I've lost track of how I set that up
<marcoceppi_> thumper: I'll give that a go
<wallyworld_> thumper: i've added some code to not start the auth worker for local provider. but there's no easy way to test it that i can see
<thumper> wallyworld_: no, probably not...
<thumper> I don't know how to help with that bit
<wallyworld_> i'll just propose as is and you can review?
<wallyworld_> i don't think we test for the other local provider hackery
<wallyworld_> thumper: https://codereview.appspot.com/49340043   i think i did the correct thing
<wallyworld_> thumper: the auth worker runs on all nodes, not just bootstrap
<thumper> wallyworld_: I know, but we only want it to not work on the bootstrap
<thumper> the other nodes are fine
<wallyworld_> ah ok
<wallyworld_> and i do recall ubuntu user created for null provider, so i'll tweak the check
<thumper> OMG!!!
<thumper> our tests suck
<thumper> FFS
 * thumper tries to work out how to unfuck this test
 * thumper takes a deep breath as he realises it is his fault
 * thumper is heading out to lunch with his birthday girl + rest of the family
<thumper> bbl
#juju-dev 2014-01-09
<axw> thumper, wallyworld_: I think the authorisation worker should be enabled for null
<axw> the ubuntu user is there, after all
<dimitern> morning all!
<rogpeppe> dimitern: yo!
<rogpeppe> dimitern: did you have a good one?
<dimitern> rogpeppe, hey
<dimitern> rogpeppe, oh yeah :) and much needed at that
<rogpeppe> dimitern: cool
<dimitern> rogpeppe, yourself?
<rogpeppe> dimitern: yeah, good thanks
<dimitern> rogpeppe, so what's cookin' ? i've been catching up on emails
<rogpeppe> dimitern: same old same old, really
<rogpeppe> dimitern: HA is coming along
<dimitern> rogpeppe, sweet!
<rogpeppe> dimitern: there was an interesting discussion about charms vs default series on the juju mailing list yesterday
<rogpeppe> dimitern: you might want to contribute
<dimitern> rogpeppe, yeah I read through it
<dimitern> rogpeppe, weekly meeting is in 1 hour, right?
<rogpeppe> dimitern: i think so
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, cheers
<fwereade> morning everybody
<dimitern> fwereade, morning!
 * fwereade is having a happy fun water-main-leaking-into-electrics day
<fwereade> dimitern, happy new year :)
<dimitern> fwereade, to you too :)
<dimitern> fwereade, that sounds dangerous
<fwereade> dimitern, just got dominion hinterlands, looks interesting, haven't played it yet
<fwereade> dimitern, indeed
<dimitern> fwereade, sweet!
<fwereade> dimitern, well the circuit breaker works at least
<dimitern> fwereade, so in addition to leaky drains now the mains are causing issues
<fwereade> dimitern, and we're ok for the moment because the water is off
<fwereade> dimitern, well, we fixed the drains and they seem ok now
<fwereade> dimitern, and hopefully it's just the one pipe
<fwereade> dimitern, but, well, we shall see
<dimitern> fwereade, *fingers crossed*
<fwereade> cheers :)
<jam> standup time
<jam> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc
<jam> welcome back dimitern
<dimitern> thanks jam
<jam> mgz: poke ^^
<axw> I can't get back onto the hangout, Internet access is very flaky
<jam> axw: no problem, we'll just assign all the work to you :)
<axw> hah
<axw> I got on :)
<jam> axw: did you get the !dead stuff sorted out?
<jam> I managed to land the other changes for add-machine compatibility, but that is now the blocking point
<axw> jam: yes, there's a CL up
<axw> jam: it was pretty trivial, and there's a test now
<axw> jam: https://codereview.appspot.com/48670045/
<jam> axw: why are you passing "Dying" to the $unset?
<axw> jam: the value is arbitrary, and ignored by $unset (but required, AFAIK)
<jam> axw: its a JSON object so it does need a value in the key: value context.
<axw> right, that makes sense
<axw> I suppose it could've been nil
<jam> axw: I'd prefer it be not something that looks like it might be a value, so "" or nil is fine
<jam> Dying made me wonder if it was only unsetting it if it was Dying, or  etc
<axw> jam: no worries, will update before landing
<axw> yep, fair point
<mgz> gah, dammit
<jam> mgz: well there you are
<natefinch> rogpeppe: btw, the pastebin in the meeting - most of those are git failures.  I was going to fix them this morning, since they obscure real failures for me
<rogpeppe> natefinch: cool, thanks
<jamespage> anyone fancy helping me with an odd juju/gccgo build issue? - https://launchpadlibrarian.net/162007788/buildlog_ubuntu-trusty-i386.juju-core_1.17.0-0ubuntu1~gccgo4_FAILEDTOBUILD.txt.gz
<jamespage> can't reproduce this outside of a launchpad builder which is awkward
<mgz> I shall look at it, and not be helpful am sure
<mgz> src/launchpad.net/juju-core/charm/config.go:14:32: error: $WORK/launchpad.net/juju-core/schema exists but does not contain any Go export data
<jam> jamespage: src/launchpad.net/goose/http/client.go:12:21: error: $WORK/launchpad.net/goose exists but does not contain any Go export data   "launchpad.net/goose"
<jam> sounds like you have a stale build file
<jam> ?
<mgz> several modules
<jamespage> jam: maybe - but the errors jump around
<jamespage> so I suspect something toolish
<mgz> does feel ording related or something, if you diff with a local build log that worked, are the modules coming up in the same sequence?
<jamespage> mgz, broadley yes - I've tried a few things such as tweaking the -p flag - I think in a launchpad builder it default to -p 1 (single cpu)
<mgz> you might be at the email-dave point then
<jamespage> mgz, yeah - that's what I guess - I already pinged him
<jamespage> mgz, trying to pull together a package that supplies both gccgo and golang-go built binaries
<jamespage> well I have it locally
<natefinch> rogpeppe: have you gotten a chance to look at the additions I made to replicaset? https://codereview.appspot.com/49290043
<rogpeppe> natefinch: oops, perhaps i haven't published my comments
<rogpeppe> natefinch: one mo
<natefinch> rogpeppe: cool
<rogpeppe> natefinch: reviewed
 * rogpeppe goes for lunch
<natefinch> arg, this kills me: // The Attempt and AttemptStrategy types are copied from those in launchpad.net/goamz/aws
<rogpeppe> mgz: there's a bit of confusion between hostname:port and hostname only in our code. i wonder if we should consistently name the former "Address" (fitting in with the "address" as passed to net.Dial) and the latter "HostName"
<rogpeppe> mgz: as it is, we've got net.Dial and now replicaset.Member.Address that hold a hostname:port combi, but instance.Address and state.Machine.PrivateAddress and others which hold host names only
<mgz> rogpeppe: that sounds sensible
<mgz> well, isn't there a better term...
 * mgz goes to look at rfcs
<rogpeppe> mgz: quite possibly
<rogpeppe> mgz: net.Dial calls it "host"
<mgz> 'authority' would be correct for the combo
<mgz> [ userinfo "@" ] host [ ":" port ]
<rogpeppe> mgz: maybe somehow "instance.HostName" seems a better fit than "instance.Host" to me though
<rogpeppe> mgz: i think we should go with the Go convention of "address" for host:port
<rogpeppe> mgz: it's used all over the place, and we can't change that in the Go tree
<mgz> host is ipvX / ipv6 / ipv4 / reg-name
<rogpeppe> mgz: alternatively we could use "HostPort"
<rogpeppe> mgz: yeah
<mgz> so, "registered name" where we explicitly mean not a ip address
<mgz> I quite like hostport
<rogpeppe> mgz: hostport is also used in go stdlib too, e.g. http://golang.org/pkg/net/#JoinHostPort
<mgz> (looking at rfc 3986 btw, there have been several url ones that somewhat update each time)
<rogpeppe> mgz: but it's not so widespread
<rogpeppe> mgz: maybe we *should* consistently use Host and HostPort throughout
<rogpeppe> mgz: it mirrors the string concatenation nicely
<mgz> that sounds like a plan
<rogpeppe> mgz: and instance.Host could grow on me, i think
<rogpeppe> mgz: thanks
<rogpeppe> mgz: i'll file a bug, and conform to that convention in new code
<rogpeppe> https://bugs.launchpad.net/juju-core/+bug/1267541
<_mup_> Bug #1267541: The name "Address" is used inconsistently <juju-core:New> <https://launchpad.net/bugs/1267541>
<rogpeppe> mgz: the only problem with "host" is that it sounds like you're talking about the signified object, not the signifier. so "SelectInternalHost" sounds like it's looking for a particular host that happens to be internal, rather than looking for a host address that can be used internally.
<mgz> right, works less well compounded, hostport likewise
<rogpeppe> perhaps hostName (hostname?) and hostPort might be better
<mgz> dstroppa: you have review
<mgz> er... if codereview is actually up atm
<mgz> okay, now it's back and the post went through
<dstroppa> mgz: got that, thanks
<fwereade> arosales, cmars, mgz, mramm2, I apologize for my absence this afternoon, the whole island had a power cut :/
<mramm2> fwereade: no problem!
<mramm2> randomly, friend of mine just messaged me a malta related video: https://www.youtube.com/watch?v=LXfVlCuWG6g
<arosales> fwereade, no worries, thanks for the fyi
<fwereade> mramm2, haha, I recognise that one :)
<cmars> fwereade, no prob, we'll resched
<fwereade> cmars, most of tomorrow is free for me I think
<fwereade> (a 132kV something-or-other tripped at the delimara power station... 132kV seems like quite enough voltage for me to forget the other details)
<thumper> 'ello
 * thumper looks at the modest proposal email thread and gives it a miss
 * thumper looks at the juju run work and tries to split it up into three chunks for review
<thumper> also realised I missed some tests...
<thumper> although in the last pipe
 * thumper gets to work
 * thumper things of music, perhaps dubstep
<jcastro> thumper, ok, I am just going to use the vagrant image for everything
<thumper> :)
<jcastro> I don't understand why juju needs to put stuff all over the disk
<jcastro> the minute something goes wrong the entire installation is worthless
<thumper> jcastro: there are reasons...
<thumper> perhaps we can discuss over a beer sometime
<jcastro> sure
<jcastro> maybe we should just tell people to always use vagrant?
<jcastro> I've had to reinstall twice this cycle already. :-/
<thumper> ?!
<thumper> really?
<thumper> that seems real screwy
<jcastro> well, you couldn't fix it the first time
<natefinch> thumper: what does git --version return for you?   I'm trying to figure out some of the tests that fail due to a newer version of git
<thumper> natefinch: $ git --version
<thumper> git version 1.8.3.2
<natefinch> thumper: and I presume uniter tests pass for you?  specifically the tests in worker/uniter/charm  ?
<thumper> natefinch: yep, all passing
<thumper> just ran them :)
<natefinch> thumper: cool
<thumper> busy breaking things up for review
<natefinch> thumper:  they're broken with git 1.8.5 for whatever reason... one fix was easy, the other... well, I'm not sure yet
<thumper> ack
<natefinch> thumper: ahh, I see it.  "git add -A ." used to be a NOOP if there were no files to add.... now in 1.8.5 it errors out saying "no files match filespec '.'"
<thumper> ha
<natefinch> it bugs me that "apt-get upgrade foo"  does not work the way "apt-get install foo" or "apt-get remove foo" works.  Inconsistent UI is aggravating
<thumper> :)
<thumper> you have seen git koans right?
<natefinch> thumper: sounds familiar
 * thumper needs another coffee, and some food
<mramm2> thumper: how are you on the networking stuff?
<mramm2> looks like MaaS folks have scheduled an emergency huddle in 25 min
<thumper> mramm2: not too hot, but I'm good at bluffing
<bigjools> o/ mramm2
<mramm2> ;)
<thumper> bugger, games up
<bigjools> I talked to thumper before xmas
<bigjools> you were useless :)
<mramm2> kapil is the best to talk to
<mramm2> he wrote most of the existing network sketch
<thumper> I'll come along to throw comments from the sideline
<mramm2> but... he is in london at a sprint this week
<thumper> not sure how much help I'll be
<bigjools> yeah he was a "tentative" on the invite
 * bigjools in another call until :30
<mramm2> thumper: bigjools: I have a candidate who would like to talk to me in 30 min
<thumper> bwahaha
<mramm2> do you think I can duck out after the first few min of our call?
<bigjools> thanks mramm2
#juju-dev 2014-01-10
 * thumper goes to look for food for lunch
<thumper> axw, wallyworld_: I have the last of juju-run up for review in three hunks
<wallyworld_> ok, will look in a bit
<axw> thumper: yup, was about to have a look
<wallyworld_> thumper: dumb logging question
<wallyworld_> thumper: i have a logger i have just created in the mock charm store
<wallyworld_> if i log Infof, nothing is written. i have to log Errorf to see some output
<wallyworld_> i'm not sure why in this once case the messages are being filtered like that
<thumper> wallyworld_: got the code?
<wallyworld_> this is in a test where i capture log output
<wallyworld_> i'll pastebin
<thumper> ok...
<thumper> the default logging for the test is probably set to warning
<thumper> what I do in test setups where I want more logging is this...
<thumper> loggo.GetLogger("my.test.thing").SetLogLevel(loggo.TRACE)
<thumper> the logging levels get cleared during the logging test suite setup
<thumper> in testing/testbase
<wallyworld_> thumper: https://pastebin.canonical.com/102760/
<wallyworld_> the same code works elsewhere i think
<wallyworld_> i can try setting the log level to trace
<wallyworld_> when i say the same code works elsewhere, i mean that in non test code, log capture works as expected
<wallyworld_> ie the logger is created in prod code and no SetLogLevel is required
<wallyworld_> in my pastebin, if i change Infof to Errorf it works
<thumper> have I mentioned recently that using logging to confirm things is a terrible idea?
<wallyworld_> yes
<wallyworld_> but it's not easy to do anything else
<thumper> I bet your logger isn't using "juju." as the base
<thumper> look at testing/testbase/log.go:48
<wallyworld_> ah i changed it to juju and it worked
<wallyworld_> didn't realise juju was special
<thumper> juju is always special
<wallyworld_> so with the log verification thing, the header value passed in has no effect on the mock store functionality, it is just a label so to speak. so very hard to verify that is has been passed through
<axw> thumper: dunno if you saw, I put up a CL for destroy-env in manual. I've been doing testing of bootstrap on Windows, and found more problems (unrelated to my changes)
<thumper> axw: ok
<thumper> I'm just looking at your review
<thumper> paste a link and I'll look next
<axw> will carry on with that, and then get onto getting manual provisioning in non-null working
<axw> thumper: did I miss anything at the end of the meeting yesterday? my wifi died
<thumper> axw: not really
<axw> thumper: "sure, although this is paranoia as there is no other return options." -- I was thinking about panics, mainly. not going to happen with the code as it stands, but someone else might come along and botch it up
<thumper> axw: ah, interesting point
<thumper> weird having a language that "kinda" has exceptions,
<thumper> either you should, or shouldn't, but mixing them is weird
<axw> like I said, it's me being paranoid; as the code stands, it's actually not necessary and your code works fine
<thumper> I still changed it :)
<thumper> axw: where is the code that removes the upstart job on SIGABORT?
<axw> thumper: preexisting, in cmd/jujud/machine.go, uninstallAgent
<axw> thumper: the same code that runs when destroy-machine is run, is exercised by this
<wallyworld_> axw: i'm looking at your ssh fingerprint branch. two issues - 1.for me md5.Sum() is not valid. i need to use md5.New().Sum() and 2. the fingerprint is different to ssh-keygen -lf which is why I abandoned ny attempt to write a go version
<thumper> axw: ok, nice
<axw> wallyworld_: md5.Sum is not valid?
<wallyworld_> not for me. my go src does not have it
<axw> wallyworld_: if the fingerprint is different, why do all the tests pass?
<thumper> :P
<axw> wat
<axw> maybe it's a 1.2 thing
<wallyworld_> axw: perhaps the fingerprint is different when not using 1.2
<axw> wallyworld_: if you changed it to use md5.New.Sum, I know why it's not working
<axw> because the slice returned does not have len == md5.Size
<wallyworld_> ah ok
<axw> wallyworld_: are you on 1.1?
<axw> does crypto/md5 have the Size constant?
<wallyworld_> i think so yeah
<wallyworld_> let me check
<wallyworld_> firsly, i'm on go 1.1.2
<axw> it would be nice if the docs had "since <version>" like the Python docs
<wallyworld_> it does have the SIze constant
<axw> thanks
<wallyworld_> +1 to that
<thumper> axw: you gocrpto ssh branch is kinda hefty
<axw> thumper: yeah I'm going to split it
<axw> that was silly
<axw> I did want to get feedback on general direction tho
<thumper> I'll look after my coffee
<axw> I will write some fingerprint tests after my tea
<thumper> hmm... looks like the bot is stuck maybe?
<thumper> axw: what do you think we should do if the results aren't utf-8 capable?
<thumper> axw: how about base64 encoding it and add a flag?
<axw> thumper: json/yaml will do that for you if it's []byte
<thumper> hmm...
<axw> if you're running one command, I'd just write it directly to Stdout/Stderr as it is
<thumper> axw: a key reason I didn't like keeping it as []byte is that it isn't easy to compare against
<axw> then you cat binaries and whatever :)
<thumper> axw: perhaps that doesn't matter...
<thumper> except...
<thumper> if you are running on multiple machines
<thumper> even with smart
<thumper> you'll get multip results
<thumper> I'd prefer to have a string if I can, and be explicit if I can't
<axw> doesn't smart go to json/yaml if there are multiple targets?
<thumper> yaml
<thumper> but if the stdout is []byte
<thumper> it is unreadble
<axw> yeah, so I'm just suggesting it be base64-encoded if it's not a valid utf-8 string
<thumper> that I can do
<axw> you might have to add an additional field tho
<axw> so you can distinguish base64-encoded binary from something that was already base64
<thumper> yeah, that was my thinking too
<thumper> also, I do like the idea of supporting globs...
<thumper> but perhaps not just yet
<thumper> :)
<thumper> let's get the basics out there
<axw> yep fair enough
 * axw wishes the bot would hurry up and merge destroy-env, so he can do a happy dance
<thumper> axw: how do I check for valid utf8?
<thumper> axw: bot is stuck
<axw> thumper: utf8.Valid
<axw> aw poop
<thumper> is that encoding/utf8?
 * thumper pokes the bot
<axw> just utf8
 * thumper tries to remember all the steps...
<thumper> there was a lock file there
 * thumper deleted it
<thumper> and is watching the log
<thumper> for some reason, chose mine first
<thumper> it is running again
<thumper> axw: unicode/utf8
<axw> thumper: eh, yes, sorry
<thumper> ctrl+. ctrl+p uft8
<thumper> axw: example invalid utf8 for a test?
<axw> umm
<axw> 0xFF ?
<thumper> kk
<axw> thumper: MSB indicates there's more bytes coming after to make up the rune
<wallyworld_> thumper: i commented on one of your branches - i disagree with the need to pass in apiConfig
<thumper> while I agree only the datadir is needed right now, it seemed more reasonable to pass in the entire config interface than a single value
<thumper> however I don't care strongly
<wallyworld_> thumper: it's just that we have a method off agentConfig which extracts values
<wallyworld_> so with your approach we are inconsistent
<wallyworld_> we are extracting values off the config, and then passing the config in anyway
<wallyworld_> and someone wrote that StateAPIInfo method or whatever it's called to get just the bits needed
<wallyworld_> I'm neutral on the need for that method etc - just want to be consistent
<thumper> wallyworld_: that was mostly to avoid rewriting too many tests...
<thumper> but I can fix
<thumper> I was trying to be lazy
<wallyworld_> :-)
<thumper> like all good programmers
<thumper> yes I realised it was a little icky
<thumper> but my fucks to be given was approaching zero
<wallyworld_> can understand that
<wallyworld_> but i twitched a lot reading the code
<wallyworld_> my view - StateAPIInfo shgould return a struct
<wallyworld_> not individual attrs
<wallyworld_> and then you can add dataDir to that struct
<wallyworld_> and we can extend easily if needed
<wallyworld_> without changing method signatures etc
 * axw happy dances
<axw> manual provider is complete
 * wallyworld_ -> shops for dinner food
<thumper> wallyworld_: I actually took your advice and just passed through the datadir
 * thumper runs the tests to see if all are still good
<rogpeppe> mornin' all
<fwereade> dimitern, hey, would you give the bot a little kick please? there are a few branches that are lying around approved
<dimitern> fwereade, sure, looking
<dimitern> fwereade, jam, standup
<natefinch> when anyone gets a chance, very small change to fix the tests in trusty (or for anyone else with a newer version of git): https://codereview.appspot.com/49470047
<natefinch> rogpeppe: ^^ this should help your tests on trusty
<rogpeppe> natefinch: reviewed
<natefinch> dimitern, mgz: bot appears out of disk space
<natefinch> rMsg:"syncThread: 14031 Can't take a write lock while out of disk space", Healthy:true, State:5, Uptime:60, Ping:0}}}
<dimitern> natefinch, hmm - I cleaned up /tmp/ - maybe it managed to get into a loop or something and exhaust it again
<dimitern> (so soon anyway - it never happened like this before)
<rogpeppe> this hopefully mean we can lose the forked http package from gwacl: https://codereview.appspot.com/48580043
<dimitern> natefinch, it doesn't seem it runs out of space: http://paste.ubuntu.com/6726123/
<hazmat> any simple streams experts around?
<dimitern> natefinch, maybe you're looking at an earlier log/
<dimitern> ?
<dimitern> hazmat, wallyworld_  is your man
<hazmat> wallyworld_, you around? got a user on irc  (private channel) having some issues getting set up with their private openstack cloud
<wallyworld_> hey, i've had a few drinks but i'm here :-)
<hazmat> their doing the juju-metadata generate-images but they still get errors against it
<wallyworld_> log?
<hazmat> wallyworld_, coming up via priv msg
<wallyworld_> ok
<natefinch> dimitern: it was from 15 minutes ago... but maybe somethnig else is going on
<TheMue> fwereade: heya, would you mind another look at https://codereview.appspot.com/44540043/?
<dimitern> natefinch, bizarre.. have you tried turning it off and on again? :) reapprove i mean
<fwereade> TheMue, should get to it soon, but probably after lunch
<fwereade> TheMue, (stuttering: tailer.FilterFunc reads better than tailer.TailerFilterFunc)
<natefinch> dimitern: trying again
<mattyw> fwereade, would you be ok if we resheduled the juju id meeting to monday?
<fwereade> mattyw, sure :)
<mattyw> fwereade, tue instead if that's ok
<TheMue> back from lunch
<TheMue> fwereade: ah, ok, will change that
<wallyworld_> mgz: ping
<mgz> wallyworld_: hey
<wallyworld_> hi, there's a guy having trouble with openstack and juju
<wallyworld_> he has his image metadata in a container, the perms seem correct, but he can't read the json files
<mgz> is there a bug or mailing list thread I should be looking at?
<wallyworld_> ie if he pastes the link in a browser, it says unauth
<wallyworld_> mgz: i'll pm you the private irc channel details
<rogpeppe> fwereade: i just left you a query on https://codereview.appspot.com/49470047/
<natefinch> rogpeppe: I don't think you actually CC'd fwereade in this: https://codereview.appspot.com/49470047/#msg6
<rogpeppe> natefinch: I pinger him above
<rogpeppe> pinged
<natefinch> rogpeppe: oh, missed it, ok.
<rogpeppe> natefinch: i presume he sees the emails anyway
<fwereade> natefinch, rogpeppe: sorry, I'm kinda focused on a weird bug
<rogpeppe> fwereade: no probs
<natefinch> fwereade: no rush, definitely
<rogpeppe> natefinch: i'd appreciate a review of this, if you could. it's only a staging post, but I'm hoping that it implements the core part of the replica set maintenance algorithm reasonably: https://codereview.appspot.com/49920045
<rogpeppe> fwereade: ^
 * rogpeppe is now done for the week
<rogpeppe> happy weekends all!
<natefinch> rogpeppe: sure thing
#juju-dev 2014-01-12
<thumper> morning
<wallyworld_> thumper: g'day, got time for a hangout?
<thumper> wallyworld_: yes, I have jesse here with me right now
<wallyworld_> https://plus.google.com/hangouts/_/76cpi8fve17qps06s1ssppkjc0
#juju-dev 2015-01-05
<thumper> davecheney: you around?
<thumper> davecheney: I'd like you to join waigani and me in a hangout
<thumper> to debug this channel problem
<davecheney> thumper: on the phone
<davecheney> do you have a working code sample ?
<thumper> davecheney: we have a non-working code sample
<davecheney> thumper: still OTP
<davecheney> can you show me the code ?
<davecheney> thumper: ok, off da phone
<davecheney> waigani: var timeout chan something // can't remember
<davecheney> if req.timeout != [
<davecheney>  timeout = time.After(timeout)
<davecheney> }
<davecheney> select {
<davecheney> case <- timeout: // will only be selectable if timeout != nil
<davecheney> waigani: thumper http://play.golang.org/p/PKlJ1dMvvM
<axw> anastasiamac: hiya. do you want to have a hangout? not much to talk about yet... :)
<anastasiamac> axw: happy new year!
<anastasiamac> axw: m actually still on holiday today ;(
<axw> anastasiamac: ah, no worries. get out of here ;)
<anastasiamac> axw: u r holding our tanzanite fort!
<axw> happy new year to you too
<anastasiamac> axw: thnx :) talk tomorrow!
<perrito666> nites, happy new year to all
<perrito666> anybody seen walyworld?
<anastasiamac> perrito666: u2!!! :)
<anastasiamac> perrito666: someone wished me a Happy New 2005! I was so happy for a while :)
<anastasiamac> perrito666: wallyworld caming today (still on holidays) - back tomorrow
<anastasiamac> perrito666: camping even
<perrito666> ah ok, then Ill see him tomorrow afternoon for me, I am actually on holiday too, its sunday night here
<anastasiamac> perrito666: have a gr8 sunday before work :)
<waigani> davecheney: thanks for the help and notes. I've jotted them down for the new branch.
<perrito666> anastasiamac: tx, although there are only 1.5 hs left to my sunday
<thumper> anastasiamac: wallyworld camps all the time ;-)
<thumper> anastasiamac: and if you are on holiday, what are you doing here?
<perrito666> ok fun ppl, see you all tomorrow
<perrito666> tadaa
<davecheney> waigani: np
<jam> happy new year everyone!
<wwitzel3> jam: happy new year :)
<jam> wwitzel3: and to you, though why are you sitting in Juju-dev at Sunday Midnight ?
<wwitzel3> jam: just lurking
<thumper> o/
<thumper> happy new year to you both
 * thumper is done for the day
<jam> same to you thumper, have a good evening
<thumper> ciao
<dimitern> morning folks!
<jam> morning dimitern
<dimitern> hey jam
<TheMue> morning
<dimitern> TheMue, morning
<TheMue> dimitern: heya, and a happy new year.
<dimitern> TheMue, thanks! and cheers to you too ;)
<voidspace> morning all, happy new year
<voidspace> fwereade: o/ morning, happy new year
<dimitern> voidspace, fwereade, hey, morning and happy NY as well ;)
<voidspace> dimitern: morning
<fwereade> dimitern, voidspace: happy new years!
<perrito666> good morning everyone and happy new year to those I didn't see since last year
<voidspace> ooh, maas update worked flawlessly
<voidspace> perrito666: morning, happy new year
<perrito666> voidspace: dont sound so surprised :p
<voidspace> perrito666: I know about computers
<voidspace> perrito666: I'm constantly surprised that anything works at all
<katco>  happy new year all!
<perrito666> idem katco
<katco> perrito666: i'm not familiar with that acronym :p
<perrito666> lol, sorry that is latin I think, its the word used in spanish for likewise or ditto
<katco> perrito666: ah ok :)
<katco> perrito666: perhaps as in "idempotent"
<dimitern> katco, perrito666, hey ;) happy NY and welcome back
<perrito666> idem means equals iirc, and in spanish, to say likewise we use a word which roughly translates to equally
<katco> dimitern: same to you! welcome back!
<perrito666> dimitern: hey happy new york to you too :p
<dimitern> thanks!
<dimitern> katco, btw if you haven't tried goflymake in emacs (with flycheck or flymake) it's *awesome* - syntax checking on the fly running go build in the background
<katco> dimitern: yes, i run it :)
<dimitern> katco, :) nice! - I wasn't sure it brings a lot, but now I really like it
<katco> dimitern: yeah, i like it too
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1407699
<perrito666> wwitzel3: ericsnow getting there, for some reason my connection to plus.google.com is not working
<voidspace> dimitern: so, it's worse
<voidspace> dimitern: we need to list the nodegroups and then list the interfaces for all groups
<dimitern> voidspace, oh what's that?
<voidspace> dimitern: it's only *marginally* worse
<dimitern> voidspace, yeah :/
<voidspace> dimitern: it's n calls instead of one
<voidspace> dimitern: and the interfaces call doesn't have the cidr
<voidspace> dimitern: I can *construct* a CIDR I think
<dimitern> voidspace, worthy of a maas bug
<voidspace> dimitern: but the output isn't immediately compatible with SubnetInfo
<voidspace> dimitern: I have a bug, I can add to it
<dimitern> voidspace, it has static ip range high and low, right?
<voidspace> dimitern: yep
<voidspace> dimitern: http://pastebin.ubuntu.com/9677036/
<dimitern> voidspace, why do you need a cidr?
<dimitern> voidspace, ah, to match yeah
<dimitern> voidspace, well it should be trivial to construct one from "ip" + "subnet_mask"
<voidspace> dimitern: nodegroups-interface doesn't have vlan tag either
<voidspace> dimitern: and the provider id will be the nodegroups-interface id not the network id (I assume)
<voidspace> dimitern: unless a nodegroup interface and a network are the same thing
<voidspace> which is unclear to me
<voidspace> dimitern: they're slightly different (and the names are different) based on the maas cli here
<voidspace> the nodegroup-interface has the name "eth0" whereas the network has the name "maas-eth0"
<dimitern> voidspace, nope - afaik interfaces and networks are different entities in the maas db
<voidspace> which worries me slightly - does it *matter* which we use
<voidspace> I would expect it to matter
<dimitern> voidspace, so to get enough to fill in SubnetInfo you'll need to use both the network config and the interfaces
<dimitern> voidspace, for juju, the subnet's provider id is the maas network name
<voidspace> dimitern: right but they have different names *etc*
<voidspace> so matching them up is hard
<voidspace> in my local maas the network has ip 172.16.0.0, whereas the nodegroup interface has the ip 172.16.0.2
<dimitern> voidspace, istm you can only match them if the network's cidr and the interface's generated cidr are the same
<dimitern> voidspace, that's the same - 172.16.0.x masked with 255.255.255.0 yields 172.16.0.0
<voidspace> yep, the netmask is the same
<voidspace> so they are actually the same
<voidspace> I just have to construct the cidr correctly
<voidspace> ok
<voidspace> dimitern: thanks
<voidspace> dimitern: so, we could still take an instance id and only pair up networks from the filtered list with nodegroup interfaces
<voidspace> as we'll still need the call to the networks api
<dimitern> voidspace, let me think for a bit..
<dimitern> voidspace, consider having *a lot* of networks, but a given node only uses a few
<voidspace> then having a filtered list is useful
<dimitern> voidspace, it seems reasonable to filter by instance id, if possible to only get the relevant networks
<voidspace> yep
<voidspace> dimitern: cool, I'll undo that change then...
<dimitern> voidspace, cheers, and sorry for the round-tripping :
<dimitern> :)
<voidspace> :-)
<alexisb> cherylj, welcome!
<alexisb> all cherylj just joined the Juju Core team
<perrito666> well wellcome to all cherylj
<jw4> cherylj: welcome!!
<ericsnow> cherylj: congrats and welcome!
<cherylj> thanks everyone :)
<cherylj> I'm super-psyched to be part of the team
<TheMue> cherylj: heya and welcome to the team from Germany too
 * perrito666 got some browser to work properly after only 2 months
<cherylj> thanks, TheMue
<alexisb> I have to day it is oddly quiet in this channel today :)
<perrito666> alexisb: it is a big machinery it takes a bit to get it rolling again
<alexisb> perrito666, heh :)
<voidspace> g'night all
<voidspace> off to see Phantom of the Opera
<katco> cherylj: welcome to the team, cherylj :)
<cherylj> thanks, katco :)
<jog> cherylj, welcome!
<katco> cherylj: btw if you have any questions about go or otherwise, feel free to ask here or ping me personally. i promised thumper i would help however i could! :)
<cherylj> Hey jog, long time no see ;)
<cherylj> And thanks, katco.  I'm still making my way through the New Starter Tasks and discovering all the things that I still don't have access to
<katco> cherylj: fun times :)
<perrito666> cherylj: katco think of it as a videogame, then we can all get together at a sprint and remember: "how did you beat the level where the dragon blocks the pop3 mail access?"
<katco> perrito666: haha
<katco> perrito666: how many lives do we get, and are we on easy mode or hard mode?
<perrito666> katco: good question, I don't intend to find it
<perrito666> :p
<katco> hehehe
<perrito666> I still recall that level where my phone holding 2fa died on me 14k km away from home
<katco> that is the stuff of nightmares
<perrito666> and I was using a brand new os, which held none of my login cookies
 * perrito666 lights a candle to IS
<katco> lol
<sinzui> katco, perrito666 : I don't see many Core on line...do either of you have time to look into bug 1407699
<mup> Bug #1407699: Precise services cannot be deployed <ci> <deploy> <precise> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1407699>
<sinzui> katco, perrito666 I need to capture some logs from a machine 1 or 2 to get more information
<perrito666> mmm I have seen this before
<perrito666> sinzui: Ill take it
<katco> i've seen it stuck in pending before, but i'm not sure if it's for the same reason
<perrito666> I have seen the particular error in functional ha backup and restore
<perrito666> it is a bit more detailed since it breaks while trying to fetch a given file
<perrito666> sinzui: precise-dummy charm is publicly available?
<sinzui> perrito666, yes., but it happens with the precise ubuntu charm too
<perrito666> sinzui: I am trying to make sure Ill try to correct incantation, Ill check the config for the test env
<sinzui> perrito666, https://code.launchpad.net/~juju-qa/juju-ci-tools/repository is the charm repo used in tests.
 * perrito666 pulls master for the second time this day and gets updates... isn't merge blocked?
<sinzui> perrito666, its a cloud-init issue
<sinzui> perrito666, I will attach the logs to the bug
<jog> sinzui, I'm also seeing '/bin/sh: 1: exec: cloud-init: not found' at the console for the maas nodes that were deployed for precise charms
<sinzui> perrito666, https://bugs.launchpad.net/juju-core/+bug/1407699 looks like failure in packages
<mup> Bug #1407699: Precise services cannot be deployed <ci> <deploy> <precise> <regression> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1407699>
<sinzui> jog I expect the maas tests to be using trusty as the tests claim. Are they?
<jog> sinzui, bootstrap node is trusty but the dummy-source and dummy-sink are precise
<sinzui> jog, that is odd, I know we can do that, but we usually make them match. Anyway. we know know all testfailures match for br 2195
<thumper> cherylj: welcome
<cherylj> thumper:  thanks!
<thumper> cherylj: do you have hangouts set up?
<thumper> cherylj: ISTR that you do
<thumper> perrito666: how goes the looking at the critical bug?
<thumper> perrito666: it smells like a missing package...
<perrito666> thumper: almost sure its a missing package
<perrito666> trying to get to know a bit more of cloudinit to know what is going on
<thumper> perrito666: have you poked the cloudinit folks?
<thumper> smoser I think
<perrito666> sinzui: if this ends up being a "third party" issue, how is it handled? I am guessing it trascends just saying "not our problem", just open a bug to the right people?
<waigani> menn0: did you get hit by another quake? http://www.stuff.co.nz/national/64684438/large-earthquake-jolts-canterbury-awake
<menn0> waigani: yep we did. it didn't feel too bad but was quite different to the other little jolts i've felt while i've been here
<sinzui> perrito666, use "Also affects project"
<menn0> waigani: it went on for quite a while and left the lights in hallway swinging for ages
<sinzui> perrito666, also, why isn't older juju affected, or trusty?
<waigani> menn0: yikes, glad you're all okay
<thumper> sinzui: older juju passes fine on precise?
<thumper> sinzui: I have just been reading the cloud-init log
<sinzui> thumper, yep, every upgrade test used 1.20.x to boostrap the same stack
<waigani> menn0: I now have an image of you unicycling in an earthquake
<thumper> sinzui: hmm...
<thumper> sinzui: can we get the actual cloud init file off the machines?
<thumper> sinzui: and compare the 1.20 cloudinit file with the 1.22-alpha?
<sinzui> thumper, the cloud-init-output.log?
<thumper> no, the source
 * thumper looks for the location
<thumper> sinzui: so.. bootstrapping works on precise but adding machines doesn't?
<thumper> sinzui: is that right?
<sinzui> thumper, yep
<thumper> sinzui: ok, unlikely to be an actual cloud init problem then...
<sinzui> thumper, the log I attached to the bug shows that cloud-init was removed during the upgrade and install steps...should it have been?
<thumper> I don't know
 * thumper pokes locally
<thumper> sinzui: local precise fails too right>?
<sinzui> thumper, 1.20.14 and 1.21-beta4 can deploy precise services fine. I have a precise machine deployed by 1.21-beta4. What do you want?
<sinzui> well I can get the cloud-init-output.log and see if cloud-init was removed
<thumper> sinzui: I'm looking...
<thumper> sinzui: that would be helpful
 * perrito666 has a broken machine
<thumper> hmm...
<thumper> my local juju deployed precise just fine using local
<thumper> sinzui: looking at this failure: http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/2275/
<thumper> sinzui: the cloud-init log isn't - it is a juju log file
<sinzui> thumper, that isn't the bug :)
<sinzui> thumper, I attached the cloud-init-output.log to the bug
<thumper> however it is still an issue
<thumper> I was looking at the local deploy failure because my one worked
<sinzui> thedac, https://bugs.launchpad.net/juju-core/+bug/1407699/comments/2
<mup> Bug #1407699: Precise services cannot be deployed <ci> <deploy> <precise> <regression> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1407699>
<perrito666> :| ls: cannot access /usr/lib/python2.7/dist-packages/cloudinit/: No such file or directory
<sinzui> perrito666, right the log shows cloud-init was uninstalled
<thumper> perrito666: it removed cloud init...
<thumper> which seems weird
<thumper> right?
<sinzui> thumper, my deploy of precise/ubuntu with 1.21-beta4 is much shorter.  it doesn't go into a phase to remove anything
<menn0> thumper: but your machine-0 is still trusty right? or do you have a precise machine/VM too?
<thumper> menn0: I deployed precise/ubuntu to a machine
<thumper> to get a precise lxc started
<thumper> and it worked fine
<thumper> although, this is from a pre-christmas trunk
 * thumper switches to master and rebuilds
<menn0> thumper: so we think it's a problem with any precise machine, even if other machines are on trusty?
<thumper> I'm looking
<thumper> sinzui: that cloud init file, was that from an lxc machine or a clout machine?
<perrito666> I deployed a just compiled version and created a stream and deployed to aws and it broke straight forward
<sinzui> thumper, machine 1 and machine 2 (both lxc in the case of local provider) had their cloud-init packages removed
<sinzui> I didn't post machine2 since the log is almost identical
<perrito666> I found it
<thumper> perrito666: yes?
<perrito666> cloud-image-utils is being installed
<sinzui> thumper, this looks the the key events. we see cloud-init being upgraded, some deferment, then something decides to do another round of upgrades that removes cloud-init http://pastebin.ubuntu.com/9678855/
<perrito666> it replaces cloud-utils
<perrito666> cloud-init deppends on cloud-utils
<perrito666> and therefore gets whacked
<thumper> and we are getting cloud-image-utils because?
<thumper> I wonder if that was added recently
<perrito666> thumper: seems to be part of an upgrade?
<perrito666> cloud init gets upgraded
<thumper> perrito666: I see in our code we explicitly install it
<perrito666> thumper: oh?
<thumper> why oh why doesn't git have a nice history viewer like bzr explorer
<thumper> is there a nice git equivalent of 'bzr qannotate' ?
<perrito666> it was part of Ians fix before the shutdown seems
<menn0> yep, 15th December
<thumper> perrito666: got a PR?
<perrito666> https://github.com/juju/juju/commit/e6cf44d0
<perrito666> got a commit
<thumper> perrito666: well, he is due to start his work year shortly, so I say we ask him "-)
<thumper> wallyworld_: oi... you broke CI :-)
<thumper> wallyworld_: welcome back to work
<wallyworld_> thumper: hi, i have a branch which i proposed before the break which fixes it if it is the issue i am thinking of
<perrito666> that sounds awfully like my car's mechanic: "oi, remember when you fixed the GNC injector, you broke the fuel pump"
<wallyworld_> i am ina meeting, will talk to you soon
<menn0> thumper, perrito666, wallyworld_: it's PR 1205
<thumper> wallyworld_: for reference, https://github.com/juju/juju/commit/e6cf44d0 introduced the package cloud-image-utils, which breaks precise deployments
<perrito666> and as menn0 said, it is https://github.com/juju/juju/pull/1205
<perrito666> lemme make that into an assigned issue :)
<perrito666> wallyworld_: left you a nice comment and assigned you to the bug, cheers
<perrito666> happy new year :p
<wallyworld_> perrito666: thanks, will look after meeting
<wallyworld_> you too
 * perrito666 wonders why he set up is office in such a manner that he needs to pick one of Air Conditioning or Big screen for the computer
<thumper> cherylj: got time for a chat?
<cherylj> thumper:  yes, ready whenever you are
<wallyworld_> thumper: just finished meeting, reading backscroll, cloud-image-utils is needed to pull in ubuntu-cloudimg-query
<thumper> wallyworld_: otp
<wallyworld_> ok
<perrito666> wallyworld_: I am guessing this might be an issue on cloud-init package dependencies in precise?
<wallyworld_> perrito666: yeah, sadly, seems like a precise only issue
<waigani> davecheney: creating a new watcher for each assert in the test works.
<wallyworld_> perrito666: i'll have to figure out the magic sauce needed to make precise work
<waigani> davecheney: I had to set the revno of each new watcher to the revno of the last watcher, as it gets updated if there was a change
<alexisb> wallyworld_, do you think we will need to make a request to the cloud-init team?
<alexisb> if so I will give gaughen a heads up
<wallyworld_> alexisb: hey. not sure yet, i'll do some more digging first
<perrito666> wallyworld_: I haven't looked at the other distros but cloud-init should deppend on a virtual (i cant recall the actual name) package satisfied by both utils and image-utils
<alexisb> wallyworld_, ack, o and I guess I should say welcome back :)
<wallyworld_> yeah,you too
<waigani> davecheney: my implementation of updating the revno for each watcher feels ugly, so I might poke you once the branch is up for review to see if there is a neater way
<perrito666> wallyworld_: ok a bit of extra info, in utopic it deppends on cloud-utils or cloud-guest-utils
<perrito666> guest-utils is pulled by cloud-image-utils
<perrito666> thus satisfying the dependency
<wallyworld_> perrito666: when you run ubuntu-cloudimg-query, it twlls you to install cloud-image-utils, so that's why i added that dependency
<perrito666> wallyworld_: this seems to be only broken on precise
<wallyworld_> yes, that is my fear
<perrito666> you need to have cloud-init 0.7.6~bzr1022-0ubuntu1 available it would seem
<perrito666> to met the dependency
<perrito666> given the metadata on all three packages you need to get a hold of scott moser
<wallyworld_> i recall cloud-init being updated recently
<alexisb> wallyworld_, smoser is on #server
<wallyworld_> ok, thanks
<perrito666> ok, eod people, see you all tomorrow
<menn0> thumper: can you PTAL at this PR from yesterday? http://reviews.vapour.ws/r/672/
<menn0> thumper: also, you were asking about a git equivalent to bzr qannotate earlier
<menn0> thumper: if your editor doesn't support such a think then have a look at "git gui blame <path>"
<menn0> s/think/thing/
<thumper> menn0: does that allow you to walk back through history?
<menn0> thumper: I believe so. you can click on a rev for a line. I haven't used it much.
<thumper> menn0: I don't think I'm using any sublime git plugins
#juju-dev 2015-01-06
<thumper> wallyworld_: want to have a quick catch up chat?
<wallyworld_> thumper: sure, meet in our 1:1
<thumper> k
<thumper> anyone? http://reviews.vapour.ws/r/676/
<axw> wallyworld_: just want some clarification on the change. AllowsSecureConnection indicates that there's a CA private key on the state servers, which allows them to generate valid certificates. without it, the certs may not have valid addresses and so the LXC code will not be told to fetch images from the API server
<axw> instead it'll go directly to the external source
<axw> is that right?
<wallyworld_> axw: yes, correct
<menn0> thumper: looking
<menn0> thumper: done
<thumper> ta
<rick_h_> thumper: got a sec to chat?
<thumper> rick_h_: sure, why not
<rick_h_> :)
<rick_h_> thumper:
<rick_h_> https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<thumper> rick_h_: you've stopped moving and making noise
<wallyworld_> thumper: if you have a moment, here's a small, simple review http://reviews.vapour.ws/r/677/
<thumper> wallyworld_: ship it
<wallyworld_> ty
<thumper> wallyworld_: is there an example somewhere in a test (and real code) of checking for the existance of tools for a particular version?
<thumper> wallyworld_: I think the upgrade-juju command does it somewhere
<wallyworld_> thumper: you mean seeing if the tarball exists?
<thumper> wallyworld_: well how about I tell you what I want to do
<wallyworld_> ok
<thumper> wallyworld_: and you can tell me the easiest way to do it?
<thumper> when someone says "create-environment" we want the version to default to the client version, but they should be able to specify a version to use when creating
<thumper> the api server needs to check for tool availability
<thumper> for created environments, we can't really support upload-tools
<thumper> nor do I think we should
<wallyworld_> thumper: i could be wrong, but i thought we were heading towards enforcing the same version as the client is used
<thumper> also, we need to make sure the requested version is <= current version of the server
<thumper> wallyworld_: for bootstrap yes
<wallyworld_> since we have run into incompatibility issues even with minor version differences
<thumper> wallyworld_: for 'juju create-environment' not necessarily
<wallyworld_> ok
<thumper> anyway
<thumper> the client's juju version may well be different to the api server they are connecting to
<thumper> so we need to pass an agent-version through
<thumper> the api server then needs to check against its version, and also for tool availability
<thumper> so two things:
<thumper> best way to have the apiserver check
<thumper> and
<thumper> best way to test it (i.e. fake the tools that it thinks are available)
<wallyworld_> so there's an apiserver ToolsFinder from memory
<wallyworld_> i'll need to dig to find some examples, give me a sec
<wallyworld_> thumper: if you look at line 53 in apiserver/client/machineconfig.go, you can see how you can set up to ask the tools finder for tools either matching a specific version, or major/minor match
<axw> wallyworld_: fyi I have updated https://github.com/juju/charm/pull/77, I just need to get fwereade to PTAL since he already started reviewing
<wallyworld_> in terms of testing, i think there's some stuff in apiserver/common/tools_test.go
<thumper> wallyworld_: thanks
<wallyworld_> axw: sure, ty, sounds good
<wallyworld_> thumper: have a look, and if you need some more info, let me know; i think i've given you what you need, but ask if nt
<thumper> cheers
<thumper> my kids are starting to go ferel
<thumper> ferrel?
<thumper> anyway, screaming and fighting
<wallyworld_> will ferrel?
<thumper> they haven't gotten out today
<thumper> feral
<wallyworld_> the dog has i bet
<thumper> nope
<thumper> well, not for a walk
<wallyworld_> she would be feral also then
<thumper> hmm...
<thumper> series...
<thumper> I don't have a series...
<thumper> actually I have a default-series
<thumper> hmm... seems I can leave it blank
<thumper> wallyworld_: is there an easy way to get a list of all the tools available?
<wallyworld_> thumper: from memory, pass in a search params with major = minor = -1, and empty arch, series etc
<thumper> hmm...
<wallyworld_> but you'd normally want to filter on arch, series
<wallyworld_> or arch at least
<thumper> well, when we create an environment, we don't have an arch
<thumper> as we aren't actually creating any machines
<wallyworld_> there's no current use case apart from possibly sync tools where you need a "find all tools"
<thumper> however we do want to use to know that there are some tools available
<thumper> so... situation is:
<thumper> user says create-environment --version x.y.z
<thumper> we check and go "hmm, no tools for that version, but we do have [a,b,c,d]"
<wallyworld_> yeah, the api doesn't work like that. you currently ask for version x.y.z and get that or nothing
<thumper> hmm...
<thumper> bugger
<wallyworld_> or you can ask for all tools matching major/minor version
<wallyworld_> of with -1 for major, minor, you get everything
<wallyworld_> or
<wallyworld_> and you then need to iterate the list of tools you get back to see if the version you want is there
 * thumper hmmmms
<thumper> I'm going to think about it over night and come back to it.
<thumper> cheers
<wallyworld_> ok
<wallyworld_> we can improve the api if needed
<wallyworld_> it fits current use cases
 * thumper nods
<thumper> night all
<axw> jam: when discussing storage, did you and sabdfl talk about fallback at all? the updated spec doesn't really work with fallback in mind at all AFAICT. e.g. if you specify --storage, the spec says the pool used is the default pool, rather than any pool that will satisfy
<jam> axw: sorry about the delay, are you still around?
<axw> jam: hiya, yes, I am
<jam> axw: so I believe the "default" source in MaaS was local disk (block devices coming from loop mounts, non-specified sizes just coming from /)
<axw> jam: ok. so we're back to no notion of degrading; the user just has to be explicit if they want something better than loop-back, and if that fails then they need to try again with something else?
<axw> *automatic degrading
<jam> axw: I believe the spec mentioned  being able to change the default source for an environment, but otherwise yes
<axw> jam: thanks
<jam> axw: I hope you had good holidays
<jam> welcome back
<axw> jam: pretty relaxing, thanks. and you?
<jam> axw: quite nice. Got to go visit family in Germany. And while we didn't get proper snow, it was at least cold for new years :)
<jam> I guess that isn't how you feel about NY
<axw> ah nice :)
<axw> not in the slightest ;)
<axw> I've been in the pool every day for at least the last week
<jam> axw: I remember martin pool mentioning that to him Christmas was Mai Tai's on the beach
<axw> we just had a barbecue with all the family round ours
<axw> wallyworld_: I have just updated http://reviews.vapour.ws/r/589/ again, removing Minimum and Preferred. The top-level Size is minimum, and Count is just required - there's no reason for anything to over deliver on count
<wallyworld_> sure, will look
<axw> wallyworld_: do you know if your change has fixed the regression? it's not clear to me from the CI dashboard
<wallyworld_> axw: yes, the previously failing local deployment CI tests pass; there's still a joyent failure though which is separate i think as all the local tests were failing before
<axw> wallyworld_: can we flip it to released, or do you want to wait for QA to verify?
<wallyworld_> axw: i just checked, the CI tests are almost finished again for a 2nd commit, the joynet local precise tests are pending. let's wait a bit longer to see how those pan out
<axw> ah ok
<axw> cool
<wallyworld_> i'm not sure if we're supposed to flip the bug status ourselves
<wallyworld_> or wait for the reporter to do it
<axw> never mind, I can wait
<jam> hi fwereade, I hope you enjoyed your break
<fwereade> jam, heyhey
<fwereade> jam, yes, thank you, it was quite disconcertingly peaceful -- and yourself?
<jam> fwereade: pretty good for me. We went to Germany to spend time with relatives for the new year. Got to be properly cold for NY (well 5 on NY, but it did get below zero in Germany)
<wallyworld_> fwereade: g'day. we missed our 1:1 earlier. can we do it a bit later
<voidspace> morning all
<axw> morning
<fwereade> wallyworld_, oops, so we did, I haven't quite adjusted to a proper timetable
<wallyworld_> np, i need to cook and eat dinner etc, can i ping you when i'm ready?
<dimitern> voidspace, jam? standup time
<voidspace> dimitern: omw
<voidspace> in fact, here
<jam> dimitern: you still there?
<fwereade> TheMue, jam, voidspace: dimitern's internets have fallen over, he's working on it
<TheMue> fwereade: thx for info
<wallyworld_> fwereade: let me know when you're free to chat?
<fwereade> wallyworld_, cleaner's in here at the moment, maybe 10 mins or something?
<wallyworld_> fwereade: sure, np
<axw> fwereade: would you PTAL at https://github.com/juju/charm/pull/77 ? I think/hope your previous concerns should be allayed
<fwereade> axw, cool, will do
<voidspace> jam: "NodeGroup is the internal name for a cluster."
<voidspace> dimitern: jam: it looks like a nodegroup-interface represents a network interface
<voidspace>     A NodeGroupInterface is identified by the uuid for its NodeGroup, and the name of the network interface it represents: âeth0â for example.
<jam> voidspace: that sounds an awful lot like it would be the actual network interface for a machine. Maybe it is the Node Group controller's interface?
<voidspace>     A NodeGroupInterface is a network interface attached to a cluster controller, with its network properties.
<voidspace> I've asked some questions on #maas
<voidspace> No reply yet
<perrito666> morning
<voidspace> jam: dimitern: an in-between approach (not too much work) is for the provider layer to choose whether it allocates or whether it lets the provider allocate
<voidspace> jam: dimitern: so with maas we use "dynamic allocation" and with ec2 we use static allocation
<voidspace> jam: dimitern: then we can move ec2 to dynamic allocation later if we want
<voidspace> Our current strategy picks an unused address and attempts to allocate that. This returns an error or nil (for success).
<voidspace> We could let the provider implementation of AllocateAddress return a *different* address if it successfully allocates one
<voidspace> allowing it to ignore the requested address if it wants to - which the MaaS implementation always would
<voidspace> slightly janky but flexible
<voidspace> perrito666: morning
<dimitern> voidspace, jam, TheMue, sorry guys I was away till now - first network issues, then the heating stopped..
<TheMue> dimitern: heya, welcome back
<TheMue> dimitern: oh, no heating is hard
<TheMue> dimitern: even harder than no network, hmmmm, or ... *justKidding*
<voidspace> dimitern: hey, hi
<voidspace> dimitern: did you see my questions/comments above or should I repeat them?
<dimitern> :D
<dimitern> I can see the one about nodegroup-interfaces being NICs
<voidspace> dimitern: right
<voidspace> NICs on the cluster controller
<voidspace> dimitern: is that what we want - will they correspond directly (one-to-one) with networks?
<voidspace> dimitern: or should I switch to a hybrid approach (which I like but is admittedly slightly janky)?
<dimitern> voidspace, AIUI networks are created when you add a NGI
<voidspace> dimitern: so, there always should be the one-to-one correspondence we need
<dimitern> voidspace, but you can create them manually as well, so this tells me they *might* sometimes not match 100%, but for a definite answer we should consult the maas guys or the source
<voidspace> I've asked questions on #maas
<voidspace> no answer yet
<voidspace> I will proceed assuming they will match
<voidspace> and will tweak appropriately if needed - or start again with a different approach...
<voidspace> depending on the answer...
<dimitern> voidspace, just a sec
<dimitern> voidspace, it occurred to me there could be valid cases where networks != NGIs
<dimitern> voidspace, NGI == networks only for those maas is supposed to manage dhcp, dns, or both
<voidspace> really?
<voidspace> ah, maybe
<voidspace> just checking what mine is
<voidspace> they seem to correspond and I *thought* I didn't have maas managing dhcp or dns, but I might be wrong
<dimitern> voidspace, it seems logical - otherwise (for non-managed - i.e. vlans, etc.)
<dimitern> voidspace, sorry, that should've been - for non-managed there's not point in having a NGI associated with the network
<voidspace> maas is managing dhcp and dns for my cluster
<dimitern> voidspace, but in any case we *only* care about dhcp-managed networks for the address allocation logic
<voidspace> dimitern: so we *can't* assume a correspondence, which means (as far as I can tell) that we can't always know the static range of the subnet
<voidspace> dimitern: ah right, so it doesn't matter - we can *ignore* networks where we don't have this information
<voidspace> dimitern: so it's one-to-one where we care
<dimitern> voidspace, that's correct I think and it is reasonable - if maas is not managing dhcp/static ips for that net using the net's corresponding NGI then we don't care
<dimitern> yeah I think so
<voidspace> dimitern: cool, thanks
<dimitern> voidspace, I do have a few unmanaged vlans on my maas
<dimitern> voidspace, and despite being unmanaged (by maas) I can still use them for instance selection and then configure them (presumably) myself after maas gives me the node
<voidspace> right, but you wouldn't expect  juju to be able to use them
<voidspace> as they require manual configuration
<dimitern> not for allocating addresses via the maas api, no :)
<voidspace> cool, good enough
<dimitern> but for constrains - yes
<voidspace> ah, so you'll want Subnets to still return those networks just with nil for the AllocatableIPLow/High
<voidspace> meaning "no allocatable addresses"
<dimitern> I think so
<voidspace> so I won't ignore them then
<voidspace> right, I'm going on lunch
<dimitern> cheers
<dimitern> :)
<perrito666> is there anything like distcc for go?
<wwitzel3> ericsnow, perrito666: having some hangout issues
<perrito666> hangout is love
<perrito666> wwitzel3: ericsnow helps if we push this one hour?
<ericsnow> perrito666, wwitzel3: fine with me
<perrito666> ok, lets push it so wwitzel3 can solve his issue without hurrying
<wwitzel3> perrito666: it is solved
<perrito666> wow you are good
<wwitzel3> but if you need to push it, that's fine :)
<perrito666> nah, I am here anyway
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<alexisb> wwitzel3, ping
<voidspace> dimitern: ping
<voidspace> dimitern: philosophical question
<voidspace> dimitern: we've called the maas nodegroups api endpoint and got a list of nodegroups (uuids)
<voidspace> dimitern: we now need to make a series of calls, fetching the nodegroup interfaces for each nodegroup
<voidspace> dimitern: and pulling out of that the ip, static_range_low and static_range_high for each interface
<dimitern> voidspace, yeah
<voidspace> dimitern: an individual call to fetch interfaces for a nodegroup can fail, as can pulling out the details from the result
<voidspace> dimitern: in the presence of an error should we log and continue (my current approach) or error out?
<voidspace> dimitern: the downside of logging and continuing is that even if *every call* errors we don't fail - we just return an empty map
<voidspace> dimitern: the downside of erroring out is that the whole call would fail just for one missing bit of information
<voidspace> dimitern: e.g. nodegroup deleted between fetching the list of nodegroups and querying the interfaces
<voidspace> as I said, my current approach is to log (as a Warning) and continue
<dimitern> voidspace, +1 on logging definitely
<dimitern> voidspace, but deciding whether to error out entirely or not at the end should be:
<dimitern> voidspace, if we gathered enough information, despite some errors -> ok, otherwise ... hmmm possibly wrap and return the (most important?) errors
<dimitern> niemeyer, hey
<niemeyer> dimitern: Heya
<voidspace> but knowing what's "enough" information or not is difficult :-)
<voidspace> if we fail to get the information, the result will be that we decide no networks have allocatable IP addresses
<dimitern> niemeyer, any plans for fix for that issue with gopkg.in not supporting branches like "v2-dev"  (I'll try to find the issue #..)
<voidspace> which is perhaps an odd error to end up with when it's a transient connection failure
<voidspace> I'll think about it
<wwitzel3> alexisb: pong
<alexisb> hey there wwitzel3
<alexisb> can you please join #server
<dimitern> voidspace, we can have a chat tomorrow perhaps? it's getting late and harder for me to not being stupid :)
<voidspace> dimitern: ok mate, you go
<voidspace> dimitern: speak tomorrow
<voidspace> dimitern: I've got more stuff to do now
<niemeyer> dimitern: Yeah, I'll work on gopkg.in this week
<voidspace> it's an annoying little decision
<niemeyer> dimitern: There are a couple of things to improve there
<voidspace> dimitern: the trick is to pick the "less wrong" answer...
<niemeyer> dimitern: The source code linking is also coming
<dimitern> voidspace, cheers, I'm sure you'll find a nice way to solve it :)
<dimitern> niemeyer, nice!
<dimitern> niemeyer, but now it seems you can't import "gopkg.in/amz.v2-dev/ec2" - perhaps I should rename that branch to v2?
<dimitern> niemeyer, until the changes happen?
<niemeyer> dimitern: Please don't do that.. let me fix the problem
<dimitern> niemeyer, ok, no problem - I wanted to ask first
<niemeyer> dimitern: For the time being, just do a "git clone" locally to the right location
<dimitern> niemeyer, yeah, that'll work
<niemeyer> (gopkg.in/amz.v2-dev/ec2)
<dimitern> niemeyer, thanks!
<niemeyer> dimitern: Labeling as v2 would be advertised as a new major available
<niemeyer> dimitern: which means you should not change it further
<niemeyer> dimitern: in incompatible ways
<niemeyer> dimitern: Or is that what you intend to do in fact?
<dimitern> niemeyer, yeah, fair point
<dimitern> niemeyer, no, I intend for it to be stable at least for a while :)
<niemeyer> dimitern: Clarifying the question: do you have further breaking changes to do on v2-dev soon?
<dimitern> niemeyer, I have 2-3 PRs queued up which add new API methods, but don't break (hopefully) existing ones
<niemeyer> dimitern: Well, so you can just rename it
<niemeyer> dimitern: The point of -dev is to prevent people from using it while in a heavy development period, readying for the release
<niemeyer> dimitern: It sounds like what you want is to release it
<dimitern> niemeyer, yeah, fair point
<dimitern> niemeyer, although it's safer to do a few more changes first as I need them anyway, and rename it once v2 is more or less stable
<dimitern> and juju needs to use v2
<dimitern> niemeyer, we should have a call some time this week, if you don't mina and have the time to discuss the other goamz topics - contributors, merging the other forks, etc.
<niemeyer> dimitern: Sounds good, but "stability in this case" is not "won't change", but "won't change in incompatible ways"
<niemeyer> dimitern: Of course
<niemeyer> dimitern: Will be a pleasure
<dimitern> niemeyer, right, cheers!
<dimitern> niemeyer, which of the coming days works for you? perhaps ~1h or less - also at what time?
<niemeyer> dimitern: I suppose now is too late for you, right?
<niemeyer> dimitern: I mean, at this time, different day
<dimitern> niemeyer, yeah, tomorrow about this time is better for me - should I sent and invite then?
<niemeyer> dimitern: +1
<niemeyer> dimitern: Oh, wait
<dimitern> niemeyer, yeah?
<niemeyer> dimitern: I have a 30mins slot at this time
<niemeyer> dimitern: Feel free to start 30 mins earlier, or reduce the slot
<dimitern> niemeyer, ok, so let's say 16 UTC tomorrow for 1h?
<niemeyer> dimitern: Sounds good
<dimitern> niemeyer, thanks, I'll send an invite then
<perrito666> wwitzel3: ericsnow any volunteers to answer that last email?
<perrito666> that was fast :p
<alexisb> wwitzel3, you when the prize for fastest status reporting :)
<ericsnow> alexisb: we still need to verify that networking is not required (only 1(?) existing provider implements it)
<wwitzel3> alexisb: not sure I want the prize .. lol
<alexisb> ericsnow, same with storage?
<ericsnow> alexisb: they all (or nearly) have storage implemented, but only because it was required for juju up until recently (yay axw)
<alexisb> ah ok ericsnow
<alexisb> so ericsnow, wwitzel3 what do you guys need from me to help answer what is needed for storage and network support?
<ericsnow> alexisb: the question came up as we jumped back in yesterday and I figured we'd just ask dimitern
<ericsnow> (looks like I missed him though)
<ericsnow> alexisb: I do think if we still want the networking stuff now it could wait until after we land the GCE provider
<ericsnow> alexisb: as to storage, I'm pretty confident we don't need it; I'll follow up with axw tonight
<perrito666> ericsnow: wwitzel3 alexisb I have a decent overlap with dimitern do you need me to tackle him and ask him something?
<ericsnow> perrito666: feel free to ask him if networking needs to be implemented for the GCE provider (basically none of the other providers have it)
<wwitzel3> ericsnow: patch is merged, I am going to try a manual fix that smoser suggested for testing purposes
<ericsnow> wwitzel3: great!
<wwitzel3> ericsnow: we have a regression
<ericsnow> wwitzel3: :(
<wwitzel3> ericsnow: with the root disk stuff in instance.go
<ericsnow> wwitzel3: k
<wwitzel3> ericsnow: http://paste.ubuntu.com/9683253/
<ericsnow> wwitzel3: want to jump into the hangout?
<wwitzel3> ericsnow: yep
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  None
<perrito666> is there a list for the possible agentconfig keys?=
<voidspace> g'night all
<wwitzel3> nn voidspace
<voidspace> o/
<perrito666> katco: I was really fearing that was a longer pr :p given the extensive description
<katco> perrito666: lol glad to disappoint in that regard :)
<katco> perrito666: i like to provide helpful commit messages if i can remember
 * katco goes to fix lunch
<thumper> cherylj: got a few minutes now?
<cherylj> thumper: yes
<thumper> niemeyer: hey, you around?
<niemeyer> thumper: Here
<thumper> cmars: ping
<cmars> thumper, pong
<thumper> cmars: 'tis our weekly chat time
<cmars> thumper, ah right. joining
<katco> fwereade: ping, 2015 style.
<wallyworld_> alexisb: you free for our QA meeting?
<alexisb> wallyworld_, no I have a conflict today
<wallyworld_> ok
<menn0> wallyworld_: just reviewed http://reviews.vapour.ws/r/678/
<menn0> wallyworld_: just a few questions
<wallyworld_> \o/ tyvm
<wallyworld_> having breakfast, will look soon
<menn0> wallyworld_, thumper: there's PR with fixes for the cloudsigma provider up for review. is anyone sheparding that work or should I review it?
<thumper> menn0: I think there is someone sheparding it, but I don't recall who
<wallyworld_> ditto
<menn0> jam?
<wallyworld_> wayne maybe
<menn0> i'll ask them
<perrito666> menn0: thumper its wayne
<thumper> perrito666: ta
<menn0> perrito666: thanks
 * menn0 is glad to dodgy that large review
 * perrito666 returned from EOD mode just for that, bye folks
<menn0> dodge even
<menn0> perrito666: good night
#juju-dev 2015-01-07
<axw> ericsnow: correct, new providers need not use storage. they *can* if it's beneficial, but from what hazmat described to me it didn't sound like it would be
<ericsnow> axw: just what I wanted to hear :)
<menn0> anastasiamac: you win for providing the most useful PR description I've seen in a while
<anastasiamac> menn0: thank you ;-)
<anastasiamac> menn0: i was apprehensive of submitting another big change... was hoping to make it easier for u :)
<anastasiamac> menn0: i always appreceate ur feedback :)
<wallyworld_> menn0: hopefully the tweaks to the unit agent status pr are ok - i added a Stopping state for unit agents (machines continue to use Stopped)
<menn0> wallyworld_: ok, i'll take a look after i've finished with anastasiamac's PR
<wallyworld_> sure, no hurry, ty
<thumper> menn0: I've updated http://reviews.vapour.ws/r/676/diff/# to add an additional test with multiple environments
<menn0> anastasiamac: regarding the first question in your PR - about a follow up PR to remove the embedded style annotation support
<menn0> anastasiamac: you're just going to change the underlying implementation right?
<menn0> anastasiamac: the old style API will need to hang around for a while to support older clients won't it?
<anastasiamac> menn0: yes, removing embedded annotator and tweak old client to not use it
<anastasiamac> menn0: yes, API will stay ;-) as deprecated...
<menn0> anastasiamac: good. in that case I don't there's a need to increment the API version number.
<menn0> anastasiamac: the external API stays the same after all.
<anastasiamac> menn0: that was my hope ;-) thnx for confirmation!
<menn0> anastasiamac: cool.
<wwitzel3> ericsnow: ping
<menn0> anastasiamac: I'm almost done with the review (looking good). just trying to answer your other questions on the review.
<anastasiamac> menn0: u r almost done? amazing!!! thnk u ;-)
<anastasiamac> menn0: m pondering if it's worthwhile adding a test to explicitely annotate a local charm... current test creates a "cs" charm...
<anastasiamac> menn0: it's just couple of lines of code but will be explicit and closely aligned to the concern in the bug...
 * wwitzel3 dances a jig
<menn0> anastasiamac: hmmm not sure. what's different about a local charm in terms of this code?
<menn0> anastasiamac: regarding your last question, what do you mean by "stuttering" in the tests?
<menn0> thumper: newEnvAsUser? shouldn't that be newEnvWithUser or something?
<thumper> menn0: I suppose
<menn0> thumper: not a biggie
<menn0> thumper: those changes look good
<thumper> cool
<thumper> menn0: if I change the name, good to land?
<menn0> thumper: even if you don't (and I had already said ship it :) )
<thumper> menn0: I don't hold those as binding if the coder does lots of changes
<thumper> :)
<menn0> wallyworld_: have you pushed the latest version of status branch? RB doesn't have it.
<wallyworld_> menn0: i thought so, let me check
<wallyworld_> menn0: the github pr has been updated,but rb appears not for some reason
<menn0> anastasiamac: i've published the review, leaving your last question unanswered.
<menn0> thumper: fair enough. well it look good regardless :)
<thumper> menn0: landing now
<thumper> ok, I'm off, back later tonight hopefully for meeting
<anastasiamac> menn0: sorry - was with kids ;-(
<anastasiamac> menn0: thnx for review - will look now-ish
<menn0> axw: question about your disk PR: how will a user specify the desired disks via the GUI or command line client? Or is this a charm level thing?
<anastasiamac> menn0: re: stuttering - result.Error.Error.Error() ;P
<menn0> anastasiamac: no problems. if you can explain the 4th question some more I can try and answer that one too.
<menn0> wallyworld_: sometime the RB or GH API chokes on large diffs I believe (not sure which side is the issue)
<anastasiamac> menn0: q4... for eg, in apiserver/annotations/client_test.go, l. 131
<menn0> there's certainly something to be said for the extra efficiency that IRC style communication gives you. I was having 3 conversations at once for a while there :)
<anastasiamac> menn0: m impressed with everyone's multi-tasking ;-)
<menn0> :)
<anastasiamac> menn0: from annotations perspective, there is no difference btw local vs non-local charm... i'll leave th test out ;) thnx for the listening ear :0
<menn0> anastasiamac: so by "stuttering" are you referring to to the repeated code snippets?
<anastasiamac> menn0: m using Jesse's jargon :p but yes
<menn0> anastasiamac: I guess it might be nice to have methods for the most commonly used bits: makeWordpressCharm(), makeMachine() seem like the biggest wins
<axw> menn0: "juju deploy --storage <storage>=<constraints>", and (at least while prototyping), "juju machine add --disks <constraints>"
<menn0> axw: cool. I was just curious.
<axw> menn0: those constraints will be combined with charm-level properties in the former case
<wallyworld_> axw: the Disks param to StartInstance - is that still determined from constraints which specify minimum and preferred values?
<axw> wallyworld_: there's no preferred anymore, but yes. on the CLI the user specifies constraints which may include size, count and a storage pool. those are converted to one or more DiskParams by looking up the pool, and (later) combining with charm storage metadata
<axw> wallyworld_: the pool lookup bit will not be in the MVP though; I'm assuming a single, unconfigurable pool for now
<wallyworld_> axw: right. so the code comment just needs tweaking to remove "preferred"
<axw> wallyworld_: ah yeah, thanks.
<wallyworld_> menn0: are you ok just to look at the github commit diffs for that pr?
<menn0> wallyworld_: yep, will do
<wallyworld_> ta
<menn0> wallyworld_: ok done. my comments are probably more due to my lack of understanding than anything wrong with the PR.
<wallyworld_> menn0: great, thank you, looking
<menn0> wallyworld_: i've got to stop for a bit now but will check back in again later on
<wallyworld_> sure
<menn0> wallyworld_: if my comments are silly, please feel free to merge
<anastasiamac> ericsnow: ping?..
<dimitern> morning all
<axw> morning dimitern
<dimitern> axw, \o
<axw> dimitern: what's the plan for switching juju over to github/go-amz/goamz?
<dimitern> axw, right, so I'm having a call with gustavo at 16 utc to discuss this and other related stuff, like collaboration and integration with other forks, maintenance, etc.
<axw> dimitern: ok, cool
<dimitern> axw, my plan is to do it sooner, even if that means using the "unstable" v2-dev branch for a while
<axw> dimitern: I have a couple of minor changes I need to make to goamz, I'm holding off until that's sorted out
<axw> ok
<dimitern> sure
<anastasiamac> dimitern: o/
<dimitern> anastasiamac, hey there
<anastasiamac> dimitern: how r u? happy ny
<dimitern> anastasiamac, cheers :) great to be back to work, eh?
<anastasiamac> dimitern: dfinitely :p
<dimitern> seriously, sometimes holidays seems a wee bit too long
<anastasiamac> dimitern: i actuually need a holiday form my holiday ;)
<anastasiamac> dimitern: as far as celebrations  r concerned, we r still in Xmas mode here - today is Russian Xmas, 13th is Russian old NY, etc...
<dimitern> :)
<dimitern> anastasiamac, oh right - until 14th?
<dimitern> yeah
<anastasiamac> dimitern: m working and celebrating ;)
<dimitern> anastasiamac, that's a nice excuse for a double ny/xmas celebrations
<anastasiamac> dimitern: any excuse to celebrate anything ;-P life is a long party in  my books :)
<dimitern> anastasiamac, awesome
<dimitern> :D
<dimitern> ah, axw - do you mind if I suggest you as a (candidate) maintainer for goamz as well?
<axw> dimitern: sure
<dimitern> axw, cheers
<menn0> anastasiamac: looks like the annotations PR needs rebasing or something...
<menn0> anastasiamac: look at all the commits listed for it on Github. Most aren't yours.
<wallyworld_> thanks menn0 :-)
<menn0> anastasiamac: Reviewboard is also not happy about it
<anastasiamac> menn0: i've rebased, resolved conflicts and got this ;-(
<menn0> wallyworld_: np
<anastasiamac> menn0: that's why i've added a list of files that I have actually touched into the awesome commit comment ;-)
<menn0> anastasiamac: it's almost like you rebased onto the wrong branch or something
<menn0> anastasiamac: i'm a little worried that if you try to merge what's there now something bad is going to happen
<anastasiamac> menn0: m considering to start another branch and move all my stuff there
<menn0> anastasiamac: you might not need to do that
<menn0> anastasiamac: are your commits all at the top of your branch?
<anastasiamac> menno: k. i'll do this either later or tomorrow
<anastasiamac> menn0: looks like they are all the bottom of the list...
<menn0> anastasiamac: I was going to suggest that you use "git rebase --onto ..." but that won't work
<anastasiamac> menn0: i'll start another branch ;(
<menn0> anastasiamac: I see annotations related commits mixed in with other people's ones when I look at Github
<anastasiamac> menn0: most of it additons anyway... ;)
<menn0> anastasiamac: a rebase onto master *should* sort it out
<menn0> anastasiamac: how are you rebasing?
<anastasiamac> menn0: when m on my branch 'git rebase master'
<anastasiamac> menn0: once master is synced...
<anastasiamac> menn0: have to go... i'll do another branch
<menn0> anastasiamac: ok
<menn0> anastasiamac: I'll send you an email with a suggestion
<anastasiamac> menn0: sounds awesome ;-)
<anastasiamac> menn0: thnx!
<anastasiamac> menn0: branch fixed as per ur suggestion! tyvm!!! scotch was ur price, wasn't it?..
<TheMue> morning
<menn0> anastasiamac: yep :)
<fwereade> sorry, freenode seems to keep falling over for me for some reason
<fwereade> I'm in the canonical ones too though if this falls over again
<perrito666> morning
<perrito666> fwereade: I addressed some of your concerns regarding my restore patch and made some action plan for the others since they require more in depth changes of the whole mechanism
<dimitern> TheMue, katco, voidspace, can any of you have a look at this http://reviews.vapour.ws/r/686/ please? If fixes bug 1355813
<mup> Bug #1355813: Interface MTU management across MAAS/juju <add-unit> <amd64> <apport-bug> <canonical-bootstack> <cts> <cts-cloud-review> <landscape> <network> <placement>
<mup> <smoosh> <trusty> <uec-images> <juju-core:In Progress by dimitern> <MAAS:New> <juju-core (Ubuntu):Triaged> <lxc (Ubuntu):Invalid> <https://launchpad.net/bugs/1355813>
<TheMue> dimitern: *click*
<voidspace> dimitern: I can do, but will have to be after lunch
<dimitern> TheMue, ta!
<dimitern> voidspace, no worries
<TheMue> dimitern: done
<dimitern> TheMue, thanks!
<TheMue> so, bfl
<TheMue> dimitern: yw
<dimitern> mgz, hey, do you have 5m?
<mgz> dimitern: hey, was at lunch, what do you need?
<dimitern> mgz, i wanted to ask if you're willing to lend a hand from time to time with goamz reviews and generally helping with maintenance/collaboration
<dimitern> it's going to get more active soon, and there are ideas to merge the existing forks into it gradually over time
<mgz> dimitern: yeah, saw you'd been busy over the holiday sorting that all out
<mgz> I'll try and jump in on reviews on github
<dimitern> mgz, yeah, it was surprising how much attention it managed to gather in a short time
<dimitern> mgz, sweet! thank you!
<ericsnow> dimitern: (in case you haven't been asked yet) what is the priority on implementing networking for the GCE provider?
<ericsnow> dimitern:  Basically none of the other providers implement it at present.
<dimitern> ericsnow, heh :) for gce - i'd say very low
<ericsnow> dimitern: k, cool
<dimitern> ericsnow, we're concentrating on ec2 and maas until 15.04, then openstack will be next most likely
<ericsnow> dimitern: FWIW, the GCE API makes the networking stuff pretty straightforward so adding it later shouldn't be a big deal
<dimitern> ericsnow, that's great to hear!
<ericsnow> mgz, abentley, sinzui: could any of you take a look at http://juju-ci.vapour.ws:8080/job/github-merge-juju/1729/console?
<ericsnow> mgz, abentley, sinzui: it is not clear to me why it can't find the dependency
<mgz> ericsnow: will in just a sec
<ericsnow> mgz: ta
<wwitzel3> ericsnow: you see my commits for gce?
<wwitzel3> ericsnow: was able to fully bootstrap and deploy mysql/wordpress last night.
<bodie_> is there a way to get a charm of a unit without the charm url on state?
<mgz> ericsnow: golang.org/x/crypto is explictly exclused in the build script - if I recall corerctly it had licensing issues
<mgz> or that might have been one of the other ones, and it was just pulled in by mistake, and can now be removed if you actually need to use it
<mgz> I'll find out
<sinzui> mgz, ericsnow. The x/crypto lib was purged because it first appeared in the tree, but wasn't in deps. It appeared there because a subdep pulled it in, but the version of the dep we used did not use it
<ericsnow> wwitzel3: awesome!
<sinzui> mgz, ericsnow (my recollection). I f the license is good, we can remove the line that purges it now that juju's dependencies state it is wanted
<mgz> ericsnow: it looks like you're not actually adding it as a dep in your new code?
<mgz> ericsnow: so, probably just the mechanism you used to update dependencies.tsv wasn't right?
<ericsnow> sinzui, mgz: well, the utils repo depends on x/crypto as of a couple revisions
<ericsnow> sinzui, mgz: so it was added as a dep when I updated the rev for utils
<mgz> okay, I'll need to update the script to try to produce a sane tarball when deps get pulled in by mistake then, that will mean I can drop my other hack
<ericsnow> mgz: cool
<sinzui> ericsnow, good. so if the lib's licence is god we can rm the line
 * mgz giggles at god
<ericsnow> mgz: do you recall what the licensing issue was?
<mgz> ericsnow: I think that was the go.net package test data
<mgz> so, not this one
<ericsnow> mgz: oh good, so once the deps mechanism is fixed in CI I should be able to try merging again :)
<ericsnow> mgz: what is the ETA on that?  I recognize you probably have higher priorities. :)
<mgz> ericsnow: I'll try to do it before your eod so you can try again
<sinzui> ericsnow, just a few minutes to remove a line and update the machine
<ericsnow> mgz: thanks!
<mgz> ah, yeah, and the unblocking of you r branhc is even easier, because it doesn't need the script fix
<mgz> just hte blacklist remove
<mgz> sinzui: shall I do it, or are you?
<sinzui> I will. I have it open
<katco> cherylj: ping
<cherylj> katco: pong
<katco> cherylj: got a few minutes to chat? i would love to meet you
<cherylj> Give me just a minute
<katco> cherylj: no rush at all
<wwitzel3> ericsnow: did you see smosers response in cloud-init?
<wwitzel3> ericsnow: I'm going to add that information to the doc
<ericsnow> wwitzel3: not yet :)
<dimitern> niemeyer, hey, just a reminder - I'm in the hangout now :)
<ericsnow> perrito666, wwitzel3: standup?
<dimitern> katco, hey, as you've contributed to goamz in the past, are you willing to give a hand from time to time with reviews and maintenance?
<sinzui> ericsnow, I let you down. I got distracted and didn't complete the deployment to the server. I am doing it now. poke in 15 minutes if I haven't confirmed it is in place
<ericsnow> sinzui: no worries; I'm itching to land the patch, but the only thing it blocks is the new GCE provider (which won't be landing yet) :)
<ericsnow> sinzui: thanks for taking the time to sort this out
<perrito666> ericsnow: wwitzel3 having some connectivity issues, sorry Ill be there in 10 mins
<ericsnow> perrito666: k
<sinzui> ericsnow, you can resubmit
<ericsnow> sinzui: thanks!
<perrito666> ericsnow: wwitzel3 I need to sort a couple of things before the standup, can we do-it in half an hour?
<ericsnow> perrito666: fine with me
<perrito666> thanks a lot
<perrito666> wwitzel3: ?
<wwitzel3> I wasn't even paying attention, sure
<perrito666> lol
<wwitzel3> :)
<wwitzel3> I'm in deep thought, I will be in seclusion in the west wing
<bodie_> I'm having some trouble with state/ConnSuite.  it seems that the charm URL isn't found on the testing units of a testing service
<bodie_> if anyone can enlighten me, it would be much appreciated!
<katco> dimitern: hey sorry i was on a call. certainly i can, as long as i'm not too pressed for time with other juju priorities :)
<dimitern> katco, awesome, will send you an invite to join! I promise not to pester you too much :)
<katco> dimitern: :)
<perrito666> ericsnow: I can see you
<perrito666> :p
<ericsnow> perrito666: haha
<perrito666> wwitzel3: can I get you to surface from the depth of your thoughts for a moment?
<perrito666> fwereade: ping me when you have a moment please :p
<fwereade> bodie_, a unit's charm url gets set by the uniter when it's actually downloaded a charm, it doesn't otherwise have one
<fwereade> bodie_, what were you expecting to use it for?
<bodie_> fwereade, I'm set.  didn't realize units weren't created with the charm URL of the parent service
<bodie_> fwereade, was just discovering that for myself :)
<fwereade> bodie_, what would you be using it for?
<katco> fwereade: hey when you have a moment, do you have time for a hangout?
<fwereade> katco, might be able to manage one later, it's a bit loud and approaching-suppery here at the moment
<katco> fwereade: no worries. it can be tomorrow as well... i think i'll likely spend the day doing reviews
<fwereade> katco, I'll ping you if/when I'm free later, otherwise grab me tomorrow :)
<katco> fwereade: sounds like a plan, and happy new years :)
<bodie_> fwereade, when an Action is enqueued on a unit, it should validate the params before enqueuing (sp?) it.  that way the user immediately gets an error when invoking it via `juju do`.
<bodie_> s/enqueuing it/adding it to the actual queue on state/
<bodie_> otherwise, the user must discover ID10T error via `juju fetch`
<bodie_> fwereade, if a unit doesn't have a charm URL, then the unit's charm can't be found, AFAICT, meaning it can't validate Actions passed to it
<fwereade> bodie_, it's certainly rational to fall back to the service's charm
<fwereade> bodie_, might even be sane to just always validate against the service charm url
<fwereade> bodie_, not clear which approach will fail more often
<fwereade> bodie_, but it's also important to keep perspective, the window is fairly narrow: running actions on a service while upgrading that service
<bodie_> fwereade, seems like if a unit is in the process of being added, it would be better to validate against the service at time of enqueueing
<fwereade> bodie_, certainly it's a good fallback when no charm url has been set
<bodie_> fwereade, I think the worker will catch the case you sketched up
<bodie_> so, the action would be enqueued but fail
<fwereade> bodie_, yeah, that's fine
<bodie_> fwereade, thanks :)
<voidspace> g'night all
<voidspace> EOD
<thumper> I feel that today is one of those "start the day with two coffees" types of day
<LinstatSDR> thumper: I feel you on that. I had to start the day off with a 4 pack of Monster Energy drinks.
<wwitzel3> ericsnow: I am going to take some time to review the cloudsigma stuff and then I'll join you back on GCE stuff.
<ericsnow> wwitzel3: sounds good
<wwitzel3> ericsnow: feel free to start on any TODOs or refactors or whatever and we can just review
<wwitzel3> ericsnow: I feel much better after eating ;)
<ericsnow> wwitzel3: I landed the PortSet patch so now I'm working on merging our branch with master
<ericsnow> wwitzel3: :)
<wwitzel3> ericsnow: ahh, ok, good idea, been a while since we did that
<ericsnow> wwitzel3: I'm doing a merge instead of a rebase since I think the history is worth keeping
<wwitzel3> ericsnow: +1
<bodie_> hmm
<menn0> anastasiamac: how close are you to landing your annotations work?
<menn0> anastasiamac: I have to make some changes which will conflict with yours
<anastasiamac> menn0: hopefully in the next 4-5 hrs?
<menn0> anastasiamac: hmmm... mine might be quicker than that (and certainly a lot smaller)
<menn0> anastasiamac: let's keep each other updated I guess
<anastasiamac> menn0: k. thnx
<perrito666> wallyworld: ill walk my dog and then be back so we can call
<wallyworld> perrito666: great, thanks, was about to ping you
<perrito666> I could do now but my dog seems to be much more urged than you and is more likely to express her unhappiness with bites :p
<wallyworld> sure :-)
<wwitzel3> katco: nice review on the cloudsigma stuff, thank you
<katco> wwitzel3: oh no problem
<katco> wwitzel3: i had to stop part-way through though; that was going to take all day
<wwitzel3> katco: yep, I'm picking up where you left off :)
<katco> wwitzel3: oh, thanks :) i thought maybe they could extrapolate a little
<wwitzel3> katco: I've never successfully done a full review of this code in a single day .. week
<katco> wwitzel3: wow yipes
<wwitzel3> katco: yeah, there are some branches that are broken out, but their latest updates touched all of them
<wwitzel3> katco: so it ended up with a big single patch on reviewboard
<katco> wwitzel3: ah i see
<katco> wwitzel3: i'm happy for their contribution, just needs a bit of standards compliance
<wwitzel3> katco: ericsnow and I are going to have the same issue when we propose GCE .. figuring out how to make it not a huge monolithic review
<katco> wwitzel3: i think it's a real challenge
<katco> wwitzel3: i always like to have everything working before i submit anything
<wwitzel3> katco: you want to give enough context to the review .. but then how much is too much
<katco> wwitzel3: right
<wwitzel3> katco: we've tried to learn from some of the abstraction leaks of other providers so that we cen propose it in useful pieces, but it is still hard.
<katco> wwitzel3: i would be really interested if someone wanted to do a hangout or writeup where they demonstrate a methodology for pipelining changes; i.e.: finish everything up, and then break it up after the fact
<wwitzel3> katco: yeah, that would be useful. Maybe eric and I can do something like that if we manage to do it successfully :)
<katco> wwitzel3: i have faith! :)
<wwitzel3> ericsnow: took your idea and sent a mail to dev, linked our branch too .. figure that way if though it isn't up for review yet, people can start poking around.
<wwitzel3> ericsnow: also you want help with the merge? how is that going?
<ericsnow> wwitzel3: it was surprisingly easy
<wwitzel3> ericsnow: well thats good :)
<wwitzel3> ericsnow: I like that rename of gce -> raw
<ericsnow> wwitzel3: :)
<ericsnow> wwitzel3: I'm trying out moving gce.go into it's own package ("gceapi")
<ericsnow> wwitzel3: so far it makes for a clearer picture
<wwitzel3> ericsnow: slightly confusing, but yeah, worth try
<wwitzel3> ericsnow: since, google-api-go-client is the gceapi
<wwitzel3> ericsnow: our's is the juju-gce-api ..
<ericsnow> wwitzel3: I'm almost done; we can look it over when you're free
<wwitzel3> ericsnow: sounds good
<wwitzel3> ericsnow: now is good :)
<ericsnow> wwitzel3: brt
<menn0> anastasiamac: it turns out those annotation changes I was going to make probably aren't necessary
<menn0> anastasiamac: no need to worry about conflicts
<perrito666> wallyworld: sorry for the delay, I am back
<wallyworld> perrito666: np, i have ameeting in15 mins, let's have a quick chat, i'll set up a hangout
<katco> davecheney: ping
<wallyworld> perrito666: https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<anastasiamac> menn0: that's gr8 news! thnx ;-)
<davecheney> katco: ack
<cmars> wwitzel3, ericsnow kudos on the gce provider. i've got some gce credits to burn, looking forward to trying it out!
<ericsnow> cmars: yeah, we're pretty excited with it :)
#juju-dev 2015-01-08
<wwitzel3> cmars: thanks, it has been fun, hopefully the finishing touches won't take too long
<katco> davecheney: hey sorry, wifey and kiddo are home
<katco> davecheney: but rq, i was wondering if you had time to look at my PR again, i was wondering why the name feature_tests was dangerous?
<davecheney> katco: _test as a package name is reserved for external tests
<davecheney> the tool will probably let you get away with it
<davecheney> but it'll bite us (just like testing in package main did)
<katco> davecheney: these are external tests though, correct?
<davecheney> also, package names should be alphas only
<davecheney> pacakge foo_test is synthesised by the test runner
<davecheney> so it's a good idea to stay away from that special cased behaviour
<katco> davecheney: feature_testS is as well?
<davecheney> katco: please don't use underscores in package names
<katco> davecheney: do you have a suggestion?
<davecheney> the name of the package should describe what it does, not its contents
<davecheney> as a stop gap
<davecheney> package featuretests
<katco> davecheney: so, something that describes the fact that it runs functional/feature tests
<katco> davecheney: i honestly can't think of anything better than featuretests if you don't want an underscore/hyphen
<davecheney> i don't have any comment apart from please don't use underscores, or any other punctuation in pacakge names
<davecheney> and don't call a package _test
<davecheney> 'cos the go tool will end up barfing and we'll hve to back it out
<katco> davecheney: so if i were to rename the package, you would lgtm?
<davecheney> katco: i guess so
<davecheney> does this need to live in the juju repository ?
<katco> davecheney: that depends; i think the intent was for developers to have the option of running it, but by virtue of the fact that it is intended for external tests only, it could certainly be external
<katco> davecheney: sinzui, wallyworld, and axw all gave verbal agreement on name/location
<katco> davecheney: perhaps they could weigh in further
<katco> davecheney: as a point of intellectual curiosity, i still don't understand why the go tool will at some future point reject _test packages
<wallyworld> katco: what about "featuretests". i really don't care about the _
<davecheney> katco: _test is a majic package
<davecheney> it never exists on disk
<davecheney> is is only syntehsised for external tests by the test runner
<davecheney> this magic will bite us
<davecheney> please don't anger it
<katco> davecheney: wallyworld: sorry, brushing the little one's teeth for the first time :)
<wallyworld> \o/
<katco> davecheney: interesting, look at how it laid it out on disk: > pwd
<katco> /tmp/go-build388828020/github.com/juju/juju/feature_tests/_test/github.com/juju/juju
<katco> feature_tests.test binary is in /tmp/go-build388828020/github.com/juju/juju/feature_tests/_test
<katco> so it looks like it generated a blank _test directory within feature_tests
<davecheney> katco: i'm not sure what you want me to say
<davecheney> i gave you my advice
<katco> davecheney: sorry, i thought you'd be interested. i'm not looking for you to say anything. thanks for the input.
<davecheney> i just know this will blow up
<davecheney> remembver we have to support Go all the way back to 1.2 shipped in a 3 year old operating system
<davecheney> the possiblilities of backporting fixes to those old distros, after two bitter years of trying, is exactly 0%
<mattyw> morning all
<mattyw> hope everyone had a good holiday
<katco> mattyw: happy new years to you sir!
<perrito666> mattyw: morning, happy new year
<anastasiamac> mattyw: morning! and a Happy 2015 :)
<mattyw> katco, perrito666 anastasiamac happy new year all
<wallyworld> katco: standup?
<katco> wallyworld: shoot brt
<perrito666> ohno dying pixel
<katco> perrito666: #nopixelleftbehind
<perrito666> katco: I discovered today that dell announced my next machine :p now I just need a way to get one of those
<katco> perrito666: sweet :)
<perrito666> none of you want to visit .ar and save me of customs hell?
<katco> axw: package name has been updated; ready for review whenever you're ready
<axw> katco: cool, looking now
<axw> katco: sorry to be a pain in the butt, but I have a question before I can LGTM
<katco> axw: not at all, what's up?
<axw> katco: published
<katco> axw: k looking
<katco> bleh i fail at review board
<axw> katco: so my concern is there's nothing stopping unit X from requesting leadership for unit Y, but from your response that's what William wants? what are the access controls *meant* to be? I don't think there's any precedent for a free-for-all
<katco> axw: it's an excellent point. again he brought up several examples wherein the unit getting leadership might not be the unit requesting it. i believe they were hypotheticals.
<katco> axw: i think in general, he is trying to be sensitive to bulk-first architecture, but the cross section of that and leadership is interesting to say the least
<thumper> menn0: yep, there was a problem with the creation of the environments, test and patch coming
<thumper> menn0: just running all the tests to catch bad tests
<katco> axw: and just for fun i'll throw the fact in that i could have misinterpreted :)
<axw> katco: can that particular change be reverted, and moved to a separate PR that fwereade can take a look at?
<axw> katco: I'm not comfortable with it, but I don't want to block the rest
<katco> axw: i'm due to talk with him tomorrow about leadership, why don't i just bring it up there and see what he has to say
<axw> katco: okey dokey
<axw> thanks
<katco> axw: thanks for the review :)
<axw> nps
<katco> axw: 10 points!
<ericsnow> wwitzel3: FYI, I've updated the branch with the gceapi commit
<ericsnow> wwitzel3: I've broken some tests but wanted to get up what I had before calling it a night
<ericsnow> wwitzel3: we can change the name too
<ericsnow> wwitzel3: I may check back in later, but maybe not :)
<menn0> menn0: ok. want me to review when it's ready?
<menn0> thumper: ^^ :)
<wwitzel3> ericsnow: sounds good, thanks :)
<thumper> menn0: http://reviews.vapour.ws/r/690/
<thumper> menn0: full test run is still going
<thumper> but I expect it to finish shortly
<thumper> (running again)
<thumper> first run found one other place in the code where we were doing it wrong
<thumper> just finished, all tests pass locally
 * menn0 looks
<menn0> thumper: is that factory change supposed to be there?
<menn0> thumper: it appears like you intend the type of factory.EnvParams.Owner to change but I don't see that
<menn0> thumper: never mind
<menn0> thumper: i'm being stoopid
<menn0> thumper: ship it
<thumper> :)
<thumper> ta
<menn0> thumper: just a typo in that test name
<thumper> fixing
<thumper> menn0: and thanks
<anastasiamac> axw: about facade version numbering...
<anastasiamac> axw: should they start at 0 or 1?
<anastasiamac> axw: i have seen a few 0s when I was adding mine...
<thumper> ah fark.....
 * thumper headdesks
<anastasiamac> thumper: again?..
<axw> anastasiamac: sorry, was afk
<axw> anastasiamac: new ones should be 1
<thumper> anastasiamac: nothing to do with you
<axw> anastasiamac: 0 is for the facades that existed before we had versioning
<axw> or something like that
<anastasiamac> axw: oh! thnx - that makes sense ;)
<anastasiamac> thumper: i was not expecting it to do with me
<anastasiamac> thumper: but ur desk must be very sturdy with all this stress relief :p
<anastasiamac> axw: I'll add this explanation to api/facadeversions.go for future references :0
<axw> anastasiamac: SGTM, thanks
<axw> anastasiamac: I think jam would be able to clarify the rationale, maybe ask him to review
<anastasiamac> jam, ping :)
<anastasiamac> axw: thnx ;-)
<axw> a bit early I think
<jam> axw: anastasiamac: I'm up, but currently in leads meeting
<axw> no rest for the wicked/leads :)
<anastasiamac> axw: :) or OCRs
<anastasiamac> axw: could u plz cast ur eyes on my annotations PR when u get a chance?
<axw> anastasiamac: yup, just finishing up with another
<anastasiamac> axw: tyvm :p
<anastasiamac> m trying to update dependencies.tv with newer version of names... i get the commit hash, I get the date but what is the date suffixed with? for eg. what's T02:50:22Z?
<anastasiamac> axw: ^^?
<axw> anastasiamac: just use godeps to get the correct values
<anastasiamac> how?
<axw> anastasiamac: godeps ./... | grep names >> dependencies.tsv
<axw> then fix up by hand
<axw> that's how I do it anyway. there's probably a smarter way
<ericsnow> axw: this (from Nate) works for me: "GOOS=windows godeps -t ./... > dependencies.tsv"
<anastasiamac> axw: i know what names commit i want dependencies.tsv to contain
<anastasiamac> axw: ericsnow: i know what date to put as well, i just don't get the last charas?..
<anastasiamac> chars even
<axw> anastasiamac: not sure what date you're talking about?
<ericsnow> anastasiamac: just set your names repo to that commit and then let godeps sort it out for you
<axw> anastasiamac: ah, the date at the end of the git lines - that's from a newer version of godeps I believe
<ericsnow> axw: newer versions of godeps put a date along with some of the revisions
<anastasiamac> ericsnow: axw: I have updated names repo and need juju dependencies.tsv to have my commit in it
<ericsnow> anastasiamac: with the names repo set to the revision you want, run the command I listed and see what it writes to dependencies.tsv
<anastasiamac> ericsnow: this removed all dates
<ericsnow> anastasiamac: I'm guessing your godeps is older then
<ericsnow> anastasiamac: try "go get -u launchpad.net/godeps && go install launchpad.net/godeps" or something like that
 * anastasiamac updating godeps
<anastasiamac> ericsnow: thnx :) got it ;-0
<ericsnow> anastasiamac: :)
<jam> anastasiamac: so pong now, in case there is something you still need clarity on
<anastasiamac> jam: just to confirm - axw's understnading of facade versioning:
<anastasiamac> jam: initial numbering - 1 for new facades, 0 for facades that existed before versioning
<anastasiamac> jam: ?
<thumper> night all
 * thumper goes to walk dogs
<axw> night
<jam> anastasiamac: the "0" version is for things that were in 1.18 (pre-versioning), yes
<anastasiamac> jam: axw: thnx for clarification. I'll add it as a comment to facadeversions on my brnach :-)
<anastasiamac> branch*
<axw> anastasiamac: did you just rename annotator.go to annotations.go, or are there other changes in that file?
<axw> oh it's not renamed at all, just extracted
<anastasiamac> axw: there r other changes... like GlobalEnitty
<axw> anastasiamac: I meant annotator.go specifically
<anastasiamac> axw: m going to remove annotator.go in the next PR
<axw> oh I see
<anastasiamac> axw: also state is now passed in
<anastasiamac> axw: current annottor is written with embedding into entities in mind
<anastasiamac> axw: my implementation ensures that the new annotations does not need to b embedded
<axw> right
<axw> so I see
<axw> sgtm
<anastasiamac> axw: :)
<axw> anastasiamac: reviewed
 * axw disappears for lunch
<anastasiamac> fwereade: ping
<fwereade> anastasiamac, pong
<fwereade> anastasiamac, getting rid of that embedding sounds like a good thing to me, that always felt like a timebomb
<anastasiamac> fwereade: about bulk annotation calls, i've sent u an email. Just thought i'd give u a heads-up ;-)
<fwereade> anastasiamac, ty
<anastasiamac> fwereade: m glad u feel this way about embedding ;)
<anastasiamac> axw: r u k to drop annotation bulk call review comments until I get confirmation from intrested parties? I'd love to land what I have so far and address the rest in separate PR...
<anastasiamac> axw: pretty plz? :)
<jam> fwereade: ping for status chat
<axw> anastasiamac: not really, because 1.22 is about to go out and then this is set in stone...
<axw> anastasiamac: if you go with my suggestion then everybody should be happy because it can handle any combination in one bulk call
<TheMue> morning
<axw> morning
<dimitern> wallyworld_, still around?
<anastasiamac> axw: addressed :) when u get a chance, could u plz inspect? :P
<axw> anastasiamac: looking
<axw> anastasiamac: reviewed
<anastasiamac> axw: thnx!
<axw> nps
<voidspace> dimitern: TheMue: I'll be a couple of minutes late to standup
<voidspace> see you soon, sorry!
<dimitern> voidspace, ok, no
<dimitern> np even :)
<voidspace> dimitern: omw
<wallyworld_> dimitern: hi, was away for a bit
<wallyworld_> voidspace: i think you're ocr? if you get a chance, i'd love to be able to land http://reviews.vapour.ws/r/692/
<dimitern> wallyworld_, hey, I wanted to ask are you willing to help now and then with goamz reviews/maintenance on github, as you've contributed in the past
<wallyworld_> sure
<wallyworld_> i'm not an expert but happy to help
<dimitern> wallyworld_, ok, you have an invite already :)
<wallyworld_> ok, will look, probably tomorrow, am tired tonight
<dimitern> wallyworld_, no worries, we'll get community members to help as well
<dimitern> wallyworld_, sure, have a good one :)
<wallyworld_> will do
<voidspace> wallyworld_: nope, ericsnow and axw
<voidspace> wallyworld_: I can look in a bit if they don't get to it
<wallyworld_> voidspace: ah, oh, sorry, i'm a day out. i can wait till tomorrow
<voidspace> wallyworld_: looking at it now
<wallyworld_> i owe you one, thanks
<frankban> katco, wallyworld_ : thank you both for the reviews! I replied to some of your comments and I have some questions, (however I am not sure I understand how review board works with comments). could you please take another look when you have time?
<wallyworld_> frankban: will do
<frankban> ty
<voidspace> wallyworld_: so imagemanager and the Client, with DeleteImage method, is pre-existing
<voidspace> wallyworld_: this is just the command to expose it
<wallyworld_> voidspace: yeah, all the api and apiserver stuff landed in a previous branch. this is just to add a juju command it use it
<wallyworld_> yep
<voidspace> wallyworld_: LGTM
<wallyworld_> voidspace: you rock, tyvm
<voidspace> wallyworld_: a disturbing amount of boilerplate required just for TestDeleteImage though
<voidspace> wallyworld_: the mocking, the patching, the fakes
<voidspace> wallyworld_: not that I see a better way
<wallyworld_> yeah. i find i complain about biolerplate in general with go
<wallyworld_> lack of generics etc makes it unavoidable
<voidspace> wallyworld_: and as a result of it, you don't actually test that the delete command calls the DeleteImage client method
<voidspace> right
<voidspace> you check the api method is called - but that is mocked out, so it's not tested
<wallyworld_> true, i think you are right, i'm more or less following established patterns
<voidspace> yeah, effectively we test the layers but don't test through all the boundaries
<wallyworld_> we are introducing a featuretests package for integration tests
<voidspace> cool
<voidspace> anyway, I added my ShipIt
<wallyworld_> the first cab off the rank is katherine's leadership service tests
<wallyworld_> so with featuretests, we can add a tests to check the end-end wiring
<voidspace> great
<wallyworld_> so we have a mix of fast *unit* tests and fewer slower intergration tests
<wallyworld_> work in progress
<wallyworld_> thanks for lgtm, i can now land this to meet the 1.22 deadline
<rick_h_> jam: still around?
 * perrito666 reads a little wtf in a review answer and gets a small brain freeze like sensation
<jam> rick_h_: hey
<rick_h_> jam: howdy, got a few min I can steal sorry for the post-hours?
<jam> rick_h_: calling you now https://plus.google.com/hangouts/_/guyjqtpuoh55ecfsilhje5smdia
<ericsnow> wwitzel3: ping
<wwitzel3> oh right
<wwitzel3> ericsnow: no one is here ..
<katco> fwereade: ping
<ericsnow> jw4: ping
<ericsnow> fwereade: you still around?
<frankban> wallyworld_: I updated my branch to reuse the code in envcmd for the default environment. I'll wait for Tim about naming issues
<gsamfira_> hello folks
<gsamfira_> I was doing a deploy of juju 1.21  beta5 on MaaS and noticed that the --constraints argument is ignored
<gsamfira_> looking at: https://github.com/juju/juju/blob/1.21/provider/maas/environ.go#L781 , it seams that the Constraints field is missing
<gsamfira_> is this by design?
<perrito666> ericsnow: wwitzel3 ?
<perrito666> weekly random time meeting?
<wwitzel3> perrito666: omw
<voidspace> rebooting and then coming (weird unity freeze thing I need to get rid of to use the browser)
<dimitern> TheMue, are you around for the team meeting?
<perrito666> cmars: ?
<voidspace> dimitern: as you're still around...
<voidspace> dimitern: https://code.launchpad.net/~mfoord/gomaasapi/nodegroupsinterfaces/+merge/245891
<dimitern> voidspace, sure, will have a look
<voidspace> g'night all
<wwitzel3> nn voidspace
<dimitern> voidspace, i'm reviewing your MP and will send a review
<voidspace> wwitzel3: o/
<voidspace> dimitern: cool, thanks
<dimitern> voidspace, have a good one ;)
<alexisb> o yeah, there is totally uber in tokyo:
<alexisb> http://www.bloomberg.com/news/2014-08-05/uber-expands-tokyo-service-to-include-taxi-booking.html
<katco> i forgot to mention for anyone who was interested in the spec: it also generates the interfaces for all of the code to ensure parity
<katco> so what you see in the spec is directly in the codebase
<alexisb> katco, have you and jam talked about your spec format before?
<alexisb> if not we should make that happen
<katco> alexisb: i have not
<katco> alexisb: i have something regarding leadership to discuss with him as well. it's low-priority, but we could definitely fill a meeting with the 2 topics
<alexisb> katco, you should get on his calendar
<katco> alexisb: will do, i'll send him an email
<alexisb> I would offer to set if up but with your earlier timezone you have a better chance of getting on the calendar solo
<katco> what tz is he?
<katco> why am i asking, it's right here lol
<katco> so 10h difference
<dimitern> alexisb, yeah, uber started in sofia recently as well
<alexisb> dimitern, cool
<alexisb> katco, keep in mind he has his son in the afternoon after school
<katco> alexisb: ok ty for the info
<dimitern> katco, i can't wait for that blog post :)
<katco> dimitern: i'm about halfway done, i will let you know :)
<dimitern> katco, my org mode skills so far include only storing my emacs conf in org babel source blocks and some todo lists :)
<dimitern> awesome
<katco> dimitern: this is even easier; it's basically a plain-text outline that you just export
<katco> dimitern: if you can write markdown, you can do this just as easily
<dimitern> katco, cool! i suppose it goes via latex to generate the pdf
<katco> dimitern: yes, exactly
<katco> dimitern: i also got it to export and odf, but it's not nearly as nice
<katco> dimitern: but i suppose the important thing is that you don't need to know latex or anything to produce one, just how to write an outline in org mode
<dimitern> katco, that's way better!
<katco> dimitern: yeah, essentially these things just fall out of the notes i take when i'm gathering requirements. it's so easy
<perrito666> dimitern: I wonder, do you know the answer to gsamfira_ question??
<katco> well, for me. but i don't think it should be hard for the uninitiated either
 * katco goes to grab lunch
<dimitern> katco, +1
<dimitern> perrito666, hmmm - what's that?
<perrito666> <gsamfira_> hello folks
<perrito666> <gsamfira_> I was doing a deploy of juju 1.21  beta5 on MaaS and noticed that the --constraints argument is ignored
<perrito666> <gsamfira_> looking at: https://github.com/juju/juju/blob/1.21/provider/maas/environ.go#L781 , it seams that the Constraints field is missing
<perrito666> <gsamfira_> is this by design?
<dimitern> perrito666, gsamfira_ it is by design because constraints are processed earlier
<gsamfira_> dimitern: then something happens, because acquireNode never sends tags to maas
<gsamfira_> so you get a random node
<dimitern> gsamfira_, ah, wait .. that's total bs
<gsamfira_> if you have a maas install handy, give it a shot
<dimitern> gsamfira_, it seems they need to be there as an arg
<dimitern> gsamfira_, that has changed recently, I guess with the AZ distribution logic
<dimitern> gsamfira_, *please* file a bug about it
<gsamfira_> sure thing
<dimitern> gsamfira_, thanks! I'll have a look in the morning
<gsamfira_> sure. The fix is easy. Just add Constraints field :). Not sure if its correct, but it works :)
<gsamfira_> dimitern: https://bugs.launchpad.net/juju-core/+bug/1408762
<mup> Bug #1408762: --constraints option is ignored on MaaS provider <juju-core:New> <https://launchpad.net/bugs/1408762>
<dimitern> gsamfira_, cheers!
<perrito666> sometimes I feel we use the word status a bit too much
<wwitzel3> need a status update on the status of health status
<alexisb> :)
<perrito666> wwitzel3: I am dealing with the status of the entity, which is analog to going to a toolshop asking the thing to put the thiguie in there
<bac> hi marcoceppi, recently you fixed the install hook on squid-reverseproxy for precise.  could you make that fix for the trusty version too
#juju-dev 2015-01-09
<anastasiamac> ericsnow: thnx for shipit :)
<ericsnow> anastasiamac: I figured it would avoid any confusion :)
<ericsnow> anastasiamac: did you get your dependencies.tsv stuff sorted out?
<anastasiamac> ericsnow: it's gr8ly appreciated! i was worried how it horrible it'll look to merge without shiptit! but m loving the echo ;)
<ericsnow> anastasiamac: :)
<anastasiamac> ericsnow: yes! ur advice was brilliant
<ericsnow> anastasiamac: good; I was just echoing what others had shown me :)
<anastasiamac> ericsnow: :)
<davecheney> thumper ping
<jw4> axw: good point about _ubuntu* :  I advocated for changing the name from _nonlinux, but your point about conflating usage and what is actually compiled is good.
<jw4> axw: would you keep the name _nonlinux?
<axw> jw4: *shrug* I don't see a reason to change it. why did you want to change it away from that?
<jw4> axw: to me that was confusing because it looked like _linux, _darwin, _windows etc. and made me question whether the _non... was a valid build constraint
<axw> I see
<jw4> axw: I'm fine with leaving the name, but I would love to see a less ambiguous name
<axw> I think that if someone uses that incorrectly it'll become obvious pretty quick, since having multiple build tags almost always involves having a common entry point
<axw> which would cause an error if the tags actually resolve
<jw4> kk, that's reasonable to me
<ericsnow> axw, jw4: thanks for taking a look
<axw> nps
<ericsnow> axw, jw4: that change doesn't pay enough so I've dropped it :)
<jw4> ericsnow: cool - thanks for considering it :)
<ericsnow> jw4: the comment in there should suffice
<jw4> yep
<axw> wallyworld: I've lost my webcam, trying to fix it now...
<wallyworld> np
<davecheney> the HUD woke up to tell me I had 10% battery life, then to prove it's point went to 100% cpu and drained my battery
<mattyw> wallyworld, quick question about juju/names?
<wallyworld> sure
<wallyworld> mattyw: ?
<mattyw> wallyworld, I reckon UnitService (https://github.com/juju/names/blob/master/unit.go#L54) should return an error rather than panic
<mattyw> wallyworld, it appears there are number of places in core that don't check IsValidUnit before making this call
<mattyw> wallyworld, I was going to make the change so that UnitService returned (string, error) but thought I'd check with someone first
<wallyworld> mattyw: sorry, my connection is a bit flaky. what was your question?
<mattyw> wallyworld, does that sound like a reasonable change - UnitService not panicing - but returning an error if the unit name is invalid
<wallyworld> mattyw: i'd be reluctant to change just that one method when all others panic if the name is invalid. i think the expecation is that names are validated before calling into the package
<wallyworld> axw_: got time for a hangout?
<axw_> wallyworld: sure, I need to duck down in 10m to get something out of the oven tho
<axw_> wallyworld: see you in 1:1
<wallyworld> ok, let's make it quick
<axw_> wallyworld: need to write a bunch of tests, but I should be able to propose a branch soon that connects "juju machine add --disks" to the machine provisioner
<axw_> I just got ec2 to provision a machine with extra volumes once again
<wallyworld> axw: that is \o/
<anastasiamac> wallyworld: thnx for shipit!
<wallyworld> np :-)
<anastasiamac> wallyworld: it's my fastest yet :)
<wallyworld> indeed
<dimitern> niemeyer, hey, if you have some time I'd appreciate a review on https://github.com/go-amz/amz/pull/12 please
<anastasiamac> voidspace: ping
<voidspace> anastasiamac: poing
<voidspace> *pong even
<perrito666> morning everyone
<voidspace> perrito666: morning
<anastasiamac> perrito666: morning :)
<voidspace> ah, I'm OCR today
<voidspace> forgot
<anastasiamac> voidspace: r u ocr?
<voidspace> *damn* :-)
<voidspace> anastasiamac: I believe so...
<anastasiamac> voidspace: thnx ;)
<anastasiamac> voidspace: could u plz have a look at http://reviews.vapour.ws/r/701/
<anastasiamac> voidspace: it's tiny and i'd love to land it in 1.22
<anastasiamac> voidspace: well, for 1.22
<voidspace> anastasiamac: looking now
<anastasiamac> voidspace: greatly appreciated!!
<voidspace> anastasiamac: looks like a nice straightforward improvement
<voidspace> anastasiamac: LGTM
<perrito666> when creating a new facade version for uniter, should the new one embed the previous one?
<anastasiamac> voidspace: thnx :)
<voidspace> dimitern: I guess landing an mp for gomaasapi is a manual merge
<dimitern> voidspace, it is I think
<voidspace> done
<dimitern> voidspace, \o/
<voidspace> dimitern: as far as I can tell it's not possible to go from node -> nodegroup via the maas api
<voidspace> dimitern: I'm just double checking the details api to see if it's in that
<voidspace> node id -> nodegroup uuid
<voidspace> and details is xml, yummy
<voidspace> and doesn't include nodegroup
<dimitern> voidspace, right, that sounds like another bug worth reporting :)
<voidspace> yeah
<voidspace> I think they're getting sick of me...
<dimitern> :D
<dimitern> it's unavoidable though..
<anastasiamac> voidspace: 've changed the code after ur lgtm
<anastasiamac> voidspace: could u plz cast ur eyes over it again?
<anastasiamac> voidspace: changed the facade and its test to reflect the fact the each entity in the list could have its annotations...
<anastasiamac> voidspace: should be a tivial modiifcation too
<anastasiamac> voidspace: modification even :)
<niemeyer> dimitern: Review is up
<dimitern> niemeyer, thanks! I'm making the suggested changes now
<niemeyer> dimitern: np!
<dimitern> niemeyer, how do you feel about renaming v2-dev to v2?
<dimitern> so we can start using it in juju
<anastasiamac> sinzui: o/
<sinzui> hi anastasiamac
<anastasiamac> sinzui: m trying to land something for 1.22 but keep getting "No space left on device"
<anastasiamac> sinzui: what shall i do?
<sinzui> I will invesitigate
<anastasiamac> sinzui: thnx :)
<anastasiamac> sinzui: also it's past midnite here but I really want it to land... when r u plannning to take 1.22? (in how many hrs?) :P
<sinzui> the juju-core-slave has 23G of space. I think the ec2 instance is low on space
<sinzui> anastasiamac, we cannot take 1.22 until 1.21.0 is created. the feature freeze is artifical
<voidspace> anastasiamac: sure
<sinzui> anastasiamac, the ec2 image had 6.5G of free space when the test started
<sinzui> anastasiamac, is this failure repeatable?
<anastasiamac> voidspace: thnx ;-)
<anastasiamac> sinzui: i've tried to merge twice and got it both times ;)
<voidspace> anastasiamac: looking at the changes
<sinzui> mgz, have you seen cases where the ec2 instance starts with 7.75G free, then the tests fail with no space left on device
<voidspace> anastasiamac: those changes look good to me
<voidspace> updated ShipIt
<anastasiamac> voidspace: tyvm :)
<TheMue> sinzui: when will the 1.22 branch be created?
<sinzui> TheMue, I may create it at my EOD or tomorrow because of CI test lag. I will select the last passing rev
<TheMue> sinzui: ok, we hope to get one more action PR into it until then, thx
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: pong
<wwitzel3> ericsnow: hi :)
<bloodearnest> #join python-uk
<bloodearnest> #/oin python-uk
<bloodearnest> whoops
<ericsnow> wwitzel3: you saw my commits (formatting and tests)?
<wwitzel3> ericsnow: I did
<bodie_> CI says "Can't take a write lock while out of disk space"
<bodie_> resolution = ?
<anastasiamac> sinzui: tried to merge 3rd time, got the same "No space left on device"
<sinzui> anastasiamac, :/
<sinzui> anastasiamac, as this is ec2 I feel pretty helpless
<anastasiamac> sinzui: it's getting l8 for me. I'll try to land it in the morning - about 4 or 5 hrs from now :)
<wwitzel3> ericsnow: yeah, looks good
<ericsnow> wwitzel3, perrito666: standup?
<ericsnow> wwitzel3: oh, good :)
<sinzui> anastasiamac, I have a clue
<anastasiamac> sinzui: k :)
<anastasiamac> sinzui: m mean I m sure u do :)
<sinzui> I think the git-merge-juju job explicitly creates a 2G tmpfs
<sinzui> CI doesn't use that feature, the only this job does
<sinzui> I will ask if I can increase the artificial constraint
<anastasiamac> sinzui: it'd b amazing!
<bodie_> sinzui, nice catch
<sinzui> anastasiamac, I am trying your PR again
<sinzui> bodie_, resubmit. anastasiamac passed after the size incread
<sinzui> increase
<ericsnow> hazmat: you have any thoughts on what a plugin provider should look like?
<ericsnow> hazmat: I have some and am writing up a spec
<ericsnow> hazmat: I recall that you had done something like this already and wanted to get your thoughts
<bodie_> thanks sinzui
<voidspace> ericsnow: providers don't have state do they, so my thinking was that we just take the existing providers and make them into an executable - with the existing api becoming commands
<voidspace> ericsnow: marshall data in and out
<ericsnow> voidspace: right
<voidspace> ericsnow: you could prototype it over the weekend... ;-)
<ericsnow> voidspace: haha
<free> hello, I'm trying to play a bit with juju actions (trunk), but can't fully figure out how to get something working, anyone available to help? basically I always get "failed" as action status, but nothing I can see in the logs
<voidspace> rogpeppe: ping
<rogpeppe> voidspace: pong
<voidspace> rogpeppe: I've updated a dependency - specifically gomaasapi
<voidspace> rogpeppe: and I want to use the new version
<voidspace> rogpeppe: dependencies.tsv for a bzr branch has revision number and some combination of email/date/hash
<voidspace> where does the weird hash thing come from, seemingly not from bzr
<voidspace> CONTRIBUTING.md suggests to run godeps -t $(go list github.com/juju/juju/...) > dependencies.tsv
<voidspace> which changes a lot of things...
<voidspace> but not the one I want
<rogpeppe> voidspace: one mo, i'm in a call
<voidspace> rogpeppe: no problem
<voidspace> rogpeppe: I think I've solved it - or at least got godeps to generate the line and I'll revert the other changes
<alexisb> ericsnow, well done, thank you very very much!
<alexisb> I will send out a summary before my eod to you and perrito666
<ericsnow> alexisb: is there a mailing-list for the team leads?
<ericsnow> alexisb: glad to do it
<ericsnow> :)
<alexisb> ericsnow, no, just my local one :)
<ericsnow> :)
<perrito666> alexisb, ericsnow tx
<alexisb> I will send you the address
<ericsnow> alexisb: k
<ericsnow> alexisb: I expect the lib will be fine (looks to be officially supported and uses the apache v2 license)
<rogpeppe> voidspace: the approach i usually use is: godeps -u dependencies.tsv
<rogpeppe> voidspace: then update the dependency you want
<rogpeppe> voidspace: then godeps -t ./... > dependencies.tsv
<rogpeppe> voidspace: except that currently doesn't work (annoyingly) in juju because of platform-specific deps
<ericsnow> GOOS=windows godeps -t ./... > dependencies.tsv
<ericsnow> and make sure your godeps is up to date :)
<rogpeppe> ericsnow: does that get linux-only deps?
<rogpeppe> ericsnow: (perhaps there aren't any...)
<ericsnow> rogpeppe: I don't know
<ericsnow> rogpeppe: I believe we only have windows-only deps
<rogpeppe> i really need to sort out that godeps issue, but i haven't any allocated time for it...
<ericsnow> nate would know better
<voidspace> rogpeppe: right, thanks
<rogpeppe> voidspace: i quite often do the cut&paste thing too, just to update a single line of dependency
<ericsnow> rogpeppe: with newer godeps does that work right (due to the timestamp)?
<rogpeppe> ericsnow: it should be fine
<ericsnow> rogpeppe: good to know
<rogpeppe> ericsnow: the time stamp is a deterministic function of the dependency
<free> does somebody know how action parameters are supposed to be accessed by the executable performing the action? some via juju env command?
<ericsnow> wwitzel3: ready?
<wwitzel3> ericsnow: yep
<ericsnow> wwitzel3: I'm in moonstone
<cherylj> katco: ping
<katco> cherylj: howdy!
<cherylj> katco: do you have a few minutes?
<katco> cherylj: sure, let me just grab a drink rq
<voidspace> dimitern: hah, we had a maas provider test depending on the bug in the TestServer that I fixed
<voidspace> dimitern: testing the fallback when it can't query architectures
<dimitern> voidspace, really? :)
<voidspace> dimitern: it relied on getNodegroups erroring rather than returning an empty list
<dimitern> voidspace, good catch!
<voidspace> dimitern: so I've changed the production code to treat an empty list of boot images to be the same as an error
<voidspace> and use the fallback for supported architectures
<voidspace> dimitern: I don't think it matters in practise
<dimitern> voidspace, I'd have a look when you propose it
<voidspace> dimitern: sure
<voidspace> dimitern: it's easy to see what I mean
<voidspace> dimitern: nearly ready for proposal
<katco> cherylj: ok sorry, what's up?
<dimitern> voidspace, cheers
<cherylj> katco, I had some questions for you.  Want to do a hangout?
<katco> cherylj: sure
<katco> hey can someone add cherylj to the juju team on github?
<katco> alexisb: ^
<alexisb> katco, let me see if I have admin to do that one sec
<katco> alexisb: i think you are in the owners group, so i think you can :)
<alexisb> cherylj, what is you gitbub user name?
<cherylj> cherylj
<katco> alexisb: cherylj
<alexisb> cherylj, katco sent an invite let me know if that is what you need
<cherylj> alexisb, got it!  Seems to have worked
<alexisb> coolness :)
<alexisb> thanks for forcing me to learn something new
<alexisb> :)
<cherylj> thanks again, katco for helping me make my first (trivial) change!
<katco> cherylj: congrats :D
<katco> cherylj: you're now an official juju hacker :)
<cherylj> yay! :D
<katco> cherylj: oh i forgot to mention: the review board ticket will now be closed as well. ericsnow's integration does that for us as well.
<katco> cherylj: you can always get back to it by looking at your "Outgoing > All" header there
<ericsnow> cherylj: \o/
<cherylj> katco: cool, thanks!
<katco> cherylj: well, it won't be closed until the juju bot closes your PR
<katco> ok, time for nom nom nom... bbiab
<voidspace> right
<voidspace> happy weekend everyone
<voidspace> EOW
<lazyPower> What kicks off the mongodb process for the local provider? is this an upstart job that i'm failing to find or is this controlled by the juju bootstrap sequence?
<katco> sinzui: hey this looks very strange to me: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1767/consoleFull
<katco> sinzui: is something the matter with the environment maybe?
<katco> lazyPower: i think it's the bootstrap process? i don't think it's configured as a service
<lazyPower> katco: 10-4, we're running down the issues with kicking off a juju env in a docker container - and this is where we're stuck
<lazyPower> mongod isn't starting - so now we're looking for the mongo logs to figure out why thats the case - the $JUJU_HOME/local isn't being created
<lazyPower> thanks for the feedback tho - *hattip*
<mgz> katco: that one looks like the normal mongo falling over with bad record MAC then everything else being seriously ill afterwards
<katco> lazyPower: ah i think i ran into this like 7mo ago, and docker containers didn't have the infrastructure to start... services. so mayb it is a service?
<katco> mgz: so flakey test? i hadn't seen this one yet (i don't think...)
<mgz> lazyPower: running local env inside docker seems... perverse
<mgz> katco: yeah, tell her to retry it
<katco> lazyPower: i just remember it having to do with how docker containers interacted with linux's init system (upstart or possibly something in /dev)
<lazyPower> mgz: but it has its merits in terms of handing someone a docker container to get them looking at juju.
<katco> mgz: will do, thank you (and happy new year btw!)
<mgz> :)
<lazyPower> mgz: when we get this figured out, we'd love your feedback on the project
<lazyPower> +1 or -1 alike - we're in this for the community
<mgz> lazyPower: and ideally our local setup would be less of a special unicorn and not have a magic machine 0, but that's where we're at currently
<lazyPower> mgz: i knowwwwww
<lazyPower> mgz: we want a container for bootstrap so bad here in ecosystems, but well be patient
<lazyPower> *we'll
<lazyPower> we know there are bigger fish to fry
<katco> lazyPower: fwiw i think core wants that pretty badly too
<katco> but as you said it's not high on the list
<lazyPower> yeah, I try not to fishbowl too much
<lazyPower> but i'm guilty of it
<whit> katco, lazyPower : $JUJU_HOME/local is created. it just gets cleaned up when the bootstrap process fails
<lazyPower> ahhh
<lazyPower> good 2 know, is there a way to freeze it from getting reaped?
<lazyPower> s/reaped/cleaned up/
<whit> what we need is a list of dependencies that jujud, mongod and friends expect for local bootstrap
<whit> lazyPower, --keep-broken
<lazyPower> niiiiice
<katco> cherylj: resubmit again
<cherylj> katco:  okay :)
 * perrito666 changes locations to get freshness
<perrito666> ok, apparently 37ÂºC is not something that can be dodged by going to the 0th floor
<cherylj> katco:  Success!  Huzzah!
<katco> cherylj: lol yaaay
<cherylj> 3rd time's a charm
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1409141
<sinzui> anastasiamac, I believe a test introduced in one of your revisions is bad, not your code, but your test. I reported bug 1409141 about ppc test failure
<mup> Bug #1409141: TestSetEntitiesAnnotation fails on ppc64el <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1409141>
<anastasiamac> sinzui: m looking. thnx!
<anastasiamac> sinzui: :(
<anastasiamac> sinzui: btw, thnx for landing my branch!
<sinzui> anastasiamac, I just sent an email about the bug to the list. Since CI  has a queue to test, I am going to wait until tomorrow to forking 1.22.
<anastasiamac> sinzui: sorry :(
<sinzui> anastasiamac, I hope this gives you time to adjust the test
<perrito666> anastasiamac: \o/ congratulations your first CI breakage, it took too long
<sinzui> anastasiamac, you didn't create the queue@
<anastasiamac> sinzui: i'll look at it a bit later than - kids r going nuts :( must be saturday
<perrito666> anastasiamac: is it already saturday for you?
<anastasiamac> perrito666: :( yes
<perrito666> anastasiamac: wow
<anastasiamac> perrito666: i grow older faster here
<perrito666> anastasiamac: lol
<anastasiamac> sinzui: i believe the problem is ordering - I say that I expect thing in one collection but the ordeer returned is reversed.
<anastasiamac> sinzui: i don't care about the order so will try to fix now ;)
<anastasiamac> sinzui: proposed fix is on reviewboard http://reviews.vapour.ws/r/706/
 * katco looking
<anastasiamac> katco: thnx :)
<katco> anastasiamac: a few comments as i was trying to understand the code, and 1 spelling correction
<katco> anastasiamac: other than that, i'll lgtm
<anastasiamac> katco: about setting collection inline in other collections instead of declaring them as separate variables first
<anastasiamac> katco: i find it hard to read and maintain if struct changes
<katco> anastasiamac: it's just a map within a map right?
<anastasiamac> katco: which was the case for me until the format of SetAnnotations was decide
<anastasiamac> katco: yes it is now but went thru couple of changes
<katco> anastasiamac: ah ok
<katco> anastasiamac: well, whatever works for you :) it's certainly fine as is
<katco> anastasiamac: the function declaration is actually confusing for me, because there's no change in indentation from the declaration and its body
<katco> anastasiamac: nor whitespace
<anastasiamac> katco: I'll add whitespace
<anastasiamac> katco: had to params on separate linesotherwise signature is too long
<katco> anastasiamac: consider breaking after last param. indentation looks like a struct and is more readable
<anastasiamac> katco: thnx ;) that's what I meant
<katco> anastasiamac: also, i have not seen anyone leave the first line of the func declaration blank like that "func(\n\n..."
<anastasiamac> katco: oh k - i would have thought it's logical to move each param on its own line :P
<anastasiamac> katco: i'll move one to func(
<katco> anastasiamac: ty!
<anastasiamac> katco: thnx for looking! updated review :)
<anastasiamac> katco: can u lgtm?
<katco> anastasiamac: did you forget the newline before ) error {, or was that intentional?
<katco> L37
<anastasiamac> katco: actually, my IDE tells me that it's not right to have return on a separate line. so intentional
<katco> anastasiamac: you just need an additional comma after the last param
<wwitzel3> ericsnow: almost back :)
<ericsnow> wwitzel3: k
<anastasiamac> katco: i c. in that case, why would I want a newline after declaration? The indentation looks k now ;) let me commit for ur perusal
<anastasiamac> katco: committed
<katco> anastasiamac: yeah with the indentation for the return type, no need for newline after declaration
<ericsnow> wwitzel3: I'm in moonstone when you're ready
<katco> anastasiamac: that looks much better... did that run through gofmt? the indentation looks strange in the declaration as well
<katco> anastasiamac: like the parameters are further in than the 1st param on my screen
<anastasiamac> katco: i believe it did. i have to go in a few min. can i get a lgtm?
<katco> anastasiamac: yup, thanks for humoring me
<anastasiamac> katco: anytime :)
<katco> anastasiamac: fwiw, play.golang.org also keeps that indentation style. that seems weird to me...
<anastasiamac> katco: m relying on my IDE to guide me as far as formatting (since it's all hooked in)
<perrito666> you know, if we change lgtms for amen we could get funny sentences more often
<katco> haha
<katco> perrito666: check out https://github.com/anastasiamac/juju/blob/set-annotations-Bug1409141/api/annotations/client_test.go
<anastasiamac> katco: m not  usually too fussed about formatting (coming from Java and all) but by all means pull me up on it when needed
<katco> doesn't L34-37 looks weird indentation wise?
<katco> anastasiamac: i usually try to ignore formatting in reviews, but that one just got me. every time i tried to scan for the function i lost track of where it was
<perrito666> it does yet I know why that happened
<katco> perrito666: please enlighten me, amen.
<perrito666> go fmt sucks at fixing multiline function declarations
<katco> haha
<perrito666> it will do the right thing with the bracket
<anastasiamac> perrito666: :)
<perrito666> which will screw the rest
<katco> well that is rather frustrating
<perrito666> or the parens I cant recall
<perrito666> its like one of the rules breaks the rest
<perrito666> I usually make declarations one line
<perrito666> to avoid these things
<wwitzel3> ericsnow: sorry for the delay, it was late enough I ended up having to make dinner instead of just lunch for myself :/
<ericsnow> wwitzel3: no worries :)
<katco> perrito666: anastasiamac: http://play.golang.org/p/jKrQB2HQbg
<katco> looks a little better
<katco> if you drop the func onto a line by itself, that's when the formatting goes wacky: http://play.golang.org/p/INbYmRMf3-
<anastasiamac> katco: yes when each param is on its own line
<katco> anastasiamac: the difference being the "func(" isn't on it's own line
<perrito666> actually its when there is ( and ) in different lines
<perrito666> indentation of ) will make all look weird
<anastasiamac> perrito666: katco: thnx for ur help! something new every day :P
<katco> anastasiamac: thank you for taking the time on your sat. to fix that!
<anastasiamac> katco: i broke it :)
<anastasiamac> katco: besides it ain't fixed until it's merged
<katco> anastasiamac: isn't that the hard truth :p
<perrito666> anastasiamac: don't punish yourself, breaking the build happens, a lot, to everyone
<anastasiamac> katco: thnx for being my ocr on this ;)
<katco> anastasiamac: i am biased towards tanzanite members ;)
<anastasiamac> perrito666: m not punishing myself :) just taking ownership :)
<anastasiamac> katco: i knowthe feeling!
 * perrito666 notices the matrix 2 is playing in the background... man those are cheap cgis
<perrito666> I wonder how much time has the TV been on
<anastasiamac> merge failed: "upgrade in progress - Juju functionality is limited"
 * anastasiamac will re-try
<perrito666> anastasiamac: yup, that is a race
<anastasiamac> perrito666: who is winning?
<anastasiamac> perrito666: did i create t or shall I just re-try?
<perrito666> anastasiamac: nop, always been there
<perrito666> just retry
<anastasiamac> perrito666: thnx :0 will do
<anastasiamac> fix merged. hopefully this will unblock trunk eventually :)
<perrito666> anastasiamac: we will fix it if it doesn't please go enjoy your weekend
<perrito666> btw, what time on saturday is?
<anastasiamac> perrito666: now almost 10am :)
<anastasiamac> perrito666: what time is it for u?
<perrito666> did you pull an allnighter?
<perrito666> 20:53 on friday
<anastasiamac> perrito666: no ;-) my son is helping with Asian Cup (soccer) and ws too existed to sleep so we've been up since 5am
<anastasiamac> perrito666: and m more of an owl than an early bird - i work beta in the evening so I usually stay up til at leats 1am :)
<anastasiamac> perrito666: at least*
<anastasiamac> however, now that my fix is committed, I'll eow
<perrito666> well, enjoy
<anastasiamac> perrito666: thnx ;) u2
#juju-dev 2015-01-11
<waigani> menn0: hangout?
<menn0> waigani: yep :) standup?
<waigani> menn0: yep, still in there
<waigani> menn0: lost you
<menn0> is anyone from QA around?
<menn0> it looks like bug 1409141 is fixed but needs to be updated to unblock merges
<mup> Bug #1409141: TestSetEntitiesAnnotation fails on ppc64el <ci> <regression> <test-failure> <juju-core:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1409141>
<menn0> thumper: review for http://reviews.vapour.ws/r/697/ pls
<hazmat> ericsnow, smoser had some thoughts, but nutshell is interface to the plugin (rpc form or shell exec) and packaging the plugin for distribution to servers
 * thumper is back and looking at reviews
<menn0> thumper: http://reviews.vapour.ws/r/697/ updated
#juju-dev 2016-01-11
<mwhudson> menn0, waigani_ (or anyone else): if i've bootstrapped and env and then hacked some stuff, how do i "upgrade" the env to the new jujud?
<mwhudson> or is it easier to just destroy and bootstrap again?
<davecheney> mwhudson: there is juju upgrade-juju --devel
<davecheney> honestly I jsut guessed thatb
<davecheney> but there is a flag that builds new tools locally with a minor version one more than what's been deployed
<mwhudson> seems the flag is --upload-tools
<waigani_> mwhudson: yep --upload-tools is what you want
<menn0> mwhudson: remember to "go install" first :)
<mwhudson> heh yes
<mwhudson> heh so http://paste.ubuntu.com/14466151/ is too simplistic
<menn0> mwhudson: what happens?
<mwhudson>     agent-state-info: 'failed to retrieve the template to clone: lxc container creation
<mwhudson>       failed: juju-xenial-lxc-template'
<davecheney> maybe there is no lxc template for xenial yet
<mwhudson> there isn't, i guess i need to make one
<mwhudson> oh
<mwhudson> no, i think it's probably more that i hacked too hard
 * mwhudson afk for now
<mup> Bug #1532670 opened: Suggest next major version upgrade <2.0> <upgrade-juju> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1532670>
<mup> Bug #1532670 changed: Suggest next major version upgrade <2.0> <upgrade-juju> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1532670>
<mup> Bug #1532670 opened: Suggest next major version upgrade <2.0> <upgrade-juju> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1532670>
<cherylj> If anyone's around, could I get a review?  http://reviews.vapour.ws/r/3490/
<anastasiamac> cherylj: i'll look...
<cherylj> thanks, anastasiamac !
<cherylj> and now, off to bed.  so tired...
<dooferlad> voidspace, frobware: standup?
<voidspace> dooferlad: omw
<voidspace> dooferlad: frobware is ill though
<mgz> master is blocked at present, new unit test fails.
<mup> Bug #1532777 opened: undertakerSuite.TestEnvironConfig fails <blocker> <ci> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1532777>
<frobware> dooferlad, that gomaasapi bug we/I looked at late on Friday was because the test didn't enable static-ipaddresses as part of the capability set.
<frobware> dooferlad, I take that back.
<dooferlad> frobware: :-|
<mup> Bug #1532831 opened: upgrade in progress - Juju functionality is limited after bootstrap <bootstrap> <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1532831>
<natefinch> ericsnow: btw there's a couple blank review comments in the review I lefty... just ignore those.  I had intended to delete them, and failed somehow.
<ericsnow> natefinch: np
<mup> Bug #1532841 opened: cannot add charm to storage <charm> <ci> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532841>
<mup> Bug #1532849 opened: precise-amd64 and trusty-ppc64el unittests do not complete <ci> <ppc64el> <precise> <regression> <unit-tests> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532849>
<mup> Bug #1532841 changed: cannot add charm to storage <charm> <ci> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532841>
<mup> Bug #1532849 changed: precise-amd64 and trusty-ppc64el unittests do not complete <ci> <ppc64el> <precise> <regression> <unit-tests> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532849>
<katco> natefinch: let's touch base after lunch on how the demo's looking
<mup> Bug #1532841 opened: cannot add charm to storage <charm> <ci> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532841>
<mup> Bug #1532849 opened: precise-amd64 and trusty-ppc64el unittests do not complete <ci> <ppc64el> <precise> <regression> <unit-tests> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1532849>
<natefinch> katco: roger
<cherylj> frobware: if we get a bless on your revert branch, is it all reviewed to be merged?  (https://github.com/juju/juju/tree/1.25-revert-maas-devices)
<natefinch> ericsnow, katco: reading the HTTP registry stuff kinda gives me the willies... it's a heck of a lot of code that I can't really determine if it's doing the right thing or not.  Maybe it's just my unfamiliarity with the HTTP code we have.
<natefinch> ericsnow, katco:  Gonna give it a ship it, but not sure I won't have missed some subtleties.
<katco> natefinch: i agree and left a comment to that effect
<katco> natefinch: i'd rather not ship that until we have empirically tested code that relies on it
<katco> natefinch: i was also unaware that we were taking that on for the demo; it's not represented in the card.
<katco> natefinch: ericsnow: i would have preferred to work on that later.
<natefinch> katco, ericsnow: gah, I left comments for the http registration on the upload api patch.... this is what you get for using dependent patches, eric :)
<frobware> cherylj, I have a "Ship It!" from dooferlad.
<katco> natefinch: ericsnow: yeah it would be nice to do a diff against that other PR to get just the important bits
<frobware> voidspace, want to take a quick look? http://reviews.vapour.ws/r/3474/
<ericsnow> katco: ah, I must have forgotten to rbt post :(
<frobware> dooferlad, ping
<voidspace> frobware: quick look !? that's a 1500 line diff...
<frobware> voidspace, ah, yes, well.
<voidspace> maybe tomorrow morning :-)
<natefinch> ericsnow, katco: finished my reviews of eric's code btw
<perrito666> ericsnow: ptal to http://reviews.vapour.ws/r/3392/ whenever you have a moment
<ericsnow> perrito666: k
<ericsnow> perrito666: might be a little while
<perrito666> np
<natefinch> ericsnow: bah, zero value fingerprint is not valid
<ericsnow> natefinch: yeah, ran into that earlier
<natefinch> ericsnow: I think zero value fingerprint is valid for zero bytes of data
<ericsnow> natefinch: it's because it isn't initialized; GenerateFingerprint(nil) worked as an alternative
<ericsnow> natefinch: but I agree the zero value should be okay
<natefinch> ericsnow: gah, your external tests make using the tests for debugging impossible :/
<natefinch> ericsnow: I guess not impossible... but more roundabout than I'd like
<natefinch> ericsnow: I assumed the hash for no bytes would be empty as well, but I guess it makes sense that the hash is constant length, so you have to define some hash for zero bytes.
<ericsnow> natefinch: right
<ericsnow> natefinch: however, as zero-value fingerprint should be the same a hash of an empty string
<ericsnow> natefinch: we'll fix that later
<ericsnow> natefinch: or at least discuss if that is meaningful :)
<natefinch> ericsnow: yeah, I can do the generate(nil) for the demo... but I would like to make the zero value valid.  Shouldn't be that hard
<ericsnow> natefinch: agreed
<ericsnow> katco, natefinch: I've refactored that API patch to not need the registration (for now)
<ericsnow> katco, natefinch: also, I found a small bug: http://reviews.vapour.ws/r/3495/
<katco> ericsnow: cool, ship it
<mup> Bug #1514857 changed: cannot use version.Current (type version.Number) as type version.Binary <blocker> <ci> <regression> <test-failure> <juju-core:Fix Released by natefinch> <juju-core lxd-provider:Fix Released by natefinch> <https://launchpad.net/bugs/1514857>
<natefinch> ericsnow: ship it
<natefinch> ericsnow: also, updated the demo data to use generateFingerprint(nil)
<ericsnow> natefinch: k
<katco> natefinch: confused... why even set it at all?
<natefinch> katco: because the default value is invalid and fails validate checks later one
<natefinch> on
<natefinch> katco: we were just talking about how we should fix that so the default value is valid for zero data
<katco> natefinch: yeah
<katco> ericsnow: ty for the refactor too
<ericsnow> katco: :)
<cherylj> Is there someone who can do a review for me?  http://reviews.vapour.ws/r/3490/
<katco> cherylj: lgtm. looks much more robust, kudos :)
<cherylj> katco: thanks!!
<mup> Bug #1532932 opened: Unable to bootstrap the lxd provider on vivid <adoption> <juju-core:New> <https://launchpad.net/bugs/1532932>
<katco> ericsnow: natefinch: fyi i'm collecting lxd bugs here: https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-lxd-provider
<katco> ericsnow: natefinch: the one mbruzek just opened we already knew about, but weren't tracking anywhere
<mbruzek> katco: How do I add the bug there.
<katco> mbruzek: there's a "link a bug report" link; not sure if you have to own the blueprint for it to show up
<katco> mbruzek: i linked it for you
<mbruzek> katco: OK
<mbruzek> thanks for your help
<katco> mbruzek: ty for trying it out
<mup> Bug #1532932 changed: Unable to bootstrap the lxd provider on vivid <adoption> <juju-core:New> <https://launchpad.net/bugs/1532932>
<natefinch> ericsnow: oops, wrong channel...
<natefinch> ericsnow: anyway... looks like tests aren't hooking up the resources code
<ericsnow> natefinch: you have to do registration (see state/resources_test.go)
<mup> Bug #1532932 opened: Unable to bootstrap the lxd provider on vivid <adoption> <juju-core:New> <https://launchpad.net/bugs/1532932>
<katco> natefinch: have you been able to run through the demo yet?
<natefinch> katco: sorry, no, I was waiting for my stuff to land and then I am working on fixing the tests in that one branch... once that's done I can merge eric's branch and do an end to end test.
<katco> natefinch: np. demo > tests right now though
<natefinch> katco: right, but I can't land if the tests fail
<katco> natefinch: we can create a binary from a branch that's not in github.com/juju
<natefinch> katco: right... ok, will do that right now.
<katco> natefinch: cool, hope it goes smooth the first time :)
<natefinch> katco: it would work better if ericsnow's code compiled ;)
<katco> lol
<ericsnow> lol
<natefinch> 3 silly little fixes... one left
<natefinch> ericsnow: state.State doesn't implement GetResource?
<ericsnow> natefinch: correct
<natefinch> ericsnow: fixed it...
<ericsnow> natefinch: fixed what?
<natefinch> ericsnow: newResourceHandler needed a couple tweaks to compile
<ericsnow> natefinch: yeah, I fixed those
<natefinch> ericsnow: well then, push ;)
<natefinch> ericsnow: nevermind, just re-fetched... only one problem now with cannot use *"github.com/juju/juju/resource/api/client".Client as type "github.com/juju/juju/resource/cmd".UploadClient
<ericsnow> natefinch: yeah, the client stuff is not right yet
<natefinch> reader vs. readseeker
<natefinch> ericsnow: is there anything I can do to help?
<ericsnow> natefinch: not really
<katco> ericsnow: demo > tests if that helps
<ericsnow> katco: yep
<ericsnow> natefinch: should be ready (sans *any* test coverage on the client)
<natefinch> ericsnow: cool
<frobware> cherylj, ping
<cherylj> frobware: what up
<frobware> cherylj, are we doing some additional runs with the backed-out PRs for 1.25.2?
<frobware> cherylj, I was just trying to understand where we are with this before I EOD.
<cherylj> frobware: yes, it was supposed to get re-run today.
<frobware> cherylj, any news?
<cherylj> jog, sinzui is the revert-branch currently being tested?
<natefinch> katco, ericsnow: I have a branch, resource-demo (note: singular resource, sorry)  it has all the code from everyone.  I also have the charm at github.com/natefinch/starsay
 * frobware wonders if no new is good news...
<katco> natefinch: nice
<katco> natefinch: have you tried running through the demo script yet?
<sinzui> cherylj: No, in the next hour it will be
<natefinch> katco, ericsnow: just got it building... doing so now
<katco> natefinch: woot woot
<ericsnow> natefinch: cool
<cherylj> frobware: while I have you here, did you get the chance to figure out what the AWS Robustness for Spaces was referring to?
<cherylj> :)
<natefinch> katco, ericsnow: doh.  ERROR failed to upload resource "store-resource": PUT https://localhost:17070/environment/2a00757a-9329-401d-8ee5-4140647864c1/environment/2a00757a-9329-401d-8ee5-4140647864c1/services/starsay/resources/store-resource: request body supplied unexpectedly
<jog> cherylj, machine-dep-engine is still running
<ericsnow> natefinch: so awesome!
<natefinch> katco, ericsnow: that's after deploy, running juju upload
<ericsnow> natefinch: fixing now
<natefinch> ericsnow: notably, environment/UUID in there twice, too
<ericsnow> natefinch: indeed
<natefinch> katco, ericsnow: btw, I updated my demo data at deploy branch so the tests will pass: http://reviews.vapour.ws/r/3484/
<frobware> cherylj, I sent some email dimiter - but we got caught up with demo stuff. he's back on Weds and will follow-up then. apologies for the delay.
<cherylj> frobware: okay, I'll move it to alpha2 until we can get it figured out :)
<natefinch> katco, ericsnow: it injects the resource code into a registry now, which is probably more like how we'd want to do it (though I imagine we'll actually want to inject DB ops to keep it transactional)... but it means that if you don't have resources registered, we won't try to use resources.
<natefinch> ericsnow, katco: I gotta run for a few hours for dinner and bedtime for the kids, but will be back after.
<katco> natefinch: kk ty
<katco> ericsnow: can you pick up where he left off>
<katco> ?
<natefinch> oh and to potentially save you a few minutes figuring it out, use 'juju deploy ~/src/github.com/natefinch/starsay --series trusty'  to deploy starsay locally (so you don't have to put it in a charm repo or special folder)
<natefinch> (obviously replacing that path with the path where you clone the repo)
<natefinch> ok, afk now
<ericsnow> katco: k
<mup> Bug #1527068 changed: MAAS retains child devices' IP addresses when a parent node is released <ci> <destroy-environment> <maas-provider> <network> <regression> <juju-core:Invalid> <juju-core 1.25:Triaged> <MAAS:Fix Released by mpontillo> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1527068>
<mup> Bug #1527068 opened: MAAS retains child devices' IP addresses when a parent node is released <ci> <destroy-environment> <maas-provider> <network> <regression> <juju-core:Invalid> <juju-core 1.25:Triaged> <MAAS:Fix Released by mpontillo> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1527068>
<frobware> cherylj, bug #1525280 is now for alpha2, so not a cut-off for this weds?
<mup> Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged by frobware> <juju-core 1.25:Fix Committed by dimitern> <https://launchpad.net/bugs/1525280>
<cherylj> frobware: isn't that bug no longer relevant when we back out bug #1483879?
<mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider>
<mup> <sts> <juju-core:Fix Released by dimitern> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Released by dimitern> <https://launchpad.net/bugs/1483879>
<cherylj> oh wait
<frobware> cherylj, on master?
<cherylj> you're talking about master
<cherylj> yeah
<cherylj> I just kinda assumed that you guys weren't going to get to it before then
<frobware> trying...
<cherylj> frobware: if you think you can get it in in the next couple days, then we can move it back
<cherylj> frobware: but really, there are some branches that are trying to land that are holding up alpha1
<frobware> cherylj, ok. I'll do some manual (yuck!) testing tomorrow.
<cherylj> frobware: if you need any help, let me know
<frobware> cherylj, I'm beginning to like the (over the wall) testing that gets done by a feature branch.
<cherylj> frobware: yeah it's nice.  We just need to get more hardware for the QA team since the number of branches we have to test has gone up so much!
<frobware> cherylj, arguably, to me at least, seems the most expedient thing we could do.
<cherylj> frobware: there is hardware that hasn't been set up by IS yet
<cherylj> I'm trying to find a name of someone who can help hurry that along
<mup> Bug #1527068 changed: MAAS retains child devices' IP addresses when a parent node is released <ci> <destroy-environment> <maas-provider> <network> <regression> <juju-core:Invalid> <juju-core 1.25:Triaged> <MAAS:Fix Released by mpontillo> <MAAS 1.8:Won't Fix> <https://launchpad.net/bugs/1527068>
<cherylj> hey natefinch-afk - is your fix for bug 1486553 in master?
<mup> Bug #1486553: i/o timeout errors can cause non-atomic service deploys <cisco> <landscape> <juju-core:In Progress by natefinch> <juju-core 1.24:Fix Released by natefinch> <juju-core 1.25:Fix Released by natefinch> <https://launchpad.net/bugs/1486553>
<cherylj> natefinch-afk: hmm, it's old.  Looks like it's there, though
<davechen1y> cherylj: hello, how can I help ?
<cherylj> hey davechen1y welcome back!
<cherylj> davechen1y: we're seeing seemingly random test failures on wily and xenial
<cherylj> davechen1y: sinzui is working on compiling a list of the failures for you to look at
<davechen1y> cherylj: ok, i'll get on it
<cherylj> thanks davechen1y!
<davechen1y> can you paste links to the failing builds ?
<cherylj> sinzui: do you have examples you can give davechen1y to look at while you're compiling the list?
<sinzui> cherylj: Still pasting.
<sinzui> davechen1y: cherylj: This is what we know, which is not much :( https://pastebin.canonical.com/147376/
<perrito666> sinzui: I know this is probably a stupid question but, do you have a moment?
<sinzui> perrito666: I do have a moment
<perrito666> sinzui: trying something else so I dont waste my time when I ask you the question
<perrito666> s/my/your
#juju-dev 2016-01-12
<davechen1y> http://reports.vapour.ws/releases/3495/job/run-unit-tests-wily-amd64/attempt/1131
<davechen1y> the coder referenced here doesn't exist anynmore
<davechen1y> did this bug get fixed ?
<anastasiamac> davechen1y: the coder or the code?
<mwhudson> that's a pretty severe penalty for introducing a race
<davechen1y> the latter
<mwhudson> davechen1y: it's on a branch?
<mwhudson> the test fails for me
<mwhudson> using go tip
<davechen1y> mwhudson: which rev are you at ?
<mwhudson> davechen1y: b9faceded0a321ffb39ba267f0a58a8a1c327fcb
<davechen1y> mwhudson: can you try tip, 756f3303f3f7ab32ddb1509c33209c34e3e3bb01
<mwhudson> davechen1y: yeah, github.com/juju/juju/worker/undertaker passes on master
<davechen1y> i think this has been fixed by a refactoring that wagini landed recentlyh
<davechen1y> there is no Kill method on this type any more
<natefinch-afk> cherylj: updated that bug and the related one - it's been fixed for a while now
<natefinch-afk> cherylj: sorry for forgetting to update the bug
<cherylj> natefinch: upi
<cherylj> whoops
<cherylj> you'd better be sorry
<cherylj> just kidding :)
<cherylj> I had an off by one error
<mup> Bug #1531718 changed: syslog full of "rsyslogd-2089: netstream session ... will be closed due to error" <juju-core:New> <https://launchpad.net/bugs/1531718>
<natefinch> cherylj: ha
<cherylj> :)
<dooferlad> frobware, voidspace: hangout?
<voidspace> dooferlad: frobware: grabbing coffee
<voidspace> with you in 2
<frobware> dooferlad, voidspace: http://reviews.vapour.ws/r/3497/
<frobware> dooferlad, voidspace: http://reviews.vapour.ws/r/3498/
<voidspace> frobware: LGTM on the short one
<frobware> dooferlad, voidspace: https://github.com/frobware/juju/commit/d155428f662378ef4856dddcab7990fe16c347a8
<frobware> dooferlad, voidspace: just a heads-up: we cannot land RB 3497 and 3498 without dooferlad's default gateway fix.
<voidspace> frobware: ah, ok
<frobware> dimitern, dooferlad, voidspace: some potential changes to ifup/down which we rely on https://bugs.launchpad.net/bugs/1337873
<mup> Bug #1337873: ifupdown initialization problems caused by race condition <patch> <sts> <verification-failed> <ifenslave (Ubuntu):Fix Released> <ifupdown (Ubuntu):Fix Released by dgadomski> <ifenslave (Ubuntu Precise):Won't Fix> <ifupdown (Ubuntu Precise):Won't Fix> <ifenslave (Ubuntu Trusty):Fix
<mup> Committed> <ifupdown (Ubuntu Trusty):In Progress> <ifenslave (Ubuntu Vivid):Fix Released> <ifupdown (Ubuntu Vivid):Won't Fix> <ifenslave (Ubuntu Wily):Fix Released> <ifupdown (Ubuntu Wily):In Progress> <ifupdown (Debian):New> <https://launchpad.net/bugs/1337873>
<voidspace> frobware: heh
<voidspace> frobware: long discussion
<frobware> voidspace, yeah
<frobware> very
<cherylj> bless on 1.25!!  woohoo!!
<ericsnow> katco, natefinch: upload is working now!  my patch is updated
<ericsnow> natefinch: looks like show-service-resources post-deploy (but before upload) may not be right
<ericsnow> natefinch: both resources are listed as "upload", but one of them should be "store" (unless I've misunderstood)
<ericsnow> katco, natefinch: oh, and hurray for (literally) dreaming up solutions to problems! :)
<natefinch> ericsnow, katco: well, upload seems to work, but I get a weird "invalid character 's' looking for beginning of value
<natefinch> "
<natefinch> ericsnow, katco: (error after running juju upload).  But juju show-service-resources says the upload succeeded (or at least enough to update the metadata)
<ericsnow> natefinch: that's due to the "application/json" content type of the response (+ returning the bare string "success")
<natefinch> lol
<ericsnow> natefinch: yep, the error comes from building the response *after* upload is completed
<natefinch> ericsnow: let's hack it so we don't see that error in the demo
<natefinch> or something
<ericsnow> natefinch: yep
<katco> ericsnow: natefinch: lol just return "{}"
<natefinch> ericsnow, katco: fixed the error.
<ericsnow> natefinch: thanks
<katco> natefinch: nice
<natefinch> well it works, except I realized I screwed up the time display in show-service-resources, so it shows 2016-12-01 for today... which is quite confusing
<natefinch> but a trivial fix
<cherylj> can I get an easy review?  http://reviews.vapour.ws/r/3502/
<natefinch> cherylj: ship it
<cherylj> thanks natefinch!
<natefinch> ericsnow, katco: http://pastebin.ubuntu.com/14478633/
<ericsnow> natefinch: nice
<katco> natefinch: very nice!
<mup> Bug #1533262 opened: Add xenial to supported series <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533262>
<mattyw> fwereade, ping?
<voidspace> fscking subnets cache
<mup> Bug #1533275 opened: agent install dies randomly on Azure <juju-core:New> <https://launchpad.net/bugs/1533275>
<natefinch> katco, ericsnow: anything I can do to help?
<katco> natefinch: we haven't paired up yet; i'm wrapping up admin stuff. maybe after lunch we can pair
<ericsnow> natefinch: review? https://github.com/juju/charm/pull/189
<natefinch> ericsnow: I'm on it
<ericsnow> natefinch: thanks
<perrito666> aghhh I just went through the pain of rebasing master into my feature branch to now get github complaining that it cannot merge
<natefinch> ericsnow: LGTM'd with a couple suggestions
<ericsnow> natefinch: k, thanks
<mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<cherylj> can I get a review?  http://reviews.vapour.ws/r/3504/
<mup> Bug #1533338 opened: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<mup> Bug #1533338 changed: TestSupportedSeries broken by the addition of xenial <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533338>
<natefinch> cd
<natefinch> gah
<natefinch> cherylj: lol
<natefinch> cherylj: ship it
<cherylj> heh, thanks natefinch :)
<natefinch> cherylj: this is where I'd use jc.SameContents
<cherylj> ah, yeah, I had forgotten about that
<natefinch> cherylj: sorting works, though :)
<natefinch> cherylj: actually, same contents is probably better
<natefinch> cherylj: since I don't think we really need to require that the list is alphabetical
<cherylj> ha, good thing I fatfingered the $$merge$$
<natefinch> lol
<cherylj> I'll go change it
<natefinch> cherylj: I only remember it because I wrote it ;)
<natefinch> cherylj: do you know if we still have a ton of failing tests on wily?  Because... I have a ton of failing tests, and I'm on wily
<cherylj> natefinch: there still are failures, yes
<natefinch> cherylj: gah
<natefinch> cherylj: well that's a shame
<cherylj> yeah, no kidding :/
<natefinch> given that it's like 3 months since it was released :/
<cherylj> natefinch: I updated http://reviews.vapour.ws/r/3504/
<waigani> fwereade: ping
<natefinch> cherylj: not to be a pain in the butt, but I think I'd keep the OSes separate.  It'll make it easier to maintain the list, I think (i.e. put xenial back after wily and put a blank line after it, and maybe a blank line before precise)
<cherylj> natefinch: heh, ok.  Can you make that comment in the RB?
<natefinch> done
<natefinch> worst ship it ever? :)
<cherylj> natefinch: it's like a string bet
<cherylj> a string ship it?
<cherylj> natefinch: 3rd time's a charm?
<natefinch> cherylj: ship it, quick before I change my mind!
<cherylj> merge like the wind!
<natefinch> cherylj: btw, looks like master is in a much better state than our resources branch...  I guess we haven't merged in a while.
<natefinch> cherylj: (wrt wily tests)
<cherylj> natefinch: yeah that will help.  There were some recent changes to help, I think
<natefinch> katco, ericsnow: I gotta run a little early today, but I can be on for a pretty long time later.  Send an update if there's stuff I can help with, otherwise, I'll see if I can get master merged into our branch (for after the demo)
<ericsnow> natefinch: k
<katco> natefinch-afk: k thx
<cherylj> jog_: sinzui how old are the trusty images on the 1.8 maas?
<jog_> cherylj, hmm not sure but I'll see if I can tell
<sinzui> cherylj: I don't recall. I think they re from 8 months ago. jog: do you recall the age of the trusry images
<jog_> cherylj, you mean the host that MAAS is running on or the images that are installed on deploy?
<cherylj> jog_: the images installed on deploy
<cherylj> if they're old and things need to be updated once they boot, it could cause this long test time
<cherylj> and potentially conflicting updates from charms (contention for dpkg lock)
<jog_> we have enable-os-upgrade: false set
<cherylj> ah
<cherylj> jog_: and enable-os-refresh-update?
<jog_> that's not set
<cherylj> it defaults to true
<jog_> the maas syncs with http://maas.ubuntu.com/images/ephemeral-v2/releases/ every 60 minutes
<cherylj> jog_: is there a way to get newer images?
<jog_> cherylj, I'm not sure what's actually pulled from that location but the newest images there are July 30
<cherylj> <mbruzek> You are using Maas, do you know how old the images are?
<cherylj> <mbruzek> I remember getting these kind of errors when we used OLD images with the lxc provider
<mbruzek> Hello cherylj and jog_
<cherylj> welcome to the party mbruzek ;)
<jog_> cherylj, I suppose we "could" point at daily but we want to test what we think is used in customer environments...
<jog_> MAAS installs with the URL I gave above
<jog_> hi mbruzek
<mbruzek> What is the status of the latest deploy?
<jog_> 26 minutes in... usually fails around 50 minutes
<cherylj> jog_: would it be possible for me to ssh into the machines and inspect while it's running?
<mbruzek> from the log that cherylj shared with me the first error was rabbitmq not starting
<mbruzek> 2016-01-12 17:31:30 INFO config-changed  * Starting message broker rabbitmq-server
<mbruzek> 2016-01-12 17:31:41 INFO config-changed  * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
<jog_> cherylj, yes... I was just going to check if the rabbit machine was up
<mbruzek> jog_: cherylj: is this not the charm store version of rabbitmq-server?
<mbruzek> 2016-01-12 17:31:30 INFO config-changed  * Starting message broker rabbitmq-server 2016-01-12 17:31:41 INFO config-changed  * FAILED - check /var/log/rabbitmq/startup_\{log, _err\}
<mbruzek> oops, i meant to paste this: 2016-01-12 17:26:16 INFO juju.worker.uniter.charm bundles.go:60 downloading local:trusty/rabbitmq-server-150 from https://10.0.80.105:17070/environment/4a6edd01-4253-4351-8ec8-e58cfe011a5e/charms?file=%2A&url=local%3Atrusty%2Frabbitmq-server-150
<mbruzek> local:trusty/rabbitmq-server-150 seems like a different charm than the charm store version.  Maybe I am looking at the wrong code
<jog_> rabbitmq-server-150 is what we're installing... it's the same bundle that the Openstack team uses
<mbruzek> jog_: Then why isn't it the one that is in the charm store?  Can this maas server not get there?  Or is there special sauce?
<mbruzek> jog_: I suspect they are not the same.  If you ran: "charm get trusty/rabbitmq-server" and diffed the directories that would tell the tale.  The rabbitmq-server charm is frequently updated.
<jog_> beisner, do you know the history of why the 7-machine bundle is locked to rabbitmq-server-150?
<jog_> cherylj, I know you know this but this is the same bundle that quickly passes with 1.25.2...
<mbruzek> last update to rabbitmq-server was 2015-10-30 but a change from beisner went in at 2015-10-22
<jog_> so just a bit confused as to how the bundled charm version would be the issue.
<mbruzek> jog_: I am confused as to why you have a local copy of a charm.  Why not just lock a revision of the charm store charm with the bundle?
<jog_> mbruzek, the Openstack team as a recommended bundle recipe that they test and release with. Juju-qa uses the same bundle to we stay in lock step with them.
<mbruzek> jog_: OK but isn't there a charm store revision of the charm that works?  Why the need for a local charm.  Are all the charms local?
<mbruzek> jog_: I am just trying to help diagnose this failure, and perhaps I am not being successful at understanding the context.
<jog_> ah... I think juju deployer downloads the charm initially and then installed them
<jog_> yup... looking at deployer logs... it branches all the charm code first
<mbruzek> OK
<ericsnow> katco: could you take a look at http://reviews.vapour.ws/r/3506/?
<ericsnow> katco: mostly, it is a port of the fingerprint stuff from the charm repo to the utils repo
<katco> ericsnow: sure
<katco> ericsnow: sorry was in a meeting... what are the new bits in this?
<ericsnow> katco: just lining up fingerprints with other hash-related tools in utils
<ericsnow> katco: Fingerprint is also decoupled from a particular hash type
<katco> ericsnow: ah cool
<katco> ericsnow: some nice code
<mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
<mup> Bug #1527020 opened: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
<mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
<mup> Bug #1527020 opened: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
<mup> Bug #1527020 changed: cannot build trusty ppc64el juju without forcing GOARCH <ppc64el> <regression-update> <trusty> <juju-core:Fix Released> <gccgo-go (Ubuntu):Invalid> <https://launchpad.net/bugs/1527020>
<mattyw> anastasiamac, hey hey
<anastasiamac> mattyw: \o/
<ericsnow> katco: have time for an ultra-quick review? http://reviews.vapour.ws/r/3509/
#juju-dev 2016-01-13
<perrito666> thanks for the review waigani very good questions
<waigani> perrito666: np :)
<menn0> waigani: here's the fix for the frequent panics in the machine-dep-engine under Go 1.5: https://github.com/juju/juju/pull/4090
<menn0> waigani: review please
<waigani> menn0: looking
<waigani> menn0: ship it. I didn't know about sync.Once - handy
<menn0> waigani: I knew about it but had never used it
<waigani> menn0: It does feel like a slight kluge. Shouldn't the flow be such that close can only be called once?
<menn0> waigani: well it's perfectly ok for Kill to be called lots of times
<waigani> that's true
<menn0> waigani: and this case you want the channel to be close on Kill
<waigani> okay, fair enough :)
<mup> Bug #1533431 opened: Bootstrap fails inexplicably with LXD local provider  <docteam> <juju-core:New> <https://launchpad.net/bugs/1533431>
<cherylj> mwhudson: is someone actively working on getting go 1.5 into trusty?
<mup> Bug #1533469 opened: github.com/juju/juju/api/reboot Build failed <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1533469>
<mup> Bug #1533469 changed: github.com/juju/juju/api/reboot Build failed <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1533469>
<mup> Bug #1379930 changed: relation config values set to the empty string are lost <charm> <relations> <juju-core:Expired> <https://launchpad.net/bugs/1379930>
<mup> Bug #1514570 changed: 'JUJU_DEV_FEATURE_FLAGS=address-allocation' blocks after first 3 ips are allocated <juju-core:Expired> <https://launchpad.net/bugs/1514570>
<mup> Bug #1533469 opened: github.com/juju/juju/api/reboot Build failed <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1533469>
<mup> Bug #1379930 opened: relation config values set to the empty string are lost <charm> <relations> <juju-core:Expired> <https://launchpad.net/bugs/1379930>
<mup> Bug #1514570 opened: 'JUJU_DEV_FEATURE_FLAGS=address-allocation' blocks after first 3 ips are allocated <juju-core:Expired> <https://launchpad.net/bugs/1514570>
<mup> Bug #1379930 changed: relation config values set to the empty string are lost <charm> <relations> <juju-core:Expired> <https://launchpad.net/bugs/1379930>
<mup> Bug #1514570 changed: 'JUJU_DEV_FEATURE_FLAGS=address-allocation' blocks after first 3 ips are allocated <juju-core:Expired> <https://launchpad.net/bugs/1514570>
<mup> Bug #1532130 changed: Config item 'version' vanishes with 1.26 <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1532130>
<mup> Bug #1532130 opened: Config item 'version' vanishes with 1.26 <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1532130>
<mup> Bug #1532130 changed: Config item 'version' vanishes with 1.26 <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1532130>
<mup> Bug #1532130 opened: Config item 'version' vanishes with 1.26 <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1532130>
<mup> Bug #1532130 changed: Config item 'version' vanishes with 1.26 <regression> <juju-core:Invalid> <https://launchpad.net/bugs/1532130>
<mup> Bug #1532130 opened: Config item 'version' vanishes with 1.26 <regression> <juju-core:New> <https://launchpad.net/bugs/1532130>
<mattyw> anastasiamac, morning, still around?
<anastasiamac> mattyw: m on and off - kids r home, dinner...
<mattyw> anastasiamac, no problem
<dimitern> frobware, dooferlad, morning :) can I bother you with a review on http://reviews.vapour.ws/r/3482/ please?
<frobware> dimitern, welcome back & done.
<dimitern> frobware, thanks!
<frobware> dimitern, I plan to make everything a bridge on the maas-spaces branch when we re-render /e/n/i. Any thoughts or concerns?
<dimitern> frobware, like we discussed last week? i.e. is_active always True?
<frobware> dimitern, yes. I think, initially, I would like to take the simplest approach and if we find that bridging the world is too much we take another look.
<frobware> dimitern, do you want to drop this (http://reviews.vapour.ws/r/3472/) as my 1.25-redux branch landed?
<dimitern> frobware, sounds good
<dimitern> frobware, will do
<dimitern> voidspace, jam, frobware, standup?
<alexisb> dimitern, I am keeping jam busy
<dimitern> alexisb, sure, np just checking
<voidspace> dimitern: omw
<jam> dimitern: voidspace: have any time to chat briefly about what's going on here?
<dimitern> jam, sure - when will be a good time for you?
<jam> I'm writing up a summary email of the discussions from the morning, I have lunch pretty soon
<jam> I seem to have a gap in about 4hrs, does that work for both of you?
<dimitern> jam, works for me
<voidspace> jam: should be fine
<jam> bridge
<mup> Bug #1533694 opened: inconsistent juju-gui and juju status <juju-core:New> <https://launchpad.net/bugs/1533694>
<mup> Bug #1533694 changed: inconsistent juju-gui and juju status <juju-core:New> <https://launchpad.net/bugs/1533694>
<mup> Bug #1533694 opened: inconsistent juju-gui and juju status <juju-core:New> <https://launchpad.net/bugs/1533694>
<cherylj> yikes.  what happened with that controller-rename test, sinzui ?
<cherylj> http://reports.vapour.ws/releases/3503
<sinzui> cherylj: the previous job left xenial-slave dirty. I am not having must success cleaning either
<cherylj> :(
<sinzui> cherylj: I am going to remove the failed 1.25 revision from testing to make controller-rename complete testing, thenlet 1.25 be rediscovered.
<cherylj> sinzui: sounds good
<voidspace> dimitern: ping
<voidspace> dimitern: unping
<TheMue> voidspace: *lol* didn't know this "command"
<voidspace> TheMue: heh :-)
<voidspace> I use it all the time...
<TheMue> cool
<voidspace> well, writing tests has just found two more bugs in my code
<perrito666> voidspace: writing tests always does that
<perrito666> its very bad for the pride :p
<voidspace> :-)
<TheMue> voidspace: just writing tests for my latest feature too
<voidspace> TheMue: heh, cool
<jam> natefinch: katco: I'm trying to use the LXD provider, but it is failing to set up ssh keys on the started container
<jam> I can see authorized-keys that make sense in the instanceconfig
<katco> jam: ericsnow as well ^^^
<katco> jam: that's a new one i think
<jam> but /home/ubuntu/.ssh/ is empty
<katco> that's very strange...
<jam> I can see in cloud-init-output.log it is complaining that there was nothing in /home/ubuntu/.ssh as well
<jam> (i think)
<perrito666> jam: try adding that to your keyring
<perrito666> I recall some of the providers not working for that
<perrito666> sinzui: it was the key ring right? during the sprint with HP
<katco> jam: talking this over with the team, but on the surface this doesn't sound like something the lxd provider would be responsible for. what build of juju are you using?
<katco> jam: also, standard questions: what ubuntu+lxd are you running?
<sinzui> jam: perrito666 : yes, add the $HOME/.ssh/<keys> to your key ring.
<jam> katco: trusty with the stable ppa
 * perrito666 is working at a bar and just asked a coffee in english
 * perrito666 hides under the table
<jam> perrito666: if I attach to the instance, /home/ubuntu/.ssh is empty
<jam> that doesn't sound like a keyring thing
<jam> And if I add a debug print before the instance is spawned, I see the ssh public key in the instance config
<perrito666> :|
<jam> katco: I'm using nate's branch
<katco> jam: ah... i'm surprised it's even getting that far? the trusty version doesn't have lxd built in because it's not >= go1.3
<jam> katco: stable ppa
<jam> ppa:ubuntu-lxc/lxd-stable IIRC
<jam> katco: I'm using the resources branch
<katco> ohhh for lxd
<katco> ok ok gotcha
<jam> I can "lxc attach" to the instance to debug it
<jam> but I get the same result reliably right now
<jam> (lxc exec ... bash)
<katco> jam: ok, that makes a lot more sense. natefinch is telling me the pastebin i sent you was local provider, not lxd. we're investigating lxd now
<katco> jam: we're probably just sitting on an unstable commit of master
<jam> ci-info: no authorized ssh key fingerprints found for user ubuntu
<natefinch> we know we're kind of out of date wrt to master... I'd just use local, if it's all the same.
<blackboxsw> g
<jam> natefinch: with local provider I can replicate the demo script
<katco> jam: we're working on getting lxd to work (as well as resource-get)
<dooferlad> dimitern, frobware, voidspace: I can work around the issue of not having a default gateway set in MAAS by setting a guests default gateway to its hosts IP address. Since we have forwarding enabled on all our hosts this works.
<dooferlad> It is a bit rubbish, but it doesn't involve parsing any more files - the data is in state.
<frobware> dooferlad, does that mean the "real" gateway is not in state?
<dooferlad> frobware: yes
<dimitern> dooferlad, we only have fwding on with the A-C feature flag
<dooferlad> dimitern: I have set no flags
<dooferlad> frobware: the host is getting its address by DHCP
<dooferlad> and the guest from the MAAS API
<dooferlad> it feels really messed up
<jam> katco: so talking with the guys here about lxd, you *shouldn't* use the linuxcontainers.org images, because those don't have cloudinit installed
<jam> you just need the lxd-images import
<jam> as that is from cloud-images.ubuntu.com simplestreams info
<dimitern> dooferlad, that's exactly what we do for A-C - host acts like a gateway, but that has its drawbacks
<perrito666> jam: the instructions do say to use the cloud images, doesn't it? (i only used lxd provider once)
<dimitern> like the need for fwding on, as well as packets coming from a container will have different TTL and source as they arrive at the destination
<jam> perrito666: the first thing it says is to "lxc add linuxcontainers.org" but then not use it
<jam> katco: fwiw, it fails with master as well
<jam> same "(publickey)" issue
<katco> jam: bootstrapping lxd?
<perrito666> jam: ah, I just ignored that one
<jam> katco: yeah
<jam> I'm using ubuntu-trusty and not ubuntu-wily, don't know ifthat matters
<jam> IIRC they use a diffreent cloud-init version
<natefinch> jam: you need ubuntu wily for the bootstrap server at least
<natefinch> jam: iirc
<katco> jam: that should work, i'm using ubuntu-trusty
<jam> anyway, I can reproduce this if you want a test case
<jam> but I'm off to other things now
<dooferlad> dimitern: I don't know why we have the host using DHCP but not for the container. Is that how the MAAS devices API works?
<katco> jam: absolutely, ty for the input
<natefinch> I'm pretty sure this is just a result of using the wrong images
<katco> jam: you're doing --upload-tools?
<jam> katco: it fails right away if you don't
<jam> (it fails with "I don't know what lxd provider is" cause it uses some other version)
<katco> jam: i dunno, i think natefinch is correct. there's something unique with what you're doing. sounds like the image
<katco> jam: i've got a bootstrapped env. right now on ubuntu-trusty
<katco> jam: but we'll figure it out, open a bug if you don't mind
<jam> katco: I just did "lxd-images import ubuntu --alias ubuntu"
<frobware> dooferlad, you have mail
<jam> its release-2015218
<katco> jam: fingerprint?
<katco> jam: actually what's lxc image list
<jam> getting it, just a sec
<dooferlad> frobware: a victory for sanity!
<katco> jam: np. understand if you have to run too
<jam> ffs. just ran into a bug with lxd-images. I had deleted the image to double check the download, and now lxd-images import is giving me a "NoneType is not iterable" after doing the download
<katco> jam: =|
<jam> katco: 0afd3f6ac was in my terminal backtrace
<natefinch> that's different than mine... are they supposed to be the same fingerprint for different people and/or different times?  I'm not sure I'd trust they don't get updated with security patches etc
<katco> jam: i think that's the one i'm on: 0afd3f6ac0d7
<jam> katco: https://bugs.launchpad.net/juju-core/+bug/1533742
<mup> Bug #1533742: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1533742>
<jam> natefinch: katco: 20151218 is dec-18 when they last updated it
<jam> (according to the URL from lxd-images import)
<katco> jam: i'm trying to repro from master as well (but my host is wily)
<jam> katco: thanks.
<jam> I would think the issue would be the image version vs the host, which I'm guessing you're thinking as well
<katco> jam: what version of go are you compiling master with?
<jam> katco: 1.6
<jam> 1.5
<jam> the one that you get after adding the lxd ppa
<jam> 1.5.1
<katco> jam: should be sufficient
<jam> anyway, now need to get ready for dinner. but I do have your demo working. I think I'm scheduled for Fri morning
<jam> so if you can add resource-get to show the resources working, that'd be great
<katco> jam: k, we're also pushing for resource-get
<perrito666> bbl, changing locations
<katco> jam: thx john
<mup> Bug #1533742 opened: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1533742>
<mup> Bug #1533742 changed: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1533742>
<mup> Bug #1533742 opened: lxd provider fails to setup ssh keys during bootstrap <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1533742>
<mup> Bug #1533750 opened: 2.0-alpha1 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1533750>
<mup> Bug #1533751 opened: Increment minimum juju version for 2.0 upgrade to 1.25.3 <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1533751>
<mup> Bug #1533750 changed: 2.0-alpha1 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1533750>
<mup> Bug #1533751 changed: Increment minimum juju version for 2.0 upgrade to 1.25.3 <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1533751>
<mup> Bug #1533750 opened: 2.0-alpha1 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1533750>
<mup> Bug #1533751 opened: Increment minimum juju version for 2.0 upgrade to 1.25.3 <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1533751>
<fwereade> huh, I think that was an earthquake
<natefinch> neat
 * natefinch says from a place that pretty much never has earthquakes.
<fwereade> yeah, it's a bit disconcerting, I never remember feeling one in the uk
<cherylj> katco: ping?
<katco> cherylj: hey
<cherylj> katco: got a minute?
<katco> cherylj: yeah sure
<cherylj> katco: https://plus.google.com/hangouts/_/canonical.com/cheryl-katco?authuser=0
<katco> natefinch: don't forget to drag the card for the bug you're working on to in progress
<katco> ericsnow: ping?
<ericsnow> katco: hey
<ericsnow> katco: sorry, I'm ready to go
<katco> ericsnow: "no more than half an hour" - ericsnow 2.5h ago
<katco> ;)
<katco> ericsnow: at this point, let's wait until after lunch.
<cherylj> Can I get a review?  http://reviews.vapour.ws/r/3519/
<cherylj> Small review
<ericsnow> katco: k
<katco> cherylj: lgtm
<cherylj> thanks, katco
<perrito666> jam: ping
<natefinch> good licl., ot
<natefinch> it's 10:41pm where he is
<natefinch> good luck, that is...
<natefinch> unless he's in cape town, in which case it's 8:41
<natefinch> still not good odds :)
<perrito666> I assumed he was in capetown
<natefinch> katco: sorry, was at lunch and then trying to figure out which of the networking bugs is least terrible to work on
<mup> Bug #1533790 opened: GCE provider is very restrictive when using a config-file (json) <juju-core:New> <https://launchpad.net/bugs/1533790>
<mup> Bug #1533792 opened: Panic: TestProvisioningMachinesWithSpacesSuccess <ci> <panic> <ppc64el> <regression> <test-failure> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1533792>
<perrito666> is anyone aware of the current status of syslog vs mongodb?
<katco> ericsnow: ok i'm ready to pair if you are
<ericsnow> katco: gimme half an hour <wink>
<ericsnow> katco: BRT :)
<katco> rofl
<thumper> morning folks
 * thumper grunts
<thumper> almost 2500 emails
<katco> heyo thumper
<perrito666> thumper: returning from holidays?
<thumper> perrito666: aye
<thumper> first day back after three weeks
<natefinch> thumper: must be rough
<perrito666> uff, heavy
<thumper> lots of email
<perrito666> it would be nice to have a "valid until" feature on emails
<perrito666> :p
<perrito666> "sorry this email went sour"
<thumper> :)
<cherylj> jog__: are you around?
<jog__> cherylj, yes
<cherylj> jog__: are the MAASes currently occupied?
<jog> cherylj, yes, there are 3 CI jobs running. What do you need?
<cherylj> jog: if I could look at a running env while it's doing the deployer test, I might be able to get more data on the rabbitmq-server failures
<cherylj> jog: or if I could do a simple depoy
<cherylj> deploy even
<jog> cherylj, If you want to bootstrap and just deploy a single rabbitmq-server charm, the MAAS should have capacity for that... deploying the entire OS bundle when other things are running is when we run into resource issues... I can deploy a rabbitmq-server for you.
<cherylj> jog: it would need to be in a container
<jog> ok
<cherylj> so just deploy --to lxc:0
<cherylj> I'm wondering if we've run into bug 1329930
<mup> Bug #1329930: rabbitmq-server fails to deploy into lxc container on maas provider <rabbitmq-server (Juju Charms Collection):Fix Released> <https://launchpad.net/bugs/1329930>
<cherylj> I see someone else has run into it recently
<natefinch> cherylj: git blame says I should talk to you about https://bugs.launchpad.net/juju-core/+bug/1515289
<mup> Bug #1515289: bootstrap node does not use the proxy to fetch tools from streams.c.c <bug-squad> <juju-core:Triaged> <https://launchpad.net/bugs/1515289>
<cherylj> natefinch: I didn't do it!
<natefinch> cherylj: totally possible :)
<natefinch> cherylj: https://github.com/juju/juju/blob/master/cloudconfig/userdatacfg_unix.go#L260
<natefinch> cherylj: so, I think the title of that bug is wrong
<natefinch> cherylj: he can bootstrap just fine, which means he gets the tools from streams ok.  It looks like the problem is actually that new nodes can't get the tools from the state server
<natefinch> cherylj: sorry, I may be confused, however
<cherylj> natefinch: he includes something else later that shows the get command the bootstrap node is trying to use to get the tools from streams
<cherylj> I then inspected the bootstrap node, and found this in all-machines.log: <...>
<natefinch> cherylj: ok, I think I understand what I'm seeing... I thought the --noproxy on the curl command from the other node was the problem, but that's probably just failing because the state server can't get the tools either
<cherylj> natefinch: yeah, I believe that's the case
<natefinch> cherylj: ok, nevermind then. Thanks for helping me understand the bug report :)
<jog> cherylj, it's bootstrapping
<natefinch> ericsnow: gah, you broke GenerateFingerprint(nil) :/
<mup> Bug #1533849 opened: github.com/juju/juju/version [build failed] on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533849>
<mup> Bug #1533849 changed: github.com/juju/juju/version [build failed] on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533849>
<mup> Bug #1533849 opened: github.com/juju/juju/version [build failed] on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533849>
<cherylj> stop it, mup
<cherylj> review, pretty please: http://reviews.vapour.ws/r/3520/
<natefinch> cherylj: shipit
<natefinch> cherylj: are you not using goimports?
<mup> Bug #1533849 changed: github.com/juju/juju/version [build failed] on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533849>
<natefinch> cherylj: or hmm, is it because it's an _windows file, so it gets missed
<natefinch> cherylj: was going to ask how you even landed code that wouldn't compile, but of course our landing bot isn't compiling on windows (yet)
<perrito666> goimports rocks
<natefinch> perrito666: yeah, I wasn't convinced until I used it, now I love it.
<perrito666> I have it hooked on save
<natefinch> yep, me too.  The only problem I have is when I manually add an import (for example, one that needs to be named) and then accidentally hit save before I have used it.
<mup> Bug #1533849 opened: github.com/juju/juju/version [build failed] on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1533849>
<perrito666> yup, happens sometimes
<perrito666> but i usually write the code the other way
<natefinch> perrito666: I have autocomplete, to help remind me what the names of things are, but it won't work if the import doesn't exist yet, so it's kind of a chicken and egg thing.
<perrito666> aaand of course, defaulting mongo log breaks tests
<natefinch> lol
<natefinch> because of course it does
<natefinch> perrito666: what, logging to mongo and having tests that inspect log output don't somehow turn two bad ideas into a good idea? :)
<perrito666> yeah, logging one into one unreliable destination beats just logging all into one destination
<natefinch> whelp, dinner time.  Back later.  Good luck storming the castle!
<cherylj> jog: any luck getting rabbitmq-server to deploy?
<jog> cherylj, not yet, I had to cleanup left behind nodes on the MAAS, it's redeploying now
<cherylj> jog: can I ssh into it from finfolk and watch the deploy?
<jog> cherylj, yes... export JUJU_HOME then run juju status -e min-lxc
<cherylj> jog: thanks!
<jog> cherylj, kill-controller ran despite --keep-env
<cherylj> blargh
<katco> cherylj: do you need me in the release standup?
<cherylj> katco: no, I don't think so.  Thanks!
<katco> cherylj: cool ty, pairing atm
<thumper> perrito666: still here?
<thumper> perrito666: state environ.go, LatestAvailableTools, never written to, added back in Sep, is it going to be used?
<thumper> hmm... found something
<thumper> nm
<cherylj> hey thumper, I figured out the cause of some of the test failures.  I have the change merging for master now.  Would you be able to rebase controller-rename once it merges?
<perrito666> axw: anastasiamac going
<perrito666> thumper: here,
<jog> the controller-rename juju binary complains if destroy-environment is used with: ERROR "parallel-maas18" is a system; use 'juju system destroy' to destroy it
<perrito666> thumper: sorry I was trying to sport away the effects of working on a desk
<jog> it also complains with: ERROR unrecognized command: juju system
<perrito666> thumper: that was added and later changed by menn0 iirc
<jog> I was able to destroy with 'destroy-controller' are we just in transition here or is a bug needed?
<mup> Bug #1533896 opened: Metadata worker repeatedly errors on new azure <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1533896>
<mup> Bug #1533896 changed: Metadata worker repeatedly errors on new azure <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1533896>
<mup> Bug #1533896 opened: Metadata worker repeatedly errors on new azure <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1533896>
#juju-dev 2016-01-14
<menn0> perrito666, thumper: what did I do?
<menn0> perrito666: natefinch-afk: the other problem with goimports is that it doesn't know about the 3 import groupings we use in Juju (i.e. std lib, external, internal)
<menn0> perrito666: natefinch-afk: it sometimes puts new imports in the wrong place
<menn0> perrito666: natefinch-afk: but apart from that it's awesome
<thumper> davecheney: o/
<davecheney> thumper: hey there
<davecheney> welcome back
<thumper> cheers
<davecheney> thumper: thought you came back tomorrow ?
<thumper> true for yesterday :)
<davecheney> understood
<davecheney> i didn't remember when I was supposed to come back
<davecheney> and turned up on monday
<thumper> haha
<natefinch> anyone online know about downloading our tools and how they relate to proxies?  re: https://bugs.launchpad.net/juju-core/+bug/1515289
<mup> Bug #1515289: bootstrap node does not use the proxy to fetch tools from streams.c.c <bug-squad> <juju-core:Triaged> <https://launchpad.net/bugs/1515289>
<natefinch> thumper, menn0, waigani, davecheney^ ?
 * thumper shakes his head
<menn0> natefinch: I suspect wallyworld or axw might be able to help
<axw> natefinch: all I can say is that it's meant to use the proxy... I don't know why it's not
<natefinch> axw: ok, pretty sure I know why it's not: https://github.com/juju/utils/blob/master/http.go#L79
<natefinch> axw: this should be setting Proxy to http.ProxyFromEnvironment .... but wanted to make sure we weren't avoiding the proxy on purpose
<axw> natefinch: yep, that'll do it :/
<axw> natefinch: not that I'm aware of
<axw> (avoiding proxy)
<natefinch> axw: I notice that the http.Client's default transport (https://golang.org/pkg/net/http/#DefaultTransport) sets a tlshandshaketimeout ... and our version doesn't.  Seems worth setting the same as the default.
<natefinch> axw: do you concur?
<axw> natefinch: seems reasonable
<thumper> axw: sometime when you have some time, I'd like to chat about storage collections w.r.t. model migration
<axw> thumper: sure thing
<thumper> menn0: it looks like my read only branch did get merged
<axw> thumper: I can do whenever really. let me know when suits you
<thumper> axw: kk, I may ping you when I need a break
<thumper> probably tomorrow
<axw> okey dokey
<thumper> menn0: ah, not all of it
<natefinch> axw: care to review? http://reviews.vapour.ws/r/3529/
<axw> natefinch: sure
<axw> natefinch: ah, looks like Go 1.2 has no TLSHandshakeTimeout field.
<natefinch> whoopee
<natefinch> timeouts are for suckers anyway
<natefinch> tempted to make two files with build constraints so we get the tls handshake timeout on builds that use go 1.3+ ...
<natefinch> axw: updated with go 1.2/1.3+ code.... I don't want to have to remember to go fix this later... now the worst that happens is we have unused go 1.2 code hanging around, which won't hurt anything if we forget about it for forever.
<axw> natefinch: WFM. shipit
<cherylj> can someone review dave's patch for the gccgo problems?  http://reviews.vapour.ws/r/3527/
<davecheney> ping https://github.com/juju/juju/pull/4106
<davecheney> this is an urgent bug fix
<davecheney> reviews most welcome
<axw> looking
<cherylj> davecheney: once reviewed, can you also get it into 1.25?
<axw> davecheney: LGTM
<davecheney> cherylj: yes
<cherylj> thumper: this is another patch you'll need to pull into controller-rename
<thumper> ugh
<thumper> k
<cherylj> davecheney: looks like the merge failed because of go fmt issues?
<davecheney> cherylj: fixed
<cherylj> thanks davecheney !
<natefinch> axw: one more review, to hook up the previous change to juju/juju (and bonus fix for metric sender that was already rolling its own transport incorrectly in other ways as well as forgetting the proxy): http://reviews.vapour.ws/r/3530/diff/#
<axw> natefinch: LGTM
<natefinch> axw: thanks!
<natefinch> axw: heh, of course, master is blocked, so I guess it's moot.  Ahh well, it'll get unblocked at some point.
 * thumper is done
<thumper> I'll check in to see if davecheney's fix lands in master and bring it into controller-rename
<davecheney> oops
<davecheney> that didnt work
<davecheney> i didnt rn the whole test suite s it tajes close to an hour for me
<davecheney> oh great
<davecheney> this is a go 1.2 vs go 1.5 differnce
<davecheney> anyway, fix coming up
<davecheney> cherylj: axw thumper-afk https://github.com/juju/juju/pull/4109
<davecheney> ^ 1.25 backport
<thumper-afk> shipit
<axw> davecheney: +1, also, you don't need to get a review for trivial back/forward ports
<davecheney> m'kay
<davecheney> axw: https://github.com/juju/juju/pull/4109
<davecheney> which part of JFDI does the bot not understand
<axw> davecheney: huh, dunno what's up with that
<mup> Bug #1534011 opened: ~/.juju/credentials.yaml permissions should be 600 <juju-core:New for wallyworld> <https://launchpad.net/bugs/1534011>
<dooferlad> dimitern, voidspace, frobware: https://plus.google.com/hangouts/_/canonical.com/juju-core-team
<voidspace> ah yes
<voidspace> dooferlad: thanks
<frobware> dooferlad, running late
<anastasiamac> waigani: ping?
<dooferlad> frobware: ISTR you mentioned lldb needing some patches to debug go. Did I imagine that?
<frobware> dooferlad, only if you want to do it within Emacs.
<dooferlad> frobware: cool!
<frobware> dooferlad, I have a patch for gud.el but I was looking back through my chrome history and cannot find its provenance.
<frobware> dooferlad, https://gist.github.com/ptrv/71b93594589f3a5f27d2
<frobware> dooferlad, found it! ^^
<dooferlad> frobware: I am sure dimitern will be interested. Myself, I am a sublime text guy.
<frobware> dooferlad, I'm sorry. :-D
<dimitern> frobware, hmm - is this the debugger code you were talking about?
<frobware> dimitern, yep. but you will need to build lldb from trunk.
<frobware> dimitern, seen this before? "WARNING interface "bond1" link 339 missing subnet"
<voidspace> frobware: dimitern: when is our "demo"?
<frobware> voidspace, was done on Monday/Tue, I believe.
<frobware> voidspace, dooferlad, dimitern: shall we have a quick call based on jam's meeting yesterday?
<frobware> voidspace, we can share news on the demo, et al.
<voidspace> frobware: sounds good, gimme 5 to grab coffee first?
<voidspace> frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/3534/
<dooferlad> frobware: +1
<frobware> dimitern, dooferlad, voidspace: I dumped an entry into the calendar but let's use the standup HO
<dimitern> frobware, yeah
<dooferlad> frobware: the juju-saphire or saphire one. There are two :-)
<dimitern> frobware, that's coming from the new NICs handling code
<dimitern> voidspace, looking in a bit
<frobware> dooferlad, juju-sapphire
<frobware> dimitern, voidspace: ready to join?
<voidspace> frobware: yes
<voidspace> omw
<mup> Bug #1534103 opened: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
<mup> Bug #1534103 changed: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
<mup> Bug #1534103 opened: "unknown operation kind run-action" (1.26alpha3) <juju-core:New> <https://launchpad.net/bugs/1534103>
<perrito666> voidspace: just as an example, there is no such thing as house-wide climatization for residences and afaik for business is way more rudimentary than yours
<frobware> dooferlad, https://bugs.launchpad.net/juju-core/+bug/1532167
<mup_> Bug #1532167: maas bridge script handles VLAN NICs incorrectly <addressability> <maas-provider> <network> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1532167>
<mgz> dooferlad: can you test lp:~gz/juju-ci-tools/common_container_networking
<mgz> dooferlad: I tried not to break your existing expectations, but it'sa pretty big change
<voidspace> perrito666: "house-wide climatization", you mean thermostat or air conditioning?
<voidspace> perrito666: we don't do air conditioning here in the UK either...
<perrito666> voidspace: climatization as climatization in any sense
<perrito666> usually we have individual heaters for each room (those with a gas powered flame)
<perrito666> and same with ACs
<perrito666> I got a house wide in-floor heating but its a weird thing
<frobware> dimitern, do you have a MAAS setup with VLANs, bonds & aliases that you could try change on: https://github.com/frobware/juju/tree/maas-space-bridge-party
<dimitern> frobware, looking
<dimitern> frobware, I don't have bonds but I'll add one now
<frobware> dimitern, I'm looking for some confirmation that what I'm doing is not too simplistic.
<cherylj> oh thank god SOMETHING got blessed
<frobware> dimitern, "WARNING interface "bond1" link 339 missing subnet" - 339 is some internal id?
<dimitern> yeah it's the link id
<dimitern> the thing represented in the "links" of an item inside the interface_set map
<voidspace> perrito666: ah ok, maybe you are safe then...
<dooferlad> mgz: it seems fine, but I haven't run it. Thanks for cleaning it up.
<mgz> dooferlad: not sure it's quite right atm, haven't got it to actually reuse an env yet
<mgz> the other bits seem fine
<mgz> (well, kvm doesn't work on aws, but that's expected)
<frobware> dimitern, can't decide whether my change or moving to 1.9.0 has affected the way bond0 works...
<frobware> dimitern, but I do have trouble with bond0 now...
<dimitern> frobware, I'm testing maas-spaces + your changes on the hw maas
<frobware> dimitern, I dropped my bond0 and all is well. Hmpf.
<dimitern> frobware, hmm - perhaps it depends on the specific bond params
<dimitern> frobware, I'm deploying a node now with the 2 NICs in a bond0, and on top of it 6 vlans with various modes - unconfigured, auto, static, dhcp
<frobware> dimitern, do you still see the 120s wait if you have an alias?
<dimitern> once it comes up I'll try the script on the rendered e/n/o
<dimitern> frobware, I haven't seen an improvement there, but also haven't tried with 1.9.0 lately
<frobware> dimitern, looks like it is still present
<frobware> dimitern, if it works, and you have the bandwidth, can juju deploy to that node and also add a container --- and verify that container can do something with the internet
<frobware> dimitern, but not apt-get update.  Too much caching going on there...
<dimitern> sure, I'm first trying the "pure" deployment - no juju involved
<katco> ericsnow: stand up
<dooferlad> frobware: so, what was the reason for not using add-juju-bridge.py from maas-spaces? It looks like we need a bridge per VLAN anyway.
<dooferlad> frobware: it it simply that the rest of our code doesn't handle 1 bridge per NIC?
<frobware> dooferlad, untested
<dooferlad> frobware: so, it may work, but we don't know.
<frobware> dooferlad, seems a fair assessment
<dooferlad> dimitern: ^^
<dooferlad> dimitern: opinions?
<frobware> dooferlad, the trouble I have is I think, in general, the script and how we get it to the node is way better on maas-spaces.
<mup> Bug #1534201 opened: TestHelpAddImage fails <ci> <regression> <test-failure> <windows> <juju-core:New> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1534201>
<dimitern> frobware, so I couldn't even get to the node without juju in play
<frobware> dimitern, oh :(
<dimitern> dooferlad, so the plan is to use the new shiny and better script from maas-spaces on master
<frobware> dimitern, it is?
<dimitern> dooferlad, but not until we're sure it's working properly
<frobware> dimitern, aha.
<natefinch> katco: btw, looks like lxc-clone and lxc-clone-aufs would not do what you'd think in LXD.  They're for when you juju deploy to a lxc container on a machine, not for when the lxd provider creates new machines.
<dooferlad> frobware, dimitern: that bug has been re-targeted to 2.0-alpha2
<frobware> dimitern, dooferlad: so for 1.25 there may be a small fix that we can do there.
<dimitern> frobware, I suspect I went with a bit too wild config of the bond, trying a simpler approach now
<dooferlad> ignore me, that is just one target
<frobware> dimitern, do you time for a quick HO?
<frobware> dimitern, all related to spaces/bond0 and state of tip on maas-spaces.
<katco> natefinch: ah interesting
<dooferlad> dimitern, frobware: but doesn't the siny new script do it right?
<frobware> dooferlad, I was concerned at the magnitude of the change.
<dooferlad> or don't we need a bridge per vlan?
<dimitern> we do
<dimitern> if we need containers on those vlans
<dimitern> frobware, well, considering my devices tests have stalled yet again due to gomaasapi limitations, sure - let's HO
<frobware> great
<frobware> I'm a bit broke too
<cherylj> frobware: did you see my question in bug 1532354?
<mup> Bug #1532354: Juju 1.26-Alpha4 reports incorrect public-address with MaaS 1.9 <juju-core:New> <https://launchpad.net/bugs/1532354>
<mup> Bug #1534011 changed: ~/.juju/credentials.yaml permissions should be 600 <juju-core:Invalid by wallyworld> <https://launchpad.net/bugs/1534011>
<mup> Bug #1534214 opened: Juju KVM container doesn't respect constraints <juju-core:Triaged> <https://launchpad.net/bugs/1534214>
<ericsnow> katco: you want to keep pairing?
<katco> ericsnow: definitely... give me a few mins
<ericsnow> katco: np, just ping me
<katco> ericsnow: will do
<ericsnow> katco: I'll be in moonstone
<mup> Bug #1488166 changed: Service with just one unit left which doesn't think it's the leader <landscape> <leadership> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1488166>
<frobware> cherylj, have added a comment to the bug.
<cherylj> thanks, frobware!
<cherylj> frobware: I'm updating the release notes for 2.0 and wanted to put in a comment about the default gateway.  Does this work?  "Users on MAAS 1.8 should set the default gateway for network used by juju to avoid problems with container networking".
<cherylj> for THE network used by juju...
<cherylj> I'm not sure what terminology we need to use for that
<frobware> cherylj, I think I would also add a comment about where you can see/validate this in the MAAS UI. "You can verify whether a default gateway has been set on an interface by looking at the network details in the "Networks" tab" - or words to that affect.
<cherylj> frobware: good suggestion, thanks!
<mup> Bug #1532354 changed: Juju 1.26-Alpha4 reports incorrect public-address with MaaS 1.9 <juju-core:Invalid> <https://launchpad.net/bugs/1532354>
<mup> Bug #1534238 opened: juju debug-log fails with 1.26alpha3 and lxd <juju-core:New> <https://launchpad.net/bugs/1534238>
<cherylj> sinzui: you mentioned I could get a windows VM to test the unit test changes.  Could I get one to test the changes for the controller-rename branch?
<cherylj> given my recent history with windows tests...
<sinzui> cherylj: I'll pass you the  connection into in a moment
<cherylj> awesome :)
<perrito666> hey anyone is familiar with debuglogfilesuite?
<natefinch> ...abstractfactorybean?
<cherylj> bogdanteleaga: ping?
<perrito666> well I am not sure what exactly it is testing or in any case why it breaks when log to mongo breaks :p
<cherylj> has anyone done unit tests in a windows system?
<natefinch> cherylj: not recently, but in theory, yes
<cherylj> natefinch: I keep getting this error:  provider\azure\environ.go:18:2: no buildable Go source files in C:\Users\Administrator\ci\gogo\src\github.com\Azure\azure-sdk-for-go\arm\resources
<cherylj> and I did a go get for the sdk
<bogdanteleaga> cherylj: hmm, that does look weird
<bogdanteleaga> I didn't run unit tests for a while, but I do build windows binaries quite often and I never got that
<bogdanteleaga> try deleting $GOPATH/pkg ?
<cherylj> bogdanteleaga: good idea, I'll try that
<cherylj> nope, same issue :(
<bogdanteleaga> do you have files in there?
<natefinch> cherylj: that's because there's no buildable go source files in https://github.com/Azure/azure-sdk-for-go/tree/master/arm/resources
 * natefinch is very helpful ;)
<cherylj> thanks, captian obvious
<cherylj> heh
<perrito666> cherylj: check if the files arent linux only
<natefinch> perrito666: there's no files at all in that folder
<natefinch> click the link I posted
<perrito666> meh why would it try to build that particular thing?
<natefinch> cherylj: did you run godeps?
<cherylj> natefinch: let me set up godeps on this vm
<hatch> is it possible for the detla sent to the GUI via the api to differ from the juju status output? The delta is returning 'pending' but status shows 'error'
<perrito666> yes
<natefinch> cherylj: that's probably the problem. They probably removed what was there in HEAD of master
<perrito666> hatch: that yes was for you
<hatch> perrito666: so is this a bug in juju or...what are we looking at? I've never seen this before
<cherylj> hatch: sorry if I missed it in the scroll back...  what is it that's showing as "pending" / "error"?
<hatch> cherylj: so here is the delta https://gist.github.com/kadams54/1c64a146b416a0639802#file-gistfile2-txt-L307 and here is the status https://gist.github.com/kadams54/1c64a146b416a0639802#file-juju-status-txt
<hatch> so the GUI is displaying the unit as in Pending as per the delta, but it's actually in error...
<perrito666> hatch: in that case I would believe status
<perrito666> and yes, that IS a bug
<hatch> I've never seen this before, another (kadams54) just ran into it in his env
<hatch> this of course breaks the GUI because it can't properly interact with that unit
<hatch> of course I'll gladly file a bug report...what information do you need from the environment for a report for this to be helpful?
<perrito666> hatch: I presume that it hapens in certain cases only
<hatch> yeah - I've never seen this before, didn't think it was even possible :)
<perrito666> the two gists should be enough, plus version of all involved juju pieces
<perrito666> well iirc the code doing the delta and the status is slightly different
<cherylj> I bet there's some aggregation of status reported in 'juju status'
<perrito666> yup, there is some massaging of the data before printing the status
<hatch> alright no problem - so there is probably some work we can do on the GUI side to make the reporting a little more resilient in this case, but I'll file a bug on juju though in the mean time
<hatch> thanks!
<perrito666> glad to not be helpful
<cherylj> heh
<hatch> lol! you were more helpful than you think :)
<perrito666> dont lie to me, you expected a "click here and all be fixed" kind of answer :p
<hatch> haha nah, I was looking for "this isn't possible, look elsewhere for the issue"
<hatch> but since it IS possible
<hatch> I can wash my hands of it lol
<hatch> (of course besides making the gui more resilient)
<cherylj> Can I get a review?  http://reviews.vapour.ws/r/3539/
<cherylj> I reverted a PR, then added back the feature flag definition
<natefinch> cherylj: ship it
<cherylj> natefinch: actually, I might have a real fix, now that I can reproduce the failure on this windows machine
<natefinch> cherylj: cool
<perrito666> whyyy, why dead code paths whyyy
<mup> Bug #1534289 opened: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
<perrito666> yeah, thanks mup, you always find a way to cheer me up
<mup> Bug #1534289 changed: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
<mup> Bug #1534289 opened: tag aws security groups to prevent accidental deletion <juju-core:New> <https://launchpad.net/bugs/1534289>
<katco> ericsnow: your patch lgtm. ready to pair up again?
<ericsnow> katco: sure
<katco> ericsnow: in moonstone
<cherylj> hey bogdanteleaga I'm now running into an issue that you had resolved elsewhere:  2016-01-14 20:30:41 WARNING utils.featureflag flags_windows.go:34 Failed to open juju registry key HKLM:\\SOFTWARE\\juju-core; feature flags not enabled
<cherylj> bogdanteleaga: it's not entirely clear to me what I need to do to fix it
<cherylj> bogdanteleaga: oh, maybe I need to use setUpFeatureFlags?
<mup> Bug #1534296 opened: api delta and juju status differ <juju-core:New> <https://launchpad.net/bugs/1534296>
<cherylj> thumper: I think this PR of yours is causing problems for me now:  https://github.com/juju/juju/pull/3271
 * thumper looks
<thumper> cherylj: tests should never poke the registry
<thumper> there is no reason that tests should do that
<thumper> what exactly is the problem?
<cherylj> thumper: http://reports.vapour.ws/releases/3508/job/run-unit-tests-win2012-amd64/attempt/1800#highlight
<cherylj> caused by Ian's change:  https://github.com/juju/juju/pull/4093
<thumper> cherylj: yeah, that is just bad...
<thumper> the testing of the flag setting should be independent of the main
<thumper> however everything is just shoved together in a single file
<thumper> cherylj: my suggestion at this stage is to file a bug, and skip the test on windows as long as the windows feature flag setup is done right
<thumper> the longer job is testing it properly
<thumper> we don't do this type of testing in other places
<thumper> because it impacts an external resource - the windows registry
<cherylj> thumper: what I've tried to do is separate out the init() into a main_nix.go and main_windows.go  and set the flags appropriately there
<cherylj> each has a main() that just calls Main()
<thumper> changing the windows registry during tests can cause independent juju commands to fail
<cherylj> is that correct?
<thumper> that'll work
<cherylj> ok, thanks
<bogdanteleaga> iirc, the tests created some random key in the registry that is not used by juju
<bogdanteleaga> oh, I was thinking about different tests
<cherylj> bogdanteleaga: how do I set feature flags on windows (and can I do it from cygwin cli?)
<bogdanteleaga> are you trying to do it for running juju or for tests?
<cherylj> for running a command
<bogdanteleaga> I think tests will just recognize environment variables
<cherylj> for manually running a juju command
<bogdanteleaga> that's $env:variable = something
<cherylj> thanks!
<bogdanteleaga> might be without space
<bogdanteleaga> in powershell at least
<bogdanteleaga> I think cygwin just does it the bash way
<cherylj> ah, then I'll give that a try
<bogdanteleaga> if not you might have to create the key in registry
<bogdanteleaga> that is, have JUJU_DEV_FEATURE_FLAGS in HKLM:\SOFTWARE\juju-core with csv of flags
<cherylj> okay, I give up for now.  I'm still getting that error when I run the tests, even when I skip the ones that set the feature flag
<cherylj> I'm reverting Ian's patch and he can deal with it later, or I'll do it later
<cherylj> mgz: has there been another os deployer run with the ceilometer failure we need to look at?
<cherylj> sinzui: the revert is merging now.  I confirmed the tests pass on windows again
<sinzui> cherylj: okay. I see perrito666's branch will finish soon
<bogdanteleaga> cherylj: I looked a bit at it now
<bogdanteleaga> it should have nothing to do with registry
<bogdanteleaga> only jujud loads variables from the registry
<bogdanteleaga> tbh, I'm not sure what the problem is, the only strange thing is that juju home is added with key=value to the env and the feature flags are only added with value
<bogdanteleaga> (inside badrun in the file with errors)
<jw4> perrito666: Thanks, loving my new beverage: https://www.dropbox.com/s/l1edd4huooft8lu/2016-01-14%2011.55.55.jpg?dl=0
<thumper> davecheney: ping
<davecheney> thumper: ack
<thumper> davecheney: I have worked around my problem, but still don't entirely understand it
<thumper> I was trying to write a custom YAML marshaller for time.Time
<davecheney> mmm
<thumper> that was smarter around IsZero
<thumper> but the unmarshal function never got called and yaml just errored out
<thumper> not sure why
<thumper> but now I'm just using time.Time
<davecheney> T vs *T
<davecheney> ?
<thumper> I copied from version.Number
<davecheney> why not teah yamk to handke times directly
<thumper> because gopkg yaml
<thumper> also was using omitempty
<davecheney> yeah, borlerline impossible to land that change
<thumper> but that didn't work with time.Time either
<thumper> so now using *time.Time in the yaml struct
<thumper> and converting at the boundaries
<thumper> using time.Time.IsZero()
<davecheney> oh well
<thumper> yeah, just futzing around
<perrito666> Jw4 glad you like, and that you could get one
<jw4> :)
<mup> Bug #1531932 changed: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
<mup> Bug #1534353 opened: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
<cherylj> hey natefinch, the idea with bug 1511659 / http://reviews.vapour.ws/r/3536/ was to see if you could take it over - try and recreate / verify the fix and get it merged
<mup> Bug #1511659: Destroyed leader, new leader not elected. <bug-squad> <leadership> <sts> <juju-core:Triaged by fwereade> <juju-core 1.25:Triaged by fwereade> <https://launchpad.net/bugs/1511659>
<cherylj> natefinch: do you have the bandwidth to do that?
<mup> Bug #1534353 changed: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
<mup> Bug #1531932 opened: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
<katco> cherylj: yes he does; that was what i communicated to him
 * thumper crawls back under his rock with the laptop
<cherylj> thanks, katco!
<mup> Bug #1531932 changed: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Won't Fix by dooferlad> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1531932>
<mup> Bug #1534353 opened: Wrong command displayed when trying to destroy a controller with destroy-environment <juju-core:Triaged> <https://launchpad.net/bugs/1534353>
<cherylj> sinzui: It looks like it failed the openstack check because juju deployer couldn't run status
<cherylj> 2016-01-14 16:27:12 Error getting status, is it bootstrapped?
<cherylj> 2016-01-14 16:27:12 Command (juju status --format=yaml -e maas-1_8-OS-deployer) Output:
<cherylj>  <blank lines>
<perrito666> axw: anastasiamac not making it to the standup, will mail later
<cherylj> I wonder if it is trying to use a different juju than what's been built for the test?
<axw> perrito666: okey dokey
<anastasiamac> perrito666: ok \o/
<sinzui> cherylj: ohh...could the script be assuming a jenv? I expect a call to Juju to work because JUJU_HOME is exported to a unique path
<cherylj> sinzui: that's exactly what I was thinking
<cherylj> sinzui: juju-ci-openstack-check.sh:export OS_AUTH_URL=${OS_AUTH_PROTOCOL:-http}://`juju-deployer -e $1 -f keystone`:5000/v2.0
<cherylj> and we can see by the output that the juju-deployer call fails
<sinzui> cherylj: The current job we are watching has its JUJU_HOME set to ~/cloud-city/jes-homes/maas-1_9-OS-deployer
<cherylj> sinzui: I bet it's using an older juju and looking for a jenv
<cherylj> in that juju home
<cherylj> sinzui: I gotta run to dinner with the family.  bbl
<sinzui> cherylj: The path is also exported...well should be if the script is run using the jujupy lib
<sinzui> cherylj: good news the health check bypasses to env var we setup. Once I start dinner, I will change the script toensure JUJU_HOME and PATH are honoured.
<katco> ericsnow: oauth kicked me out, brt
#juju-dev 2016-01-15
<anastasiamac> menn0: ping
<anastasiamac> tanzanite was planning to do the renaming of all env to model once controller-rename branch gets into master
<menn0> anastasiamac: pong
<menn0> anastasiamac: how were you going to handle things like DB collections?
<menn0> anastasiamac: and what about API names?
<anastasiamac> menn0: we have not gotten to the point of actually discussing it yet as controller-rename branch is still pending in limbo somewhere...
<menn0> anastasiamac: ok np
<anastasiamac> menn0: i suspect that we will have a brief next week where we'll discuss the approach
<anastasiamac> menn0: i'd love to get anyone who is interested involved
<anastasiamac> (u sound like one)
<anastasiamac> involved in discussion that is :D
<menn0> anastasiamac: would you mind replying to my email then... if there's going to be a major rename effort so that "environment" goes away completely then I'm fine with using "model" everywhere
<menn0> anastasiamac: I think the rename is going to be hard to get right
<anastasiamac> menn0: k. and I agree.... hence i think we should brain-storm before we dive into actual rename \o/
<menn0> anastasiamac: but if anyone can do it it's your squad :)
<anastasiamac> wot?!
<menn0> anastasiamac: I'm happy to participate in the discussion and planning
<anastasiamac> i think with onyx's experience and the lessons learnt from controller-rename, ur squad is very well positioned to do it ;D
<anastasiamac> awesome!
<menn0> anastasiamac: onyx has been banned from working on anything but model migrations
<menn0> anastasiamac: but since this affects model migrations I think we can at least be involved in the discussion
<anastasiamac> menn0: k. xross-squad pairing sounds awesome :D
<menn0> sure :)
<menn0> probably not going to happen though
<anastasiamac> :( i can dream
<anastasiamac> i have a dream?...
<menn0> :)
<davecheney> cherylj: chasing this https://bugs.launchpad.net/juju-core/+bug/1534394
<mup> Bug #1534394: trusty/i386 test failure <juju-core:New> <https://launchpad.net/bugs/1534394>
<cherylj> davecheney: I think that waigani already fixed that bug.
<cherylj> bug 1532777
<mup> Bug #1532777: undertakerSuite.TestEnvironConfig fails <blocker> <ci> <regression> <unit-tests> <juju-core:Fix Committed by waigani> <https://launchpad.net/bugs/1532777>
<cherylj> davecheney: the current things we're blocked on may be CI test issues.  So at this point, I don't have specific bugs for you.
<cherylj> we will need some help with wily / xenial unit tests on 1.25 as we're extending its support for a while
<cherylj> but I've been focused on 2.0-alpha1 right now and don't have a list of those bugs yet
<cherylj> davecheney: so I don't need you right now.
<cherylj> was that rambling enough?
<mup> Bug #1534394 opened: trusty/i386 test failure <juju-core:New> <https://launchpad.net/bugs/1534394>
<davecheney> cherylj: noted
<davecheney> i'll move on to something else
<ericsnow> katco: crickets
<mup> Bug #1534394 changed: trusty/i386 test failure <juju-core:New> <https://launchpad.net/bugs/1534394>
<mup> Bug #1534480 opened: LXD: bootstrap error: no registered provider <juju-core:New> <https://launchpad.net/bugs/1534480>
<mup> Bug #1534511 opened: Support for multiple apt sources and apt keys in isolated environments <cpe> <stakeholder> <juju-core:New> <https://launchpad.net/bugs/1534511>
<frobware> dimitern, voidspace, dooferlad: will be 10-15 mins late for standup.
<dooferlad> frobware: I am happy to start late
<dooferlad> frobware: ping us when you are ready?
<dimitern> sure
<frobware> dimitern, voidspace, dooferlad: ready
 * dooferlad joins hangout
<voidspace> omw
<voidspace> dimitern: frobware: dooferlad: still need a review by the way: http://reviews.vapour.ws/r/3534/
<mup> Bug #1534480 changed: LXD: bootstrap error: no registered provider <juju-core:Invalid> <https://launchpad.net/bugs/1534480>
<voidspace> frobware: dimitern: dooferlad: so in the merge provider/maas/environ.go is fairly screwed
<voidspace> this is becauase a bunch of code was broken out into separate files on maas-spaces
<voidspace> but fixes applied to master (for default gateway stuff)
<mgz> bless on controller-rename btw
<voidspace> frobware: dimitern: dooferlad: coffee
<voidspace> dimitern: frobware: dooferlad: still need a review by the way: http://reviews.vapour.ws/r/3534/
<frobware> voidspace, ack
<voidspace> dimitern: frobware: dooferlad: my merge branch now compiles, except for the tests
<voidspace> which are still pretty screwed
<frobware> voidspace, nice
<voidspace> as soon as they compile I can see what's broken
<voidspace> I'm worried that fixes that landed on master in code that was extracted into separate files on maas-spaces might get lost
<voidspace> that's the biggest danger
<voidspace> *hopefully* the tests will pick that up
<voidspace> but tests got moved too
<voidspace> so it'll need a good review to make sure we haven't lost fixes in the merge
<cherylj> can I get a review?  http://reviews.vapour.ws/r/3546/
<cherylj> It's a quick one
<mup> Bug #1521777 changed: Allow for upgrades to 2.0 <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1521777>
<dimitern> voidspace, you've got a review btw
<perrito666> lazyPower: ping
<voidspace> dimitern: cool - thanks
<voidspace> dimitern: ah, I didn't know about the "if !c.Check(...) {continue}" trick
<voidspace> dimitern: that's why I wasn't using check in that loop
<voidspace> thanks
<dimitern> voidspace, :) yeah - it's useful
<frobware> dimitern, voidspace, dooferlad: let's use https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<voidspace> frobware: really?
<voidspace> I'm already in the one you linked to
<voidspace> ah well.
<voidspace> omw
<frobware> voidspace, ah, sorry. I tried to change it to that but the juju-sapphire URL but it obviously didn't work.
<dimitern> frobware, omw, 2m
<lazyPower> perrito666 pong
<mgz> cherylj: lgtm
<cherylj> thanks, mgz
<natefinch> chery, sorry I missed your emssage last night. Yes, that's what I'm doing now.  Trying to repro with the steps in the bug.  I reviewed fwereade's patch, which looks pretty sane... but I haven't been able to reproduce the bug yet, so it's hard for me to tell if the fix will fix it.
<natefinch> cherylj: ^
<cherylj> natefinch: thanks for the update!
<mgz> oh, I thought we were all calling her 'chery' now...
<mup> Bug # opened: 1534610, 1534619, 1534620, 1534623
<mup> Bug #1534626 opened: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 opened: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<perrito666> lazyPower: sorry I solved itt myself, thank you anyway
<lazyPower> ah bueno perrito666  :)
<perrito666> that is pretty much like throwing a wrench into my brain gears
<perrito666> I was considering for a moment what channel was this
<mup> Bug #1534626 changed: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 changed: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug #1534626 opened: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 opened: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug #1534626 changed: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 changed: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug #1534626 opened: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 opened: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug #1534626 changed: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 changed: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug #1534626 opened: provisionerSuite.SetUpTest fails because connection reset <ci> <intermittent-failure> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1534626>
<mup> Bug #1534627 opened: Destroyed models still show up in list-models <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
<mup> Bug # opened: 1534632, 1534636, 1534637, 1534643
<mup> Bug # changed: 1534632, 1534636, 1534637, 1534643
<mup> Bug # opened: 1534632, 1534636, 1534637, 1534643
<cherylj> can I get another easy review?  http://reviews.vapour.ws/r/3549/
<natefinch> cherylj: ship it
<cherylj> thanks, natefinch!
<natefinch> katco, ericsnow: someone needs to make a "let me man pages that for you"
<natefinch> fwereade: I don't suppose you have a test charm that exercises leadership?
<lazyPower> natefinch: i have one
<mup> Bug #1534757 opened: Attempting to run charm before unit provisioned, 1.26 <juju-core:New> <https://launchpad.net/bugs/1534757>
<natefinch> lazyPower: I actually figured out that I don't need a special charm... every charm gets a leader, most charms just don't care :)
<natefinch> lazyPower: so I can just use a dummy charm and juju run is-leader on it, and that's sufficient for my purposes :)
<beisner> mgz, cherylj - still re-confirming, but two bootstrap attempts with 1.25.2 + 1.9 give me a bootstrap timeout.  the machine comes online, maas state is deployed.  it's reachable for a bit, then no-talky from then on.  http://pastebin.ubuntu.com/14506872/
<mgz> beisner: thanks
<mgz> beisner: what does maas say about it?
<beisner> mgz from maas perspective, it is "deployed"
<beisner> i've backed out to 1.25.0, same procedure, same maas, bootstraps ok
<beisner> i suspect juju bridge foo is the moment we lose network
<beisner> unfortunately, i can't inspect the aftermath b/c i can't reach it.  i've got SOL / ipmi, and can see that it is up at the login screen.  but of course no user/pwd login enabled.
<mgz> can you ssh in parallel when it's installing and stuff and hold that connection?
<mgz> I'd be interested to see logs/networking config changes on the box
<beisner> me too.  i shall keep trying.    do you have 1.9 maas that you can try a bootstrap against?
<mgz> beiser: see http://reports.vapour.ws/releases/3511/job/maas-1_9-OS-deployer/attempt/181
<mgz> log in with sso and go to that page
<mgz> that's our result for 1.25.2 on maas 1.9 deploying your trusty-liberty bundle
<beisner> mgz, that's using 1.25.3
<beisner> i'm using 1.25.2 from ppa:juju/proposed, plus agent-stream: proposed
<mgz> ah, whoops, wrong rev, go back to /releases/3506 and attempt/163
<mgz> which is the same code, though not literally the same binaries
<mgz> our maas is certainly not your maas though
<mgz> beisner: I'm presuming you don't have any of the feature flags on as well?
<beisner> mgz right, just as a vanilla new user
<beisner> ok, i'll fire off a fresh bootstrap with 1.25.2 and see if i can sneak onto that unit before it goes lalalala
<mgz> as soon as it starts the apt installing stuff you should be good, note you'll want the same ssh key/juju env key available
<beisner> ha.  i got this seconds before the first reboot.  http://pastebin.ubuntu.com/14507351/    /me watches closely...
<beisner> ok mgz.  i had a total of ~10s of reachability, then unreachable.  i did establish ssh in that window, did another `ip a` and got as far as the b in `brctl show` when it cut me off:
<beisner> http://pastebin.ubuntu.com/14507430/
<beisner> so before maas' first reboot, sane.
<beisner> after maas' first reboot, sane.
<beisner> after juju init stuff, no connectivity.
<perrito666> oh great someone did the same I was doing
<mgz> so, session did get cut off, that pretty much does mean this is a interface reconfiguration
<katco> natefinch: planning
<natefinch> katco: oops, coming
<mgz> beisner: I think we need a bug to track. probably want maas network output included.
<beisner> mgz, yep i'm raising one now.
<frobware> beisner, can I give you a binary that would allow console login
<beisner> frobware, yes please & thx
<frobware> beisner, you would obviously have to bootstrap with --upload-tools
<beisner> fyi:  bug 1534795
<mup> Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:New> <https://launchpad.net/bugs/1534795>
<beisner> frobware, ack
<frobware> beisner, ok give me 10-15mins - will verify locally
<beisner> thx frobware
<beisner> mgz, frobware - good news:  in our openstack-provider automation, things are looking good so far :)
<frobware> beisner, so any clue as to why the other setup is borked? different MAAS setup?
<beisner> frobware, two different providers.
<mgz> frobware: using the maas provider rather than openstack provider
<frobware> beisner, on the MAAS side what's the network config look like? VLANs? Bonds? straight-forward eth0?
<frobware> beisner, and version of MAAS?
<beisner> maas:  1.9.0+bzr4533-0ubuntu1~trusty1
<beisner> juju:  1.25.2-0ubuntu1~14.04.1~juju1
<frobware> beisner, ack
<beisner> frobware, eth0, untagged
<frobware> beisner, so as vanilla as it gets.... sigh.
<frobware> beisner, amd64?
<beisner> yep amd64
<frobware> beisner, just checking. ;-)
<beisner> frobware, yep, np
<frobware> beisner, what's the easiest way to get binaries to you?
<beisner> i've used our private chinstrap in the past for that.  i've not used the new private-fileshare bits yet, though we can try that.
<beisner> frobware ^
<frobware> beisner, any other interfaces or just eth0?
<mup> Bug #1534795 opened: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:New> <https://launchpad.net/bugs/1534795>
<beisner> frobware, machine has 4 nics, only eth0 and eth1 are cabled up.  we've only ever used eth0 on these particular machines.
<beisner> frobware, mgz:  oo interesting ... note that on my 2nd paste in the bug, eth1 is up for some reason.
<beisner> that is unexpected
<frobware> beisner, http://178.62.20.154/~aim/juju-bin.tar.bz2
<frobware> beisner, that's 1.25.2 but before juju has a little play with /e/n/i is does `passwd -d ubuntu' - so you should be able to login on the console.
<frobware> mgz, ^^
<mgz> frobware: thanks for helping out
<beisner> thx, grabbing the bin now frobware
<frobware> mgz, beisner: I'm very tempted to make that a capability behind a flag... as we run into it too often and it's difficult to diagnose once it goes wrong.
<frobware> mgz, beisner: the issue of course is security
<beisner> that would be a good t-shooting tool indeed.   but yep, that.
<frobware> beisner, I just tried with two NICs configured and it bridged eth0 OK
<beisner> frobware, so i have two nics CONNECTED, but not two nics configured.
<beisner> frobware, ie.  http://pastebin.ubuntu.com/14508207/
<frobware> beisner, so when I say configure, in MAAS 1.9 parlance, they're configured and both have static ip assignment when looking in the MAAS UI
<beisner> yet eth1 winds up UP
<beisner> frobware, https://launchpadlibrarian.net/234276622/network.png
<frobware> beisner, let's see what happened to e/n/i once you bootstrap and can login
<frobware> beisner, but I see no smoking gun there
<beisner> frobware, \o/  i'm in via ipmi
<beisner> sol that is
<beisner> with that bin
<frobware> beisner, the binary I sent you didn't work?
<beisner> frobware, yes.  it let me log in with ubuntu.  now poking around in it.
<beisner> frobware, eth0 is down;  eth1 is up;  no bridges.  no ipv4 addresses.
<beisner> grabbing /etc, /var/log, anything else?
<frobware> beisner, can you send me /etc/network/interfaces*
<mup> Bug #1534804 opened: debug-log is unstable with LXD local provider <docteam> <juju-core:New> <https://launchpad.net/bugs/1534804>
<frobware> beisner, and capture ip route
<frobware> beisner, is is possible to HO?
<beisner> frobware, https://plus.google.com/hangouts/_/canonical.com/andrew-mcdermot?authuser=1
<beisner> wow `ip route` blank
<beisner> that's a new one
<frobware> beisner, in there
<frobware> beisner, mgz: http://pastebin.ubuntu.com/14509474/
<beisner> frobware, added tarball to bug. woot.  thx again for your help.  & mgz
<frobware> beisner, mgz: I know exactly what the bug is.
<frobware> beisner, mgz: fixed in maas-spaces, doesn't help... however, we ran into the same issue a week ago on maas-spaces - and we had not seen it there for > 1 month. Something changed upstream so that we get dns-nameserver entries partwya through /e/n/i and we don't parse that correctly.
<perrito666> :| ubuntu does not define xdg_config_home ?
<beisner> frobware, excellent.  and yep, i'll do a maas non-juju deploy of that machine and collect the same in a bit.
<frobware> beisner, pretty sure you won't need to do that. uploading a new binary for you to try.
<frobware> beisner, I'll leave the `passwd -d ubuntu' in just to help out.
<frobware> beisner, I still don't understand why my MAAS setup doesn't give me the same dns-nameserver entries other people get.
<cherylj> frobware: I'm really happy you're still up to look at this :)  I saw the bug report while at the doctor's office
<frobware> beisner, http://178.62.20.154/~aim/juju-bin.tar.bz2
<frobware> beisner, md5sum a2d16e6f3993cc56e7c998aadfe48b74
<beisner> frobware, thx.  will grab and run it shortly
<frobware> cherylj, https://bugs.launchpad.net/juju-core/+bug/1534795/comments/7
<mup> Bug #1534795: unit loses network connectivity during bootstrap: juju 1.25.2 + maas 1.9 <maas-provider> <uosci> <juju-core:Confirmed for frobware> <https://launchpad.net/bugs/1534795>
<frobware> cherylj, https://bugs.launchpad.net/juju-core/+bug/1534795/comments/8
<frobware> beisner, see my updates to the bug ^^
<cherylj> frobware: thanks so much!
<beisner> frobware, cherylj - cycling now.  it's progressed to pkg installation and maintained connectivity thus far \o/
<frobware> beisner, great. I would really appreciate if you could try it again with http://178.62.20.154/~aim/juju-bin-lp1534795.tar.bz2 as this is a build from the proposed PR.
<frobware> beisner, I'll hang around for 10-15 mins to hear your "BOOTSTRAPPED!" message. :)
<frobware> cherylj, beisner: the only thing I would point out about my binary build is it is based on the tip of 1.25... not the 1.25.2 tag. Caveat Emptor!
<katco> ericsnow: natefinch: what was your alternative proposal for "juju charm --resources"?
<natefinch> katco, ericsnow: anything else
<natefinch> katco, ericsnow: uh... maybe just charm-resources?
<ericsnow> natefinch: I actually think it fits well, even if it requires a new juju sub-command
<natefinch> ericsnow: I can't abide adding a new subcommand that doesn't do anything, just so it can have a flag that does something.  That's terrible.
<ericsnow> katco, natefinch: yeah, ideally charm-resources
<katco> ericsnow: natefinch: ok, i'll float the suggestion. it's entirely possible that we intend to expand on the charm command
<natefinch> katco: I'd be fine with it if juju charm was a command that was goign to do other things.... though I'm generally against using flags to do completely different things... that's what subcommands are for
<natefinch> katco: so like, if juju charm cs:foo gave you generic info about the charm, and juju charm --resources gave you info about the charm's resources, that's cool
<perrito666> please dont add an empty command, that is counter intuitive
<katco> perrito666: we're fighting it
<perrito666> charm-resources sounds a bit less painful
<perrito666> my kingdom for an unblocked master
<natefinch> ditto
<beisner> frobware, 0          started 1.25.2.1 fat-machine.dellstack
<katco> perrito666: natefinch: it's not going to unblock until cherylj decides we're good for stabilizing 2.0-alpha1: http://pad.lv/1533750
<natefinch> looks like just this left: https://bugs.launchpad.net/juju-core/+bug/1534201
<mup> Bug #1534201: TestHelpAddImage fails <ci> <regression> <test-failure> <windows> <juju-core:In Progress by cherylj> <https://launchpad.net/bugs/1534201>
<cherylj> yeah, I need to add back in the feature flag without breaking windows
<anastasiamac> cherylj: it's staurday here but.. i can look at it at my monday
<anastasiamac> cherylj: did u get a chance to progress this bug?
<frobware> beisner, that's booted OK then?
<natefinch> later all, dinner time
<cherylj> anastasiamac: I haven't yet.  going to this evening
<cherylj> anastasiamac: did you have anything to hand off?
<mup> Bug #1532777 changed: undertakerSuite.TestEnvironConfig fails <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1532777>
<anastasiamac> cherylj: k.. keep me posted
<anastasiamac> cherylj:  jsut an idea on how to fix it from tim...
<anastasiamac> cherylj: the fundamental problem is tests should not touch external singleton resources, such as the windows registry
<cherylj> yeah...
<anastasiamac> cherylj: this is why all the tests use the environment for feature flags
<anastasiamac> cherylj: i suspect that the base test suite for these commands needs to be re-written
<anastasiamac> cherylj: but i was going to see if i can re-run juju tests on my wndows
<anastasiamac> cherylj: and had trouble getting it going
<mup> Bug #1532777 opened: undertakerSuite.TestEnvironConfig fails <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1532777>
<cherylj> anastasiamac: yeah, thanks to sinzui, I have a windows machine I can use for unit tests
<anastasiamac> cherylj: \o/
<perrito666> oh, blessed master
<anastasiamac> cherylj: neeed to go to have a weekend :/ will check back in on monday and pick it up if needed
<sinzui> cherylj: master is reightfully bless. I parused CI because I am looking to move some jobs to other public clouds since Joyent hasn't fixed the firewall yet
<beisner> frobware, yessir
<cherylj> thanks anastasiamac!  have a good weekend!
<anastasiamac> cherylj: thanks \o/ you as well!
<frobware> beisner, excellent.
 * frobware is gone gone gone!
<cherylj> thanks, frobware!
<mup> Bug #1532777 changed: undertakerSuite.TestEnvironConfig fails <blocker> <ci> <intermittent-failure> <regression> <test-failure> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1532777>
<perrito666> oh great, juju home is not defined by a single source of truth
<beisner> cherylj, frobware, mgz - ok i'm eod + eow.  off monday, US holiday.   i can commit to cycling the 3rd bin (http://178.62.20.154/~aim/juju-bin-lp1534795.tar.bz2) at some point this weekend and chiming in on the bug with how that went.
<cherylj> thanks, beisner!
<perrito666> ok, this got into my nerves, EOW
<beisner> yw, cherylj    o/  have a nice weekend, all
#juju-dev 2016-01-16
<mup> Bug #1534923 opened: Juju needs to be able to specify floating ip pool  <juju-core:New> <https://launchpad.net/bugs/1534923>
<mup> Bug #1534307 opened: juju-metadata plugin tests are currently being skipped on Windows <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1534307>
#juju-dev 2016-01-17
<mup> Bug #1535019 opened: juju destroy-environment not deleting security groups on aws/ec2 <juju-core:New> <https://launchpad.net/bugs/1535019>
<mup> Bug #1535019 changed: juju destroy-environment not deleting security groups on aws/ec2 <juju-core:New> <https://launchpad.net/bugs/1535019>
<mup> Bug #1535019 opened: juju destroy-environment not deleting security groups on aws/ec2 <juju-core:New> <https://launchpad.net/bugs/1535019>
<mup> Bug #1535019 changed: juju destroy-environment not deleting security groups on aws/ec2 <juju-core:New> <https://launchpad.net/bugs/1535019>
<mup> Bug #1516977 changed: juju upgrade-juju should guess version number <juju-core:Expired> <https://launchpad.net/bugs/1516977>
<axw> anastasiamac: I can't make standup, will email
<anastasiamac> axw: k. i won't standup either then and will reply to urs \o/
#juju-dev 2017-01-09
<redir> One last PR up. Also easy. And I am going EoD.
<redir> laters
<blahdeblah> thumper: did you see my ping in $OTHERIRC?
<blahdeblah> Anyone else around to assist with https://bugs.launchpad.net/juju-core/+bug/1484105/comments/18 in thumper's absence?
<mup> Bug #1484105: juju upgrade-charm returns ERROR state changing too quickly; try again soon <bug-squad> <canonical-is> <upgrade-charm> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1484105>
<anastasiamac> blahdeblah: \o/
<anastasiamac> that sounds like a fun exercise :D
<blahdeblah> anastasiamac: You have a rather warped definition of fun. ;-)
<blahdeblah> But I'll take all the help I can get :-)
<anastasiamac> blahdeblah: not sure what I can do in addition to thumper's suggestion
<thumper> blahdeblah: sorry, back now
<hoenir> can anyone explain why I'm seeing in constraints/constraints.go instance/instance.go the same functions ? like for example parseUint64 ?
<hoenir> (branch develop)
<hoenir> anyone?
<perrito666> morning
<voidspace> rick_h: frobware: jam: macgreagoir: I have an appointment to have my ears syringed - so I will miss first standup I'm afraid
<frobware> voidspace: k
<frobware> voidspace: i had it done last year & was a blessing...
<voidspace> frobware: great
<perrito666> frobware: I get it done every year :)
<perrito666> voidspace: be prepared for a couple of hours of super hearing
<voidspace> haha
<voidspace> perrito666: frobware: I jammed up my ears trying to clean them, I've spent the last week feeling like I'm underwater...
<perrito666> voidspace: its terrible, I actually did that a couple of times and was dizzy for a week
<frobware> voidspace: I want 27 days. It was horrendous.
<frobware> went
<perrito666> the doctor told me I produce too much wax so I just need to go every year
<voidspace> yeah, my Dad has to do it every year.
<voidspace> I've only had to do it once before
<hoenir> so guys anyone has any clue why there is dupplicated code?
<voidspace> frobware: perrito666: so there was no wax at all in my ears, which is bad news - because it means the hearing problem (according to the nurse) is probably due to blocked "station tubes" *behind* the eardrum
<voidspace> frobware: perrito666: decongestant can help, but it can take up to a month for them to clear...
<frobware> voidspace: :(
<voidspace> frobware: well, it certainly could be worse! A mild annoyance anyway.
<frobware> voidspace: my right ear was completely blocked for ~1 month. I could not hear anything and when it was unblocked... wow! Stereo! :)
<voidspace> frobware: nice, almost worth it... almost.
<frobware> voidspace, macgreagoir, jam: a trivial PR - https://github.com/juju/juju/pull/6786
<voidspace> frobware: looking, sorry
<redir> hello juju-dev
<perrito666> hello redir
<redir> :)
<rogpeppe> natefinch and anyone else that's interested: this updates godeps so that it always calculates dependencies for all known architectures and OS's: https://github.com/rogpeppe/godeps/pull/6
<rogpeppe> interestingly, it already bowled out one extra dependency - when compiled with GOARCH=solaris, juju depends on golang.org/x/sys
<perrito666> rogpeppe: amazing work, tx for that
<rogpeppe> perrito666: it's been a while in coming, i'm afraid :)
<rogpeppe> perrito666: i only just realised that i needed to bite the bullet and fork go/build
<rogpeppe> perrito666: your approval on the PR would be appreciated BTW
<perrito666> rogpeppe: approved, do know that this pr makes me very happy, will be able to use it for my own project too
<rogpeppe> perrito666: cool, thanks
<perrito666> rogpeppe: no, thank you
<rogpeppe> perrito666: another godeps change you might like: https://github.com/rogpeppe/godeps/pull/8
<rogpeppe> anyone want to give it a review? dead simple change. redir voidspace frobware https://github.com/rogpeppe/godeps/pull/8
<redir> rogpeppe: looking
<rogpeppe> redir: ta
<redir> rogpeppe: requested changes made to https://github.com/juju/juju/pull/6782 FWIW
<rogpeppe> redir: thanks - just came across that PR randomly this morning, sorry for the drive-by review :)
<redir> np
<redir> it was useful
<redir> LGTM rogpeppe
<rogpeppe> redir: tyvm
<redir> perrito666 natefinch I have a couple easy PRs in the queue, if you've got a few minutes
<natefinch> redir: sure
<redir> did reviewboard suddenly reappear?
 * redir needs more caffeine
<redir> brb
<redir> backk
<natefinch> rick_h: just a clarification, you're saying I shouldn't work anymore on the interactive bootstrap stuff, right?
<lazyPower> hey nate, can i poke you for clarification on something?
<natefinch> lazyPower: no
<natefinch> :D
<natefinch> yes of course :0
<natefinch> :)
<lazyPower> natefinch - i've got a customer deployment thats exhibiting really weird behavior. The unit didn't request termination on an attached subordinate, and its locked in the stopping state
<natefinch> oy
<lazyPower> i attached via debug-hooks and cycle the unit agent and it never seems to attach, it'll cycle between lost and (stop)
<lazyPower> but never actually intercept the hook context with debug-hooks
<lazyPower> i have no idea how this happened, what should i collect to help file a bug that is meaningful to your team?
<natefinch> mainly logs for the machine and unit
<rick_h> natefinch: yes, that's correct.
<jcastro> hi, I'm trying to use juju show-status-log but the help is confusing
<jcastro> juju help show-status-log --model "koi:conjure-up"
<jcastro> error: flag provided but not defined: -m
<jcastro> I am trying to find the status log of an etcd unit
<jcastro> the help says:     Model to operate in. Accepts [<controller name>:]<model name>
<jcastro> sorry I mispasted the wrong command, the actual error is missing entity name
<redir> jcastro: juju show-status-log etcd/0 ?
 * redir lunches
<lazyPower> did the behavior of juju remove-application change to no longer take the subordinates that are related to the application with its principal during teardown?
<thumper> morning folks
<nurfet> I am testing implementation of a new cloud provider. What's the best way to provide source image and tools?
<lazyPower> Mornin thumper
<thumper> lazyPower: sup?
<thumper> nurfet: as long as the version of the local juju is bigger than any published tools, the local tools will be used
<thumper> nurfet: using the standard cloud images for ubuntu server is probably best
<thumper> perrito666, redir, anastasiamac: can we do the standup earlier?
<perrito666> thumper: sure, when?
<perrito666> thumper: where in the world are you?
<thumper> perrito666: I'm in NZ
<thumper> not in CT
<thumper> but since axw isn't around until Thursday
<thumper> I was hoping to move things a bit earlier so I can make my lunchtime BJJ classes :)
<perrito666> I can do whenever you want
 * thumper thinks anastasiamac is probably having breakfsat
<thumper> redir: still need reviews?
<redir> prolly
<redir> thumper: looks like it
<thumper> redir: I'll take a look
<thumper> redir: can you do an earlier standup?
<redir> thumper: tyvm
<redir> thumper:
<redir> how much earlier?
<nurfet> thumper: my dev version is 2.0.1. Should I increase it?
<redir> I mean yes, but I'm about to reach out to someone and may be on a hangout for a bit
<thumper> nurfet: yes
<thumper> redir: probably not for an hour at least
<thumper> it is 7am ish in Brisbane
<redir> thumper: OK. I also have someone coming to provide an estimate on tree pruning.
<perrito666> thumper: we can accidentally phone anastasia :p
<thumper> nurfet: merge in the devel branch from github.com/juju/juju
<thumper> redir: ack
<redir> but I just need to let them in the garden
<redir> so I can do it whenever.
<thumper> nurfet: or just make it after 2.1
<thumper> nurfet: I *think* devel has 2.2-alpha1
<nurfet> thumper: for now, I'll just make it after 2.1
<thumper> nurfet: ack
<nurfet> that's a good info
<nurfet> thumper: I am also puzzled about tools json file. It should be alike index.json for my local testing?
<thumper> don't worry about it, it won't be used if your version is higher
 * anastasiamac finished breakfast
<anastasiamac> thumper: when do u want to stand up?
<thumper> how about in 14 minutes?
<thumper> redir, anastasiamac, perrito666: ^^^
<anastasiamac> thumper: k
<katco> anastasiamac: hallo! do you know if wally is out today?
<anastasiamac> katco: he is in cape town :D
<katco> anastasiamac: ah ok! tyvm!
<thumper> redir, perrito666: ping
<perrito666> thumper: pong
<thumper> standup?
<perrito666> going
<thumper> perrito666: now?
<redir> coming
<anastasiamac_> thumper: i think it's related to the bug you r looking at https://bugs.launchpad.net/bugs/1655169
<mup> Bug #1655169: Juju 2.1beta3: Mongo Out Of Memory on bootstrap machine 0 <juju:New> <Landscape Server:New> <https://launchpad.net/bugs/1655169>
<redir> thumper: updated PR #6783 thanks for the reviews.
<anastasiamac_> thumper: redir: perrito666: a small-ish but important-ish: https://github.com/juju/juju/pull/6788
<redir> anastasiamac_: looking
<anastasiamac_> redir: \o/
<redir> #6783 still needs a +1
<anastasiamac_> redir: yep, m getting to OCR-ing... :D
<redir> shipit anastasiamac_
<anastasiamac_> redir: i'd rather thumper +1'ed as he was requesting changes originally :D
<redir> me too:)
<anastasiamac_> redir: tyvm!
<redir> thumper is head deep in memory leaks though
<redir> and it doesn't appear that jenkins is healthy right not
<redir> now
<anastasiamac_> redir: :(
<redir> maybe it will timeout soon and move on.
<redir> 75 minutes might be normal for 1.25 runs
#juju-dev 2017-01-10
<mup> Bug #1645477 changed: Problem deploying openstack-ha with juju deploy  <cpec> <juju:Triaged> <https://launchpad.net/bugs/1645477>
<anastasiamac_> thumper: ping
<mup> Bug #1645477 opened: Problem deploying openstack-ha with juju deploy  <cpec> <juju:Triaged> <https://launchpad.net/bugs/1645477>
<mup> Bug # changed: 1195040, 1268364, 1457575, 1504272, 1528261, 1544796, 1552237, 1571457, 1613992, 1645477, 1645729, 1653888
<thumper> anastasiamac_: hey
<anastasiamac_> thumper: it looks like memory/disk issues are prevailent on latest 1.25.x too... could it be related to what we are seeing in juju 2?
<anastasiamac_> thumper: and hence related to work we did at EOY?
<thumper> anastasiamac_: all different memory and disk issues
<thumper> so much changed between 1.25 and 2.0
<thumper> hazaah
<mup> Bug # opened: 1195040, 1268364, 1457575, 1504272, 1528261, 1544796, 1552237, 1571457, 1613992, 1645729, 1653888
<blahdeblah> anastasiamac_, thumper: We're definitely still seeing memory issues on latest stable versions of both 1.25 and 2.0
 * thumper sighs... yeah
<thumper> we suck
<anastasiamac_> thumper: we dont!
<thumper> but let's just focus on adding features
<thumper> it'll be fine
<anastasiamac_> thumper: did u find perfscaling CI collects helpful in triaging 2.x memory issues? don't we track goroutines there?
<anastasiamac_> veebers: ^^
<veebers> anastasiamac_: we don't currently track goroutines there
<veebers> (but that's a possible feature we could add in the near future)
<mup> Bug # changed: 1195040, 1268364, 1457575, 1504272, 1528261, 1544796, 1552237, 1571457, 1613992, 1645729, 1653888
<blahdeblah> anastasiamac_, thumper, veebers: I'm about to do a check of my envs (1.25.9 & 2.0.2) for memory issues; any info I could provide on bug 1645729 or others that would help?
<mup> Bug #1645729: environment unstable after 1.25.8 upgrade <juju:Fix Committed by axwalk> <juju 2.1:Fix Released by axwalk> <juju-core:Fix Released by axwalk> <juju-core 1.25:Fix Released by axwalk> <https://launchpad.net/bugs/1645729>
<thumper> blahdeblah: not right now... I don't think
<veebers> blahdeblah: I can't suggest anything useful
<mup> Bug #1650401 changed: Kubernetes-core bundle fails to deploy. Easy-rsa results with failed hook <juju:New> <https://launchpad.net/bugs/1650401>
<mup> Bug #1650405 changed: Juju Embedded - Juju logout/login not working for multiple users connected to same controller   <juju:New> <https://launchpad.net/bugs/1650405>
<blahdeblah> thumper, veebers: FWIW, I have a 2.0.2 Canonistack controller running 1 env which has up since Dec 27 05:51:53 2016
<thumper> and
<blahdeblah> So it seems a lot better on 2.0.2 than 1.25.9 which has been restarted several times since.
 * thumper nods
<blahdeblah> anastasiamac_ asked for an update on that bug, so I'll add the above there.
<anastasiamac_> blahdeblah: thank you!
 * thumper screams
<thumper> loudly
<thumper> FFS
 * thumper headdesks
<anastasiamac_> thumper: wot?
<thumper> very stupid code
 * thumper blames ian
<anastasiamac_> good! u can only blame ppl that r not here to defend themselves :D
<anastasiamac_> thumper: which part of code?
<thumper> cmr
<thumper> I'm trying to trace the run away state references...
<anastasiamac_> awesome \o/ should it not have been behind a feature flag?
<thumper> 75 machines
<thumper> call it average 6 units per machine
<thumper> or even three
<thumper> that is 300 api connections
<thumper> each api connection creates an extra state because stupid
<anastasiamac_> wow :(
<thumper> so... found that
<thumper> but it isn't the cause of this leak
<thumper> i just... don't even...
 * redir goes eod
<anastasiamac_> veebers: i have a q about MM functional tests. r u the person to ask?
<thumper> anastasiamac_: https://github.com/juju/juju/pull/6789
 * anastasiamac_ looking
<anastasiamac_> thumper: Stata? funny :) that alone is an indication of the rush in which this code was produced...
<thumper> yeah
<anastasiamac_> well, done - i think it should b added to Hall of Fame or at leats 'Treasure Hunt 2017' repository... i suspect there will b a few of these in the months to come
<anastasiamac_> lgtm'ed
<anastasiamac_> natefinch: ping... r u really here?
<anastasiamac_> frobware: ping
<veebers> anastasiamac_: hey, I probably am. What's the query? :-)
<anastasiamac_> veebers: was looking at https://bugs.launchpad.net/juju/+bug/1648063
<mup> Bug #1648063: kill-controller removes machines from migrated model <gap> <model-migration> <juju:Triaged by alexis-bruemmer> <juju-ci-tools:Triaged by veebers> <https://launchpad.net/bugs/1648063>
<anastasiamac_> veebers: which looks like it could have a pretty simple functional test... do we have one?
<anastasiamac_> veebers: i was hoping that we did and could easily verify if the issue has been fixed..
<anastasiamac_> veebers: there were couple of MM fixes over the last couple of weeks, it seems
<veebers> anastasiamac_: there is no test for this currently, but it's on the books to be added
<anastasiamac_> veebers: k. thnx
<anastasiamac_> thumper: funny: https://bugs.launchpad.net/juju/+bug/1519147... somehow I do not thinkg that Dave's on it
<mup> Bug #1519147: worker/rsyslog: data races <2.0-count> <juju:In Progress by dave-cheney> <https://launchpad.net/bugs/1519147>
<thumper> yeah... probably not
<t0mb0> can anyone tell me from https://jujucharms.com/docs/stable/authors-charm-actions#example-schema
<t0mb0> looking at the example schema
<t0mb0> what is going to be in the files under actions/
<t0mb0> ie actions/report
<t0mb0> from reading that it looks like everything is defined in actions.yaml
<t0mb0> and then the implementation is handled in the reactive layer
<anastasiamac_> t0mb0: this looks like a question best suited for #juju channel :)
<blahdeblah> anastasiamac_: We've got another occurrence of what looks like 1645729 on juju 2.0.2 - do you want any further info gathered?
<anastasiamac_> blahdeblah: and i was planning to hold my breath for the next 7mins...
<anastasiamac_> blahdeblah: yes plz ;)
<blahdeblah> What needs gathering?
<blahdeblah> Just the standard go routines dump?
<anastasiamac_> blahdeblah: for now, yes.
<anastasiamac_> blahdeblah: altho m a little confused, the bug is about 1.25.x..
<blahdeblah> It seems to be assigned to all current versions, including 2.1
<blahdeblah> presumably because axw found the same issue in them
<anastasiamac_> blahdeblah: ah i see... and u have been sayint that equivalent 2.0.2 is fine.. until 5mins away from eod ;D
<anastasiamac_> blahdeblah: got it..
<anastasiamac_> blahdeblah: thank you for providing more info!
<blahdeblah> So on my canonistack env, 2.0.2 has been good so far, but this is another env on the azure provider
<anastasiamac_> blahdeblah: \o/ loving it! and yes, update on the bug would be awesome
<blahdeblah> anastasiamac_: Mind having a 1-minute look over https://wiki.canonical.com/InformationInfrastructure/WebOps/Juju#Gathering_debug_info_with_pprof to make sure I'm gathering the right stuff?
 * anastasiamac_ looking
<anastasiamac_> blahdeblah: looks awesome \o/ someone who worte it up should get a medal
<blahdeblah> OK - gathering now
<blahdeblah> TBC, this might be lp:1635311 rather than lp:1645729 - I can't be sure until checking the symptoms
<anastasiamac_> blahdeblah: ack
<frobware> anastasiamac_: pong & HNY
<anastasiamac_> frobware: HNY to u 2 :D
<anastasiamac_> frobware: m about to do kids/dinner.. could I pm u later-ish? maybe in 3hrs?
<frobware> anastasiamac_: sure
<anastasiamac_> frobware: \o/
<SimonKLB> when using maas as the provider, what is deciding the ip of the machines? for some reason, the machine ip of the node seem to be choosen arbitrary even though im using an external dhcp (not the one maas provides)
<SimonKLB> when i first booted up the maas node i got the correct ip from my dhcp server, but when i run "juju add-machine" the node is created with a different ip
<SimonKLB> that ip is even in one of the "reserved ranges" that i have stated in the maas configuration, which makes me even more perplexed
<frobware> SimonKLB: what is the network configuration of the node? DHCP? Auto Assign? Static Assign?
<frobware> SimonKLB: Correction - "what is the network configuration of the node that was allocated from MAAS" when you did juju add-machine
<voidspace> natefinch: hey, you around?
<voidspace> natefinch: I'm off to the dentist, I'll be in touch on my return
<SimonKLB> frobware: ah, youre correct, it was set to auto-assign, tried static first and then DHCP which worked, still curious though how auto-assigned resulted in a different ip which was reserved
<SimonKLB> frobware: does juju have anything to do with how the ip is chosen, or is it purely maas?
<frobware> SimonKLB: MAAS
<frobware> SimonKLB: consider MAAS as your IP address management source
<SimonKLB> frobware: gotcha
<SimonKLB> frobware: what about LXD containers, for example in the openstack bundle?
<SimonKLB> frobware: from where are they grabbing their ips?
<frobware> SimonKLB: if you do `juju add-machine lxd:0` we as MAAS for an IP address. It's static in /e/n/i in the container but is statically allocated from MAAS.
<SimonKLB> will it fetch the ip from the same subnet as the host?
<SimonKLB> frobware: and if you have multiple nics, which subnet?
<frobware> SimonKLB: for Juju 2.0 it will use interfaces that have a subnet and an IP address
<frobware> SimonKLB: otp - will answer in a bit
<SimonKLB> frobware: yea, just tried it, it has the same behavoir as auto-assign in MAAS it seems
<SimonKLB> frobware: it grabs an ip that is reserved, which is problematic :/
<frobware> SimonKLB: as in the reserved range? What's the issue?
<SimonKLB> frobware: yea, i want to restrict the subnet to a range, from what i understand the reserved ranges are supposed to be "those that are already taken"
<SimonKLB> frobware: but when i deploy an LXD container it still grabs an ip from a range that is reserved
<SimonKLB> frobware: this is where i read it https://docs.ubuntu.com/maas/2.1/en/intro-concepts
<frobware> SimonKLB: you have a reserved range setup in MAAS?
<SimonKLB> "Reserved range An IP range that MAAS will never use. You can use it for anything you want (e.g. infrastructure systems, network hardware, external DHCP, or the namespace for an OpenStack cloud you will be building)."
<SimonKLB> frobware: i have a subnet with a CIDR that includes a number of ips, most of them i have in the reserved range so that they are restricted from being used by MAAS
<frobware> SimonKLB: hmm. so the container has been allocated a IP addr from your reserved range.
<SimonKLB> frobware: correct
<SimonKLB> frobware: and this also happened to a machine before
<SimonKLB> frobware: when it had "auto-assign" as the ip mode option
<frobware> SimonKLB: I have two ranges on my 10.100.0.0/24. 10.100.0.1->10.100.0.99 as reserved and 10.100.0.250..10.100.0.254 as dynamic.
<SimonKLB> frobware: the dynamic ranges are only used when you use the MAAS DHCP right?
<SimonKLB> frobware: im running an external DHCP
<frobware> SimonKLB: I just added two containers and they ended up as 10.100.0.101 and 10.100.0.102 - which seems to be correct
<frobware> SimonKLB: yes to your DHCP question
<SimonKLB> frobware: good, with you so far!
<frobware> SimonKLB: so, it seems to be allocating out of the correct range. agreed?
<SimonKLB> frobware: yea
<SimonKLB> frobware: but i wonder if it could be behaving differently with an external DHCP instead of the MAAS one
<frobware> SimonKLB: perhaps. difficult for me to repro that quickly.
<frobware> SimonKLB: I did try without a DHCP range as well. it was allocated out of the non-reserved range.
<SimonKLB> frobware: yea np, but is there a way to simulate the DHCP "IP Mode" option that you have for machines?
<SimonKLB> frobware: for lxd containers that is
<SimonKLB> frobware: because changing it from auto-assigned to DHCP seemed to have fixed it for me at least for the machines
<frobware> SimonKLB: you're using MAAS 2.1.1, correct?
<SimonKLB> frobware: maas/xenial,now 2.1.2+bzr5555-0ubuntu1~16.04.1
<frobware> SimonKLB: I wonder if there is some difference on 2.1.2.
<frobware> SimonKLB: I just created: reserved range: 10.100.0.40->10.100.0.99 and dynamic as 10.100.0.100->10.100.0.199
<frobware> SimonKLB: allocated another container and it came back as 10.100.0.3 i.e., before the reserved range
<SimonKLB> frobware: what happens when you try to allocate more containers than available IPs?
<frobware> SimonKLB: which to me says MAAS is finding the first applicable IP address, given the ranges.
<SimonKLB> frobware: yea i wish :)
<frobware> SimonKLB: I would expect MAAS to say "no, IPs available", and for Juju to gracefully fail.
 * frobware lunches
<voidspace> natefinch: bug #1631254
<mup> Bug #1631254: [2.0rc3] lxd containers do not autostart <rteam> <juju:In Progress by mfoord> <https://launchpad.net/bugs/1631254>
<voidspace> natefinch: https://github.com/tych0/juju/commit/81156dfb3c1d21431cb3bd5047a51e13bd91fc5d
<voidspace> macgreagoir: thanks for the email
<redir> thumper: can you have a look at https://github.com/juju/juju/pull/6783 ?
<thumper> ack
<redir> thanks
<redir> what's the magic incantation to get cross model relations to work. I assume it is behind a feature flag
<redir> well I thikn i have it but still have an error
<redir> got it
#juju-dev 2017-01-11
<redir> thumper: yt?
<thumper> yep
<redir> that test bit is a fake, it doesn't really matter what it returns. The actuall code that does that work is in container/kvm
<thumper> redir: I trust you to make a good call
<thumper> do what you think is right
<redir> I'll update the code to use nonsense names and not depend on runtime since it is a fake to let the Initialiser complete so the rest of the suite will passa
<thumper> ok
<redir> crap maybe I'm wrong
<redir> me looks harder
<redir> brb
<redir> back for a few
<hoenir> Hi guys, other than "--debug" option there is anything that triggers the output to be more "verbose" ?
<hoenir> ?
<hoenir> anyone?
<hoenir> can provide some insight?
<macgreagoir> hoenir: Not that I know of. You can up the logging levels on the machines/units though. Take a look at `model config`.
<babbageclunk> hoenir: You can also get a lot more logging out during the bootstrap process by setting JUJU_LOGGING_CONFIG, eg:
<hoenir> Thanks, I'm already aware of that option. I thought that there is more than this, some special flag hidden in the cmd that I'm not aware already.
<hoenir> the JUJU_LOGING_CONFIG tirggers the ctx.Verbose flag to be true?
<babbageclunk> hoenir: I don't think so -  the --verbose flag does that.
<babbageclunk> hoenir: hang on, what I was saying was: `JUJU_LOGGING_CONFIG="<root>=TRACE" juju bootstrap ...`
<hoenir> babbageclunk, I will try now this.
<babbageclunk> so setting the env var before bootstrapping (or other command) will show more logging from the client
<babbageclunk> which might be useful if you're interested in --verbose
<hoenir> simple just like this ? JUJU_LOGGING_CONFIG="<root>=TRACE"
<babbageclunk> hoenir: yes, and then the command.
<babbageclunk> hoenir: oh, are you on linux or windows?
<hoenir> linux amd64-arch linux.
<babbageclunk> hoenir: actually I
<babbageclunk> oops
<hoenir> Actually what?
<hoenir> :))
<babbageclunk> hoenir: no, it was a half-thought and I meant to delete it.
<babbageclunk> dumb laptop keyboard ;)
<hoenir> I forgive your keyboard.
<hoenir> Tell him/her to not worry.
<hoenir> ^_^
<hoenir> and thanks for the advice.
<babbageclunk> so setting that env var using export and then running the command should do it, or prefixing the command with the assignment.
<babbageclunk> my pleasure - hope it helps!
<babbageclunk> oops - bedtime!
 * babbageclunk bedtimes
<perrito666> morning jujuers
<junaidali> Hi guys, I'm trying to restore a failed juju controller. I have created a new controller and running the command 'juju restore-backup -b --file=juju-backup-20170110-092916.tar.gz'
<junaidali> but it is erroring out with the message 'ERROR old bootstrap instance ["bootstrap:6tdgfk"] still seems to exist; will not
<junaidali> replace'
<junaidali> I'm following this doc->https://jujucharms.com/docs/2.0/controllers-backup. Am I missing anything here?
<junaidali> On deleting all existing controllers, commands outputs: empty controller name not valid
<junaidali> command*
<perrito666> junaidali: restore -b needs the controller to be gone, you can do that by killing it in your cloud controller
<perrito666> junaidali: it is intended to be used when the controller is fully gone (usually died on its own)
<perrito666> I advice you to do this
<junaidali> perrito666: I have killed all the controllers but now the error is 'empty controller name not valid'
<perrito666> junaidali: how exactly did you kill the controllers if I may ask?
<junaidali> juju kill-controller <controller-name>
<perrito666> ah there lies the problem
<perrito666> junaidali: backup is intended to restore a fallen controller, so for instance, lets say you have an lxd juju
<perrito666> if you go and lxc delete --force controller
<perrito666> you end up with a headless juju
<perrito666>  in that case a backup would give you back a controller
<perrito666> if you kill controller, you kill the environment
<junaidali> oh :(
<perrito666> sorry :(
<junaidali> no issues, it was a test setup. Thanks, I will be careful next time :)
<perrito666> junaidali: yay, better this happening on test setups
<perrito666> junaidali: in any case you can also restore a backup into the working controller but that is not the preferred way
<perrito666> ask around if you have more doubts, ill be here all day
<junaidali> perrito666: thanks, much appreciated.
<perrito666> anyone knows in depth how upgradeStepsGate
<natefinch> voidspace: so, I seem to have that change working with lxd.... but I'm not entirely sure how to test that the constraints are actually applied
<natefinch> tych0: how can I test that my lxd limits are applied correctly?  i.e. 2GB RAM
<perrito666> natefinch: compile juju inside lxc
<natefinch> lolol
<SimonKLB> whats the current status on how the primary ip is "chosen" for a machine in juju? last i checked it was kind of arbitrary when you have multiple interfaces on the machine
<SimonKLB> has there been any recent discussions on that topic?
<perrito666> SimonKLB: afaik it chooses one of the public ones but sort of randomly (ie, there is no predefined order)
<perrito666> SimonKLB: perhaps voidspace can answer better
<SimonKLB> yea, it would be nice to have a way to force it to choose one of them, for example, i have a maas setup where each machine have 2 nics, and i'd like one of them to be an internal network while the other the public one
<SimonKLB> right now there doesnt seem to be a way to guarantee that the nic i use as the public one becomes the primary in juju
<perrito666> SimonKLB: I see, I presume the ips are both "public" or both "private" ?
<SimonKLB> one public and one private
<perrito666> SimonKLB: I believe spaces should provide you with a solution for that I am not sure what is the working status of that for maas to be honest
<perrito666> natefinch do you?
<natefinch> spaces are supposed to do that, I think
<SimonKLB> are maas spaces and juju spaces one and the same?
<natefinch> for maas, yes, I believe so
<perrito666> brb, lunch while bootstraping
<perrito666> natefinch: SimonKLB I would not be so sure
<perrito666> there is some overlapping in the definition but something tells me that juju spaces might be a bit more encompassing
<perrito666> frobware: ?
<natefinch> hmm, possibly
<frobware> SimonKLB: your desire for "internal and public" would be met by spaces
<SimonKLB> frobware: and would that be defined in maas or in juju, or both?
<SimonKLB> because i see that both maas and juju have spaces
<SimonKLB> not sure if they are directly translated from the provider to juju or if it's something that you define separately
<frobware> SimonKLB: define your spaces in MAAS. That's your definitive network setup/topology. Juju will learn of the spaces on bootstrap. From there you can use do: https://jujucharms.com/docs/2.0/charms-deploying#deploying-with-binding
<SimonKLB> frobware: thanks!
<SimonKLB> oh and btw, what decides what is going to be the primary ip and not?
<frobware> SimonKLB: You can also use spaces (i.e., their names) in provisioning machines.
<SimonKLB> so now i have machines with two nics, one on the public subnet and one private, the public subnet is in spaces-0 and private in internal-0
<SimonKLB> since spaces-X are special spaces names, do they simply have priority? or how can i force the public subnet to become the primary nic/ip in juju?
<SimonKLB> this looks kind of related https://bugs.launchpad.net/juju/+bug/1473069
<mup> Bug #1473069: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <2.0> <addressability> <bug-squad> <cdo-qa-blocker>
<mup> <landscape> <lxc> <maas-provider> <networking> <uosci> <juju:Triaged by rharding> <Landscape Server:New> <https://launchpad.net/bugs/1473069>
<SimonKLB> also this: https://bugs.launchpad.net/juju/+bug/1616098
<mup> Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> <cpec> <juju:Fix Released by dimitern> <https://launchpad.net/bugs/1616098>
<frobware> SimonKLB: the software that you want to run an be public should be deployed and bound to your public space
<frobware> SimonKLB: you guide the exposure using spaces
<SimonKLB> frobware: my issue is that i can guarantee that juju chooses the "correct" public ip
<SimonKLB> frobware: so i could end up with the private ip being the one exposed in juju
<SimonKLB> frobware: i dont see anywhere an option in maas to define a spaces as "public" or "private"
<frobware> SimonKLB: put discrete subnets you put in your "public" space
<frobware> in your...
<frobware> SimonKLB: bbiab; meeting
<SimonKLB> okok!
<redir> brb reboot
<redir> new kernel
<perrito666> this bug is starting to feel like a fractal ffs
<redir> :(
<perrito666> k , EODing until standup, ill reply if privmsgs are sent tho
 * redir lunches
 * perrito666 is back
#juju-dev 2017-01-12
<axw> redir: chat about cross compiling agents?
<redir> axw: yes please
<redir> HO?
<axw> redir: https://hangouts.google.com/hangouts/_/canonical.com/reed-andrew?authuser=1
<anastasiamac> veebers: thumper: is tab completion with juju-core or qa team?
<thumper> it is in core I think but not sure who understands it
<anastasiamac> thumper: awesome \o/
<babbageclunk> anastasiamac: I'm not sure how to fix bug 1648063
<anastasiamac> used to mgz, I *think*
<mup> Bug #1648063: kill-controller removes machines from migrated model <gap> <model-migration> <juju:Triaged by alexis-bruemmer> <juju-ci-tools:Triaged by veebers> <https://launchpad.net/bugs/1648063>
<anastasiamac> see? amusement :D
<anastasiamac> babbageclunk: does it mean that you know what's going on and just don't have a solution?
<babbageclunk> anastasiamac: Oh, hang on - I think I need to try to reproduce it now that a related/intersecting bug is fixed.
<anastasiamac> veebers: would have been awesome if we had that functional tests to prove/disaprove it ^^
<anastasiamac> disprove*
<babbageclunk> anastasiamac: but I'm a bit worried about how to fix the problem in the general case
<veebers> anastasiamac, babbageclunk (mentioned in email just forwarded) Seems I came across another version of that bug (or just an extension). After migration everything seems happy, but when I destroy the origin the units get "Agent lost"
<veebers> anastasiamac: ack
<anastasiamac> babbageclunk: "worried" is our perpetual state... it's generally good!
<anastasiamac> means we care
<babbageclunk> anastasiamac: after a migration there might be clients that think they know which machines belong to this controller, and end up killing machines that now belong to the target controller.
<anastasiamac> babbageclunk: don't we identify mahcines by which controleer they belong to + machine id (maybe even a model)?
 * anastasiamac can't type today... at all
<babbageclunk> anastasiamac: hmm, with tagging? maybe. I'll need to do some experiments.
<babbageclunk> ouch, migrating models with cross model relations might be complicated.
<babbageclunk> thumper: that migrations bug anastasiamac pointed out is pretty bad, should I pick that up or work on intermittent landing blockers?
<thumper> babbageclunk: look at the bad one :)
<babbageclunk> thumper: yay
<thumper> babbageclunk: the model destruction code in the api server just needs to take migration status into account
<thumper> the model may be there still but marked migrated
<thumper> the destruction code doesn't check
<thumper> that is my working hypothesis
<anastasiamac> thumper-dogwalk: did u hear back from larrymi about how custom binary went? m trying to figure out if your change would be of benefit here: https://bugs.launchpad.net/juju/+bug/1655169
<mup> Bug #1655169: Juju 2.1beta3: Mongo Out Of Memory on bootstrap machine 0 <juju:New> <Landscape Server:Triaged> <https://launchpad.net/bugs/1655169>
<redir> bah
<redir> axw: ERROR failed to bootstrap model: cannot use agent built for "arm64" using a machine running on "amd64"
<axw> redir: hrm. what's your bootstrap line?
<redir> juju bootstrap arm64-maas kvm/arm64dev2 --constraints arch=arm64 --metadata-source ~/Sync/juju/arm64-bin/streams < axw
<axw> redir: I think that means it didn't find the tools using --metadata-source
<axw> redir: I'd use --debug to figure out what's going on with agent selection
<redir> yeah that's it found 0 packaged agent binaries
<redir> axw: do I have to do something to tell it to look for devel streams?
<redir> rather than released
<axw> redir: ah yeah probably need to pass --config agent-stream=devel
<axw> or whatever it's called
<redir> but really juju bootstrap --use-this-agen /path/to/jujud would be nic3
<redir> ahh
<redir> same issue
<redir> if I'm on 16.10 is it looking for 16.04 and missing?
<redir> I wonder
<anastasiamac> redir: I *think* u can ask it to look for 16.04... there might b a config option...
 * redir looks for config optiosn
<perrito666> k, see you tomorrow everyone
<anastasiamac> perrito666: o/
<redir> same problem
<redir> cannot use agent built for "arm64" using a machine running on "amd64"
<redir> I'll have to get back to it tomorrow
<natefinch> man, kill controller -t 0 on lxd is gloriously fast
<natefinch> anastasiamac: you around?
<rogpeppe> anyone know what's going on with this juju build failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju/10005/artifact/artifacts/trusty-err.log
<rogpeppe> i've been trying to merge this trivial juju-core change for days now
<rogpeppe> and i keep getting failure after failure
<perrito666> tim was working on it last night iirc
<rogpeppe> perrito666: ok, thanks
<rogpeppe> perrito666: it's a wonder that anything lands at all...
<perrito666> this has increased over the last days afaik
<perrito666> the erroring  mean
<perrito666> bbl lunch
<natefinch> redir: you around/
<redir> not yet but will be soon-ish
<redir> what's up natefinch ?
<natefinch> wondering if you know if kvm containers respect constraints
<redir> natefinch: not positive
<redir> about all
<redir> but disk size, ram, cpus are
<redir> arch isn't
<redir> requires hostarch
<natefinch> redir: *nod*  what happens if you try to deploy a container with RAM=32G on a machine with 16G?
<redir> at this point I am guessing
<natefinch> redir: it's ok, I can check, just wanted to know if you knew
<redir> kvm fails to start
<redir> I also think it is a problem if you put 4 kvms with 30G disks on a system with a 60GB drive
<redir> it will seems ot work, but run out of disk on the 'host'
<redir> good questions
<redir> bbiab
<redir> natefinch: so the the mem case it defines the domain but cannot start it
<natefinch> tych0: you around?
<natefinch> redir: interesting. How does that appear to the end user of Juju?
<redir> natefinch: poorly
<redir> it just doesn't start
<natefinch> redir: lol, not surprising
<redir> I'll put it on the list of known issues
<redir> after it works on rare arches it shouldn't be too hard to handle and return a useful error
<redir> even easier if go-libvirt grows the API we need
<natefinch> yeah, the problem I'm looking at is that I'm implementing constraints for LXD, which do the right thing as long as your constraint matches the host machine, but you can set mem=8G for a container on a machine with 4GB, and lxd still happily runs a container
<natefinch> but it'll obviously only have 4GB of ram available
<redir> that isn't ideal
<redir> I think kvm has that issue with disk
<redir> because they are sparse... so aren't actually too big on creation
<redir> but I haven't tested that
<redir> yet
<natefinch> voidspace: you still around by any chance?
<perrito666> bbl
<admcleod_> hi, any approximate release date for 2.1?
<thumper> real soon nowâ¢
<redir> bbiab going to run an errand
<babbageclunk> thumper: ping?
<thumper> ping
<thumper> pong
<thumper> whatever
<thumper> babbageclunk: whazzup?
<babbageclunk> thumper: so the instances are being deleted in environ.Destroy() - is there a way to rename the containers?
<thumper> environ.Destroy on the controller model?
<thumper> or on the hosted model?
<babbageclunk> thumper: controller I think
<thumper> we need to work out why
<babbageclunk> thumper: It's just using prefix matching on the names.
<thumper> environ.Destroy *should* only destroy that model's machines
<thumper> the prefix match shouldn't match others
<thumper> we shouldn't be calling environ.Destroy on migrated models
<babbageclunk> thumper: Hmm, true - ok, I added lots of logging, I'll rerun my experiment to see.
<thumper> ok
<nurfet> thumper: again a question about implementing a new cloud provider. Now I'm getting: ERROR cmd supercommand.go:458 failed to bootstrap model: cannot start bootstrap instance: no "xenial" images in us/las with arches [amd64]
<nurfet> what is wrong here?
<perrito666> thumper: hey, to make your beginning of day more complicated 1) sorry for making you review a pr that was partly obsoleted but tx for the review it gave me a few pointers, 2) there was some talking thes afternoon in another channel about mongo logs and oplog eating most of the ram on some situations, is that what you where looking at?
 * thumper is otp right now
<thumper> perrito666: we need to talk about storage at some stage, do you have much overlap with axw where we can do it all together?
<thumper> either that or I could catch you first
<perrito666> thumper: if you give me 1/2 h we can talk
<perrito666> then you can talk with axw
<thumper> nurfet: not entirely sure where this is failing... is it in the provider code where it is trying to start the instance?
<thumper> if so, it will be very provider specific, and how it looks for cloud images in the cloud
<thumper> perrito666: talk in 30 minutes? or talk for 30 minutes?
<perrito666> thumper: we can talk now, sorry I was finishing some house chores
<thumper> perrito666: gimmie 30 minutes
<perrito666> thumper: ack
<nurfet> thumper: it's failing in the provider code. I am not sure how to link an existing image, for instance xenial, with my provider region "us/las".
<nurfet> sorry I might be asking well known stuff but I am pretty new to Juju
<katco> anyone around? need a 3rd data-point
<perrito666> thumper: time is up
<katco> pretty easy ask, and if you help you get 100 internet points!
<perrito666> katco: I sort of am if is a low attention thing
<katco> perrito666: it is
<perrito666> shoot
<katco> perrito666: can you build/bootstrap lxd from upstream/2.1-dynamic-bridges ?
<katco> perrito666: looking for binary y/n was successful
<perrito666> katco: sure, fetching
<katco> perrito666: ta
 * perrito666 builds
<thumper> nurfet: you are hitting the very cloud specific bits. There needs to be some way for the provider code to ask the cloud to start particular instance types with a particular OS image
<thumper> how those images are identified and mapped is very cloud specific
<thumper> perrito666: making hangout
<nurfet> thumper: that's clear to me but I am concern what info I need to provider/store locally in order for Juju to be able to deploy charms?
<redir> katco: I seem to be sticking around at waiting for ip address for longer than I recall happening on lxd
<thumper> nurfet: juju stores info locally about the machine, like the series and instance id
<thumper> nurfet: once the machine has been started, it is the juju agent running on that machine that deploys the charm
<katco> redir: ta for trying; that might be because this branch is a bit diverged from recent changes. but it should bootstrap i think
<thumper> all the provider code needs to be able to do is to start an instance for a model
<thumper> and list instances for that model
<thumper> normally there is some tagging of the instances using the model UUID
<thumper> if we are just thinking about the first step of the machines, you need to be able to start, stop and list instances for a model
<thumper> uuid tagging is the easiest way to get some listing
<thumper> that uuid tagging has to be at the cloud provider level
<thumper> and not rely on any local storage (meaning user's host machine)
<thumper> how that tagging is done is very cloud specific
<thumper> nurfet: does that help?
<redir> katco: look at gh:jameinel/juju dynamic-bridges branch
<redir> it have developp merged up to it
<redir> at least as of last week
<katco> redir: cool ty... i think i may have figure out what's going on
<redir> k not bootstrapping here
<katco> redir: ta for starting to tal
<nurfet> thumper: pretty much. The problems are that my cloud provider doesn't support instance tagging nor instance flavors
<nurfet> but i think i can get around those weeknesses
<thumper> nurfet: does it support any form of persistent disk?
<thumper> one way we used to do it before instance tagging
<thumper> was a file in presistent storage that had a mapping for us
<nurfet> thumper: it does support persistent storage i.e. HDD volumes
<thumper> nurfet: storage not attached to an instance?
<nurfet> thumper: the storage must be attached to the instances but that's performed on a remote host
<nurfet> no any kind of local storage is required
<nurfet> I trying to find a correlation between my cloud provider images and images published on http://cloud-images.ubuntu.com/releases/
<nurfet> I am trying to find a correlation between my cloud provider images and images published on http://cloud-images.ubuntu.com/releases/
#juju-dev 2017-01-13
<redir> emulation is slooow
<redir>  /me goes eod real soon now
<thumper> axw, babbageclunk or anastasiamac_: https://github.com/juju/juju/pull/6794
 * anastasiamac_ looking
<axw> looking
<babbageclunk> not looking
<axw> thumper: what's the gcwriter thing? doesn't seem related
 * anastasiamac_ has a feelling that babbageclunk will miss out on magic \o/
<anastasiamac_> huge reduction in test runs? magic!
<thumper> axw: it isn't entirly related
<thumper> but I did it while tracing the timings
<thumper> seemed useful,
<babbageclunk> oh man, is it like a fun surprise PR? almost tempted to click.
<thumper> so left it in
<axw> thumper: it's going to route all command output to test output? I think I'd prefer that was opt-in, might lead to a lot of spam
<anastasiamac_> i'd say anything that imporves readibility of our logs and speeds up diagnosis is useful - happy for u to leave it. +1 from me
<thumper> hmm...
<axw> if it's not that spammy, leave it
<thumper> when we get the test output, I think it is because something is broke
<thumper> the more detail when that happens IMO is useful
<axw> fair enough
 * anastasiamac_ wonders if we can abandon 1.25.x since we can't land
<blahdeblah> yeah - nobody uses that! :-P
<thumper> thanks
<anastasiamac_> blahdeblah: :D
<blahdeblah> install base, schminstall base
 * thumper hopes this fixes some of the arm64 issues
<thumper> I have a feeling though that we'll need to target other tests too
<thumper> I almost feel like running the entire test suite with a modified cert.NewCA function that writes to a local file with the call stack of every call site.
<thumper> Just to see how many times we call it
<thumper> to identify the test suites...
 * thumper wonders how hard that would be to coble together quickly
<thumper> probably not too hard...
 * thumper attacks
 * thumper looks for a quick file append call
<natefinch> thumper: os.Open(filename, os.O_WRONLY | O_APPEND | O_CREATE, 0600) -ish ?
<thumper> yeah, had got to that
<thumper> natefinch: but thanks
<natefinch> :)  no helper AFAIK
<redir> still building:| I'll see if it works tomorrow
<redir> later #juju-dev
<anastasiamac_> redir: o/
<mup> Bug #1656188 opened: metric-collect error when deploying charm <juju-core:New> <https://launchpad.net/bugs/1656188>
<mup> Bug #1656304 opened: juju2/maas2: nodes allocation fails if any bridge created in MAAS <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1656304>
<perrito666> katco: do you still that data point? the deployment last night blew my network and then I was absorbed by a hangout so I did not dare try again but I have some time now (sorry for not mailing this yesterday)
<katco> perrito666: hey thanks for checking in; no i'm all good
<katco> perrito666: tyvm for the attempt
<perrito666> katco: I am curious, do you think the bootstrap is what killed my net or was just a coincidence?
<katco> perrito666: frobware could better answer that question; i don't know =/
<perrito666> lol
<katco> perrito666: i am only just touching this branch
<katco> perrito666: but i can say i haven't had network problems
<perrito666> katco: perhaps just an unhappy coincidence
<katco> perrito666: sorry if i caused you any issues!
<perrito666> nah, just restarted the connection
<perrito666> I start every juju test with the assumption my machine is going down, something that stayed in my head since the times of local provider :p
 * katco cries
<perrito666> katco: did I just bring back bad juju memories?
<katco> perrito666: unfortunately not memories. i just hate that our test suite does what it does
<perrito666> katco: oh, I was talking about testing by hand, I dont think our test suite ever killed my computer
<natefinch> it killed mine a couple times.
<katco> perrito666: i've had our test suite muck with nics
<perrito666> natefinch: oh yeah :)
<katco> perrito666: and it compiles things, and other weird weird stuff
<mattyw> hey folks
<katco> mattyw: hey, long time!
<natefinch> it starts mongo.  I mean, geez
<perrito666> I am pretty sure that running the suite with sudo would do some interesting wrecking
<mattyw> katco, hey hey, happy new year
<perrito666> mattyw: hehey
<katco> natefinch: and further just starts it by running the binary =|
<mattyw> perrito666, hello there, happy new year to you too
<katco> mattyw: happy new year
<mattyw> so I'm juju bootstrapping, and hoping my local jujud to be uploaded, and it seems to not be "just doing the right thing"
<katco> mattyw: you can use --build-agent flag
<mattyw> katco, I can do, do we still need to do that?
<natefinch> if you want to be sure it uses your local binary, yes
<katco> mattyw: if it's not building the agent and you want it to, yes ;)
<mattyw> I was looking for that flag but didn't see it in the help
<katco> mattyw: generally it does the right thing, but the rules can be a bit opaque, and the outcome can change depending on what is in streams
<mattyw> is it secret, or have I forgotten how to read?
<natefinch> based on state far outside your control or knowledge, sometimes it'll do that anyway (based on your local client version and the versions in streams)... but if you want to be sure, then use --build-agent
<katco> mattyw: juju bootstrap -h |grep build-agent |wc -l
<natefinch> yeah, it's in my help
<mattyw> katco, not sure how I feel about there being a command to prove I'm wrong :)
<mattyw> natefinch, I see it now thanks
<mattyw> natefinch, I didn't know what I was looking for last time I looked :)
<katco> mattyw: rofl; few things in life are so black and white. i enjoy such certainty! ;)
<mattyw> katco, natefinch thanks for the help
<katco> mattyw: thanks for stopping by. good to hear from you
<mattyw> katco, I'm always, here, just normally like hiding in the corner
<katco> :)
<redir> bbiab
<redir> Woohoo ARM64 bootstrapped!
#juju-dev 2017-01-14
<natefinch> redir: I have a fix for that PR
<voidspace> macgreagoir: ping
<ejat> can maas 2.0 and juju 2.0 works to build Canonical OpenStack Autopilot?
#juju-dev 2017-01-15
<perrito666> This place is really silent on sundays
<mup> Bug #1656188 changed: metric-collect error when deploying charm <juju:New> <https://launchpad.net/bugs/1656188>
<mup> Bug #1656304 changed: juju2/maas2: nodes allocation fails if any bridge created in MAAS <canonical-bootstack> <juju:New> <https://launchpad.net/bugs/1656304>
#juju-dev 2018-01-08
<axw> babbageclunk: happy new year. skip standup today? it'll just be us
<axw> last week I did bugs, this week I do bugs
<babbageclunk> axw: happy new year to you too!
<babbageclunk> ha
<babbageclunk> yeah, I'm fine to skip - last week I did tramping
<axw> nice :)
<babbageclunk> today I'm doing upgrade testing
<thumper> axw: wondering if you could comment on https://bugs.launchpad.net/juju/+bug/1738993
<mup> Bug #1738993: ERROR creating hosted model: model already exists <juju:New> <https://launchpad.net/bugs/1738993>
<thumper> I'm not sure where to start
<thumper> it is vmware I think
<axw> okey dokey
<thumper> thanks
<thumper> babbageclunk: hey
<thumper> babbageclunk: do you have some time to talk about audit logging?
<babbageclunk> thumper: oops, just saw this now. yes, I do if you're still free!
<babbageclunk> in 1:1?
<thumper> babbageclunk: I'm about to chat to anastasiamac, after that?
<babbageclunk> thumper: yup yup
<thumper> axw: good find on the region name dots
<axw> thanks
 * thumper looks for babbageclunk
<babbageclunk> thumper:
<babbageclunk> oops hi
<thumper> babbageclunk: 1:1 HO?
<babbageclunk> yup
<kjackal> Hi Juju devs. I had to prune orphaned transactions of a subordinate charm. That seems to fixed the mongo db issues but now the charm is unresponsive with  https://pastebin.ubuntu.com/26346175/ on its logs
<kjackal> the agent is in failing state
<kjackal> ani ideas how to get out of this situation
<kjackal> I do not mind redeploying the subordinate, but I do not wand to kill the principal charm
<thumper> kjackal: you could try 'juju resolved --no-retry'
<thumper> to get the unit out of the error state
<kjackal> thumper: the unit is not in error state, it is blocked and the agent failing
<kjackal> let me tryit
<thumper> hmm..
<thumper> how did it get into this state?
<kjackal> https://pastebin.ubuntu.com/26348573/
<kjackal> There was a corruption in mongodb. At that point all operations were failing, so I tried to pruneorhaned transactions
<kjackal> and this is where we are now
<kjackal> Do not want to redeploy the prometheus-gateway since it hosts all these other subordinates
<kjackal> If I could get rid of the failing subordinate it would have been great
<kjackal> thumper: could I go in the node and stop some of the running services so as to disable the failing agent?
<thumper> kjackal: sorry, had a call
<thumper> kjackal: I *think* we could fix it by editing a file on disk on that agent
<thumper> effectively it seems that it is stuck in a loop, retrying, but not able to make progress due to the database not being in a state that matches the unit
<thumper> the uniter on the machine has a FSM for working out what to do
<thumper> I think we might be able to nudge that
#juju-dev 2018-01-09
<hml> wallyworld: do we indent error messages that go to a new lineâ¦ i think iâve seen it before, but canât find it.
<wallyworld> one sec, otp
<thumper> hml: for example?
<hml> iâm adding a line to the create back up error messageâ¦ to suggest using juju switch or the -m flag
<wallyworld> thumper: you got a sec?
<wallyworld> hml: i can't recall one, just use no indent and see how it looks
<thumper> wallyworld: yeah
<wallyworld> thumper: see pm for link
<wgrant> Am I good to upgrade my test controller to 2.2.9?
<wallyworld> babbageclunk: ^^^^ ho'ws the release?
<babbageclunk> wgrant: streams aren't updated yet
<wgrant> AH heh
 * thumper afk for a bit to run kids around
<thumper> bbl
<axw> wallyworld: there's probably a more appropriate place to fix this, but I don't know who/what/where/how, and this works: https://github.com/juju/juju/pull/8268
<wallyworld> axw: yeah, looking now
<axw> ta
<babbageclunk> wgrant: sorry for the delay - 2.2.9 should be available for you to upgrade your test controller now
<balloons> babbageclunk, looks like you got through everything yesterday in the end
<babbageclunk> balloons: yup - can I talk through the steps with you before I update the template?
<balloons> babbageclunk, absolutely. I think you hit the same issue in verify-upgrade I did -- it seems like a juju bug
<balloons> that is; you can't upgrade to a specific agent in the proposed stream
<babbageclunk> Right - we have code that picks a stream based on the version number, so we'll only look in proposed if the version's an rc.
<babbageclunk> I guess adding an agent-stream option to upgrade-juju would do it.
<balloons> babbageclunk, that does kind of ruin our cautionary steps then at pushing to proposed first
<balloons> babbageclunk, but that's nice to know it's intentional. The verify-upgrade test though needs some love either way, so I'm glad you got so experience with it
<babbageclunk> I was going to suggest always looking in proposed when there's a specified version, but I guess that also would break the safety of being able to try upgrading before it was released...
<babbageclunk> Or does it?
<babbageclunk> Actually I think that would be ok.
<babbageclunk> And probably not difficult.
* babbageclunk changed the topic of #juju-dev to: #juju-dev
* babbageclunk changed the topic of #juju-dev to: #juju-dev https://jujucharms.com | On-call reviewer: see calendar | Open critical bugs: None
<balloons> babbageclunk, so shall we chat now?
<babbageclunk> balloons: yes please...
<babbageclunk> just making a ho
<babbageclunk> balloons: https://hangouts.google.com/hangouts/_/canonical.com/balloons?authuser=1
 * balloons twiddles thumbs waiting for google
<balloons> babbageclunk, hmm.. apparently I can't connect to hangouts
<babbageclunk> It took me a few goes - maybe they're having issues?
<balloons> now i don't see you in the call.. sigh
<babbageclunk> weird - I'm there
<babbageclunk> now I'm getting an error too.
<anastasiamac> balloons: babbageclunk: wanna take it into release call?
<balloons> trying to join yes
#juju-dev 2018-01-10
<fatgoose> anyone knows how to find k8s logs from the juju charm canonical distribution of kubernetes? specifically the controller-manager log. where is it on the master node?
<fatgoose> (assuming this is the right place to ask such question)
<anastasiamac> fatgoose: best place for these kind of questions would be #juju rather than #juju-dev
<fatgoose> thanks.
<thumper> axw: I noticed an intermittent failure in develop featuretests, to do with upgrade testing: upgrade_test.go:140: c.Assert(waitForUpgradeToStart(upgradeCh), jc.IsTrue), ... obtained bool = false
<thumper> axw: I know you love intermittent failures :)
<axw> thumper: I love them so much. I'll take a look after lunch
<thumper> axw: awesome, thanks
<wgrant> axw: Do you have a moment to talk about statuseshistory?
<axw> wgrant: sure
<wgrant> Jan 10 05:43:21 juju-189c77-controller-0 mongod.37017[1098]: [conn96] remove juju.statuseshistory query: { _id: ObjectId('5a53ff76f582e9a9395ed438') } ndeleted:1 keyUpdates:0 writeConflicts:0 numYields:1 locks:{ Global: { acquireCount: { r: 762, w: 762 } }, Database: { acquireCount: { w: 762 } }, Collection: { acquireCount: { w: 393 } }, Metadata: { acquireCount: { w: 369 } }, oplog: { acquireCount: { w:
<wgrant> 369 } } } 120ms
<wgrant> axw: Does that mean it deleted only one row at a time?
<wgrant> I just ran remove-application on 2.2.9 on a unit with lots of statuseshistory, and mongo and juju are now each eating a core and there's a LOT of that in the logs
<wgrant> Ah, got some of this toward the end, which looks more reasonable:
<wgrant> Jan 10 05:43:54 juju-189c77-controller-0 mongod.37017[1098]: [conn49] command juju.$cmd command: delete { delete: "statuseshistory", deletes: 1000, writeConcern: { getLastError: 1, j: true }, ordered: true } keyUpdates:0 writeConflicts:0 numYields:0 reslen:100 locks:{ Global: { acquireCount: { r: 2002, w: 2002 } }, Database: { acquireCount: { w: 2002 } }, Collection: { acquireCount: { w: 1002 } }, Metadata:
<wgrant> { acquireCount: { w: 1000 } }, oplog: { acquireCount: { w: 1000 } } } protocol:op_query 1051ms
<axw> wgrant: the first one does look like that, yes
<wgrant> axw: Interestingly, the batching does not totally fix the problem. I've just accidentally reproduced the saslStart storm outside the big controller for the first time...
<wgrant> I wonder what information I should gather.
<axw> wgrant: syslog and jujud log for a start, goroutine profile and cpu profile of jujud might also be helpful
<wgrant> axw: "perf top" shows that almost all CPU time is spent calculating SHA-1s.
<wgrant> For SASL
<axw> wgrant: the profile might still give a clue as to why
<wgrant> axw: How do I do the goroutine thingy?
<axw> 1 sec, need to refresh my own memory
<axw> wgrant: on the controller, "juju-goroutines"
<axw> and "juju-cpu-profile" will give you a cpu profile
<wgrant> axw: Wow that's easier than I expected
<wgrant> axw: https://private-fileshare.canonical.com/~wgrant/juju-prod-ols-snap-store-20180110-saslStart-storm.tar.gz
<wgrant> I'll add it to the bug as well, just wanting to gather as much as possible before I restart it.
<axw> wgrant: thanks
<axw> wgrant: no smoking gun in that data AFAICS :(
<wgrant> axw: :(
<tasdomas> hi
<tasdomas> how do I run juju acceptance tests on my machine?
<balloons> tasdomas, you should be able to just run most of them
<tasdomas> balloons, I thought so too
<balloons> Some may require arguments but the tests try and be smart in most cases and make default values
<balloons> tasdomas, I assume you are looking at the assess_budget tests?
<tasdomas> balloons, yeah
<tasdomas> balloons, however, I'm getting this when I try to run tests: https://pastebin.ubuntu.com/26360414/
<tasdomas> balloons, that's with a virtualenv, with requirements.txt installed
<balloons> tasdomas, well that's simple enough. You are missing python-fixtures looks like
<balloons> tasdomas, the requirements.txt is a bit of a lie atm, as you also need the packages in juju-ci-common
<balloons> tasdomas, these packages: https://github.com/juju/juju/blob/develop/acceptancetests/juju-ci-tools-common
<tasdomas> balloons, thanks - I'll keep looking into this
<balloons> tasdomas, sorry for the trouble. But thanks for updating the tests as well. If you continue to have trouble let me know
<tasdomas> balloons, I will
#juju-dev 2018-01-11
<wallyworld> agprado: you dropped out?
<axw> thumper: I don't know if you already saw, but wgrant is still seeing performance issues with 2.2.9 - still seing saslStart
<axw> see backscroll
<axw> thumper: also, I couldn't repro that intermittent test failure. tried it a couple hundred times
<thumper> :(
<thumper> ok
<wallyworld> axw: if you had 5, just wanted a quick chat RE: the status PR. easier than typing into a PR
<axw> wallyworld: sure
<wallyworld> standup
<wallyworld> axw: thumper has a theory that api rate limiting is broken - that could explain the SASl overhead
<wallyworld> as the server / mongo is getting hammered
<axw> okey dokey
<wallyworld> he says prodstack retstart showed a thundering herd
<wallyworld> all agents reconnected within a few seconds
<wallyworld> maybe if we address rate limiting issue that will help alleviate the SASL symptoms
<axw> thumper: do you have some logs to share?
<axw> or were you looking at a screenshare
<thumper> axw: no
<thumper> I was watching the prodstack grafana instance
<thumper> just noticed that the connection count for the controllers jumped back to full very quickly
<axw> thumper: looks to me like the connection count is incremented before rate-limiting kicks in
<axw> rate limiting happens in the Login handler, which is after we update teh conn count (which is what feeds the prometheus metric)
 * thumper nods
<tasdomas> balloons, ping?
<tasdomas> how do I trigger a test build on a juju PR?
<anastasiamac> tasdomas: !!build!!
<tasdomas> anastasiamac, thanks
<anastasiamac> nws :)
<tasdomas> anastasiamac, could I get a review of https://github.com/juju/juju/pull/8262 ?
<anastasiamac> tasdomas: it's past my eod but tomorrow for sure ;)
<tasdomas> anastasiamac, ah, sorry - enjoy your evening
<tasdomas> balloons, ping?
<balloons> good day tasdomas
<tasdomas> balloons, are juju acceptance tests actually being run?
<balloons> tasdomas, not during the PR. They run post-commit
<tasdomas> balloons, why is it looking into .juju/environments.yaml ( https://github.com/juju/juju/blob/develop/acceptancetests/jujupy/configuration.py#L44 ) ?
<balloons> tasdomas, it looks for JUJU_HOME first as you can see
<balloons> tasdomas, that should be JUJU_DATA, but JUJU_HOME is a juju 1ish that is still present
<tasdomas> balloons, still, on l67 it looks for a file called environments.yaml
<balloons> tasdomas, yes that file defines the cloud credentials
<balloons> tasdomas, are you wanting to run your test?
<balloons> tasdomas, typically we export JUJU_HOME which has the environments.yaml with our CI creds in it, and the tests go from there
<balloons> that means we don't have to juju add-credentials everytime
<tasdomas> balloons, so that is not the old-style environments.yaml that juju used to use
<balloons> tasdomas, no.. it's a weird combination of juju1 and juju2
<balloons> tasdomas, we have a plan to eliminate all the juju 1ism's from the test framework, but the work is only about halfway done
<balloons> the use of JUJU_HOME and environments.yaml is some of the last holdouts
<balloons> tasdomas, if you like I can run your test changes through jenkins manually to ensure it passes
<tasdomas> balloons, is there a way for me to do that myself?
<axw> thumper: with the "too many open files" thing, forget what I said about state objects being open during upgrade. that's still a problem for upgrades from 2.1, but 2.2.8 to 2.2.9 wouldn't have run any upgrade steps
<thumper> right
#juju-dev 2018-01-12
<babbageclunk> wallyworld: Please could you take a look at https://github.com/juju/juju/pull/8285?
<wallyworld> sure
<wallyworld> babbageclunk: should the default exclude list contain several more read only methods out of the box?
<wallyworld> babbageclunk: left some comments, happy to discuss
<babbageclunk> wallyworld: no, I don't think it should - I had a pretty big discussion with John about that in the last change. See discussion here: https://github.com/juju/juju/pull/8242#issuecomment-352670932
<babbageclunk> (sorry, off doing dinner and bath time - will look at the comment s in a bit.)
<wallyworld> ok
<wallyworld> babbageclunk: his point was to audit all write methods by default and filter out read methods. but i don't think an opinion was offered as to the value in logging lots of read only methods which really don't reflect changes to the system
<wallyworld> i can't see any point in recording that someone ran ListModels
<wallyworld> why is that any more interesting that Status
<wallyworld> do we have field input on this?
<wallyworld> babbageclunk: i'll be in and out - got to start packing, so if i don't respnd straight away, it's not that i'm ignoring you :-)
<tasdomas> morning
<tasdomas> could I get a review of https://github.com/juju/juju/pull/8262 ?
<babbageclunk> wallyworld_: The thinking isn't that ListModels is interesting, rather that it's pretty unlikely someone is running it so often that it would swamp the log (say, running it under watch).
#juju-dev 2018-01-14
<mup> Bug #1732004 changed: arm64 shows 1 vs. 96 cores via Juju GUI version 2.10.2 <juju-core:Expired> <https://launchpad.net/bugs/1732004>
