#juju-dev 2012-06-18
<rog> davecheney, fwereade: hiya
<fwereade> rog, heyhey
<TheMue> Morning.
<davecheney> morning all
<TheMue> davecheney: Hi
<twobottux> aujuju: How to SSH into local juju instance? <http://askubuntu.com/questions/152428/how-to-ssh-into-local-juju-instance>
<TheMue> Hmm, t-storm above our home.
<Aram> morning.
<TheMue> Aram: Hi
<voidspace> is this page still the "official" guide to writing charms?
<voidspace> https://juju.ubuntu.com/docs/write-charm.html
<voidspace> if so, then maybe it should start by referencing a directory that actually *exists* in juju trunk
<voidspace> having to check out juju trunk when you're using an installed juju is not the friendliest way of starting a tutorial as well
<voidspace> "Assuming the current directory is the juju trunk"...
<voidspace> anyway, just some friendly feedback :-)
<rog> niemeyer: yo!
<fwereade> voidspace, thanks for pointing that out :)
<fwereade> niemeyer, heyhey
<Aram> hi niemeyer.
<voidspace> fwereade: morning
<fwereade> voidspace, how's it going?
<voidspace> fwereade: mainly good :-)
<fwereade> voidspace, mainly glad to hear it then :)
<voidspace> fwereade: daughter has unexplained minor illness causing random temperature fluctuations
<fwereade> voidspace, aww :(
<niemeyer> Gooood morning all!
<voidspace> fwereade: but she's happy and lively, so not *much* of a problem :-)
<voidspace> niemeyer: morning
<voidspace> fwereade: and yourself?
<voidspace> our team is sprinting on getting us all up to scratch with juju this week...
<fwereade> voidspace, yeah, very good thanks
<fwereade> voidspace, ah, excellent
<voidspace> fwereade: so expect more "observations" on your documentation :-)
<fwereade> voidspace, they're greatly appreciated
<voidspace> hehe
<fwereade> voidspace, bug reports even more so ;)
<Aram> niemeyer: I have some errands to attend to, I'm talking half a day off and will recuperate it later this evening/night.
<voidspace> getting juju up and running with lxc inside a vm was astonishingly easy though - so kudos on that (using precise)
<niemeyer> Aram: Sounds good, thanks for the note
<voidspace> fwereade: want an issue for the charm writers guide?
<fwereade> voidspace, it's very cool, isn't it -- sadly I can't take much credit for that bit :)
<voidspace> fwereade: I wasn't 100% certain I was on the current-latest-correctest documentation page anyway
<fwereade> voidspace, that would be fantastic
<voidspace> heh
<fwereade> voidspace, if it's what you find when you look for the docs then I think that's something we should address
<voidspace> fwereade: yep
<fwereade> niemeyer, when you have a mo please let me know if I still appear to be on crack re relation types
<fwereade> niemeyer, I do think that RelatedService is applicable more widely than just in the unit agent
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: Maybe.. that comment was made on a bad foundation. I still had in mind the old interface of AddRelation
<fwereade> niemeyer, yeah, I was a bit surprised when I looked back at the python code and discovered that nobody ever paid any attention to the result of AddRelation
<fwereade> niemeyer, add_relation_state, rather
<niemeyer> fwereade: I still think eventually we'll need something that represents relations themselves, so we can more easily iterate. But that's a gut feeling rather than any kind of certainty, so I'm happy to see if we can tailor the model to something sensible for the use cases at hand
<fwereade> niemeyer, I can well believe that, but I don;t think we're there atm -- have you looked at the Relation type in python recently?
<fwereade> niemeyer, it has an internal_id property, and that's it :)
<niemeyer> fwereade: Good point :)
<fwereade> niemeyer, there's something else on my mind actually
<fwereade> niemeyer, consistency of the history that unit agents see
<fwereade> niemeyer, it really rather bugs me that we have a mix of zk-current and hook-queue-current state available when we're running hook
<fwereade> niemeyer, and I think it exposes us to bug that we only don't hit through sheer luck, and coincidental properties of the rest of the implementation
<niemeyer> fwereade: How so?
<fwereade> niemeyer, for example, what should we do when we ask ZK for the current relations in a -joined hook and it turns out that the relation we're supposed to be joining was just deleted?
<hazmat> fwereade, previously to relation-ids it all worked as expected
<hazmat> fwereade, the hook could use apis see a state current at time of execution, and delete hook exec would be pending
<niemeyer> fwereade: It's an excellent question, and we have several such issues all around the code base
<fwereade> hazmat, ok; but we can also do things like try to look up settings for a relation that doesn't exist any more, and that's only safe because we don't GC anything under /relations
<hazmat> fwereade, that wasn't a happy accident that was by design
<hazmat> fwereade, we don't gc things that could be in current use
<fwereade> hazmat, understood; but it feels to me like it'll be kinda tricky to ever GC relations given the current usage
<niemeyer> fwereade: There are two options.. either we cope with the fact that the relation is being removed and offer a sensible answer
<hazmat> fwereade, its quite simple actually.. no presence nodes, not in topology, its dead
<niemeyer> fwereade: or we tag the relation (or whatever object) as dead and allow the code to handle it in a timely way
<fwereade> hazmat, until some misfunctioning unit agent comes back up..?
<hazmat> fwereade, and it would come back up and see the rel doesn't exist
<hazmat> ie. it would check the topo
<fwereade> niemeyer, or alternatively, we snapshot settings just as we do membership, and have unit agents execute hooks against the histroy we snapshotted
<fwereade> hazmat, ok, GC isn't as tricky as I worried :)
<hazmat> fwereade, if its disconnected for a while and hasn't notified yet
<niemeyer> fwereade: Not sure I understand what that would mean
<hazmat> then it will come back up and queue a broken hook in a separate context, and with queue reduction that wins
<fwereade> niemeyer, hazmat: I may be missing something, but it seems to me that the unit agent gets notified of every relevant change to state, and can therefore keep a consistent local history through which it can run at its own pace (which isn't necessarily as slow as it might be, thanks to hook reduction)
<niemeyer> fwereade: It can't.. assume the unit is down when a change happens
<fwereade> niemeyer, it can; it has to know how to diff current state against its known latest state anyway
<niemeyer> fwereade: Well, yes, and that goes against "every relevant change to state on consistent local history", right?
<fwereade> niemeyer, I don;t see the tension there -- we always knew we might miss some changes, and we have queue reduction anyway... what's the difference?
<hazmat> fwereade, terminology, its not seeing every change, it seeing deltas
<hazmat> its
<niemeyer> fwereade: I'm just pointing out that "it's fine to miss some changes" and "every relevant change to state on consistent local history" are not friends.
<fwereade> hazmat, yeah, exactly
<fwereade> niemeyer, I'm saying that within the constraints we're used to, we can run every hook against the state we knew to exist at the time we detected the need for a hook to run (collapsed as necessary), rather than running against a mixed state
<fwereade> niemeyer, and I was wondering if there was an obvious downside to that strategy
<niemeyer> fwereade: We can't snapshot the whole state at once
<niemeyer> fwereade: Which means that by the time you discovered you had to run "joined", the state has already moved forward
<niemeyer> fwereade: So there doesn't seem to be much of a point to me to be getting a state that is arbitrary in a time before it is needed
<niemeyer> fwereade: But maybe I'm misunderstanding what you mean
<fwereade> niemeyer, we're already snapshotting membership, and using that; we're snapshotting settings versions, and using those to figure out when to collapse; we could do the same with the actual settings, n'est-ce pas?
<hazmat> its not really snapshotting
<hazmat> its tracking
<fwereade> niemeyer, when you do a relation-list, you're explicitly not getting the current related units; you're getting the units at the time the change was detected
<hazmat> its still broken though
<hazmat> er. not a snapshot
<fwereade> hazmat, go on
<hazmat> but conversely if you do a relation-get you do see a current value
<hazmat> that's cached for the hook exec
<niemeyer> fwereade: There's no way to get the data for multiple nodes at the same time.. it's a cache, rather than a consistent snapshot
<niemeyer> fwereade: relation-list might work better in the case of relation-joined, specifically, but it won't work well in the case of relation-changed, for example
<fwereade> hazmat, thatis rather my problem, that I'd be a lot more comfortable if we were grabbing the settings at the time they changed and using them
<fwereade> hazmat, I don;t think we'd ever be too far out of date, because of queue reduction
<hazmat> fwereade, agreed, these semantics are hard, without evolving a local state copy you can't be consistent throughout
<niemeyer> fwereade: Because you detecting the change and listing the relations are two operations
<niemeyer> fwereade: Done at different times
<niemeyer> fwereade: Yes, not too far out of date, but that's not the point.. if it is out of date, what are we trying to solve then?
<hazmat> fwereade, and even then its not clear that its truly consistent even then
<fwereade> niemeyer, (we're always out of date a little)
<niemeyer> fwereade: Exactly
<fwereade> hazmat, this is to me the most interesting bit... how do you see us being inconsistent with local state?
<niemeyer> fwereade: So doing a snapshot, say, 2 minutes ago so we can run a hook doesn't sound like solving a problem
<niemeyer> fwereade: Reduction is evidence that we actually don't care about the intermediate state
<hazmat> fwereade, well the question then is what is meant by consistent? that all values ever show to a hook are true as of the time of its related change event mvcc style?
<niemeyer> fwereade: We just try to bring the unit aware of the latest state
<fwereade> niemeyer, then why do we bother doing what we do with relation-list in the first place?
 * hazmat needs some coffee to correct typos
<fwereade> niemeyer, I think I'd be comfortable with either "you always get current state" or "you always get consistent state"
<fwereade> niemeyer, but it feels liek we're mixing the two and it makes my head hurt a little
<rog> fwereade: +1
<niemeyer> fwereade: Current is impossible, as we both know..
<fwereade> niemeyer, and "current" has the problem that we could then be running relation-joined against some remote unit which relation-list tells us doesn't exist
<rog> i wonder if we wouldn't be better having simple "something has changed"-style notifications
<fwereade> niemeyer, "latest known" then
<fwereade> niemeyer, but regardless, I agree that whatever you call it, it has problems
<niemeyer> fwereade: Let's talk about relation-changed.. what do you suggest we do regarding relation-lsit?
<hazmat> fwereade, so re not clear, there's also cross context manipulation now, you have to have a linear view across relations
<hazmat> ie. relation-set from rel-a-hook to rel-b-hook
<fwereade> niemeyer, AIUI what we currently do is keep track of which units have joined/departed according to local state, and always give that when asked to relation-list
<hazmat> er.. rel-b
<fwereade> hazmat, can you expand a little? I don't *think* that hurts us... but I'm probably missing something
<fwereade> hazmat, a unit agent only sets its own settings, right? and that's in response to hooks running relation-set... and so that's automatically synchronised, isn't it?
<niemeyer> fwereade: We could snapshot the state of the relation the specific hook is part of before we start the hook, if that's not done today
<niemeyer> fwereade: Is that what you mean?
<fwereade> hazmat, a unit's own settings will always reflect whatever it's decided to set given the hook that have so far been handled
<niemeyer> fwereade: or rather, what you are suggesting?
<fwereade> niemeyer, yes, I'm just suggesting that when we detect a settings change we store the settings as part of the history rather than just the fact of a change
<fwereade> niemeyer, and that that is strictly more consistent than what we have now, and makes my head hurt less :)
<fwereade> niemeyer, (and hopefully will make life less confusing for people when they're debugging tricky relations)
<niemeyer> fwereade: How does that improve things?
<niemeyer> fwereade: As we just discussed, when we detect that settings have changed, and go to get that, it's already out-of-date
<fwereade> niemeyer, if we can divorce hook execution environments from zookeeper state (apart from the unit writing its own relation settings) we can eliminate having to think about an entire class of whoops-zk-changed-in-a-confusing-way situations
<niemeyer> fwereade: Why is that out-of-date state any better than the out-of-date state we get when we actually run the hook?
<hazmat> fwereade, right now the state tracking is mostly in independent relation contexts, it works cross relation through benefit of the db giving us a linear time view (albeit with per rel queue reduction), the point i was trying to raise is that we have cross relation activity now from hooks. i don't think its insurmountable if the linear view across relations is maintained, but it is something to keep in mind. ie any rel-a hook could change settings on a rel-b
<hazmat>  thing.
<rog> niemeyer: FYI continuing weird behaviour with bzr (i've been stuck on it all morning). http://paste.ubuntu.com/1047256/  time to lose the branch, i think. if bzr is this broken, lbox has no hope.
<fwereade> hazmat, ...whoa, ok, I missed that
<fwereade> hazmat, how is that OK?
<hazmat> fwereade, its not without some careful thought ;-) but generally it can work because we have a linear view of events changes across relations that the cache is kept up to date for, but it does require thought to the cache maintenance wrt to queue reduction
<fwereade> hazmat, we're talking about a foo-relation hook on unit X relation A changeing settings on... unit X relation B?
<niemeyer> fwereade: How is it not ok?
<hazmat> fwereade, yes
<fwereade> niemeyer, hazmat: it's not *necessarily* not ok, but it's a surprising extra channel
<niemeyer> rog: Sorry, I can't really help since I can't reproduce the issue locally
<niemeyer> fwereade: I find it pretty straightforward
<rog> niemeyer: yeah, i have no idea. just thought you might be interested to see the bizarreness.
<hazmat> rog, naked bzr works pretty well.. i kept running into issues with cobzr and gave it up
<fwereade> niemeyer, ok, as long as it's all on the same unit, that's fine
<niemeyer> hazmat: FWIW, I use it for every single bzr branch
<niemeyer> fwereade: It is, the property "relation-set only changes myself" is sustained
<rog> hazmat: i've never had a problem before. i think i mucked things up when i accidentally did a bzr commit as root.
<hazmat> rog, interesting.. easy to fix with a chown.
<fwereade> niemeyer, cool, I misunderstood on first reading, thought we were talking about something altogether more disturbing
<rog> hazmat: that was the first thing i did
<niemeyer> fwereade: So, still trying to understand what you mean
<niemeyer> fwereade: Just so you get the background..
<niemeyer> fwereade: The idea of caching comes from giving people consistent answers across calls that read data from a remote unit, to make things a little more saner
<niemeyer> fwereade: E.g. (relation-get username + relation-get password) will get data for the same person
<rog> would someone be able to explain to me why what thing changes which relation settings is important here?
<hazmat> niemeyer, also applies to the local unit reads via the writeback cache
<niemeyer> hazmat: Rihgt
<niemeyer> fwereade: So, you can see our model as "latest known state, snapshotted on first query"
<fwereade> niemeyer, per queried unit, yeah
<fwereade> niemeyer, and apart from the actual list of units, which is from longer ago
<fwereade> niemeyer, none of these things *seriously* bother me
<rog> i.e. why is cross-relation activity a difficulty?
<niemeyer> rog: It's not.. was a red herring
<rog> niemeyer: ok, thanks.
<fwereade> niemeyer, but I'm equally not sure wat benefit we derive from having two different "now" states in play at a time
<niemeyer> fwereade: We have N "now" states.. we have data from a distributed system, where each detail is arbitrarily old and invalid
<hazmat> niemeyer, it can be
<hazmat> niemeyer, with an attempt to have a consistent cache.. at least in the dictates of the py impl
<fwereade> niemeyer, ok, but we have ordering guarantees from ZK, right?
<niemeyer> fwereade: zk has ordering guarantees.. I don't know what you mean, though
<hazmat> niemeyer, each rel has a separate queue subject to reduction rules, if a hook corresponding to event 3 in rel B executes at a time before a hook corresponding to event 2 in rel A, and they cross communicate it is an issue.
<rog> fwereade: i'm with you, but i think for a slightly different reason. we *do* have potential consistency problems, but i think they should be solved as close to source as possible. so watchers should detect inconsistency if possible and act appropriately. by the time we get to the actual agent, all the information should be available in processed form.
<niemeyer> hazmat: I don't know what you mean by "cross communicate".. hooks don't communicate
<fwereade> niemeyer, I'm just not 100% convinced that it's never going to break anything if we get settings newer than the relation list
<hazmat> niemeyer, cross communicate -> i mean hook in rel B modifies rel A setting
<niemeyer> hazmat: I don't see any issue there
 * fwereade cig/assimilate break, 3 mins
<niemeyer> hazmat: Yeah, don't see any issue there
<niemeyer> fwereade: Cool, let's talk when you're back
<niemeyer> fwereade: FWIW, I find your concern great.. it's nice to have that kind of problem in mind
<niemeyer> fwereade: Let's figure the way we *want* relation-list and hooks to interact
<hazmat> niemeyer, its only problematic for attempting to maintain a consistent view for each hook, because hook B modified settings in a separate rel using a different consistent view then the present time of the other rel. the linear view of time is subject to some jumps because of how we reduce the queue, it is consistent but only to a rel context, cross rel communication, requires a linear view that is scoped at a higher level to achieve consistency
<rog> niemeyer: trying to get my head clear around this. this is only a problem because we're not getting all the info from a watcher, right? so the action that an agent is taking depends not only on the data received from the watch, but also some data that it reads from zk later?
<niemeyer> hazmat: Sorry, I still don't see the problem.
<hazmat> again it depends on what you looking for consistency, fwereade was looking for something akin to mvcc (ie. snapshot isolation)
<fwereade> niemeyer, heh, I think what I just thought is what hazmat just said
<niemeyer> hazmat: "B modified settings in a separate relation"..
<niemeyer> hazmat: That's sequential
<niemeyer> hazmat: Hooks aren't executing in parallel
<rog> i don't think we can guarantee consistency across relations.
<hazmat> niemeyer, but they are subject to time skips due to reduction
<niemeyer> hazmat: Not time skips, no
<niemeyer> hazmat: They are subject to ignoring events and acting on the latest known state, yes
<hazmat> niemeyer, right their linear advancing, but yes the clock does skip event ticks
<niemeyer> hazmat: I don't think that changes anything with regards to relations in different contexts, though
<hazmat> it works now because we feed all of them (hook exec queues)  into a linear scheduler
<hazmat> yeah.. it might be a red herring
<niemeyer> hazmat: A hook executing for relation A, B, C, or D, and doing changes for relation A, B, C or D, has the system as consistent as if the hook was doing changes on a single relation
<rog> niemeyer: i don't think it does
<fwereade> niemeyer, when relation B changes relation A's settings, it could plausibly affect how relation A acts... right?
<rog> niemeyer: because the settings for each relation are in a different zk node
<niemeyer> fwereade: Yes, hopefully :)
<rog> niemeyer: and we can reorder zk watch firing across different nodes
<fwereade> niemeyer, and if relation A doesn't have access to the same view of history that B used to make that change to A, I think we could end up in confusing states
<fwereade> niemeyer, maybe it all shakes out, but I haven't convinced myself of that yet
<hazmat> i'd need to white board to work it out, i haven't worked through it with the new cross rel communication work in, its something that needs thought though.
<niemeyer> rog: DOesn't matter in that case we're discussing. We don't order those events.
<hazmat> s/thought/verification
<niemeyer> fwereade: I don't see how that's an issue
<niemeyer> Quick break, biab
<hazmat> rog, how's the upgrade work coming?
<rog> hazmat: i finished that upgrader thingy. but it's judged premature for the time being, so i've put it on ice. currently working on parallel stuff towards the machine agent.
<fwereade> niemeyer, ok, let's say B has set some setting per related unit on A, based on "current" state at the time a hook ran for B; and A then runs a hook, based on a new and incompatible "current" state for A; this feels liable to lead to upset and confusion
<hazmat> rog, cool.. i got inspired to work on it as well
<fwereade> niemeyer, whereas if B and A are both working with the same history, the "current" states don't matter -- both B and A will agree on (say) what units A is currently related to
<hazmat> rog, although its turning out to be a lot more work than i had hoped.
<rog> hazmat: yeah, i found that. but it wasn't too bad. if you want to copy the protocol, the code is here https://codereview.appspot.com/6307061
<rog> hazmat: i had a plan to automatically generate test permutations, but didn't get quite that far.
<hazmat> rog, i eschewed the separate process for minor upgrades
<rog> hazmat: ah, cool.
<rog> hazmat: where are you finding the main difficulties?
<hazmat> rog, i want to get to major upgrades though, which is where things get interesting.. else i'll never be able to merge any of the scaling work (json switch)
<niemeyer> fwereade: That's a good direction for us to explore.. it'll be easier to get a point across with examples indeed
<niemeyer> fwereade: I don't understand yours, though
<niemeyer> fwereade: Let me try to translate
<hazmat> rog, no part in particular is difficult.. i ended up going with some new abstractions (state protocols), its just a lot of pieces.
<niemeyer> fwereade: We have two units, A and B, is that what you mean?
<fwereade> niemeyer, two relations within the same unit
<niemeyer> fwereade: Okay, so let's call two relations R1 and R2
<niemeyer> fwereade: and two units A and B
<niemeyer> fwereade: Are R1 and R2 both between A and B?
<fwereade> niemeyer, let's say yes
<niemeyer> fwereade: Okay
<fwereade> niemeyer, well, heh, R1 and R2 are each between the respective services of A and B
<niemeyer> fwereade: So you mean that we have a hook R1-relation-changed executing within A?
<fwereade> niemeyer, yes; and R1-relation-changed sets something on A.R2's settings
<niemeyer> fwereade: Okay, I'm with you
 * fwereade thinks a mo, maybe it doesn't matter... just a sec
<fwereade> niemeyer, ok, thinking aloud... R1 sets a key in A.R2 per unit related to A, which is currently [B]
<niemeyer> fwereade: Okay
<fwereade> niemeyer, B departs, and B' joins
<niemeyer> fwereade: C joins, please :)
<niemeyer> fwereade: Or you mean B joins again?
<fwereade> niemeyer, ok, C joins
<fwereade> niemeyer, now, I meant another unit of the service that B was a unit of
<niemeyer> fwereade: Okay, let's call it C since the service relation doesn't really matter in this case.. it's a different unit in the relation
<fwereade> niemeyer, yep, ok
<fwereade> niemeyer, so, given the delays etc in play, we could well have a situation in which A.R1 still thinks it's related to B, but A.R2 thinks it is now related to C
<niemeyer> fwereade: Oops, hold on
<fwereade> niemeyer, A.R2 thinks A.R1 is now related to C
<niemeyer> A.R1 doesn't think anything.. this is a settings node
<niemeyer> fwereade: Neither does A.R2
<fwereade> niemeyer, yes: A.R1 is a node distinct from A.R2 though
<niemeyer> fwereade: Yes, and neither of them "think" anything.. they are state
<fwereade> niemeyer, s/thinks/has written state predicated on the assumption that/
<niemeyer> fwereade: Yes, and that's not a problem..
<niemeyer> fwereade: R1-relation-joined will be called for C
<niemeyer> fwereade: and A will have a change to do whatever it pleases with it
<niemeyer> fwereade: If the person maintaining the charm for A is doing crazy stuff that makes no sense, though, we can't avoid it
<fwereade> niemeyer, I think I agree that we will eventually reach a steady state in which everything makes sense
<niemeyer> fwereade: Yep, that was the main thinking
<fwereade> niemeyer, but it seems wrong to let C see A.R1's settings in a state wildly divergent from A.R2's settings
<fwereade> niemeyer, the eventual consistency may indeed trump all though
<niemeyer> fwereade: You've lost me now
<niemeyer> A.R1 and A.R2 were both set solely by A..
<niemeyer> fwereade: There's no way for them to be "divergent"
<fwereade> niemeyer, the "wildly divergent" is hyperbolic, but is meant to indicate that A.R1 could respond to 30 events before A.R2 responds to any
<fwereade> niemeyer, unless we're thinking a little about the cross-relation stuff alluded to above
<fwereade> niemeyer, I think that would take a pathological scheduling situation and it might be impossible but I can't comfortable state that I'm certain it is impossibvle
<niemeyer> fwereade: We can improve the scheduling algorithm over time to make events across relations "fair", in case they don't naturally get fair
<niemeyer> fwereade: We've lost the use of practical examples, though
<fwereade> niemeyer, well observed
<fwereade> niemeyer, I might have to try to turn this into an email
<niemeyer> fwereade: R1-relation-changed can *really* have 30 events happening before R2-relation-changed happens
<rog> fwereade, niemeyer: is it this kind of scenario we're potentially concerned about? http://paste.ubuntu.com/1047364/
<niemeyer> rog: I'm not aware of any scenario we're concerned about, after the above conversation
<fwereade> rog, I don't follow that I'm afraid
<niemeyer> rog: The password case I mentioned works today
<rog> niemeyer: yes, but it  might not work if the username and password were stored in different relations, right?
<niemeyer> rog: That's an artificial example that we're not concerned about
<rog> niemeyer: ok. i was trying to understand fwereade's concerns, sorry.
<niemeyer> rog: No worries, I'm just explaining what I've been discussing with fwereade
<rog> niemeyer: i was trying to come up with a concrete example of
<rog> [15:08:36] <fwereade> niemeyer, but it seems wrong to let C see A.R1's settings in a state wildly divergent from A.R2's settings
<rog> niemeyer: of course, it *is* an artificial example
<niemeyer> rog: See my comments that follow that :-)
<rog> niemeyer: and i'm happy for us to say that settings are only consistent within a relation.
<niemeyer> rog: Cool, that's a given today, and I agree it doesn't feel useful to go over the trouble
<niemeyer> fwereade: Okay, can we go back to that branch we were talking about when the conversation diverged?
<rog> niemeyer: i do think that it might make sense to make the agents use info read by the watchers though, rather than going into the zk state again. it would mean the watchers can detect inconsistencies early on and produce a consistent-looking stream of events which will lead to determinstic actions.
<niemeyer> rog: The agents use info read by the watchers today.
<rog> niemeyer: if they do, that's no problem. i seem to remember that wasn't the case though.
<niemeyer> rog: They do. Of course, there are a lot of details about this, but those details should be taken into account when saying "we should do foo".
<niemeyer> rog: The whole conversation above was exploring those details
<rog> niemeyer: looking at this before, it seemed to me that more stuff needed to be cached in the state types for this to be true. but perhaps things have changed, or the agents don't need as much info as i thought.
<niemeyer> rog: Sorry, but I really don't know what you're suggesting.
<rog> niemeyer: one example: when the machine agent is watching units for a machine, it sees the topology change and sends a *Unit down a channel. by the time the agent comes to ask the unit for its CharmURL, the unit might be gone.
<rog> niemeyer: on a completely different subject: how do you feel about the possibility of using build tags for conditional tests instead of flags? (i'm thinking of -amazon here, to start with)
<niemeyer> rog: I've seen the thread.. sounds fine, but we shouldn't be worrying about this right now
<rog> niemeyer: i'm just about to add another flag, and it seems a bit wrong. and it's awkward to test everything with the flags.
<rog> niemeyer: it would be quite and easy to change
<rog> s/quite/quick/
<niemeyer> rog: What flag are you adding?
<rog> niemeyer: -root
<niemeyer> rog: Hmm.. why do we need it?
<rog> niemeyer: because the only way of testing the container package with any usefulness is to run the tests as root
<rog> AFAICS
<niemeyer> rog: I can't see why that would be the case right now
<niemeyer> rog: We're not adding support for LXC today
<rog> niemeyer: not possible to add upstart scripts without being root
<rog> niemeyer: i could just leave out testing entirely
<niemeyer> rog: You can add upstart scripts to a path that you define
<rog> niemeyer: putting yet another shim second-guessing what commands the upstart package will be invoking seems wrong
<rog> niemeyer: really? running upstart myself, then?
<rog> niemeyer: i hadn't tried that.
<niemeyer> rog: Yes, that actually works
<niemeyer> rog: Although I'd probably just verify that the script was put in place
<niemeyer> rog: Well, depending on what else is being tested in that path
<rog> niemeyer: i quite like having a test that really verify that it actually works with upstart for real.
<niemeyer> rog: Either way, definitely not require root for tests
<rog> niemeyer: indeed.
<rog> niemeyer: hence the flag.
<niemeyer> rog: Those will be run close to never
<rog> niemeyer: same as the amazon tests :-)
<niemeyer> rog: Not really.. I run those fairly frequently
<niemeyer> rog: I don't run *any* test suite as root, though
<rog> niemeyer: really? when was the last time you did? last few times they've failed for me.
<niemeyer> rog: We may need that for LXC, unfortunately
<niemeyer> rog: For EC2/S3, every single time I change the tests
<rog> niemeyer: that's why i thought it was reasonable to do it now.
<niemeyer> rog: We're not implementing LXC now
<niemeyer> rog: Are you working on LXC?
<rog> niemeyer: nope
<niemeyer> rog: So I'm lost
<niemeyer> rog: Only need for LXC => That's why I'm doing it now => Doing LXC? => No => Vhat geev?
<rog> niemeyer: i thought that since the container package was going to need to have root tests eventually, and that the current tests are more effective running as root, that it would be reasonable to have root tests there now.
<niemeyer> rog: Testing as root is bad practice, and you know that
<rog> niemeyer: i agree. but how do you suggest i provide a meaningful test of this code: https://codereview.appspot.com/6312044/diff/1/container/container.go
<rog> ?
<rog> niemeyer: second-guessing what the upstart package is going to do seems wrong to me
<niemeyer> rog: Please have a look at how fwereade tested the upstart package
<rog> [15:45:50] <rog> niemeyer: second-guessing what the upstart package is going to do seems wrong to me
<rog> i can't test this without knowing exactly what commands upstart is going to call, where it's storing the files, what they look like, etc
<niemeyer> rog: Sorry, but I don't know what that means.. I'm suggesting having a look at the technique used by the upstart package to test things
<niemeyer> rog: The actions from these package look trivial
<rog> niemeyer: they are
<niemeyer> rog: I hope we can find a trivial way to test them
<rog> niemeyer: i haven't succeeded yet!
<niemeyer> rog: that doesn't involve running them as root
<rog> niemeyer: suggestions very welcome.
<rog> niemeyer: i've looked at the upstart tests BTW
<rog> niemeyer: anyway, gotta go to the dentist. back in a bit.
<niemeyer> rog: Isn't this merely writing a file on disk right now?
<niemeyer> rog: I hope we don't need root to test that! :-/
<niemeyer> fwereade: ping
<fwereade> niemeyer, pong
<rog> niemeyer: yes. but to verify that file, i've got to know what file is written and what it looks like. given that the upstart package itself doesn't have a single test that actually verifies that it really works with upstart, we should do that *somewhere* i think.
<niemeyer> <niemeyer> fwereade: Okay, can we go back to that branch we were talking about when the conversation diverged?
<niemeyer> rog: Okay.. if you can't figure how to test that file, please move on to something else and I'll figure it.
<niemeyer> rog: It's a trivial text file
<fwereade> niemeyer, probably, if you tell me where you consider it to have diverged...
<niemeyer> rog: That somewhere is the upstart package, by the way..
<niemeyer> fwereade: I just mean following up the conversation
<niemeyer> fwereade: We were talking about the CL and then moved on to something else.. I'd just like to see what we do with it
<fwereade> niemeyer, ah, cool, the RelatedService one
<niemeyer> fwereade: Yeah
<fwereade> niemeyer, well... not sure where to go really: have I allayed your fears somewhat?
<niemeyer> fwereade: Yeah, I'm happy with the overall concept
<niemeyer> fwereade: I'm not entirely happy with the type and method itself, though
<fwereade> niemeyer, ah, ok, go on
<niemeyer> fwereade: The data in the RelatedService method feels very weird to me
<niemeyer> fwereade: It alludes a bit to that conversation we had the other day
<niemeyer> fwereade: About how we store data
<niemeyer> fwereade: I'm looking at https://codereview.appspot.com/6307099/diff/1/state/service.go
<fwereade> niemeyer, I'm more than happy to stick "relation" on the front of everything
<niemeyer> fwereade: Line 239
<niemeyer> fwereade: Not about naming.. about the actual data
<fwereade> niemeyer, ah, ok, the RelatedRole?
<fwereade> niemeyer, or the totality of bits of data that make up RelatedService?
<niemeyer> fwereade: If s is service A, with a requirer relation R1 named "cache".. this is storing {A, R1, provider(!)}
<niemeyer> fwereade: If s is service A, with a requirer relation R1 named "cache".. this is storing {A, R1, "cache", provider(!)}
<niemeyer> (added the name)
<fwereade> niemeyer, whoa, I would appear to be totally on crack there
<niemeyer> fwereade: This RelatedService is *not* the remote service.. this is the *local* idea of a relation for service s.. look at the service key in the data.
<fwereade> niemeyer, I switched that back and forth several times, must have desynchronised myself
<niemeyer> fwereade: The previous doc for the type, and the data stored in the relation, was apparently right
<fwereade> niemeyer, my intent there was to store the *other* service, and its role
<niemeyer> fwereade: Yeah, I'm not sure it's right, though
<fwereade> niemeyer, well, the relationKey and scope are the same on either side
<niemeyer> fwereade: The relation key and scope are.. the relation role and relation name are not
<niemeyer> fwereade: We're losing those
<fwereade> niemeyer, the relation name should IMO come from the local side, and the role and service key from the remote side
<niemeyer> fwereade: Exactly.. that sounds a bit messy to be honest
<fwereade> niemeyer, but I'm pretty sure that that is the actual data we need
<fwereade> niemeyer, it's everything about the remote service, plus the local name for that service
<fwereade> niemeyer, ok not for the service
<niemeyer> fwereade: ;-)
<fwereade> niemeyer, for the relation through which we are connected to that service
<fwereade> niemeyer, hell, just "for the relation"
<niemeyer> fwereade: You're getting into the confusion that I'd like to avoid :-)
<niemeyer> fwereade: At the moment s.Relations() returns the participation for s in all its relations
<niemeyer> fwereade: {s.key, relation key, relation name, relation role}
<niemeyer> fwereade: All of that data is for *s*
<fwereade> niemeyer, yes, that is true; and it looks nice and simple there, and then we have to collect all the remote data later
<fwereade> niemeyer, which is not so nice and simple, and happens more than once
<niemeyer> fwereade: Yep, we can add another call which is also nice and simple that returns the other services participating in the same relation
<niemeyer> fwereade: and in fact we should cache that data so we don't have to query it again
<fwereade> niemeyer, what would you call that other method?
<niemeyer> fwereade: Relation.Services?
<niemeyer> fwereade: Alternatively,
<fwereade> niemeyer, ah, so you're suggesting a top-level Relation type?
<fwereade> niemeyer, it really feels like just one more step to go through
<niemeyer> fwereade: I'm trying to imagine how to solve it rather
<niemeyer> fwereade: Another suggestion:
<niemeyer> func (s *Service) Relations() ([][]*ServiceRelation, err error)
<niemeyer> fwereade: One relation per entry
<fwereade> niemeyer, ok, and then we still have to go through the leaves discarding or not-discarding the various Servicerelations that refer to the original service
<niemeyer> fwereade: First ServiceRelation in the relation is guaranteed to be s
<fwereade> niemeyer, picking what to do based on the length of the []ServiceRelation is kinda nasty though
<fwereade> niemeyer, IMO the advantage of RelatedService is it's something that all the clients I'm aware of can treat the same regardless of role or scope
<niemeyer> fwereade: Doesn't have to be based on the length.. l[0].RelationRole()
<niemeyer> fwereade: The disadvantage is that it's mixing up roles and services in a way not seen anywhere else
<niemeyer> fwereade: We AddRelation() a list of endpoints.. we add-relation a list of relations with service:rel on the same side.. etc
<niemeyer> fwereade: We store them in the topology in the same way..
<fwereade> niemeyer, it doesn't seem to me to be enormously controversial to suggest that user-facing representations of data do not necessarily map perfectly to internal representations of same
<niemeyer> fwereade: The internal representation is *also* the same..
<niemeyer> fwereade: topology stores data exactly like that
<niemeyer> fwereade: This is an edge case not seen anywhere else
<fwereade> niemeyer, ...and in different contexts internally, the same data sometimes wants to be stored in different ways
<niemeyer> fwereade: and one of the reasons why it is an edge case is that it's being customized for a representation that so far we don't enforece
<niemeyer> fwereade: enforce
<niemeyer> fwereade: Relations can have three services today, if we choose to
<niemeyer> fwereade: and as we debated today, this isn't so far fetched (e.g. peer relations)
<niemeyer> fwereade: I'm not suggesting we start implementing that now, but it sounds silly to start designing things in a way that is unlike everything else and make that impossible
<niemeyer> fwereade: (when we can trivially not)
<fwereade> niemeyer, it strikes me as a lot of speculative generality... AFAICT multi-peer relations should remain easy whatever I do here, and pro/req remain brain-bendingly hard
<fwereade> niemeyer, I feel that you're less happy with the general concept than perhaps you thought... either the RelatedService concept is sane, in which case by its nature it ends up combining useful bits of data from potentially more than one service... or it's not, and we have amore fundamental disagreement in play :)
<niemeyer> fwereade: I would agree on the speculative generality if we were not in a situation where everything else works the same way.
<niemeyer> fwereade: and if we didn't have an option at hand that was trivial to implement.
<niemeyer> fwereade: What you're suggesting is a departure from what we have now,
<niemeyer> fwereade: And you just mixed up both sides while *suggesting it* above
<niemeyer> fwereade: I'd really appreciate if we could find a model that was not like that
<niemeyer> fwereade: Doesn't have to be my suggestion, though. You know the constraints and concerns we have. Anything else that solves these issues is also fine.
<fwereade> niemeyer, I mixed it up in the aftermath of a long conversation, involving many of us, which would seem to imply that the whole subject is not quite as simple as it might at first appear
<niemeyer> fwereade: In my humble opinion, you've mixed up in the precise place I'm concerned about, because it is confusing.
<niemeyer> fwereade: Having {service key, relation key, relation name} where relation name is not for {service key, relation key} is *extremely* confusing and unnecessary.
<fwereade> niemeyer, ok.... I'll think some more
<fwereade> niemeyer, I'm just very reluctant to remake the mistakes we made in the python version and then duplicated in the go version
<fwereade> niemeyer, (it's just a doc issue... the docs in both places claim a perspective that is not accurate)
<fwereade> niemeyer, maybe fixing the types to match the docs is not the right way though
 * fwereade cig, think
<niemeyer> fwereade: I've been explaining why it's not just a doc issue.. we have a model used across the board
<niemeyer> fwereade: and this is not it
<niemeyer> fwereade: I'm not suggesting we follow blindly what we do with Python, though
<niemeyer> fwereade: You've been making changes to the relation stuff that have been accepted
<fwereade> niemeyer, that wasn't what I was trying to imply, sorry
<fwereade> niemeyer, how would you feel about something with the same core idea, but hopefully a little more explicit and less confusing: {remoteServiceKey string, relationKey string, localEndpoint RelationEndpoint}?
<fwereade> niemeyer, combining "what we're connected to" and "how we're connected to it" without leading to the confusion you rightly disapprove of
<fwereade> niemeyer, (I would still say that having all the existing types documented to embody a perspective that they actually don;t *is* a doc issue)
<niemeyer> fwereade: Where are we doing this today?
<fwereade> niemeyer, // ServiceRelation represents an established relation from
<fwereade> / the viewpoint of a participant service.
<niemeyer> fwereade: As far as I understand, that is true with the current implementation
<niemeyer> fwereade: It's not great, though, I agree
<fwereade> niemeyer, ha, yes, I see that... :(
<niemeyer> fwereade: What about [][]RelationEndpoint?
<niemeyer> fwereade: We wouldn't even need the RelatedService/ServiceRelation red herring
<niemeyer> fwereade: This is pushing in the direction you were already doing too, with AddRelation(endpoints...) and RemoveRelation(endpoints...)
<fwereade> niemeyer, hmm, there's still a certain amount of tomfoolery necessary to extract the data we care about in both the unit agent and in status
<niemeyer> (no docs!)
<niemeyer> fwereade: I don't see how it's any worse than the RelatedService interface, to be honest
<niemeyer> fwereade: rels := s.Relations(); for i, endpoints := rels { ... }
<niemeyer> fwereade: rels := s.Relations(); for i, endpoints := range rels { ... }
<niemeyer> fwereade: That's really it
<niemeyer> fwereade: With the additional guarantee that endpoints[0] is always for s
<niemeyer> fwereade: and len(endpoints) > 0
<fwereade> niemeyer, plus fooling around to determine which endpoint we care about, which the s[0] thing doesn't address
<niemeyer> fwereade: This sounds really easy to deal with
<niemeyer> fwereade: That went over my head
<fwereade> I guess s[len(s)-1] is not too hard
<niemeyer> fwereade: INdeed, and I bet that we'll need to special case the peer case anyway
<fwereade> niemeyer, the point of this is to avoid special-casing peers
<niemeyer> fwereade: Yeah, I understand, I'm saying that I suspect we'll need to be careful about it anyway
<niemeyer> fwereade: Peer relations are established by hand, etc
<niemeyer> fwereade: Erm, manually by juju
<fwereade> niemeyer, yeah, that is also something that bugs me
<fwereade> niemeyer, but not all that much :)
<niemeyer> fwereade: I quite like the above interface, actually.. it seems quite appropriate that we can, for example, iterate over the results of s.Relations() and use the result to call state.RemoveRelation(endpoints...) directly
<fwereade> niemeyer, yeah, I don't have a strong negative reaction to that one
<fwereade> niemeyer, I'll see where I can take it
<niemeyer> fwereade: I also love the fact we don't have to document ServiceRelation :-)
<fwereade> niemeyer, ha, yeah :)
<fwereade> niemeyer, offhand it seems this *does* imply a Relation type... {key string endpoints []RelationEndpoint}
<niemeyer> fwereade: Indeed.. but is it any better than [][]RelationEndpoint?
<niemeyer> fwereade: For that specific use case?
<niemeyer> fwereade: I see this as []Relation
<niemeyer> fwereade: We just happened to have leaning towards representing Relation as []RelationEndpoint, apparently
<fwereade> niemeyer, ...hmm, I guess I can keep the relation key out of it for a while
<niemeyer> have been
<fwereade> niemeyer, we can grab it from the topology when we need it
<niemeyer> fwereade: I'm not suggesting that's a bad idea, by the way.. sounds like a perfectly good type
<niemeyer> fwereade: We might just hold off a bit to see if we need it as such in practice
<niemeyer> fwereade: If you feel the logic would be more sensible with it, I'd be happy too
<niemeyer> fwereade: (e.g. maybe we do need the relation key materialized for the algorithms)
<fwereade> niemeyer, I'm sure enough we'll want it soon that I'd like to wrap the []RelationEndpoint in  a Relation type, even if I leave the key out until it's needed
<niemeyer> fwereade: +1 then
<fwereade> niemeyer, just to reduce the churn from []RelationEndpoint to *Relation
<fwereade> niemeyer, cool, I'll see what I can do with that
<niemeyer> fwereade: We can have  the key from the get go.. sounds sensible enough even if unused
<fwereade> niemeyer, even better :)
<niemeyer> fwereade: Woohay agreement
<niemeyer> :)
<fwereade> niemeyer, thank you... as usual, I feel wiser :)
<niemeyer> robbiew: Do we have the cloud consistency call today?
<robbiew> niemeyer: let me check with zaid
<niemeyer> fwereade: My pleasure, love those conversations too
<niemeyer> robbiew: Cool, leaving for lunch now.. will be back on time no matter what
<robbiew> niemeyer: bet on it being cancelled
<hazmat> robbiew, ? why
<robbiew> hazmat: b/c sabdfl isn't here ;)
<hazmat> cool
 * hazmat lunches
 * rog is in need of a good name. The provisioning agent has ProvisioningAgent (the command) and Provisioner (the implementing type, renewed when the state connection fails). I'm looking for an equivalent to Provisioner for the machine agent.
<rog> i'm wondering about machineAgent, but that might be confusing.
<niemeyer> rog: MachineAgent + Machiner? :-)
<rog> niemeyer: Machiner seems weird though. i did think of that.
 * rog didn't see the smiley
<niemeyer> rog: It does sound weird, but I was only half-joking ;)
<rog> niemeyer: ok, Machiner it is for the time being, pending better thoughts
<niemeyer> rog: Sounds good
<niemeyer> mramm: ping
<fwereade> rog, hmm, Uniter is actually a surprisingly good name for what the unit agent does, too :)
<rog> fwereade: unite all the rest of the juju functionality in one command, you mean?
<fwereade> rog, it also unites various services, if you squint
 * rog can't squint that hard :-)
 * fwereade has -6.5, -7.0 eyesight and can squint with the best
<niemeyer> fwereade: RelatedFoo tends to be a bad name to refer to something that is part of a relation
<niemeyer> fwereade: Everything there is related
<fwereade> niemeyer, crap, you're absolutely right, but Counterpart didn't seem quite right there
<fwereade> niemeyer, still, if I can teach myself to default to that every time I want to type Related it'd probably be better, wouldn't it
<niemeyer> fwereade: Right.. and this seems related to a more fundamental issue
<niemeyer> fwereade: *Relation* shouldn't have these methods
<niemeyer> fwereade: For the reasons we discussed earlier.. a Relation has no side
<fwereade> niemeyer, hence the unordered endpoints
<fwereade> niemeyer, my feeling was that the serviceName specified a side quite well
<niemeyer> fwereade: Hm.. how so?
 * fwereade is really glad he's talking about this now and not just seeing the review tomorrow am ;)
<fwereade> niemeyer, back up a sec: do you have a problem with (*Relation)Endpoint(serviceName string) (RelationEndpoint, error)?
<fwereade> niemeyer, or just with RelatedEndpoint(serviceName)
<niemeyer> fwereade: Hmm
<niemeyer> fwereade: The former sounds totally fine
<fwereade> niemeyer, I freely admit the name of the latter is awkward
<fwereade> niemeyer, I *think* it's a valid thing to ask for though
<niemeyer> fwereade: I'm starting to think we should go back on CounterpartRole, or at least make it private..
<niemeyer> fwereade: This seems to have been guiding your thinking in those branches
<rog> fwereade: OtherEndpoint ?
<fwereade> niemeyer, not consciously...
<niemeyer> fwereade: and I would prefer to not create APIs that sparkle these assumptions on the whole code base
<niemeyer> fwereade: There's no RelatedEndpoint
<fwereade> niemeyer, it just seems that there were a couple of places where we needed to match up counterparts, and I anticipate another, so...
<niemeyer> fwereade: There are participants in a relation
<niemeyer> fwereade: The only assumption a given endpoint should make is that it is part of a relation with other endpoints
<niemeyer> fwereade: The number of other endpoints depends on role
<fwereade> niemeyer, or without any other endpoints whatsoever ;)
<niemeyer> fwereade: There's nothing in our current model that binds the number of endpoints to one, two, three, etc
<niemeyer> fwereade: Over the last few days, I've been trying to maintain that model, and we have been arguing back and forth around issues that deep inside are related to that
<fwereade> niemeyer, yeah, this sounds like it's the heart of it
<niemeyer> fwereade: RelatedEndpoint makes no sense if there are three endpoints
<fwereade> niemeyer, agreed
<niemeyer> fwereade: and it makes little sense if there is a single one
<niemeyer> fwereade: (the related endpoint of A is A? huh?)
<fwereade> niemeyer, well, it makes more sense than you might think
<fwereade> niemeyer, if you read the docs for RelatedEndpoint
<niemeyer> fwereade: "In the case of a peer relation,"
<fwereade> niemeyer, I *think* I was careful to write it in such a way that it did make sense for peer relations
<niemeyer> fwereade: That's in the docs
<niemeyer> fwereade: It means "Yo reader! Special case ahead!"
<fwereade> niemeyer, on the contrary, it means "yo reader! you probably didn;t read the last sentence carefully enough!" ...which I concede is not *much* better
<fwereade> niemeyer, ok, in both significant cases I am aware of, I want to be able to easily get the service which has units that units of a given service might want to relate to
<niemeyer> fwereade: Hmm.. is that implementation right?
<niemeyer> fwereade: Oh, ok, nevermind
<fwereade> niemeyer, would it make you happier if I made that service*s* which have units which units of a given service might want to relate to?
<niemeyer> fwereade: It is a special case indeed..
<niemeyer> fwereade: Look at the implementation
<niemeyer> fwereade: "If it's not my service, than pick the other"
<niemeyer> Erm
<fwereade> niemeyer, yes
<niemeyer> fwereade: "If it's not my name, than pick the other"
<fwereade> niemeyer, indeed
<fwereade> niemeyer, the trouble is that we have this task I described above
<fwereade> niemeyer, it doesn't seem to me to be a good move to insist on sprinkling special cases per relation type through the code right now, every time we want to do this, on the basis that we might want to have more special cases later
<niemeyer> fwereade: Agreed, but that seems to have different meanings for us
<fwereade> niemeyer, apparently so :)
<niemeyer> fwereade: RelatedEndpoint in my mind is *huge* special casing
<niemeyer> fwereade: It  special cases the concept of provider and requirer, of peer, and of the assumption that there are only 1 or two relation endpoints
<niemeyer> fwereade: All in that small block of code
<fwereade> niemeyer, all in that small block of code *tacked onto the Relation type*
<fwereade> niemeyer, I think we agree that there are special cases regardless
<niemeyer> fwereade: No, not at this level
<fwereade> niemeyer, I want my relation-related special cases packaged up neatly in the place I expect
<niemeyer> fwereade: The existence of a Relation is generic
<niemeyer> fwereade: The fact multiple endpoints participate in a relation is generic
<niemeyer> fwereade: The fact they may have arbitrary types is generic
<niemeyer> fwereade: The fact they are arbitrarily numbered is generic
<niemeyer> fwereade: All of those were properly generic in the previous API
<niemeyer> fwereade: CounterpartRole changes that
<niemeyer> fwereade: RelatedEndpoint changes that
<fwereade> niemeyer, weeeeeeelll.
<fwereade> niemeyer, I invite you to take a look at just what would be involved in adding multi-endpoint relations to the python
<niemeyer> fwereade: and I'm feeling bad about it because it feels like we're going down that path for no good reason
<fwereade> niemeyer, but I *am* trying to figure out a middle ground :)
<fwereade> <fwereade> niemeyer, would it make you happier if I made that service*s* which have units which units of a given service might want to relate to?
<niemeyer> fwereade: I didn't parse that sentence.. that's mainly why I didnt answer
<niemeyer> fwereade: "services which have units which units of given service"?
<fwereade> niemeyer, so, (*Relation) OtherEndpoints(serviceName string) ([]RelationEndpoint, error)
<fwereade> niemeyer, ok, not Other
<niemeyer> fwereade: No, that actually sounds fine
<niemeyer> fwereade: With Other too
<fwereade> niemeyer, because I would still want to return the peer endpoint there
<niemeyer> fwereade: Uh oh
<niemeyer> fwereade: Then no
<fwereade> niemeyer, it's a matter of "[units of which services] might my units want to communicate with?"
<niemeyer> fwereade: You have a very specific use case in mind, and is tailoring a generic interface to that very specific use case
<niemeyer> fwereade: Just special case it in your use case.. I bet it's a three or four lines function
<niemeyer> fwereade: Exactly.. there no "my units" concept outside of "your unit"
<fwereade> niemeyer, yes, I am primarily focused on getting an interface that allows me to express what I need in the same way in the 2 cases we currently have
<fwereade> niemeyer, so you wouldn't be opposed to a function that basically did that, but you don't like having it on Relation?
<niemeyer> fwereade: Silly example: it's a well known model to have Primary, Secondary, and Voter
<niemeyer> fwereade: If I have a Secondary, what's the other Unit?
<fwereade> niemeyer, I don't really see how that fits our scenario... can't secondaries become primaries, etc?
<niemeyer> fwereade: That's not the point..
<niemeyer> fwereade: What's the CounterpartRole?
<rog> niemeyer: a couple of small reviews for you, if you like: https://codereview.appspot.com/6302089/ and https://codereview.appspot.com/6312044/
<niemeyer> rog: Thanks, I'll include them in the set of reviews
<rog> i've gotta go, see y'all tomorrow
<niemeyer> rog: Have a good one
<fwereade> niemeyer, look, I tried to start this conversation several days ago, and you brushed it off with words to the effect of "I don't know, maybe we'll need more, maybe we're fine with what we have"
<fwereade> niemeyer, I'm happy to drop CounterpartRole
<niemeyer> fwereade: Thanks, I'm starting to feel like this is more important than I thought, because it will affect our thinking elsewhere
<fwereade> niemeyer, I understand the high-level concept of "there may be more relation types"
<fwereade> niemeyer, I don;t follow how primary/secondary/voter fits in with what we have, because roles can change
<niemeyer> fwereade: But i was actually trying to explain why I see issues in the OtherEndpoint stuff
<niemeyer> fwereade: It was an example.. I do think we'll have other relations in the future, and I don't know how they look like right now
<niemeyer> fwereade: We'll need smart brains, etc
<niemeyer> fwereade: We'll have maintenance of filesystems and whatnot
<fwereade> niemeyer, it seems to me that the roles we have in play are used in really quite a lot of places
<niemeyer> fwereade: I don't know how those will look like
<niemeyer> fwereade: But I'm trying to point out that there's no reason why relations are singletons of pairs only
<niemeyer> fwereade: Primary/Secondary/Voter is a model that I thought was easier to get across
<niemeyer> But maybe not..
<fwereade> niemeyer, I'm trying to handle one single problem: given a relation R, and a service S in that relation, independent of the number of services
<fwereade> niemeyer, *what* services in that relation might units of S need to respond to changes in?
<fwereade> niemeyer, I think that this is a generic question
<niemeyer> fwereade: Processing your (clean) statement.. hmm
<fwereade> niemeyer, I understand your reservations re CounterpartRole, but I'm not sure it's as simple as dropping it... what about topology, where we had the counterpart dict beforehand?
<niemeyer> fwereade: This is facilitating an algorithm that takes into account the specific roles.. that algorithm knows the roles, and deals with them appropriately
<fwereade> niemeyer, CanRelateTo takes one argument, and that encodes the 2-service asusmption as well
<niemeyer> fwereade: Not really
<fwereade> niemeyer, at least, surely, we need a CanMakeRelationWith(roles ...RelationRole) ?
<niemeyer> fwereade: CanRelateTo(A, B).. CanRelateTo(B, C)..
<niemeyer> fwereade: Not necessarily, no
<niemeyer> fwereade: Just like you don't need a GreaterThan(numbers ...) to see if a number is larger than a set of numbers
<niemeyer> fwereade: FWIW, that API was conceptualized in that form with this in mind
<fwereade> niemeyer, I think relations between services are perhaps a little more involved than comparisons between reals, but I worry that I'm straying off the point
<fwereade> niemeyer, does it make sense to have an incomplete multi-endpoint relation though?
<niemeyer> fwereade: CanRelateTo(Voter, Primary)... CanRelateTo(Primary, Secondary)...
<niemeyer> fwereade: These are examples.. I hope they make some sense to you
<fwereade> niemeyer, *kinda*, but... does it really make sense to have, say, *just* voters and primaries?
<niemeyer> fwereade: In a number of cases, yes
<fwereade> niemeyer, I'm not clear what impact the votes could have then
<fwereade> niemeyer, but can we take it as read that there are more kinds of relation than are dreamed of in my philosophy
<niemeyer> fwereade: For a typical database, maybe it doesn't do much, but it actually works, and may be a fine step towards establishing the full topology wanted
<niemeyer> fwereade: The real point is that CanRelateTo(Primary, Primary) would fail.. and CanRelateTo(Peer, Requirer) would also fail
<fwereade> niemeyer, ok, that makes sense
<fwereade> niemeyer, but regardless... can you think of a generic way to expose an answer to the problem I'm trying to solve?
<fwereade> niemeyer, OtherEndpoints would almost work, except for peer relations it's not really an "other" endpoint
<fwereade> niemeyer, RelatedEndpoints feels to me like it's the closest I've heard yet
<fwereade> niemeyer, but I suspect you will dislike that word for perfectly rational reasons
<niemeyer> fwereade: I'm still processing your previous (clean) statement.. that was a great way to put it
<fwereade> niemeyer, thanks :)
<fwereade> niemeyer, I'm also fretting that, really, we've got a *lot* of generic code to put in place to support this
<fwereade> niemeyer, for example, I can't in good conscience implement unit agents with only one presence node per relation
<fwereade> niemeyer, I can't watch related units without watching a range of possible locations for the presence nodes
<fwereade> niemeyer, it all makes me very nervous
<fwereade> sorry, brb
<niemeyer> fwereade: Okay, your thinking seems to be reaching my head
<fwereade> b
<niemeyer> fwereade: :)
<fwereade> niemeyer, indeed, I'm not actually blind to your perspective, but it has been rather hard to incorporate it at the point where the bits hit the disk, as it were ;)
<niemeyer> fwereade: Your idea of RelatedEndpoint sounds fine.. I can't think of a better name either
<niemeyer> fwereade: Can we do one tweak:
<fwereade> niemeyer, surely :)
<niemeyer> fwereade: Considering all the conversation about regarding multiple endpoints and the unknown coming future,
<niemeyer> s/about/above
<niemeyer> fwereade: I'd appreciate if we could make counterpartRole private, and make RelatedEndpointS (plural) return a slice
<fwereade> niemeyer, SGTM
<niemeyer> fwereade: and attempt to keep in mind the fact we don't have a clearly defined set of relation roles when doing the lower level algorithms
<fwereade> niemeyer, if I'd been thinking I would have made that private in the first place
<fwereade> niemeyer, I'll do my best :)
<niemeyer> fwereade: I don't want to go crazy with that, though
<niemeyer> fwereade: It's just a way to force us to *try* to go in that direction if it's not too much pain
<niemeyer> fwereade: If it turn out to make no sense, we can always talk again and see if we should reevaluate our position
<fwereade> niemeyer, ok, I'll see how we do :)
<niemeyer> fwereade: Thanks a lot, and sorry for making such a minor step difficult somehow
<fwereade> niemeyer, on the upside, multi-peer relations really shouldn't be too hard even as we are now
<fwereade> niemeyer, np, a pleasure, we all end up the richer for these discussions ;)
<niemeyer> fwereade: That's an easy case to keep in mind.. if we can handle that with minor trouble, we're probably in a good direction
<fwereade> niemeyer, cool
<fwereade> niemeyer, I should probably go and see some physical human beings now, gn :)
<niemeyer> fwereade: Haha
<niemeyer> fwereade: Sounds like a good plan, thanks :-)
#juju-dev 2012-06-19
<niemeyer_> Heya
<niemeyer> andrewsmedina: ping
<andrewsmedina> niemeyer: PING andrews (0.0.0.0): 56 data bytes
<niemeyer> andrewsmedina: Heya
<niemeyer> :)
<andrewsmedina> niemeyer: 64 bytes from andrews: icmp_seq=0 ttl=48 time=613.936 ms
<andrewsmedina> niemeyer: =)
<niemeyer> andrewsmedina: Gosh, that's a terrible ping time ;)
<davecheney> niemeyer: thanks for your comments on the dummy branch
<davecheney> i have another idea which i'll propoes for you and rog.
<niemeyer> davecheney: My pleasure
<niemeyer> davecheney: Sounds great, thanks
<davecheney> i'm thinking of making Operation an interface
<davecheney> then op.Kind becomes a type switch
<davecheney> will do a quick branch to see how large the change is
<davecheney> to me this feels better than sticking a lot of mostly zero fields in Operation
<niemeyer> davecheney: Sounds reasonable
<niemeyer> davecheney: We can also mix both
<niemeyer> davecheney: Having Kind() on the interface
<davecheney> sure
<niemeyer> But see how it looks like..
<davecheney> that might be a good way to introduce it
<niemeyer> Experimenting should tell the best path
<davecheney> i'll discuss it with Rog this evening
<niemeyer> davecheney: type OperationKind int; func (k OperationKind) Kind() OperationKind
<niemeyer> davecheney: ;)
<davecheney> indeed, it makes it easy to introduce a placeholder type
<niemeyer> <3 Go
<davecheney> niemeyer: the reason I added the insts field to operation was so I could get the actual *instance
<davecheney> in general, do you think this is a sane way of doing it
<davecheney> it might require instance to define some sort of equality
<niemeyer> davecheney: I think it's reasonable.. for that specific case, you might as well have opened the environment a second time
<niemeyer> davecheney: and retrieved the instance from the env itself
<niemeyer> davecheney: But I don't think that works for everything
<niemeyer> davecheney: E.g. you might as well take the chance to check the machine id (!)
<niemeyer> davecheney: It's a sane field to stick in the candidate StartInstanceOp struct type
<davecheney> but not a good case for all operatoins
<niemeyer> davecheney: and that kind of thing starts to get boring to check on the environment
<niemeyer> davecheney: We'll have more of those over time
<niemeyer> davecheney: E.g. constraints, etc
<niemeyer> davecheney: Which are easier to take them out of the operation type than from querying the env externally
<davecheney> niemeyer: https://codereview.appspot.com/6315043
<davecheney> mercifully shorter
<davecheney> will propose this afternoon
<niemeyer> davecheney: Hm?
<niemeyer> davecheney: I've LGTMd it :)
<niemeyer> davecheney: Looks good overall, anyway
<niemeyer> I'll head to bed now
<niemeyer> Night all
<davecheney> niemeyer: night
<rog> davecheney: hiya
<rog> davecheney: the possibility of making Operation an interface was always there, but i didn't want to complicate things prematurely
<rog> davecheney: you might also consider adding an "Error() error" method, because ISTR that some test code relies on knowing that the operation has been invoked even though it returns an error
<davecheney> ahoy!
<davecheney> rog: did you catch the conversation with gustavo ealier ?
<rog> davecheney: yeah
<davecheney> I had a quick crack at making Operation an interface and it isn't that horrible
<davecheney> dozens of lines, not hundreds
<rog> davecheney: i did a similar thing with file operations some time ago
<davecheney> if you think it sounds good in principal, i'll polish it up and propose
<davecheney> rog: so the PA can now start and stop machines
<rog> davecheney: yeah, i think that sounds better than arbitrarily putting Instances in Operation, actually
<davecheney> what is stopping us trying to bootstrap an environment ?
<rog> davecheney: cool. have you tried using it for real?
<davecheney> rog: yeah, then we can have concrete impls of operation that contain only the fields they need
<rog> davecheney: just the code in cloudinit
<rog> davecheney: yeah
<davecheney> rog: i agree that having a bunch of fields which are only valid in some circumstances is a code smell
<davecheney> and exactly what go interfaces avoid
<rog> davecheney: yup
<davecheney> sounds like a solid case to proceed
<rog> davecheney: i just had a dream in which i was vigorously trying to defend Go interfaces against discriminated unions to an old work colleague :)
<rog> davecheney: while wandering through a forest full of fungi...
<rog> davecheney: strange
 * davecheney is speechless
<davecheney> so, lets change the subject to cloud init
<rog> lets
<davecheney> tell me what is missing and if I can help
<rog> davecheney: i think that it just needs a line of code in environs/ec2
<rog> davecheney: it might even have a TODO there
<davecheney> curses, we're doomed, we'll never make it
<davecheney> :)
<rog> davecheney: yeah, grep for TODO in environs/ec2/*.go
<rog> davecheney: only problem is i think the amazon tests might currently be broken.
<rog> davecheney: i haven't been running them often enough (they take ages to run and only work 30% of the time anyway because of transitory errors).
<rog> davecheney: i need to up the timeout and ssh to the bootstrap machine to see what's going on
<rog> davecheney: in fact, i think i'll do that now.
<davecheney> rog: hotsauce
<rog> davecheney: congrats BTW. having the first agent done is a huge step forward!
<rog> davecheney: ha! found the culprit! http://paste.ubuntu.com/1048666/
<rog> davecheney: i've no idea why it's trying to use the dummy package in the cloud
<fwereade> rog, davecheney: mornings
<rog> fwereade: hiya!
<davecheney> rog: o_O!
<davecheney> rog: how much work is it to resolve that facepalm ?
<rog> davecheney: i hope not much. the stack traces don't seem to match the code, so i'm just sanity checking the binaries
<rog> davecheney: i don't know how it is ending up in that code.
<davecheney> could it be the old juju tree ?
<rog> davecheney: it's possible. i'll try again, modifying that error message...
<davecheney> rm -rf $GOPATH/pkg/launchpad.net/juju
<rog> davecheney: the binaries don't come from there
<rog> davecheney: it builds them on demand in a temporary directory
<davecheney> gocheck ?
<rog> davecheney: gocheck?
<rog> davecheney: i've found the problem BTW
<rog> davecheney: and i think you came up with the solution a few days ago
<davecheney> fixitfixitfixit
<rog> davecheney: the problem is that provisioning.go imports the dummy environ
<davecheney> rog:  ... yes,
<davecheney> maybe it shouldn't, as long as I import it in the tests, it will work
<rog> davecheney: that's right
 * davecheney facepalm
<davecheney> i'll fix that shit right now
<rog> davecheney: i'll do it here and check that it works too.
<fwereade> rog, I have a trivial for you: https://codereview.appspot.com/6308089
<davecheney> rog: if you want to propse, please do, i have to run out in a second
<rog> davecheney: ok, will do
<rog> fwereade: LGTM. oops.
<fwereade> rog, np, cheers :)
<fwereade> rog, how would you feel about me trying to factor out some sort of common topology watcher? I want a service relation watcher, and at first glance I'm going to end up duplicating most of the machines/machine-units watchers
<rog> fwereade: i'm not convinced. i can't see that it could save more than 4 lines per watcher.
<rog> fwereade: (the code that parses the topology)
<rog> fwereade: what other code do you think you could factor out?
<fwereade> rog, I was wondering whether I could get rid of the Stop and a fair amount of loop, but it might indeed not turn out all that nice
<rog> fwereade: i'm not that keen on adding another buffered value for not that much gain
<fwereade> rog, yeah, fair enough, I'll give it 15 mins and then take a cynical self-look
<rog> fwereade: sounds like a good plan
<rog> fwereade: could you check that "go test launchpad.net/juju-core/juju/..." works for you, please?
<rog> fwereade: it's hanging up for me in jujuc/server
<fwereade> rog, did just a few minutes ago
<rog> fwereade: hmm.
<rog> fwereade: oh, bizarre. i've found the problem.
 * fwereade concludes that, yeah, a topology watcher isn't worth the effort, and is sad about that
 * fwereade never expected to seriously miss c-style macros
<rog> fwereade: there may easily be some other way to refactor all that code.
<rog> fwereade: i had some ideas right at the beginning which might work.
<fwereade> rog, I'll probably get annoyed with it again later today and give the tyres another kick, but it seems like it'll get a bit convoluted unless I'm careful
<rog> fwereade: yeah, that's the potential problem.
<rog> fwereade: here's why that test was hanging BTW. i'd changed state.zkTimeout to 45*time.Minute.
<rog> fwereade: but... that *should not* have caused the test to hang
<rog> fwereade: when i changed the timeout back to 15*time.Second, the dial in question succeeded after 5 seconds.
<fwereade> rog, weird
<rog> fwereade: for watcher refactoring, i was toying with the idea of something like this: http://paste.ubuntu.com/1048710/
<rog> TheMue: good morning!
<TheMue> rog: Morning rog.
<rog> fwereade: i'm not entirely sure if it would be worth it though.
<fwereade> rog, yeah, I was just toying again with a similar idea
<fwereade> rog, I have a w.loop(w) in there, and that's the thing that feels a bit off really
<TheMue> Ah, and morning fwereade too.
<fwereade> TheMue, heyhey
<rog> fwereade: it doesn't actually factor out that much code.
<fwereade> rog, yeah
<rog> fwereade: and it makes the code harder to follow, as callbacks do.
<fwereade> rog, not so sure, there's a little more initial investment but I think once you have 3 of them it's arguable that it pays off
<rog> fwereade: and closing the channel is awkward.
<fwereade> rog, agreed :)
<rog> fwereade: anyway, worth continuing to think on
<fwereade> rog, ey up, I'm not sure about MachinesWatcher... is it ok to depend on the topology always containing at least one machine to guarantee the initial event?
<rog> fwereade: hmm, does it?
 * rog goes to look.
<fwereade> rog, looks like it does to me
<rog> fwereade: yes, and the test agrees with you
<rog> fwereade: that needs fixing. i should've seen it.
<fwereade> rog, I think I reviewed that one as well :)
<fwereade> rog, programming is hard ;)
<fwereade> rog, btw, same applies to machine units watcher
<rog> fwereade: ahem
<fwereade> rog, or not?
<rog> fwereade: definitely does
<rog> fwereade: my fault. i blindly copied from MachinesWatcher.
<rog> fwereade: without remembering the "first event" thing.
<fwereade> rog, IMO once the code's reviewed the blame is distributed evenly ;)
<rog> fwereade: and it's particularly important for machine units watcher too, as the machine agent actually acts specially on the first event.
<rog> fwereade: good catch!
<rog> fwereade: feel free to fix 'em both, if you like.
<rog> :-)
<fwereade> rog, sure
<fwereade> rog, https://codereview.appspot.com/6295100 (again trivial IMO)
<rog> fwereade: LGTM. i think i'd prefer "sentValue" as a name, but i see emittedValue is already used in watcher/watcher.go
<rog> fwereade: "and -0 on ROW". do you really mean Roswell airport there?
<fwereade> rog, I meant Rest Of World :p
<rog> fwereade: ah!
<fwereade> rog, I suspect I should amend it to -0 on ROW, excluding ROW, which also gets +1; but that would probably be even more confusing
<rog> fwereade: :-)
<fwereade> rog, yeah, I'm not too keen on emittedValue, but that was niemeyer's suggestion over "started" so I went with it
<rog> fwereade: fine.
<fwereade> rog, trivial enough to be a trivial?
<rog> fwereade: i think so.
<fwereade> rog, cool, cheers
<rog> fwereade: i've just realised that we need some more working juju commands if we're to test the new PA
<rog> fwereade: deploy!
<fwereade> rog, I made a start on deploy a while ago but was blocked by lack of AddRelation
<fwereade> rog, I guess i could switch back to that quickly
<fwereade> rog, I'm a little reluctant to continue with my pipeline, it depends on the 2 I have out for review
<fwereade> rog, I'd prefer to get at least one in before I propose another :)
<rog> fwereade: couldn't we do a minimal deploy with no relations.
<rog> ?
<fwereade> rog, my feeling was that half-working features were a no-no
<rog> fwereade: gotta start somewhere!
<fwereade> rog, individual features *entirely* not working is fine though ;p
<fwereade> rog, I think I even have most of it implemented somewhere
<rog> fwereade: "relation" is a feature :-)
<fwereade> rog, I'll get on it now :)
<fwereade> rog, yeah, but deploy is expected to add relevant peer relations
<fwereade> rog, I guess I could have just done panic("can't deploy services with peer relations yet")
<rog> fwereade: i'm sure that if you did an initial deploy implementation with "TODO" for the relations stuff, it would be acceptable
<fwereade> rog, I think I'm actually unblocked on it now
<rog> fwereade: a trivial for you: https://codereview.appspot.com/6295101
<fwereade> rog, LGTM
<fwereade> rog, do we have a way t get the default series from the environ yet?
<rog> fwereade: nope. there's no default series parsed in environs/ec2/config.go
 * fwereade grumbles
<fwereade> TODO comment I guess
<fwereade> rog, half-implementing things really bothers me
<fwereade> rog, I feel it's one of the biggest risks
<rog> fwereade: it's not possible to implement everything at once
<rog> fwereade: i started doing that originally, but there's just too much cruft and you don't know how it's gonna be used
<fwereade> rog, yeah, but something that *looks* like it works, to a casual inspection, is IMO actually worse than something that doesn't exist at all
 * rog isn't sure.
<rog> i think having something that works at all is useful in itself
<Aram> moin.
<fwereade> Aram, heyhey
<Aram> so, we're nor going to brazil after all...
<niemeyer> Gooood mornings
<Aram> heyhey.
<fwereade> heya niemeyer
<niemeyer> fwereade, Aram, davecheney: Hey folks!
<rog> niemeyer: hi
<niemeyer> rog: Heya
 * davecheney hates prereqs
<Aram> davecheney: I replied to your named return argument note.
<davecheney> Aram: yup, no worries
<davecheney> i'm glad we can agree to disagree
<rog> niemeyer, fwereade, davecheney: here's an initial impression of the machine agent code (untested as yet). http://paste.ubuntu.com/1048896/
<rog> niemeyer, fwereade, davecheney: am i missing something?
<niemeyer> rog: Well, I'd prefer to review it in codereview :)
<davecheney> rog: line 45, line 60
<rog> niemeyer: i have no tests yet
<rog> niemeyer: actually, i'll propose it as wip
<fwereade> rog, I don't think it needs to do anything else, honestly
<niemeyer> rog: Well, write the tests?
<rog> niemeyer: that's something i want to talk about
<fwereade> rog, I would suggest that maybe the non-principal filtering should be done at the watcher level... do we expect any other clients?
<davecheney> rog: niemeyer busted by ass about making it recover if the watcher closes, so its only fair i pass on the love :)
<rog> niemeyer: my current best idea is to add an exported function pointer to the container package that it will call to do the install.
<rog> fwereade: no, but i think Machine.UnitsWatcher should mirror Machine.Units
<fwereade> rog, PrincipalUnitsWatcher?
<rog> fwereade: PrincipalUnitsForMachineWatcher :-)
<niemeyer> rog: I'd prefer to have smaller bits going in
<niemeyer> rog: Well tested
<niemeyer> rog: and properly reviewed
<rog> niemeyer: this isn't small?
<niemeyer> rog: add the skeleton
<niemeyer> rog: No, this is a paste with no tests
<rog> niemeyer: it's 100 lines of code... i thought that was a reasonable size.
<rog> niemeyer: in fact it's only 70 lines of new code.
<rog> niemeyer: without Machiner.loop, i'm not sure there's any functionality to test
<niemeyer> rog: If there's nothing to test, I guess we don't need the code..?
 * rog is feeling a bit shit.
<rog> [12:04:14] <niemeyer> rog: I'd prefer to have smaller bits going in
<niemeyer> rog: Sorry, that was a direct reaction to your statement that you had no tests and seemed unsure about what you were working on
<niemeyer> rog: I prefer to break a task down further to a point you are sure about than to be reviewing untested code in a paste, that's all.. it wasn't a direct statement about your code
<rog> niemeyer: i didn't want the code reviewed, just a quick glance for first impressions.
<niemeyer> rog: Yes, deploy units and destroy units.. that seems right. I'd suggest having a look at some of the early on logic that Dave worked on before getting into those details.
<davecheney> rog: did you try removing dummy from the PA to see if it fixed the problem ?
<rog> davecheney: it did
<rog> davecheney: i proposed the change
<davecheney> hmmm, y u no email ?
<davecheney> i'll find it online
<rog> davecheney: https://codereview.appspot.com/6295101/
<davecheney> ta
<rog> davecheney: i seem to have misspelled "remove"
<davecheney> LGTM anyway.
<davecheney> it's night time for me
<rog> davecheney: see you tomorrow, i hope
<davecheney> all: i'll be off and on line tomorrow because they are putting in a new floor downstairs, so I have to pack away the router and stuff
<davecheney> so i'll be on reduced internet rations via phone
<davecheney> i don't expect this will cause a problem
<rog> fwereade: i've just realised a not-so-good thing about the watchers
<rog> fwereade: if the sub-watcher watch channel is closed, the tomb is killed with "content change channel closed unexpectedly" which will actually mask the underlying error returned from the sub-watcher.Stop AFAICS
<niemeyer> rog: http://etherpad.ubuntu.com/NCUR4J1kbL
<fwereade> rog, won't the wtahcer.Stop return the underlying error?
<fwereade> rog, oh, I see
<fwereade> rog, hmm
<niemeyer> fwereade:
<niemeyer> / mustErr panics in case err is not set.
<niemeyer> / This is used to make sure there's no weirdness in the implementation
<niemeyer> / of the watcher. Basically, and underlying watcher should never be
<niemeyer> / *cleanly* stopped if the outer watcher is still expecting it to be alive (duh!).
<niemeyer> fwereade: Makes sense?
<fwereade> niemeyer, it does, I'll need to thik a little more to convince myself it's a panic situation
<fwereade> niemeyer, but offhand, yeah, it does seem like that would indicate a logic error
<niemeyer> fwereade: Yeah, indeed.. rog mentioned it could return an error as well
<fwereade> niemeyer, I haven't thought of any problem with panicing yet
<fwereade> niemeyer, but I'm still a *little* reserved about it
<fwereade> niemeyer, not enough to say we shouldn't though
<niemeyer> fwereade: rog had some good points about closing the Changes channels too
<niemeyer> fwereade: It's silly for us to be closing them.. it's just creating more work
<niemeyer> Magic!
<fwereade> niemeyer, I think I'll need a little more convincing there, not sure I totally like the idea of anything sitting watching an abandoned channel forever
<niemeyer> mramm found a reasonable flight for saturday the 27th, I forwarded it to the agency, and they "discovered" it
<fwereade> niemeyer, if we give every watch a Dying though I'd be very happy to select on Changes()/Dying()
<fwereade> nihaha
<fwereade> niemeyer, haha
<fwereade> niemeyer, was that what you were you thinking of?
<niemeyer> fwereade: Exactly
<fwereade> niemeyer, cool, +1 then
<niemeyer> fwereade: Although, you do have a point..
<niemeyer> fwereade: We could just as well do the same logic with closing the Changes
<niemeyer> fwereade: if !ok { foo.tomb.Kill(mustErr(foo.watcher.Err())); return }
<niemeyer> rog: ^
<fwereade> niemeyer, hmm, I think that's even better actually
<hazmat> niemeyer, g'morning
<niemeyer> hazmat: Heya
<niemeyer> hazmat: What's up in hot Washington?
<fwereade> heya hazmat
<hazmat> niemeyer, there are a couple of charms that afaics should be in the charm store, but aren't.. and its not clear per se why
<niemeyer> fwereade: Agreed.. no need to be casing twice every time
<hazmat> pretty good in dc.. wet atm.. waiting to the dog walk
<hazmat> niemeyer, i put together this page of the missing ones.. http://jujucharms.com/tools/store-missing
<niemeyer> hazmat: mthaddon is our man in those cases
<hazmat> some i can see why.. but quite a few its not clear
<niemeyer> hazmat: He has to dig out of the log for the moment
<hazmat> gotcha
<niemeyer> hazmat: We need a proper interface for that, as these details are actually already in the database
<rog> niemeyer: that LGTM
<hazmat> niemeyer, well on a few it returns the reason with the response..
<hazmat> niemeyer, also i was curious how to use the stats interface, like what's the param
 * hazmat pulls up charmstore src
<hazmat> it looks like its listening on /stats/counter/  and then the param name is the lp branch name?
<Aram> I need some help with bzr
<Aram> I used a worng branch by mistake
<Aram> and I don't know what to do... I created a correct branch with the changes, but I don't know how to fix the original
<fwereade> Aram, just abandon it I think :)
<Aram> it's the maste branch though
<Aram> master
<Aram> can I delete it and recreate it?
<Aram> and still keep my other branch?
<fwereade> Aram, master branch of what?
<Aram> juju
<fwereade> Aram, if it's just some branch from which you have already merged the changes you should be fine
<Aram> it's not
<fwereade> Aram, ah, lp:juju-core/juju then?
<fwereade> Aram, what's happened to it? :)_
<Aram> yes
<Aram> I commited to my local copy of it.
<Aram> some changes.
<rog> Aram: i'm +1 with dfc on named return values FWIW. i think they should only be used for trivial functions - they're very easy to get wrong.
<fwereade> Aram, hmm, I think there's a "bzr uncommit"
<rog> Aram: (and that's also the policy in the go core i think)
<fwereade> Aram, http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html has helped me once or twice
<fwereade> Aram, better I think is to get into the habit of branching for *everything*
<fwereade> ;)
<rog> Aram: for reference: http://codereview.appspot.com/2125042/diff/15006/src/pkg/archive/zip/reader.go#newcode85
<Aram> rog: I agree with rsc if s/trivial/small/. in that example named returns are bad because they force you to do 'return nil, err' in the middle of a huge function, but if the function is such that an unadorned return always suffices I see no problem with them.
<Aram> fwereade: bzr uncommit worked for fixing that branch, thanks.
<Aram> I still have another problem though.
<fwereade> Aram, sweet
<fwereade> Aram, go on
<rog> Aram: i think it's worth using named return values if they actively add value. often that's not actually the case, and they force the reader to go back through the code to work out what's actually being returned.
<Aram> what's the equivalent of hg update in bzr?
<rog> Aram: bzr pull?
<Aram> I though so, but then why:
<Aram> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<rog> Aram: maybe you want to do a merge
<Aram> what does that mean, there are no conflicts.
<rog> Aram: bzr merge lp:juju-core/juju
<Aram> bzr merge worked, but
<Aram> zr merge lp:juju-core/juju
<Aram> oops
<Aram> white:state$ bzr diff | wc
<Aram>     875    3448   23475
<Aram> do I have to commit after merge?
<rog> Aram: yes
<Aram> hmm
<rog> Aram: i usually do: bzr commit -m 'merge trunk'
<Aram> ok, thanks.
<Aram> all fine now.
<Aram> rog: yes, I agree that named return values should be used only if they add value, but I think they can add a lot of value if the programmer writes the code in a particular way.
<rog> Aram: example: Machine.SetInstanceId. what value is the named return value adding there?
<Aram> rog: none, I agree in that case.
<rog> Aram: another example. here i would definitely prefer the second version: http://paste.ubuntu.com/1049099/
<rog> Aram: at a glance it's obvious that we're returning the correct combination of machine and error
<rog> Aram: in the first version i have to look at the if err != nil logic to make sure that it's correctly returning a nil error.
<Aram> rog: but if err != nil { return } is such a common idiom that by convention you know what it does, error out using the result from the previous function and code past it means it's all fine. it's like a for loop, you learn how it looks, you don't have to think about it.
<rog> Aram: it's the bare return at the end i was talking about.
<Aram> yes, it's past the if err != nil { return } so you know err is nil.
<rog> Aram: exactly, you have to look back into the function to check that it's returning a nil error
<rog> Aram: for me, the second version has less code, is more trivially readable, and the documentation looks nicer too.
<Aram> but with things like return &Machine{st: s, id: id}, nil I always have to look to match up return parrameters with the return types to figure out what am I doing and if it's right, if it's a bare return I don
<Aram> 't have to think about it.
<Aram> and without named returns, error paths usually end up like 'return nil, err' or 'return "", err', and I always have to think about who is that nil or "".
<Aram> and return &Machine{st: s, id: id}, nil makes me to fill up a mental stack frame processing &Machine{st: s, id: id} and then the return, whilst in my version the code is written in the same natural order the mind processes it (do the Machine, then return).
<Aram> it's the same reason I don't like 'if ok := f(); ok {}', I like them separate.
<Aram> ok := f(); if ok  {}
<rog> Aram: there are almost always exactly two return values...
<rog> Aram: so matching return values with types isn't too onerous
<rog> Aram: i think my mind can process &Machine{...} as a blob to go along with the nil
<niemeyer_> Aram: FWIW, I agree with rog in the original paste
<niemeyer_> Aram: This seems like overusing named results to me as well
<hazmat> Aram, that's only safe to do when have a branch of trunk and not a checkout re uncommit
<niemeyer_> (that, specifically: http://paste.ubuntu.com/1049099/)
<niemeyer> The second seems both shorter and reads more clearly
<rog> Aram: in the "if ok := ..." case, i use the one line version when possible because it means i have to check less places to see if something relies on the result of ok.
<rog> niemeyer: this is a one-line trivial change: https://codereview.appspot.com/6295101/
<niemeyer> Looking
<niemeyer> rog: LGTM
<rog> niemeyer: thanks
<niemeyer> rog: With that kind of change you can just go ahead if you have someone else's review
<rog> niemeyer: it was interesting that it broke the agent.
<rog> niemeyer: it made me think that it would be nice if we had something that ssh'd in to the bootstrap machine and tailed the logs so we could automatically get feedback when a bootstrap fails.
<rog> niemeyer: but i think that's too much pain for not enough gain
<niemeyer> rog: I've been thinking about something along those lines too
<niemeyer> rog: Once we get it on pair, we should look at doing some debugging improvements
<niemeyer> rog: I think we should make better use of syslog, though
<niemeyer> rog: To deliver *all* logs onto a central location
<rog> niemeyer: agreed. but in this case it died with a panic in init.
<niemeyer> rog: So we can say "juju log" and get a tail of it aall going
<rog> niemeyer: before we'd have managed to set up the log, i think.
<rog> niemeyer: yeah, it would be fantastic to have a centrally tailable log.
<niemeyer> rog: I see.. that doesn't concern me as much.. I'm happy to have juju ssh for that
<niemeyer> rog: We should probably do some early use of papertrail to get started
<rog> niemeyer: papertrail?
<niemeyer> rog: papertrailapp.com
<rog> niemeyer: looks good
<niemeyer> rog: If we make juju set up the machine syslog up, which is on the trivial side, we can use their service while we don't have our own syslog receiver
<niemeyer> rog: We may actually never *have* to have a syslog receiver.. just deploy a syslog charm as a first step, and then do "juju set-env syslog=<address>" or whatever
<niemeyer> rog: This should be a big aid for us
<rog> niemeyer: a syslog subordinate charm?
<niemeyer> rog: No, a syslog server charm
<niemeyer> rog: We should probably have a basic syslog setup within juju itself, so we can do debugging across the board more easily
<niemeyer> rog: It's really quite simple to have syslog sending logs from one machine onto the server
<niemeyer> rog: The machine agent could just do that
<niemeyer> I have flights for Lisbon, for the full week, thanks to mramm
<Aram> great, so it's the original date?
 * rog will go and try to book flights
<rog> niemeyer: when should i plan to leave?
<rog> niemeyer: friday evening? or sat morning?
<niemeyer> rog: Late Fri or anytime Sat both are great
<niemeyer> Aram: Yeah
<niemeyer> Aram: The change didn't quite worked out, and in the end there *was* a flight returning on the proper day that the agency I was talking to "didn't see" (!?)
<Aram> heh
<niemeyer> rog: Sent a couple of ideas on https://codereview.appspot.com/6312044/
<rog> niemeyer: seen. that's useful thanks.
<niemeyer> rog: Glad to hear
 * rog is booking flights now.
<Aram> so we don't use BTS or anything like that, we book our own flights?
 * Aram is a little bit confused
<fwereade> mramm, are we meeting in 10, or do I have time zones confused?
<niemeyer> Aram: We use BTS
<Aram> niemeyer: ah, so I should contact BTS?
<niemeyer> Aram: Yeah
<Aram> niemeyer: ok, thanks, understood.
<niemeyer> Aram: We as in you, me, and a few others.. depends on where the person is
<niemeyer> Aram: We have a few different agencies
<niemeyer> Aram: You can just get in touch with that email that I've CCd you in using your Canonical email address
<niemeyer> Aram: Point out dates, location, and event in case they have to confirm
<Aram> thanks
<hazmat> smaddock, bcsaller invitations out
<smaddock> hazmat: thanks, jointing now
<rog> niemeyer: i think i've addressed those issues now. https://codereview.appspot.com/6312044/
<niemeyer> rog: Super, I'll have a look as soon as I returned from lunch.. just got a call from Ale about it
<rog> niemeyer: ok
<hazmat> bcsaller, incidentally not sure if you saw the lp, but i assigned you the lp bug re lxc
<bcsaller> hazmat: yes
<fwereade> rog, TheMue, niemeyer: I seek advice re testing deploy with the charm store; don't want to hit real cs:, don't know how I should intercept requests (or replace url from outside package, or whatever). suggestions?
<rog> fwereade: chat about it tomorrow morning?
<rog> i'm off for the evening
<fwereade> rog, sure, sounds good, thanks :)
<rog> niemeyer: another small CL: https://codereview.appspot.com/6312051/
<fwereade> rog, happy evening :)
<rog> fwereade: toi aussi
<niemeyer> rog: Just done https://codereview.appspot.com/6312044/
<niemeyer> rog: Reviewed too
<niemeyer> rog: Just wondering about whether it should follow our established conventions
<niemeyer> rog: fooFixture/setup/teardown  is generally FooSuite/SetUpSuite/TearDownSuite
<fwereade> gn all, might make it on a bit later, or might not
<niemeyer> fwereade: have a good one
<jimbaker> hazmat, please see my comments re https://codereview.appspot.com/6308044/
<jimbaker> sadly the choice of using a json transport seems to be essential to preserving the format: 1 bugginess
<jimbaker> when i restructured the code so the conditional logic was removed in favor being polymorphic, it might have made the comment in juju.lib.format.Format1 re JSON serialization too far away from what was going on
<jimbaker> hazmat, but that's why there is dump/load methods in the Format classes, otherwise would just have used yaml.safe_load/safe_dump
<fwereade> niemeyer, fwiw, I have a couple of fixes and a couple of counterarguments on https://codereview.appspot.com/6305107/
<fwereade> niemeyer, if you're at a loose end (har har) I'd appreciate your thoughts :)
<niemeyer> fwereade: Checking :)
#juju-dev 2012-06-20
<hazmat> jimbaker, you can do the encode/decode on the server
<hazmat> jimbaker, the transport is irrelevant to maintaining the format
<hazmat> ie transfer in yaml, encode/decode cycle in json
<jimbaker> hazmat, i will see if i can make that work
<jimbaker> hazmat, in principle this makes sense, it just is the approach i first tried. however, the code is much more refactored, so it's possible this is simpler to do
<fwereade> morning davecheney
<davecheney> fwereade: howdy
<fwereade> davecheney, how's it going?
<davecheney> fwereade: good; so we're back to lisbon in july i hear
<fwereade> davecheney, yeah, that's my understanding
<fwereade> davecheney, is that better or worse for you?
<davecheney> fwereade: probably better, although I dunno if mark will like the prices, 2700 euro
<davecheney> well, between 2000 and 2700
<fwereade> davecheney, cool -- and, well, the cheapest I saw for me to POA was >2000 euros
<davecheney> that is what i decoded from the travel agent blather
<davecheney> fwereade: it was more the 45 hours travel that didn't do it for me
 * fwereade winces *hard*
<davecheney> i think it went SYD -> the frikken moon -> POA
<fwereade> davecheney, haha
<davecheney> then a return trip via saturn
<davecheney> which is insane, because it's shorter to go SYD -> Perth -> POA, than SYD -> LAX
<davecheney> geographically speaking
<fwereade> davecheney, the longest I've had to deal with (without incorporating a bed, at least) is probably *just* over 24 hours door to door
<fwereade> davecheney, and that was bad enough
<fwereade> davecheney, if you have flights that long though it may well be worth checking with marianna if you can have an overnight break in an airport hotel
<davecheney> fwereade: yeah, save my back
<fwereade> davecheney, I wasn't expecting that, but my very first trip had what would otherwise have been 8 hours on the floor of an airport
<davecheney> 16 hours LAX -> SYD
<fwereade> davecheney, swapping that for 5 hours in an actualy bed was very much a good move
<davecheney> was pretty sore by the end of it
<fwereade> davecheney, I bet
<davecheney> oh, and a return trip to POA was > 5,000 AUD, which was the 'piss off, we don't want to do it price'
<fwereade> davecheney, crikey
<fwereade> heya TheMue
<TheMue> fwereade: Morning
<fwereade> rog, TheMue: I would welcome opinions on https://codereview.appspot.com/6317043 (which, in hindsight, reads somewhat passive-aggressively, but I don't really know what to do about that :/)
<TheMue> fwereade: Passive-aggressively?
<fwereade> TheMue, http://en.wikipedia.org/wiki/Passive%E2%80%93aggressive_behavior
<fwereade> TheMue, the problem is perhaps that I didn't express the issues I had with that approach in those terms during the discussion
<fwereade> TheMue, in my mind, the assumed context was "it's obvious that this is a lot more work", but that may in fact not have been obvious to all participants
<TheMue> fwereade: Understand
<TheMue> fwereade: From a technological perspective LGTM.
<TheMue> fwereade: But I need more background to understand the problem you want to solve.
<TheMue> fwereade: Best in some simple words for a "newbie". ;)
<rog> fwereade: i see what you mean :-)
<rog> fwereade, TheMue: mornin' BTW
<TheMue> rog: Morning
<rog> hmm, my computer just crashed
<rog> if anyone said anything after my "mornin' BTW", i missed it
<TheMue> rog: Only my greeting after you re-entered the channel
<rog> TheMue: cool
<fwereade> TheMue, rog: rewritten; is it more helpful now?
<fwereade> TheMue, btw, wrt what you said earlier, that CL is IMO entirely unnecessary, and that's the reason I was whining so extravagantly in the description
<fwereade> rog, TheMue: btw, do you have a moment to discuss how I should test charm store access, from outside the charm package, without hitting the real charm store?
<rog> fwereade: sure
<fwereade> rog, ok... short of screwing up /etc/hosts, what *can* I do? :)
<rog> fwereade: is the charm store address hard-coded into the charm package?
<fwereade> rog, yeah
<rog> fwereade: well, one possibility would be to make it an exported variable that could be changed by testds
<fwereade> rog, sure; it just feels last-resorty
<rog> fwereade: of course then you've got to run some kind of your own server
<TheMue> fwereade: After reading the changed description it's more clear, thx.
<fwereade> rog, AIUI niemeyer is rather against exposing that at all
<fwereade> rog, as it is it's a const (because that was my understanding of niemeyer's perspective on the charm store)
<TheMue> fwereade: If the address is returned by a function we could introduce a package local variable switch by a function SetTestMode(bool).
<rog> fwereade: so what functionality are you needing to test exactly?
<TheMue> fwereade: When setting it to true the function returns localhost.
<fwereade> rog, that we can deploy a charm from the charm store
<fwereade> rog, I think there *may* be a case to be made that InferRepository is properly tested, and both local repos and the charm store are properly tested
<fwereade> rog, and that therefore hitting just one of the InferRepository code paths is actually adequate
<fwereade> rog, but my go-testing-fu is not adequate to determine whether this is defensible
<rog> fwereade: that sounds like it may be reasonable.
<rog> fwereade: there's no point in testing the same functionality in two different places
<fwereade> rog, yeah, that's what my heart says
<fwereade> rog, but it was hard work forcing myself to test everything a million different times in python when I joined the project
<fwereade> rog, and I haven't quite figured out how the prevailing rules have changed
<fwereade> rog, ok, I'll propose it as-is with an explanation
<rog> fwereade: seems reasonable.
<TheMue> rog, fwereade: Different topic, did you already booked you flights?
<rog> TheMue: yes, i've booked. arriving late sunday evening.
<fwereade> TheMue, ah yeah, I crash-stopped the booking the other day and haven't redone it yet
<fwereade> TheMue, ty for reminder
<TheMue> fwereade: np ;)
<TheMue> rog: Yes, I'll arrive at 21:45 and depart on Sat at 9:10.
 * TheMue only hopes he's now right with location and date :D
<rog> fwereade: when you say "we discard the actual data and retain only the version." which code are you referring to?
<rog> fwereade: or is this stuff as yet to be written?
<fwereade> rog, the python, and the proposed code
<rog> fwereade: so, in your view, it would be better to have a ConfigNodeWatcher or something like that?
<rog> fwereade: that passes the settings along as they change
<fwereade> rog, well, I don't think we need anything other than a map[string]interface{}
<fwereade> rog, except hmm no
<rog> fwereade: no?
<fwereade> rog, blast, I haven't fully thought through the cross-relation settings-settings
<rog> fwereade: that, i think, might have been part of gustavo's point
<TheMue> So, added the flight data to the wiki page.
<rog> fwereade: but explain, please.
<fwereade> rog, I'm just mainly thinking that there is no reason whatsoever for settings of relations of *other* units to be writable at all
<fwereade> rog, offering the opportunity to do do so can only lead to bugs and confusion
<rog> fwereade: why does setting *writing* make any difference to what we're talking about, which is *reading* settings, no?
<fwereade> rog, maybe it's just a slight discomfort with ConfigNodes used in read-only contexts
<fwereade> rog, (and a ConfigNode can be refreshed, too, which doesn't fit my idea of what we should be doing)
<rog> fwereade: you could return a ConfigNode with a nil zk :-)
<fwereade> rog, heh, that could work :)
<rog> fwereade: but tbh, why does it matter? we're not going to use it to set values.
<TheMue> rog: Not nice, better an own type.
<fwereade> rog, but actually, it's not an issue anyway -- you'll never see changes of your own unit's relation settings
<rog> fwereade: a config node represents a node with settings. we can choose not to write to it.
<fwereade> rog, so nothing we are ever watching ever has any reason to be anything other than read
<rog> fwereade: i'd be happy if it was <-chan map[string]interface{} too.
<rog> fwereade: is there a problem with that?
<fwereade> rog, and IMO we shouldn't even offer the opportunity to write it or update it, for similar reasons to those people use to justify public/private distinctions in code
<fwereade> rog, I'd like that
<fwereade> rog, ok, people can still write to a map[string]interface{} but at least they have no way of screwing up Zk state by doing so
<TheMue> fwereade: Otherwise just do a little type struct { data map[string]interface{} } with a Get(string) interface{}. So there's no chance.
<fwereade> TheMue, indeed, that would work nicely
<rog> TheMue: nah, let them use the map directly.
<rog> TheMue: there's no harm in writing to it.
<rog> TheMue: and then it's easy to range over, etc
<fwereade> rog, in general my problem is simply with discarding well-sequenced information just so we can approximately reconstruct it later, with additional code to make sure the sequence breaks are less common than they might be
<rog> i'd say either use a map, or a ConfigNode, but not something in between
<TheMue> rog: No harm to ZK, yes. OK, and the range may be an argument.
<rog> TheMue: an argument?
<fwereade> rog, I'm not even saying this leads to perfect consistency (config-get is still out of sequence), but it's more consistent with less code and I just don't see the downside
<TheMue> rog: For using the map directly.
<rog> fwereade: i definitely don't see the point in a version watcher.
<fwereade> rog, ok, there is a downside: we will store more data locally on the nodes
<rog> fwereade: we've got to get that data anyway, right?
<fwereade> rog, that doesn't seem to me to be a strong argument for all the extra complexity :)
<fwereade> rog,  indeed
<TheMue> rog: The ssh.go in state is by you, isn't it?
<rog> fwereade: and the version watcher is fetching all the content anyway.
<fwereade> rog, yeah
<rog> TheMue: no, that's me
<fwereade> rog, this is rather my point :)
<TheMue> rog: You *are* the ssh.go? ;)
 * rog blushes
<fwereade> TheMue, ssh, we don't want reporters involved
<TheMue> ;)
<rog> TheMue: i think you meant to say "You are *the* ssh.go?" :-)
<TheMue> rog: There are several fmt.Printf() in it, are they still needed?
<rog> TheMue: erp
<rog> TheMue: i don't see any fmt.Prints
<rog> TheMue: i see log.Printfs
<TheMue> rog: Oh, my mistake, just seen log. Sh**!
<TheMue> rog: So here the prefix "state:" is also still ok.
<rog> TheMue: they're probably a little excessive tbh, but i find them useful for the time being. perhaps they should be log.Debugf's
<rog> TheMue: yeah.
<TheMue> rog: I'm adding the errorContextf() so I found them and thought it would be debugging code. But in the log it makes sense.
 * rog goes downstairs to get a bowl of cereal
<fwereade> rog, I was just wondering some more about MachineUnitsWatcher
<rog> fwereade: uh huh?
<fwereade> rog, as you point out, we can't make a *Unit from a deleted unit
<fwereade> rog, but how are we keeping track of the things on the other end? might unit names be a better thing to pass around than units?
<rog> fwereade: i suggested that originally, but gustavo didn't like it
<fwereade> rog, isn't that how the client will be referring to the units in the first place?
<rog> fwereade: and actually, he's right
<fwereade> rog, bah, ok
<fwereade> rog, go on
<rog> fwereade: because if you look at the container API, it's phrased in terms of *Units
<rog> fwereade: which seems nice
<fwereade> rog, ah, ok, that does make sense
<rog> fwereade: although actually it might only use 'em for their names
<fwereade> rog, I kinda suspect it would ;p
<fwereade> rog, I have an analogous situation I would welcome input on
<fwereade> rog, ServiceRelationsWatcher
<rog> fwereade: yup. but... it's entirely possible that it might use more info from the unit for deployment in the future.
<fwereade> rog, yeah, could be
<rog> fwereade: although then we've got the out-of-date info problem, potentially.
<rog> fwereade: similar thing with ServiceRelationsWatcher, presumably?
<fwereade> rog, yeah; specifically I suspect we'll have a map[something]*RelatedUnitsWatcher that I'll want to remove watchers from (and stop them) as the service leaves relations
<rog> fwereade: so the ServiceRelationsWatcher is maintaining several watchers?
<fwereade> rog, I don't *think* it makes sense to use actual *Relations as keys (I should probably reread the spec and find out exactly what it takes to be usable as a map key)
<rog> fwereade: any pointer can be a map key
<rog> fwereade: (anything that defines equality can be a map key)
<fwereade> rog, no, the unit agent is maintaining several watchers which it starts/stops in response to the ServiceRelationsWatcher's changes
<fwereade> rog, ok, so actually I should be doing exactly what you're doing
<fwereade> rog, and define equality on Relations
<rog> fwereade: equality is defined on any pointer
<rog> fwereade: (the pointers are compared)
<rog> fwereade: you can't "define equality" on something
<fwereade> rog, ok, then that's surely not what I want
<fwereade> rog, so I had thought, my misinterpretation of your comments gave me hope
<rog> fwereade: what defines a relation in this context?
<fwereade> rog, the endpoints
<rog> fwereade: i.e. what information would you put in a key?
<fwereade> rog, hold on a sec
<fwereade> rog, what do you do in the machine agent when it comes up after an unexpected exit and wants to take down a container for a unit that no longer exists?
<fwereade> rog, how do you create the *Unit in that case?
<fwereade> rog, I have to solve the same problem in the unit agent with *Relations, I think
<rog> fwereade: there's no *Unit in that case
<fwereade> rog, how do you deal with it then?
<rog> fwereade: i have to look at running containers
<rog> fwereade: and see which of them do or don't correspond with current *Units
<fwereade> rog, and somehow find out what *Units... hmm, ok
<rog> fwereade: when we come up after an unexpected exit, we will never see units deleted.
<fwereade> rog, and how do you determine correspondence? by name, I presume?
<rog> fwereade: yeah, probably.
<fwereade> rog, yeah, I'm talking about purely at the agent level, when it has to diff last-known state against what the watcher says is current
<fwereade> rog, hold on
<rog> fwereade: depends how you store last-known-state
<fwereade> rog, can you give me an example of when we might want to know anything other than unit name to set up a container?
<rog> fwereade: perhaps the unit's service might have settings that influence how the LXC container is allocated
<fwereade> rog, isn't it a matter of setting up a named container, and poking in an upstart script to run `jujud unit foobar/17 ...`?
<fwereade> rog, the unit agent itself should surely be responsible for everything else
<rog> fwereade: i think things are a bit more involved when we're starting stuff within LXC containers
<rog> fwereade: but yeah.
<fwereade> rog, hmm, I fear I forsee another discussion-heavy afternoon :/
<rog> fwereade: for your ServiceRelationsWatcher, what would you use that corresponds to the use of unit names in MachineUnitsWatcher?
<fwereade> rog, that's what I'm asking
<rog> fwereade: for the record, i'm off on holiday at the weekend for two weeks. so good to get the discussions in now...
<fwereade> rog, I'm inclined to tweak describeEndpoints to sort the endpoints before joining them with " " and using that as a key
<fwereade> rog, very good to, I'm off thu/fri
<rog> fwereade: ah, so this is last day we're online together before ages away...
<fwereade> rog, one of those irritating situations where, really, I love to spend time with my family but right now feels rather inconvenient
<rog> fwereade: yeah
<fwereade> rog, I suspect I'll be sneaking away to work at night occasionally, but I probably won't coincide with you
<rog> fwereade: we'll be in the camper van in cornwall. almost entirely offline.
<fwereade> rog, cool, have fun :)
<rog> fwereade: you can use a struct as a key BTW
<rog> fwereade: e.g. map[struct{e1, e2 string}] *Relation
<rog> fwereade: so no need to join with " "
<fwereade> rog, number of endpoints is abritrary
<fwereade> rog, and I'm pretty sure I can't use a slice as a key, right?
<rog> fwereade: that's right
<rog> fwereade: number of endpoints is arbitrary pending more relation kinds than provides/requires/peer
<rog> ?
<rog> fwereade: or is it not to do with that?
<fwereade> rog, ATM only possibilities are 1 and 2
<fwereade> rog, that's exactly what it is
<rog> fwereade: why can't you use the relation key as a key?
<fwereade> rog, because I'm pretty certain maintaining the watchers is the unit agent's responsibility, and it doesn't feel like state is the right package
<fwereade> rog, ahhhh hmmm maybe I could use the relation ident
<rog> fwereade: we could add a Key method to Relation, i suppose.
<fwereade> rog, we expose that to users, even though it's just a thinly-disguised key
<rog> fwereade: relation ident?
<fwereade> rog, I'd prefer not to go down that path unless we have to
<fwereade> rog, for relation-0000000001, it's "relation-1"
<rog> fwereade: that seems like a fine thing to use for a key
<rog> fwereade: especially if it's exposed to users
<fwereade> rog, we export JUJU_RELATION_IDENT in foo-relation-* hooks so the charm can distinguish between the different runtime relations using the foo charm relation
<rog> fwereade: so maintaining a map of that to *Relation seems ideal to me
<fwereade> rog, I was thinking more a map of that to RelatedUnitsWatcher
<rog> fwereade: ok, sure.
<fwereade> rog, which might hold a *Relation, but I'm not even sure that's needed past construction time
 * fwereade slopes off for cig/think time
<Aram> hello everyone
<fwereade> Aram, heyhey
<rog> Aram: hiya
<fwereade> rog, fwiw, I was wrong: it's JUJU_RELATION_ID, not IDENT, and it's not relation-1: it's relation-name-according-to-service-1
<rog> fwereade: well, maybe that's a reasonable form for the unit agent to key it on too. because it's not going to hold any relations for any other services, right?
<fwereade> rog, yeah, agreed, I just wanted to corrcet the misconceptions that might right now be burrowing through your brain :)
<rog> fwereade: rooted out!
<fwereade> rog, btw, should I do a quick CL for the MustErr watcher stuff we discussed yesterday?
<rog> fwereade: sounds good
<fwereade> rog, or are you on that?
<fwereade> rog, cool
<rog> fwereade: nope, i'm on unit agent tests currently
<fwereade> rog, ah cool, what sort of thing?
<rog> fwereade: oops, i meant machine agent
<rog> doh
<fwereade> rog, ah rigt :)
<rog> boring :-)
<rog> fwereade: i'm just looking at cmd/juju/deploy.go BTW
<rog> fwereade: i wondered if unpacking the charm in memory is a good idea
<rog> fwereade: perhaps it would be better to store in a temp file instead
<fwereade> rog, hmm, maybe so
<rog> fwereade: and then for *charm.Bundle you could use the raw file as is
<rog> fwereade: (no need to read twice, even)
<rog> fwereade: 'cos charms could potentially be arbitrarily big
<fwereade> rog, indeed so
<rog> fwereade: i wonder if the charm.Charm interface should support BundleTo.
<fwereade> rog, possibly, I'd have to think about it a bit :)
<rog> fwereade: yeah, there may well be a good reason it's not there
<rog> fwereade: at the very least, charm.Bundle could implement BundleTo :-)
<rog> fwereade: although that kinda loses the point
<Aram> rog: a new inferno fan: http://debu.gs/entries/inferno-part-2-let-s-make-a-cluster
<rog> Aram: not new - this is the guy that did the post about my shell.
<Aram> ah, yes.
<rog> Aram: but it's really nice to see him get excited about it all
<rog> Aram: it still excites me actually, but i've kinda left it behind
<rog> Aram: it's always great to see people play with toys you've made yourself.
<Aram> yes, indeed.
<Aram> hi niemeyer.
<niemeyer> Hello!
<rog> niemeyer: yo!
<fwereade> niemeyer, heyhey
<fwereade> niemeyer, quick check: rick spencer is the head of my business unit, right?
<niemeyer> fwereade: yep
<fwereade> niemeyer, cool, tyvm
<niemeyer> fwereade: That reminds me of a guy back at Conectiva
<fwereade> niemeyer, oh yes?
<niemeyer> fwereade: He ranted with someone online on an internal mailing list
<niemeyer> fwereade: A couple of months after joining the company
<niemeyer> fwereade: Then, right after sending his last email to the rant, he asks "Who's that silly guy!?"
<niemeyer> fwereade: "It's your direct manager, dude.."
<fwereade> niemeyer, haha
<fwereade> niemeyer, in this case it's just because the travel agent wants to know
<niemeyer> fwereade: Good thing you're not fighting with him yet! ;-D
<fwereade> niemeyer, but I hope this guy called "sabdfl" I've been insulting isn't anyone in particular ;p
<niemeyer> LOL
<fwereade> niemeyer, btw, https://codereview.appspot.com/6298097 should be very quite, it's the mustErr stuff we discussed yesterday
<fwereade> s/quite/quick/
<niemeyer> fwereade: Looking
<niemeyer> I intend to to a good pass on everything now, btw
<niemeyer> Aram: Specially on yours long standing
<fwereade> niemeyer, cool, thanks :)
<Aram> niemeyer: great, I have charms and units in the queue.
<niemeyer> fwereade: Done
<TheMue> Grrr, router had a problem.
<fwereade> niemeyer, cool, thanks
<rog> fwereade: did you run all tests before submitting https://codereview.appspot.com/6298097/ ?
<rog> fwereade: i suspect it may have broken other packages
<fwereade> rog, oh, crap, I may have just done state/...
<rog> fwereade: yeah, i think it breaks cmd/jujud
<rog> fwereade: though i haven't checked
<fwereade> rog, I saw a ... in history, and...
 * fwereade hangs head in shame
<fwereade> rog, you're absolutely right :(
 * rog goes for lunch in the blessed sunshine
<fwereade> niemeyer, observe screwup above; now I've fixed that and really truly properly verified it's unbroken, what would happen if I were to just lbox propose/submit again in the same branch?
<Aram> meh, how can flight search technology be so bad.
<Aram> I mean, it's a trivial problem to solve.
<niemeyer> fwereade: Won't work
<niemeyer> fwereade: Just branch it over with "bzr checkout -b <original name>-fixup"
<niemeyer> fwereade: and then "lbox propose; lbox submit"
<fwereade> niemeyer, cheers, will do
<Aram> hmm, lbox propose (without -cr) uses the previously created cr on rietveld if it exists?
<fwereade> rog, it appears to me that there's something up with the container tests as well...
<niemeyer> Aram: Yep
<Aram> greta
<Aram> great
<niemeyer> Aram: The previous CL/merge proposal/whatever.. it updates whatever was done
<fwereade> rog, http://paste.ubuntu.com/1050880/
<niemeyer> Aram: Well, almost.. it won't touch existing bugs
<TheMue> fwereade: When I now start with ServiceRelation.AddUnit(), would I conflict with you?
<fwereade> TheMue, yes, please don't touch ServiceRelation, it's gone
<fwereade> TheMue, what are you planning?
<TheMue> fwereade: I'm thinking of continuing with the relation methods, but I know you're doing some changes there.
<TheMue> fwereade: Relation is gone, but ServiceRelation not yet.
<fwereade> TheMue, I would very much prefer if it we didn't step on each other relation-wise
<TheMue> fwereade: That's why I asked before. ;)
<fwereade> TheMue, I have one CL out and a whole *bunch* of stuff waiting in the wings that wants only for agreement and go-ahead on the current bits
<fwereade> TheMue, there's a missing thing for state.Service though... we don't have any way to set service config
<fwereade> TheMue, and I think that then implies the whole format 2 business
<TheMue> fwereade: OK, so I'll concentrate on other parts.
<niemeyer> Aram: Review sent
<Aram> thanks
<niemeyer> Aram: Please let me know if you'd like to talk
<TheMue> fwereade: OK, I'll take a look.
<niemeyer> Aram: Most points should be straightforward, though
<niemeyer> Aram: Glad to see this moving!
<Aram> yes!
<TheMue> fwereade: Todays code only has a get_config. What would you exactly expect from a SetConfig()? Isn't it normally done by retrieving the config, even if it's empty and then do changes and write it again?
<fwereade> TheMue, huh, you're perfectly right
<fwereade> TheMue, maybe a look at the format 2 stuff then if you're not too much averse to it?
<fwereade> TheMue, I had it planned but I seem to have got rather caught up in these bits, and I think it'll take me a few days to burn it down again
<TheMue> fwereade: No problem, but where do I find infos about the format 2 stuff?
<fwereade> TheMue, just a mo; I'll collect what I can find for you
<TheMue> fwereade: Thx.
<Aram> niemeyer: right now in ZK we use incrementing integer id's for some thing, this has the property of making nice names (/machine-0, /unit-1-0, etc), but in MongoDB incrementing integers are nasty: http://www.mongodb.org/display/DOCS/How+to+Make+an+Auto+Incrementing+Field
<Aram> so so we still want to go with incrementing integers in mongodb, or are random numbers fine?
<rog> Aram: flight search is actually turing complete: http://research.swtch.com/ita
<niemeyer> Aram: A machine id is an integer.. this isn't about MongoDB or ZooKeeper this is the API itself
<Aram> niemeyer: I'm not debating whether it should be an integer or not, but whether should be an incrementing integer or a random one :)/
<niemeyer> Aram: It should remain an incrementing integer
<niemeyer> Aram: 9879872198729831 won't be great :)
<rog> fwereade: ah! i see the problem. i've got jujud in my path, but you haven't.
<rog> fwereade: i think the test should probably create a fake jujud
<rog> fwereade: and set the path to point to it
<fwereade> rog, sounds sensible
<Aram> rog: I know the problem is computationally hard, my issue is that nobody publicly exports the flight data so people could build better 3rd party software than the crap software flight agencies provide.
<rog> Aram: true too
<niemeyer> Aram: Btw, how is it nasty to increment an integer in MongoDB?
<niemeyer> Aram: It's a trivial inc operation
<niemeyer> Aram: I suggest adding a "sequence" collection, where the _id is the collection name
<niemeyer> Aram: and having a sequence(name string) (int, error) helper in State
<Aram> niemeyer: so in that link I sent you, you prefer option #1 to option #2?
<Aram> that's perfectly fine by me.
<niemeyer> Aram: I prefer to have a scheme as suggested above
<niemeyer> Aram: So we can reuse this next time we need a sequence number
<Aram> yes, it's great.
<Aram> ok.
<Aram> niemeyer: is it possible to create a new bzr branch, but use the same CR as an existing branch?
<niemeyer> Aram: nope
<Aram> bummer
<niemeyer> Aram: Well, maybe yes
<niemeyer> Aram: But why?
<Aram> niemeyer: I did the mistake of using my trunk for the changes you reviewed, I ported them to a different branch, but that also created a new CR...
<niemeyer> Aram: I think it can be made to work:
<niemeyer> Well, you already created a new CL, right?
<Aram> yes
<niemeyer> Aram: Edit the description in the *new* merge proposal, and change the very last link of codereview to point to the proper place
<Aram> interesting
<niemeyer> Aram: Then, mark the last branch as Rejected
<niemeyer> Aram:  and run "lbox propose" again
<niemeyer> Aram: It's not great to be doing this because the merge proposal will lose part of the history
<Aram> ok.
<niemeyer> TheMue: Reviewed https://codereview.appspot.com/6300098/ again
<TheMue> niemeyer: Just seen, thx
<niemeyer> TheMue: please ping me if you repush soon and I'll have an immediate look so we can integrate
<niemeyer> Aram: Yeah, so we need to do something with this, since it's a copy of the last branch: https://codereview.appspot.com/6295103/
<TheMue> niemeyer: Should be only a few moments.
<niemeyer> Aram: Are you doing the trick mentioned?
<Aram> niemeyer: yes
<niemeyer> Aram: Super
<Aram> niemeyer: how do I mark a branch as rejected?
<niemeyer> Aram: Sorry, not the branch, the merge proposal
<Aram> same question, where do I do that? :)
<niemeyer> Aram: I've marked it as Work In Progress
<niemeyer> Aram: In the merge proposal page itself
 * niemeyer finds
<niemeyer> "Sorry, there was a problem connecting to the Launchpad server."
<Aram> heh
<Aram> "Delete proposal to merge"?
<Aram> this onw
<Aram> one
<Aram> ?
<niemeyer> Aram: Done
<niemeyer> Aram: No need to delete
<niemeyer> Aram: It has some history there
<niemeyer> Aram: I've marked it as Rejected
<niemeyer> Aram: and added a note pointing out to the new MP
<Aram> niemeyer: I think it worked, https://codereview.appspot.com/6304099 shows the correct branch.
<Aram> niemeyer: but the issue is closed, is that expected?
<niemeyer> Aram: No, this doesn't happen automatically.. have you closed it by hand?
<niemeyer> Aram: lbox will only close on submit, which hasn't happened
<Aram> niemeyer: ah, yes, sorry, my fault, forgot I closed it yesterday.
<Aram> so I can open it again
<Aram> done
<Aram> great
<niemeyer> Super
<Aram> thanks again niemeyer
<TheMue> niemeyer: So, had a text conflict to resolve first, but now it's in again.
<hazmat> bcsaller, ping
<niemeyer> Aram: np!
<niemeyer> fwereade: you've got a review on https://codereview.appspot.com/6312048/
<niemeyer> fwereade: Let me know if you'd like to talk about it so we can get this in soonish
<niemeyer> fwereade: I'll be stepping out for lunch in a moment
<niemeyer> TheMue: Super, will look
<fwereade> niemeyer, I'd be happy to, reading now
<niemeyer> TheMue: LGTM
<TheMue> niemeyer: Thx, will submit it now.
<fwereade> niemeyer, ok, I think I agree with what you have there
<fwereade> niemeyer, sorry about the Id, it seemed like a good idea at the time :/
<niemeyer> fwereade: Actually, LGTM with that in.. doesn't seem to be controversial in any way.
<niemeyer> fwereade: No worries, I actually find the value of JUJU_RELATION_ID a good user-facing feature
<niemeyer> fwereade: When sitting within the unit, that relation id makes perfect sense
<niemeyer> fwereade: In state not so much
<fwereade> niemeyer, well, I'd love to get this in... but I guess I'm not sure what in particular differentiates the review from a LGTM-with-these-fixes one
<fwereade> niemeyer, most of your suggested changes seem sane and simple
<fwereade> niemeyer, which ones are subtler than I think at first glance?
<niemeyer> <niemeyer> fwereade: Actually, LGTM with that in.. doesn't seem to be controversial in any way.
<niemeyer> fwereade: ?
<fwereade> niemeyer, ah, ok, I see
<fwereade> niemeyer, so, you're OK with the implementation of Id as it is?
<niemeyer> fwereade: Nope, with the suggested change
<fwereade> niemeyer, just the int then, cool
<niemeyer> fwereade: func (r *Relation) Id() int
<fwereade> niemeyer, great
<niemeyer> fwereade: (no error even.. we have the key)
<fwereade> niemeyer, indeed
<fwereade> niemeyer, ok, I'll fix those and submit
<fwereade> niemeyer, tyvm
<niemeyer> fwereade: Thanks a lot
<fwereade> niemeyer, a pleasure :)
<niemeyer> fwereade: I'm afraid I don't have enough time to cover it before lunch, but maybe we should talk about the VersionWatcher stuff afterwards
<niemeyer> fwereade: I'm missing the context
<fwereade> niemeyer, I would be very keen to
<niemeyer> fwereade: You seem unhappy with it, and I don't even know why we need it, which means we should talk :)
<fwereade> niemeyer, definitely -- I was trying to talk about it yesterday, but in hindsight I was framing the discussion all wrong
<fwereade> niemeyer, I'm not sure precisely when I'll be around this evening
<niemeyer> fwereade: No worries
<niemeyer> fwereade: We can talk whenever
<niemeyer> fwereade: We have enough overlap for this to not be an issue
<fwereade> niemeyer, and I'm off after that until the end of the week -- *but* this is a subject dear to my heart atm so I will definitely track you down at some point before the weekend
<niemeyer> fwereade: Oh, I didn't know that, ok
<fwereade> niemeyer, (it is a pleasure to see my family... but curse the timing)
<niemeyer> fwereade: Take a good rest and enjoy their presence
<fwereade> niemeyer, I *think* I mentioned it a while ago but I forgot to actually book it...
<fwereade> niemeyer, cheers :)
<fwereade> niemeyer, after that I think I'm saving my holiday for post 12.10 :)
<niemeyer> fwereade: It will be quite a walk towards it :)
<fwereade> niemeyer, it feels like we're doing ok so far :)
<niemeyer> fwereade: Indeed, very happy with how we've been pushing things forward
<niemeyer> fwereade: Real momentum
<fwereade> niemeyer, absolutely, it makes even a short holiday feel quite the unwelcome intrusion ;)
<niemeyer> fwereade: Hehe :)
<niemeyer> Alright!
<niemeyer> Time to find some nice lunch
<rog> fwereade: is it possible for a service to be subordinate to more than one other service?
<fwereade> rog, hmmm
<fwereade> rog, I wouldn't swar you couldn't write a charm that implied such a relationship :/
<rog> fwereade: it certainly seems possible in the state API.
<fwereade> rog, but I don't think such an arrangement makes any sense
<fwereade> rog, how so?
<fwereade> rog, ah, wait, reparsed: I think it makes perfect sense
<fwereade> rog, deploy wordpress; deploy mysql; depoy logging; add-relation logging mysql; add-relation loggin wordpress
<rog> fwereade: you can d1 = AddService("wordpress"); d2 = AddService("wordpress"); sub1 = AddService(subord); d1.AddUnit(); sub1.AddUnitSubo .... you got it
<fwereade> rog, sorry, I have units on the brain at the moment, ahd totally wrong context
<rog> fwereade: ok, so that's fine. good
<rog> fwereade: thanks
<Aram> niemeyer: did all the requested changes including monotonically increasing integer ids and state compatible errors.
<rog> niemeyer, fwereade: machine agent implementation: https://codereview.appspot.com/6294096/
<fwereade> rog, cool
<rog> fwereade: if you manage to give some feedback today, that would be marvellous, as it would be nice to polish it tomorrow & friday.
<fwereade> rog, I'll do what I can :)
<rog> fwereade: ta! :-)
<imbrandon> where should this be filed http://15.185.100.228/out.charmload
<rog> imbrandon: juju-core, i think
<imbrandon> k
<rog> niemeyer: looks like your schema checking isn't quite sufficient...
<imbrandon> https://bugs.launchpad.net/juju-core/+bug/1015700 :)
<fwereade> rog, initial thoughts posted
<rog> fwereade: thanks. BTW the fact that the watcher returns subord units too was decided after fairly extensive debate with niemeyer.
<rog> fwereade: that change was why i ended up adding the isPrincipal field to state.Unit
<rog> fwereade: which makes the current behaviour more or less cost-free
<fwereade> rog, cool, I'm always open to counterarguments/being overruled :)
<fwereade> rog, in that narrow context it seems like a slightly odd decision, but I'm sure there's context I'm not seeing
<rog> fwereade: and it's nice if status commands could potentially use Machine.Units to pull out stuff for a status, for example.
<fwereade> rog, I'm ok with that, but less sure that Units and WatchPrincipalUnits aren't both sensible methods for their particulat uses
<rog> fwereade: i don't see the extra four lines of code as particularly onerous
<fwereade> rog, it's the *indentation*! the horror, the horror! ;p
<rog> fwereade: oh well, if *that's* what you don't like, i'll do: if !u.IsPrincipal() {continue} :-)
<fwereade> rog, haha :)
<Aram> what the hell does bzr want from me this time: http://paste.ubuntu.com/1051236/
<Aram> I only did a bzr pull
<Aram> bzr revert fixed it
<Aram> but... what's the procedure with these things?
<fwereade> Aram, was that a pull from a branch which included mate into a branch that had mstate but hadn't yet added it?
<fwereade> Aram, but I'm not sure it's any nicer when it has been added
<Aram> fwereade: I pulled from lp:juju-core into my mstate branch.
<fwereade> Aram, why merge rather than pull?
<fwereade> Aram, er vice versa
<Aram> hm? I should have done bzr merge instead of bzr pull?
<fwereade> Aram, I basically never pull, but I can't claim to have anything more than a vague intuitive understanding of bzr in the first place
<Aram> hmm, this is strange. in hg/git you always pull, there's no other way.
<Aram> so here pull does soemthing else...
<fwereade> Aram, my workflow is almost always `bzr branch <prereq-or-trunk>`, followed by regular `bzr merge`s to keep the local branch up to date
<Aram> ok, I'll try that.
<Aram> fwereade: thanks, it worked.
<fwereade> Aram, excellent :)
<Aram> basically I never have to use pull.
<Aram> strange.
<fwereade> Aram, IME messing around with checkouts and pulls inevitably causes me pain
<fwereade> Aram, branch, merge, and push do basically everything I need
<fwereade> Aram, with ocasional judicious use of --remember on merge or push
<rog> fwereade: do you think all watchers should implement Err()? it seems to me like calling Stop is enough.
<Aram> "TOO LONG (>50)" change summaries are limited to 50 chars?
<rog> fwereade: no more substantial comments?
<rog> fwereade: actually, publish them on the CL if you have some. i've gotta go!
<rog> fwereade: thanks a lot for the review BTW
<rog> fwereade: have a great long weekend, and i'll see you in a little over 2 weeks' time
 * rog is off. see y'all (william excepted) tomorrow!
<rog> fwereade: i think i fixed that container test bug BTW. it'd be good if you could test it on your machine.
<rog> fwereade: https://codereview.appspot.com/6302103/
<Aram> rog: fwereade: TheMue: trivial one liner: https://codereview.appspot.com/6305121
 * niemeyer waves
<niemeyer> Aram: LGTM
<niemeyer> Aram: Just in time ;)
<niemeyer> rog: LGTM too
<Aram> niemeyer: what do I do now, lbox submit? why does it want to update the description again?
<TheMue> Aram: LGTM, I prefer this style of durations.
<niemeyer> Aram: It's a chance for you to adjust it before committing, if necessary
<Aram> niemeyer: ah, ok
<Aram> niemeyer: I updated the mstate CR with everything you said
<Aram> TheMue: yes, indeed.
<niemeyer> Aram: Cool, will have a look now
<niemeyer> Aram: Hmm.. your branch is not in the queue
<niemeyer> Aram: Did you run lbox propose again?
<Aram> yes
<fwereade> niemeyer, I'm around for a bit; are you free for a quick talk about VersionWatcher and related affairs? say in 10 mins perhaps, if you're in midflow with Aram?
<niemeyer> Aram: So something isn't right
<Aram> niemeyer: maybe I should click on "resubmit proposal" on the lpad website?
<niemeyer> Aram: Nope.. just "lbox propose" on the right branch should do it
<niemeyer> fwereade: Yeah, sounds good
<fwereade> Aram, the fantastic thing about lbox is you basically never need to visit launchpad ;)
<fwereade> niemeyer, cool, off for a ciggie then, bbs, ping me when you're free
<niemeyer> Aram: Change *summaries* are limited to 50 chars.. change descriptions are not
<Aram> niemeyer: yes, I figured.
<niemeyer> Aram: These summaries end up in emails etc
<niemeyer> As in, subjects
<Aram> niemeyer: what about now, is it in th queue?
<Aram> I did lbox propose again
<niemeyer> Aram: It is
<niemeyer> Aram: Thanks
<Aram> niemeyer: ah, I did -wip before.
<niemeyer> Aram: Ah, that'd explain it
<Aram> I didn't want to spam you all with emails while I was doing experiments.
<Aram> personally I get enough email already.
<niemeyer> Aram: Did you change the branch name a third time?
<Aram> niemeyer: I did change it three times, yes, but all the hacketry we did today was with name it has now...
<niemeyer> Aram: Okay, please don't keep changing branch names as it spreads references around
<niemeyer> Aram: The note I added to the previous MP is broken, for example
<Aram> I'll try to.
<niemeyer> Aram: There's something wrong in your setup still
<niemeyer> Aram: "Aram HÄvÄrneanu (aramh) wrote 4 minutes ago:"
<niemeyer> https://code.launchpad.net/~aramh/juju-core/juju/+merge/110920
<niemeyer> Aram: This means a local branch is being pushed onto the old location still
<Aram> hmm? how can I check/debug?
<niemeyer> Aram: try "bzr info" on the branch itself
<niemeyer> Aram: Well, maybe lbox is actually picking the wrong one
<niemeyer> Aram: Let's just delete the old MP
<niemeyer> Aram: Done.. please delete this branch too: https://code.launchpad.net/~aramh/juju-core/juju
<Aram> done
<Aram> niemeyer: now what?
<niemeyer> Aram: Okay, now run "bzr info" on bzr.. let's make sure it's not referring to the old name
<niemeyer> on the branch, I mean
<Aram> niemeyer: http://paste.ubuntu.com/1051331/
<niemeyer> Aram: Okay, I suppose you're not using cobzr
<Aram> I am
<Aram> white:mstate$ cobzr branch
<Aram>   master
<Aram> * mstate-machine-basic
<Aram>   store-mgo-timeconsts
<niemeyer> Aram: Oh, sorry, I misread
<niemeyer> Aram: What "bzr nick" tells you?
<Aram> white:mstate$ bzr nick
<Aram> mstate-machine-basic
<niemeyer> Aram: Looks good
<niemeyer> Aram: Try lbox propose again then, with -v please
<Aram> ok
<Aram> niemeyer: http://paste.ubuntu.com/1051334/
<niemeyer> Aram: Yay, looks good
<niemeyer> Aram: Aha, I know what's wrong
<Aram> niemeyer: what is? is it on my side?
<niemeyer> Aram: The email of the Launchpad MP on the CL is outdated
<niemeyer> Aram: Can you please edit it as you're the only one with permission?
<niemeyer> Aram: It should say 111235 rather than 110920
<Aram> ok, let me try it
<Aram> done
<niemeyer> Aram: Outstanding.. should all be in sync now
<niemeyer> fwereade: Do you wanna talk before I dive into the review?
<fwereade> niemeyer, please
<niemeyer> fwereade: Cool, so what's up.. tell me about a VersionWatcher :)
<fwereade> niemeyer, so... it seemed to me that we discussed the python style of related-unit watching
<fwereade> niemeyer, in which we track settings version changes
<niemeyer> fwereade: Ok
<fwereade> niemeyer, and then, when we come to execute hooks, we grab the latest settings for a given unit relation and then cache them for the duration of the hook
<fwereade> niemeyer, this feels to me like unnecessary extra work -- we have the node data, we reduce it just to a version, and then later we grab the node data again and do extra work to make it appear constant
<niemeyer> fwereade: Kind of.. I think you know it, but just to be super clear, it's cached at the time of first query
<niemeyer> fwereade: Right?
<fwereade> niemeyer, yes, first query per unit relation per hook, AIUI
<niemeyer> fwereade: Ok
<fwereade> niemeyer, it seems to me that this is an awful lot of work to go to when we could just grab the settings as they change
<niemeyer> fwereade: Okay, can we please have a step back.. you seem to be assuming an implementation
<niemeyer> fwereade: Where does that assumption comes from?
<niemeyer> come
<niemeyer> fwereade: Then, as a follow up question, what does "as they change" mean in the last sentence
<fwereade> niemeyer, well, I was trying to suggest that that implementation, despite the fact that it's what we do in python, is an awful lot of work for little benefit, when we have all the data available anyway
<niemeyer> fwereade: What does grab the settings as they change mean?
<fwereade> niemeyer, it means we should, IMO, record the actual contents of the node (in one form or another... I kinda favour plain ol' map[string]interface{}, but that's by the by)
<fwereade> niemeyer, rather than just the version of the node
<niemeyer> fwereade: Okay, so..
<fwereade> niemeyer, I don;t think I'm assuming an implementation -- I'm comparing a proposed one with the existing python one
<fwereade> niemeyer, and trying to get buy-in on the idea that it is worth pursuing
<niemeyer> fwereade: I meant it assumes an approach already, when it wasn't clear what this was about
<niemeyer> fwereade: I'm not judging, just trying to understand the background
<fwereade> niemeyer, I understand, I clearly haven't communicated this especially well
<niemeyer> fwereade: I think I have a better idea now
<niemeyer> fwereade: As I understand it, there are two different problems, and they are being conflated in a single piece, which confuses the problem statement a bit more
<fwereade> niemeyer, I definitely took the wrong approach yesterday -- "this leads to a more consistent hook execution environment" is fundamentally not interesting, but "this saves us a bunch of work" hopefully leads to a more interesting discussion
<niemeyer> fwereade: The first problem is caching
<fwereade> niemeyer, ok, yes;
<niemeyer> fwereade: Caching is done so that we can implement more manageable data visibility for hooks
<niemeyer> fwereade: So in effect, it's about *not showing changes*
<niemeyer> fwereade: Slightly ironic, as the other problem is on the opposite end
<niemeyer> fwereade: The second problem, is related to restarts
<fwereade> niemeyer, yes: during the execution of a single hook, we don't want the environment to visibly change
<niemeyer> fwereade: (at least the settings data)
<niemeyer> fwereade: So, with the second problem, we have the issue that we may lose events
<niemeyer> fwereade: Because there's of course zero guarantee that we'll be permanently connected to whatever the backend turns out to be
<fwereade> niemeyer, indeed so
<niemeyer> fwereade: So in that sense, we're interested in knowing whether things have changed since we last looked
<niemeyer> fwereade: where "last looked" may be a process restart ago
<niemeyer> fwereade: For that, we don't really care about what the content was
<fwereade> niemeyer, AIUI, though, the losing-events problem is always potentially in play... ZK doesn't guarantee I'll see 2 changes to a node that changes twice, does it?
<niemeyer> fwereade: Because we just wanna know if we're supposed to tell the charm implementation that the data has changed, via a hook execution, or not
<fwereade> niemeyer, sure
<niemeyer> fwereade: It doesn't, but that's fine. We offer at-least-once semantics
<fwereade> niemeyer, but the actual data tells us that just as well as the version does
<fwereade> niemeyer, in fact, it tells us better
<niemeyer> fwereade: Without taking into consideration any implementation suggestions,
<fwereade> niemeyer, if there's a change followed by a revert while we're offline, diffing the settings reveals that there are no changes we care about
<fwereade> niemeyer, sorry, yes, go on
<niemeyer> fwereade: it's a bit strange to cache a blob of, say, 64kb, when the text "42" would do
<fwereade> niemeyer, ok, so this is an optimization?
<niemeyer> fwereade: It's not an optimization.. I'd call it non-silliness, from that specific perspective
<fwereade> niemeyer, ok, that is indeed a reasonable perspective
<niemeyer> fwereade: But go on, you seem to have more detials
<niemeyer> details
<niemeyer> fwereade: This was just background
<fwereade> niemeyer, I'm not certain that perspective is worth the extra complexity involved in throwing away data and then reconstructing and caching it, when caching from the get-go leads, in my mind, to a much simpler model
<niemeyer> fwereade: Sorry, but you're again jumping on a bit
<niemeyer> fwereade: Why do we need to reconstruct and cache anything?
<niemeyer> fwereade: This data is old.. we don't use it anymore.
<fwereade> niemeyer, well, distributed system, the data is always old
<niemeyer> fwereade: No, that's not what I mean
<fwereade> niemeyer, ok; sorry to be dense; please restate
<niemeyer> fwereade: In the scenario I just described, we track the version so that, in case of restarts, we know whether we must run a hook or not
<niemeyer> fwereade: If we do detect an out-of-date situation, we run the hook
<niemeyer> fwereade: We don't care about what the *data* used to be.. that 64kb fromt the old version is trash
<fwereade> niemeyer, ok, and that is a slightly eager but reasonable heuristic for rerunning hooks
<niemeyer> fwereade: Eager?
<fwereade> niemeyer, a newer version does not necessarily imply that the data we care about has changed
<niemeyer> fwereade:
<fwereade> niemeyer, but that's not a flaw worthy of the term flaw, let alone worth arguing over
<niemeyer> fwereade: Does it generally change or not when we bump a version?
<niemeyer> fwereade: We shouldn't be bumping the version of settings nodes without changes
<niemeyer> fwereade: I'd consider that a bug
<fwereade> niemeyer, sure, understood, but versions don't revert when the data does -- but regardless, can we drop this? it's a derail
<niemeyer> fwereade: Okay, yes, agreed regarding reverts, and agreed regarding derail.
<niemeyer> fwereade: Okay, now, should we talk about VersionWatcher in that context, or is there some background that is missing in that brainstorm?
<fwereade> niemeyer, ok, that sounds interesting
<fwereade> niemeyer, if there's some that's relevant it will no doubt become apparent
<fwereade> niemeyer, my reading was that *if* we're tracking settings node versions, a VersionWatcher is just the ticket
<niemeyer> fwereade: Well, I'm not sure, and that's what I'd appreciate gaining more insight into
<fwereade> niemeyer, I'm hoping that you have some insight I've missed here ;)
<niemeyer> fwereade: When the agent *is* running, we're interested not only in the version but also in the data, since as we've discussed it may be queried and cached
<fwereade> niemeyer, ...ok, wait, I thought you were just arguing against caching the data outside of indivdual hook executions
<niemeyer> fwereade: I'm arguing against saving it persistently
<niemeyer> fwereade: and trying to understand whether we should be caching it in memory or not
<niemeyer> fwereade: to solve problem *1*
<fwereade> niemeyer, ah-HA, this is a distinction that had entirely escaped me
<fwereade> niemeyer, ty for clarification
<niemeyer> fwereade: Problem 2 doesn't require data.. problem 1 does
<fwereade> niemeyer, this is true; I maintain that the same data *could* be used to solve problem 2 as well, but I agree that it is not necessary when one considers problem 2 in isolation
<niemeyer> fwereade: It could. It's just misoptimization. :)
<fwereade> niemeyer, that may well be so :)
<fwereade> niemeyer, although what I was trying to optimize when I thought of it was simplicity of implementation, which is IMO a pretty good candidate for first-thing-to-optimize
<niemeyer> fwereade: Comparing two integers counts highly in my simplicity-meter
<niemeyer> :)
<niemeyer> fwereade: You may have further information that reveals why it is simpler to do something else, though
<fwereade> niemeyer, it's simply that we don't need to get and cache individual relation settings in a hook context if we already have them available
<niemeyer> fwereade: I agree!
<niemeyer> fwereade: That's about problem 1, though.
<niemeyer> fwereade: And we get a version every time we get data out of ZooKeeper
<niemeyer> fwereade: So there's a relationship between them
<niemeyer> fwereade: We can solve both problems with a single watcher, cache the data for problem 1, and keep the version around for problem 2.'
<fwereade> niemeyer, ok, I did think of just extending ContentWatcher to include the version
<niemeyer> fwereade: +1
<fwereade> niemeyer, and let the clients discard what they will
<fwereade> niemeyer, I think I have to go now; I think I'll want to talk about this some more over the next couple of days though
<niemeyer> fwereade: Sounds good. Hopefully that was useful.
<fwereade> niemeyer, thank you, I think we;re making progress :)
<niemeyer> fwereade: Glad to hear it, and you're welcome
<fwereade> niemeyer, I'm not quite there yet though ;)
<fwereade> niemeyer, cheers
<fwereade> niemeyer, happy evening :)
<niemeyer> fwereade: Have a good one
<niemeyer> Aram: So, back to your branch
<Aram2> right
<niemeyer> Aram: Had another pass: https://codereview.appspot.com/6304099
<niemeyer> Aram: Probably the last one
<niemeyer> Aram: It's looking great
<Aram> niemeyer: thanks for the review.
<niemeyer> Aram: My pleasure
<davecheney> howdy, anyone seen mark
<davecheney> https://twitter.com/campoy83/status/215255686592995331
#juju-dev 2012-06-21
<rog> davecheney: mornin' boss
<davecheney> rog: ahoy!
<rog> davecheney: it's funny, i saw gustavo's response to 6304104 but not the original proposal email
<rog> davecheney: am looking at it now
<davecheney> rog: ta
<rog> davecheney: hmm
<rog> davecheney: i'm wondering if the interface shenanigans are worth it
<rog> davecheney: how about just using a different type for each operation, e.g. http://paste.ubuntu.com/1052155/
<davecheney> rog: what is the type returned on the channel ?
<davecheney> interface{} ?
<rog> davecheney: we could put a private method on it
<rog> davecheney: then it could still be Operation
<davecheney> switch o := o.(type) { case ... } ?
<rog> davecheney: yeah, except we never need to do that AFAICS. i've only done a cursory look mind
<rog> davecheney: i think we always know what operation we're expecting
<rog> c.Assert(op, Equals, dummy.OpBootstrap{env, inst})
<rog> davecheney: s/OpBootstrap/OpStartInstance/
<davecheney> rog: sure
<rog> and that wouldn't work of course because equality isn't defined on Instances
<rog> and but you get the idea.
<rog> it means we can lost all the OperationKind stuff and the table. so we probably save lines overall.
<rog> s/lost/lose/
<davecheney> rog: nice, I always wanted to switch on the type, rather than a synthetic kind field
<rog> davecheney: something like this perhaps, if we want an Operation type. http://paste.ubuntu.com/1052161/
<rog> davecheney: cool
<rog> davecheney: oops, isOperation should be defined on OpEnv
<rog> davecheney: although... that won't print so nicely
<rog> davecheney: scratch that last suggestion
<rog> davecheney: could go with something like this: http://paste.ubuntu.com/1052167/; or just use interface{}.
<davecheney> rog: feels a bit forced
<rog> davecheney: the Operation type?
<davecheney> all those empty methods to satisfy the interface
<rog> davecheney: yeah. there is precedent (go/ast) but i think it's probably best to use interface{}
<rog> davecheney: it's not a public-facing API after all
<Aram> moin.
<TheMue> Moin
 * TheMue wanted to start later after doing some sports but the club is closed this morning. It seems the morning shift has overslept.
<rog> Aram: hiya
<rog> TheMue: hiya
<TheMue> rog: Hi, just had to restart after firmware update.
<rog> I like it when I'm reading an IRC conversation from some hours ago and thinking "I'd want to say *this*", then the conversation ends up at exactly that conclusion.
<rog> i'm off into town to fetch my bike and buy a replacement jacket for the one i left behind in Oakland (:-[). back in a couple of hours.
<Aram> bokes are great
<Aram> bikes
<hazmat> Aram, any thoughts on the loss of atomicity and ordering with mongodb (my reply on your thread on list)?
<hazmat> ie. given multiple collections to insert for observation/notification
<Aram> there's no loss of ordering.
<Aram> atomicity may be a problem.
<Aram> but ordering should not be.
<hazmat> Aram, lacking atomicity, with concurrent ops, how can retain ordering
<hazmat> ie. given logical ops A and B and their respective inserts, they could go A1, B1, B2, A2
<Aram> there's an atomic sequencing mechanism that generates incrementing integers, and these integers can be used to query for data in a particular order.
<Aram> hazmat: basically the sequencing mechanism is atomic because we make it so, it's a single document.
<hazmat> Aram, combined with locking? what's a sequence flow look like..
<hazmat> of a logical op
<hazmat> get sequence value, lock observation collection, atomic update doc using sequence value as condition, insert into observation collection, unlock?
<Aram> n reset by peer)
<Aram> <davecheney> howdy, anyone seen mark
<Aram> meh
<Aram> dumb paste
<Aram>  
<Aram> hazmat: there's no locking in mongodb.
<Aram> hazmat: I can't answer your question because we haven't decided yet :-).
<Aram> hazmat: I only made sure we can implement a mechanism if/when we need it, whatever that mechanism might be.
<Aram> hazmat: for example we can implement full transactions using multi-phase commits, if we consider it necessary, but we hope we would not need such a heavy weight mechanism.
<Aram> hazmat: I can tell you the technical details of various mechanisms we might use, but I can't tell you which one will use at this early stage. probably gustavo has some better insight.
<hazmat> Aram, right re locking i meant app locking not native primitives, and thanks for clarifying the current state
<marrusl> hey juju folks...  for Juju on openstack, is swift required?
<marrusl> hrm... maybe wrong channel ;-)
<marrusl> i'll check in #juju
<Aram> hi niemeyer
<niemeyer> Yo!
<rog> niemeyer: hiya
 * Aram is amused by people who censor profanity words on the internet.
<niemeyer> Aram: Yeah, seriously
 * TheMue moved on the veranda to continue work there.
<TheMue> niemeyer: Hi.
<TheMue> niemeyer: After a talk yesterday I started to read the mail thread and CL regarding format: 2.
<TheMue> niemeyer: A talk to fwereade
<TheMue> niemeyer: Shall I continue with that topic or with non-relation topics in state? Like e.g. hooks.
<niemeyer> TheMue: Hmm
<niemeyer> TheMue: Hooks are not really in state, and fwereade has already been moving towards having them working
<niemeyer> TheMue: What else is missing from state?
<TheMue> niemeyer: Maybe I said it wrong. In Py in state there are hook, firewall, auth and security.
<TheMue> niemeyer: Those are still open.
<TheMue> niemeyer: I wanted to continue with relation but fwereade is doing there a lot and asked me to take another topic.
<TheMue> niemeyer: That's why he passed me infos about format 2.
<niemeyer> TheMue: Yeah, handling the change to format 2 sounds like a good  idea
<niemeyer> TheMue: It's just out of state, AIUI
<niemeyer> TheMue: Which is why I asked if you're leaving something else behind
<TheMue> niemeyer: Those four files above and relations, then state should have been done.
<TheMue> niemeyer: So far I compared it file by file and type by type.
<niemeyer> TheMue: That's fantastic
<TheMue> niemeyer: But I could do a usage scan (Where is state used today?) and see what functionality is missing in the Go port.
<niemeyer> TheMue: So it sounds like it's pretty much done indeed
<niemeyer> TheMue: The last two are not going to be ported as we'll want to do something else
<niemeyer> TheMue: Hooks, as I mentioned, is very close to the implementation of the unit agent, and shouldn't be done in isolation
<TheMue> niemeyer: Yes, you once said it when I started with auth.
<niemeyer> TheMue: Firewall may be the more interesting bit
<Aram> my T410 is overheating sometimes, had the same problem with my T400.
<TheMue> niemeyer: So I could do firewall first.
<niemeyer> TheMue: I'm having a look at it
<TheMue> niemeyer: Just to get the state done.
<niemeyer> Aram: I haven't been having it with T410, but I had it all the time on the T60
<niemeyer> TheMue: Hmmm
<niemeyer> TheMue: We have to do firewall, but it shouldn't look like what is there right now
<niemeyer> TheMue: It has a *provider* in the constructor, which makes no sense for a state package
<TheMue> niemeyer: Yes, just scanned the code quickly. It's using the state, but it is no state.
<TheMue> niemeyer: Interesting.
<niemeyer> TheMue: It is state to some degree
<niemeyer> TheMue: It's just mixed up
<niemeyer> TheMue: Most of that file is really preparing for this:
<niemeyer>             for port, proto in to_open:
<niemeyer>                 yield self.provider.open_port(machine, machine_id, port, proto)
<niemeyer>             for port, proto in to_close:
<niemeyer>                 yield self.provider.close_port(machine, machine_id, port, proto)
<niemeyer> TheMue: We have to invert the relationship as usual for watchers
<niemeyer> TheMue: This is a type along the lines of PortChanges { Opened Closed }
<niemeyer> TheMue: and Machine.WatchOpenPorts
<TheMue> niemeyer: IC
<niemeyer> TheMue: Or really, Machine.WatchPorts
<TheMue> niemeyer: As today in Unit.WatchPorts
<niemeyer> Hmm
<niemeyer> Why do we watch ports for both units and machines
 * niemeyer reads
<TheMue> niemeyer: Today it's only in Unit.
<niemeyer> TheMue: I mean why the original code does that
<TheMue> niemeyer: Oh
<niemeyer> TheMue: Ah, of course
<niemeyer> TheMue: One is based on the other
<rog> niemeyer: do we want the machine agent to do the port opening and closing? it seems that it's currently the provisioning agent's job
<rog> niemeyer: hmm, i can see why we might not want that, as it currently requires ec2 creds
<niemeyer> rog: We do want that, but this is a refactoring step we should do when we're done with the port
<rog> niemeyer: ok, so PA to start with
<niemeyer> Yeah
 * TheMue looks how firewall is used today.
<hazmat> TheMue, only in the provisioning agent
<hazmat> TheMue, it doesn't really belong in the state package
<TheMue> hazmat: Yes, seen it.
<TheMue> Fresh cherry cake by my wife, bad for my diet. *sigh*
<rog> niemeyer: ping
<rog> TheMue: i want some, please
<niemeyer> rog: Heya
 * TheMue dcc's rog some cake.
<rog> niemeyer: just looking at starting the PA
<niemeyer> rog: Ok
<rog> niemeyer: there's a little awkwardness that i thought it might be worth discussing
<niemeyer> rog: Cool. Can we cover this after lunch?
<rog> niemeyer: ok
<niemeyer> It's food-o-time here
<rog> niemeyer: enjoy! ping me after lunch...
<niemeyer> rog: Thanks, will do
<niemeyer> rog: Yo, so what's up?
<rog> niemeyer: so...
<rog> niemeyer: we want the provisioning agent to know the machine address to give when starting new machines
<rog> niemeyer: so i thought we can easily use the metadata service to pass the address into the provisioning agent
<rog> niemeyer: same kind of thing we do with the machine agent
<rog> niemeyer: or initzk anyway
<rog> niemeyer: with instanceIdAccessor
<rog> niemeyer: i added hostNameAccessor
<niemeyer> rog: How is it done today?
<niemeyer> Aram: Just reviewed https://codereview.appspot.com/6304099
<Aram> thanks
<rog> niemeyer: good question. i should have looked. one mo
<niemeyer> rog: We should look how it is currently done, because this problem has been solved in a way that works for several providers
<niemeyer> rog: Maybe it's not optimal, but we should be sure we're improving on it if that are any changes to it
<niemeyer> s/that/there
<Aram> niemeyer: I did the change, can I just submit now?
<niemeyer> Aram: Yeah
<Aram> good
<niemeyer> Thanks! Woohay first mstate branch going in!
 * TheMue cheers
<Aram> TheMue: I think we'll share a flight  returning from the sprint.
<TheMue> Aram: Oh, good you mentioned it, I've got to change the wiki. BTS found a cheaper flight with KLM. So sorry, we do not share it. *sigh*
<hazmat> mramm, do you a percentage on travel arrangements ? ;-)
<Aram> hmm, maybe I should ask for different flights, I know there are more flights than BTS told me.
<mramm> hazmat: so far it's just pro-bono work
<TheMue> hazmat: Hehe, that question shocked him. ;)
<rog> niemeyer: ah! ok, problem solved. and dave's problem too.
<rog> niemeyer: i should've thought of it anyway
<niemeyer> rog: So what's the deal?
<rog> niemeyer: the PA calls StateInfo
<rog> niemeyer: easy peasy
<niemeyer> rog: Aha, ok
<niemeyer> rog, Aram, TheMue: Folks, I think now is a good moment to do the move lp.net/juju-core/juju => lp.net/juju-core
<niemeyer> Do you have any pending work that is about to be merged?
<TheMue> niemeyer: From my side +1.
 * rog looks
<Aram> +1.
<rog> niemeyer: no, that's fine
<niemeyer> I'll give Dave a hand and see if any of his branches are mergeable and submit them myself now
<niemeyer> fwereade will have to update, unfortunately
<niemeyer> But it's almost as low a hit as we can manage I think
<niemeyer> Running tests even for the dummy package is taking an awful lot of time.
<niemeyer> s/package/provider/
<rog> niemeyer: i have an idea about how we might be able to speed up the tests. the slowness is almost all caused by the zookeeper startup time
<niemeyer> There seems to be something wrong..
<rog> niemeyer: we could start one zk server on demand and use the zk chroot functionality so that it could be used across all tests in all packages.
<niemeyer> START: /home/niemeyer/src/launchpad.net/juju-core/juju/environs/jujutest/test.go:96: LiveTests.SetUpTest
<niemeyer> This is blocking
<niemeyer> Sorry, no, it's not
 * rog realises he's broken the build
<niemeyer> rog: ?
<rog> niemeyer: my recent container "fix"
<rog> niemeyer: i could've sworn i ran the test, but evidently i didn't
<niemeyer> rog: Hmm.. we'll probably need some kind of submission mechanism soon, hooked with lbox
<niemeyer> rog: Btw, this line:
<rog> niemeyer: i think lbox should probably run all the test on the merged branch before actually submitting it
<niemeyer>         err := t.Env.Bootstrap(true)
<niemeyer> rog: Is taking 36 seconds to execute
<niemeyer> rog: With the *dummy* env
<rog> niemeyer: i suspect zookeeper, but i may be wrong.
<niemeyer> rog: It may be zk.. we call state.Initialize there
 * niemeyer checks
<niemeyer> rog: PutTools
<rog> niemeyer: ah, it's taking ages to build the tools, i suppose
<rog> niemeyer: because nothing is installed
<rog> niemeyer: because you've just changed everything perhaps?
<niemeyer> Could be
 * niemeyer verifies
<niemeyer> % time go install launchpad.net/juju-core/juju/cmd/...
<niemeyer> go install launchpad.net/juju-core/juju/cmd/...  24.71s user 7.27s system 99% cpu 32.157 total
<niemeyer> rog: ^
<niemeyer> rog: Now, the question is why is it taking such a long time *every time*
<niemeyer> Clearly something is not ok
<rog> niemeyer: just using vanilla "go install" it always takes that long for you?
<niemeyer> rog: What's vanilla go install?
<rog> niemeyer: just go install on the command line, no other stuff going on like GOBIN etc
<rog> niemeyer: for me it takes 1.12s the second time i run it
<niemeyer> rog: Sorry, I still don't get it. The command above is go install on the command line.
<rog> niemeyer: right. and you ran it twice and got the same time each time.
<rog> niemeyer: i've no idea what's taking it so long there then
<niemeyer> go install -x isn't even printing results
<niemeyer> I'll rebuild my go tree
<niemeyer> % time go install -x launchpad.net/juju-core/juju/cmd/...
<niemeyer> WORK=/tmp/go-build238159301
<niemeyer> go install -x launchpad.net/juju-core/juju/cmd/...  24.93s user 7.07s system 99% cpu 32.182 total
<niemeyer> WTF.. it's taking 32 seconds before it even does anything
<rog> niemeyer: if go install -x isn't printing results, it means it's doing nothing, yeah.
<rog> system 99%
<rog> try a syscall trace perhaps
<niemeyer> I'll try rebuilding Go first, just to make sure I don't have something funky there
<rog> niemeyer: you get 32s before it even prints the WORK line?
<niemeyer> rog: Yeah
<niemeyer> rog: If I can reproduce with a rebuild I'll see where more exactly
<rog> niemeyer: at least this time, i think we can say the blame doesn't fall on the juju testing :-)
<niemeyer> rog: Yeah! :)
<rog> niemeyer: can i propose/submit a quick fix for the container brokenness before you proceed?
<niemeyer> rog: Hmm.. we could add a flag to lbox submit such as "--test-command"
<niemeyer> rog: Yeah, definitely
<rog> niemeyer: that sounds like a good plan
<niemeyer> rog: We can then have it in .lbox so we don't have to enter it every time
<rog> niemeyer: yeah. but it's important that the tests run on the merged version
<niemeyer> rog: Of course
<niemeyer> Still broken
<niemeyer> Let's see where this time is being spent
<niemeyer> Holy crap.. it's doing an awful lot of things
<niemeyer> I suspect someone added some logic without much consideration for what else is under $GOPATH/src/, as it's walking the whole tree :-(
<rog> niemeyer: maybe it's not so clever about prefixes of ... patterns
<rog> niemeyer: but walking the tree doesn't take long, surely?
<niemeyer> rog: Surely does
<niemeyer> rog: If the tree is large
<rog> % time find $GOPATH/src > /dev/null
<rog> 0.01user 0.04system 0:00.05elapsed 98PU (0avgtext+0avgdata 4880maxresident)k
<rog> not for me :-)
<rog> niemeyer: presumably it's not reading all the files in the tree?
<niemeyer> rog: Presumably it's spending 32 seconds doing that
<rog> niemeyer: how long does it take you to run that command?
<niemeyer> [niemeyer@gopher ~/src]% time find > /dev/null
<niemeyer> find > /dev/null  1.86s user 5.89s system 25% cpu 30.253 total
<rog> niemeyer: gosh. that is really really big. or you've got a slow disk/network drive.
<niemeyer> rog: I have a lot of stuff in my src/
<niemeyer> rog: and an SSD
<rog> niemeyer: ah! you have GOPATH=$HOME ?
<niemeyer> rog: Yep
 * rog is glad he didn't do that
<niemeyer> rog: Heh
<rog> niemeyer: the go tool should be more intelligent
<niemeyer> rog: It should be less stupid, rather
<niemeyer> Why on earth is it walking everything like that
<rog> niemeyer: because it's walking the directories then matching against the pattern
<rog> niemeyer: rather than walking the constant prefix of the pattern
<rog> niemeyer: at least that's my assumption
<niemeyer> rog: OMG, I hope you're wrong
<rog> niemeyer: yeah, that's exactly what it's doing
<niemeyer> It's like, "Oh you want everything under /home/joe? Okay! Let's start over in /var!"
<rog> 		filepath.Walk(src, func(path string, fi os.FileInfo, err error) error {
<rog> and src is everything
<rog> niemeyer: to be fair it was done quickly, and correctness is more important than quickness.
<rog> niemeyer: but it will be easy to fix.
<niemeyer> rog: Yeah, I'll fix that now
<rog> niemeyer: i'd make matchPattern return the longest path prefix as well as the match function
<niemeyer> rog: Doing this right is a no-brainer, to be honest.. it was just a brain fart from someone
<niemeyer> rog: Actually, they've done in right elsewhere there
<rog> niemeyer: really?
<niemeyer> rog: Yep.. see matchPackagesInFS
<rog> niemeyer: so it does.
<rog> niemeyer: i'm off for the evening. hope the switchover goes ok...
<rog> 'night al
<rog> l
<niemeyer> rog: Thanks, have you seen the LGTM?
<rog> niemeyer: just making sure with a final test, then i'll submit
<niemeyer> rog: Cheers
<rog> niemeyer: re: https://codereview.appspot.com/6304104/ i think we might have decided to go with a different, slightly simpler approach.
<rog> i get this sporadic failure:
<rog> FAIL: presence_test.go:328: PresenceSuite.TestWaitAlive
<rog> presence_test.go:348:
<rog>     c.Assert(err, IsNil)
<rog> ... value *errors.errorString = &errors.errorString{s:"presence: still not alive after timeout"} ("presence: still not alive after timeout")
<niemeyer> rog: The approach there looks pretty straightforward and clean to me
<rog> niemeyer: this was my suggestion to dave this morning: http://paste.ubuntu.com/1052155/
<niemeyer> rog: I mentioned it could stay simpler, but I also don't see an issue with doing it now, given Dave actually wrote it
<rog> niemeyer: which he seemed to quite like
<rog> niemeyer: in some similar form anyway
<niemeyer> rog: That sounds fine too
<rog> niemeyer: it means we can get rid of operationKinds, the string table etc
<rog> niemeyer: https://codereview.appspot.com/6332044 submitted. build fixed.
<niemeyer> rog: Thanks!
<niemeyer> rog: Can you please add a comment to the review then?
 * rog really is off now. see you tomorrow (my last day before i'm away for two weeks BTW)
<niemeyer> Nevermind.. copied the IRC conversation on the proposal
<rog> niemeyer: i added a comment
<rog> niemeyer: ah, but replied to the wrong email!
<rog> darn
<niemeyer> rog: np
<niemeyer> So, fixed go problem.. can actually test code in a non-ridiculous timeframe now
<niemeyer> juju-core/juju => juju-core move is complete!
<niemeyer> Please see juju-dev@ list for details.
 * niemeyer steps out
<andrewsmedina> niemeyer: :)
#juju-dev 2012-06-22
<rog> davecheney: mornin'
<davecheney> rog: 'sup!
<davecheney> just putting the final touches on the dummy change
<rog> davecheney: i looked at the python code yesterday and discovered that provisioner StateInfo problem has a trivial solution...
<davecheney> ohh do tell
<rog> davecheney: http://paste.ubuntu.com/1053800/
<davecheney> that'll wokr
<davecheney> work
<rog> davecheney: yeah. so obvious now that i know it...
<rog> davecheney: this my last day before going on hols for two weeks BTW, so if there's anything you wanna talk about...
<davecheney> rog: sorry, was in another screen
<davecheney> i tried to do a juju bootstrap today
<davecheney> it didn't work (not surprising)
<davecheney> what are the steps you think remain between now and having juju bootstrap working ?
<davecheney> opp, getting my hurry up call
<davecheney> rog, have a good holiday, i'll catch ya in a fortnight
<rog> davecheney: i'll try me very best :-)
<rog> davecheney: have fun in the meantime, and don't finish everything before i'm back - i don't wanna miss all the fun!
<rog> TheMue: hiya
<Aram> heyhey.
<rog> Aram: hiya
<TheMue> Hi Aram, hi rog
<Aram> TheMue: rog: does this look right to you? http://go.pkgdoc.org/launchpad.net/juju-core
<Aram> I wonder how can we force a refresh
<rog> Aram: it only shows subpackages if they've been requested
<Aram> I see.
<rog> Aram: try it now
<Aram> yeah, much better
<rog> Aram:  for(i in `{ls  | grep -v '\^.'}) {curl -s http://go.pkgdoc.org/launchpad.net/juju-core/$i > /dev/null &}
<rog> :-)
<Aram> hi niemeyer
<Aram> rog: even better, I did it recursively: http://go.pkgdoc.org/launchpad.net/juju-core
<Aram> to refresh everything.
<rog> Aram: good call
<rog> Aram: we need to add more package-level docs!
<niemeyer> Heya!
<rog> niemeyer: yo!
<Aram> niemeyer: I had the same experience booking my flight, I found a flight on the internet they didn't find, but after I told them about it surely they found it!
<niemeyer> Aram: We should bring that kind of stuff with management..
<niemeyer> The agency is of limited usefulness if they can't find flights unless we point out that they exist.
<TheMue> Aram: Hehe, my flight has been ok so far, but then KLM cancelled one of the flights. Now we look for an alternative.
<rog> niemeyer: here's a CL to look at if you fancy it: https://codereview.appspot.com/6336047
<rog> niemeyer: one more step towards getting the provisioner actually deployed
<rog> niemeyer: i'm very happy about the code move BTW
<niemeyer> rog: Sweet!
<rog> niemeyer: there's one thing i wasn't entirely sure about
<rog> niemeyer: how to handle the distinction between the original StateInfo (as passed on the command line) and the StateInfo as retrieved from the environment
<niemeyer> rog: Not sure I get the point
<niemeyer> rog: ACtually, I'm sure I don't :)
<rog> niemeyer: in the CL it always connects with the original StateInfo, but that might be dubious
<niemeyer> rog: Yeah, we'll want to improve that over time
<niemeyer> rog: But sounds fine for the moment
<rog> niemeyer: ok. i think that perhaps we'll eventually want to connect using the most-recently-retrieved info, but fall back to the original if that fails
<niemeyer> rog: If mstate works out, we should be saving the live servers every once in a while
<niemeyer> rog: Persistently, so that a restart sees all the servers it knew about
<rog> niemeyer: yeah, and if the PA can't get the correct info then everything is broken!
<rog> niemeyer: because clients won't be able to connect
<niemeyer> rog: Right
<rog> niemeyer: so maybe overwriting Provisioner.info is the right thing to do
<niemeyer> rog: Sorry, I lost the leap there
<niemeyer> rog: You mean replacing it every once in a while with state.StateInfo()?
<rog> niemeyer: yes
<niemeyer> rog: Ah, agreed
<rog> niemeyer: currently we store it in a different field
<rog> niemeyer: (and keep the original in origInfo)
<niemeyer> rog: Reviewed
<rog> niemeyer: thanks!
<niemeyer> rog: Currently or in the CL you're proposing?
<rog> niemeyer: in the CL i'm proposing
<niemeyer> Okay
<rog> niemeyer: the "check that instance is started" TODO is pending dave's changes to the dummy provider
<rog> niemeyer: which will make it easy to check.
<rog> niemeyer: i can't add the test without making conflicting similar changes to dummy
<niemeyer> rog: Okay, let's try to get these changes in now then
<rog> niemeyer: the dummy changes?
<niemeyer> rog: Yeah
<rog> niemeyer: i'm not sure it's ready. unless i missed a message.
<niemeyer> rog: It's up for review
<rog> niemeyer: hmm, i think i must be missing messages
<niemeyer> Hmm.. we left the genericOperation private..
<niemeyer> s/we/he
<rog> niemeyer: weird, i don't seem to have seen *any* of dave's proposal emails
<rog> niemeyer: i see your replies to them
<niemeyer> rog: https://codereview.appspot.com/6304104/
<niemeyer> I think it's good to go in, except for genericOperation
<rog> niemeyer: yeah, i've found it
<niemeyer> rog: But you can fix that in your branch easily
<rog> niemeyer: i don't know that genericOperation needs to be exported actually
<niemeyer> rog: Well, how one knows how to build the type otherwise?
<rog> ah, except that Env won't show up
<rog> yeah
<niemeyer> rog: I'll submit it to unblock you
<rog> niemeyer: that would be great, thanks
<niemeyer> rog: Branch is in
<rog> niemeyer: thanks a lot
<niemeyer> rog: np!
<rog> niemeyer: am just working on live tests for the PA BTW
<rog> niemeyer: crossed fingers for the end of the day
<niemeyer> rog: Wow, cool
<niemeyer> rog: Having it actually firing stuff up would make the week for sure
<rog> niemeyer: BTW it would be great to have that resilience stuff in aws. it really slows down testing when 80% of the really slow tests fail...
<niemeyer> rog: Yeah, I know
<niemeyer> rog: Sorry about that
<rog> niemeyer: 's'ok!
<rog> niemeyer: just a little nudge every now and again :-)
<niemeyer> rog: Hehe :)
<niemeyer> Okay, I'll get some lunch.. back soon
<rog> niemeyer: https://codereview.appspot.com/6336047 all done, i think. took a little more work than i thought, but i think the tests are better for it.
<niemeyer> rog: Looking
<niemeyer> rog: Done
<rog> niemeyer: lovely. thanks very much for doing it so quickly!
<niemeyer> rog: My pleasure
<rog> niemeyer: submitted
<rog> niemeyer: i've got a preliminary CL that starts the provisioning agent, but i haven't done the tests yet. https://codereview.appspot.com/6333056/
<rog> niemeyer: someone might want to take it on while i'm away
<niemeyer> rog: Sounds great, thanks a lot
<niemeyer> I'll have to step out for a while.. I'm in a bit of trouble here. Have to take some recurrent papers to the bank before the trip tomorrow and we're out of paper
<rog> niemeyer: oops. that reminds me - i must submit my expense!
<rog> s
<rog> niemeyer: ok, there's now one uncompleted test. it's running now... we'll see if it works!
<rog> darn, it failed.
<rog> oh well, it did actually start the PA, even if it didn't work!
<rog> right, i'm off to pack.
<rog> catch y'all in two weeks' time
<TheMue> rog: Where do you travel?
<rog> TheMue: to cornwall
<rog> TheMue: in the camper van
<rog> TheMue: should be good i hope!
<TheMue> rog: And with you bikes.
<rog> TheMue: oh yes
<rog> TheMue: hope you have a good two weeks
<TheMue> rog: *sigh* Sounds very good. Never been there, but I still want.
<TheMue> rog: We'll do our best.
<Aram> rog: have a great time!
<rog> TheMue: don't finish it all before i get back!
<rog> Aram: hope so!
<TheMue> rog: Out holidays on Ruegen will be in September.
<rog> fingers crossed for the weather
<rog> gotta go, i hear a voice from below!
<TheMue> rog: No, we'll leave the last line of code for you. ;)
<niemeyer> rog: Superb, thanks so much
<niemeyer> rog: and have a brilliant time there
<TheMue> niemeyer: One little CL: https://codereview.appspot.com/6332048. It's needed for the port of Firewall.
<niemeyer> TheMue: Looking
<TheMue> niemeyer: It's only the ExposedWatcher.
<TheMue> niemeyer: The firewall is only used in the PA. So I think the cmd package would be a good home for it.
<niemeyer> TheMue: Done
<TheMue> niemeyer: Ah, thx, will quickly change it.
<TheMue> niemeyer: Is in again.
<niemeyer> TheMue: Checking
<niemeyer> TheMue: Done
<TheMue> niemeyer: And once again in. ;)
<niemeyer> TheMue: Man.. :)
<niemeyer> TheMue: https://codereview.appspot.com/6332048/diff/8002/state/watcher_test.go
<niemeyer> TheMue: Well, nevermind.. it's actually alright there
<niemeyer> TheMue: I thought there were more references missing still
<niemeyer> TheMue: LGTM.. please just fix the CL description when submitting
<niemeyer> TheMue: Btw, the usual convention is
<niemeyer> prefix: summary with lowercase first letter
<niemeyer> TheMue: For that summary line
<niemeyer> TheMue: But that's minor
<TheMue> niemeyer: OK, will keep in mind.
<niemeyer> TheMue: Thanks!
<TheMue> So, time to leave. Have a nice weekend.
#juju-dev 2013-06-17
<mramm> snow!
<mramm> fortunately, that does not happen here in panama
<wallyworld_> thumper: so far, no feedback on my containers email. i might go ahead and implement the new assignment policies (but just do the new code, still retain the hard wiring to AssignNew)
<thumper> wallyworld_: yeah, sorry about that, I didn't even read it fully
<thumper> if you give me a few minutes, I'll do that, then we can chat?
<wallyworld_> it more more others i was hoping to hear from
 * thumper nods
<wallyworld_> ok
<wallyworld_> thumper: i reproposed the watchers branch too
<wallyworld_> it was a sad tale of things which didn't work
<thumper> :)
<thumper> wallyworld_: https://plus.google.com/hangouts/_/c13964bb956b545d4b70115743cd124bebf19c19?hl=en
 * thumper considers lunch
<thumper> hi davecheney
<thumper> davecheney: good holiday
<thumper> ?
<davecheney> thumper: yessir!
 * thumper rages a little
<thumper> wallyworld_, davecheney: I just want to write a test that assumes that I have some environment running...
<jam> thumper: did davecheney take you away from lunch?
<jam> (reading the backlog)
<thumper> jam: nah, made myself pizza
<jam> I thought that might be why you were raging.
<thumper> followed up with a nice flat white and home made ginger kisses
<thumper> lit a fire earlier
<thumper> no...
 * thumper sighs
<jam> sounds pretty good
<thumper> just testing blues
 * thumper feels like this test should be easier to write
<thumper> hmm...
<jam> wallyworld_: so after a bit more digging, it turns out we can't "just wait longer". The issue is that when it happens, the new Connected socket will never get Close called on it, because it missed the server.Close call
<jam> thumper: JujuConnSuite has lots of stuff set up for you :) (though I'm told it has too much and we should avoid it)
<thumper> jam: yeah, I'm avoiding it :)
<thumper> wondering whether to actually bootstrap my dummy environment
<jam> thumper: and congrats on most of your patches just landing without needing to be resubmitted due to the connection timing bug.
<thumper> or just fake the state and api info
<thumper> jam: didn't hit the connecting timing bug
<jam> thumper: TBH I'd probably go with bootstrap a dummy enviroment.
<thumper> but did hit some spurious test failures a couple of times
 * thumper bootstraps
<jam> thumper: that is the connection timing bug
<thumper> oh...
<thumper> I did hit it a few times
<jam> more of your patches have landed without failing than anyone elses.
<jam> even if you have hit it.
<jam> I've tracked it down to a race condition inside mgo.
<jam> It is starting a new connection when Close is called.
<jam> so the new conn routine is blocked in a conn request, and hasn't registered the new conn with the list of liveconns
<jam> server 'closes' all of its conns,
<jam> routine comes back and adds one more.
<jam> thumper: anyway, just checking email before taking my son to school, good luck, and hopefully I'll have a patch for the conn thing early today.
<thumper> awesome
 * thumper sighs...
 * thumper works out what is needed for a valid cloudinit
<thumper> anyone know off the top of their head how to get the tools from environs that were used to bootstrap?
<thumper> using: 	err = environs.Bootstrap(environ, constraints.Value{})
<thumper> with a dummy environment
 * thumper goes to collect the girls
<wallyworld_> jam: i was wondering about that
<wallyworld_> hence maybe a mutex is needed
<wallyworld_> thumper: want to bikeshed a name for the method on instance.Instance which returns the "characteristics". i'm thinking just Metadata()
<thumper> wallyworld_: you mean, cores, power, memory etc?
<wallyworld_> yeah
<wallyworld_> Characteristics() doesn't do it for me
<thumper> hmm...
<thumper> Metadata works for me
<wallyworld_> cool
<wallyworld_> jam: did you get the meeting invite for later today?
<arosales> wallyworld_, I do and I accepted it :-)
<wallyworld_> arosales: thanks, the acceptance hasn't come up in my calendar event
<wallyworld_> but it did insist on a gapps.canonical email address
<wallyworld_> maybe that confused it
<arosales> wallyworld_, hrm. well I indeed did accept and will be there @ 23:00 UTC
<arosales> tomorrow for me
<wallyworld_> arosales: thank you, just wanted to doule chec
<thumper> wallyworld_: the way you were talking it was 11pm for you
<thumper> not 11pm utc
<arosales> sure np
<bigjools> wallyworld_: do you use simplestreams to manage images for openstack?
<wallyworld_> thumper: it is 11pm for me
 * thumper keeps out of it
<wallyworld_> arosales: the meeting is 11pm GMT+10, or is supposed to be. so should be morning for you
<arosales> wallyworld_, that is the juju api discussion, right?
<wallyworld_> arosales: no, the simplestreams stuff
<arosales> oh
<arosales> good thing you confirmed :-)
<wallyworld_> yeah :-)
<arosales> accepted that one as well
<wallyworld_> thanks!
<arosales> thank you for setting it up and confirming :-)
<wallyworld_> arosales: so to check the time, it is 11pm for me and maybe 8 or 9am for you
<wallyworld_> np
<wallyworld_> i think i made it after the api one, not sure now
<wallyworld_> bigjools: yes, there are simplestreams metadata files which list the available images
<wallyworld_> juju uses these t figure out the image id to ask for when telling openstack/ec2 to start an image
<wallyworld_> instance i mean
<bigjools> wallyworld_: I am wondering if that stuff will work with the provider we're working on
<bigjools> I guess time will tell
<thumper> wallyworld_: please don't add extra import dependencies to the instance package
<thumper> wallyworld_: I'm trying to remove them all
<wallyworld_> bigjools: it might work so long as your provider can have the concept of a caller passing in an image id and there's some sort of lookup the provider does to then figure out what image to start
<wallyworld_> thumper: i don't plan on it
<thumper> coolio
<bigjools> wallyworld_: I don't know if this provider allows custom images yet
<wallyworld_> bigjools: they don't have to be custom - juju just wants to be able to say "give me an instance for amd64/precise". there's a mapping in simplestreams from those constraints to an image id. so the provider just has to do the right thing when given an image id
<bigjools> wallyworld_: if the constraints contain the amd64/precise info we can just ignore the image id, right?
 * thumper afk for kid sports and shopping, back later tonight to talk to fwereade
<bigjools> oh we can do custom images
<wallyworld_> bigjools: yes, the provider can ignore the simplestreams stuff if it wants and just look at the constraints
<wallyworld_> fwereade: if you are around, i'd love a quick catchup
<fwereade> thumper-afk, wallyworld: sorry, I'm going to a school thing for laura for at least a couple of hours -- you're best off emailing me, I think
<rogpeppe> mornin' all
<jam> wallyworld_: yay, you're back
<wallyworld_> jam: sorry, power was cut
<jam> wallyworld_: I was pretty sure you're just hiding from your 1:1 :)
<jam> rogpeppe: I'm just poking at tarmac right now to make the test suite more reliable (bug #1191487). So I'm going to bump your proposal while I'm testing it, and then I'll set it back to Approved when I'm done.
<_mup_> Bug #1191487: mgo sockets in a dirty state <tarmac> <test> <juju-core:Triaged by jameinel> <mgo:Confirmed> <https://launchpad.net/bugs/1191487>
<rogpeppe> jam: what do you mean by "bump"?
<rogpeppe> jam: put on hold?
<jam> rogpeppe: I'm going to stop the test suite running, which will probably mark your proposal as Needs Review with a test suite failure.
<jam> so ignore that failure
<rogpeppe> jam: ok. darn. i thought i was early enough to get it merged.
<rogpeppe> jam: thanks for letting me know
<jam> rogpeppe: well, you had a 75% chance that it would have failed anyway because of bug #1191487
<_mup_> Bug #1191487: mgo sockets in a dirty state <tarmac> <test> <juju-core:Triaged by jameinel> <mgo:Confirmed> <https://launchpad.net/bugs/1191487>
<jam> that test has been *very* unreliable on the tarmac machine
<rogpeppe> jam: i, i saw that this morning and thought it was because i was running against go tip
<rogpeppe> s/i/ah/
<jam> rogpeppe: nope, I have a whole bunch of stuff that sorts out *why* it is happening. Ends up as a race condition in Close that can leave a new connection Alive but abandoned
<rogpeppe> jam: i can't believe how slow the cmd/juju tests have become. 3 minutes makes it the slowest of all.
<rogpeppe> jam: cool. i wasn't looking forward to diving into that stuff again.
<rogpeppe> jam: what was the basic problem?
<jam> rogpeppe: we have a lock on the server object, we release it during Connect
<jam> when we return we grab the lock again and add the connection to active connections
<jam> but Close() can be called while connect is waiting
<jam> and then we get an object that will never have Closed called on it.
<rogpeppe> jam: which server object?
<jam> rogpeppe: all of this is in mgo
<rogpeppe> jam: ah!
<jam> rogpeppe: details are in the bug now
<rogpeppe> jam: that's a great bug to have found, thanks!
<jam> rogpeppe: I requeued your patch with a local fix for mgo
<rogpeppe> jam: thanks a lot
<jam> rogpeppe: If you want to review my changes on the bug, I'd love to get someone else to see if it is a reasonable patch to land in mgo trunk
<rogpeppe> jam: i'll take a look
 * jam makes a run to the grocery store
<rogpeppe> jam: it's funny that the trigger for the problem is that a single test takes more than 10 seconds...
<rogpeppe> jam: i'm pretty sure that the second of your suggested patches (make AcquireSocket return an error if the server is closed) is the correct one
<rogpeppe> jam: and would it be that much more invasive, given that AcquireSocket already returns an error?
<TheMue> morning
<thumper> TheMue: morning
<thumper> TheMue: I decided to continue using golxc because it was nice and self-contained
<thumper> TheMue: didn't seem like any value copying that code into juju-core
<thumper> TheMue: can you merge my branch into trunk?
<thumper> TheMue: also... do you want to change the owner of the trunk branch?
<thumper> TheMue: we could get jam to add it to the go-bot maybe
<TheMue> thumper: shouldn't be a problem, only have to look how to do it
<TheMue> thumper: never played that much with lp
<thumper> TheMue: well, to merge it in, do the following
<jam> thumper: it must pass my extensive review process :)
<thumper> TheMue: go to your version of trunk
<thumper> TheMue: follow the instructions from the merge proposal - bzr merge lp:~thumper/golxc/my-branch-name-that-I-cant-remember
<thumper> bzr commit --author="Tim Penhey <tim.penhey@canonical.com>" -m "Add mocking ability"
<thumper> bzr push
<thumper> and you're done
<thumper> to change the owner of the branch
<thumper> there is an edit link on the top right menu collection for the branch page
<thumper> there the owner of the branch is shown as a select box
<thumper> with all the teams you are a member of
<TheMue> thumper: fine, but your really named it "my-branch-name-that-I-cant-remember"? *scnr*
<jam> rogpeppe: so if you return an error, by default the loop will go back into 'sleep for 10s' mode rather than exiting because the server has closed.
<thumper> you could change it to juju-core now, and we could change it again to go-bot later
<jam> it turns out that may not get *noticed* because the socket has already been marked closed (even though there are active goroutines running)
<TheMue> thumper: ok, will do. nice to see this young lady growing
<thumper> :)
<thumper> TheMue: I have another branch to add shortly
<thumper> TheMue: which changes the wait conditions based on new-learning
<thumper> TheMue: but not today :)
<TheMue> thumper: yeah, your today is almost done while mine has just started
<thumper> almost?
<thumper> it is 8:20pm...
<thumper> game of thrones starts in like 10 minutes
<jam> rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725
<jam> you have a go-1.1ism in the code.
<rogpeppe> jam: oops
<rogpeppe> jam: where can i see the compiler failure in that merge proposal?
<rogpeppe> jam: oh, i see
<jam> rogpeppe: https://code.launchpad.net/~rogpeppe/juju-core/317-rpc-dynamic-serve/+merge/169725/comments/377524
<jam> # launchpad.net/juju-core/rpc_test
<jam> rpc/rpc_test.go:168: function ends without a return statement
<jam> FAIL	launchpad.net/juju-core/rpc [build failed]
<TheMue> thumper: almost in the sense of "you're still here"
<rogpeppe> jam: yeah, i just saw it
<thumper> TheMue: heh, just back, not still here :)
<TheMue> thumper: enjoy GoT
<jam> thumper, TheMue: if you want me to manage the golxc trunk with tarmac, it should be pretty easy to set up, but obviously you need to make sure you have a passing test suite, etc first
<rogpeppe> jam: yes, the pinger loop would have to check for errServerClosed or whatever
<rogpeppe> jam: but i think that explicitness would make the code more obvious
<rogpeppe> jam: it seems wrong to me to return a socket that we know is bad
<rogpeppe> i've just discovered that it's only the graphics freezing up when my computer crashes - i can still ssh in
<rogpeppe> i wonder if there's a way to reboot all the graphics while leaving everything else running
<thumper> jam: the test suite passes, however, as it is lxc, part of the test suite requires sudo
<thumper> jam: but running that in a clean environment *shouldn't* be too hard, right?
<thumper> jam: expecting mgz?
<jam> thumper: define "clean environment" :)
<jam> the bot doesn't currently have sudo rights, though it could be adde
<jam> added
<thumper> jam: something where you can run the tests with sudo and not feel violated :)
<jam> thumper: running tests with sudo... not sure I can avoid violation :)
<thumper> jam: perhaps we should create an lxc container to run the tests in
<jam> thumper: I would expect mgz to show up some time soon.
<thumper> but that needs sudo too
<thumper> hmm, may just email
<thumper> night all
<jam> thumper: I don't feel too bad about giving the bot sudo over just this stuff.
<jam> rogpeppe1: so the issue go bot just brought up is that it had not refreshed the MP page when you marked it approved (you Approved it before you pushed)
<jam> you can just go back and approve it again.
<rogpeppe1> jam: heh
<rogpeppe1> jam: so i can't just push then approove
<rogpeppe1> approve
<jam> you should be able to push, then refresh the page, then approve.
<jam> The diff doesn't have to finish updating, LP just needs to notice there are new revisions.
<rogpeppe1> jam: ah, it's a client-side issue?
<jam> rogpeppe1: when you load the page, it tracks the revision that you approve.
<rogpeppe1> jam: ah
<rogpeppe1> jam: thanks
<jam> so that you don't approve X, then someone pushes something completely different, and that lands.
<jam> it makes more sense when you are landing stuff proposed by 3rd parties.
<rogpeppe1> once more into the breach
<rogpeppe1> "The application Startup Disk Creator has closed unexpectedly".
<rogpeppe1> sigh
<TheMue> anyone able to show me where in LP i can change the ownership of a trunk?
<jam> TheMue: you go to the branch, and then change owner.
<jam> rogpeppe1: on the plus side, your patch landed :)
<rogpeppe1> jam: that's good
<rogpeppe1> jam: i'm currently working towards reinstalling from scratch on my laptop
<rogpeppe1> jam: hoping that it'll fix my increasingly frequent freeze-ups
<rogpeppe1> jam: i'm bringing up my old mac up as a backup in case the laptop really is hosed.
<TheMue> jam: exactly that is the question: where there? i only see "change details" and there's no owner on the following page.
 * TheMue always like the LP usability
<jam> TheMue: if I go to a branch I own, such as: https://code.launchpad.net/~jameinel/bzr/2.4-client-reconnect-819604/ there is a Change Details link in the upper right, which takes you to .../+edit
<jam> which you can then select a dropdown to set the owner.
<jam> TheMue: are you the owner of the current branch?
<jam> you can point me to the branch, and I'll help as I can
<TheMue> jam: yes, I am
<TheMue> jam: but let me check something, I changed my lp profile after registering this project
<TheMue> jam: ah, my profile says I don't own or drive any projects
<rogpeppe1> aargh, dynamic libraries
<TheMue> jam: strange, take a look at https://launchpad.net/golxc
<rogpeppe1> Fatal Python error: pycurl: libcurl link-time version is older than compile-time version
<jam> TheMue: so on this page: https://code.launchpad.net/~themue/golxc/trunk
<jam> there should be a Change Details lnk
<jam> which you can use to change the owner
<jam> if it isn't there
<TheMue> jam: oh, there it is, so i navigated a wrong way (also with a Change details link)
<TheMue> jam: i'll change the ownership to "juju hackers" first. the current testing needs to run a script as root and then only does live testing. the test suite needs mocks for the lxc commands.
<jam> mgz, wallyworld, danilos_: coming to join me? https://plus.google.com/hangouts/_/8868e66b07fa02bdc903be4601200d470dae9ee3
<wallyworld> i was on the one in the calendar
<mgz> I;m there
<fwereade> wallyworld, sorry I wasn't around earlier -- you might like to take a quick look at lp:~fwereade/juju-core/watch-containers-alternative, which does what I originally suggested; at first glance, though, your LifecycleWatcher changes look good and are worth landing regardless
 * wallyworld looks
<fwereade> wallyworld, I copied your test but the rest is soppy+ untested, and hasn't had the UnitsWatchername replaced
<wallyworld> fwereade: i made a generic collection watcher but backed out the changes
<fwereade> wallyworld, if I read you correctly, the problem was just that you were watching the wrong document to get notified of containers-changed
<fwereade> wallyworld, hmm, if I were to press ahead with that I'd need a test for what happens if we upgrade from pre-containers-docs code
<fwereade> wallyworld, should probably have those anyway in general
<wallyworld> fwereade: the way i read the units watcher code, and my reworking to a generic watcher of collections, was that the collection being watched had to be an attribute of the parent entity's doc, but seems like that's not the case
<fwereade> wallyworld, I think that was just a coincidental feature of the existing ones
<wallyworld> right, so it seems. the watcher stuff i found hard to follow, and there's so much almost duplicated code. all those loops that do the same thing. there's got to be a way to consolidate all that
<wallyworld> i think we don't use interfaces enough in our Go code
<wallyworld> we use structs all the time, so hard to generisise stuff
<fwereade> wallyworld, agreed in general
<fwereade> wallyworld, I think there is definitely fertile ground for more consolidation there
<wallyworld> fwereade: so my reworking of units watcher seems similar to yours at first glance (from memory and all that). i also introduced a new interface with a Changes() method like you did. but my current code also works. what's your preference for moving forward?
<fwereade> wallyworld, at least all the ids are the same type ;p
<fwereade> wallyworld, keep going with what you have
<wallyworld> ok, will land that then
<wallyworld> fwereade: i wish we had aliased the core entity id type
<fwereade> wallyworld, I'll review it properly later today, and would expect you to land it tonight; I'll fix UnitsWatcher independently and switch the implementation when it's ready
<wallyworld> ok, sounds like a plan
 * fwereade is hungry, goes looking for lunch
 * wallyworld is thirsty for a beer but has a meeting soon :-(
<wallyworld> arosales: you ok for meeting now?
<TheMue> fwereade: ping
<fwereade> TheMue, heyhey
<TheMue> fwereade: heya
<fwereade> TheMue, rog was ofc quite right to point out that the Resumer could be better tested
<TheMue> fwereade: the pure http access to the store is really pretty simple, I've tested it with real world data (our tool url)
<fwereade> TheMue, oh! fantastic
<rvba> Hi guys, could you please have a look at https://code.launchpad.net/~rvb/juju-core/az-config-items2/+merge/169759 / https://codereview.appspot.com/10338043/ when you get a chance?
<TheMue> fwereade: now I want to change the synctools test. as this access to the tools is used only there, is it ok to try to keep the testbed as small as possible
<TheMue> fwereade: today we use a faked environment and the tool are uploaded for test UploadFakeTolsVersion()
<fwereade> rvba, ack
<rvba> ta
<TheMue> fwereade: I would create a small server, delivering the correct data here as I don't have to provide full storage functionality (e.g. put tools).
<fwereade> TheMue, if that's simplest, go for it
<TheMue> fwereade: fine
<TheMue> fwereade: and regarding the resumer I'll see how I can evaluate that it's running each minute
<fwereade> TheMue, left a couple of comments on https://codereview.appspot.com/10266043/
<TheMue> fwereade: nice idea with the interface +1
<jam> niemeyer: I'm trying to do a patch to mgo, but I'm unable to get the suite to pass. I assume you run 'make startdb' in one window and then 'go test' in another. But mid way through startdb fails with "addUser succeded, but cannot wait for replication since we no longer have auth".
<jam> Any idea?
<niemeyer> jam: "make startdb" returns after it's done
<niemeyer> jam: So you shouldn't run them in parallel
<jam> niemeyer: ah, k
<jam> it just runs for a long time
<niemeyer> jam: Right.. and that's why it's setup like that
<jam> I thought it ran something that the test suite connected to.
<niemeyer> jam: You run it once, and then do as many runs as you want
<jam> k, thanks
<niemeyer> jam: You probably want to use go test -fast -gocheck.v
<niemeyer> jam: To get a feeling if your change is okay
<niemeyer> jam: There are tests that put databases down and wait for them to resync, etc
<niemeyer> jam: Which really take a while to get run
<niemeyer> jam: I usually run these only after I'm comfortable with the change
<jam> niemeyer: also, 'go fmt' reports lots of files to change. Shall I just submit that one first?
<niemeyer> jam: Ouch.. I have to add something to prevent commits without fmt
<niemeyer> jam: Please pull it
<jam> will do
<TheMue> fwereade: hangout?
<fwereade> TheMue, oo thanks sorry
<TheMue> mramm: hangout
<mramm> sorry, lost track of time
<fwereade> rvba, reviewed; I'm just in a meeting, but ping me in 20 mins if you'd like a quick chat about it
<jam> danilos_: you marked your proposal Approved, but forgot to set the commit message (which is why it wasn't trying to land)
<rogpeppe1> fwereade: am just doing the state/api/machineagent tests. they have lots in common with the machiner tests. three possibilities: 1) merge machiner into machineagent (rationale: all the APIs for a given agent live in the same package); 2) factor out the testing code into a new testing package (possible name state/apiserver/machineagent/testing); 3) duplicate the testing infrastructure.
<FunnyLookinHat> Ok guys - do any of you know if there's a way to dump the requests being made with juju-core?  I _really_ need to see what the distance is between JuJu and Rackspace... they're bought in to getting things working, but they need debug information to explain the 411 Content Length errors keeping me from auth'ing
<fwereade> rogpeppe1, I would favour (2) if that works for you
<rogpeppe1> fwereade: i'm slightly reluctant to go for 2, which i suspect is your preferred approach, as our packages are breeding like rabbits
<FunnyLookinHat> I'm not seeing any issues with what's in goose - everything seems to be correct..... but that's why I need to debug the requests :)
<fwereade> FunnyLookinHat, I'm not a goose expert, but I think there's a debug switch somewhere in there, isn't there? mgz/jam?
<rogpeppe1> our --debug switch should really turn on request logging in goose actually
<fwereade> rogpeppe1, agreed
<rogpeppe1> universal use of loggo (and judicious changing of command-line options) should make this story better
<fwereade> rogpeppe1, +1
<rogpeppe1> fwereade: is there a particular reason it's not a good idea to put the machiner and machine agent APIs together in the same package?
<fwereade> rogpeppe1, it feels a bit like the wrong granularity... I think the association of workers with particular agent types is generally speaking coincidental rather than fundamental
<fwereade> FunnyLookinHat, ah! it looks as though you can pass a logger in place of the nil in environs/openstack/provider.go:460
<rogpeppe1> fwereade: the testing seems to me to be oriented around the currently logged in entity. if we moved a worker from one agent to another, we'd not be able to share the testing infrastructure any more and we'd have to change a fair amount of the code. that seems to me to be a reasonable rationale for keeping them together. moving them will probably be no harder if they're in separate packages than if they're together in one.
<rogpeppe1> fwereade: "moving them will probably be no harder if they're in one package than if they're in separate packages" of course
<fwereade> FunnyLookinHat, and you *might* be able to pass in `loggo.GetLogger("goose")`
<fwereade> FunnyLookinHat, you can import "launchpad.net/loggo" at the top of the file
<FunnyLookinHat> fwereade, Ah ok - let me fork and try a build to see if manually patching would be easy for testing :)
<fwereade> FunnyLookinHat, but I have not used loggo in anger yet and don't quite remember for sure
<fwereade> FunnyLookinHat, so long as you --upload-tools for now, it should be fine
<FunnyLookinHat> fwereade, well that helps anyways - thanks for the direction... pretty sure we're on the goal-line for Rackspace support.
<FunnyLookinHat> --upload-tools ?
 * FunnyLookinHat is completely new to building juju
<fwereade> FunnyLookinHat, if you have source available in your GOPATH, it builds and uploads it, rather than trying to bootstrap with released tools
<fwereade> FunnyLookinHat, we messed up and trunk is incompatible with the bootstrap tools at the moment; I'm on it
<FunnyLookinHat> ah
<rogpeppe1> fwereade: if there's already a bootstrapped environment, it shouldn't matter, should it?
<rogpeppe1> fwereade: FunnyLookinHat could just build the local tools and use them against the existing environment, with logging turned on
<fwereade> rogpeppe1, (btw: ok, that seems fair)
<FunnyLookinHat> I don't have ANY existing environment... so there's nothing to save there
<FunnyLookinHat> well , nothing worth saving I mean.
<fwereade> rogpeppe1, maybe, but even then, at some stage he'd try an env-set and everything would be borken ;p
<FunnyLookinHat> heh
<rogpeppe1> FunnyLookinHat: don't do that :-)
<FunnyLookinHat> rogpeppe1, don't do what? build it?
<rogpeppe1> FunnyLookinHat: use env-set (when you've built the tools locally but haven't used --upload-tools)
<rogpeppe1> mramm: your link to the security bug didn't take me anywhere
<rogpeppe1> mramm: what issue are you referring to?
<rogpeppe1> mramm: if it's the "hard coded salt" issue, this is absolutely not critical
<fwereade> rogpeppe1, you may not be logged in ;p
<rogpeppe1> fwereade: i'm logged in
<fwereade> ah, ok, sorry
 * fwereade goes off to supper
<mramm> how is it not critical?
<rogpeppe1> mramm: my original design used a random salt, but gustavo persuaded me that it's not necessary. and i think he's probably right too.
<mramm> ok
<mramm> persuade me
<rogpeppe1> mramm: what is the security vulnerability here?
<mramm> and add a copy
<mramm> so, what does salt do for you in general?
<mramm> it makes it so that the password itself is not the only data that goes into creating the hash
<niemeyer_> rogpeppe1: I don't think I ever said anything like that
<rogpeppe1> mramm: if someone gets hold of the hashed password, it makes a rainbow-table attack harder
<niemeyer_> Oct 05 14:49:34 <niemeyer>      rogpeppe: Why the big salt?
<niemeyer_> Oct 05 14:49:43 <rogpeppe>      niemeyer: why not?
<niemeyer_> Oct 05 14:49:47 <niemeyer>      rogpeppe: Because two bytes should be enough
<niemeyer_> Oct 05 14:50:03 <rogpeppe>      niemeyer: ok, i'll use a smaller slat
<niemeyer_> Oct 05 14:50:05 <rogpeppe>      salt
<rogpeppe1> niemeyer_: i think it was later than that that you persuaded me a fixed salt would be fine
 * rogpeppe1 goes to look in the loges
<rogpeppe1> logs
<mramm> ok, if you know the salt you have a leg up on all kinds of attacks (common password hash searches become trivial, for example)
<rogpeppe1> [Friday 05 October 2012] [16:16:27] <rogpeppe>	niemeyer: alternatively
<rogpeppe1> [Friday 05 October 2012] [16:16:45] <rogpeppe>	niemeyer: we could not use a salted password at all and just say "use a long random password"
<rogpeppe1> [Friday 05 October 2012] [16:17:20] <niemeyer>	rogpeppe: Just use a well known salt for now
<rogpeppe1> [Friday 05 October 2012] [16:17:28] <rogpeppe>	niemeyer: what's the point?
<rogpeppe1> [Friday 05 October 2012] [16:17:58] <rogpeppe>	niemeyer: well, i guess we can add salt later :-)
<rogpeppe1> [Friday 05 October 2012] [16:18:19] <rogpeppe>	niemeyer: the changes are fairly small actually
<rogpeppe1> [Friday 05 October 2012] [16:18:30] <niemeyer>	rogpeppe: The point is the same of having a salt
<rogpeppe1> [Friday 05 October 2012] [16:18:58] <niemeyer>	rogpeppe: You can't attack a juju environment with a pre-made dictionary unless that dictionary was built specifically to attack a juju environment
<rogpeppe1> [Friday 05 October 2012] [16:18:59] <rogpeppe>	niemeyer: there's no point in having a constant salt - it's equivalent to having no salt at all
<rogpeppe1> [Friday 05 October 2012] [16:19:08] <rogpeppe>	niemeyer: i guess so
<rogpeppe1> [Friday 05 October 2012] [16:19:14] <niemeyer>	rogpeppe: No, it's not equivalent
<rogpeppe1> [Friday 05 October 2012] [16:19:19] <rogpeppe>	niemeyer: yeah, i see your point
<rogpeppe1> [Friday 05 October 2012] [16:19:24] <niemeyer>	rogpeppe: If you use a salt, you force people to start building that dictionary today
<rogpeppe1> [Friday 05 October 2012] [16:19:48] <rogpeppe>	niemeyer: ok, constant salt it is
<rogpeppe1> [Friday 05 October 2012] [16:20:09] <niemeyer>	rogpeppe: If you use an algorithm that takes 1 second to compute the hash on a modern computer, even a short password will take many years to break
<niemeyer_> rogpeppe1: Well, yes?
<niemeyer_> rogpeppe1: So the idea is to *have* a salt, plus using costly hashing
<niemeyer_> rogpeppe1: ?
<rogpeppe1> niemeyer_: so do you think that the fact that we're using a constant salt today deserves to be designated a critical bug?
<mramm> http://stackoverflow.com/questions/9195692/does-salt-need-to-be-random-to-secure-a-password-hash
<niemeyer_> rogpeppe1: So the idea is to *have* a salt, plus using costly hashing?
<rogpeppe1> niemeyer_: a random salt? or a well-known salt?
<niemeyer_> mramm: You don't need to convince me that salting is important.. that's why I've raised a flag given the blank statement I've heard from Roger
<mramm> right
<mramm> I was trying to convince roger ;)
<mramm> ideally we'd have random salt for each password, not for the whole environment
<rogpeppe1> niemeyer_: so you now think it's wrong to use a well known salt?
<rogpeppe1> mramm: i agree. that's what i did originally.
<niemeyer_> rogpeppe1: I think it has security implications for sure, and I believe you know that
<niemeyer_> rogpeppe1: The question is the size of the trade off
<niemeyer_> rogpeppe1: How long does it take to compute 100.000 hashes? More than the time the software is out? Then yes, it's an issue
<niemeyer_> s/more/less
<mramm> well, there is also the "users use the same password" issue
<mramm> which if all of the salt is the same, makes it easy to just find matching salt
<mramm> I mean matching hashes
<niemeyer_> mramm: I don't think you need to explain how salt works, or why salting is important
<mramm> sure
<niemeyer_> rogpeppe1: The question is purely one of trade off
<niemeyer_> SOrry
<niemeyer_> mramm: The question is purely one of trade off
<rogpeppe1> niemeyer_: what's the trade off?
<niemeyer_> rogpeppe1: Do you want a more resilient system today, or do you want to implement X?
<rogpeppe1> niemeyer_: ?
<rogpeppe1> niemeyer_: resilient to what?
<niemeyer_> rogpeppe1: Okay, maybe you do not understand salting!?
<niemeyer_> rogpeppe1: The only reason I suggested postponing the random salting is so you could get stuff done.
<mramm> resilient vs password attack
<rogpeppe1> niemeyer_: ah, good point; i've just reminded myself.
<rogpeppe1> mramm: it's a good point actually - where do we store the salt?
<mramm> you can store it in mongo
<rogpeppe1> mramm: how?
<rogpeppe1> mramm: hmm, actually, maybe...
 * rogpeppe1 thinks
<mramm> happy to talk about the how if you want
<FunnyLookinHat> Ok - say I just added logs to environs/openstack/provider.go - how do I build that to use it locally?
<rogpeppe1> mramm: i don't think we can do it until we have API everywhere
<FunnyLookinHat> oh never mind - found doc
<niemeyer_> Lunch time.. biab
<FunnyLookinHat> Err - $ go install      can't load package: package .: no Go source files in /home/funnylookinhat/source/juju-core
<FunnyLookinHat> Ah - will just use go to grab source and deps
<FunnyLookinHat> Ah geez - it looks like I can't import "log" because it's redeclared in the package?
<FunnyLookinHat> fwereade, having trouble figuring out the syntax since juju-core has it's own "Log" package...  any suggestions?  I just want the most simple dump possible
 * rogpeppe1 has reached end of day
<rogpeppe1> FunnyLookinHat: i'd just put some fmt.Printf statements inside goose
<rogpeppe1> FunnyLookinHat: you don't necessarily need to use the log package
<FunnyLookinHat> rogpeppe1, Yeah that's what I'm trying... having trouble tracing where specific requests are made
<FunnyLookinHat> And I'm randomly adding Content-Length 0 headers to requests to find out which one it is :D
<rogpeppe1> FunnyLookinHat: do you need to see just the requests, or the replies as well?
<FunnyLookinHat> rogpeppe1, Just requests right now
<FunnyLookinHat> nearly there I think...
<rogpeppe1> FunnyLookinHat: looks like sendRateLimitedRequest is the place
<rogpeppe1> FunnyLookinHat: just before resp, err = c.Do(req)
<FunnyLookinHat> rogpeppe1, which file ?
<FunnyLookinHat> oh client.go
<rogpeppe1> FunnyLookinHat: yeah
<rogpeppe1> FunnyLookinHat: something like this might do the trick:
<rogpeppe1> fmt.Printf("%s %s; headers: %+v\n", method, URL, req.Header)
<rogpeppe1> FunnyLookinHat: i have to go. good luck! ping me tomorrow if you're still having issues.
<FunnyLookinHat> rogpeppe1, That helps a lot actually - thanks for the help
<FunnyLookinHat> Just getting used to syntax mostly  :)
<rogpeppe1> FunnyLookinHat: it's always a steep learning curve
<rogpeppe1> FunnyLookinHat: ttfn
<FunnyLookinHat> Well crap.  It looks like the core go library isn't sending a Content-Length header
<FunnyLookinHat> But - as luck would have it - it also prevents you from adding one because it wants to do it itself.
<FunnyLookinHat> Or something...  but as far as I can tell, either Goose or Go isn't working as it should.
<FunnyLookinHat> Seems to be the same issue though: https://bugs.launchpad.net/goose/+bug/1124561
<_mup_> Bug #1124561: the Content-Length header is missing <Go OpenStack Exchange:Invalid> <https://launchpad.net/bugs/1124561>
<FunnyLookinHat> Does anyone here know ~patrick-hetu ?
<jcastro> I do
<jcastro> what's up
<FunnyLookinHat> jcastro, Not sure who I should be pushing on - Goose or Go - but it appears that one of the major hurdles to getting RS to work with Juju is that Content-Length isn't being sent correclty in headers
<FunnyLookinHat> However - I think I just narrowed it down to a core go issue
<FunnyLookinHat> Which - ultimately - is worse news... slower, etc.
<FunnyLookinHat> jcastro, it's a bit of a fiasco within the Go world it seems... I've managed to find a solution and posted to the above linked bug... I guess we'll see what Patrick thinks.  :)
<arges> hi. why does ppa:juju/devel not have saucy packages?
<FunnyLookinHat> Getting closer it seems - any ideas on this one ? http://hastebin.com/jehukavoye.bash
<FunnyLookinHat> arges, could have to do with juju-core being current dev?  https://launchpad.net/juju-core has saucy packages I believe
<arges> those are 1.10.0 when i installed
<arges> on sauncy
<arges> saucy
<FunnyLookinHat> Yeah? I'm confused. :)
<FunnyLookinHat> Hmm - so I'm confused as to exactly what Juju is looking for in this JSON Auth response to find object-store: http://jsonblob.com/51bf7a2ee4b04ed0983b2845
<thumper> morning
<FunnyLookinHat> howdy thumper
<thumper> hi FunnyLookinHat
<FunnyLookinHat> mind if I pick your brain real quick before you do REAL work ?
<FunnyLookinHat> I've managed to get juju to authenticate to rackspace with a minor patch to Goose - but it's now complaining with this error: http://hastebin.com/jehukavoye.bash - trying to narrow down what it's looking for in this auth response to see object-store http://jsonblob.com/51bf7a2ee4b04ed0983b2845
 * thumper looks
<thumper> FunnyLookinHat: unfortunately I know next to nothing about openstack or goose, but wallyworld, who does, should be online in an hour or two
<FunnyLookinHat> Ah I'll try to stick around :)
<FunnyLookinHat> Thanks though!
<wallyworld> FunnyLookinHat: thumper: hi, i'll look at it soon, after breakfast
<thumper> fwereade: was hoping to have some magic answers from you this morning :)
<wallyworld> FunnyLookinHat: your keystone does not define an object-store endpoint for the DFW region
<FunnyLookinHat> wallyworld, Do you have an example of what that response would look like so I can pass it on to rackspace?
<FunnyLookinHat> from some other provider, et.c
<wallyworld> i'll pastebin one, just a sec
<FunnyLookinHat> That'd be awesome - thanks
<hallyn> hazmat: heya.  I'm having a weird issue with (py) juju.  All my clients currently are raring, stock.
<hallyn> I'm using ec2 provider.
<wallyworld> FunnyLookinHat: https://pastebin.canonical.com/92973/
<hallyn> when i use default-series precise, juju bootstrap works
<hallyn> when i use default-series raring, juju bootstrap results in a bootstrap node which is useless until i manually log in and reboot it (after setup is completed)
<hallyn> then it proceeds
<FunnyLookinHat> wallyworld, You do not currently have access to the pastebin.
<hallyn> any nodes i bootstrap are the same - i have to lo gin manually and reboot before they are registered with juju
<FunnyLookinHat> I logged in w/ launchpad creds...
<wallyworld> FunnyLookinHat: ah sorry, i'll post to the public one
<FunnyLookinHat> no worries :D
<hallyn> hazmat: I"ll email the juju dev list laster tonight when my cable company deems fit to give me internet, but thought i'd ask here first.
<thumper> hallyn: weird...
<hallyn> thumper: it's 100% reproduccible so i figured it must be a known bug, but noone seems to think it is, so... :)
 * thumper is pleased it is pyjuju
<wallyworld> FunnyLookinHat: http://pastebin.ubuntu.com/5775344/
<FunnyLookinHat> wallyworld, great thanks - and Rackspace was curious as to what the object-store is used for...  just geek interest I think, but it piqued my own
<hallyn> thumper: does pyjuju do different things on the target nodes?
<wallyworld> FunnyLookinHat: juju uses the openstack swift APIs for storage
<thumper> hallyn: almost certainly
<wallyworld> FunnyLookinHat: there needs to be a world readable, "public" swift container for the tools
<FunnyLookinHat> wallyworld, Ah ok - I believe RS is pushing "swift compatible" API end points... just need to be put in that auth response
<wallyworld> FunnyLookinHat: and a "private" container is created for you when juju starts up
<FunnyLookinHat> Thanks
<wallyworld> np, goodl luck and ask again if you need to
<mramm> hey wallyworld you around?
<wallyworld> mramm: yes
<mramm> got time for a quick hangout, or you in the middle of stuff>
<mramm> ?
<wallyworld> nah got time, you got a url?
<wallyworld> or want me to start one?
<mramm> i got it
<mramm> sent to you
<wallyworld> right, got it
<thumper> wallyworld: https://codereview.appspot.com/9824047/ when you have a moment :) lbox sucks at dealing with merging trunk in the middle, just look at the LP diff
<thumper> wallyworld: ah... it is proposed against old trunk
<wallyworld> thumper: on a call with mramm
 * thumper nods
<fwereade> thumper, sorry, I didn't even look at your test failure :(
<hazmat> hallyn, that is quite strange, if you log in manually it would be useful to see the content of  /var/log/cloud-init-output.log
<thumper> fwereade: ok, I'll try to stumble through it
<hallyn> hazmat: will do that later tonight, thanks.  you're saying you can't reproduce?
<fwereade> thumper, I did get as far as briefly peering at the branch and wondering a bit about all the work you do in TestContainerCreate
<fwereade> thumper, what is it that requires all the infrastructure?
<thumper> fwereade: cloud-init creation
<fwereade> thumper, ok, I guess you want a real environ config, but can't you just use faked-up data for all the rest?
<thumper> possibly
<fwereade> thumper, even the environ config only needs to be good enough to get through New
<thumper> fwereade: can you point me at some similar type tests
<thumper> and I'll try to reduce the overhead
<fwereade> thumper, testing.InvalidStateInfo and .InvalidApiInfo for example
<thumper> fwereade: ta
<thumper> fwereade: don't stress, I'll work it out :)
<fwereade> thumper, and I don't think there's any need to touch state at all
<fwereade> thumper, the provisioner extracts the necessary info from state and passes it into StartInstance, and I think that's well enough tested already
<fwereade> thumper, you can just make up whatever you like and check that the generated cloud-init is consistent with what you expect
<thumper> fwereade: yeah, but I'm needing this to test the lxc container creation bits...
<thumper> I don't care what is in cloud-init
<thumper> not really
<thumper> I'm not looking inside
<thumper> that is tested in the cloud init tests
<thumper> I just want something valid to be written out
<fwereade> thumper, valid enough to actually run inside the container? surely not?
<thumper> it doesn't need to actually run
<thumper> as the lxc stuff is mocked out
<thumper> I'm testing the creation of the files in the right place
<fwereade> thumper, so, no need for the information you use to actually be backed in state, I think
<thumper> it seems that somewhere inside the cloud init, it is accessing state with the wrong password
<thumper> somehow
<thumper> causing mgo to reconnect
<thumper> which causes testing errors
 * fwereade gets nervous
<thumper> so I'm probably passing the wrong password info through to cloud init
<thumper> I may try reverse engineering the problem
<thumper> instead of poking from the top down
<fwereade> thumper, I don't think we should try to connect to state at all in order to generate a cloud-init
<thumper> *this* is why we should have interfaces around everything
<thumper> so we can mock it all out
<thumper> hmm... I'll dig some more
<fwereade> thumper, sure, I understand that just fine -- but in this particular case it may be a little bit gnarlier, because we *know* we usually generate cloud-init files without state access... at bootstrap time
<thumper> hmm...
<thumper> let me poke some more
<fwereade> thumper, what fails if you disable the home-fakery/
<thumper> still in start-up mode, haven't got to poking the test yet this morning
<thumper> merging the two dependent branches
<thumper> one is in, one is landing now (I believe)
<fwereade> thumper, ah, NewConnFromName I guess
<thumper> then I'm all over it like a rash
<thumper> fwereade: I need some valid stateInfo and apiInfo for the cloud-init
<fwereade> thumper, np, sorry to hassle, just kinda thinking aloud
<thumper> is that just to write out?
<thumper> I could fake those, right?
<fwereade> thumper, yeah, that's basically what Invalid*Info are for AIUI
<thumper> kk
<fwereade> thumper, "Fake" would be a better prefix
<thumper> :)
 * thumper reads his own code again...
<thumper> perhaps this is all bollocks...
 * thumper getting too concerned
 * thumper hacks
<fwereade> thumper, in particular, forget the Conn creation... that will probably be trying to do passwordy-hackery-bollocks
 * thumper nods
<thumper> I'm going to create a branch that renames the Invalid*State methods to Fake*State, and moves them from juju/testing into testing
<thumper> less dependencies
<thumper> \o/ two more branches landed
 * fwereade cheers
<fwereade> thumper, it seems we don't have standard code for the creation of a valid dummy Config for testing
<fwereade> thumper, except via home-hackery and yaml-juggling
<thumper> fwereade: point me to a good example, and I'll move one into juju-core/testing
 * fwereade counts 21 /"type": *"dummy"/ and has a bit of a sad
<fwereade> thumper, hmm, wait
<thumper> wait what?
<fwereade> thumper, all it needs is a *config.Config... you can create them pretty minimally, and they don;t even have to have a registered provider type iirc
<thumper> umm... wat?
<thumper> state/multiwatcher depends on testing?
 * thumper has an import cycle
<fwereade> thumper, ouch, grr
<thumper> hmm
<thumper> state/export_test.go
<thumper> seems to have a lot of stuff that shouldn't be there
<fwereade> thumper, that TestingEnvironConfig is indeed a good candidate to move elsewhere
 * thumper nods
<thumper> i have a file now
<thumper> testing/state.go
<thumper> I'm attempting to move
<fwereade> thumper, possibly TestingInitialize as well actually
<thumper> testing.Charms is another dep there
 * thumper digs
<fwereade> thumper, ok, yeah, best keep Initialize out
 * thumper moves some shit around
<thumper> fwereade: Initialize out of what?
<fwereade> thumper, I was thinking "testing"
<fwereade> thumper, but I guess cutting export_test down would have helped quite a lot?
 * thumper nods
<thumper> doing that now
<fwereade> thumper, as long as there are no internal tests using bits of it ofc
 * thumper nods
<wallyworld> thumper: off call now, did you need to repropose that branch?
<thumper> wallyworld: I resubmitted it
<wallyworld> ok
<thumper> grrr
<thumper> fwereade: state/settings_test.go is an internal test
<thumper> that using testing
 * thumper wonder how far to pull on this thread
 * fwereade wishes Settings just didn't exist, it's misused more than it's used
<mramm> fwereade: hahaha
<mramm> thumper: time box that thread pulling ;)
 * thumper will stop at noon
<thumper> thread pulling that is
<thumper> not work
<mramm> :)
<mramm> what time is it there now?
<thumper> 10:51
<mramm> cool
<thumper> I strongly hold the opinion that state should not depend on testing
<thumper> and we should be able to have testing provide state functions
 * thumper hits megawatcher_internal_test
<thumper> tempted to stop now...
<thumper> this is just getting stupid
 * thumper reverts, uncommits, and reverts again
<thumper> wallyworld: ta
<wallyworld> np
<thumper> \o/ create test passes with all fake inputs
<fwereade> thumper, sweet
<fwereade> thumper, be forewarned, in case you ever hit it: the environs/dummy is used inappropriately by something or other, and has similar tentacles
<thumper> fwereade: simple refactoring  https://codereview.appspot.com/10344044/
#juju-dev 2013-06-18
<thumper> grr
<thumper> davecheney: I'm getting grumpy at go right now...
<thumper> http://paste.ubuntu.com/5775663/
<thumper> http://paste.ubuntu.com/5775665/
<thumper> davecheney: any idea what I'm doing wrong?
<thumper> http://paste.ubuntu.com/5775667/
<thumper> file.go:10:2: import "launchpad.net/testing/checkers": cannot find package
<thumper> hmm...
<thumper> ah...
<thumper> forgot the juju-core bit
<thumper> works now
<thumper> nm
<davecheney> thumper: glad you solved it
<bigjools> how much attention is getting paid to locking critical sections in providers for non re-entrant code?
<thumper> bigjools: lots
<thumper> bigjools: AFAIK, providers should be reentrant
<bigjools> they can try to be :)
<thumper> can accessible from multiple go routines
<thumper> bigjools: right, just not dying is a good start
<bigjools> one of my esteemed colleagues was whinging about something
<bigjools> I figured it can't be that bad
<bigjools> thumper: oh the actual whinge was that concurrency/locking was not tested
<bigjools> is that right?
<thumper> probably
<bigjools> ok
<thumper> wallyworld: can I get you to look at https://codereview.appspot.com/10344044/ ?
<thumper> wallyworld: also, I have made an IsTrue checker
<wallyworld> ok
<wallyworld> +100000 for the IsTrue checker
<thumper> wallyworld: it will land with my lxc-container branch
<wallyworld> kk
<thumper> wallyworld: so... fake vs mock
<wallyworld> yeees?
<thumper> actually, those instances are neither fakes nor mocks
<thumper> in the traditional sense
 * wallyworld doesn't really care about the name
<wallyworld> land it i say
<thumper> so, tests say... Mocks have internal assertions
<thumper> fakes fake it
<wallyworld> yeah
<thumper> stubs are always dumb and the same
<thumper> so kinda fakes
 * thumper lands it
<wallyworld> \o/
 * thumper proposes the lxc-container branch
<hallyn> thumper: well, that figures.  today raring is bootstrapping fine.   !   Thanks anyway :)
<thumper> heh
<thumper> wallyworld: Rietveld: https://codereview.appspot.com/10370044
 * wallyworld looks
<wallyworld> thumper: i gotta take the dog to the vet, i'll finish the review when i get back soon
<thumper> wallyworld: kk
<thumper> wallyworld: todo with the claw?
<wallyworld> thumper: yes, it is almost better
 * thumper sighs
<thumper> ...
<wallyworld> thumper: for lxcFactory, did you consider making the containerfactory embedded? i can't see a need for the lxc attribute, just confuses things
<thumper> no, didn't consider that
<thumper> except I use separation at time
<thumper> particularly in the tests
<thumper> but perhaps it doesn't matter?
 * thumper is EODing to make dinner
<thumper> lxc-broker review coming too
<wallyworld> thumper: ok, i'll make the comment in the review
<jam> thumper, wallyworld: it looks like the stability stuff has been handled on go-bot. Have either of you had a patch rejected? (I don't see anything in the logs)
<wallyworld> jam: nope, so far so good \o/
<rvba> Hi fwereadeâ¦ I'm not sure I understand your comments on this branchâ¦ should I mark the MP on launchpad approved and get this landed or is there something wrong somewhere?
<rvba> s/this branch/my branch/
<fwereade> rvba, it looks like there's a storage-list-files branch that's the same as az-config-2
<fwereade> rvba, please get another review from someone on whichever you wish, then land it
<rvba> fwereade: that's probably the result of me messing with lbox.
<rvba> Oh, I thought one review was enough these days.
<rvba> But okay.
<TheMue> morning
<jam> morning TheMue
<rvba> Hi guys, could I please get a second review of https://code.launchpad.net/~rvb/juju-core/az-config-items2/+merge/169759 / https://codereview.appspot.com/10340044/ ?
<TheMue> rvba: *click*
<TheMue> jam: hiya
<rvba> TheMue: thanks!
<fwereade> rvba, if you get a "LGTM trivial", that's good enough, but for everything else wait for 2xLGTM please
<rvba> All right.
<fwereade> so, guys, I'll be off for most of the morning because (1) I have an appointment at 10 and (2) I was up way past my bedtime last night doing https://codereview.appspot.com/10251047
<TheMue> rvba: another lgtm
<rvba> TheMue: ta
<TheMue> fwereade: oh, will take a look. and you take care for yourself and recover
<fwereade> fwiw I now have 6 branches up on https://code.launchpad.net/juju-core/+activereviews and, while I could probably just land state-testable-transaction as is, even that one would apreciate a second pair of eyes (because it changed a lot since the first lgtms)
<fwereade> TheMue, thanks
<fwereade> TheMue, cheers :)
<TheMue> fwereade: i've got duty today, so i'll walk through your cls
<fwereade> TheMue, great, ta
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 9 Critical, 79 High - https://bugs.launchpad.net/juju-core/
<rogpeppe1> mornin' all
<TheMue> rogpeppe1: morning roger
<rogpeppe2> fwereade, TheMue: pretty trivial (but with nice effects!): https://codereview.appspot.com/10375043
<TheMue> rogpeppe2: just working on a different one by thumper, but then I'll take yours
<rogpeppe2> TheMue: thanks
<TheMue> rogpeppe: you've got a lgtm
<rogpeppe> TheMue: thanks
<rogpeppe> fwereade: TheMue says trivial but I'd like your LGTM just to OK where I've put the tweaks, if you're around. https://codereview.appspot.com/10375043
<fwereade> rogpeppe, concur, but maybe call it FastInsecureHash or something, just to be clear
<rvba> TheMue: thanks for the review, I'll land that branch as it's definitely a trivial change :).
<rogpeppe> fwereade: ok
<rogpeppe> fwereade: thanks
<TheMue> rvba: it is, yes
<hazmat> g'morning.. getting some odd failures trying out a fresh juju environment on ec2 today. new machines after bootstrap aren't being created
<hazmat> sound familiar? this is on trunk
<hazmat> hmmm. go 1.1 issue maybe
<mgz> what sort of failures?
<hazmat> mgz, that's the odd part, no failures, just failure to converge on state. i've had a machine pending for 10m, but nothing of note in the logs
<fwereade> hazmat, there is currently an incompatibility with 1.10/1.11, so unless you --upload-tools it won't work
<fwereade> hazmat, it's in review now
<hazmat> ah, ic
<hazmat> fwereade, thanks
<hazmat> fwereade, fwiw  --upload-tools didn't do the trick, i'll wait for the config incompatibility mp
<hazmat> oh.. maybe it did
 * hazmat retries w/ patience
<jam> mgz, danilos, wallyworld_: I think my son just hurt his knee, so I have to take him to the ER. I'm going to miss the standup
<mgz> jam: okay
<danilos> jam: ack, I hope it's not something serious, good luck
<hazmat> fwereade, so with --upload-tools, and deploying a service, i end up with a second machine, that tries to loops on a connect to mongodb on localhost, which is correct per its cloudinit data.
<fwereade> hazmat, hmmmmm, that sounds as though it might be an issue with tim's provisioner stuff
<fwereade> hazmat, thanks for flagging it, I'll investigate
<fwereade> rogpeppe, btw, what's the ETA on having agents actually connecting to the API? I have a feeling you were working a branch a little while ago..?
<FunnyLookinHat> seen Dave Cheney ?
<fwereade> FunnyLookinHat, bad time of day for him, I think; maybe I can help?
<FunnyLookinHat> fwereade, Just had some back an forth with him on this bug and didn't want to be updating it / bugging him about it if invalid... I know you guys have lots to do  :)  https://bugs.launchpad.net/juju-core/+bug/1124561
<_mup_> Bug #1124561: the Content-Length header is missing <Go OpenStack Exchange:Invalid> <juju-core:Invalid> <https://launchpad.net/bugs/1124561>
<FunnyLookinHat> I had accidentally misread the original bug and so when I applied it to juju-core it didn't really make sense...  my mistake.
<fwereade> FunnyLookinHat, that sounds sane to me for juju-core, but looks like it's worth reopening in goose
<jtv> Hi team â got time for a review?  Got a proposal up here.  Sorry to ask â we're in that initial phase for our work where everyone's blocking on everyone's branches.  Proposal is https://codereview.appspot.com/10367045/
<FunnyLookinHat> fwereade, Ah ok - thanks for the confirmation
<fwereade> jam, mgz: you guys know goose; it looks to me like that should hopefully be a relatively simple fix that'll unblock FunnyLookinHat, so would one of you please take a quick look at lp:1124561? see comment #5 in particular
<fwereade> jtv, on it
<jtv> thanks fwereade!
<FunnyLookinHat> fwereade, should I create a new bug or just change the status?  I'm not familiar with LP etiquette
<FunnyLookinHat> Ah thx  :D
<rogpeppe> fwereade: currently eating lunch, will get back to you
<fwereade> rogpeppe, cheers
<fwereade> FunnyLookinHat, put it back to New I guess? hopefully mgz or jam will take a look shortly and confirm
<FunnyLookinHat> Ok - thanks
<fwereade> FunnyLookinHat, if it's simple and an unblocker for you I might be able to pick it up myself if they can't -- and if it hasn't been touched by tomorrow please prod me
<FunnyLookinHat> fwereade, No worries - I have plenty to do on my end... I've unblocked myself by having my own branch of goose... now I'm working with Rackspace to sort out some object-store issues
<FunnyLookinHat> Thanks again for your help
<fwereade> FunnyLookinHat, ah, great
<jam> fwereade: reading the goose code POST is intentionally a chunked request (it takes an io.Reader to send, not a set of bytes to upload)
<jam> whether we can change that 'trivially' I don't know. But all of our POSTs are chunked by design.
<rogpeppe> fwereade: hands are free now :-)
<fwereade> jam, ahh, hmm, that'd be why the storage interface takes a reader and a length I suppose?
<fwereade> rogpeppe, cool
<rogpeppe> fwereade: i'm very much hoping to have some branches (re)proposed by end today/tomorrow. currently sorting out numerous non-flagged merge conflicts from all the code moving that has taken place.
<jam> fwereade: so it is possible we can change it, but it is how it is written right now.
<fwereade> rogpeppe, awesome, tyvm
<fwereade> rogpeppe, I'm impatient to get some task actually running against the api ;)
<rogpeppe> fwereade: yeah indeed
<rogpeppe> fwereade: if the API hadn't been redesigned under my feet, we would already...
<fwereade> rogpeppe, I'd expected that the process of getting the agent talking to the api would be independent of that, but I guess it's all distraction
<rogpeppe> fwereade: it's all bound up together
<fwereade> jam, but AFAICT you do in fact always have a length available at that point
<fwereade> jam, it really does look a little bit like a one-line fix, although I'm not sure how pleasant it will be to test
<fwereade> jam, am I missing something?
<jam> fwereade: so I think the same code is used to upload multi-MB files that is used to write request data.
<jam> It seems possible that we could do a normal POST for small-ish things.
<jam> But if chunked is going to fail in the future, it will still fail to upload tools, etc.
<jam> rogpeppe, mgz: https://code.launchpad.net/~jameinel/mgo/bug-1191487-close-race/+merge/169999 is my mgo patch that fixes the race condition for our test suite, and adds a test for the new behavior to the mgo suite as well.
<rogpeppe> jam: there should be no problem using lbox even without an lbox configuration
<rogpeppe> jam: lbox propose -cr -for lp:launchpad.net/mgo
<jam> rogpeppe: well when I firsrt tried it told me to go shove off because it couldn't find something about mgo
<jam> but this time it worked
<jam> so the description should be updated
<rogpeppe> jam: ah, you've got a codereview link?
<jam> hmm... it found the proposal, but didn't add a CR
<jam> I'll try again with -cr
<jam> rogpeppe: I think the problem was I thought "lp:mgo" would be trunk, but it is not
<jam> you have to propose to "lp:mgo/v2"
<jam> rogpeppe: https://codereview.appspot.com/10392043/
<rogpeppe> jam: is it deliberate that you're not unlocking the server when you return from AcquireSocket?
<fwereade> jam, I has a bit of a confused... what are the situations where we don't have a length available? it seems like all of goose/http expects a length to be known
<jam> fwereade: so I'm actually end-of-day now, so I won't be able to poke at goose. mgz do you have a chance to see if we can make POST from goose always do Content-Length instead of chunked uploads?
<jam> rogpeppe: ugh, old version of the patch
<jam> rogpeppe: no it isn't
<jam> it doesn't "matter" but we should unlockd
<rogpeppe> jam: +1
<jam> rogpeppe: patch and proposal updated
<fwereade> jam, mgz: http://golang.org/pkg/net/http/#Request has a TransferEncoding field, and the docs seems to indicate it's entirely independent of Content-Length and will magically handle chunked transfer for you
<fwereade> jam, mgz: what's the downside to setting .ContentLength and letting the http package do its thing with it?
<mgz> yeah, we should probably just set the length
<rogpeppe1> jam: reviewed
<ahasenack> hi guys, has anyone seen this error on a unit yet? http://pastebin.ubuntu.com/5777099/
<ahasenack> that's from trunk today, fwiw
<hazmat> ahasenack, yes.. i've had the same issue with trunk today
<ahasenack> oh
<ahasenack> I guess I should file a bug then
<hazmat> ahasenack, effectively trunk is broken with it, the machines try to connect to localhost for mongo instead of back to the state servers, fwereade was looking at it
<ahasenack> hazmat: is there a bug already?
<fwereade> ahasenack, hazmat: sorry, several things happened, let me double-check the logs and see if it'll be simple to back out
<hazmat> ahasenack, just filed one.. 1192172
<ahasenack> thanks
 * hazmat goes back to vacation mode
<jam> rogpeppe1: for a 'sleep' isn't there a go function for run other goroutines rather than sleep?
<jam> You're right that if I remove the log it hangs consuming cpu in that loop.
<rogpeppe1> jam: yeah, runtime.GoSched
<rogpeppe1> jam: is there a problem with calling sleep?
<jam> rogpeppe1: sleep in tests is an evil source of non-determinism
<rogpeppe1> might be runtime.Gosched actually
<rogpeppe1> jam: it looks like that test is fundamentally non-deterministic anyway, no?
<rogpeppe1> jam: you're polling waiting for something to happen
<jam> rogpeppe1: it is quite deterministic.
<jam> I'm polling for something to converge, and then continuing
<hazmat> how does the sleep change that
<rogpeppe1> jam: you might as well sleep for at least a millisecond or so while polling, or does the condition only happen momentarily?
<jam> rogpeppe1: it is the length of time for a goroutine to notice a read fails on a socket after a write has failed. *Usually* (99 in 100 times) it has already finished. That loop is for the 1in100 times it fails, and log was saying it took 40microseconds.
<rogpeppe1> jam: if you're not careful, you'll spend all the time running around that loop and the actual work that you're waiting for will never be done
<jam> sleep(1ms) would be ok
<hazmat> sleep(0) == runtime.GoSched
<rogpeppe1> jam: sleep for 100us if you want
<jam> hazmat: right, but if you do that, why not just GoSched?
<jam> and be explicit
<jam> rather than assume side-effect of sleep
<rogpeppe1> jam: i think a sleep makes it more explicit that you're actually waiting for something to happen
<hazmat> fair enough.. sleep(0) is a pretty common pattern for coroutine systems
<rogpeppe1> jam: i'm not sure that the scheduler is guaranteed to be fair
<hazmat> jam, openstack is littered with it ;-)
<rogpeppe1> jam: BTW, does newServer always return with len(unusedSocket) > 0 ?
<rogpeppe1> jam: ah yes, it looks like it
<jam> rogpeppe1: no
<jam> it depends what triggers the failuer
<jam> socket.Write is not guaranteed to fail
<jam> sometimes socket.Read fails
<jam> triggering the Abend before the newServer returns
<jam> that is the 99% case
<jam> actually
<jam> it is only infrequently that I need to loop
<rogpeppe1> jam: that's not what i was wondering about (i think). if newServer sometimes returns without an unused socket added, then you won't loop, but for the wrong reason. but since it calls pinger synchronously, i think you're guaranteed that if newServer returns without an error, the connection is there.
<rogpeppe1> jam: if you *do* loop, won't you have to wait for as long as the pinger interval?
<rogpeppe1> jam: which is presumably quite a long time.
<rogpeppe1> jam: if so, wouldn't you be better sleeping for a longer time rather than heating up the cpu waiting for the other goroutine's sleep to complete?
<jam> rogpeppe1: I never have to wait for the pinger interval
<jam> I wish it didn't ping at all
<jam> but the connection will always "fail" in that I'm connecting to localhost which connects and then closes the connection (I'm not talking to Mongo in this test)
<jam> the test itself completes in <1ms most of the time.
<rogpeppe1> jam: i think i've misunderstood the logic of the test entirely
<jam> rogpeppe1: so the only logic it is asserting, is that if server.Close() is called while we are waiting on net.DialTCP, that AcquireSocket notices and closes the socket rather than treating it as a new alive socket.
<niemeyer> jam: Thanks for catching that issue.
<jam> rogpeppe1: the issue is that pinger can trigger this case, but I'm triggering it directly by calling AcquireSocket with server.dial = closeDial
<jam> rogpeppe1: it happens that because newServer pings synchronously, there may-or-may-not be an unusedSocket lying around from that original ping.
<jam> It always gets cleaned up eventually because the localhost server closes the connection on it.
<fwereade> rogpeppe1, kanban
 * rogpeppe1 comes in from the garden to get wi-fi signal
<niemeyer> jam: Just sent a review.. let me know if you want to talk further about it
<jam> niemeyer: well, I didn't arrive at the fix because of breakage in mgo's test suite. Only from juju-core's test suite (which was quite hard to understand why it was failing with unclean threads)
<jam> We could strip the test down a bit, and actually connect to mgo (not set up a local server, etc)
<jam> but it would make the test a bit less isolated.
<niemeyer> jam: Hmm.. interesting. I thought it was in the suite due to the "left sockets in dirty state."
<niemeyer> jam: Which is a check I copied from the mgo suite
<jam> niemeyer: that was the juju-core suite
<jam> niemeyer: right
<niemeyer> jam: Sure, but we have the same check in mgo
<niemeyer> jam: What is the juju-core test doing that we don't do in mgo's?
<jam> niemeyer: probably you don't have many/any tests that take longer than 10s in mog
<jam> mgo
<jam> niemeyer: so the pinger thread doesn't wake up
<jam> at the same time the test is tearing down.
<jam> (goroutine)
<niemeyer> jam: There are, actually, since it takes a while for replica sets to recover, in the tests that very behavior on harsh shutdowns
<jam> niemeyer: so for reproducing it, adding a sleep to the Dial code and decreasing the pingDelay made it easier to trigger directly.
<jam> I didn't run the mgo test suite in anger enough times to see if it ever failed.
<niemeyer> jam: We can add a sleep to the dial code externally.. I'd be fine with having a test method equivalent to one we have in juju, for tweaking down the pingDelay time
 * niemeyer looks for the form used in juju
<jam> niemeyer: the test in juju is failing by accident because it is doing a lot of stuff and then pinger wakes up and leaves a stale lock
<jam> and the teardown cleanup code notices there is a stale connection.
<jam> (as in, it isn't testing pinger directly, etc)
<jam> niemeyer: I explicitly changed the dial to call server.Close() during the dial
<jam> so that it triggers at "exactly" the bad time
<jam> that part I think is fairly straightforward
<niemeyer> jam: Sure, that's fine.. these tests that check if there are connections hanging around are run on every single test
<jam> niemeyer: right, but only tests that stop right about the time a pinger wants to wake up and check have a chance of triggering the bug
<jam> and the window is pretty small
<niemeyer> jam: So I'm fine without a test for this
<jam> they have to wake up, ask to connect which on these machines is <10ms.
<jam> niemeyer: so for your other comment, would you like to see the check taken out of the if loop: time.Sleep() code; and just put into AcquireSocket?
<jam> that would remove some of the extra checks.
<jam> or is it just the check for closed after the ping completes that you want to avoid
<niemeyer> jam: Right, the former.. if we're checking in AcquireSocket, we can get rid of the local lock+check.
<jam> niemeyer: I'm pushing an update now which: (1) Adds a check for server.closed at the start of AcquireSocket, (2) removes it from pinger, (3) removes server_test.go (though I did check it still passed with the new code)
<niemeyer> jam: Super, will check it out
<ahasenack> fwereade: hazmat: reverting to r1291 fixed it for me for now
<ahasenack> but you probably know that already ;)
<FunnyLookinHat> So - is there an easy way to take the image I'm booting with KVM and my own custom user-data and snapshot it so I can throw it into my own OpenStack for testing?  Built with this:   https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_12.04_LTS_.28Precise.29_and_beyond_using_NoCloud
<hazmat> FunnyLookinHat, probably a better question for #ubuntu-server
<FunnyLookinHat> hazmat, good call.
<fwereade> rogpeppe2, TheMue: can I get an LGTM on https://codereview.appspot.com/10391045 (which just reverts r1292) please?
<rvba> TheMue: my branch https://codereview.appspot.com/10380043/ is not landing although I marked the MP approvedâ¦ did I miss something?  Do I need to approve it myself to have two LGTM?
<fwereade> rvba, have you set a commit message?
<rvba> fwereade: arg, that must be it, it's a classic :).  Thanks.
<rogpeppe2> fwereade: looking
<TheMue> fwereade: will look
<rogpeppe2> fwereade: which was the problematic bit? the changes in provisioner_task.go ?
<fwereade> rogpeppe2, specifically, we started getting addresses from state rather than the environ, I think
<fwereade> rogpeppe2, the previous form has problems too
<rogpeppe2> fwereade: yeah, that's what i thought. i was just looking for how provisionerTask.stateInfo actually gets set
<fwereade> rogpeppe2, but they're strictly less bad than not being able to deploy anywhere other than machine 0
<rogpeppe2> :-)
<rogpeppe2> fwereade: ah, i see
<rogpeppe2> fwereade: the problem is that we don't actually store the state.Info in the state
<rogpeppe2> fwereade: wouldn't that be a better fix?
<fwereade> would it be? that'd still get us unwanted localhosts
<fwereade> rogpeppe2, I think
<rogpeppe2> fwereade: i don't think do. not if we make sure that we use the result of Environ.StateInfo to pass to state.SetInfo
<rogpeppe2> s/do/so
<rogpeppe2> fwereade: the current problem is that state.Addrs is returning the same addresses that it used to connect
<rogpeppe2> s/Addrs/Addresses/
<fwereade> rogpeppe2, it's returning whatever LiveServers tells it
<fwereade> rogpeppe2, I absolutely agree that the "fix" I have proposed is not a fix
<rogpeppe2> fwereade: oh yeah
<rogpeppe2> fwereade: that's still wrong though
<rogpeppe2> fwereade: fair enough.
<rogpeppe2> fwereade: revert away; the right fix is probably not that trivial
<fwereade> rogpeppe2, I'll be talking to tim about it; I think it'll involve some machine addressability work to get it right
<fwereade> rogpeppe2, but maybe only a little before it's adequate
<rogpeppe2> fwereade: a quick fix would be to use Environ.StateInfo as previous. the addressability work can probably wait until we're actually doing HA
<fwereade> rogpeppe2, I don't see how that would help... we still connect to localhost on the bootstrap node, so localhost will be in the state info
<fwereade> rogpeppe2, the addressability work cannot wait, it's bound up with containers
<rogpeppe2> fwereade: the environ does a host lookup to get the stateinfo address, doesn't it?
<rogpeppe2> fwereade: that's why things work currently
<fwereade> rogpeppe2, the *environ* does, yeah, but the reason *juju* works currently is that it uses the info from the environ, not the one from state
<fwereade> rogpeppe2, or rather, the reason it doesn't work is the opposite
<fwereade> rogpeppe2, and this change restores the happy variant
<fwereade> rogpeppe2, we will indeed need more work in this area
<fwereade> rogpeppe2, but for now I'd just like to have a working trunk
<rogpeppe2> fwereade: exactly. i think that's what i was suggesting - when the provisioner comes up, it calls state.SetStateInfo with the results of environ.StateInfo
<rogpeppe2> fwereade: +1
<rogpeppe2> fwereade: (not that there *is* a SetStateInfo call currently, of course)
<rogpeppe2> hmm, it probably wouldn't be SetStateInfo; probably SetStateServerAddresses or something
<fwereade> rogpeppe2, yeah, something like that -- but actually having those addresses set on the machine objects would be quite nice too
<fwereade> rogpeppe2, that said, your suggestion does mean it'll work for the GUI on machines-other-than-0, so I will pass that along; cheers
<rogpeppe2> fwereade: yeah, it would be good to have addresses associated with machines in the state.
<rogpeppe2> fwereade: i think i proposed a worker for that in my HA sketch
<niemeyer> jam: I've tagged the fixed revision, btw
<niemeyer> jam: So updates will already pick the fix, although I'll announce with the new release
<fwereade> jam, hey, if you set a commit message on an approved MP that tarmac has previously ignored, will it reliably pick it up then?
<fwereade> ahasenack, hazmat: trunk should bootstrap again, and should in a few minutes bootstrap with 1.10 again, tarmac willing
<ahasenack> fwereade: thanks
<hazmat> fwereade, awesome
<jtv> I've got one of these situations where every  error return from my function can prefix the same context string onto the error message...  Would it be terrible of me to move that into a helper function like this?  https://codereview.appspot.com/10361047
<rogpeppe> jeeze everything about this machine has become incredibly flaky. the display, the wi-fi, youtube fullscreen, multiscreen. i wonder how much is hardware and how much is software
<jtv> Not fun debugging those problems.
<rogpeppe> jtv: you don't recognise this sequence from syslog by any chance, do you? sometimes it gets itself into a mode where this repeats forever without successfully connecting to the network it actually knows the correct password for. http://paste.ubuntu.com/5777587/
<rogpeppe> jtv: i *think* it usually happens when i've been switching between wi-fi hubs quite a bit
<FunnyLookinHat> rogpeppe, what sort of machine?
<rogpeppe> FunnyLookinHat: lenovo thinkpad x220
<FunnyLookinHat> Ah, well there's your problem...  ;)
<FunnyLookinHat> jk - that surprises me.  Intel graphics, yes?
<FunnyLookinHat> And probably wireless as well...
<rogpeppe> FunnyLookinHat: i was told it was one of best supported laptops.
<rogpeppe> FunnyLookinHat: oh well
<rogpeppe> FunnyLookinHat: it's been stable for two years. i've only seen these problems after upgrading to raring
<FunnyLookinHat> Ah strange.  Well - time to upgrade...  :)   https://www.system76.com/laptops/model/galu1
<rogpeppe> FunnyLookinHat: i've been meaning to reinstall from scratch to see if that helps, but i can't quite bring myself to lose a week fixing everything that i will inevitably have lost in the process.
<rogpeppe> FunnyLookinHat: no good - i need three buttons
<FunnyLookinHat> Fair enough - I was the same way ( used to be a ThinkPad guy ) and loved the eraser and all...  I just got over it eventually  :)
<rogpeppe> FunnyLookinHat: i use the world's strangest editor, which really really needs a three-button mouse.
<FunnyLookinHat> rogpeppe, PEBCAK ! :)  What editor?
<rogpeppe> FunnyLookinHat: http://research.swtch.com/acme
<FunnyLookinHat> Ah interesting - thx for the link
<rogpeppe> FunnyLookinHat: what i really want is a laptop with a display that works well in full sunlight
<benji> rogpeppe: you live in the UK and expect us to believe you have ever seen full sunlight?
<rogpeppe> lol
<benji> ;)
<rogpeppe> benji: i have to take advantage of whatever we have
<benji> heh
<FunnyLookinHat> haha
<rogpeppe> benji: hence i'm out in the garden currently
<rogpeppe> benji: because the sun is almost out
<rogpeppe> benji: and that's what triggered my wi-fi issues because i have to switch to phone data out here because the landline hub doesn't stretch this far
<benji> honestly your weather is probably better than mine today, it's raining on and off and I'm sitting outside anyway (under a covered porch)
<benji> we should start a line of weatherproof outdoor wifi boosters
<rogpeppe> benji: last couple of days it's been absolutely gorgeous. when british weather is good, it's wonderful
<benji> :)
<rogpeppe> benji: it only happens about 3 days a year tho
<benji> what is it the British say about how great summer is there: it's their favorite day of the year
<benji> it's all good though, come August I'll be sweltering in near 100% humidity, so I have to poke fun while I can
<jtv> rogpeppe: I don't recognize the sequence, but my wifi isn't working very well either...
 * jtv looks
<jtv> Nope, my log looks very different.
<jtv> Would anybody be willing to review my little error-context helper?  It's at https://codereview.appspot.com/10361047
<rogpeppe> jtv: we have something very similar called ErrorContextf in juju-core
<jtv> Ah great
<jtv> I looked for other similar "defer" calls, but didn't see it.
<jtv> Maybe I only looked in the providers.
<rogpeppe> jtv: i have mixed feelings about it in general
<jtv> I think it's something to be seen as a utility, not as a universal element in all error handling.
<jtv> There are clearly places where it's not appropriate.
<jtv> I'll scupper this branch then, thanks!
<rogpeppe> jtv: but that's because i think we do our error messages a bit wrong in general. i reckon error messages to tell you about what went wrong, not about what function you're calling (you know that, in general)
<rogpeppe> jtv: see utils.ErrorContextf
<jtv> Yes, looking at it now.
 * rogpeppe has to go.
<jtv> nn
<rogpeppe> g'night all
<rogpeppe> jtv: see ya
<jtv> nnnn
<jtv> (weird keyboard)
<TheMue> so, synctools change is in for review, have a good night
<thumper> fwereade: ping
<fwereade> thumper, pong
<thumper> fwereade: what was wrong with the provisioner branch?
<thumper> I'm not sure how the localhost thing is three
<thumper> there
<fwereade> thumper, I'm an idiot, I forgot that State.Addresses would return a localhost address if that was how the connection was made
<thumper> ah...
<thumper> well that is a bit screwy
<thumper> how should we address that?
<fwereade> thumper, yeah, there are better ways and worse ways of addressing it, but the sensible ones all seem to demand a bit of machine adddressability
<thumper> heh
<fwereade> thumper, I spoke to mgz, and the first step is apparently to clone the unit addressing stuff onto machine
 * thumper nods
<thumper> so, should we attempt to fix this branch now
<thumper> or just wait until some addressability bits are done
<fwereade> thumper, and then, if we have a machine agent running, we'll have an address for the machine, and everything will be good
<fwereade> thumper, because we should be able to get the management machines out of state very easily
<thumper> fwereade: do you have some time for a quick hangout?
<fwereade> thumper, sure
<wallyworld_> thumper: s'up
<thumper> wallyworld_: hey, OTP with fwereade right now
<wallyworld_> kk
<wallyworld_> thumper: tell fwereade to go to bed or else he will turn into a pumpkin
<thumper> something amusing from twitter yesterday: RT @qntm: "I love stateless systems." "Don't they have drawbacks?" "Don't what have drawbacks?"
<wallyworld_> lol
#juju-dev 2013-06-19
 * thumper proposes IsTrue and IsFalse in a separate branch for wallyworld_
<wallyworld_> \o/
<thumper> wallyworld_: I'll collect that beer sometime
<wallyworld_> ok
<thumper> wallyworld_: I'm trying to think how to test the error conditions better
<wallyworld_> which branch?
<wallyworld_> thumper: afk for a few minutes, bathroom guy arrived
<thumper> ack
<thumper> wallyworld_: Rietveld: https://codereview.appspot.com/10395044 this one
<thumper> davecheney: how do I create an inline []interface{} containing strings
<thumper> ?
<davecheney> inline interface{} ?
<thumper> nm
<thumper> []interface{}{"foo", "bar"}
<thumper> I was missing the first {}
<wallyworld_> thumper: when you are free, i'd like to hear about the outcome of your deliberations regarding the lxc branch. but don't interrupt your current work
<thumper> wallyworld_: I'm just making some lunch
<thumper> but can talk soon
<wallyworld_> no hurry, whenever
<wallyworld_> now you've made me hungry
 * thumper is making pizza
<thumper> wallyworld_: chat now while the pizza cools?
<wallyworld_> thumper: i'm free now but feel free to eat first
 * thumper is munching now
<thumper> wallyworld_: I'll ping you when not chewing
<wallyworld_> sure
 * thumper goes to make a coffee, then let the dog in
<thumper> wallyworld_: now?
<wallyworld_> ok
<wallyworld_> i'll make a url
<wallyworld_> thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
 * thumper needs another +1
<thumper> davecheney: you around?
<thumper> bigjools: I wonder if your +1 is good enough :)
<thumper> I think if I tried to propose this branch now, it'd shit itself
<thumper> because I added a dependency
 * thumper does it anyway to see what it looks like
<jam> thumper: +1 on what?
<thumper> hi jam
<thumper> jam: https://codereview.appspot.com/10395044/
<jam> thumper: my immediate thought is, do we need 'testing/checkers' vs just having the checkers in the 'testing' package? (given the earlier conversations about this).
<jam> *I* like modules, but I recognize it doesn't always need to be separated.
<thumper> jam: yes...
<thumper> because
<thumper> import . "launchpad.net/juju-core/testing/checkers"
<thumper> as it brings them into the current namespace
<thumper> normally with the testing functions, we don't want that
<thumper> only checkers are in the testing/checkers
<thumper> so you shouldn't be bringing in other functions
<thumper> means our checkers can be used just like the normal gocheck ones
<jam> (I don't think it would be terrible to have c.Assert(foo, testing.IsTrue) but I'll live with that)
<thumper> jam: that makes it longer than c.Assert(foo, Equals, true)
<thumper> :)
<thumper> trying to make the tests more readable
<jam> thumper: I type at about 60wpm :). I would hope the point of IsTrue is to give better messages.
<thumper> by having meaningful checkers wthout package prefixes
<thumper> me too
<thumper> I'm more about the readability of the code
<thumper> and I think without the package prefix reads more nicely
<thumper> jam: however there are also some we work with that don't seemed to have learned to type :-)
<davecheney> thumper: ack
<davecheney> sorry, was at lunch
<thumper> davecheney: that's ok
<davecheney> and when I say 'was at lunch'
<davecheney> i was in my kitchen eating a sausage
<jam> thumper: reviewed https://codereview.appspot.com/10395044/
<thumper> davecheney: sounds healthy
<thumper> jam: ta
<thumper> jam: did switch ever get to the state where it could remove directories that were added  in the other branch, and only contain ignored files?
<jam> thumper: vila had a patch which moved ignored files into a lost-and-found instead of marking it conflicted.
<thumper> jam: now, I tend to go "clean-tree", followed by "resolve --all"
<jam> thumper: I think you have to turn it on with a config setting (tell it to treat ignored as lost and put them there, but I don't remember the exact syntax)
 * thumper nods
<jam> thumper: bzr.transform.orphan_policy=move
<jam> will put them in `bzr-orphans'
<jam> thanks to spiv in #bzr
<thumper> jam: changed the file test functions into checkers
<thumper> jam: have many more tests now
<thumper> ok, and now I'm off
<thumper> see y'all tomorrow
<rogpeppe> mornin' all
<TheMue> morning guys
<TheMue> phew, what a start. had to fetch our daughter from work due to circulation problems. weather is extreme close and will go up to 34Â° today.
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: danilos | Bugs: 10 Critical, 79 High - https://bugs.launchpad.net/juju-core/
<jam> rogpeppe1: I'm looking at https://code.launchpad.net/%7Erogpeppe/juju-core/312-alt-api-jobs/+merge/170135
<jam> your cover letter sounds like you were moving code
<jam> but I only see addition of code.
<jam> Am I missing something?
<rogpeppe1> jam: looking
<rogpeppe1> jam: state/apiserver/machine/machiner.go has moved from state/apiserver/machiner
<rogpeppe1> jam: the machine agent API is new
<rogpeppe1> jam: (as per the CL description)
<rogpeppe1> jam: (well, CL title anyway)
<jam> rogpeppe1: https://codereview.appspot.com/10398043/ I guess codereview doesn't show renames very well. The only '-' lines I see are really machine_test.go
<jam> it would appear Launchpad was unable to produce a diff
<rogpeppe1> jam: no, it doesn't know about renames at all
<rogpeppe1> jam: if you look at https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/machiner.go - all that "unchanged" code is moved from a different directoryu
<rogpeppe1> jam: (note the package name change at the top)
<jam> rogpeppe1: well "machiner" vs "machine" is a bit hard to spot. You can actually see the rename in the unified diff mode.
<jam> rogpeppe1: is there more than just mechanical changes here?
<rogpeppe1> jam: yes
<jam> rogpeppe1: any chance you can point them out, because most of the diff is just renaming stuff
<rogpeppe1> new code:
<rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/api/params/params.go
<rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/agent.go
<rogpeppe1> https://codereview.appspot.com/10398043/diff/2001/state/apiserver/machine/agent_test.go
<jam> rogpeppe1: what is the difference between GoStringer and Stringer? (I realize what the actual attribute difference means, but what is the functional difference between having a String method and a GoString method) ?
<jam> Is that %v vs %#v ?
<rogpeppe1> jam: yes
<rogpeppe1> jam: see the fmt docs for details
<rogpeppe1> jam: that's all the significant new code. there are a few other tweaks here and there, which should be evident
<rogpeppe1> jam: sorry for the confusion. i should probably have split it up into about 4 small CLs
<rogpeppe1> jam: but i thought it was probably ok as is
<jam> rogpeppe1: it probably would have been a bit easirer to review. Mixing mechanical renames with functional changes takes different mindsets to review.
<rogpeppe1> jam: agreed
<jam> The former is "is this a reasonable rename to do, yes/no" and the latter takes thinking about what the code is trying to doe.
<jam> do
<rogpeppe1> jam: i was trying to make a CL that would be a replacement for an earlier CL with similar intent in the another pipeline
<rogpeppe1> jam: but i totally failed to merge it
<jam> mgz, danilos: I'll definitely miss the standup today, have a kid's-friend's-birthday party to attend.
<jam> I've been mostly doing reviews, my code to mgo landed, though.
<mgz> jam: okay
<jam> rogpeppe1: reviewed
<jam> LGTM
<rogpeppe1> jam: thanks
<fwereade> jam, last night go-bot complained that I'd approved a branch without getting it re-reviewed... and then it somehow got magically merged by tim overnight
<fwereade> jam, what did tim do, and what should I do to induce the same thing to happen?
<danilos> jam: ok
<danilos> jam: don't drink too much with those kids, though :)
<wallyworld> fwereade: hi, you up for a chat sometime?
<fwereade> wallyworld, sure, would you start one?
<wallyworld> ok
<wallyworld> fwereade: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
<rogpeppe3> danilos: any chance of a review of https://codereview.appspot.com/10398043/ please?
<danilos> rogpeppe3, sure, taking a look
<rogpeppe3> danilos: thanks
<danilos> rogpeppe3, LGTM, minor comments on your comments only :)
<rogpeppe3> danilos: tyvm
<danilos> rogpeppe3, I like it how your code looks nice and clean, good job :)
<rogpeppe3> danilos: thanks
<rogpeppe3> danilos: re the bulk API call - it purports to allow you to get information for many machines at once. but we only allow a single machine to be got (the machine agent's own machine instance)
<rogpeppe3> danilos: so there's no possible latency to be saved AFAICS
<rogpeppe3> danilos: we can only ever usefully pass a single id to GetMachines
<danilos> rogpeppe3, right, I'd say the API call names are a bit misleading then
<danilos> rogpeppe3, I was thinking of something like juju-gui using a call like this to get information on all the machines
<rogpeppe3> danilos: we are directed to make bulk API entry points for every single API call, regardless of whether it's actually appropriate to have one
<rogpeppe3> danilos: i must obey :-)
<danilos> rogpeppe3, ah, I see your point: you are complaining about the policy in that comment, understood :)
<danilos> rogpeppe, ok then, keep the 'utter maddness' in :P
<rogpeppe> danilos: the madness remains :-)
<danilos> mgz, hey-hey, joining us?
<mgz> danilos: want to talk? I'd need to reboot to do g+
<mgz> had, same time
<mgz> can you guys do mumble for today?
<wallyworld__> ok
<danilos> mgz, coming
<fwereade> TheMue, ping
<danilos> wallyworld__, can you hear me?
<mgz> doh!
<mgz> I'd left it on push to tal
<mgz> danilos, wallyworld__: my audio was working fine the whole time, I just didn't look at the right setting till just after we'd finished :)
<TheMue> fwereade: pong
<fwereade> TheMue, tyvm for sync-tools work; can I ask for a little followup though?
<TheMue> fwereade: sure, just proposed the resumer with better testing ;)
<fwereade> TheMue, please delete the dead source environment config, and move the storage reader into environs/ec2 (actual location open to discussion, but it shouldn't be in juju/cmd)
<fwereade> TheMue, (moving the actual syncing off somewhere different should also be done soon, but that's not what I'm talking about today)
<TheMue> fwereade: ok, but in ec2 it will be public
<TheMue> fwereade: thought i had the source stuff removed everywhere *sigh* will cleanup a bit :D
<fwereade> TheMue, I want it to be public, it's a perfectly good StorageReader ;p
<fwereade> TheMue, I think it's just one var :)
<TheMue> fwereade: fine
<danilos> mgz, heh, that only means you could have replied to all of our trash talk, but you missed it :P
<fwereade> TheMue, btw, I redid https://codereview.appspot.com/10302043 to be simpler, would you take a quick look please?
<TheMue> fwereade: *click*
<rvba> danilos: Hi, would you mind having a look at jtv's branch (https://codereview.appspot.com/10367045/) when you get a chance?  Jeroen is off today but he will be back tomorrow and this is an important building block for our work on the Azure provider.
<TheMue> fwereade: nice, looks better that way
<danilos> rvba, sure
<rvba> ta
<rogpeppe> right, away with dodgy phone connections; i now have wired ether to the garden!
 * rogpeppe goes for some lunch
<ahasenack> hey guys, got this error updating trunk just now:
<ahasenack> 	imports launchpad.net/juju-core/state/apiserver/machiner: import "launchpad.net/juju-core/state/apiserver/machiner": cannot find package
<ahasenack> now it's working again, nm then
<benji> gary_poster: I'll see if I can help him.
<gary_poster> benji, oh ye of the jumping channels, thank you very much!
<benji> gary_poster: it's confusing being omnipresent
<gary_poster> lol
<TheMue> fwereade: ping, hangout
<niemeyer> jam: ping
<mgz> niemeyer: jam probably won't be around this afternoon now
<niemeyer> mgz: Cool, thanks
<niemeyer> rogpeppe: ping
<rogpeppe> niemeyer: in a call right now
<niemeyer> rogpeppe: Cool, cheers
<rogpeppe> niemeyer: i'll be with you in a bit
<niemeyer> rogpeppe: Thanks, not in a hurry
<rogpeppe> niemeyer: hiya
<rogpeppe> niemeyer: call done
<niemeyer> rogpeppe: Heya
<niemeyer> rogpeppe: Would you mind to have a quick look at https://codereview.appspot.com/10366044/
<rogpeppe> niemeyer: looking
<niemeyer> rogpeppe: It's a simple change to implement ,inline in goyaml
<niemeyer> rogpeppe: It's pretty much copied from mgo/bson
<niemeyer> rogpeppe: There's a second part that I didn't do yet, to support inlining of maps
<niemeyer> rogpeppe: I'll do that as well, but that will require some additional time
<niemeyer> rogpeppe: I've just submitted https://codereview.appspot.com/10417043 as well, which is an obvious fix
<rogpeppe> niemeyer: what happens if there are field conflicts?
<niemeyer> rogpeppe: The same thing that happens currently: an error
<niemeyer> rogpeppe: I know that's unlike the json API.. but it's okay, we can improve it later in a compatible way
<rogpeppe> niemeyer: sounds like a good way forward
<niemeyer_> Erm
<niemeyer_> Weird those harsh disconnections
<niemeyer_> <rogpeppe> niemeyer: sounds like a good way forward
<niemeyer_> rogpeppe: That was the last thing I saw
<rogpeppe> niemeyer_: that's the last thing i said :-)
<niemeyer_> Cool
<rogpeppe> niemeyer_: do anonymous struct members work essentially the same way as "inline" struct members?
<niemeyer__> WTF?
<rogpeppe> [15:49:08] <rogpeppe> niemeyer_: do anonymous struct members work essentially the same way as "inline" struct members?
<rogpeppe> niemeyer__: i don't seem to see any code that understands about anonymous struct members, so perhaps not?
<niemeyer__> rogpeppe: No, the only way to inline is with ,inline
<rogpeppe> niemeyer__: ah
<niemeyer__> rogpeppe: They are orthogonal concerns
<rogpeppe> niemeyer__: encoding/json doesn't seem to think so
<niemeyer__> rogpeppe: mgo/bson seems to think so, though :)
<niemeyer__> rogpeppe: It's a departure from the standard behavior for sure, and a good one IMO
<rogpeppe> niemeyer__: i'm wondering when you wouldn't want an embedded struct member to be treated as inline
<niemeyer__> rogpeppe: They are orthogonal concerns
<rogpeppe> niemeyer__: they *can* be orthogonal, sure. i'm just wondering if there's a particular benefit in having things that way
<niemeyer__> rogpeppe: Whether you want to handle something in your code as inlined or not is an independent concern of whether you want it to look like being in a single block in a file
<niemeyer__> rogpeppe: This *is* the benefit
<rogpeppe> niemeyer__: perhaps so. i'm happy to see how it pans out.
<niemeyer__> rogpeppe: Either way, we don't really have to debate this
<niemeyer__> rogpeppe: We can't do anything else wihtout breaking compatibility
<rogpeppe> niemeyer__: good point
<rogpeppe> niemeyer__: i think you should be able to inline a *struct too
<rogpeppe> niemeyer__: ha
<rogpeppe> [15:57:49] <rogpeppe> niemeyer__: good point
<rogpeppe> [15:58:31] <rogpeppe> niemeyer__: i think you should be able to inline a *struct too
<rogpeppe> niemeyer__: reviewed, BTW
<rogpeppe> fwereade_: ping
<fwereade_> rogpeppe, pong
<rogpeppe> fwereade_: i was just looking at this line in state/api/state.go:
<rogpeppe> func (st *State) Machiner() (*machiner.Machiner, error)
<rogpeppe> fwereade_: and thinking about future developments.
<fwereade_> rogpeppe, oh yes
<rogpeppe> fwereade_: i'm wondering about something like this instead: func (st *State) Machiner() *machiner.State
<rogpeppe> fwereade_: reasoning that making a dummy request to check if we're allowed access isn't really that important
<rogpeppe> fwereade_: and that from a client's point of view, it really looks like a kind of state object
<fwereade_> rogpeppe, assuming that's all handled by the root swapping, yeah
<rogpeppe> fwereade_: then we can have machineagent.State, upgrader.State etc etc
<fwereade_> rogpeppe, it kinda does, yeah, I'm still thinking though
<rogpeppe> fwereade_: well, you'll still be able to call State.Machiner even if you're not a machine agewnt
<rogpeppe> fwereade_: but i don't think it matters much if we don't get an error until we make the first request
<rogpeppe> fwereade_: because it's something that should never happen in practice anyway
<fwereade_> rogpeppe, sure; and that leaves us open to construct agent-specific facades if we decide we have leisure to be clever in the future
<rogpeppe> fwereade_: yeah
<rogpeppe> fwereade_: i might be heading in that direction anyway
<fwereade_> rogpeppe, I'm kinda +1 on having a common name, so the shapes of the packages are nice and clear and consistent
<fwereade_> rogpeppe, but I'm not quite sure it should be State
<fwereade_> rogpeppe, machiner.API, for example, feels closer than machiner.State
<rogpeppe> fwereade_: using the name "State" means that we won't have to rename all the existing variables in the agent code
<fwereade_> rogpeppe, ha, good point :)
<fwereade_> rogpeppe, ok, sgtm, with an option on a future declaration (once I've forgotten this discussion) that it's a silly name and we should do a global replace ;p
<rogpeppe> fwereade_: i think that from a client point of view, it's actually a perfectly sensible name - that's how you talk to the state
<rogpeppe> fwereade_: the API is just a window onto the state
<fwereade_> rogpeppe, you may very well be right
<fwereade_> rogpeppe, cheers
 * fwereade_ is off for a bit now, probably back later at some point
<rogpeppe> fwereade_: ok, thanks
<rogpeppe> time to stop and enjoy the sunshine with a cold drink
<rogpeppe> g'night all
<thumper> I'm going to be starting a little late today as I have to take kids to the dentist
<dpb1> Hi folks: found one that might be low-hanging-fruit: https://bugs.launchpad.net/juju-core/+bug/1192728
<_mup_> Bug #1192728: differing behavior with pyjuju: config-get all json <juju-core:New> <https://launchpad.net/bugs/1192728>
<jtv> jam: since you commented on my branch, would you be willing to vote for landing?  It's this one: https://codereview.appspot.com/10367045/
<jtv> If so, I can apply your generic version of the locking-test pattern in a follow-up branch.
<jtv> (For now, we're rather blocked on this branch)
#juju-dev 2013-06-20
<wallyworld__> gary_poster: ping
 * thumper wonders why his branch isn't being picked up by tarmc
<thumper> hi wallyworld__
<wallyworld__> hi
<thumper> wallyworld__: would be good if you could take another look at https://codereview.appspot.com/10370044/
<wallyworld__> ok
<thumper> also, I think that https://codereview.appspot.com/10361045/ is missing a prereq
<wallyworld__> thumper: when we start a container via StartContainer(), do we really need to pass in tools and environ config? Why do containers need these and StartInstance in the provisioner doesn't?
<thumper> wallyworld__: yes, in order to create the cloud-init file
<thumper> and the provisioner does
<thumper> well...
<wallyworld__> StartInstance(machineId, machineNonce string, series string, cons constraints.Value, info *state.Info, apiInfo *api.Info) (instance.Instance, error)
<thumper> the environ provisioner has the environement
<wallyworld__> that's from the orker interface
<thumper> containers don't
<thumper> and tool selection for environment machines is done based on what you ask for
<thumper> for the container, it is got from the parent machine
<wallyworld__> ok, that makes sense, thanks
<wallyworld__> when we have so many params, i sort of like to do a struct to hold them
<wallyworld__> but no biggie
 * thumper shurgs
 * thumper calls bikeshed
<thumper> but I can understand where you are coming from
<wallyworld__> lots of other places in the code do it. i'm not saying it's a blocker or needs to be fixed, just thinking out loud
<wallyworld__> thumper: i can't see the container manager New() implementation
<wallyworld__> am i going blind?
<thumper> wallyworld__: is golxc ContainerManager method
<thumper> you said to embed it
<wallyworld__> ok, thanks, makes sense
<wallyworld__> thumper: so when we stop a container, why to we call manager.New() to get a container reference. why don't we ask for the existing container by id or something
<wallyworld__> New() just seem counterintuitive to get an existing container
<thumper> wallyworld__: New just gives an object that wraps a name
<thumper> New returns a new container object
<thumper> doesn't create the container
<wallyworld__> very confusing
<wallyworld__> New normally implies a new entity that is managed by the manager is created
<wallyworld__> ie the underlying foo didn;t exist before but does exist after New is called
<wallyworld__> so i read that code and expect a whole new container to be created
<wallyworld__> and once created, we shouldn't call New again just to get a reference to it
<wallyworld__> surely some other method can be used, like Get()
<thumper> wallyworld__: https://bugs.launchpad.net/juju-core/+bug/1174778 can you comment on this?
<_mup_> Bug #1174778: generate-config needs to be updated for new HP Cloud images <juju-core:New> <https://launchpad.net/bugs/1174778>
<thumper> wallyworld__: also, this one https://bugs.launchpad.net/juju-core/+bug/1183446
<_mup_> Bug #1183446: Error uploading tools into openstack: 401 Unauth <juju-core:New> <https://launchpad.net/bugs/1183446>
<wallyworld__> thumper: looking now, had to talk to tiler
<bigjools> I am told that trying to share symbols in _test.go files between packages doesn't work, is that right?
<thumper> bigjools: whazzup?
<thumper> bigjools: but the answer is yes if you are asking what I think you are asking
<bigjools> thumper: I want to export test features from one package so another can use them
<thumper> general practice is to move useful functions into juju-core/testing
<bigjools> not gonna happen here, because it's a function in gwacl
<bigjools> we want to expose something that creates a test object in the library
<thumper> what is gwacl?
<bigjools> thumper: azure library
<bigjools> I guess the question can be re-phrased as, does exporting symbols in test files actually do anything?
<thumper> bigjools: no, don't think so
<thumper> bigjools: make a testing package inside gwacl?
<bigjools> thumper: we thought of that but it presents more problems
<thumper> why?
<bigjools> the same exporting problem in reverse mainly
<thumper> wat?
<bigjools> we have test code that pokes around in package structs and what not
<thumper> oh, internal testing
<bigjools> yeah
<thumper> we don't do that (on the whole)
<thumper> if we need to poke internals
<thumper> we add functions to export_test.go
<thumper> which is i the main package
<thumper> not the _test package
<thumper> that way they are only exported for the test
<thumper> but generally not
<bigjools> what does exporting mean in a test?
<thumper> bigjools: as in:
<thumper> func SomeTestFunc(c *C, some value)
<thumper> so it is accessible from the test file
<bigjools> in a different package?
<thumper> no, just in the tests for that package
 * bigjools is confused now
<thumper> because that is the only time the _test files are used
<thumper> ok, example time...
<bigjools> I realise that - but I don't understand the need to export for use in the same package
<thumper> bigjools: hangout?
<bigjools> sure
<thumper> bigjools: you start?
<bigjools> head or bunny? (can never remember)
<thumper> head
<thumper> https://code.launchpad.net/juju-core/+activereviews
<thumper> bigjools: can you add ~juju-core to ~maas-maintainers?
<bigjools> thumper: why would I want to do that?
<thumper> bigjools: do you want to maintain the project? or do you want core to?
<bigjools> it's me for now
<thumper> I know it is
<thumper> that's why I asked you
<bigjools> :) it's not really anything to do with juju core though
<thumper> if you are happy to keep it, that's fine with me
<thumper> was an action item for me to chase from our last meeting
<bigjools> oh really?
<thumper> aye
<bigjools> gomaasapi now belongs to ~juju
<bigjools> maas-maintainers are down as driver though, feel free to change
<bigjools> thumper: got a sec to help with a compile error?
<thumper> sure
<thumper> jam: ping
 * bigjools assembles pastebin
<bigjools> thumper: http://paste.ubuntu.com/5782476/
 * thumper clicks
<bigjools> missing this:
<bigjools> func (t *TestTransport2) RoundTrip(req *http.Request) (resp *http.Response, err error) {
<bigjools> forgot to paste it
<thumper> bigjools: you need an &
<bigjools> where?
<thumper> transport := &TestTransport2{}
<thumper> TestTransport2 doesn't implement the interface
<bigjools> ok god this is the pointer vs non-pointer interface stuff
<thumper> *TestTransport2 does
<thumper> aye
<bigjools> :(
<bigjools> thanks
<thumper> wallyworld__: ping
<wallyworld__> hello
<thumper> wallyworld__: does machine.Destroy take containers into consideration?
<wallyworld__> think so, let me check
<wallyworld__> yes, it won't allow a machine to be destroyed if it has containers
<thumper> cool
 * thumper stopping for a bit, back for meetings tonight
<TheMue> morning
<jam> TheMue: morning
<TheMue> jam: hiya, thanks for review. will change to caps for abbrevs, yes
<TheMue> jam: regarding the location of the test server I have thought for some time. I need it in the ec2 package to test the reader but also in  the synctools to test there. *sigh*
<jam>  TheMue: can you put it into the testing/ locations ?
<jam> TheMue: I can live with it, but it would be nice to be clearly test-only code that doesn't have to end up in the juju and jujud binaries
<TheMue> jam: thought about testing too. in this case i would have to duplicate the structs for the xml marshalling/unmarshalling
<TheMue> jam: but maybe that price is worth it, yes
<jam> TheMue: fair enough.
<jam> Id probably say not
<jam> TheMue: I think you've already found a reasonable balance.
<jam> I didn't know about all the complexities. so LGTM where it si.
<jam> is
<TheMue> jam: thx
<rogpeppe> mornin' all
<TheMue> rogpeppe: heyhey
<rogpeppe> TheMue: hiya
<jam> greetings wallyworld_
<wallyworld_> hi
<jtv> jam: hi there!  Did you see how my test-for-proper-locking helper worked out, in the separate branch?
<jam> jtv: I did, and I posted a comment on it.
<jam> looks pretty good.
<jtv> Ah, thanks!
<jam> it doesn't quite match what you originally requested, but it does assert that the function doesn't return until after you've unlocked.
<jtv> jam: thumper suggested making it a checker.  Would love to, but right now I've got to get the basics out of the way, and they're blocking the team.  Funny how each improvement leads to a new one.  :)
<jtv> jam: I meant this, newer proposal: https://code.launchpad.net/~jtv/juju-core/generic-locking-test/+merge/170477
<jtv> Based on yours but pared down to something very simple & reusable.
<jam> jtv: I did review it, but I forgot to submit my inline comments.
<jam> jtv: sorry about that. 2-step review process and all
<jam> jtv: go-bot rejected your change because you added a new depdency. I imagine we need lp:gwacl installed on the machine?
<jtv> jam: argh!  Thanks for pointing that out.  Yes, we do.
<jam> jtv: done
<jam> you can resubmit
<jtv> Thanks very much.  :)
<jtv> Hadn't realized we hadn't had the dependency operational yet.
<jtv> jam: blast.  Now we also need gwacl's dependencies.  For starters, it needs github.com/andelf/go-curl
<jtv> (Looking for any other dependencies)
<jam> jtv: curl ?
<jtv> jam: yes, the built-in http library doesn't support tls renegotiation.
<jtv> (That set us back a bit!  Requests just failed with the words "no renegotiation," and the rest we had to figure out from source)
<jam> jtv: so do we need 'libcurl-dev' ? do you know what package?
<jam> (libcurl is one of those that has 20 different versions based on what SSL lib you use, etc)
<rvba> We need libcurl4-openssl-dev.
<jtv> What RaphaÃ«l said.  :)
<jam> rvba: wow, that brings in a lot
<jam> krb5, ldap2, gpg-errror, gcrypt11, etc, etc.
<jtv> There are also some packages *inside* gwacl that we need: launchpad.net/gwacl/dedent, launchpad.net/gwacl/logging
<jam> jtv: isn't that provided by 'bzr branch lp:gwacl' ?
<jam> jtv: 'go get launchpad.net/gwacl/...' succeeded
<jtv> I imagine it is... just wanted to save you later roundtrips if it came to that.
<jtv> That's it.  No other dependencies that I can see.
<jtv> Shall I retry?
<jam> jtv: you can retry as much as you like :)
<jam> may not *work*, but hopefully it will this time.
<jam> jtv: go-curl brings in a cgo dependency, which I think we were trying to avoid?
<jam> jtv: can you at least send an email to juju-dev bringing it up
<jtv> jam: I have no idea what the issue is that you're talking about...  could you elaborate about what dependency you mean, and why we're trying to avoid it?
<jam> jtv: go-curl has .c code in it. Which  means it isn't pure go code. We just changed goyaml to be pure go, and we implemented 'golxc' in terms of shell calls rather than lib calls because of not wanting to use cgo.
<jam> jtv: It is something that sounds like it needs a juju-dev conversation, but maybe I'm better to bring it up. I'm just in a call now and didn't want to forget about it.
<jam> jtv: test suite failed, not sure why
<jam> should be on the MP shortly
<jtv>  /o\
<jam> jtv: ffs, that looks like the mgo stuff that I thought I had fixed
<jtv> Yup.
<jam> jtv: ah, subtly different
<jtv> :(
<jam> jtv: this is 1 connection "InUse" the old failure was 1 connection "Alive"
<jam> jtv: 2 columns in the output, the 1 moved from the right to the left.
<jtv> I can't imagine it being related to my branch, but that may be a lack of imagination on my part.
<jtv> The universe of possible failures tends to defy imagination.
<jam> jtv: well, the same test is failing
<jtv> Same test as with that problem you worked on?
<jtv> Maybe it's one of those random failures?
<jtv> Passes sometimes, fails sometimes?
<jtv> If so, I guess I could just retry landing mine.  But then we'd better be damned sure my branch isn't to blame.  :)
<jam> jtv: I'm running the test directly right now
<jam> jtv: So far I've run it 12 times and it hasn't failed without your branch. Will try it with your branch
 * jtv hopes for success
<jam> jtv: run in isolation it passes with your change. We have to figure out where this 'InUse" connection is from.
<jtv> Shall I give my landing another go then?
<jam> jtv: right now I have the lander blocked while I'm testing
<wallyworld_> rogpeppe: hi, if you are free at some point i have a watcher question
<TheMue> fwereade_: ping
<rogpeppe1> wallyworld_: ask away
<rogpeppe1> wallyworld_: sorry i didn't see your ping
<wallyworld_> rogpeppe: i have a watcher and a test. if i comment out the SetProvisioned() line in the test, there should be no event but the watcher still gets a change and i can't see why. if i println inside the watcher, i see an empty change come through and i don't know why. here's a pastebin of some code snippets https://pastebin.canonical.com/93139/
<rogpeppe> wallyworld_: watchers always provide one initial event
<wallyworld_> oh. why?
<jam> wallyworld_: to give you a starting point
<rogpeppe> wallyworld_: so that you know you're in sync
<wallyworld_> ok. and that initial event is empty?
<rogpeppe> wallyworld_: that initial event gives you the current state of the world
<rogpeppe> wallyworld_: as the watcher sees it
<wallyworld_> ok, thanks.
<wallyworld_> rogpeppe: also
<wallyworld_> do you know about the mega watchwr?
<rogpeppe> wallyworld_: i do
<rogpeppe> wallyworld_: at least, i really *should* do :-)
<wallyworld_> rogpeppe: long story, but i have moved the InstanceId and Nonce attrs off machineDoc and int a separate instanceMetadata doc where other machine instance things like mem, cpu cores etc are now stored
<wallyworld_> the mega watcher tests expect to listen to machine and see instanceids
<rogpeppe> wallyworld_: ah, you'll need to add another collection to the megawatcher stuff
<wallyworld_> rogpeppe: sure. but i'm worried about what uses the mega watcher to listen to instance ids. does anything?
<rogpeppe> wallyworld_: yeah, the GUI does
<wallyworld_> what does it use InstanceId for? I will need to coordinate the changes then since when i land this, the ui stuff will break
<rogpeppe> wallyworld_: is the instanceMetadata collection already watched by the megawatcher?
<wallyworld_> not yet
<wallyworld_> that doc is new
<wallyworld_> it holds instance related things
<wallyworld_> like mem, cores, id, nonce etc
<wallyworld_> it's Id is the same as the machine to which it is related
<wallyworld_> its
<wallyworld_> when i say mem, id; i mean mem, instanceid
<wallyworld_> when I say Id, I mean _id aka primary key
<rogpeppe> wallyworld_: look at the backingStatus in megawatcher.go for a pattern to follow to update the megawatcher
<wallyworld_> rogpeppe: so why does the gui need to know the InstanceId? can't it just send requests using the machine.Id?
<wallyworld_> rogpeppe: i'll look at the backinfStatus, thanks. luckily there's only 3 failing tests out of the entire test run
<rogpeppe> wallyworld_: it can, but we maintain the invariant that the properties you see when asking for an entity are the same things the you see changing with the AllWatcher
<rogpeppe> wallyworld_: i think that's a good thing to maintain
<rogpeppe> wallyworld_: and we provide that information currently, so i don't think we should break backward compatibility
<wallyworld_> so if InstanceId is not longer a property on machine.....
<rogpeppe> wallyworld_: it is as far as the client is concerned
<rogpeppe> wallyworld_: even if it's not held in the database that way
<wallyworld_> what business reason does the gui have for needing the instanceid?
<rogpeppe> wallyworld_: so we watch the metadata collection and update the machine entity in the megawatcher store when the metadata changes
<gary_poster> wallyworld_, hi
<wallyworld_> gary_poster: hi
<rogpeppe> wallyworld_: it's actually a little simpler than for the statuses, because instanceMetadata can only apply to a machine, i assume
<wallyworld_> gary_poster: can i fill you in on the current conversation?
<rogpeppe> wallyworld_: where statuses can apply to several different kinds of entity
<wallyworld_> rogpeppe: yes, 1-1
<gary_poster> have a call in 3 wallyworld_ .  I *thinjk* the answer is "we need it as a key"
<wallyworld_> gary_poster: would love to chat perhaps after your call
<gary_poster> wallyworld_, you'll still be around in 1 hr?
<wallyworld_> yep
<gary_poster> ok will ping wallyworld_
<wallyworld_> thanks
<wallyworld_> rogpeppe: in the meantime, i'll look into making the current megawatcher tests pass
<wallyworld_> by adding a new collection etc
<rogpeppe> wallyworld_: cool
<wallyworld_> wish me luck
<wallyworld_> i've not done anything with this bit of the codebase before
<rogpeppe> wallyworld_: sorry for the extra work - that's the down side of using different collections for attributes with the same primary key
<rogpeppe> wallyworld_: feel free to ping me at any time
<wallyworld_> rogpeppe: no need to apologise. when the data model changes, there are always consequences
<rogpeppe> wallyworld_: i'm not sure that anyone else has added stuff to that particular part of the code base before
 * wallyworld_ straps on the headlamp and goes diving in
<rogpeppe> wallyworld_: the basic model is that a multiwatcher maintains a store of information on all the entities that are currently being watched
<wallyworld_> the *entire* data model?
<wallyworld_> what if we have 1000000 machines
<rogpeppe> wallyworld_: that's indeed a current problem with having a watcher that watches for all changes
<rogpeppe> wallyworld_: in the future, we'll probably move to a model where clients only watch for some summary of the state
<wallyworld_> rogpeppe: so am i right in assuming the store of info on the client mirrors exactly the persistent model?
<rogpeppe> wallyworld_: so we won't need to keep all info in mmeory
<wallyworld_> same classes etc
<rogpeppe> wallyworld_: not really
<rogpeppe> wallyworld_: it's exactly derived from it
<rogpeppe> wallyworld_: but it holds the entities that are observed by the client
<rogpeppe> wallyworld_: which don't necessarily map directly to the entities stored in the database
<wallyworld_> ok, so if there's a machineDoc with A,B attriutes, there'll be a clientMachine with A,B also etc
<rogpeppe> wallyworld_: status being a good example
<rogpeppe> wallyworld_: not necessarily
<rogpeppe> wallyworld_: we don't provide all attributes to the client
<rogpeppe> wallyworld_: and we provide extra attributes in some cases (for instance the machine status)
<wallyworld_> ok. will look at the code with that in mind
<rogpeppe> wallyworld_: the indirection is implemented by the    Backing.Changed(all *Store, change watcher.Change) error method
<wallyworld_> rogpeppe: so if gary just uses InstanceId as a key, he could also use Machine.Id right?
<rogpeppe> wallyworld_: i wouldn't dare to guess
<rogpeppe> wallyworld_: and i definitely think we should provide the instance id through the AllWatcher, so i think the point is moot
<wallyworld_> i'm not across what AllWatcher does
<wallyworld_> ie how it differs from mega watcher
<rogpeppe> wallyworld_: megawatcher.go implements the AllWatcher
<rogpeppe> wallyworld_: they're the same thing - just the AllWatcher is the "official" name
<wallyworld_> when you say provide InstanceId, does it have to be attached to a Machine object?
<wallyworld_> or can we expect code to listen to instanceMetadata to get it?
<jam> wallyworld_, mgz, danilos: The Juju team manager meeting is going to overlap with our standup, if it is done in time, I'll be there, but I might miss it.
<rogpeppe> wallyworld_: it must be attached to the params.MachineInfo object
<rogpeppe> wallyworld_: no, i don't think the client should need to know that there are two collections underneath
<wallyworld_> so the watcher listens to both and merges the data into MachineInfo?
<rogpeppe> wallyworld_: in the future, we might provide a multiwatcher that can watch a limited subset of the state, but that's not where we are now.
<rogpeppe> wallyworld_: yes
<wallyworld_> i'd still like to know what the business case is for needing InstanceId though
<wallyworld_> InstanceId is now just one bit of info that becomes available when a machine is provisioned - we now also have mem, cores etc
<wallyworld_> we didn't have all this previously
<rogpeppe> wallyworld_: we did provide the instance id through the AllWatcher
<wallyworld_> if InstanceId is just being used as a key, the Id will do fine
<rogpeppe> wallyworld_: InstanceId is also shown to the user
<wallyworld_> we did provide it, but do we need to continue prviding it if there's no business reason for it
<mgz> jam, wallyworld, danilos: if we could mumble the standup, that would save me various bother (and jam could be on mumble and hangouts at the same time :P)
<rogpeppe> wallyworld_: (it's an important piece of info, after all)
<rogpeppe> wallyworld_: I think that's probably the only way that the GUI finds out about instance ids
<rogpeppe> wallyworld_: and i think backwards compatibility is worth preserving
<rogpeppe> wallyworld_: there are other people using the API too
<rogpeppe> wallyworld_: outside of juju-core
<wallyworld_> backwards compatibility is good if the cost is not too great and/or the business reason is high
<rogpeppe> wallyworld_: i don't think the cost is too great here; and the benefits are significant
<rogpeppe> wallyworld_: you can use the AllWatcher as a way to show a dynamically updated system status
<jam> mgz: if only I could split the headphones so I listen to you with my right ear, and the managers with my left :)
<wallyworld_> ok, i'll look at the code. i'm still wondering why it's such an important piece of info. just curious as to why it's needed
<jam> mgz: and you *can* be on 2 hangouts at once, I believe.
<wallyworld_> what benefit do users get from seeing it?
<rogpeppe> wallyworld_: it's the only way a user can cross-correlate juju instances with instances in the ec2 management console, for example
<wallyworld_> ah ok, that makes sense
<wallyworld_> and i guess the same would hold for openstack
<rogpeppe> wallyworld_: indeed
<wallyworld_> if there is a management console
<rogpeppe> wallyworld_: there are presumably non-juju tools for managing openstack
<wallyworld_> yes
<rogpeppe> wallyworld_: there y'go then :-)
<wallyworld_> rogpeppe: it's still all a bit abstract - i'll look at the status stuff and try and understand what's being done and apply that to this case. thanks for the input.
<rogpeppe> wallyworld_: np
<mgz> fwereade_: have reproposed dimiter's machiner watcher branch as https://codereview.appspot.com/10439043 - can you give me a few more details on how to test watcher id validity?
<rogpeppe> wallyworld_: again feel free to ask about specific bits of code or anything else
<wallyworld_> rogpeppe: will do for sure. it's way past my EOD so i'll take a proper look tomorrow
<rogpeppe> mgz: if you want to test invalid watcher ids, you can always make raw api calls directly as necessary.
<jam> mgz: I also need to find out what is going on with co-installability with go-juju and py-juju.
<mgz> it's less that I want to test invalid ones, and more that I want to verify what I get is valid.
<mgz> jam: we need to update how we do the ppa
<mgz> because it's diverged from the fixed packaging
<mgz> the backporting to 12.04 is also much requested, but pretty much just ubuntu-process (we can basically take the existing raring packages for both pyjuju and gojujuju)
<mgz> tooju
<wallyworld_> fwereade_: fyi, i put up a mp to refactor the instance metadata api. i did it as a pre-req to the branch storing the metadata in state because the latter branch needs the allwatcher stuff modified and i want to get the api tweak in trunk asap https://codereview.appspot.com/10384049/
<fwereade_> wallyworld_, tyvm, sorry meeting now
<wallyworld_> np, just a heads up
<mgz> wallyworld_: hm, I approve of that idea in principle, looking at the branch now
<wallyworld_> ty
<mgz> danilos, jam, wallyworld: I'm on mumble
<danilos> mgz, coming
<danilos> jam: I don't think you can do two hangouts, last I tried (for on-air stuff), it complained
<rogpeppe> i'd appreciate a review or two of these CLs, if anyones feels inclined to:
<rogpeppe> https://codereview.appspot.com/10364046/
<rogpeppe> https://codereview.appspot.com/10437043/
<rogpeppe> anyone
<jam> rogpeppe: I *think* I figured out why my 'hack' patch worked, and the actual one that landed didn't.
<gary_poster> wallyworld_, you still want to talk?
<rogpeppe> jam: oh yes?
<jam> It seems that socket.Close *doesn't* remove the socket from the alive counts.
<jam> So when I returned a Closed socket.
<jam> It was calling socket.Release() on it
<rogpeppe> jam: ah!
<jam> now that I return an Err
<jam> nobody is Releasing it
<jam> so the code needs to be 'if server.closed: socket.Release(), socket.Close() return err"
<rogpeppe> jam: i should have looked deeper, sorry for slack code review!
<jam> rogpeppe: well, the test suite was passing
<jam> and I didn't do quite enough rigor testing of the juju-core test suite with the updated patch
<wallyworld_> gary_poster: hi, i think i'm ok now. the db model is changing to support instance metadata (ram, cores etc) for provisioned machines. part of the change is moving InstanceId from machine to a new entity. but i think i can still keep the watcher interface the same for your stuff
<rogpeppe> jam: Release doesn't do a Close then?
<jam> because it takes 10s for each run, and only fails once in a while when there is a release.
<jam> rogpeppe: Release is "put this back in the available queue" vs "Close" is don't let anyone talk on this anymore.
<jam> I would have thought Close would do a Release, but it doesn't
<rogpeppe> jam: so they're entirely orthogonal?
<jam> Release shouldn't clase.
<wallyworld_> gary_poster: i just wanted to find out how much you depended on InstanceId - i think you display it to the users
<gary_poster> cool thanks wallyworld_ .  FWIW, backwards incompatible changes without a transition period make me concerned generally
<jam> rogpeppe: not in *my* head :)
<rogpeppe> jam: neither mine :-)
<jam> Close calls kill
<jam> which makes the socket unusable
<jam> but it doesn't mark it as not InUse
<jam> just NotAlive
<fwereade_> mgz, sorry, just out of meetings -- I guess that successfuly using the watcher id is the clearest demonstration of its being valid
<rogpeppe> jam: a subtle distinction...
<jam> rogpeppe: well that is the 2 columns
<jam> and why the count moved from one into the otherc
<jam> but my old patch worked
<wallyworld_> gary_poster: yeah, understood. i wasn't sure how your stuff used the attribute ie the impact of any change, hence i wanted to find out before doing too much on it
<jam> because it happened to still call release
<gary_poster> wallyworld_, not sure but we might also need it as a key.  would have to look through code but won't since you are not changing now
<jam> because it used the 'send a request even if it is closed'
<rogpeppe> jam: presumably because it was relying on the usual code patch for cleaning things up
<gary_poster> cool thanks wallyworld_
<rogpeppe> s/patch/path/
<jam> rogpeppe: yep
<jam> and the test I wrote
<jam> just was testing that it noticed the server was closed
<jam> which it did
<gary_poster> have a good night wallyworld_ :-)
<wallyworld_> gary_poster: thanks also
<rogpeppe> jam: ha. gustavo was right about that test
<wallyworld_> will do
<rogpeppe> jam: too embedded in implementation detail
<jam> rogpeppe: but it also gave precise injection of concurrency
<jam> which is usually the tradeoff
<rogpeppe> jam: agreed
<jam> "run this 100 times and maybe it fails once"
<jam> vs "this will always fail if you got it wrong"
<jam> rogpeppe: it wouldn't be hard to have had my test case also check that all sockets had been fully cleaned up.
<rogpeppe> jam: but it would be nicer still to have a test that didn't delve so much into the implementation
<rogpeppe> jam: though i appreciate that might be hard...
<jam> rogpeppe: precise injection of concurrency is usually very white-box testy
<jam> otherwise it is in the "well maybe they happened at the same time"
<jam> or "maybe the scheduler did them in an order that always passes"
<rogpeppe> jam: sometimes just having a slow test that runs things in a loop, failing probabilistically isn't a bad approach
<niemeyer> And very white-box tests that exercise precise scenarios of concurrency are generally a drag. In practice, it's trivial to introduce race conditions that go uncovered.
<jam> rogpeppe: right now, juju-core test suite almost always fails when run in practice, but if you run just the test, it almost always passes
<niemeyer> Good morning/afternoon, by the way :)
<rogpeppe> niemeyer: yo!
<jam> niemeyer: that is true, but you can also add those cases as you find them. The main issue is without adding those cases
<jam> all you know is that you probablistically made things better.
<niemeyer> jam: If you Release the socket and it's injected back onto a closed server, the socket is immediately closed.
<niemeyer> jam: Sure, but I don't consider it a good tradeoff. You're testing an extremely specific race condition, not the next one
<jam> niemeyer: RecycleSocket doesn't add it to unused, but *doesn't* call socket.Close()
<jam> niemeyer: unless I'm missing something, you must call both Release and Close on the socket.
<niemeyer> jam: Indeed, you're right, because Server.Close already closed htem
<jam> One to unset the IsAlive flag, and one to unset the InUse flag.
<niemeyer> jam: As long as we don't allow new sockets to be created (as the old code was doing) or left open, it should be okay
<jam> niemeyer: by the time server.Connect has returned, it has created a new socket that has been acquired, so it needs both.
<niemeyer> jam: On a meta level, for race-prone logic, what I appreciate doing is punching the code with concurrency and checking that it survives in a consistent way
<niemeyer> jam: That's actually useful, because it's covering the past and future cases of uncovered races.
<niemeyer> jam: It's what mgo/txn does, for example
<rogpeppe> i find it interesting, given what people say about Go's memory non-safety, that almost none of the race conditions we've discovered have resulted from memory races
<rogpeppe> and would probably have been possible to occur in any of the so-called "concurrent-safe" languages
<niemeyer> rogpeppe: Sure, I don't think anyone expects code that is not memory-racy to bug-free
<niemeyer> rogpeppe: If that wasn't the case, every Python application would be bug-free :)
<rogpeppe> this particular issue is a good example - it could easily have occurred in haskell with STM
<rogpeppe> niemeyer: sure
<rogpeppe> niemeyer: i just think it's an interesting thing to observe
<niemeyer> rogpeppe: I agree
<niemeyer> rogpeppe: Reminds me of The Rubber Boots post
<rogpeppe> niemeyer: what post is that?
<niemeyer> rogpeppe: https://plus.google.com/u/0/107994348420168435683/posts/993U42yVbfk
 * rogpeppe sees the dark clouds gather above and wonders if it might be a good moment to go inside
<rogpeppe> niemeyer: thanks - i vaguely remember that now
<TheMue> rogpeppe: we had a kind of apocalypse yesterday evening
<rogpeppe> TheMue: lots of rain?
<rogpeppe> TheMue: or angels of darkness and death?
<TheMue> rogpeppe: heavy thunderstorms
<TheMue> rogpeppe: thankfully the center has been more south of us, so here not much rain. but around my hometown ...
 * rogpeppe can't decide if this particular large black cloud might not produce rain and have sun following it, or if i might have to run for it
<ahasenack> hi guys, just wanted a quick assessment of https://bugs.launchpad.net/juju-core/+bug/1192728
<_mup_> Bug #1192728: differing behavior with pyjuju: config-get all json <juju-core:Confirmed for themue> <https://launchpad.net/bugs/1192728>
<ahasenack> if you agree it's a bug, or not, etc
<TheMue> ahasenack: it is, i'm just working on it
<ahasenack> basically config-get with no key returns all keys. In pyjuju, it only returns keys that were set (manually or via default values)
<ahasenack> in juju-core it returns all
<ahasenack> TheMue: ah, ok, thanks
<TheMue> rogpeppe: ask www.nsa.gov/prism, they know if it'll rain
<rogpeppe> TheMue: only because they bug the Met Office :-)
<jam> niemeyer: so with my "patch" to widen the concurrency hole (set pingerDelay to 5s and add a 10ms delay in newSocket). I can get the juju-core test suite to fail 8-in-10 times, and adding a line 'socket.Release()' before socket.Close() in AcquireSocket, it passes 10-in-10.
<jam> niemeyer: do you want a branch for that, or you can do the change yourself?
<rogpeppe> ahasenack: have you encountered a problem with that behaviour?
<rogpeppe> ahasenack: (the Go-juju behaviour, that is)
<niemeyer> jam: I can do the one-liner quickly.. I'm actually just trying to write a high-level test that exposes that logic to concurrency in a black-box fashion
<ahasenack> rogpeppe: yes, one charm of ours basically dumped all juju config values into the config file
<rogpeppe> ahasenack: i'm wondering if there's another way to see all possible config options without looking directly at the charm config metadata
<ahasenack> rogpeppe: in gojuju we started getting "url = None"
<ahasenack> rogpeppe: in pyjuju we didn't get that key, because it wasn't set
<jam> niemeyer: you can have a goroutine calling AcquireSocket and closing it, and another closing the server at some random point in time. But you need real hardware concurrency, rather than single-threaded 'maybe the scheduler decided to switch goroutines'.
<jam> (i think)
<rogpeppe> ahasenack: interesting, thanks
<ahasenack> rogpeppe: honestly, I'm surprised with both
<rogpeppe> ahasenack: what behaviour would you expect?
<jam> niemeyer: the problem is that the test suite *I* have, without the changes to delay, passes 10-in-10, and really only fails under direct test about 1-in-50 or so.
<ahasenack> rogpeppe: one can argue both ways, that both behaviours are correct I think
<jam> (it fails when running the whole test suite about 3-in-4, I'm guessing because of extra load/memory/timing changes/etc.)
<ahasenack> "config-get" will return all config keys. The ones that weren't set will have a value of None
<ahasenack> or
<ahasenack> "config-get" will return all config keys that have a value set either manually or via a default value
<rogpeppe> ahasenack: the former is the current Go behaviour, right?
<ahasenack> rogpeppe: right, and I'm slightly in favor of it
<ahasenack> rogpeppe: at this point I guess it's more a question of maintaining backwards compatibility
<rogpeppe> ahasenack: yeah
<rogpeppe> ahasenack: maybe we could add a "-a" flag
<rogpeppe> ahasenack: so that the current Go behaviour is still available ('cos it's useful) but backward-compatibility is preserved
<ahasenack> hm
<ahasenack> so the go behaviour that we have now would only happen if you added "-a", for "all"?
<TheMue> rogpeppe: -a or --all?
<rogpeppe> TheMue: maybe both, meaning the same thing
<rogpeppe> ahasenack: yes
<TheMue> rogpeppe: as an option like --format
<ahasenack> seems nice
<ahasenack> the docs would say something like this
<ahasenack> "config-get with no key specified will return all keys that have a value, either set manually or via a default value"
<ahasenack> "if -a is provided, then all keys, regardless of their value, will be returned"
<rogpeppe> ahasenack: "config-get with no key specified will return all keys that have a value that is not None" ?
<ahasenack> what if I set "None" in the config? Is there an equivalent yaml value for python's None?
<rogpeppe> ahasenack: because i think it might be possible to manually set a config setting to its original unset value
<rogpeppe> ahasenack: it's a good question, i'm not sure
<rogpeppe> ahasenack: i *think* that "" is always unset, but fwereade_ has poked at this a lot more recently than me
<ahasenack> I find myself reading your version several times over to understand it
<rogpeppe> ahasenack: yeah, double negatives are never good
<rogpeppe> ahasenack: "config-get with no key specified will return all keys that have a value"
<rogpeppe> is probably good enough
<rogpeppe> s/that have/with/
<ahasenack> +1, but I prefer that have
<fwereade_> ahasenack, rogpeppe: I have a lurking feeling that it will actually include those without values
<rogpeppe> fwereade_: indeed
<rogpeppe> fwereade_: that's the bug
<fwereade_> ahasenack, rogpeppe: (independent of default substitution for missing values ofc)
<rogpeppe> fwereade_: https://bugs.launchpad.net/juju-core/+bug/1192728
<_mup_> Bug #1192728: differing behavior with pyjuju: config-get all json <juju-core:Confirmed for themue> <https://launchpad.net/bugs/1192728>
<fwereade_> ahasenack, rogpeppe: ah-ha, ok, thank you
<rogpeppe> fwereade_: but we think the current go behaviour is actually useful, so the proposal is to add a -a (and/or a --all) flag
<rogpeppe> fwereade_: with which you'd get the current behaviour
<ahasenack> --include-unset?
<ahasenack> we have two "all"s in here
<ahasenack> config-get with no key returns "all" keys (with values set)
<fwereade_> rogpeppe, ahasenack: --full? --complete?
<ahasenack> and -a returns all keys again (regardless of value)
<rogpeppe> fwereade_: i think -a has quite a bit of historical precedent
<fwereade_> rogpeppe, fair enough, don't let me bikeshed it :)
<fwereade_> rogpeppe, ahasenack: I'm +1 on this then
<fwereade_> TheMue, I see you're assigned to it
<TheMue> fwereade_: yep
<fwereade_> TheMue, it should just be a trivial tweak in jujuc I think
<TheMue> fwereade_: already working on config-get, there is another issue
<ahasenack> rogpeppe: "config-get with no key specified will return all keys that have a value" s/all//
<TheMue> fwereade_: looks like, yes
<fwereade_> TheMue, ah, what's the other issue?
<rogpeppe> ahasenack: or s/all/any/ ?
<TheMue> fwereade_: https://bugs.launchpad.net/juju-core/+bug/1192706
<_mup_> Bug #1192706: config: empty strings return null with --format=json <bitesize> <cmdline> <jujud> <juju-core:In Progress by themue> <https://launchpad.net/bugs/1192706>
<ahasenack> rogpeppe: works too
<fwereade_> TheMue, hmm, when was an empty string ever a valid value for anything?
<fwereade_> TheMue, it's not settable
<TheMue> fwereade_: as i understood default is no empty string but the string '""'
<TheMue> fwereade_: two double quotes in the yaml
<niemeyer> jam, rogpeppe: Waiting for sockets to die: 451 in use, 46 alive
<fwereade_> TheMue, that's an empty string, try unmarshalling that yaml
<rogpeppe> fwereade_: is it possible to explicitly set an empty string for a string-typed config value?
<fwereade_> rogpeppe, it never was before, empty strings were always converted to "delete" internally
<niemeyer> jam, rogpeppe: http://paste.ubuntu.com/5783538/
<rogpeppe> fwereade_: yeah. it does seem a bit wrong though. sometimes i might *want* an empty string even though the charm default is non-empty.
<fwereade_> rogpeppe, ok, but thus far it has been impossible except apparently via this default backdoor
<rogpeppe> niemeyer: that's more the kind of test i was imagining
<rogpeppe> niemeyer: +1
<TheMue> fwereade_: if i've seen it right we currently don't handle a default value if a key is missing
<fwereade_> TheMue, sorry, restate please
<TheMue> fwereade_: in the example of the issue a default: is used
<jam> fwereade_: I just sent an email to juju-dev trying to summarize the API for Upgrader as I see it. Can you at least skim it and see that it matches what you got out of our conversation?
<fwereade_> jam, I'll try, I'm rather backlogged today :)
<TheMue> fwereade_: maybe i'm not yet deep enough in our code, but i haven't seen where we handle it
<fwereade_> TheMue, default is handled at ReadConfig time
<jam> fwereade_: I'm not working on it till Sunday anyway
<jam> no rush
<jam> niemeyer: pingDelay*10 seems a bit funny. can you make the const pingDelay 20 instead ? (so you get a feeling for the range from the const at the top)
<TheMue> fwereade_: ah, ic, so looked at the wrong place
<TheMue> fwereade_: thx for the hint
<jam> ah, I guess I see why it is separate.
<fwereade_> TheMue, and hits the ""-becomes-nil logic when figuring out the actual default
<niemeyer> jam: It's not the same thing, but sure.. it'll probably hit the bug either way
<TheMue> fwereade_: just started to take a look into config-get, but it's earlier. good to know
<fwereade_> TheMue, I am a bit nervous about having separate validation paths for default settings and normal settings
<TheMue> fwereade_: will have to look at it first
<TheMue> fwereade_: but a small different topic before
<TheMue> fwereade_: would like to merge the moved ec2 http storage reader
<jam> niemeyer: so nm, because you use pingDelay as s
<TheMue> fwereade_: it has two lgtms but i would like to discuss the location of the test server with you
<jam> I would say you probably want pingDelay +/- randomTime
<jam> as the time.Sleep part
<jam> (possibly only - ?0
<niemeyer> jam: Nah.. it's simpler.. taking the ping delay down to 1 already triggers it
<niemeyer> jam: Just letting them fight a little bit is enough
<TheMue> fwereade_: i made it public iin the same package, as i have to use it their for the test and in synctools for the test. other location would be testing, but in this case i would have to duplicate the xml marshaling structs
<niemeyer> (even without random)
<TheMue> fwereade_: so both solutions have their downsides
<TheMue> fwereade_: what do you say, keep it  in ec2 or move it to testing?
<fwereade_> TheMue, ok, cool, I will see if I can figure it out quickly
<TheMue> fwereade_: thx
<fwereade_> TheMue, ah, ok, it's a full-fledged server, not just canned data?
<TheMue> fwereade_: it's the same one like before, a faked one but handling the requests of the http reader
<TheMue> fwereade_: delivering the index xml and the files (simplified ones out of a map)
<niemeyer> jam, rogpeppe1 : It's fixed and up
<niemeyer> bbl
<rogpeppe1> niemeyer: thanks
<niemeyer> rogpeppe1: np
<fwereade_> TheMue, ISTM that it's a bit wrong to reuse the same structs... it renders the tests somewhat tautological
<fwereade_> TheMue, how about cutting the internal structs down to just the fields we care about, and using the full structs (ideally with some actual values filled in) in the testing server?
<TheMue> fwereade_: would be possible, yes. we don't use very much of the structure.
<fwereade_> TheMue, if it's not too much hassle I think that would be ideal
<TheMue> fwereade_: and also move the server to testing then?
<fwereade_> TheMue, yes please
<TheMue> fwereade_: no, should be simple and feels even better for me
<fwereade_> TheMue, awesome news
<TheMue> fwereade_: just re-proposed it
<fwereade_> TheMue, cool, ty
<rogpeppe1> mgz: you have a review
<mgz> rogpeppe1: ta
<TheMue> argh, missed the change in synctools test, but now a (hopefully) final propose
<jtv> jam: I guess you figured out the problem with that test?
<fwereade_> rogpeppe2, TheMue, kanban
<rogpeppe2> fwereade_: trying
<rogpeppe2> fwereade_: it doesn't seem to like me currently
<fwereade_> rogpeppe2, it's been a bit picky with me lately too
<fwereade_> rogpeppe2, let's give it a minute
<rogpeppe2> fwereade_: it's just not loading the page
<rogpeppe2> fwereade_: other connectivity seems ok
<rogpeppe2> fwereade_: same problem trying to connect to plus.google.com
<fwereade_> rogpeppe2, I have had that too
<fwereade_> rogpeppe2, rebooting my router seems to help, but it's probably superstition
<rogpeppe2> fwereade_: google.com just fine
<jam> jtv: yeah, I sorted it out
<jam> mgz: Can you go to the cross-team meeting again today
<jam> ?
<mgz> jam: can if I reboot, it's now, right?
<mgz> can someone invite me on g+?
<benji> rogpeppe2: here's your syntax: juju set option=â
<benji> ;)
<ahasenack> hi guys, I got myself in a dying loop: http://pastebin.ubuntu.com/5783889/
<ahasenack> I will try to reproduce it, but basically it's a ceph unit, with a subordinate, and I ran "juju destroy-unit ceph/3"
<ahasenack> and all hell broke lose :)
<ahasenack> that pastebin is happening in a loop
<FunnyLookinHat> Wow - my crash course in GoLang has made me more frustrated with it than anything...  apparently it can't handle null values in JSON responses.  :-/
<mgz> FunnyLookinHat: it can, but probably not in the way you expect
<FunnyLookinHat> mgz, well - all I know is that juju-core can't bootstrap to my devstack because it's failing on a null value
<mgz> you can unserialised to a pointer type in the struct, or use an intermeduary form
<FunnyLookinHat> http://hastebin.com/rokukasixi
<mgz> FunnyLookinHat: file a bug (and then probably just fill in the description in your devstack config)
<FunnyLookinHat> Yeah I'll do that - going to make sure it's not some patch I applied to Goose inadvertently
<mgz> you don't even need to file a bug, just +affectsmetoo bug 1188825
<_mup_> Bug #1188825: If description is unset, goose doesn't understand 'null' value <serverstack> <Go OpenStack Exchange:Confirmed> <https://launchpad.net/bugs/1188825>
<FunnyLookinHat> Perfect
<mgz> you can just that in devstack
<mgz> I haven't got a step-by-step for it though
<FunnyLookinHat> right right - I can figure that much out - thanks for the bug ref
<mgz> dpb1: ^see the above, do you remember off-hand what keystone config you needed to set for that?
<dpb1> mgz: jamespage actually worked-around it. I'm not sure what he set.  james?
<jamespage> mgz, you need to have an empty description in the tenant/project
<mgz> ah, so when you create it via the keystone api?
<mgz> rather than in a conf file?
<jtv> Any reviewers available?  I had to make this a native Launchpad review, because there was an unlanded prerequisite branch: https://code.launchpad.net/~jtv/juju-core/session-certificate/+merge/170611
<mgz> looks reasonable to me jtv, though haven't read the prereq yet
<jtv> Thanks mgz â the prereq has landed by now
<mgz> ..prereq does seem to be merged? or did the bot blow up again
<jtv> It wasn't landed at the time I wrote that, but it s now.  :)
<mgz> jtv: you can just run `lbox propose -cr -v` in the branch now for the normal method then?
 * jtv decodes
<jtv> It's proposing...
<mgz> newTempCertFile is surprisingly manual, doesn't go help you with any of that?
 * mgz just looked up the implementation out of curiosity, as hadn't looked at the original mp for it
<jamespage> mgz, yes
<jamespage> (I'm lazy and did not specify one when setting up tenants for serverstack)
<mgz> jtv: hm, seems the rietveld proposal is still confused about something
<mgz> jamespage: thanks
<jtv> mgz: I was just updating the LP MP because it didn't get the link to the Rietveld MP.
<jtv> mgz: ouch...  lots and lots of diff!
<jtv> Maybe we can just stick with the native MP?
<jtv> I'm not too worried about the final merge, because that's going to be based on the LP diff not the Rietveld diff.
<mgz> I'd expect it to be correct, indeed
<mgz> jam/bot smarter than goetveld
<jtv> goetveld...  "goodfield"?
<mgz> don't expect the non-dutch to make sense when squidging dutch and english together :)
<jtv> Why on Earth not?
<jtv> Any backup reviewer for this branch?  The Rietveld MP got a little messed up, but the Launchpad one is good: https://code.launchpad.net/~jtv/juju-core/session-certificate/+merge/170611
<jtv> rogpeppe2 maybe?   ^
<jtv> (And thanks mgz for the first review :)
<rogpeppe2> jtv: if you merge trunk into the prereq and push it, then re-propose, it might sort out the rietveld problem
<rogpeppe2> jtv: obviously you'd need to pump the pipeline too
<jtv> I don't have a pipeline there actually.
<jtv> The prereq is already landed.  I had hoped that would make things simpler.
<mgz> merging trunk would probably work, though shouldn't really be needed again...
<jtv> I'll give it a go...
<mgz> I think the issue is basically goetveld doesn't understand three-way merges, at all
<jtv> Turns out there was a conflict, too.
<jtv> mgz, rogpeppe2: re-proposing updated version of my branch...  Fingers crossed!
<rogpeppe2> jtv: you've merged and pushed the prereq too, presumably?
<jtv> That was already landed.
<jtv> So implicitly that happened as well, yes.
<rogpeppe2> jtv: it doesn't matter
<rogpeppe2> jtv: lbox diffs against the branch that it finds in launchpad
<rogpeppe2> jtv: which won't have had trunk merged into it unless you did so explictly
<jtv> Ahhh
<rogpeppe2> jtv: despite the fact that it was merged *into* trunk itself
<jtv> Gotcha.
<jtv> I have a new Rietveld MP now, and it updated my Launchpad LP but kept the old (broken) Rietveld link.  So I updated manually.
<jtv> But get this: the two Rietveld MP ids are near-identical, with just one digit somewhere in the middle being different!
<jtv> Thanks mgz & rogpeppe2 for helping me out of this.  I'll have to leave now, but I'm in a better state.  :)
<rogpeppe2> jtv: that's much more common than you might think
<rogpeppe2> jtv: due to the way that rietveld allocates ids
<rogpeppe2> jtv: have you got a link?
<jtv> https://codereview.appspot.com/10447043
<jtv> (While I triple-check that I have the right one here :)
<rogpeppe2> jtv: that's much more like it! :-)
<jtv> Yup, much more modest size.
<jtv> I think I'll just delete the old one, before some poor passer-by tries to review it.
<jtv> (Very courageous of the Rietveld MP to have a Delete button with no Undo and no confirmation dialog! :)
<rogpeppe2> jtv: you have a review BTW
<jtv> Thanks!
<jtv> (Yes I know I said I was gone for the evening...  No backbone :)
<ahasenack> guys, is there some sort of timeout involved in this error?
<ahasenack> error: cannot put charm: cannot make Swift control container: failed to create container: juju-51e360f7f9cbfdf5d24fdb84aa0d4112
<ahasenack> caused by: failed executing the request https://swift.canonistack.canonical.com/v1/AUTH_850578306acb4f1baeaceae75ff7ada1/juju-51e360f7f9cbfdf5d24fdb84aa0d4112
<ahasenack> caused by: unexpected EOF
<ahasenack> I'm wondering because that particular charm has a big'ish tarball inside it, something like 6Mb
<ahasenack> I wonder if that is uploaded to the swift container
<ahasenack> (and I changed my control bucket id already, don't worry)
<rogpeppe2> yay, live test with machine agent connecting via the API worked!
<rogpeppe2> ahasenack: sorry, not sure i can help there without more info
<rogpeppe2> ahasenack: and it's eod for me
<rogpeppe2> see y'all tomorrow!
<ahasenack> rogpeppe2: ok, I'm looking through the code trying to find out where it defines timeouts for this connection
<rogpeppe2> ahasenack: it seems a little unlikely to be a timeout, but y'never know
<rogpeppe2> ahasenack: it might just be the underlying TCP connection failing
<rogpeppe2> ahasenack: i mean - unlikely to be a timeout that we've built in
<ahasenack> I'm getting that a lot recently
<ahasenack> I'll resort to tcpdump soon
<fwereade_> .
<thumper> morning
<thumper> fwereade_: would love a quick chat if you are up and bored
<fwereade_> thumper, hey, I'm really sorry, I am hyperfocused
<thumper> np
<fwereade_> thumper, and I haven't done any reviews :/
 * thumper is just reproposing the broker one with the right pre-req
<fwereade_> thumper, but I'm *this* close to nailing the destroy-services-quicker bug, and I think we can do it backward compatibly
<thumper> awesome
<thumper> fwereade_: quick question, I'm adding a job type for JobEnvironProvisioner, should I add one for JobFirewaller at the same time?
<fwereade_> thumper, those two are JobManageEnviron
<thumper> I know, now...
<thumper> do we want to keep them like that?
<fwereade_> thumper, task is more granular than job
<thumper> or break them out
<fwereade_> thumper, is the idea
<thumper> I could just shelve this bit and just use JobManageEnviron
<thumper> is that your suggestion?
<fwereade_> thumper, yeah, I think JobManageEnviron implies run-an-environment-provisioner
<thumper> kk
 * thumper removes pipe
<fwereade_> thumper, I guess that's one of the things that causes me to lean towards having more than one top-level task in play
<thumper> hmm...
<fwereade_> thumper, the task implementation is shared which is great
<fwereade_> thumper, but they're being run for different reasons
<thumper> fwereade_: you thinking that we rename provisioner to environ-provisioner
<thumper> and add one for lxc?
<thumper> if they are managed by the outer task runner
<thumper> it is certainly simpler
<fwereade_> thumper, I'm not 100% sure we'll need extra types for the lxc-provisioner
<fwereade_> thumper, I think that's just a task primed with the right watcher and broker
<fwereade_> thumper, the environ casehas extra funky watching so the actual provisioner is wrapped there
 * thumper nods...
<thumper> let me see if I can get this working
<thumper> I'll keep the multi-task runner the jujud bit itself
<fwereade_> cool
<fwereade_> I think it might work out quite neat
 * thumper goes to see what a machiner actually does
<thumper> arse
 * thumper needs to go back to refactoring the state info getter
 * thumper will test this version in ec2 to make sure the provisioner still works
 * thumper sighs
<thumper> forgot to upload tools
<thumper> at least my client works with 1.11.0 tools
<arosales> Dave C. around?
#juju-dev 2013-06-21
<thumper> wallyworld_: what is the watcher I look for for lxc containers on a machine?
<wallyworld_> thumper: machine.WatchContainers()
<thumper> wallyworld_: from state.Machine?
<wallyworld_> where machine is a machine object
<wallyworld_> machine is a state.Machine
 * thumper nods
<thumper> wallyworld_: umm... no
<wallyworld_> let me check, my memory has failed me perhaps
<thumper> no method there
<wallyworld_> / WatchContainers returns a watcher that notifies of changes to the lifecycle of containers on a machine.
<wallyworld_> func (m *Machine) WatchContainers(ctype ContainerType) *LifecycleWatcher {
<wallyworld_> in state/watchers.go
<wallyworld_> maybe that branch hasn't landed yet, let me check
<wallyworld_> thumper: no, it should be in trunk
<thumper> wallyworld_: which file?
<thumper> not in machine.go
<wallyworld_> ^^^^^^^^^^
<wallyworld_> state/watchers.go
<wallyworld_> if your IDE did method name completion.....
<thumper> WHY?
<wallyworld_> because that's where all the other watchers are defined
<thumper> I really strongly dislike splitting functions for types between different files
<thumper> it's dumb!
<wallyworld_> i just folllowed convention
<wallyworld_> blame the previous guy :-)
<wallyworld_> anyways, a good IDE makes it a moot point :-P
<davecheney> marcoceppi: ping
<marcoceppi> davecheney: o/
<davecheney> which method of communication would you like to attempt ?
<marcoceppi> How well does G+ work for you?
<davecheney> wfm, two secs
<davecheney> ARGH
<davecheney> thwere are two marcoceppi's who both work for canonical
<davecheney> and BOTH are well dressed !?!
<marcoceppi> davecheney: haha, you can hit either one of them
<marcoceppi> The one with the canonical bullseye is my "work" account
<davecheney> i'm going to choose the one with the best moustache
<davecheney> gameshow music ... dialing
<fwereade_> aw, wtf, how is that the time
<fwereade_> thumper, wallyworld_: despite my shameful failure to review any of your code today, I have one for you: https://codereview.appspot.com/10420045
 * wallyworld_ looks
<wallyworld_> just finishing another review firat
<thumper> huh
<wallyworld_> first
 * thumper needs beer
<thumper> or a wine
<thumper> perhaps something italian
<wallyworld_> whine?
<thumper> I'm getting frustrated at some of our tests
<fwereade_> thumper, wallyworld_: it is not the nicest of branches because it involves getting up to the elbows in state
<wallyworld_> :-(
<thumper> as soon as you add something that depends on what would be expected in a normal environment
<thumper> shit breaks
<fwereade_> thumper, wallyworld_: but code gets removed, tests get bigger, comments get more detailed, and buried in there are a couple of crucial lines that actually change behaviour
<wallyworld_> yep, that's Go for you
<fwereade_> thumper, wallyworld_: and all of those are, I believe, reflected explicitly in new test cases
<wallyworld_> fwereade_: cool. sounds good
<fwereade_> (oh, there are also 4 tests that fail elsewhere that I just saw, but it's obvious why in each case by inspection
<fwereade_> I'll fix them tomorrow)
<bigjools> Can we use Go 1.1 features yet?
<thumper> bigjools: no
<thumper> bigjools: see jam's email about it on juju-dev
 * bigjools doesn't pay much attention to that list
<bigjools> I guess I had better familiarise myself with the new features as the online Go docs refer to 1.1 now
<thumper> wallyworld_: http://paste.ubuntu.com/5785676/
<thumper> wallyworld_: less buggering around with this to get them going
<wallyworld_> \o/
<thumper> wallyworld_: although there is an 'orrible hack
<thumper> time.Sleep(1 * time.Second) :)
<wallyworld_> yuk
<thumper> wallyworld_: as the lxc provisioner tries to get the tools from state before the machiner has set them
<thumper> and the jujud process doesn't yet restart subtasks properly
<wallyworld_> sounds like we need a channel or something
<thumper> it will do when it integrates the worker runner code
<thumper> not really
<thumper> it should just die
<thumper> and get restarted
<thumper> don't add dependencies
<wallyworld_> instead of waiting on an event from the host saying "ready now" or something?
<thumper> I don't want to add extra dependencies right now
<thumper> I woner why instance-state says "missing" on status
<wallyworld_> what extra dependencies? adding a channel isn't a dependency except on the std lib
<thumper> but it is between go routines
<thumper> that shouldn't be tied together
<thumper> trust me on this one
<wallyworld_> ok
<thumper> with units: http://paste.ubuntu.com/5785689/
<wallyworld_> don't know about why instance state is missing
<wallyworld_> the code says it is because ec2 couldn't find that instance id
<wallyworld_> not ec2
<thumper> well, duh, obviously
<wallyworld_> our environment
<thumper> wallyworld_: what are you doing again?
<thumper> I'm about to write the end of week email
<thumper> apart from reviews
<thumper> and bug triage
<wallyworld_> OCR today. but main work is to get into state the instance metadata. there's a rework of the data model so it's become complicated
<wallyworld_> 3 failing tests - gotta fix the mega watcher
<wallyworld_> next step - machine characteristics in status
<wallyworld_> i'll also need to look at some other critical bugs thrown my way and the simple streams metadata
<bigjools> hey guys, if I want to include a data file as part of my source, and have it required at runtime, what's the best way of doing this?
<wallyworld_> what sort of file?
<bigjools> binary
<bigjools> it's a trailer for a VHD
<wallyworld_> you want the code to write it out somewhere when it runs?
<bigjools> no, it needs to read it and then we send it to Azure
<bigjools> (as part of other stuff)
<wallyworld_> i wonder if it shouldl be packaged in the tools tarball?
<bigjools> it's a jigsaw piece of a bigger file if you like
<wallyworld_> how big is it?
<bigjools> I need it to live in the provider library though, not juju core
<bigjools> 512 bytes
<bigjools> I'm wondering if there's a way of compiling the data in somehow
<wallyworld_> i'd maybe uuencode it
<bigjools> or base64
<wallyworld_> yeah
<bigjools> hmmm :)
<wallyworld_> and write it out
<bigjools> you're not just an ugly face
<wallyworld_> well, with enough beer perhaps
<bigjools> it would need a lot
<wallyworld_> sure, but you'd need more
<jam> bigjools: you can use "godoc" to run the docs locally, I believe. Which should match the version of go you are using.
<bigjools> jam: hey there.  ah yes I keep getting confused with godoc
<jam> bigjools: for a 512byte content, I would just base64 encode it in source. I think there is a way to get to argv[0] (not sure what it is in go), but there won't be a directory of files like python.
<bigjools> yeah base64 does the job nicely
<bigjools> 6+ years since I used a compiled language... it's slowly coming back
<jam> bigjools: for the test suite, there is stuff like "find the source directory", but that doesn't work as well in final binaries :)
<bigjools> yeah
<thumper> wallyworld_: your watcher returned the same id twice
<thumper> wallyworld_: when I removed it
<thumper> causing the provisioner to crash :)
<wallyworld_> \o/
<thumper> when it tried to stop the container the second time
<wallyworld_> i jut use a lifecycle watcher
<wallyworld_> i'll have to see what's going on with that
<thumper> wallyworld_: it is possible that it is me, I can add more tracing to check, but not today
<thumper> finishing early due to insane meetings last night
<wallyworld_> sure. i'm also knee deep in this other branch
<wallyworld_> hagw
<TheMue> morning
<rogpeppe2> thumper: ping
<rogpeppe2> TheMue: hiya
<rogpeppe2> wallyworld_: any chance of a review of https://codereview.appspot.com/10364046/ ?
<rogpeppe2> wallyworld_: (you reviewed the branch that had it as a prereq)
<wallyworld_> ok, but i'm onto my 3rd beer for the evening :-)
<wallyworld_> might improve the quality of my reviews :-)
<rogpeppe2> wallyworld_: thanks for the other review, BTW - the "password" oops was a good catch!
<wallyworld_> now worries :-)
<wallyworld_> no
<wallyworld_> rogpeppe2: done. btw, i got the watcher stuff sorted out thanks to your advice where to look
<rogpeppe2> wallyworld_: cool, nice one.
<rogpeppe2> wallyworld_: thanks
<wallyworld_> fwereade_: there are 2 untriaged bugs for juju-core which i didn't really feel i could accurately process today. ie they seem important to me but ymmv. could you possibly take a look sometime?
<fwereade_> wallyworld_, I hope so, I'm just trying to catch up on reviews this morning
<fwereade_> wallyworld_, thanks for your review last night
<wallyworld_> no hurry as such
<wallyworld_> np, i liked your branch
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: wallyworld | Bugs: 7 Critical, 74 High - https://bugs.launchpad.net/juju-core/
<rogpeppe2> fwereade_: would appreciate a review of https://codereview.appspot.com/10449044 - another prereq for getting the agent connected to the API
<fwereade_> rogpeppe2, looking
<fwereade_> rogpeppe2, lovely, LGTM
<rogpeppe2> fwereade_: thanks!
<fwereade_> rogpeppe2, if you get a mo, I'd appreciate your thoughts on https://codereview.appspot.com/10420045/
<rogpeppe2> fwereade_: looking
<TheMue> anyone interested in reviewing https://codereview.appspot.com/10441044 (config-get output)
<TheMue> ?
<TheMue> fwereade_: btw, had a chance to take a look on the ec2 http reader moving?
<fwereade_> TheMue, sorry, it's *right* at the bottom of the page
<fwereade_> TheMue, I'm on the 3rd last though
<TheMue> fwereade_: ok, no pro, i've got more in the queue so it can wait ;)
<fwereade_> TheMue, cool
<fwereade_> TheMue, I proposed something last night that'll fix a noticeable bug when the cleaner integration lands :)
<TheMue> fwereade_: oh, will take a look (when I return from lunch)
<rogpeppe2> fwereade_: so... just trying to get this straight in my head
 * fwereade_ braces himself for helpfully difficult questions ;)
<rogpeppe2> fwereade_: your CL changes things so that a service is only removed when the cleaner gets around to removing its units?
<rogpeppe2> fwereade_: i'm trying to understand the role of the cleaner here
<fwereade_> rogpeppe2, not exactly
<fwereade_> rogpeppe2, it just runs unit.Destroy for each unit sooner than the unit agents themselves will (potentially, anyway -- and usefully, in case cases where there's no agent inplay yet)
<fwereade_> rogpeppe2, the fundamental problem is that the UA was solely responsible for its lifecycle advancement past Dying once it was on a provisioned machine
<fwereade_> rogpeppe2, but there's really quite a long delay between a machine being provisioned and any assigned unit agents actually starting to run
<rogpeppe2> fwereade_: indeed there is
<rogpeppe2> fwereade_: so... why can't the initial operation run unit.Destroy when appropriate?
<fwereade_> rogpeppe2, checking the analysis captured in unit.Destroy is the big one, if that's crack then so is the whole idea
<fwereade_> rogpeppe2, the idea was that we didn't want to tie the client up destroying everything one by one
<fwereade_> rogpeppe2, and I think that's still reasonable
<rogpeppe2> fwereade_: ah, seems like a good plan
<rogpeppe2> fwereade_: i'd have asked the other way if you'd done it like that
<fwereade_> rogpeppe2, but I don;t really mind tying up the cleaner worker, that's its job
<fwereade_> ;p
<rogpeppe2> fwereade_: i think this is the right approach, but i just wanted to get it all straight in my head
<rogpeppe2> fwereade_: does the cleaner worker execute everything sequentially?
<fwereade_> rogpeppe2, yeah
<rogpeppe2> fwereade_: if not, i wonder if it might be good to make it execute some operations concurrently (assuming that gives some speed up) in the future
<fwereade_> rogpeppe2, sounds reasonable, yeah
<rogpeppe2> fwereade_: i can imagine that it might be really slow to destroy large services
<fwereade_> rogpeppe2, indeed, but don't forget the unit agents are still busily killing themselves where possible on service destroy
 * fwereade_ has food on the table
<rogpeppe2> fwereade_: that's true, but if you've accidentally typed an extra 0 onto --num-units and are trying to remove the service ASAP, it might be an issue
<rogpeppe2> fwereade_: enjoy!
<fwereade_> rogpeppe2, yeah, point taken, this is the simplest possible v1 of what will otherwise become a disturbingly big change
<rogpeppe2> fwereade_: oh yes, i wasn't suggesting we do it now
<rogpeppe2> fwereade_: or even in the near future
<rogpeppe2> fwereade_: just that it's something to bear in mind
<fwereade_> rogpeppe2, however, any that do manage to short-circuit will have to be executed serially anyway, because they all use the service doc
<rogpeppe2> fwereade_: not if there are two (or more) services being destroyed, i guess
<fwereade_> rogpeppe2, very true
<fwereade_> rogpeppe2, concurrent handling of actual cleanup docs themselves would be nice
<fwereade_> TheMue, LGTM
<rogpeppe2> fwereade_: yeah - otherwise this might tie up the cleaner for a long time when actually all the units are deployed and happy to remove themselves, stopping another service from being cleaned up.
<rogpeppe2> fwereade_: reviewed
<fwereade_> rogpeppe2, thanks, +1 on TransactionChecker, very nice
<rogpeppe2> fwereade_: cool
<fwereade_> rogpeppe2, yeah, the cleanup thing is pretty ghetto at this stage, at least it'll hopefully be relatively simple to massage into shape at some point
<fwereade_> rogpeppe2, but suboptimal cleanup beats no-cleanup-at-all pretty handily :)
<rogpeppe2> fwereade_: indeed so :-)
<rogpeppe2> TheMue: reviewed
<rogpeppe2> fwereade_: i don't think you published your TheMue LGTM
<rogpeppe2> TheMue: would appreciate a review of https://codereview.appspot.com/10449044
<rogpeppe2> or from anyone else, for that matter
<fwereade_> rogpeppe2, TheMue: I was thinking of https://codereview.appspot.com/10296046/ -- looks LGTMed to me
<rogpeppe2> fwereade_: ah, i thought you were referring to g https://codereview.appspot.com/10441044
<fwereade_> rogpeppe2, ha, missed that one, thanks
<rogpeppe2> TheMue: you have another review
<fwereade_> TheMue, reviewed https://codereview.appspot.com/10441044 as well
<rogpeppe2> fwereade_: do you know if live tests have been fixed now?
<fwereade_> rogpeppe2, I'm afraid I don't
<rogpeppe> fwereade_: :-(
<rogpeppe> fwereade_: i guess i'll try with trunk and see what happens
<rogpeppe> fwereade_: if i'm to land the agent API stuff, i really need to be able to test live
<fwereade_> rogpeppe, I have a vague recollection of flinging those at you for verification the other day
 * fwereade_ looks a little shamefaced
<rogpeppe> fwereade_: flinging what?
<fwereade_> rogpeppe,  a couple of bugs related to those
<fwereade_> rogpeppe, I may be wrong, that bug weekend is a bit of a blur
 * rogpeppe starts running TestBootstrapAndDeploy
<rogpeppe> fwereade_: you'll probably be happy to know i got the machine agent actually talking to the API live yesterday.
<fwereade_> rogpeppe, I saw! awesome news :D
<fwereade_> rogpeppe, you were gone before I saw it so I couldn't fling virtual underwear in appreciation
<rogpeppe> fwereade_: BTW we seem to have reverted to dialling more often than we should (about 3 times a second)
<fwereade_> rogpeppe, whaa? :(
<FunnyLookinHat> I'm trying to figure out how we might take advantage of the upcoming containerization feature... but I need to test density.
<FunnyLookinHat> Do you think it'd be a decent comparison to just bootstrap juju locally and deploy a bunch of nodes via LXC ?
<rogpeppe> fwereade_: ah, looks like live tests do work on trunk, phew
<fwereade_> rogpeppe, excellent ;p
<fwereade_> rogpeppe, would you open a bug for the redialing though please? feels like a bad bug to release with
<fwereade_> rogpeppe, so I think it's critical until we figure it out
<fwereade_> FunnyLookinHat, what are you looking to explore in particular?
<FunnyLookinHat> How much density I can get with lamp-stack deployments for a PHP + MySQL application
<FunnyLookinHat> fwereade_, i.e. I want to compare between simply having 100 virtual hosts on a single apache w/ a single mysql in separate directories w/ having 100 lxc container'd hosts including mysql
<TheMue> rogpeppe: reviewed
<rogpeppe> TheMue: thanks
<fwereade_> FunnyLookinHat, ok, so you're thinking, say, 1 node with N containers, each container holding one php app and one mysql?
<TheMue> rogpeppe, fwereade_ : thx for your reviews
<FunnyLookinHat> fwereade_, Yeah, exactly
<FunnyLookinHat> "Entire Stack" in each LXC - with the purpose of serving a single PHP application.
<FunnyLookinHat> I'm hoping that will make backup and restoration a breeze
<fwereade_> FunnyLookinHat, ok, cool -- this in contrast to 1 machine with N+1 containers, in which N hold a php app and one holds a single unit of a shared mysql service?
<fwereade_> FunnyLookinHat, yeah, that sounds sensible
<fwereade_> FunnyLookinHat, I know thumper has been making good progress there
<FunnyLookinHat> fwereade_, Sort of - yes.
<FunnyLookinHat> fwereade_, Yeah I saw his update this morning :)
<fwereade_> FunnyLookinHat, I have architecture quibbles but I expect they'll all come out in the wash
<FunnyLookinHat> fwereade_, Realistically I'm trying to figure out "how dense" juju will be able to get me, or if I need to figure something else out...  i.e. how much overhead is in LXC
<fwereade_> FunnyLookinHat, so I would *hope* that trunk will be letting you play with that manually within the next week or so
<FunnyLookinHat> fwereade_, but you're essentially saying that I'd be able to get a decent idea just by running LXC within a Compute Instance or something
<fwereade_> FunnyLookinHat, yep, makes sense, thanks
<fwereade_> FunnyLookinHat, I think so yeah
<FunnyLookinHat> fwereade_, Ok thanks - much appreciated :)
<fwereade_> FunnyLookinHat, the juju agents don't take up too many resources last time I checked
<FunnyLookinHat> Yeah - my only concern is running 250 mysql daemons and 250 apache daemons instead of 1 and 1
<FunnyLookinHat> That's a lot of overhead
<FunnyLookinHat> thus the need to test
<fwereade_> FunnyLookinHat, quite so
<rogpeppe> ha, don't accidentally type "go get -u" - you'll pull --overwrite your current repo. ouch.
<FunnyLookinHat> LOL
<wallyworld_> rogpeppe: my IDE has local history built in so when i did go get -u one time, it was easy to recover :-)
<rogpeppe> wallyworld_: i thought i'd interrupted it in time, but i hadn't. luckily i had another copy of the branch that i was using to test against go1.0.3. i've proposed https://codereview.appspot.com/10455043 to fix the issue.
<wallyworld_> oh cool :-)
<wallyworld_> mramm: hi, i almost have a fix for bug 1188815 ready to test. do you know what cloud the bug was seen with, and if i can get some credentials to do a live test?
<_mup_> Bug #1188815: security group on quantum/grizzly is uuid, goose chokes on it <serverstack> <Go OpenStack Exchange:Confirmed for wallyworld> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1188815>
<fwereade_> rogpeppe, responded to https://codereview.appspot.com/10420045
<fwereade_> rogpeppe, I would be interested if yu had any thoughts on the Cleanup-after-service-destroy-in-client idea
<fwereade_> rogpeppe, it's kinda nasty
<fwereade_> rogpeppe, *but* it means that new tools will do quick-destroys of old services in old environments
<fwereade_> rogpeppe, but then maybe we don't want to encourage people to keep their 1.10 deployments going, long-term..?
<mramm>  wallyworld_: I am not sure, it is whatever the Landscape team is using... Best to ask beret... He's online now.
<wallyworld_> will do
<Beret> ahasenack, can you lend wallyworld_ a hand with that one?
<wallyworld_> Beret: hi,  i almost have a fix for bug 1188815 ready to test. do you know what cloud the bug was seen with, and if i can get some credentials to do a live test?
<_mup_> Bug #1188815: security group on quantum/grizzly is uuid, goose chokes on it <serverstack> <Go OpenStack Exchange:Confirmed for wallyworld> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1188815>
<Beret> ahasenack, it's probably dpb that found it
<rogpeppe> fwereade_: i'm not sure exactly what idea you're referring to. is it mentioned in the comments? or are you just talking about our discussion earlier?
<ahasenack> hm?
 * ahasenack reads
<fwereade_> rogpeppe, it's at the end of the CL description
<ahasenack> wallyworld_: it was seen in our internal serverstack deployment, one that uses quantum for networking, not canonistack, which uses nova networking
<wallyworld_> ahasenack: any chance of getting some credentials so i can test the fix against that?
<rogpeppe> fwereade_: ah, i think i'd probably gone into "tl;dr" mode by that stage and had just dived into the code :-)
<fwereade_> rogpeppe, not surprised
<ahasenack> wallyworld_: I'll see what I can do, I'm not sure even I have credentials, that thing was just deployed
<fwereade_> rogpeppe, sorry about that
<wallyworld_> ahasenack: we have test service doubles i can test with, and also regression test against canonistack, but i want to be sure the issue is really fixed for you too
<ahasenack> wallyworld_: yeah, canonitsack will only help in terms of regression testing, since the bug doesn't happen there
<ahasenack> we need openstack with quantum for this
<wallyworld_> exactly
<rogpeppe> fwereade_: i think it's not worth calling Cleanup
<fwereade_> rogpeppe, cool
<fwereade_> rogpeppe, upgrade tools, upgrade environment, get fast destroys
<rogpeppe> fwereade_: precisely
<wallyworld_> ahasenack: see what you can do and drop me an email. it's late friday evening for me now so no rush as such. i've still got a bit of coding to finish on the issue and will try and get that done over the weekend so i can get a fix committed asap for you
<fwereade_> rogpeppe, gets people using the code we want them to too :)
<ahasenack> wallyworld_: where can I get a build/branch?
<ahasenack> wallyworld_: attached to the bug?
<rogpeppe> fwereade_: we have upgrade - people can use it (and they can downgrade too if there are problems)
<fwereade_> rogpeppe, if an upgrade has problems I fear for its downgrade too tbh
<wallyworld_> ahasenack: i'll commit the fix to goose trunk when it's done. it's still uncommitted on my harddrive
<ahasenack> wallyworld_: can you push somewhere, or would you like to test it first yourself?
<rogpeppe> fwereade_: hopefully the upgrade stuff doesn't touch much of the stuff that might be problematic for people
<rogpeppe> fwereade_: BTW i worked out why my second API-connecting machine agent wasn't working - the provisioner wasn't calling SetPassword on the new machine. fingers crossed this live test will work fine...
<wallyworld_> ahasenack: you can certainly pull from my lp branch once i push it up (before it is reviewed and committed to trunk). but i have a little coding work to finish first. it's about 80% done
 * fwereade_ also crosses fingers
<ahasenack> wallyworld_: ah, ok
<wallyworld_> ahasenack: i thought getting access to the cloud to test might take a little time so thought i'd ask ahead of time to minimise delays
<ahasenack> wallyworld_: ok
<wallyworld_> i was hoping to have access or something say monday :-)
<fwereade_> rogpeppe, yeah -- I just worry that there's some subtle incompatibility in the data that gets stored by the current code
<wallyworld_> ahasenack: i only started on the problem after my EOD today since it was marked as critical :-)
<wallyworld_> and i had other stuff to get done first
<ahasenack> wallyworld_: ok, thanks
<wallyworld_> even if i can't get access to the cloud, i'm pretty confident it will work if you grab the code and test
<rogpeppe> 8:04.529 PASS: live_test.go:0: LiveTests.TestBootstrapAndDeploy	479.767s
<rogpeppe> yay!
 * fwereade_ cheers, hoots, flings underwear
<fwereade_> hmm, plus.google.com hates me again today
<dpb1> wallyworld_: if you give a branch and tell me how to pull it, I can test it
<dpb1> wallyworld_: I'm running trunk in that cloud already, so it should be easy to update nad overlay your stuff
<wallyworld_> dpb1: awesome thanks. i'll have something done within a day. just finishing a bit more coding
<dpb1> wallyworld_: ok, I'm in the US Mountain Time, so if you get something finished before I eod, I'll look at it.
<wallyworld_> dpb1: i'm GMT+10 so it's midnight here and i may not stay awake to get it done. i can send you an email over the weekend with the branch details. i'm really hopeful of getting it done real soon now
<fwereade_> ffs
<dpb1> wallyworld_: hehe, ok, goodnight then (or close to it!)
<fwereade_> sorry guys, didn't contribute much there
<fwereade_> TheMue, how's the worker integration looking?
<dpb1> wallyworld_: given your nick, I was wondering if you were down under.
<wallyworld_> dpb1: good night
<wallyworld_> yep, am in brisbane australia
<dpb1> wallyworld_: ah, cool. :)
<fwereade_> gaah -- has anyone tried to --upload-tools from current trunk? I'm assuming that the problem is that my network appears to be very flaky today, but it'd be nice to have confirmation that it really does work
<TheMue> fwereade_: not yet started, currently working on the review feedback for config-get
<fwereade_> TheMue, ok, it's become critical for me -- shall I try and pick it up?
<fwereade_> (btw, just managed to --upload-tools -- it's not you it's me)
<rogpeppe> fwereade_: it worked fine for me earlier
<fwereade_> rogpeppe, cheers
<TheMue> fwereade_: ok, feel free to pick it, then i'll do auto sync tools next
<TheMue> fwereade_: in your review of the config-get you said it's a good opportunity to change the way of the format comparison
<TheMue> fwereade_: could you explain it more?
<fwereade_> TheMue, asserting on precise bytes is not great, because YAML can produce all sorts of valid representations of the same data
<fwereade_> TheMue, we would like it if, were we to (say) tweak the formatting details in cmd/out.go, these tests would continue to pass
<fwereade_> TheMue, so, rather than asserting precise output, unmarshal that output and compare against the actual data you expect
<fwereade_> TheMue, it's not foolproof, though, the precise numeric types might be unmarshalled differently by different implementations, say -- but I'm less worried about that
<fwereade_> TheMue, sane?
<TheMue> fwereade_: ah, thx, then i had it already understood right
<TheMue> fwereade_: yes, so i can continue as i already started. it's the final change before a repropose :)
<fwereade_> TheMue, sweet
<fwereade_> TheMue, can I ask you to do a quick proposal before you do auto sync tools please? I think it demands a little bit of discussion
<TheMue> fwereade_: a quick proposal? you mean for the way i will do it?
<fwereade_> TheMue, yeah, I think it deserves just a little thought before we rush in
<TheMue> fwereade_: sure, will come back to you first when read a bit more about the problem
<fwereade_> TheMue, just to figure out the drawbacks of whatever we pick and whether they're worth it
<TheMue> fwereade_: sounds fine to me, yes
<rogpeppe> i'm getting a compile problem trying to merge: https://code.launchpad.net/~rogpeppe/juju-core/325-machineagent-api-setpassword/+merge/170788/comments/380527
<rogpeppe> it's really weird, because it builds fine locally
<rogpeppe> and i tried pulling trunk and merging into that and it still builds fine
<rogpeppe> mgz: any ideas what the problem might be?
<rogpeppe> particularly annoying because it's preventing me from proposing my agent-connects-to-state branch
<rogpeppe> jam: ^
<TheMue> assignement count mismatch, aha
<TheMue> how do those lines look like?
<TheMue> ...oooOOO( before navigating through the code )
<rogpeppe> TheMue: ha ha, they're still wrong.
<rogpeppe> TheMue: it *built* fine, but tests don't
<mgz> rogpeppe: not off the top of my head...
<mgz> ah, tests fail on the merged code?
<rogpeppe> mgz: yeah. i think i've sorted it though. there must've been a problem with tests failing after merging with trunk. i was sure i'd tested it properly. but there y'go
<rogpeppe> right, another 15 minute wait
<rogpeppe> fwereade__: ping
<fwereade__> rogpeppe, pong
<fwereade__> rogpeppe, how's it going?
<rogpeppe> fwereade__: i've got a bit of a testing problem
<fwereade__> rogpeppe, oh yes?
<rogpeppe> fwereade__: i just propose -wip'd my branch (after endless hassles with dependencies)
<rogpeppe> fwereade__: and going through it, i saw a test-related hack i'd forgotten about
<rogpeppe> fwereade__: which is a time.Sleep(2 * time.Second) inside runStop (this is in cmd/jujud)
<rogpeppe> fwereade__: this is when testing the password changing stuff
<rogpeppe> fwereade__: the issue is that we don't have any way of knowing *when* the agent changes the password
<fwereade__> rogpeppe, hmm... poll the conf file for changes?
<fwereade__> rogpeppe, except I can't remember whether that happens before or after
<rogpeppe> fwereade__: hmm, i thought of that and wrote it off because i thought there were cases where we don't actually change the conf file
<fwereade__> rogpeppe, surely we do if we're changing the password?
<rogpeppe> fwereade__: there are several checks in that test
<rogpeppe> fwereade__: but actually, i think the conf file is changed in all of them
<rogpeppe> fwereade__: which probably means it's not an adequate test, ironically
<fwereade__> rogpeppe, how about a watcher on the state.Unit, waiting for the old password to give an error?
<rogpeppe> fwereade__: too specific - sometimes it doesn't actually change the password even though it changes the conf file
<rogpeppe> fwereade__: i think i'll go with polling the conf file and see if that works ok
<fwereade__> rogpeppe, if it's tricky to test, I may be hearing the extract-type bells ringing a little
<rogpeppe> fwereade__: you know, actually i think you're right - i'll just test openAPIState in isolation. there's no particular virtue in testing it in situ, as the other tests would fail if it wasn't being called.
<fwereade__> rogpeppe, cool
<rogpeppe> fwereade__: thanks for the suggestion
<rogpeppe> fwereade__: https://codereview.appspot.com/10259049/
<rogpeppe> fwereade__: (finally!)
<rogpeppe> if anyone's still around, i'd appreciate a review of the above
<rogpeppe> and that's a good place to stop for the week.
<rogpeppe> see y'all monday!
#juju-dev 2013-06-23
<rogpeppe1> jam: hiya
<jam> hi rogpeppe1
<rogpeppe> jam: i was just thinking about your "single watcher for multiple agents" remark and wondering how you thought it might work
<jam> rogpeppe: on the client side, when you get an event from Changes it includes the context of what thing was changing.
<rogpeppe> jam: i'm talking about the watcher at the API level here, not the watcher on the state directly
<rogpeppe> jam: usually it doesn't
<rogpeppe> jam: e.g. the result from an EntityWatcher is struct{}
<rogpeppe> jam: it's true that if you want to watch multiple things, you'd probably need to interpose an intermediate goroutine to add the context
<jam> rogpeppe: right, I don't intend to use the EntityWatcher model, because the only thing we are watching is a state.Tools which is a small compact thing. It seems perverse to send an empty "something changed" rather than sending the actual 100 bytes of what changed.
<rogpeppe> jam: sure, that's fine
<rogpeppe> jam: what other watchers *do* include the context of what thing was changing?
<jam> rogpeppe: LifeCycleWatcher returns an array of things that changed, though I guess not what they changed to?
<jam> I mentioned it with fwereade__, and he seemed fine with it.
<jam> I can see for things you are worried about convergence, you want an event to go check there is something new.
<rogpeppe> jam: LifecycleWatcher doesn't tell you what collection of things you're watching (which is the equivalent)
<rogpeppe> jam: i think that sending the state.Tools is fine
<rogpeppe> jam: i don't think it's worth sending the Id though
<rogpeppe> jam: especially since i can't imagine a scenario where an agent is watching many things for tools changing, and even if it did, it's easy to work around.
<rogpeppe> jam: it's also easy to add the id at the client side if we want
<rogpeppe> jam: we already have an intermediate goroutine that calls Next and sends on the channel which has info about the id being watched
<rogpeppe> jam: it could easily add its local knowledge of the id to the channel without it needing to go across the network
<rogpeppe> jam: does that make sense?
<jam> rogpeppe: but why do you need N goroutines watching N watchers when you could have 1 goroutine watching 1 watcher watching N things?
<rogpeppe> jam: the upgrader is only watching one thing, right?
<jam> rogpeppe: the API is intended to allow you to watch more than one thing if you ask for it.
<jam> ATM it probably only watches one.
<jam> But why explicitly limit it
<jam> when it isn't that hard to have it do more
<jam> with the only "overhead" that the Change event includes slightly more context.
<rogpeppe> jam: ah, i see, you want the bulk call to return a single watcher for all the things being watched
<jam> rogpeppe: that was the idea, yes
<rogpeppe> jam: i see. that could work. except that it's probably more code (you have to keep track of more stuff at the server side, i think) and as with most of the bulk call stuff, i cannot think of any possible future scenario where we might possibly actually use this functionality.
<rogpeppe> jam: the whole point of this watcher is for a single entity to ask to be notified of its new tools. why would we ever want to watch multiple things? ok, i see (well i don't, but i go along with it) that for reasons of "habit", we make the initial Watch call a bulk call, but it's simpler, less code, easier to understand and just as general to return a watcher for each id (and in practice we'll only ever have one) than a single watcher that
<rogpeppe> watches many things.
<rogpeppe> jam: it's probably not even going to be measurably less efficient
<jam> rogpeppe: except if you ever want to transition to the case of more-than-one-thing you have to go into a fairly complex "create a bunch of goroutines adding context into a single channel", when a watcher that watches multiple things naturally handles all of that for you.
<rogpeppe> jam: that assumes that you have a single goroutine wanting to see changes on all those entities, of course.
<rogpeppe> jam: my visceral reaction is YAGNI here
<rogpeppe> jam: i think it will be much easier to write the server side if a Next call is looking up tools with respect to a single entity.
<rogpeppe> jam: hmm, maybe it's not too bad. here's a sketch of how Next might work at the server side in each case: http://paste.ubuntu.com/5791950/
<rogpeppe> jam: you might want to have a single state watcher shared by the whole API server that watches the global version number.
<rogpeppe> jam: there are some interesting questions about the best way to send the info to all the watchers
<rogpeppe> jam: something like this might turn out to be useful: https://code.google.com/p/rog-go/source/browse/values/values.go
<jam> rogpeppe: what is wrong with my logic for AgentVersion ?
<jam> A user requests an upgraded version
<jam> that sets the global version
<jam> Machine agents notice
<jam> upgrade
<jam> when the upgrade finishes
<jam> they save their current actual version
<jam> Unit agents notice when their Machine agent versions upgrade
<jam> and they go to upgrade
<jam> You're right that if we want to do canary upgrades, we'd need a separate field.
<jam> Though we can make the API be "what version do you want me to be", and the first implementation just watches the global field.
<jam> And future versions can change that in a perfectly compatible manner. (I think)
<rogpeppe> jam: yes, that last seems good to me (but just thinking through the implications)
<jam> rogpeppe: some of this is more on the "lets make sure we can do what we think we need to" rather than "lets do this right now".
<rogpeppe> jam: +1 to that
<rogpeppe> jam: upgrades will be marginally slower (two poll intervals rather than one) but other than that, i can't think of any down sides.
<rogpeppe> jam: especially since every container is now a "machine", so we know that only one piece of code has the responsibility for actually downloading stuff.
<jam> rogpeppe: if you're still around, any idea why the last patch set of https://codereview.appspot.com/10437043/#ps2001 includes 'azure' changes?
<rogpeppe> jam: if you do a diff between two patch sets, it'll show you the actual diffs between the two branches
<rogpeppe> jam: and that has many changes because i'd merged trunk between the two
<rogpeppe> jam: but...
<jam> rogpeppe: sure, by why when you merged trunk didn't the updated diff be computed against trunk again? (I guess this is a difference between how LP computes diffs, and how lbox does)
<rogpeppe> jam: i don't see that happening here
<rogpeppe> jam: there's only one patch set, and i don't see any azure changes
<jam> rogpeppe: https://codereview.appspot.com/10437043/#ps5002
<jam> (same CL, next patch set
<jam> Patch Set 2 looks quite sane to review.
<jam> Patch set 3 has lots of unrelated changes.
<rogpeppe> hmm, weird
<rogpeppe> jam: probably because i hadn't merge trunk to the prereq
<rogpeppe> merged
<jam> something like that sounds reasonable.
<jam> prereq + merge trunk can make lbox confused
<jam> Launchpad does prereq's differently than lbox
<rogpeppe> one mo, i'll sort it out
<jam> rogpeppe: you don't have to spend a lot of time. the "I merged trunk" is a sufficient answer.
<jam> I don't think you did much in your responses, I was just following along.
<jam> And didn't think you did lots of Azure changes in response to feedback :)
<rogpeppe> jam: i didn't. and i can't sort out the CL now
<rogpeppe> jam: "error: Failed to send patch set to codereview: diff is empty"
<rogpeppe> jam: unsurprisingly
<jam> rogpeppe: right, because your patch has landed
<jam> oh well
<jam> np
<rogpeppe> jam: if you're in reviewing mode, i'd appreciate your thoughts on https://codereview.appspot.com/10447047/
<rogpeppe> jam: and also https://codereview.appspot.com/10259049/ (i know william's commented already, but the more eyes the better)
<jam> rogpeppe: golang question. How is it possible that net/fd.go defines a "netFD" struct, which is also defined by "fd_windows.go".
<jam> I think I understand the 'compile only modules that have _$GOOS' on the appropriate platform
<jam> does doing that override types that are defined in the root x.go file ?
<rogpeppe> jam: i don't see a file fd.go
<rogpeppe> jam: i only see fd_$GOOS.go
<rogpeppe> jam: for GOOS in {bsd, plan9, unix, windows}
<jam> rogpeppe: is that go-1.1 vs go 1.0.3?
<jam> because I clearly see src/pkg/net/fd.go
<rogpeppe> jam: perhaps; are you looking at go 1.0.3
<rogpeppe> ?
<rogpeppe> jam: i'll check there
<jam> rogpeppe: right. And: grep -rnI "type netFD" returns 2 locations. One in 'fd.go' and one in 'fd_windows.go', but no definitions in fd_linux.go etc.
<rogpeppe> jam: ah, in 1.0.3, the build constraints on fd.go are: // +build darwin freebsd linux netbsd openbsd
<rogpeppe> jam: that doesn't include windows
<jam> rogpeppe: so the magic '+build' comment
<rogpeppe> jam: yeah, and it looks like x_$GOOS.go might be treated specially
<rogpeppe> jam: which i'd forgotten about - a bit of a possible gotcha
<rogpeppe> jam: ah yes: http://paste.ubuntu.com/5792362/
<rogpeppe> jam: that's a good reason to avoid underscores in filenames unless using them for magic (e.g. _test.go)
<rogpeppe> jam: see go doc go/build for the lowdown
<jam> rogpeppe: sure, I knew about the _windows magic, as I've seen it quite a bit. I didn't know about +build
<rogpeppe> jam: ah!
<rogpeppe> jam: i knew about +build but had forgotten about the _windows magic :-)
<jam> I've probably seen more _amd64 magic.
<rogpeppe> jam: // +build ignore
<rogpeppe> jam: is quite useful sometimes
<rogpeppe> jam: for commenting out a file
<jam> rogpeppe: also, lbox doesn't compile on Windows because goetveld only has a 'terminal_linux.go' module,
<rogpeppe> jam: i don't see that
<rogpeppe> jam: i'm looking at revno 39 of goetveld
<rogpeppe> jam: which i just go got
<rogpeppe> jam: hmm, maybe i'm looking at a different tree. i can't see any terminal_linux.go in the revision history
<jam> rogpeppe: I have a version of goetveld that has a patch from Dave Cheney which renames terminal.go => terminal_linux.go and adds terminal_darwin.go
<jam> terminal.go itself doesn't compile on Windows
<rogpeppe> jam: ah
<jam> because it uses syscall.Termios functionality
<jam> that doesn't exist
<rogpeppe> jam: it would be easy enough to mock up a portable version of readPassword
<rogpeppe> jam: that didn't bother turning echo off
<jam> probably
<rogpeppe> jam: at least that would be a stand-by
<jam> it is trying to do direct-to-terminal with-no-echo which I understand is useful for passwords.
<jam> I tried to do something (because I was doing some juju work on Windows for enablement)
<jam> but I sort of gave up.
<rogpeppe> jam: yeah, it's useful but not essential
<rogpeppe> jam: you can always make sure there's noone else in the room :-)
<rogpeppe> jam: it should really take a *File rather than the fd
<rogpeppe> jam: the portable version could print a warning: "WARNING: your password will not be hidden when you type it"
<jam> rogpeppe: it looks like you might be able to use 'conio.h' and getch(): http://stackoverflow.com/questions/6856635/hide-password-input-on-terminal
<jam> though I don't really know how to get access to that without cgo.
<jam> Anyway, not my primary concern today :)
<rogpeppe> jam: it sounds like echo is off by default in windows
<jam> rogpeppe: I think 'getch' == characters with no echo, 'getc' is characters with echo from Posix.
<jam> rogpeppe: http://msdn.microsoft.com/en-us/library/078sfkak%28v=vs.80%29.aspx
<rogpeppe> jam: the os package has special code to invoke ReadConsole under windows. i wonder if you just called syscall.Read, it might work with no echo
<rogpeppe> jam: or this http://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx
<rogpeppe> jam: but unfortunately syscall has GetConsoleMode but not SetConsoleMode
<jam> rogpeppe: I thought there was a non-cgo way of grabbing functions from kernel32.lib
<rogpeppe> jam: it's possible
<rogpeppe> jam: i haven't used go on windows at all
<jam> rogpeppe: at least, ISTR reading some other go code that didn't need cgo in order to call some windows API stuff. but maybe it just used the already exported syscall functions.
<rogpeppe> jam: yeah, i think you can probably use syscall.Syscall directly
<rogpeppe> jam: it's a pity that modkernel32 isn't exported, but perhaps it doesn't matter
<jam> rogpeppe: well, it looks like you could always directly call syscall.LoadDLL() if you really wanted.
<rogpeppe> jam: yeah, my reading of http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx is that it will be idempotent
<rogpeppe> "
<rogpeppe> something about "where is
<rogpeppe> this variable coming from" that I find hard to read with our current
<rogpeppe> idioms
<rogpeppe> "
<rogpeppe> jam: do you use emacs?
<jam> rogpeppe: vim
<rogpeppe> jam: ah
<jam> rogpeppe: I can use ctags + "^]" to go to a tag definition
<rogpeppe> jam: if you were using emacs, there's a plugin that uses my godef tool
<jam> it is still very 'somewhere else in this package you might find something'
<rogpeppe> jam: which is much much better than ctags
<rogpeppe> jam: it takes you *precisely* to the definition
<rogpeppe> jam: even if you click on "z" in the expression like f().x.y.z and z is defined as a field in many paces
<rogpeppe> places
<rogpeppe> jam: it might not be too much hassle to fit it into vim, though i'm not at all familiar with vim-as-programming-language
<jam> rogpeppe: there was a vim runnig-a-server-to-get-definitions program that I used for a while a year ago, but then I stopped doing go for a while and it isn't packaged so I haven't tracked it down again.
<rogpeppe> jam: http://godoc.org/code.google.com/p/rog-go/exp/cmd/godef
<jam> rogpeppe: https://github.com/nsf/gocode
<jam> That one does autocomplete on '.' sort of things.
<rogpeppe> jam: i think that did code completion but not definition finding AFAIR
<rogpeppe> jam: godef could theoretically be used to do code completion too
<rogpeppe> jam: as it knows about member names
<rogpeppe> jam: its dark side is that it's written against an ancient fork of the go parser
<rogpeppe> jam: some time i intend to make it use go/types, but "in my copious spare time"
<rogpeppe> jam: for the moment i use it constantly and it works in 99% of cases
<rogpeppe> jam: (and it's pretty instantaneous - runs in ~10ms)
<jam> rogpeppe: so that is your "rog-go/exp/go/ast' stuff?
<rogpeppe> jam: yeah
<rogpeppe> jam: it does symbol resolution at ast-construction time
<rogpeppe> jam: which is *almost* but not quite possible in general
<rogpeppe> jam: rather, it's not possible without reading all the imports, which i didn't want to do
<rogpeppe> jam: and that's made worse by import to .
<rogpeppe> jam: which godef doesn't support (probably its main limitation)
<thumper> ah fark...
#juju-dev 2014-06-16
<davecheney> menn0: none
<davecheney> menn0: actually, none, but i'm sure someone else will have 100% opinion on it
<davecheney> ask the juju plugin writers
<davecheney> they parse status
<menn0> davecheney: k thanks
<waigani> menn0: can I give you a call?
<thumper> menn0: given that the error is going to be on unit wordpress/0 (say), the error text of "mysql-relation-changed with mysql:server" seems clear
<thumper> I don't have a strong preference on the "for" vs. "with" bikeshed
<thumper> but I think the wordpress:mysql bit is superfluous when on the wordpress unit, and the relation will be 'mysql-relation-chagned;
<wallyworld_> axw: hiya, in amongst the az work for openstack, are you also able to look at the e2 startup issues due to az? it seems to me we want this fixed for 1.20 also?
<axw> wallyworld_: yeah I will look at both
<axw> wallyworld_: OpenStack one is pretty trivial
<axw> ec2 not so much
<wallyworld_> thank you. and thanks for the +1 on my mongo fuk up fix
<axw> nps, sorry I missed it before
<axw> I think I reviewed that..
<wallyworld_> huh? you didn't miss anythng
<axw> maybe I just looked at it
 * axw shrugs
<wallyworld_> yeah, but why would we think we wanted clusteradmin on a non admoin user?
<wallyworld_> i think we've got stuff to fine tune with our user mgmt
<wallyworld_> and no unit tests failed
<wallyworld_> axw: if there's no bug already for the e2 az stuff, can you raise one when you have a moment and assign to the 1.19.4 milestone? i'd mark it as critical
<axw> wallyworld_: I raised one for each last night
<axw> wallyworld_: marked OS as critical, EC2 as high - will change
<wallyworld_> ok. sorry, i didn't see it on the milestone, i'll chek my eyes :-)
<wallyworld_> i think critical because bootstrap doesn't "just work" anymore
<wallyworld_> it failed  for me this morning
<waigani> thumper: that was it! ugh $#%#3 so frustrating
<menn0> thumper: thanks. I think you're right. I also thinking including both endpoints can make the status output quite long especially if the charm and interface names are long.
<menn0> waigani: sorry, I was out for a bit and only just saw your messages. Do you still want a call?
<waigani> menn0: no, all good, thanks anyway
<menn0> waigani: great
<waigani> thumper: is there a convenience method for errors.New(fmt.Sprintf(...))
<axw> wallyworld_: what region are you using? us-east-1?
<thumper> waigani: errors.Errorf
 * thumper otp
<waigani> thumper: sweet, cheers
<wallyworld_> axw: us-west-1
<axw> ta
<waigani> menn0: responded to your review, new code up
<menn0> waigani: otp
<menn0> waigani: will look soon
<menn0> waigani: I'm done with the review
<waigani> menn0: otp
<davecheney> thumper: https://github.com/juju/juju/pull/103 and https://github.com/juju/names/pull/5
<davecheney> as discussed
<waigani> menn0: ping
<menn0> waigani: just responded privately
<waigani> oh did I miss the card sizing ?
<jam> morning all
<menn0> waigani: no. it's probably happening tomorrow
<menn0> jam: morning
<jam> morning menn0
<wallyworld_> jam1: what's the state of bug 1319694, marked as in progress against the 1.19.4 milestone?
<jam1> wallyworld_: that one might actually be done, I'll investigate and get back to you
<jam1> I miss mup
<jam1> _mup_: poke
<wallyworld_> yeah
<dimitern> jam1, i'm getting sso errors trying to login
<dimitern> jam1, let's use mumble instead?
<jam1> dimitern: I have to install it again, give me a sec
<dimitern> jam1, i can't login to mumble as well :(
<jam1> dimitern: well, sso is probably used for both, fwiw
<dimitern> jam1, yep
<jam1> dimitern: do you have a personal gmail account?
<jam1> well, google account
<dimitern> jam1, yes, trying that now
<jam1> wallyworld_: fix committed for bug #1319694
<wallyworld_> great :-)
<jam1> at least the specific dataDir part of that bug is committed, and the rest is in the branches I've put up for review, but can easily be treated as something separate.
<jam1> dimitern: I just invited your personal account
<wallyworld> axw: i have an errand tonight, did you have time for a quick standup now?
<axw> wallyworld: sure, be there in a moment
<wallyworld> kk
<axw> wallyworld: https://plus.google.com/hangouts/_/gzksidi5kx4jxzf6qty6lf56iqa?authuser=1&hl=en
<wallyworld> ok, i was in the normal one
<axw> ah I can come
<axw> heh I think we just switched.. I'm in tanzanite now
<voidspace> morning all
<menn0> voidspace: morning!
<voidspace> menn0: o/
<axw> wallyworld: thanks, I was able to repro with the shared credentials
<mattyw> axw, dimitern fwereade can I get another review for https://github.com/juju/juju/pull/64 when one of you has a spare moment?
<axw> mattyw: done
<jam> fwereade or dimitern: I'd like to run a design thing past you about the Client side code for API versioning. It might be most appropriate to talk about it in a hangout, though hopefully it won't take super long.
<dimitern> mattyw, sorry, axw was faster :)
<dimitern> jam, sure
<fwereade> jam, I am making a much-belated effort to be dark and just write some damn specs today -- dimitern, can I dump it on you please
<dimitern> fwereade, jam, np, dump away :)
<jam> dimitern: https://plus.google.com/hangouts/_/canonical.com/dimiter-john
<mattyw> axw, I guess you just mean remove the commented line I guess?
<axw> mattyw: yes please
<mattyw> axw, thanks very much, and then you think it's ok to land?
<axw> yes I think so
<perrito666> rogpeppe1: hi by any chance you got time to take another look to restore?
<rogpeppe1> perrito666: np. will do
<perrito666> rogpeppe1: tx a lot, sorry I really need that landed :)
<rogpeppe1> perrito666: can you remind of the PR please?
<rogpeppe1> perrito666: https://github.com/juju/juju/pull/79 ?
<perrito666> https://github.com/juju/juju/pull/79
<perrito666> yup sorry
<perrito666> had to look it up :)
<rogpeppe1> perrito666: i'm still concerned that this code has never been tested for real
<perrito666> rogpeppe1: after voidspace can merge it with his part I can run a test I "borrowed" from CI but as is is a bit hard
<rogpeppe1> perrito666: yeah, i guess so. it can always be fixed when the logic becomes integrated
<perrito666> rogpeppe1: previous backup was easier to try since it was a standalone script
<mgz> axw: know if wallyworld is back around yet?
<voidspace> perrito666: it won't be long before we can test it
<voidspace> perrito666: api is done, api client is basically done
<voidspace> it needs restore to test it *properly* of course
<perrito666> voidspace: tecnically not :) I made it so it is compatible with current restore :)
<voidspace> ah, cool
<voidspace> even better
<voidspace> perrito666: it could be possible to have an "end-to-end" test today then
<axw> mgz: sorry, was afk. I think he said he'd be back around 8:30 his time, which is in 15m
<mgz> axw: ta!
<axw> jam1: are you CLA-savvy? https://github.com/juju/cmd/pull/2 can be merged without signing right? since it's just a teeny bug fix
<axw> mgz: or you? ^^
<mgz> axw: we *have* merged similar contributions in the past
<mgz> I'm not really sure you can argue it's trivial though
<mgz> kind of mp I love though, adds a failing test, fixes bug
<voidspace> it's 8 lines of code
<voidspace> I would think that counts as "trivial" (even if technically astute)
<rogpeppe1> axw: is there a reason we couldn't just do a normal type switch in FormatSmart?
<axw> rogpeppe1: I didn't even look
 * axw looks
<axw> rogpeppe1: well you can't do a type-switch on a string array if you don't know the length
<axw> apart from that one case, it'd be fine
<rogpeppe1> axw: ah, good point
<rogpeppe1> axw: and we do actually pass in string arrays to FormatSmart?
<axw> rogpeppe1: I'm wondering that myself - seems unlikely
<axw> though that is what the bug fix is for...
<mgz> not panicing seems worthwhile even if current callers don't do that
<perrito666> rogpeppe1: tal
<axw> I'm gonna merge it, we can look at making it non crappy later
<rogpeppe1> mgz: yeah, on reflection, i tend to agree
<rogpeppe1> mgz, axw: although, thinking about it, that code can still panic
<axw> ? :(
<mgz> quiff smilie!
<rogpeppe1> axw: i think the test probably needs to be if v.Type().Elem().Type() == reflect.TypeOf("") {
<axw> uh yeah, typed string
<axw> named
<rogpeppe1> yeah
<rogpeppe1> axw: same with the others actually
<mgz> moar tests needed
<rogpeppe1> axw, mgz: well, according to the docs, arrays are not supported
<mgz> can we just panic("no arrays") at the top then?
<mgz> I don't like un-coded preconditions to functions
 * perrito666 has to chain a displayport adapter to a thuderbolt adapter to ensure noise filtering.... I am back in the 90s
<mgz> perrito666: you bought the wrong kind of computer :)
<rogpeppe1> mgz: na, we could just delegate to FormatYaml as documented
<rogpeppe1> mgz: the docs specifically mention []string
<perrito666> mgz: I think the problem, this time, lies in the $1 cable and the $2 adapter
<perrito666> :;p
<wallyworld> mgz: hi, just got back, having sinner, will ping you soon
<wallyworld> dinner
<mgz> ehhe
<dimitern> jam1, vladk, standup?
<jam1> brt
<rogpeppe1> mgz, axw: i suggest we keep things simple and change the implementation to this: http://paste.ubuntu.com/7652447/
<rogpeppe1> mgz, axw: which corresponds more directly to the docs
<mgz> rogpeppe1: that's deliberatly getting yaml to do the int/float case?
<rogpeppe1> mgz: yeah - which the current code does too
<mgz> seems fair then
<rogpeppe1> mgz, axw: just checking that all the cmd/juju tests pass with that - i'm pretty sure they will
<rogpeppe1> yeah, they do
<rogpeppe1> i'll propose an alternate PR
<rogpeppe1> hmm, it's already merged
<rogpeppe1> axw, mgz: https://github.com/juju/cmd/pull/3
<perrito666> voidspace: I made the changes suggested and triggered the merge
<voidspace> perrito666: awesome
<wallyworld> mgz: hiya, wanna join the standup hangout?
<perrito666> voidspace: merged
<wwitzel3> fwereade: https://github.com/juju/juju/pull/2
<voidspace> wwitzel3: hey, morning
<wwitzel3> voidspace: morning
<voidspace> gah, just wasted 20 minutes merging and resolving conflicts on the wrong branch
<voidspace> damn confusing names
<voidspace> my own fualt
<voidspace> *fault
<voidspace> perrito666: integration *slightly* more than two lines of code as I need admin password and mongo port
<voidspace> perrito666: will finish after lunch
 * voidspace lunches
<rogpeppe1> perrito666: re: "Done, I went with ReadAll, although I was under the impression that Read would read len(b)", see http://golang.org/pkg/io/#Reader
<rogpeppe1> perrito666: in particular: "Read reads up to len(p) bytes into p"
<rogpeppe1> perrito666: it is even possible for it to return zero bytes, tho' that's discouraged
<perrito666> rogpeppe1: the "up to" part is what worried you, right?
<rogpeppe1> perrito666: yeah - there's no guarantee that Read returns any given number of bytes
<rogpeppe1> perrito666: if, for example, you're reading from the network, it's quite common for reads to return too few bytes
<rogpeppe1> perrito666: it's also not uncommon for it to happen when the underlying reader is using a buffer
<rogpeppe1> perrito666: that's why io.ReadFull exists
<mgz> was about to ask about SIGINT then remembered we weren't in c
<perrito666> mgz: lol
<rogpeppe1> mgz: i'm not sure what go does about automatic syscall restarting actually
<rogpeppe1> mgz: i *presume* it does restart syscalls automatically
<mattyw> fwereade, ping?
<bodie_> morning all
<mgz> hey bodie_
<natefinch> perrito666, wwitzel3, ericsnow, voidspace:  Can we delay the standup a little?  I'm still waiting for my wife to come back from a school board meeting
<perrito666> natefinch: np for me
<voidspace> natefinch: sure
<ericsnow> natefinch: yep
<voidspace> no problem
<perrito666> I am just working looking at wwitzel3 and ericsnow
<perrito666> its like being in an office
<ericsnow> perrito666: so sorry ;)
<perrito666> we do have the weirdest layout for an office :p very one has a very different room behind them
<voidspace> perrito666: ping
<perrito666> voidspace: pong
<wwitzel3> is a "safe" way to turn off the apiworker so a state machine isn't running an apiserver? I've tried just not starting it in cmd/jujud/machine, but the problem there is the machine itself seems to not be available yet, so my call to st.Machine are panicing
<voidspace> natefinch: ping
<voidspace> mgz: you around?
<voidspace> I need the mongo admin password for the backup api call
<voidspace> it is available in the AgentConfig
<voidspace> and I'm wondering how to get that from the apiserver
<voidspace> I have a State
<mgz> hmm
 * voidspace goes and looks how the AgentConfig is created in the first place
<voidspace> agent.NewAgentConfig is called from cloudinit
<voidspace> that just creates the ConfigSetterWriter in memory
<voidspace> I guess it's associated with the machine tag
<voidspace> so I probably need to read it in from disk
<mgz> if you have state that should be fine - though apiserver to mongo admin is a bit dodgy
<voidspace> mgz: what do you mean specifically by "should be fine"?
<voidspace> mgz: what should be fine - reading the AgentConfig from disk?
<voidspace> the admin password isn't in the db so it isn't on State (as far as I can tell)
<mgz> getting the password by some means or other then using it
<voidspace> ah
<voidspace> cool
<voidspace> that's good, because it's required for backup now
<cmars> fwereade, could you take another look at my remove-unit pr? https://github.com/juju/juju/pull/52
<voidspace> mgz: state.EnvironConfig().StatePort() and AdminSecret() ?
<voidspace> for mongo port and admin password?
<voidspace> plausible
<voidspace> state.State. ...
<fwereade> cmars, will try to get to it sometime today
<fwereade> cmars, bit meetingy at the moment
<fwereade> cmars, btw I copied you in on a mail earlier today that isn't actually to do with you
<cmars> fwereade, :)
<fwereade> cmars, I thought it was but it wasn't but I forgot to remove you
<mgz> voidspace: it's something like that, but I don't recall the details and there were some fiddly bits with the change to config stuff
<mgz> voidspace: poke rogpeppe1 maybe
<voidspace> mgz: right, those methods exist and the docstrings look positive about what they're for
<voidspace> mgz: heh, ok :-)
<voidspace> in a minute though
<voidspace> taking a "wee break" (said in a Scottish accent)
<voidspace> rogpeppe1: ping
<ericsnow> voidspace: patch for the backup CLI at https://github.com/juju/juju/pull/97
<ericsnow> voidspace: when you have a sec see if that matches up with your stuff
<voidspace> ericsnow: sure
<voidspace> ericsnow: currently failing to set test values for the mongo port and admin password for a test :-/
<voidspace> I think the code is done, but I'm not sure :-)
<voidspace> ericsnow: looking now
<ericsnow> voidspace: cool
<voidspace> ericsnow: yep, looks good to me
<voidspace> ericsnow: at least the few specific lines of integration look fine
<voidspace> :-)
<TheMue> somebody interested in reviewing a little additional test in the rpc package? https://github.com/juju/juju/pull/107
<ericsnow> voidspace: okay, good :)
<natefinch> perrito666, wwitzel3, ericsnow, voidspace:  Wow, sorry, that took like way way longer than I expected.
<wwitzel3> natefinch: np, I just got off a call anyway
<perrito666> brb, lunch
<perrito666> or not
<perrito666> natefinch: wwitzel3 we are set for the standup?
<natefinch> perrito666, wwitzel3, ericsnow, voidspace:  yeah, hope in, wayne and I are there
<perrito666> in there, sorry I missed the irc notification
<SIGILL> For my bachelor thesis I'd like to test 'virtual network embedding' algorithms in the wild, escpecially with latency in mind. Do you think there's room for improvement in juju regarding that?
<SIGILL> NB: those algorithms try to figure out how to map a virtual network (the cloud) to actual machines in the most efficient way
<natefinch> voidspace: let me know when you're back so we can catch up
<voidspace> natefinch: back, sorry
<voidspace> natefinch: https://github.com/voidspace/juju/compare/download-backup
<voidspace> https://github.com/voidspace/juju/compare/download-backup#diff-198897e828f0611e3185053d7354a523R96
<voidspace> natefinch: s.State.UpdateEnvironConfig
<voidspace> jam1: ping
<voidspace> on the off-chance you're still around
<jam1> voidspace: pong
<jam1> what's up?
<voidspace> jam1: I have a problem with a test :-)
<voidspace> it's (indirectly) a JujuConnSuite test with an apiserver and api client
<voidspace> I'm testing an api endpoint (so apiserver) that needs to use the mongo port and mongo administrator password
<voidspace> I'm pretty sure I can get these by calling state.State.EnvironConfig() and then calling AdminSecret and StatePort
<voidspace> so what I want is a test that checks those values are used
<voidspace> I can't find a way to set those values (from the test) in the environ config used by the test suite
<voidspace> setting them in DummyConfig doesn't work
<voidspace> calling BackingState.UpdateEnvironConfig doesn't work
<voidspace> calling BackingState.SetAdminMongoPassword and State.SetAdminMongoPassword doesn't work
<voidspace> any ideas?
<voidspace> jam1: the test specifically is here: https://github.com/voidspace/juju/compare/download-backup#diff-198897e828f0611e3185053d7354a523R96
<voidspace> see the XXXX on that line
<voidspace> if you search for EnvironConfig() on that page you'll see the code that fetches them
<voidspace> by "doesn't work", I mean that the values I set aren't used
<voidspace> and I get 1234 for mongo port and "" for admin secret
<voidspace> I have to EOD
<voidspace> krav maga
<voidspace> I may be around later though
<voidspace> see you all tomorrow
<bodie_> adios
<voidspace> o/
<perrito666> fwereade: non urgent ping, does the note added to https://github.com/juju/juju/pull/30/files conveys your message to future workers developers?
<ericsnow> natefinch, perrito666: I started working on the restore command and noticed that the plugin basically does it already (or am I missing something?)
<perrito666> ericsnow: the plugins does it
<perrito666> it just does it in a very ugly way
<perrito666> if you follow the plugin:
<perrito666> 1) it checks that the machine we are trying to restore is no longer working
<perrito666> 2) it creates a state server
<perrito666> 3) it runs a bash script through ssh
<perrito666> we intend to split that into 1&&2 properly coded/tested into the client side and 3 properly coded in go and tested on the server
<ericsnow> perrito666: right, but the actual CLI part of that won't really change
<ericsnow> it will just call the new client API
<perrito666> ericsnow: there is room for improvement definitely
<ericsnow> k
<perrito666> ericsnow: if you want I can hangout about this (and we can even bring in natefinch)
<perrito666> :p
<ericsnow> perrito666: yeah, let's do that
<perrito666> lets go to the moonstone channel
<natefinch> perrito666: in minute - in a meeting
<thumper> fwereade: hey, I need to take the dog for a walk before I start, but if you are around later, we can chat
<natefinch> perrito666: you still around?
<perrito666> natefinch: always
 * perrito666 has no life
<natefinch> perrito666: so evidently there's a failure with backup and restore with HA
<perrito666> natefinch: current or old?
<perrito666> i mean, new or old?
<natefinch> unknown... Ian said he ran the CI tests for it, and they failed for some reason
<natefinch> he said "functional tests" but I assume he means CI
<natefinch> "the functional HA backup and restore tests fail. I e-ran that job after the Mongo fix and something is still not right."
<natefinch> s/e-ran/re-ran/
<perrito666> I guess yes, strange, those are currently running and not failing or I would have sinzui looking at me very angry
<perrito666> did he send an email about that?
<natefinch> ian sent it to the team leads,  I unfortunately missed it until alexis pointed it out to me
<perrito666> that is as much detail as there is?
<natefinch> perrito666: http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore-devel/
<natefinch> just found that
<perrito666> daf...
<natefinch> perrito666: http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore-devel/136/console
<perrito666> yup, I was reading
<natefinch> kk
<natefinch> looks like... maybe aws is being slow?
<perrito666> last succesful run is 104
<natefinch> not really sure
<natefinch>  there were intermittent failures before
<perrito666> natefinch: it sees it was running well then began failing then it completely failed
 * perrito666 scratches his chin
<natefinch> brb...
<menn0> morning all
<perrito666> menn0: hi
<menn0> perrito666: how's things?
<perrito666> could be better
<perrito666> :)
<perrito666> natefinch: well, sadly, this is new
<perrito666> :(
<perrito666> this was not there before adding-vote: 2, 3
<natefinch> well crap. We can look at it in the morning, but it's highest priority right now
<natefinch> perrito666: gotta run
<waigani> morning all
<waigani> menn0: I'm unable to reproduce the fail locally. I see in the ci logs the LastConnection is in timezone Z, Zulu which is the same as UTC
<waigani> menn0: I'm guessing it's a time zone issue but that does not explain why i cannot reproduce it locally
<menn0> waigani: from looking at the failure message I don't think the problem is TZ related (although I wouldn't discount it completely given that the CI server is in a different TZ)
<menn0> waigani: shall I try on my machine?
<waigani> menn0: yes please
 * menn0 has to think about how to add tracking branches...
<waigani> menn0: in the last push I set the time stamps to UTC, which fails for me locally
<waigani> menn0: can't you just checkout my branch from my repo?
<menn0> yeah, but I need it in the right place so adding a remote is perhaps easier. it also makes future collaboration easier. It's not hard - almost done.
<menn0> waigani: right... that test fails for me as well
<waigani> menn0: the one you pulled down? DateCreated set to UTC ?
<waigani> try what I emailed you
<waigani> menn0: try user.DateCreated.Local() and user.LastConnection().In(obtained.Result.LastConnection.Location())
<menn0> yep doing that now
<menn0> waigani:  that works
<waigani> menn0: right, that is the same for me
<waigani> i still think its the timezones
<menn0> so the thing about DeepEquals and pointers is a red herring. It's just a misleading error message.
<menn0> yes, now I think it's time zones too
<waigani> okay, so keep what I originally had and compare .Result ?
<waigani> BUT that still does not explain why it passes locally and not on CI
<menn0> checking Result is not going to help
<menn0> if timezones differences are the problem
 * menn0 thinks
<waigani> if the user factory just returned everything in UTC it could solve the problem
<waigani> but I'm still intrigued as to why CI fails and local does not - unless NZST got hardcoded? but surely not
<menn0> it's not the user factory's problem. It's just returned in the user document
<menn0> i'm just experimenting with a few things
<waigani> menn0: the factory creates a user and returns DateCreated and LastConnection for that user with different timezones and locations than what UserInfo returns
<waigani> that is the crux of the problem as I see it
<menn0> waigani: yes but that's just a difference between how these values are stored in state and how the API returns them
<waigani> menn0: exactly, it's formatting - which my original test addressed
<waigani> menn0: and passed locally
<jcw4> I've added Tag implementations for Action in juju/names; PTAL: https://github.com/juju/names/pull/6
<waigani> menn0: so LastConnection has a location set when returned by the API, but not via the user factory
<waigani> menn0: I set the API to always return UTC - the missing location in LastConnection is the only difference between the two now
<menn0> waigani: it could also be something to do with LastConnection being uninitialised because there's never been a connection
<menn0> but when you print the user docs LastConnection and the one from the API they both look the same (and are both in UTC)
<menn0> it could also be the Local conversion for DateCreated...
<menn0> sending you an email now
<menn0> waigani: just your inbox
<waigani> menn0: sweeet, thanks
<davecheney> thumper: could I get another set of eyeballs on https://github.com/juju/names/pull/5
<davecheney> so I can land this and move on to my next branch this morning
<thumper> yup
<jcw4> s/5/6/ ;)
<jcw4> davecheney: are there specific characters that are (or are not) allowed as a Tag() name?
<jcw4> davecheney: I see that / and : are replaced with - and . respectively
<jcw4> davecheney: for our Actions entity, I am using # as a marker token in the mongo _id
<jcw4> davecheney: and I want to expose the Action name/id through a Tag()
<davecheney> jcw4: not really sure
<davecheney> i think this is a side effect of forcing tags to be expressable as strings
<jcw4> I have a discussion pending with fwereade, but since you did that work on the names package I wanted to see if there were any 'easy' answers  :)
<jcw4> thanks davecheney
<davecheney> jcw4: sorry, i don't know the answer
<davecheney> i think there were some unfortunate interactions with the printed form of, say a relation
<davecheney> with the stringified version of the tag
<davecheney> given we use hypehn to separate between the name of the tag and it's value
<jcw4> davecheney: hence the translation for relations, i see
<waigani> menn0: I'll just go wash this curry off me then get back into debugging the timezone issue.
<waigani> I'll let you know if i find anything interesting
<menn0> waigani: cool. I'm going to leave you to it for a bit so I can get this branch landed but can help out later on if it's still not working out.
<waigani> menn0: no problem, I've got a few ideas to try out
<jcw4> davecheney: thanks for the ParseActionTag suggestion, I'll investigate; I think it's something we do want
<davecheney> jcw4: you may, you can always get the same result with
<davecheney> tag, err := ParseTag(tag)
<davecheney>  // check err
<davecheney> if tag, ok := tag.(ActionTag); ok {
<davecheney>  // yup it's an action tag
<davecheney> }
<jcw4> davecheney: okay, I'll look into that closer.
#juju-dev 2014-06-17
<jcw4> davecheney: I just understood your comment... derp :)  I was thinking about ParseActionTag being a way to extract unit and/or service name from the action name
<jcw4> I think for now tag, ok:= tag.(ActionTag); ok {} should work
<davecheney> jcw4: and that is only needed if
<davecheney> a. you want to ensure the string you passed to ParseTag was actually an action tag
<davecheney> b. you care about any specific fields on ActionTag, rather than just the Tag interface
<menn0> Phew! Review please: https://github.com/juju/juju/pull/109
<waigani> thumper, menn0: State.User.DateCreated() and State.User.LastConnection() were returning timestamps in local rather than UTC timezones. I've added .UTC() to ensure UTC timezones: https://github.com/juju/juju/pull/91
<waigani> menn0: i.e. timezone bug solved!
<menn0> waigani: is it worth figuring out why local timestamps were being returned and fixing that? According to the doc string for DateCreated() we expect a UTC timestamp to come out.
<menn0> and thumper expected that too
<waigani> menn0: timezone bug not solved!
<waigani> menn0: It's set to UTC on AddUser and also on UpdateLastConnection. You said the user docs were the same. So it must be converted to local time on read.
<menn0> waigani: yes it is converted to local time on read - that's the problem. That means our expectations aren't correct (see the doc string for DateCreated)
<menn0> waigani: it could be that mgo is doing the conversion, or mongo itself
<thumper> I'd suggest updating the user methods to do a UTC
<thumper> should be a no-op if already in UTC
<thumper> however, that doesn't explain the factory tests passing
<thumper> why is that different?
<menn0> thumper: I just figured that out. They're not running!
<thumper> wah...?
<menn0> missing this: var _ = gc.Suite(&factorySuite{})
<thumper> oh ffs
<menn0> I've added that and they fail
<thumper> :-(
<thumper> but \o/
<thumper> that explains it
<thumper> menn0: did you want to propose a branch that just fixes that?
<thumper> if you don't
<thumper> I will
<menn0> thumper: will do. I literally just discovered this.
<waigani> ah
<menn0> so what do we want to do about the failures
<menn0> thumper: ?
<thumper> menn0: how about I fix it?
<menn0> the tear down fails too: Error: Test left sockets in a dirty state
<thumper> I know what I want to do
 * thumper takes it
<menn0> thumper: no problems
<menn0> thumper: are you going to get mgo/mongo to give us UTC timestamps back too?
<thumper> menn0: I'll make the tests pass :-)
<waigani> thumper: I've added .UTC() to user methods
<menn0> thumper: I guess that will do
<thumper> waigani: yeah, saw that, I may do that in my branch to make sure it works
<thumper> ack
<waigani> thumper: so should I land my branch now or wait for yours?
<thumper> wait please
<thumper> won't be long
<waigani> ok
<thumper> wow the tests take a while to run now...
<thumper> FAIL	github.com/juju/juju/replicaset	455.322s
<thumper> ok git folks, I've accidentally committed to the local master
<thumper> how to I get my master back following upstream master?
<thumper> menn0, waigani: https://github.com/juju/juju/pull/110
<thumper> axw: ta
<axw> nps
<axw> thumper: if you accidentally committed to master, you can "git reset HEAD^". you probably want to stash the working tree first
<thumper> axw: I already branched from it and pushed, hence pull 110
<thumper> nope, already done
<thumper> what I want is uncommit
<waigani> git reset --hard HEAD^	
<axw> thumper: yes, that is equivalent to uncommit
<thumper> HEAD^ whazzat?
<axw> HEAD-1 I think?
 * thumper missed the caret
<thumper> that worked
<thumper> ta
<davecheney> state/state.go:189
<davecheney> I think we are leaking mongo iterators
<davecheney> var tagPrefix = map[byte]string{ 'm': names.MachineTagKind + "-", 's': names.ServiceTagKind + "-", 'u': names.UnitTagKind + "-", 'e': names.EnvironTagKind + "-", 'r': names.RelationTagKind + "-", 'n': names.NetworkTagKind + "-",
<davecheney> }OMG, i just found a private encoding of tags in the state package ...!!!
<waigani> haha, good to see your hard work being appreciated
<menn0> thumper, axw: "git help revisions" talks about all the ways to refer to revisions with git. It's useful and complete but dense. This page is a bit gentler: http://git-scm.com/book/en/Git-Tools-Revision-Selection
<axw> thanks menn0
<thumper> menn0: please don't add "er" on to the method name for the interface name
<thumper> that will make me want to kill you
<thumper> especially if it is a nonsense name
<thumper> String, Stringer is kinda ok
<thumper> Read, Reader is ok
<thumper> Status, Statuser is not
 * thumper has an OCD meltdown
<menn0> davecheney: it looks like that tag mapping is only used in one place as well
<menn0> thumper: we have plenty of other interfaces that use a similar naming style (there's even a setStatuser, so ha!). I used that and other code and articles I've seen online as a guide as I figured that was the idomatic Go thing to do.
 * thumper twitches
<davecheney> thumper: there is a reason why the thing that runs Hooks is called a Uniter
<thumper> haha
<davecheney> you can ask fwereade about that
<thumper> and not a HookRunner?
<menn0> I can call it StatusAPI or something if that makes the twitching stop
<thumper> because, OMG that might tell you what it is doing
<thumper> there are still those that titter when I explain to them that a hooker is a valid rugby position
<menn0> is that the player who hangs around the dark corner of the field not wearing very much?
 * menn0 disappears to change the interface name...
<waigani> menn0: ugh, sorry about the statuser - stupid
<menn0> waigani: np. given that it confused you and thumper hates it, I'll change the name.
<davecheney> ... what does a Thumper do ?
<thumper> Thumps
<thumper> :-)
<menn0> http://en.wikipedia.org/wiki/Sun_Fire_X4500 ?
<menn0> ;->
<davecheney> coll, id, err := state.ParseTag(s.State, m.Tag())
<davecheney> why does state have it's own ParseTag method ...
<davecheney>         m, err := s.State.AddMachine("quantal", state.JobHostUnits)
<davecheney>         c.Assert(err, gc.IsNil)
<davecheney>         coll, id, err := state.ParseTag(s.State, m.Tag().String())
<davecheney> we have a machine, we get it's tag, then we parse it's tag
<davecheney> and then I (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»)
<axw> wallyworld: https://github.com/juju/juju/pull/112 when you're free
<wallyworld> sure
<wallyworld> axw: just reading the desc, can we retry bootstrap for the user?
<axw> wallyworld: I think it's actually quite rare to occur, so I'd rather not complicate it
<axw> wallyworld: I've never seen it delete after afterwards
<wallyworld> ok
<axw> it just sits there
<menn0> thumper, waigani: interface name changed
<thumper> :)
<waigani> thumper: you've got a test failure
<thumper> waigani: ta
<waigani> thumper: you need to replace DateCreated:    time.Time{}, with user.DateCreated()
<waigani> thumper: I've done that in my branch, ironically if I landed my branch first, yours would pass
<waigani> thumper: state/apiserver/usermanager/usermanager_test.go:189
 * thumper nods
<thumper> looking at it
<thumper> waigani: that isn't it though :)
<waigani> oh?
<thumper> it is the zero value from last connection has a TZ of UTC
<thumper> now that we specify that...
 * thumper hacks
<waigani> thumper: all tests pass on my branch. DateCreated and LastConnection are just set from the corresponding user methods - as long as they return UTC
<thumper> you'll see
<waigani> thumper: what happens when you UTC a zero time?
<thumper> you get something that is no longer zero
<menn0> waigani, thumper: I think the setting-UTC-on-a-zero-time thing is part of what was confusing us (well at least me) this morning. A Time{} and Time{} with UTC set both convert to the same string when printed but are actually different.
 * thumper nods
<waigani> thumper: menn0: and the difference seems to be only the location
<menn0> thumper, waigani: here's a good example of the problem: http://play.golang.org/p/zYoOyRiUsm
<menn0> 0001-01-01 00:00:00 +0000 UTC
<menn0> 0001-01-01 00:00:00 +0000 UTC
<menn0> false
<menn0> that's pretty sucky. if "no location" is supposed to get interpreted as UTC (which the string representation seems to indicate) then they should compare equal.
<davecheney> http://golang.org/pkg/time/#Time.Equal
<davecheney> read the comment
<menn0> davecheney: I was just looking to see if there was such a thing
<menn0> davecheney: thanks. that's good to know about.
<menn0> davecheney: it is a bit tricker for some of the cases were were dealing with today where there were Times stored in structs that were being compared.
<waigani> menn0: just ran your example through jc:
<waigani> mismatch at (*.loc): validity mismatch; obtained <nil>; expected time.Location{name:"UTC", zone:[]time.zone(nil), tx:[]time.zoneTrans(nil), cacheStart:0, cacheEnd:0, cacheZone:(*time.zone)(nil)}
<davecheney> menn0: store them as uint64s
<menn0> waigani: jc?
<waigani> menn0: jc "github.com/juju/testing/checkers"
<menn0> davecheney: nah. I like the richer type. it's just one of those things you need to be aware of.
<menn0> waigani: jc.DeepEquals?
<waigani> menn0: sorry, yeah that is what I mean
<waigani> it shows you the problem
<menn0> waigani: that's also very useful to know. The error message from gc.DeepEquals was completely misleading.
<menn0> hooray for learning lots of new stuff today :)
<waigani> menn0: yeah thumper has been trying to thump it into me to use jc instead of gc
<waigani> so converting to UTC changes .loc from nil to time.Location{....
<menn0> waigani: yep. Here's that earlier example using %Q, which shows the difference: http://play.golang.org/p/5yjGGgGjTr
 * menn0 gets back to more pressing matters
 * davecheney can't believe nobody pulled me up for this
<davecheney> http://godoc.org/github.com/juju/names#Tag
<waigani> menn0: thumper's fix breaks the tests - the rabbit hole deepens
<menn0> waigani: what's the failure?
<waigani> menn0: If you pull trunk and update the UserInfo tests to compare user.DateCreated(), user.LastConnection() instead of time.Time{} you'll see it is the same error
<waigani> menn0: i.e. the user factory returns .loc = nil, while the api returns .loc = time.Location{...
<menn0> waigani: I can't look right now, deep in schema upgrade stuff and about to finish up anyway
<waigani> menn0: removing thumpers fix, and always returning UTC, even on zero time, makes all the tests pass
<waigani> menn0: I don't need you to, just sharing as you are interested in the problem
<menn0> waigani: I am interested. I'll have a look tomorrow if you don't figure it out first. It'll be a matter of stepping through all the pieces.
<waigani> menn0: have a good evening :)
<menn0> you too
<wallyworld> axw: jeez, your ahving no luck with the merging
<wallyworld> you're
<axw> wallyworld: yeah it's giving me the shits
<wallyworld> axw: i'm off to soccer but will talk to martin when i get back and see if he can fix it
<axw> wallyworld: thanks. have fun
<wallyworld> will do
<wallyworld> axw: incidentally, i just re-ran the azure upgrade test and it passed. i had a theory that your azure fix would help as the run was previously failing to bootstrap, maybe due to old resources hanging around
<wallyworld> so i'll let curtis know and hopefully it will continue to be well behaved
<axw> wallyworld: sweet
<voidspace> morning all
<TheMue> morning
<TheMue> anyone available for reviewing https://github.com/juju/juju/pull/107 ? itâs a very small one, only added a test
<jam> TheMue: I just reviewed: https://github.com/juju/juju/pull/107
<jam> perrito666: what is the status of https://github.com/juju/juju/pull/30, there seem to be a ton of comments on it, and I'm not really sure what has and hasn't been addressed. Can you give a quick summary?
<TheMue> jam: thx
<jam> wallyworld: I realize we've been doing release-y stuff, which is great. But have you looked at alternative code review yet?
<TheMue> jam: I thought I read that I first have to Start() before Serve(). It seems I got it wrong. Will change.
<jam> TheMue: well if docs say that, they are probably wrong, and we should fix those while we're here.
<jam> certainly if you had to have a "channel' in order to use a website, it would just be broken, right?
<TheMue> jam: exactly
<TheMue> jam: costed me some time to get why I have a race condition every 10th to 20th run :/
<jam> fwereade: dimitern: any chance I can ask you guys to have a look at my API Versioning proposals? They've been sitting for 2 days, and apparently they scare the on-call reviewersâ¦ :)
<jam> https://github.com/jameinel/juju/pull/1 https://github.com/jameinel/juju/pull/2 https://github.com/jameinel/juju/pull/3
<jam> are the incremental diffs
<dimitern> jam, really sorry I couldn't get to them yesterday, I'll have a look quickly, but I'll do a more thorough review after the standup (after I finish the doc finally)
<jam> dimitern: it can wait until you can focus on it, I guess.
<jam> I'm the OCR today, so I can't just poke myself to go review it. :)
<dimitern> :) indeed
<TheMue> jam: ah, found it, wrong understanding. not âit has toâ but âit may beâ. so itâs only said that one can call Serve() later, e.g. to register another root
<jam> TheMue: right. We do use that to switch from the "Admin" root that only exposes Login to the functional root that lets you do all the actual work.
<TheMue> jam: will keep it in mind for the docs ;)
<jam> thx
<tasdomas> axw, I think I don't have the permissions to merge pull requests into github.com/juju/juju
<jam> tasdomas: you probably need to set your membership in the juju group to public
<jam> tasdomas: go here https://github.com/orgs/juju/members?page=2
<jam> and you can fix it
<jam> the bot needs to know that you're in the "allowed" group
<tasdomas> jam, thanks - this takes time to apply, right?
<jam> tasdomas: well, it takes a while before the bot polls again, but I don't think you have to vote again.
<jam> *I* see you as public now
<jam> so the bot should be happy
<perrito666> jam1: I think it can be merged, I was waiting on fwereade to ack that the last note I added actually clarifies what he wanted it to say about creating new workers, but that should not be a showstopper
<perrito666> jam1: that is abot PR:30
<voidspace> perrito666: morning
<perrito666> voidspace: morning
<jam> tasdomas: "merge request accepted" was just posted by the bot
<jam> so it looks like your perms are sorted out.
<tasdomas> jam, thanks!
<jam> it will takeâ¦ 15min + for the bot to actually process it.
<jam> tasdomas: it is running it now: http://juju-ci.vapour.ws:8080/job/github-merge-juju/179/
<jam> ericsnow: I just commented on https://github.com/juju/juju/pull/97
<jam> feel free to ask any questions if you want clarification.
<jam> overall a pretty good first submission IMO
<voidspace> jam: did you see the question of mine late last night?
<voidspace> jam: I don't suppose you had any thoughts?
<jam> voidspace:
<voidspace> jam: about changing values in the EnvironConfig of the server side of a JujuConnSuite
<jam> I remember reading that you had a test problem, and I think I started investigating, but then had a phone call and completely forgot the context
<voidspace> I'm about to start poking at it again
<voidspace> heh
<voidspace> I had to go anyway
<voidspace> jam: let me grab the link to the code
<voidspace> if you're ok to have a look now that is
<voidspace> <voidspace> it's (indirectly) a JujuConnSuite test with an apiserver and api client
<voidspace> <voidspace> I'm testing an api endpoint (so apiserver) that needs to use the mongo port and mongo administrator password
<voidspace> <voidspace> I'm pretty sure I can get these by calling state.State.EnvironConfig() and then calling AdminSecret and StatePort
<voidspace> <voidspace> so what I want is a test that checks those values are used
<voidspace> <voidspace> I can't find a way to set those values (from the test) in the environ config used by the test suite
<voidspace> <voidspace> setting them in DummyConfig doesn't work
<voidspace> <voidspace> calling BackingState.UpdateEnvironConfig doesn't work
<voidspace> <voidspace> calling BackingState.SetAdminMongoPassword and State.SetAdminMongoPassword doesn't work
<voidspace> * arturt has quit (Quit: Computer has gone to sleep.)
<voidspace> <voidspace> any ideas?
<voidspace> <voidspace> jam1: the test specifically is here: https://github.com/voidspace/juju/compare/download-backup#diff-198897e828f0611e3185053d7354a523R96
<jam> voidspace: just for context, this is the backup code, right?
<voidspace> that's correct
<voidspace> this is the api endpoint
<voidspace> it needs the mongo port and mongo admin password to call the code doing the actual backup
<jam> voidspace: we should also make sure that you guys are talking with menn0 et al because their looking to use the backup code with their upgrade rollback stuff.
<voidspace> ah, right
<voidspace> we haven't talked at all yet
<jam> voidspace: and one thing that popped out is that they want to give the backup to the client, but they also really would like to keep a copy on the server
<voidspace> the backup code is now in
<jam> so the client doesn't have to get involved if upgrade fails
<voidspace> right
<voidspace> that's easy for them to implement on top of what perrito666 did
<voidspace> when you call Backup you give it a directory to put the backup file in
<voidspace> in my code I send that to the client and then delete the backup file
<voidspace> they wouldn't need to reuse my code at all
<jam> voidspace:  for "c.Assert(os.IsNotExist(err), jc.IsTrue)
<jam> "
<jam> you can use"
<jam> c.Assert(err, jc.Satisfies, os.IsNotExist0
<jam> sorry
<voidspace> right, I saw examples of that
<voidspace> but I saw no benefit
<jam> no "(" in the end of that line
<jam> voidspace: when it doesn't match
<jam> you get output on the console
<jam> which describes "err"
<jam> rather than output
<jam> that describes" false"
<voidspace> ok
<jam> voidspace: so when the assert fails, you get better debugging information.
<voidspace> although *specifically* what I'm interested in is "does the directory still exist"
<voidspace> so it's kind of a true / false situation
<jam> also, you should try to use "Check" rather than "Assert" whenever you can reasonably continue to check more things.
<voidspace> although if there's another error it would be useful to know what it is I guess
<voidspace> jam: c.Check ?
<voidspace> that's helpful
<jam> voidspace: so yes, what you care about is that you get IsNotExist, but if the test *fails* I'd rather know that it got ErrNOTDIR or EINVALID or ESOMETHING ELSE
<voidspace> yep, fair enough. Thanks.
<jam> voidspace: because the first thing that you're going to do if that assert fails is go in and change the line to something else so that you get that context :)
<wallyworld> jam: it's one of mgz's top priorities
<jam> voidspace: c.Check vs c.Assert is something that we're not particularly consistent with, but just a guideline to keep in mind.
<jam> I try to use Assert for things that would cause a panic
<jam> later if not Asserted
<jam> and then Check for everything else.
<wallyworld> but the intermittent github merge rejections (after tests have passed) are becoming too annoying to ignore
<voidspace> yeah, that's better - I keep commenting out asserts to see if a later one passes
<jam> voidspace: anyway back to your original question. The idea is "I need to inject my test values and assert that I see them passed correctly to my apiserver.Backup function" correct?
<voidspace> I just haven't used Check before
<voidspace> jam: yep
<voidspace> jam: JujuConnSuite has a BackingState which is allegedy the State used by the apiserver in the test
<voidspace> jam: so that is where I should be setting the test values
<voidspace> jam: however I have so far failed to influence what EnvironConfig returns
<perrito666> axw: you just made me realize that the hook is not working for me (i have it set)
<axw> perrito666: what's your git version?
<axw> perrito666: it's just called "pre-push" in .git/hooks?
<perrito666> axw: 1.9.1 I most likely did something wrong when setting it up
<axw> perrito666: in .git/hooks, you should have "pre-push -> ../../scripts/pre-push.bash"
<perrito666> axw: I had done the simlink wrongly
<perrito666> I had pre-push.bash
<perrito666> instead of pre-push
<voidspace> so I get errors from pre-push now
<voidspace> because of perrito666's code!
<voidspace> :-)
<perrito666> voidspace: its fixed by axw merge again
<perrito666> :p
<voidspace> hehe
<voidspace> I'd better pull then
<natefinch> jam: you around?  We should talk multi-env state servers.  I'm unfortunately going to have to be out for much of the morning due to a rescheduled doctor's appointment
<voidspace> natefinch: morning
<natefinch> voidspace: morning
<jam> voidspace: tbh, both BackingState and State should be touching the same DB.
<voidspace> jam: right
<jam> You should only need BackingState for things that are already cached in memory, like workers and watchers sort of things.
<jam> natefinch: I'm around, and can chat a bit. I have team standup in 30min.
<voidspace> jam: however, calling UpdateEnvironConfig doesn't seem to change the values it returns
<natefinch> Yep ok
<jam> Though I have more evening time than normal because my family is out of town
<natefinch> jam: well, I'll probably be available around 8:30pm your time...  if you're on, we can talk.
<natefinch> but yes, some time now would be good
<voidspace> brb
<jam> natefinch: start up a g+ and invite me, I'll come in, I'm trying to help out voidspace a bit right now., but maybe I can do both
<jam> natefinch: if you want, we can just use our team standup one, since I'm sure we'll be talking right up until standup: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<voidspace> jam: these are the things I've tried specifically: http://pastebin.ubuntu.com/7657695/
<natefinch> jam: that makes sense
<jam> voidspace: you probably should be checking the error returned from UpdateEnvironConfig
<jam> it might tell you there is a bug in what you're asking.
<voidspace> jam: ok, good point
<voidspace> thanks
<jam> voidspace: for example, I think StatePort is immutable once set
<jam> voidspace: so you're probably better off just looking internally for what the current value is, and then asserting that you see it in the test.
<jam> rather than trying to change it.
<voidspace> ok
<voidspace> that would be fine
<voidspace> as the admin password is set to an empty string I would really rather change that
<voidspace> as an empty string could come from anywhere
<voidspace> jam: your suspicion was correct
<voidspace> well, sort of
<voidspace> ... value *errors.errorString = &errors.errorString{s:"admin-secret should never be written to the state"} ("admin-secret should never be written to the state")
<voidspace> setting the admin-secret in the EnvironConfig fails
<voidspace> setting the mongo admin password directly doesn't change the one stored in EnvironConfig either
<voidspace> which maybe means it's the wrong place to get it from
<jam> fwereade: is there a template for us to use for writing up multi environment state server spec ?
<voidspace> jam: and yes, the state-port is immutable too
<voidspace> I can get that by introspecting the EnvironConfig though
<jam> well, you could introspect both of those, right?
<voidspace> jam: the admin secret in EnvironConfig is an empty string
<voidspace> and that could come from anywhere, so I don't think it's a good test
<jam> voidspace: admin secret is the password for the "user-admin" I think, and not intended as the password you use for the DB
<jam> you need machine-0's (machine-1, etc) mongo password
<voidspace> *plus*, calling state.SetAdminMongoPassword("something") doesn't change what is returned by EnvironConfig.AdminSecret()
<jam> voidspace: right, but you shouldn't be using it anyway
<jam> sorry, I'm still paging in some context of how all this works.
<voidspace> ok, perrito666 told me that I *should* be using the admin password
<jam> we probably don't use admin secret anymore.
<jam> admin secret is the password for "user-admin" and we actually don't give them direct DB rights anymore (IIRC)
<jam> so you need to be using the machine password for the API server.
<voidspace> hmm... the parameter to backup.Backup is specifically called adminPassword
<voidspace> perrito666: will the state server machine password do?
<voidspace> jam: how do I get the machine password? (I haven't looked for that, so maybe it's easy)
<perrito666> voidspace: well, according to what jam says, it should
<voidspace> it sounds like AdminSecret is definitely wrong though
<voidspace> perrito666: heh, ok
<voidspace> the state server has write permissions to the database (obviously), so I would expect so
<jam> voidspace: perrito666: Have to do this call now, so I'll try to get back after our standup is done
<voidspace> jam: thanks very much
<jam> voidspace: so machines know their password by reading their agent.conf
<jam> presumably that is also stored in the DB because of the API validating their password.
<voidspace> AgentContext is how perrito666 suggested I get it, but that means finding the location of the conf file
<voidspace> so I wanted to see if there was an easier path first
<voidspace> I don't *think* it's stored in the state though, I did have a bit of a spelunk
<voidspace> I may have missed it
<perrito666> voidspace: the easy way is to try to run the dump with a different password (and perhaps you will have to change the user too
<voidspace> perrito666: you mean try it manually with a running mongo?
<voidspace> sounds like a good check
<perrito666> voidspace: yup, current backup uses admin/oldPassword
<wallyworld> mgz: i'd like a quick hangout if you are free
<mgz> wallyworld: sure
<wallyworld> mgz: https://plus.google.com/hangouts/_/gruuhdkj3yzsvab42gsqrpr5i4a
<natefinch> perrito666: are you working on the HA backup thing?
<mgz> gurk, can we use the standup one?
<perrito666> natefinch: yup, I am reading the prs merged around the breakage
<natefinch> perrito666: good, thanks.
<jam> natefinch: if you want to join again, our standup is done
<jam> voidspace: perrito666: thinking about it, I think we actually only store the *hash* of the API Password in the database. And the Agent logs in by supplying the real text, and we then hash it and make sure it matches our saved hash.
<jam> So we probably don't actually store the actual password anywhere but in the agent files.
<jam> however, this is going to be run as the current agent user, right?
<jam> so it should have some idea of what its current password is.
<jam> though it is possible that it loads that information, connects, and then immediately forgets about it for the rest of its process.
<jam> which is a bit of a shame.
<voidspace> I couldn't see how to get the AgentContext from the apiserver without reloading it
<voidspace> (and yes, I saw various references to the password hash - but not to the password itself)
<voidspace> so it looks like I have to re-read it
<voidspace> the conf file is in a subdirectory of DataDir, the sub-directory is easy because that's the machine Tag
<voidspace> jam: do you know how I find the DataDir for the conf file?
<natefinch> jam: ok
<jam> voidspace: I think the cmd/juju/machineAgent has that information
<voidspace> jam: thanks, will look
<voidspace> London to Boston flights in July are really expensive
<voidspace> cheapest is Â£900 return - and the travel provider always seems to cost more
<mgz> eech
<voidspace> yeah, direct is Â£1500!
<voidspace> so looks like I'll be stopping :-/
<perrito666> voidspace: lucky you there is no direct from here
<voidspace> heh, yeah very lucky. A direct option I can't take... :-)
<mgz> hm, looks okay via AMS
<mgz> lucky me
<perrito666> The shortest flight I see, which has 1 scale costs 3kUSD
<voidspace> mgz: AMS?
<voidspace> perrito666: 1 scale?
<mgz> voidspace: my local airport is Norwich INTERNATIONAL... because it has a hop to schiphol
<perrito666> so I do my city > brazil, brazil > somewhere in US, somewhere > boston
<voidspace> perrito666: :-(
<voidspace> hopefully I'll have only one stop
<perrito666> I hope brazil airport is nice, I have 13h there
<perrito666> :p
<jam> mgz: the same is true for my "International" airport in Cedar Rapids, and apparently true for the Nuremberg International airport. I haven't been able to book travel from DXB all the way to Nur, but apparently I can get to Schiphol and then take a direct flight from there.
<mgz> it's actually pretty handy, as an alternative to train down to heathrow
<TheMue> I always have to hop, via FRA, MUC or AMS
<TheMue> BRE next too me is too small, only CPH worked directly
<voidspace> jeebers, so many levels of indirection
<voidspace> BootstrapCommand calls InitializeState which calls initUsersAndBootstrapMachine which calls initBootstrapMachine
<voidspace> this creates a new mongo password, storing only the hash in the state
<voidspace> it does however call ConfigSetter.SetPassword - the ConfigSetter instance being a configInternal
<voidspace> the implementation of SetPassword stores the new password on c.stateDetails.password (or c.apiDetails.password)
<wwitzel3> thanks jam, I do that a lot with mailing lists
<voidspace> so I need to work out how to get that config and then get the password from it
<jam> wwitzel3: it doesn't help that google's default is just reply, though you can edit your settings to make the default reply all.
<jam> For tbird, I think it is a different shortcut, but still I just learned to use that one for most replies.
<jam> wwitzel3: I *think* I touched all the non-WIP reviews except the massive cloudsigma one.
<perrito666> there was a lab to make reply to all the default
<perrito666> very useful I must say
<voidspace> I don't see the new password being written out, which would be odd as the state machine rebooting would no longer be able to access the db
<voidspace> so that can't be right
<voidspace> the DataDir is just a constant set in environs/cloudinit.go - so I'll see if just reading the config back in works
<perrito666> :|
<perrito666> ERROR juju.provider.common bootstrap.go:119 bootstrap failed: cannot start bootstrap instance: cannot run instances: Your requested instance type (m3.medium) is not supported in your requested Availability Zone (us-east-1a). Please retry your request by not specifying an Availability Zone or choosing us-east-1d, us-east-1e, us-east-1c. (Unsupported)
<perrito666> anyone knows how to go around that?
<fwereade> perrito666, I think axw is working on that -- you should be able to bootstrap --to zone=one-that-works
<perrito666> fwereade: trying now
 * perrito666 merges back with trunk just in case
<axw> perrito666: pull trunl, it should be fixed
<axw> trunk*
<fwereade> and, everybody, I'm sorry but I seem to be ill. felt a bit crappy, had a lie down after lunch, fell asleep, still feel crap and have a bit of a temperature
<fwereade> I'm going away again for a bit, might come back if I'm more with it later
<axw> hope you're feeling well soon fwereade
<fwereade> axw, cheers :)
<TheMue> fwereade: yeah, get well soon
<perrito666> fwereade: get better
<perrito666> axw: ping me if you have a moment plz
<axw> perrito666: what's up?
<perrito666> axw: what exactly is "fixed" in this case?
<axw> perrito666: nothing much, just preventing warnings from the race detector
<perrito666> I meant about the region issue
<perrito666> :)
<axw> perrito666: they're only in the test code
<axw> perrito666: oh
<axw> perrito666: the automatic spread code will attempt with another zone if the one it chooses is constrained
<axw> perrito666: hum. your error message is a bit different
<axw> perrito666: the fix was https://github.com/juju/juju/pull/105, but looks like your error is subtly different
<axw> would you please file a critical bug against 1.19.4 with the error message you got?
<bodie_> o/
<Beret> alexisb, is 1.20 still on track for this week do you know?
<alexisb> Beret, it will potentially be delayed given the development release is still held up due to critical bugs
<alexisb> Beret, I will work with the team today to get an adjusted eta for 1.20
<Beret> ok, thanks
<voidspace> ericsnow: wwitzel3: perrito666: are we going to do standup without natefinch or wait?
<voidspace> I'm happy to wait
<ericsnow> voidspace: me and perrito666 are in already
<perrito666> voidspace: as you guys wish
<voidspace> heh
<perrito666> if no one has any important question I am happy to continue debugging
<perrito666> mmpf, kickt out
<voidspace> rogpeppe: ping
<rogpeppe> voidspace: pong (but currently in a call)
<voidspace> rogpeppe: I'm in the apiserver (specifically the new backup end point)
<voidspace> rogpeppe: I need the mongo admin password
<voidspace> rogpeppe: the right way to get it seems to be to read the agent conf
<voidspace> rogpeppe: for that I need the current machine tag
<voidspace> rogpeppe: the httpHandler has a state
<rogpeppe> voidspace: are you just debugging, or writing code?
<voidspace> rogpeppe: writing code
<voidspace> rogpeppe: the backup command (the shell command we run) needs the admin password
<rogpeppe> voidspace: you'll need to pass in the password from the machine agent
<voidspace> rogpeppe: we're not sure if that will work, we *think* we need the admin user and password to do the dump with opLog
<voidspace> rogpeppe: however, how would I get the machine agent password (and username and mongo port as well)
<voidspace> I can test both
<rogpeppe> voidspace: there is no admin user with mongo access
<rogpeppe> voidspace: the machine agent should have admin rights
<voidspace> there is an admin user
<voidspace> that's what the agentConf.OldPassword field is for
<rogpeppe> voidspace: not quite
<voidspace> however, I'm happy to run it as the machine agent and see if that works
<voidspace> but I *still* need to be able to get at that password
<voidspace> as far as I can tell the password hash is set in the state but not the password
<rogpeppe> voidspace: the machine agent has access to that password
<voidspace> I'm inside the apiserver
<rogpeppe> voidspace: inside jujud/machine.go
<voidspace> I've seen that code
<rogpeppe> voidspace: you'll need to pass the password into the api server
<voidspace> that's not where I am...
<voidspace> yuck
<voidspace> change the way the apiserver is created
<voidspace> is the configInternal that is created in machine.go stored anywhere
<rogpeppe> voidspace: alternatively, you could provide a way to get the password from the *state.State that was used to connect to it
<voidspace> so we don't store that password and as we now need it I have to store it
<voidspace> hmm, ok
<voidspace> rogpeppe: what is agentConf.OldPassword() for? because that was working for perrito666
<rogpeppe> voidspace: no
<voidspace> "no" is not a semantically valid answer to that question :-)
<rogpeppe> :-)
<rogpeppe> voidspace: OldPassword is to force an agent to change their password when it first starts, because the password's been passed through insecure cloudinit
<voidspace> rogpeppe: if a state server has to restart, how does it connect back to mongo?
<rogpeppe> voidspace: the machine agent reads its config file
<voidspace> so the password is in the machine agent config file?
<rogpeppe> voidspace: then uses the info from that to reconnect to mongo
<rogpeppe> voidspace: yes, but that's something that the api server should not know about
<jam> ericsnow: I reviewed https://github.com/juju/juju/pull/113
<jam> voidspace: nate is missing standup today if you didn't notice
<ericsnow> jam: thanks!
<rogpeppe> voidspace: add this method to state/open.go:
<rogpeppe> func (st *State) Info() *Info {
<rogpeppe> 	return st.info
<rogpeppe> }
<rogpeppe> voidspace: then you can get access to the password
<rogpeppe> voidspace: you may want to copy the info before returning it
<voidspace> jam: we thought he would be coming later
<voidspace> rogpeppe: ok, interesting - thanks
<jam> voidspace: he said he won't be back for 2 more hours
<jam> at least, I talked with him just before he left, and he said he was going to miss his standup again.
<jam> I'm not sure why he wouldn't tell *you* guys that directly :)
<voidspace> jam: he did email us
<voidspace> jam: we were just hopeful we would get to talk to him I guess :-)
<jam> ah, k. Well, he said he would be back in ~2 hours from now, because we wanted to collaborate on some stuff. So he should be back later today. I'm guessing that's going to be a bit too late for voidspace but at least perrito666, wwitzel3, and ericsnow can chat with him
<voidspace> jam: two hours is fine
<voidspace> jam: we're all in the hangout anyway
<voidspace> jam: I'm around for ~3hours (just less)
<voidspace> rogpeppe: perrito666 thinks that this command actually requires the admin user, not just admin permissions though
<rogpeppe> voidspace: i don't believe so
<voidspace> heh, he believes so and he's *tried* it - however, I have an open mind
<rogpeppe> voidspace: if so, then our model is flawed
<voidspace> heh
<perrito666> voidspace: as I said, I tried this some time ago by actually doing the xport in the current juju-backup script
<perrito666> have you tried with the machine-N user again?
<voidspace> the answer is still no
<perrito666> Y U NO TRY
<rogpeppe> perrito666: AFAIK there are no special rights given to the user named "admin" that can't be given to other users too
<perrito666> rogpeppe: nothing would make me happier than the dump thing working with the regular password so lets hope the tag user has the right permissions
<perrito666> rogpeppe: nevertheless he will still have to fetch that pass
<rogpeppe> perrito666: i suggested a way, above
<rogpeppe> perrito666: (a one-line method)
<voidspace> rogpeppe: yeah, I'm trying that - thanks
<voidspace> just need to split the port out of info.Addrs[0]
<jam> rogpeppe: perrito666: I wouldn't think that we would default to configuring the mongo database with full access rights using the user's name and password. We expect them to connect via the API, so you can't just pass those details to "mongodump". However, using the machine-0 (the agent running the API server) seems to make sense to me.
<jam> It is a little clumsy to get the password, because the agent doesn't cache it directly, but you can get to it.
<rogpeppe> jam: actually, the agent does cache it directly
<jam> rogpeppe: on the api.Info as "tag, password" ?
<rogpeppe> jam: it's in state.State.info.Password
<rogpeppe> jam: so the api server actually (almost) has access to it already
<dimitern> jam, replied to your comments on the networking model
<jam> dimitern: k, I didn't finish reading it all, though I'm probably done for today
<rogpeppe> perrito666: what exactly did you try that didn't work?
<perrito666> rogpeppe: iirc, this was a couple of weeks ago, mongodump --oplog --loadsofparams --username <tag>
<rogpeppe> perrito666: was that to dump one db, or all of them?
<perrito666> all of them
<perrito666> $MONGODUMP -v --oplog --ssl --host localhost:PORT --username admin --password <agent.conf OldPassword>
<perrito666> that worked
<rogpeppe> perrito666: it's possible you might have to log in to one db - i remember something odd about that
<perrito666> and, again iirc, that with the tag as username didn't
<voidspace> if I don't copy the info it makes it easier to test, as I can modify it...
<rogpeppe> voidspace: ha, that is blatant abuse :-)
<voidspace> well, without that it's basically untestable
<voidspace> as far as I can tell
<rogpeppe> voidspace: really? won't it just connect to the local mongo?
<voidspace> rogpeppe: my code doesn't have it connect to an actual mongo - it just checks it uses the right params
<rogpeppe> voidspace: in which case, you just need to check that the params match, i guess
<voidspace> exactly
<voidspace> match what?
<perrito666> command Q is too close to command w
<voidspace> the default info.Tag is empty
<voidspace> so is the password
<voidspace> that is not a useful test
<rogpeppe> voidspace: the original info passed to Open
<voidspace> it's JujuConnSuite that creates the State(s) though
<voidspace> and it has an empty password and tag
<rogpeppe> voidspace: you can open the state yourself
<rogpeppe> voidspace: you can even add a new machine to log in as if you want
<rogpeppe> perrito666: do you know what version of mongo we use now?
<voidspace> rogpeppe: the existing test infrastructure gives me a state and api server and methods to make requests against that apiserver
<voidspace> I'm not especially keen to throw all that away
<rogpeppe> voidspace: you don't have to
<perrito666> rogpeppe: cant remember
<rogpeppe> voidspace: but you can connect to the state server again
<rogpeppe> perrito666: it's possible that --authenticationDatabase is the flag you're after, but it looks like that only appeared in 2.4
<rogpeppe> perrito666: i'm guessing that the reason that flag was added is that without it, there's no way to log in as a user in a particular db but dump all databases
<perrito666> rogpeppe: sounds like a reasonable guess
<rogpeppe> mgz, natefinch: do you know what version of mongo we can assume?
<rogpeppe> fwereade: ^
<perrito666> rogpeppe: fwereade left, he was not feeling well
<rogpeppe> perrito666: ah, ok
<perrito666> rogpeppe: is mongo updated in old servers?
<rogpeppe> perrito666: probably not
<rogpeppe> perrito666: you may have to call mongodump once for each db
<rogpeppe> perrito666: oh, no!
<rogpeppe> perrito666: hmm
<rogpeppe> perrito666: wallyworld's been looking at some related issues recently, i think
<natefinch> rogpeppe: 2.4.6 I believe is the minimum in precise
 * rogpeppe wonders if the mongodump version is updated with the mongod version
<rogpeppe> i've got mongodump version 2.2.0 but mongod version 2.4.9
<natefinch> no idea how the two versions are related
<voidspace> natefinch: hey, hi
<voidspace> natefinch: how are your teeth?
<natefinch> voidspace: they're fine.  But I was at the doctor :)
<voidspace> natefinch: hah, ok
<voidspace> natefinch: I hope everything is good
<natefinch> voidspace: yep
<mgz> rogpeppe: 2.4
<rogpeppe> mgz: thanks
<perrito666> natefinch: wanna jum into the hangout?
<natefinch> yeah, I'll have the kiddo in a minute, but I can jump in
<perrito666> natefinch: there is noone right now
<perrito666> although you can see me cooking
<perrito666> sinzui: are you available?
<sinzui> I am
<perrito666> sinzui:  I am trying to figure out why suddenly backup/restore tests are not working for HA
<perrito666> sinzui: did you change anything on the tests themselves before this broke or it was only juju related?
<sinzui> perrito666, Was that really broken...I think CI reported it could not put the state-server into HA
<sinzui> perrito666, ahh, I see some progress and a failure
<perrito666> sinzui: I http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore-devel/
<perrito666> something around 84 began breaking
<sinzui> perrito666, CI had 2 jobs stuck for 21 hours. It is catching up now. I think we should assume noting is broken until we have a report of tip
<perrito666> and then it all went wrong
<sinzui> perrito666, only the last test run, the one you found is about restore. All other failures are a failure to get into HA (or network/apt issues)
<sinzui> perrito666, We are still waiting to publish the test tools. I think in 2 hours we will know the real state of juju
<perrito666> sinzui: trust me on this one, it is broken :p I have just run that exact test on my local machine and it timeouts
<wwitzel3> rogpeppe: you have any suggestions for how/where I could safely turn off the api for a given state machine?
<sinzui> perrito666, :(
<perrito666> sinzui: good news is
<perrito666> its just a time thing
<rogpeppe> wwitzel3: from outside or inside the api server itself?
<perrito666> the replica takes forever
<rogpeppe> perrito666: yes, mongo is bog slow to replicate
<perrito666> I just let it run (I commented out the destroy env part on the cleanup) and it eventually started
<rogpeppe> perrito666: i dunno why - their protocol must be really crap
<wwitzel3> rogpeppe: inside, this is for when a server is brought back online, but has been replaced by ensure availability. We talked about it before and thought we might not need to stop the api.
<perrito666> sinzui: at least I get a 4 machines and 1 service all started after a moment
<perrito666> rogpeppe: yup
<sinzui> perrito666, The only change we have made to that test since it started failing was to extend to timeout to allow 15 minutes to get into HA
<wwitzel3> rogpeppe: but we actually have no idea how long this resurected machine has been offline, it could be very old, so disabling the api seems like a good thing to do.
<sinzui> perrito666, The previous change to the test was a month before to add the test scenario that is now broken
<perrito666> sinzui: well I know I am not giving you a decent time measure there, but I had time to make lunch (a chicken steak) eat it and it was started somtime around the time I was washing the dishes
<rogpeppe> wwitzel3: the easiest thing to do in that circumstance is just to never start the api server at all
<perrito666> sinzui: I think amazon is stretching a bit too thin
<sinzui> perrito666, Indeed. I am extending resources into other clouds. I was planning to use HP, but the apparent limit of 10 secgroups is troublesome
<rogpeppe> wwitzel3: if the state server's mongo connection is broken, then it will reconnect
<mgz> sinzui: we may be able to beg for an increase to that
<perrito666> sinzui: before getting this test to run I had to do the "find an AZ with enough machines"
<sinzui> mgz, the UI says we have 200. Juju or API is not seeing all 200
<sinzui> oh
<wwitzel3> rogpeppe: right, I've been trying that .. but I can't find a good place to do that .. I tried in jujud/machine.go , but there I can't do the proper check of HasVote || WantsVote because the machine doesn't actually exisit yet (as far as I can tell), so when I try to get the machine from st.Machine(Tag) .. it panics when trying to access any methods of the machine.
<voidspace> rogpeppe: ok, so I'm convinced that re-opening the apiserver state with new params and testing that they're used is a *better test*
<rogpeppe> voidspace: good :-)
<rogpeppe> wwitzel3: i'm having difficulty imagining a scenario where this issue is a problem
<perrito666> sinzui: would you be so kind to tell me where can I change that timeout?
<sinzui> perrito666, interesting, I think az3 was bring selected most of the time. CI was using az3 exclusively for tests, though we don't care where the test happen
<voidspace> I still don't think immutability is a god to be worshipped for its own sake however...
<voidspace> but my heresies aside
<voidspace> rogpeppe: how do I do that then? :-)
<wwitzel3> rogpeppe: if the state machine dies, is replaced by ensure-availability, then an upgrade is performed, then someone manually starts up that old state machine.
<sinzui> perrito666, I don't think that will help
<voidspace> rogpeppe: I can see where suite.BackingState is set, but that's magically plucked from the already created apiserver
<sinzui> perrito666, line I changed is in def wait_for_ha()
<perrito666> sinzui: as I said, I waited a stupid amount of time and it eventually came back
<wwitzel3> rogpeppe: wouldn't that cause potentially for commands from the client to go to a state machine that couldn't handle them?
<sinzui> perrito666, okay
<perrito666> sinzui: I know its not a solution
<rogpeppe> wwitzel3: presumably the issue you're worried about is that the machine goes down, we upgrade the environment, the machine gets resurrected, someone manages to connect to the API server in the 0.5s before it decides to upgrade itself
<perrito666> I just want to make sure I wasn't just lucky
<sinzui> perrito666, in test_recovery.py restore_missing_state_server() has this line
<sinzui> env.wait_for_started(150)
<wwitzel3> rogpeppe: well I didn't say it was likely, but if automated things are running, etc.. also I'm all for a good argument that it doesn't need to be done.
<rogpeppe> wwitzel3: if that's your concern, i honestly don't think it's worth worrying about. the worst that can happen is that *if* a client happens to hit that <0.5s window, that they use an older API version for a few moments before they're forced to reconnect
<sinzui> ^ perrito666 maybe change that to 1800 to allow 30 minutes?
<wwitzel3> natefinch: when you're back
<rogpeppe> wwitzel3: i'd be more interested in an argument to automatically terminate old state server instances that are now down
<wwitzel3> rogpeppe: ok, well I discuss with nate when he is back can't remember if he had a scenario as well
 * perrito666 runs with larger timeout
<wwitzel3> rogpeppe: like a cleanup command the user could run?
<rogpeppe> voidspace: i don't worship the god of immutability either, but *relying* on the fact that the Info method returns a reference to the info held inside the State seems not great
<rogpeppe> wwitzel3: i'm more thinking of something the provisioner could take care of
<voidspace> well, if that's its specified job it doesn't sound so bad
<wwitzel3> rogpeppe: I thought we never delete state machines without the user explicitly saying so
<rogpeppe> wwitzel3: that is currently the case, yes
<voidspace> but changing those params and then testing we get them back isn't as good a test as checking that "the params we opened the state with" are used
<wwitzel3> rogpeppe: that seems like a safe and sane practice to me
<rogpeppe> voidspace: to connect to the state server, use state.Open(suite.StateInfo(c))
<voidspace> rogpeppe: how do I make sure that the apiserver the test suite is using uses the *new state*
<voidspace> rogpeppe: that's the specific issue, not just connecting to the state server
<wwitzel3> rogpeppe: we don't know why this machine was manually restarted .. so having the provisioner delete it without input from the user seems a bit aggressive.
<voidspace> or rather, make sure it uses the new connection
<wwitzel3> rogpeppe: so I will discuss with natefinch again about potentially just leaving the api server running and see if there is any concern there. thank you
<rogpeppe> voidspace: it's pretty trivial to start an api server directly (see apiserver.serverSuite.TestStop for an example)
<voidspace> rogpeppe: it has an environ craeted from "environs.PrepareFromName", this seems to be what creates the apiserver
<rogpeppe> wwitzel3: before adding a bunch of complexity in this area, i'd suggest coming up with a concrete scenario where this issue could be a problem, and balance that against the likelihood of it actually happening and the cost of it if it did
<voidspace> rogpeppe: so I do have to throw away all the infrastructure provided by the existing test suite :-/
<rogpeppe> voidspace: it's an unusual test, so it requires unusual infrastructure. but it's only a few lines of code.
<wwitzel3> rogpeppe: +1, we may have one I am forgetting, thanks.
<rogpeppe> voidspace: alternatively, split the code into two - one part that takes an api address and does all the hard work of backing up, the other which just extracts the api address from the api and calls the former function
<rogpeppe> voidspace: then you can test the first one directly, and the second one by mocking the first one and checking that it gets called
<rogpeppe> voidspace: the bulk of the logic will be in the code that does the actual backing up
<voidspace> rogpeppe: that sounds better...
<voidspace> rogpeppe: I'm intriuged that it should only be a few lines of code though
<rogpeppe> s/api address from the api/api address from the State/
<rogpeppe> of course
<voidspace> rogpeppe: it would replace JujuConnSuite.setUpConn which is non-trivial
<rogpeppe> voidspace: starting an api server is only a single function call
<rogpeppe> voidspace: it's fine to have several api servers running at once
<voidspace> rogpeppe: and we need the client that can talk to it
<rogpeppe> voidspace: that's also just a function call
<voidspace> rogpeppe: so my current code is essentially this
<voidspace> resp, err := s.authRequest(c, "POST", s.backupURL(c), "", nil)
<voidspace> rogpeppe: can you sketch out the code I'd need to make that work against a new apiserver
<voidspace> rogpeppe: JujuConnSuite is a little mystical - the apiserver *seems* to be started as a side-effect of preparing the environment
<rogpeppe> voidspace: well, your actual client call will be something like st.Client().Backup(), right?
<rogpeppe> voidspace: it is, yeah. it's started by the dummy environ
<voidspace> rogpeppe: I'm not testing this through the client here
<rogpeppe> voidspace: actually, it shouldn't be started at Prepare time
<voidspace> rogpeppe: I'm hitting the api endpoint
<rogpeppe> voidspace: ok.
<rogpeppe> voidspace: doesn't that mean you'll need to duplicate the authRequest code in your test?
<voidspace> rogpeppe: that bit is easy, it's not much code
<rogpeppe> voidspace: i'd just test the client code rather than directly invoking the PUT request
<rogpeppe> voidspace: that's how most of the client requests are currently tested
<voidspace> rogpeppe: well, the charms upload code is tested this way
<rogpeppe> voidspace: and means you don't have to break layering to write the tests
<voidspace> rogpeppe: and this api endpoint is a special snowflake in the same way
<rogpeppe> voidspace: how so?
<voidspace> rogpeppe: they both return binary blobs so they're directly httpHandlers
<voidspace> rather than json apis
<rogpeppe> voidspace: i don't really see the distinction
<voidspace> well, sort of
<voidspace> rogpeppe: I'm just saying I used the charms code as the template for the server here - and the tests for the charm as a template for the tests
<rogpeppe> voidspace: the way that the request is phrased is part of the implementation detail of the API (modulo the fact that we actually publish API specs for non-Go clients)
<rogpeppe> voidspace: anyway... assuming you want to do this, it's pretty easy
<voidspace> even testing through the client we'd have the same issue - in a unit test we *don't* want to actually backup a mongo server
<rogpeppe> voidspace: you'll need to make the state server address a parameter to s.authRequest
<voidspace> so we need to be able to specify the params we expect to see
<voidspace> rogpeppe: it is already - through the call to buildURI
<voidspace> so that's easy
<rogpeppe> voidspace: i'd quite like a client-local test that the backup actually works tbh
<voidspace> we need a system test too
<voidspace> but that's not a good reason not to unit test the code
<voidspace> which is what I'm trying to do
<voidspace> a system test isn't complete without restore
<rogpeppe> voidspace: so, you start the api server, you get its address, you make the backup url from the address, you make an http request using that url
<voidspace> yep, great
<voidspace> rogpeppe: you have the bandwidth to join a hangout?
<rogpeppe> voidspace: sure, though i'm finishing soon
<voidspace> rogpeppe: me too, it should be quick
<voidspace> rogpeppe: I just feel like we're going round in circles and we can be done a lot quicker if we actually talk
<voidspace> rogpeppe: I'm in moonstone if you want to join
<voidspace> rogpeppe: https://plus.google.com/hangouts/_/canonical.com/moonstone?v=1402515430&clid=4D10946615DC3A35
<natefinch> perrito666: how goes the HA functional test?
<natefinch> perrito666: all fixed I presume? :)
<perrito666> strongly depends on your definition of fixed
<perrito666> but seriously, I am running it with a few changes to make sure I nailed the issue
<natefinch> that's awesome
<perrito666> sadly the error is at the end of the test
<perrito666> :p
<jcw4> mgz: the Actions Tag() implementation in names package: https://github.com/juju/names/pull/6
<jcw4> mgz: PTAL /
<jcw4> (after squash)
<jcw4> jam, or wwitzel3 I guess you're on call today too :)  https://github.com/juju/names/pull/6
<wwitzel3> jcw4: yep, I will take a look
<jcw4> thanks wwitzel3
<voidspace> wwitzel3: https://github.com/juju/juju/pull/114
<voidspace> yay, tests pass :-)
<voidspace> finally...
<voidspace> and they're sensible tests (finally)
<voidspace> and on that note
<voidspace> EOD
<voidspace> g'night all
<voidspace> see you tomorrow
<ericsnow> voidspace: yay!
<voidspace> :-)
<ericsnow> natefinch: are we meeting in the moonstone hangout?
<perrito666> sinzui: natefinch it was just a matter of time
<perrito666> or wasnt
<perrito666> sorry, false alarm, still hasnt finished
<natefinch> ericsnow: sorry, got distracted, yep
 * perrito666 bashes head on kb
<wwitzel3> natefinch: I'm on call review today with jam, so I've been doing that. Also I need to chat a bit about the API server for resurected start servers, specifically what the scenario was for why it should be turned off and if it is worth even more time/complexity in the code.
<sinzui> perrito666, natefinch canonistack's swift is failing. It failed the last 3 attempts to publish tools
<perrito666> sinzui: @more
<sinzui> perrito666, natefinch: I am contemplating how I can quickly work around this
<perrito666> uff, this is my personal hell
<sinzui> perrito666, I am pushing a hack to use the deb built by the previous failed job. It wont publish to canonistack.
<perrito666> sinzui: why is the tools publishing failing?
<sinzui> cannonistack swift is dying
<perrito666> ah uff
<sinzui> perrito666, CI is only as good as the clouds we test...and we know a lot about where each fails
<bodie_> https://github.com/juju/charm/pull/5 mgz / fwereade / anyone else, really simple
<natefinch> wwitzel3: we should try to hit up fwereade when we get the chance.  The idea was basically just that this makes for an unusual state for a state server to exist in, and that means it's one that's going to be less tested and less well-understood.
<sinzui> perrito666, abentley : Added a temporary hack to the publish-revision step.
<sinzui> perrito666, abentley : A proper separation of building packages from publication will take many days of unplanned work
<abentley> sinzui: ack.
<bodie_> anyone know if there's a suitable vagrant box for core juju dev?  I'm getting fed up with tweaking broken stuff, I have a remote box but I'd like to work locally
<natefinch> bodie_: we all use our base machines
<bodie_> I guess maybe I'll set up a vagrant box this weekend
<bodie_> I went to set some stuff up to use the juju local provider and I think I have a version conflict between some binaries since I rearranged my GOPATH/bin to the end of my PATH
<bodie_> I should've been working in a VM all along
<natefinch> nah, it's fine... the problem is likely that "which juju" returns the installed version from apt rather than the one you built
<natefinch> that screwed me for a while
<natefinch> I put my gopath at the head of my PATH... I never want anything on my machine to override something I've specifically built and installed
 * perrito666 just deleted juju from package
<bodie_> yeah, I wanted it to override it
<bodie_> because I wanted to use the apt-installed local provider, because I thought that was the only way to get the local provider
<natefinch> ahh no, local provider is just part of juju
<bodie_> probably dumb, whatever, it would just be easier to have a stable version to use on my workstation and a vm to dev in
<natefinch> the useful thing in juju-local is just the juju-mongodb
<natefinch> I don't know that the stable version is terribly more useful than the dev version.  We don't blow things up that often ;)
<bodie_> on that note, I'm getting failing tests on both my machines, one of which is supposed to be a fairly pristine dev box
<bodie_> maybe there's something left over from before the github migration, but something is wacky
<bodie_> also, the failing tests are different
<bodie_> jcw4 tells me there's work happening on the HA stuff right now?
<bodie_> and these appear to be mongo related, but it's hard to say
<natefinch> there's work happening on HA backup and restore.  But nothing that would affect the tests
<jcw4> fwiw, go test ./replicaset worked for me just now
<jcw4> bodie_: might be something transient on your machine
<bodie_> yeah, I'm clearing out /tmp with maximum prejudice
<sinzui> hi dev. Hp test might fail because we our juju configs don't implicitly select an AZ. We uses to specify az-3.
<sinzui> any ideas how we might trick juju into always placing machines in az3?
<perrito666> sinzui: I think axw might know how to answer that
<natefinch> perrito666: how goes? \
<perrito666> natefinch: still trying to figure out what broke (the thing is restored but for some reason replset fails to start properly)
<natefinch> perrito666: can you get on the machine to see the mongo log? It's usually a lot more informative than our logs in that case
<perrito666> is there a mongo log (besides the /var/log/juju logs)
<natefinch> yes.... /var/log/mongo maybe?  Not sure.. hang on
<sinzui> perrito666, the functional tests have started
<sinzui> We will no results in about 30 minutes
<perrito666> natefinch: nothing there, that why I ask
<perrito666> sinzui: great
<perrito666> I am trying to find out what in the universe is broken
<perrito666> something is once again re-adding the api addresses to machine-0/agent.conf
<perrito666> natefinch: ok, something on the bash script embedded in restore did not run...
<natefinch> ahh, ok, that's good to know
<natefinch> getting there
<perrito666> yeah, I ran the steps by hand and the machine came to life
<natefinch> timing issue maybe?  Doing stuff by hand is a lot slower
<thumper> morning
<natefinch> morning thumper
<perrito666> natefinch: might be, although there are a bunch of waits in the code it might be that, if something in mongo became even slower the script broke
<perrito666> thumper: morning
<thumper> o/
<perrito666> natefinch: perhaps its just the script's survival instinct trying to get me distracted debugging it instead of re-coding it in go
<natefinch> haha
<natefinch> I gotta run... do what you can, send an email to the dev list when you're done, maybe one of the guys down under can poke at it overnight
<perrito666> natefinch: ack
<natefinch> Thanks for the hard work.
 * thumper looks around for alexisb
<alexisb> thumper, crap sorry lost track of time
<alexisb> on my way
<menn0> anyone able to review this? https://github.com/juju/juju/pull/109
<menn0> a few people have made small comments but it hasn't seen a full review
<wwitzel3> menn0: I can take a look when I'm done with my current one
<menn0> wwitzel3: thanks
<thumper> cmars: just finishing off with alexisb
<cmars> thumper, ok
<sinzui> perrito666, I switched the functional tests to joyent. I don't know why the tests fail now on aws...and if they fail on joyent and hope they pass
<perrito666> sinzui: ack, I am running them against aws trying to pinpoint the bug
<sinzui> wallyworld, is there a undocumented secret to specify an availability zone that juju should use with HP?
<perrito666> I have a theory about mongo being the culprit, but I am not yet sure what in mongo
<sinzui> wallyworld, tests are failing because juju is getting az1 or az2, which don't have enough machines
<wallyworld> sinzui: um, there is i think but i'll need a moment to find what it is
<wallyworld> sinzui: have you tried using the zone option to bootstrap?
<wallyworld>  juju bootstrap --to zone=az3
<sinzui> wallyworld, This is what we are seeing. juju 1.19.4 clearly shows the passes are on az3 (which was where we use to test)
<sinzui> http://juju-ci.vapour.ws:8080/job/hp-upgrade-precise-amd64/1338/console
<sinzui> wallyworld, 1.18.4?
<wallyworld> sinzui: that zone option is new in 1.19 trunk
<sinzui> wallyworld, right
<wallyworld> for 1.18.3 i think you encode it in the region
<sinzui> I think we are rolling dice to get an az we can test on
<wallyworld> eg region=az3.blah
<sinzui> wallyworld, doesn't work with havana or icehouse
<wallyworld> oh, well that sucks
<wallyworld> so we either backport the zone placement stuff to 1.18 (which is not really viable) or we accept we need 1.20 for H and I
<sinzui> perrito666, I also switched all function tests to trusty
<sinzui> wallyworld, :/
<wallyworld> sinzui: the zone placement stuff is a lot of code
<sinzui> we cannot add features to old versions of juju. if we get the MRE we must be extra careful to honour Ubuntu's definitions
<wallyworld> ah yes, that's true
<wallyworld> so 1.18 will have to remain without the new zone placement stuff
<sinzui> maybe I can switch all hp testing to east coast us. it has just one zone
<wallyworld> worth a try i guess
<sinzui> might work. No one is using it
<sinzui> wallyworld, I also realised that though we can have 40 instances in hp, we have a mem limit of 15G. The smallest instance type has 1G, so it is impossible to get to even half of our number of serv ers
<wallyworld> :-(
<sinzui> wallyworld, oh, swift is dying in canonistack too. the canonistack tests passed because I severed the streams from aws or joyent
<wallyworld> sinzui: well that is kinda suboptimal. makes it hard when the underlying platform is flakey
<sinzui> Every cloud is ill. It is hard to say if juju is broken.
<wallyworld> yes it is sadly. i don't *think* juju is broken (apart from the confirm ha functional restore test issues)
<sinzui> wallyworld, I am afk for a bit. I am trying hp tests in region-b.geo-1, which has a single az. I hope juju 1.18.4 like it
<hatch> is there a saucy release of 1.18.x?
<perrito666> sinzui:  are you getting a lot of errors trying to deploy to ec2? (regardles of the present bug)
<perrito666> if not, could you make a run for me with debug=true for jujupy and appending --debug to juju restore and get me the output?
<bodie_> can I get this merged so I can update the deps properly?  https://github.com/juju/charm/pull/5
<bodie_> it's a REALLY simple change
<bodie_> or at least a LGTM -- it's a two or three-liner
<bodie_> just need to update deps to get the other PR in
<thumper> bodie_: done
<thumper> sinzui: I want to disable the user juju subcommand on the 1.20 release branch
<thumper> sinzui: when are you cutting that?
<bodie_> sweet
<bodie_> thumper, good with you if I just merge it so I can get that dep updated w/o two LGTMs?
<thumper> ack
<bodie_> as in acknowledged or as in "ack! no!"
<bodie_> heh
<rick_h_> thumper: howdy, got time to chat today?
#juju-dev 2014-06-18
<bodie_> would be great if I could get a quick LGTM so I can get this dep update in
<bodie_> https://github.com/juju/charm/pull/5
<bodie_> nvm, think I'm covered
<jcw4> I would appreciate a quick review on https://github.com/juju/names/pull/8 ... it's only documentation and variable name changes to clarify intent
<jcw4> diffstat +14 -14
<bodie_> just stepping away to eat, I'll get you after if nobody else has
<jcw4> bodie_: thanks
<rick_h_> thumper: will check back with you.
<jcw4> wallyworld: tx
<wallyworld> np
<waigani> thumper: you about?
<jcw4> wallyworld; new pull request https://github.com/juju/juju/pull/116  (diffstat +56/-43)
<jcw4> I'm afraid I don't know the irc nick for Horacio?
<wallyworld> jcw4: jut finishing another review, will look real soon now
<wallyworld> jcw4: it's perrito666 but he's likely asleep now
<jcw4> thanks wallyworld
<jcw4> perrito666: Sorry didn't know you were he :)
 * jcw4 steps away for a while
<sinzui> thumper, I want to do that in 2 days. Juju HA/backup-reatore is broken. If I must release, I will take a revision from last week. This what we had to do for 1.19.3 as well
<thumper> waigani: ya
<thumper> sinzui: ack
<thumper> rick_h_: hey, back now
<sinzui> perrito666, I not really. I see a few of these cases, but they resolve themselve in a 2nd run http://juju-ci.vapour.ws:8080/job/aws-deploy-precise-amd64/1323/console
<waigani> thumper: in the factory tests e.g. TestMakeUserAny, if I add c.Assert(saved, jc.DeepEquals, user), it fails
<waigani> thumper: ... mismatch at (*(*).doc.DateCreated.loc).name: unequal; obtained "Local"; expected "UTC"
<waigani> thumper: if I call user.DateCreated().Location().String() - it returns "UTC", even when in the doc the loc name is "Local"
<wallyworld> sinzui: there's some critical stuff landed this week which we can't ship 1.20 without, so if we do release 1.19.4 with a rev from last week, we'll need to do a 1.19.5 as well
<thumper> waigani: push up your latest, and I'll grab it and look here
<sinzui> perrito666, Merge pull request #79 from perrito666/translate_backup_to_go is the last good rev for backup-reatore. A lot of branches landed while joyent and ha stalled ci for 21 hours
<jcw4> wallyworld: you're a machine... thanks :)  I'll add those comments and split that test
<rick_h_> thumper: hey, let me know when you get a sec
<wallyworld> awesome, thank you
<sinzui> perrito666, commit ba83d11 is the last good commit for backup-restore
<thumper> rick_h_: I'm just munching right now, let me finish eating and help waigani
<rick_h_> thumper: rgr
<sinzui> wallyworld, I think that is a given, juju has not proven itself to be stable for user
<wallyworld> sinzui: i've not got to the joyent root cause of suckiness yet. how is hp looking?
<sinzui> in a word, *fucked*
<waigani> thumper: I don't have anything to push. Just add this test to testing/factory/factory_test.go and you'll see the problem: http://pastebin.ubuntu.com/7661265/
<thumper> ok, let me look
<wallyworld> sinzui: but we think it's because of cloud resourcing issues rather than juju per se right?
<sinzui> wallyworld, I region-b doesn't have writable provider storage. The test failed, This is the error I always see with HP http://juju-ci.vapour.ws:8080/job/hp-upgrade-precise-amd64/1349/console
<wallyworld> axw: morning. any chance of you looking at bug 1329477 today?
<_mup_> Bug #1329477: Destroying a juju machine with the manual provider, does not completely shutdown any services installed on that machine <destroy-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1329477>
<sinzui> wallyworld, since that error is with 1.18.4. I know the problem is Hp
<axw> wallyworld: yep, sure. just fixing up ec2 again, will take a look after
<wallyworld> axw: ta
<wallyworld> sinzui: that may be, still makes it horrible to know if juju is good or not
<sinzui> wallyworld, the functional tests that failed do have working stable and devel jujus. The only change I made to the functional tests was to extend the timeout
<waigani> thumper: the test name is out of date - I started with testing s.Factory.MakeAnyUser(), but the root, it seems, is in s.State,AddUser which is storing DateCreated with a local location
<wallyworld> sinzui: you talking about the "functional-*" jobs?
<sinzui> yes
<wallyworld> so they're all red right now except for one
<wallyworld> i guess that's with the smaller timeout
<waigani> thumper: do you want to pair?
<thumper> waigani: actually, what is your problem?
<thumper> yeah
<thumper> hangout
<thumper> waigani: start one
<davecheney> omg, state has it's own version of names.ParseTag
<davecheney>         for _, name := range bad {
<davecheney>                 c.Logf(name)
<davecheney>                 coll, id, err := state.ParseTag(s.State, name)
<davecheney>                 c.Check(coll, gc.Equals, "")
<davecheney>                 c.Check(id, gc.Equals, "")
<davecheney>                 c.Assert(err, gc.ErrorMatches, `".*" is not a valid( [a-z]+)? tag`)
<davecheney>         }
<davecheney> which has IDENTICAL FUNCTIONALITY
<waigani> thumper: https://plus.google.com/hangouts/_/gwtpvhcmdtc52fcnhi4c2bmglya?hl=en
<thumper> davecheney: colour me unsurprised
 * davecheney is running out of furnature to throw
<davecheney> this will be the next victim once I get this PR proposed
<davecheney> coll, id, err := state.ParseTag(s.State, m.Tag().String())
<davecheney> this function takes a tag, as a string, and parses it into it's kind and its id
<davecheney> m is a machine
<davecheney> where does m.Tag() get the string it returns from ?
<davecheney> by calling NewMachineTag(m.tag)
<davecheney> where m.tag is the string versino of the tag without the prefix
<davecheney> so all that nonsense is just to get the value of m.tag
<davecheney> and you know what the collection is, because you passed in a machine
<davecheney> so clearly it's the machines collection ...
<sinzui> wallyworld, http://juju-ci.vapour.ws:8080/job/hp-deploy-precise-amd64/ is a first time pass. My tuning the the env and extra cleanup of HP has had a positive affect.
<wallyworld> \o/ well done!
<sinzui> ha ha canonistack passes when I serve streams from other clouds
 * sinzui needs to file an rt tomorrow
<sinzui> I wrote a script last Friday to delete 10 terabytes of disk files left on Azure.
 * davecheney shrieks
<thumper> rick_h_: around?
<rick_h_> thumper: hanging in there
<thumper> rick_h_: wanna hang with me?
<rick_h_> sounds like a party
<rick_h_> your link or mine?
<thumper> https://plus.google.com/hangouts/_/gtnotdg6x5r34ae6zuuwuenssia?hl=en
<axw> wallyworld: can we have an "investigating" section under Doing in leankit?
<wallyworld> sure, sounds reasonable
<wallyworld> axw: done
<axw> wallyworld: thanks
<waigani> thumper: okay got it, you needed to return a pointer reference in order to be able to return a nil
<jcw4> davecheney: yep I stumbled across that today... I thought maybe it was a legacy of when the code was organized differently
<davecheney> jcw4: it's on my shit list
<jcw4> let me know if there's any grunt work you want me to do on that
<jcw4> davecheney:
<davecheney> jcw4: you can review my branch in an hour or so
<jcw4> davecheney: will do
<davecheney> basically i'm starting at state and working outwards
<jcw4> yes, I have a pending PR that touches some of that too
<davecheney> urgh
<davecheney> in state
<davecheney> or the api we have a thing called params.Entity
<davecheney> and an entity has a tag
<davecheney> why _isnt_ it a Tag
<davecheney> ?!?
<jcw4> You mean the Tag() that returns string :)
<davecheney> jcw4: that is also on my shit list
<jcw4> sweet
<bodie_> https://github.com/juju/juju/pull/118
<bodie_> Actions as a Hook in uniter
<bodie_> pretty simple
<jcw4> Addressed comments by wallyworld, PTAL https://github.com/juju/juju/pull/116
<wallyworld> jcw4: will do, thanks. i marked the previous version as LGTM as I trusted you to make the changes. i'll take another look though :-)
<jcw4> Oh, right... thanks and then I'll $$merge$$ it after you look.
<sinzui> I have procs and files left behind from a manual provisioning test. There is no juju or juju-mongodb running, but I cannot provision the machine. What can I delete
<sinzui> juju-db.conf
<sinzui> 10.245.67.135 is already provisioned ["juju-db.conf\njujud-machine-0.conf"]
<wallyworld> axw: ^^^^^^^^^^^^^^^
<wallyworld> jcw4: tests look much nicer, thanks for splitting them up
<wallyworld> sinzui: axw is working on that bug now
<jcw4> wallyworld: my pleasure tx
<axw> sinzui: weird, I couldn't repro. do you have steps to?
<sinzui> axw Not really. CI seems to be doing for the ppc manual tests
<sinzui> http://juju-ci.vapour.ws:8080/job/manual-deploy-trusty-ppc64-devel/
<sinzui> axw, I found jujud amd juju-mongod running on that machine and the failure. I deleted /var/lib/juju then killed the procs
 * sinzui doesn't know any other way to clean up after a failed provisioning
<sinzui> axw, I have had lots of failed provisioning on these machines because of egress access to download the tools and charms. IS fixed the egress access today
<sinzui> axw, ssh as jenkins@10.245.67.135
<axw> ta
<sinzui> axw export JUJU_HOME=~/cloud-city/
<sinzui> juju switch kvm-local-trusty
 * sinzui thinks
<sinzui> oh, axw , I have everything garbled
<sinzui> jenkins@10.245.67.134 is bootstrapping 10.245.67.135 with the  manual-trusty env
<axw> ok
<sinzui> axw, the staging key will get you in to look at the evidence
<axw> sinzui: FWIW, the right way to clean up a machine is "sudo killall -SIGABRT jujud"
 * sinzui pastes that into notes
<davecheney> https://github.com/juju/juju/pull/119
<davecheney> wow
<davecheney> sorry for the massive changeset
<axw> sinzui: also, "destroy-environment --force" will not terminate manually provisioned machine agents
<axw> (apart from the bootstrap one)
<sinzui> oh, then
<sinzui> I will need to add something to cleanup between tests
<axw> sinzui: manual should always do destroy-environment without --force to be safe
<axw> otherwise killall
<axw> yeah, I think that's safest
<axw> killall -SIGABRT jujud and then wait until it's gone
<jcw4> davecheney: my pull request that just went in may need a little work to get the same refactor applied
<jcw4> davecheney: since my pr already landed it may have to be merged in your pr :-/
<jam> mgz: ping when you're around
<davecheney> jcw4: no worries
<davecheney> 'tis but a small matter of typing
<jcw4> davecheney: hehe, but you only have so many keystrokes in your lifetime...
<davecheney> jcw4: thanks, thanks for that thought
 * davecheney prepares his resignation
<jcw4> >:-}
<davecheney> jcw4: thanks for the review
<davecheney> what TZ are you in ?
<jcw4> davecheney: US West Coast... UTC -7 right now
<davecheney> o/
<jcw4> \o
<jcw4> Its a fun timezone, I get to hang out with the cool kids down under and in Europe
<davecheney> \( ï¾â¡ï¾)/
<davecheney> i'm not child
<davecheney> i just act like one online
<jcw4> haha
<jcw4> me either/too
<jcw4> davecheney: you in NZ / AU ?
<davecheney> AU
<jcw4> cool
<davecheney> go, tests, go !
<jcw4> if you're really compulsive like me you have the console output of the CI on your screen
<davecheney> same
<davecheney> the job's not done til finished: SUCCESS
<davecheney> now to address some of those TODOs
<davecheney> i gotta get a faster machine
<davecheney> this branch has taken too long because of how long it takes to run/fix/run/fix/run/fix the tests
<davecheney> and before anyone mentions the cloud
<davecheney> this 2 year old x220 laptop is _faster_ than anything aws has to offer
<davecheney> and I have graphs to prove it
<davecheney> https://github.com/juju/juju/pull/120
<davecheney> one more before i sign off
<bigjools> jam1: your email about git diffs has (probably unintentionally) made me laugh a lot
<bigjools> or are you jam2 today...
<jam2> bigjools: probably jam2 by accident
<jam> there we go
<jam> bigjools: I can certainly appreciate the humor.
<bigjools> jam1: I know this particular horse has been flogged to death already, but that was just hilarious
<voidspace> morning all
<voidspace> jam: wallyworld: thanks for the reviews guys
<jam> voidspace: happy to help
<voidspace> jam: wallyworld: one point I disagree with
<jam> hopefully its useful feedabck
<voidspace> jam: yep, good stuff
<voidspace> especially moving the code out of the ServeHTTP method and restructuring
<voidspace> discussion of headers etc
<voidspace> jam: wallyworld: on moving the asserts into the "mockBackup" function
<voidspace> jam: wallyworld: I actually really dislike that
<voidspace> jam: wallyworld: I think it's much cleaner to have that function do the setup work / store the information about how it was called
<voidspace> and keep the asserts inside the body of the test method
<voidspace> if the issue is storing the parameters on the test suite I can provide another object to store them on and avoid polluting the suite
<voidspace> plus, state.Info() seems fine to me as a name (returning a state.Info). state.StateInfo() seems a bit redundant :-)
<TheMue> morning
<voidspace> I'll add these as comments for further discussion on the PR
<TheMue> dimitern: happy birthday
<jam> voidspace: StateInfo isn't what I'd use, but IIRC ian was asking for MongoConnectionDetails or something significantly more descriptive.
<jam> voidspace: I don't think we want to use suite level attributes as they cross contaminate tests
<jam> (the suite object is shared between all testts, which is how SetUpSuite can maintain its state)
<voidspace> jam: oh, yuck
<jam> voidspace: I'm personally fine with asserts in functions that are defined inside that test
<jam> voidspace: arguably the "right" way is to create a struct type, and a channel, call the body, in the body have it push the updated info out the channel, and read in from the channel in the rest of the test
<voidspace> jam: I prefer the pattern: call the code under test, then assert about how it behaved.
<jam> then it is asynchronous safe as well
<voidspace> heh
<voidspace> it's not asynchronous safe because of the patched module
<voidspace> at least in the sense that we can't parallelise the tests when we use PatchValue
<jam> voidspace: well once you've done the patching ,you can then call "go Backup()" and there isn't a race.
<jam> but no
<jam> we can't parrallelise 75+% of our tests
<voidspace> I could push a struct into a channel, it's slightly unnecessary complexity but I like it conceptually
<jam> voidspace: it isn't terrible to just have a var struct if you prefer that to the complexity of a channel
<jam> so "var data struct {backupName string; mongoPort int; ...}
<jam> data.backupName = backupName
<voidspace> yep
<voidspace> thanks, I'll get on those fixes
<jam> voidspace: its certainly better than the "data = []" tricks I did in python because of local vs global vs notlocal scoping
<jam> voidspace: IIRC nonlocal fit the use case, but wasn't available in the versions of python we were supporting.
<dimitern> TheMue, thanks! :)
<voidspace> jam: yeah, nonlocal solves exactly that problem
<wallyworld> voidspace: hi, sorry, my car broke down when i was getting my kid from school. had to wait for tow truvk etc, back now. that pattern i suggested is what we use everywhere else. it asserts the values passed into the function are as expected and makes more sense to me
<wallyworld> mgz: axw ok for standup now if you guys are free
<voidspace> wallyworld: hey, we get to sprint with you guys in Lexington
<wallyworld> \o/
<voidspace> wallyworld: which is cool
<wallyworld> very cool
<voidspace> wallyworld: do we have offices there?
<wallyworld> yes
<wallyworld> i'm told lexington is a hole though
<voidspace> right, makes sense
<voidspace> heh
<axw> wallyworld: heya. can you give me 5-10 please? wasn't expecting you back, need to get my daughter dinner
<voidspace> it's not far from Boston though
<wallyworld> middle of nowhere, nothing to do
<wallyworld> no gun ranges
<axw> lol
<voidspace> wallyworld: the Boston Python user group (biggest user group in the USA) is on Monday
<voidspace> wallyworld: ned batchelder and crew - it would be good if we can make it
<wallyworld> axw: sure, i may be eating myself, but we'll sync up i'm sure
<TheMue> whatâs the current status of the lexington sprint?
<wallyworld> voidspace: +1 to that
<voidspace> TheMue: it's been approved
<voidspace> TheMue: it's natefinch's team and wallyworld's team
<TheMue> voidspace: ok
<TheMue> voidspace: alexisb also asked who else of the other teams will join
<voidspace> TheMue: I didn't see anyone else on the sprint list
<TheMue> voidspace: ah, so maybe this plan changed
<mgz> wallyworld: no one in the standup?
<axw> mgz: wallyworld is having some dinner, he'll ping in a bit
<mgz> k
<wallyworld> mgz: axw: there now
<perrito666> morning
<jam> dimitern: thanks for the review. I believe I've responded to all your requests if you want to refresh https://github.com/jameinel/juju/pull/1
 * menn0 is back for more...
<dimitern> jam, cheers, i've reviewed it again, still LGTM
<jam> great. I plan on just merging the last of the series, once we've gone through them all.
<jam> thanks for starting on the next one.
<jam> menn0: run, run while you still can ! :)
<menn0> jam: it's ok... I had a lot of distractions today so am catching up now
<dimitern> jam, next one is lgtm as well
<jam> menn0:  you don't understandâ¦ its not safe for you hereâ¦ dimiterâ¦. oh my god, dimiter. He's reviewing all the codeâ¦ he's.. reviewingâ¦ *all*â¦ the codeâ¦. *sob*
<jam> thanks dimitern
<menn0> LOL!
<dimitern> jam, last one reviewed as well
<dimitern> fwereade, are you around?
<dimitern> fwereade, when you can spare some time, i'd really like you to review the networking model doc https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/
<jam> dimitern: fwereade said earlier that he isn't feeling very well today, so he may be in and out a bit
<jam> I still need to finish looking at that doc as well.
<jam> dimitern: I responded to the idea about FacadeVersions.
<jam> my personal opinion is that a map is not a structure for the API itself.
<dimitern> jam, ah, right ok
<dimitern> jam, why?
<jam> dimitern: it seems odd to me that the textual byte stream requires that results must be parsed into a dict
<jam> yes that is what we actually do with it once we've gotten it
<jam> but it doesn't seem like the stream of data itself is a map
<dimitern> jam, i'm a bit thick today is seems :/ what's the byte stream textual rep has to do with it? :)
<jam> dimitern: so the API returns data on the wire, which we then read, right?
<dimitern> jam, it is essentially a map name-to-versions, right?
<dimitern> jam, yep
<jam> It seems odd to me that you would require that to be a JSON object type, rather than a list type.
<dimitern> jam, if it's an actual map, we can do fast lookups with the results directly, no need for helper methods
<jam> We do use it as a dict type
<jam> dimitern: well, the first thing we do is put it into a map for storing, but that is just iterating the result and storing it.
<dimitern> jam, it's not a dict per se, it's an object
<dimitern> jam, right, but if that's something we need to do all the time on the client it seems sub-optimal
<jam> dimitern: well it is being done anyway regardless of whether it is explicit or implicit
<dimitern> jam, i.e. if the most common operation on these results will be "what versions has the facade named Foo?"
<jam> dimitern: well, I liked that it was a sorted list, fwiw
<jam> which you can't easily code into a map structure.
<dimitern> jam, wait a sec :)
<jam> dimitern: FacadeRegistry.List() returns a sorted list of the versions
<dimitern> jam, are we talking about the same things here? I mean the FacadeVersions slice, not the Versions slice inside it - the latter will be sorted still if []FacadeVersions becomes FacadeVersionsMap
<dimitern> jam, the only thing we'll lose with a map is the keys can't be sorted
<jam> dimitern: it is a sorrted list of names each containing sorted versions.
<dimitern> jam, so the names being sorted as well is nice, but doesn't contribute much (except for displaying them perhaps, which can be done with sorting), and makes lookups harder
<jam> and putting that *into* a map is a rather trivial loop which is exactly what is done in line 48 of state/apiserver/state.go where you commented about us sorting the version ints.
<wallyworld> jam: any chance of a review? https://github.com/juju/charm/pull/6 fixes critical 1.19.4 bug 1330919
<_mup_> Bug #1330919: local charm deployment fails with symlinks <charms> <regression> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1330919>
<wallyworld> or fwereade
<jam> wallyworld: fwereade is mostly out sick today, I'll give it a look
<wallyworld> ok, thanks, whenever you are free
<jam> wallyworld: should we be checking that the target is inside the REPOSITORY ?
<jam> I'm generally hesitant about just letting symlinks point anywhere
<wallyworld> jam: hmmm. i could do
<wallyworld> i guess i never figured it mattered
<jam> wallyworld: I'm not *positive* about it, since maybe its ok
<jam> but I'd like us to *think* about it first
<jam> wallyworld: would we want to just use "filepath.EvalSymlinks" ?
<jam> http://golang.org/pkg/path/filepath/#EvalSymlinks
<wallyworld> probably, i'm not very familaiar with those api calls
<wallyworld> i can tweak it
<wallyworld> jam: inside the dir.go code, i don't think we even know what REPOSITORY is
<wallyworld> so i guess any check would have to be external to that
<jam> wallyworld: sure. as for EvalSymlinks, I just mean we can potentially replace the resolveSymlinkRoot entirely with just rootPath, err := filepath.EvalSymlinks(rootPath)
<jam> technically it resolves any symlink anywhere along the path, but I don't think that is a problem for us.
<jam> and it means less code we have to write/maintaine
<wallyworld> jam: yeah, just tried, that, test failed. but i'll make it work
<wallyworld> jam: also, we seem to have a plethora of these new juju repos. the new lander just does juju/juju. tarmac doesn't handle them either i don't expect
<wallyworld> looking at previous pr's, it seems people landed by hand perhaps
<jam> wallyworld: thats my guess
<jam> we *should* have them all under the bot,but people who have been pulling stuff out of Juju haven't been diligent about it
<jam> at least IMO
<wallyworld> yep, +1. that was my thought too, just wanted to check
<natefinch> MOrning all
<jam> well, maybe in your opinion as well :)
<jam> morning natefinch
<voidspace> natefinch: morning
<dimitern> jam, ok, still LGTM though, I'd rather have this landed, we can refactor it later if need be
<jam> dimitern: can you LGTM the juju/juju pr?
<jam> https://github.com/juju/juju/pull/100
<stub> wallyworld: (as the bug reporter) I think symlinks should be followed in the repository blindly, but symlinks in the charm should be contained within the charm. It is interesting currently that $JUJU_REPO/precise can be a symlink but $JUJU_REPO/precise/foo cannot (fails per bug report)
<wallyworld> stub: yeah, that's how i've done the fix
<dimitern> jam, done
<jam> dimitern: thanks, I'll go look at the networking doc now
<dimitern> jam, TheMue, standup?
<TheMue> ouch, yes, comming
<wallyworld> stub: that bug is fix committed; if you run from source you can try it out. be sure to get the latest juju/charm code as well as juju/juju
<stub> ta
<mgz> wallyworld: it's just on the bundling up side right, so no faffing with uploading alternative tools to test?
<vladk> dimitern: please, take a look https://github.com/juju/juju/pull/121
<wallyworld> mgz: yup
<wallyworld> mgz: i think so
<wallyworld> or hangon
<wallyworld> no
<wallyworld> i think you may need new tools too, not sure
<wallyworld> i did test and seem to recall i needed to redo the tools
<wallyworld> could be wrong
<jam> yay, it has finally landed !!
<jam> vladk: while you are waiting for dimitern's review of your work, it would probably be helpful to have you look over his networking document: https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/edit?disco=AAAAAJrgVD8#heading=h.8afzt9469s6q
<dimitern> vladk, you've got a review, ping me if you have questions please
 * perrito666 notices travel agency got something wrong and is trying to send him to london
<perrito666> jam: you should also look into gitk/gitg which makes git trees navigation a lot less painful
 * perrito666 answers mails via irc, brain wires crossed
<jam> perrito666: it still doesn't handle my diff problem well, as they do the equivalent of "git show"
<jam> I have tried
<jam> I've also tried Atlantassian's SourceTree
<perrito666> jam: mm, I thought they had more features
<jam> which is pretty nice, but doesn't do what I want
<jam> perrito666: so you *can* select a range, and eventually get what you want, but it is clumsy
<jam> the default of just selecting a rev shows you the equivalent of "git show"
<perrito666> ok, syntax highlight in the comments is nice
<mfoord> damn internet connection
<perrito666> mfoord: again?
<mfoord> perrito666: still
<mfoord> perrito666: my line has degraded to 1.6mb downstream
<mfoord> perrito666: I haven't sorted it yet
<mfoord> perrito666: got on the case a bit this morning - but of course tech support from my isp is awful
<mfoord> anyway
 * mfoord lunches
<wwitzel3> natefinch: oops, just looked at the clock
<wwitzel3> natefinch: hopefully you forgot too ;)
<natefinch> wwitzel3: yeah, was busy helping with the kids, forgot we had a new meeting this morning
<natefinch> wwitzel3: we can do it after the standup
<ericsnow> natefinch, wwitzel3: standup in an hour, right?
<wwitzel3> ericsnow: correct
<natefinch> ericsnow: yep
<bodie_> morning all
<jcw4> morning bodie_
<natefinch> wwitzel3, ericsnow, voidspace, perrito666: the TOSCA meeting is running over, so we will need to move the standup back about half an hour
<perrito666> natefinch: ok
<tasdomas> I'm having a little trouble understanding the relation between state/api, state/apiserver and state/apiserver/client in juju
<jcw4> tasdomas: me too; I think the doc/api.txt file may help some but I'm a little fuzzy about that myself
<voidspace> yay, internet back
<voidspace> for now anyway :-/
<voidspace> I *really* need a dongle
<voidspace> I also need the time to go and buy one
<voidspace> maybe tomorrow during the day as I can work late tomorrow
<wwitzel3> if only there was some way you could just order one online and it would arrive at your home
<voidspace> wwitzel3: yeah, because telecoms company don't *deliberately* make that shit confusing to buy online
<ericsnow> wwitzel3, voidspace: :)
<wwitzel3> voidspace: good point :)
<voidspace> wwitzel3: plus, if I order it today it will probably arrive just after we've left for France on Saturday morrning
<voidspace> wwitzel3: I did look online and the contract details available were either "too short to be useful" or "too long to be humanly possible to read"
<wwitzel3> perrito666, natefinch: standup?
<wwitzel3> voidspace: I guess you too :P
<voidspace> heh, ok
<natefinch> yep
<voidspace> jam: wallyworld: I've pushed changes to the backup-download PR
<voidspace> https://github.com/juju/juju/pull/114/files
<voidspace> ah, now I have internet I see I got an LGTM
<voidspace> wallyworld: thanks!
<jcw4> voidspace: internet is such a sweet thing
<voidspace> jcw4: heh, it certainly is :-)
<tasdomas> where does state/apiserver/client fit into the go stack described in doc/api.txt ?
<jcw4> fwereade: ^^ (or anyone else with state knowledge since I believe fwereade is under the weather today)
<mgz> tasdomas: it's the api server side for client-oriented api calls
<mgz> doc/api.txt is all future-tense - I don;t think it's ever been updated from when the api actually got implemented, so probably isn't as clear as it could be
<tasdomas> mgz, and state/api is the client-side api end-point?
<mgz> yup, that's it
<tasdomas> mgz, I don't see any tests that call the state/apiserver/client calls directly (they seem to all test that via state/api) - am I missing something?
<mgz> tasdomas: the client package there is a little different to all the other apiserver bits, they get tested through the client side only, not at both end
<tasdomas> mgz, right - that makes things a bit clearer, thanks
<tasdomas> mgz, a testing-related question, if I can bother you with it
<tasdomas> mgz, in https://github.com/juju/juju/pull/115 I modify the EnsureAvailability call to make it a bulk API call
<perrito666> lunch bbl
<tasdomas> mgz, is there a way to patch the EnvironTag value in the state in state/api ?
<tasdomas> mgz, I want to add a test that sends an incorrect environment tag, but since it's a private state property, I think it's not patchable
<mgz> tasdomas: can you not do it via state/conn_test.go ? that has some ability to do fiddling under the coversd
<mgz> dimitern may have better ideas on how you want to check that something is a bulk call, if he's around
<tasdomas> mgz, thanks - I'll pick it up with dimitern tomorrow then (EOD)
<jam1> tasdomas: api.Open takes an api.Info object which specifies the EnvironTag to pass
<jam1> though Open should fail if you pass an invalid one
<jam1> you're trying to override it after the fact?
<jam1> tasdomas: if its a state/api test, you could put a helper in state/api/export_test that let you explicitly poke at the internals
 * natefinch is finally having breakfast
<jcw4> natefinch: you on the west coast today?
<jcw4> ;)
<natefinch> heh nope.  Just busy morning
<perrito666> man I wish I understood flight reservation sofware encoding
<jcw4> software encoding?
<natefinch> The second best thing about having a sprint nearby is not having to do reservations and all that BS
<perrito666> jcw4: they use this very old console soft
<perrito666> like almost serial printer console old
<jcw4> yeah?
<perrito666> and each line of information is a fixed width columns set
<perrito666> so, you get things like this as a result
<perrito666> 1  *LA2422  H  05JUL  COR  LIM   0455  0700   E0/320
<perrito666> now, I understand most of it :p
<perrito666> but the * in front of LA is amistery
<perrito666> the H too
<jcw4> I think it means you're on a TSA watchlist
<perrito666> and the ocasional numbers in a column that is not there is also a mistery
<jcw4> I'm always interested in those codes too... they sometimes give information that isn't published anywhere else
<perrito666> jcw4: I am mostly interested because I am trying to decipher if I want or not that flight
<perrito666> jcw4: you can make a tourism operator course, they teach you to use that thing
<natefinch> can't you just use kayak.com like everyone else? :)
<perrito666> everything about tourism is so 80s
<jcw4> haha
<perrito666> I use despegar.com
<perrito666> natefinch: but this is the email sent to me by the tourism guys :) which assume I also did the software course
<perrito666> same happens to me when I go to a travel agency for vacations, they print me this monospaced font paper and give it to me :p
<jcw4> perrito666: well, good luck with that.
<natefinch> perrito666: just look up the flight number online
<perrito666> natefinch: yup did that, seems normal :p
<voidspace> natefinch: I've found out that they're tinkering with the internet connection for the village
<voidspace> natefinch: adding "new boxes", so it will be ropey for at least another week
<voidspace> natefinch: and then hopefully better
<voidspace> natefinch: but I'm away next week *anyway*
<voidspace> natefinch: so hopefully all good when I get back
<voidspace> good to have an answer anyway
<ericsnow> voidspace: yay
<ericsnow> voidspace: it wasn't my fault ;)
<voidspace> ericsnow: hah, I'm sure karmically it's still your fault somehow...
<ericsnow> voidspace: no doubt :)
<natefinch> voidspace: yeah, nice to know why it's happening, and nice to know it'll be done eventually
<voidspace> yep
<perrito666> voidspace: they are changing the 6eths switch for an 8eths one :p
<voidspace> perrito666: I don't know what that means
<voidspace> but it sounds good
<perrito666> voidspace: I was implying that the internet of your whole village was held by a 6port switch :p
<voidspace> perrito666: heh, I doubt we even get six...
<perrito666> when I moved to my current city (capital of this state) one of the largest providers of dsl had such bad config that we where on a LAN I could fetch things from the shared MyDocuments folders from every other client on my subnet
<perrito666> sinzui: any luck running in another provider?
<sinzui> perrito666, I just got more RAM for HP. I will move the functional-ha-backup-restore to HP and hope for a pass
<perrito666> sinzui: I am having hell running on ec2
<sinzui> perrito666, I think trusty is more brittle than precise on ec2
<sinzui> I moved those tests back to precise
<perrito666> I get a machine to create the state machine but it blows when trying to create the cs:ubuntu one
<voidspace> right, BBQ time!
<voidspace> EOD
<voidspace> g'night all - see you tomorrow
<natefinch> night voidspace
<perrito666> nite voidspace
<voidspace> o/
<sinzui> perrito666, CI isabout 2.5 hour from running the failing test with tip. I started a run against hp with the last commit from a few hours http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/168/console
<perrito666> Ill go do some biking to cool off my head then see if I can finally crack this issue
<natefinch> perrito666: good luck
<natefinch> ericsnow: just catching up on email... about the CLI for restore... it sounds like the question is basically whether or not you have to juju bootstrap before you can call juju restore.  Is that a correct summary?
<natefinch> ericsnow: or were you thinking something like juju bootstrap, juju upload-backup, juju restore?
<ericsnow> natefinch: I'm not sure what the use case is for more than one command
<ericsnow> natefinch: I was talking more about the API client side of things
<natefinch> ericsnow: ahh
<natefinch> ericsnow: it seems like all we really need is an http API called "Restore" that can take a file.  If it can restore, it does.  If it can't it says so.
<ericsnow> natefinch: that makes sense to me for the immediate term
<ericsnow> natefinch: and it may be all we need long-term too :)
<natefinch> ericsnow: YAGNI :)
<ericsnow> natefinch: exactly!
<sparkiegeek> if I have two units of the same subordinate service "hulk-smashed" onto a single machine, will I get hooks being run concurrently? (e.g. unit/0 hookX and unit/1 hookX being run at the same time)?
<sparkiegeek> or does juju guarantee that they'll be serialised
<natefinch> sparkiegeek: juju guarantees nothing if you have hulk smashed
<sparkiegeek> natefinch: so two agents = operate independently?
<natefinch> sparkiegeek: that being said, I'm not sure of the current behavior right now, it's possible they'll be serialized.
<ericsnow> natefinch: nice :)
<sparkiegeek> natefinch: anecdotal evidence suggests they *are* but I'm trying to hunt down a race condition which might be caused if they're not :)
<sparkiegeek> (1.19.3 FWIW)
<natefinch> marcoceppi: do you know if two units of the same subordinate service will have their hooks serialized?  or is it possible they'll get run at the same time?  I don't actually know how hooks are serialized?
<natefinch> sorry... ^^ if they are hulk smashed on the same machine
<marcoceppi> wow, hulk smashing the same subordinate on a machine twice, sounds like someone is asking for it
<natefinch> basically what I said
<marcoceppi> natefinch: afaik, it's serialized at the unit level, not the service level, so you could probably have two hooks on a unit running simultaneously
<marcoceppi> I'd totally chaulk this up to "it's working as designed and you're wrong"
<sparkiegeek> marcoceppi: FWIW I was asking what the design/behaviour was, not for a change :P
<marcoceppi> well, this is my understanding, I've not confirmed this
<marcoceppi> but it should jsut follow normal unit event dispatching, there's no special case for juju and events esp wrt hulksmashing
<marcoceppi> I should also mention IANACD
<natefinch> haha
<sparkiegeek> marcoceppi: noted :)
<sparkiegeek> it *seems* like events are serialised
<sparkiegeek> I was hoping to shortcut lots of testing by asking you guys :)
<marcoceppi> I'm under the impression they are serialized on a single unit basis and not nessiarily per service. I could be completely wrong though
<sparkiegeek> marcoceppi: thanks. That was my assumption too but logs suggest that they are serialised. Ho hum
<sinzui> natefinch, We have a ppc64el/gccgo regression https://bugs.launchpad.net/juju-core/+bug/1331744
<_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1331744>
<sinzui> ^ we may need to wait for wallyworld or Dave to wake up
<natefinch> sinzui: weird
<natefinch> sinzui: that is some unfortunately gnarly code
<natefinch> jam1 or jam2 will likely have a better understanding of it, I think.
<jam2> natefinch: it is likely soemthing funny with the api versioning stuff, but I'm about to fall asleep. I assigned it to myself, but if wallyworld or someone else wakes up to it first, they are welcome to look at it.
<natefinch> jam2: ha, yeah, pretty late there.  OK
<perrito666> sinzui: back, the build failed for a reason I dont understand
<sinzui> perrito666, It failed because HA wasn't achieved in 15 minutes or was it 20 minutes
<perrito666> sinzui:  did you see that it marked 3 machines just when it died?
<sinzui> I did
<sinzui> perrito666, I was going to let CI just play the test with the current build...
<perrito666> something interesting I noticed the other day, I sshd into the machine as it was doing the ha sync and the load was on the skyes
<sinzui> perrito666, but there is a gccgo problem with the current build...the arm64 builder took 3 hours.
<perrito666> man, there is a huge load of bad karma with this issue
<sinzui> I am going to reboot the arm64 machine. I had to do that with the ppc64el machine because all the memory and disk was used up
 * perrito666 tries to reproduce the test by hand
<sinzui> or not. The machine says it is healthy now
<sinzui> perrito666, I will run the test again...I want to extend the time to get to HA
<perrito666> give it time, I am curious to know if the test goes trough regardless of the lag of HA, to see if I can finally figure out where is the problem
<perrito666> I read the commits around the first failures, there is no indication of anything that goes even near restore
<perrito666> sinzui: my local test failed, it restored the machine but status reports the old info
<sinzui> :/
<perrito666> is, as if the mongo query runs but takes no effect
<perrito666> but when I go to the shell and do it by hand it works
<perrito666> mm strange
<ericsnow> perrito666: perhaps a difference in shell environment?
<perrito666> yes, that is my current line of thought, mongo's client man page says that there might be differences between what is available to --eval and in the actual shell
<perrito666> perhaps there was a version change in mongo that affected us
<perrito666> Ill try something
<thumper> morning folks
<thumper> omg, so many emails...
 * thumper needs to get some tweaking on pull request emails.
<lifeless> thumper: heh, I read that as twerking on pull request emails
<waigani> morning thumper
<thumper> lifeless: ha
<thumper> morning waigani
<mattyw> thumper, morning
<alexisb> mattyw, you must be working the late shift
<mattyw> alexisb, I'm hoping to grab thumper to ask a couple of questions, I'm going to make up for it tomorrow morning :)
<thumper> mattyw: hey, otp with fwereade
<alexisb> :)
<mattyw> thumper, no problem, ping when you have 5 minutes
<perrito666> large threads that include hazmat and fwereade should arrive to my kindle instead of my mailbox :p
<fwereade> perrito666, oh, I can get *much* worse if it comes to it ;p
<perrito666> aghh juju robustness is biting me
<perrito666> I edit out any possible reference to old apiservers from the machine and it comes back
<thumper> mattyw: I have 5 minutes
<thumper> perrito666: hahaha
<mattyw> thumper, ok cool - I'll just type questions then if that's ok?
<thumper> sure
<mattyw> thumper, the change-password command, at the moment entering an empty password (or just calling juju change-password) will cause a random one to get generated, should I change this to expect the user to input the password, and have a flag for generating a password?
<thumper> mattyw: hmm...
<thumper> mattyw: to be honest, not quite sure...
<thumper> mattyw: I have been spending a lot of time looking at the whole identity vs. user issue
<thumper> mattyw: and all the stuff we have now is likely to change :-)
<mattyw> thumper, that's fine, change is good
<thumper> mattyw: we have two main reasons for change password
<thumper> 1) as a user I'd like to change my password to something meaningful to me (or in my lastpass)
<thumper> 2) as an admin, I want to reset another user's password
<thumper> the problem is right now, everyone is an admin
<thumper> as we don't have the permissions in there yet
<thumper> so, for 1) we need to think "why is the user asking?"
<thumper> perhaps we should always prompt, but accept empty to mean "please generate one for me"
<mattyw> having a prompt means the user's password doesn't appear in the bash history - but then again the password is stored in plain text in the jenv anyway
<thumper> sure, for now
<thumper> I think prompting is the correct approach
<mattyw> But my next question was going to be: At the moment the setpassword call in the apiserver only allows you to change the password for the user you're logged in as
<thumper> right...
<thumper> which doesn't allow use-case 2
<mattyw> and I wonder if that's a good approach or not - I will have to change.... - yeah exactly
<mattyw> change-password and access-file feel like very similar commands to me
<mattyw> thumper, isn't your standup coming up - shall I join it?
<thumper> I think... that we should make change-password a bulk call where is specifies a list of users/passwords
<thumper> and worry about permissions later
<thumper> mattyw: if you like
#juju-dev 2014-06-19
<menn0> davecheney: so did I do something wrong to cause that panic on power? I've gone back and looked at that code and nothing's jumping out at me.
<davecheney> menn0: no idea
<davecheney> haven't looked
<davecheney> yet
<davecheney> fighting with the bot for my previous commit
<davecheney> menn0: if three was a mistake, it would relate to tools selection
<davecheney> and an unchecked error path
<davecheney> this is just suposition and does not indicate assignment of blame
<menn0> davecheney: hmmm, I'll wait to see what you figure out. Let me know if I can help.
<davecheney> this bug is all fucked up
<davecheney> https://bugs.launchpad.net/bugs/1331744/+attachment/4134402/+files/run-unit-tests-ppc64el.log
<_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1331744>
<davecheney> is just one long line
<davecheney> no \r's
<thumper> davecheney: view source
<thumper> davecheney: it is being rendered as html
<thumper> davecheney: it should have the content type of "text/plain"
<thumper> but it doesn't
<davecheney> :sadtrombone:
<davecheney> grr, mongo keeps shitting itself in the tests
<davecheney> panic: Session already closed
<davecheney> goroutine 3633 [running]:
<davecheney> runtime.panic(0xa66ca0, 0xc2103c9720) /usr/lib/go/src/pkg/runtime/panic.c:266 +0xb6
<davecheney> labix.org/v2/mgo.(*Session).cluster(0xc210a96c60, 0xc21035a820) /home/ubuntu/juju-core_1.19.4/src/labix.org/v2/mgo/session.go:1153 +0x66
<wallyworld> thumper: reschedule 1:1 after core meeting?
<davecheney> wallyworld: axw is there an issue for these mgo panics ?
<davecheney> https://github.com/juju/juju/pull/120
<davecheney> 3 in a row trying to land this PR
<axw> yes
<axw> there's a couple
<axw> apiserver seems to fail more than others
<thumper> wallyworld: yeah...
<davecheney> is it possible to get a build plan that runs with -race ?
<davecheney> it'd be a very small amount of SABDFL's massivel pile of SSL money that there is a race in there
<davecheney> s/be/bet
<axw> I've run the race detector and already fixed the races - sadly they were not related to the failures
<davecheney> :(
<axw> do I get SSL money now?
<davecheney> axw: sure, it's in the Isle of Man, i'll wait
<perrito666> sinzui: it is very naive for me to expect for you to be still here right?
<sinzui> perrito666, i am here. I have no social life
<perrito666> sinzui: neither do I, that is why I am also here
<perrito666> sinzui: how flexible is CI (can you replay old rev tests?)
<sinzui> I can play old revs, though only a few tests can play a specific rev. I often need to setup ci to retest a revision, but that is all the tests
<sinzui> perrito666, which rev do you care about?
<sinzui> I assume you want the backup-restore tests run again...they use the published streams so the early part of the test suite needs to be run to put those streams in place
<perrito666> sinzui: r0cbd5b87 its the last to have succesfully run
<perrito666> sinzui: I am trying to reduce the possible culprits of this odd breakage
<sinzui> I see it
<perrito666> sinzui: if r0cbd5b87 doesnt run I think I will say its something outside juju that changed if not I can look inside juju, in any case I can produce a fix somewhere tomorrow but I would really like to go less blind about it
<sinzui> perrito666, I ran the tests on Hp and aws
<sinzui> and switched between trusty and precise
<sinzui> perrito666, We can wait for CI to run that revision, I can could publish an alternate stream from these debs: http://juju-ci.vapour.ws:8080/job/publish-revision/496/
<perrito666> sinzui: well in the beginning apt-get upgrade is run, so that could produce a version change although it should not
<sinzui> perrito666, the tools/streams we tested where made from those debs. The function tests use streams, so we need to republish to test again
<perrito666> sinzui: as you wish, let me know if you can replay r0cbd5b87, if you cant I think I can do a fairly decent work reproducing the test conditions but will be tomorrow
<perrito666> ok I think its better that I do it then
<perrito666> its a good thing I neved deleted that script
 * perrito666 creates cheap stream
<perrito666> sinzui: running testsuite with the old revision, will see the result tomorrow, I am going to bed now
<wallyworld> thumper: want to get it over and done with now?
<thumper> wallyworld: yeah
<thumper> wallyworld: just use the hangout on our normal meeting
<wallyworld> already there
 * thumper-cooking back in an hour or so after kids have eaten
<davecheney> menn0: the bug is herer
<davecheney>         status, err := apiclient.Status(c.patterns)
<davecheney>         // Display any error, but continue to print status if some was returned
<davecheney>         if err != nil {
<davecheney>                 fmt.Fprintf(ctx.Stderr, "%v\n", err)
<davecheney>         }
<davecheney>         result := newStatusFormatter(status).format()
<menn0> aha
<davecheney> i'll fix
<menn0> funny because that's mostly pre-existing code
<menn0> I guess the way that status is used has changed
<davecheney> there may be several errors
<davecheney> i don't understand why comment 2 is unrelated to the original error
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1331744
<waigani> menn0, thumper-cooking, davecheney: user info cmd PR ready for review: https://github.com/juju/juju/pull/126
<_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1331744>
<davecheney> s/error/bug
<waigani> I had to rewrite the branch because rebasing made a mess of it
<davecheney> run_test.go:293: c.Check(testing.Stdout(context), gc.Equals, string(jsonFormatted)+"\n")
<davecheney> ... obtained string = "[{\"Error\":\"command timed out\",\"MachineId\":\"1\",\"Stdout\":\"\"},{\"MachineId\":\"0\",\"Stdout\":\"megatron\\n\"}]\n"
<davecheney> ... expected string = "[{\"MachineId\":\"0\",\"Stdout\":\"megatron\\n\"},{\"Error\":\"command timed out\",\"MachineId\":\"1\",\"Stdout\":\"\"}]\n"
<davecheney> yay, map ordering errors
<davecheney> hmm, that is odd, these should always be sorted
<waigani> davecheney: jc.SameContents ?
<davecheney> i think both are strings
<davecheney> not slices
<waigani> oh right
<davecheney>  % juju destroy-environment -y $(juju switch)
<davecheney> uh oh
<davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap --upload-tools
<davecheney> uploading tools for series [precise trusty]
<davecheney> Launching instance - i-4376dc11
<davecheney> Waiting for address
<davecheney> Attempting to connect to ec2-54-91-67-54.compute-1.amazonaws.com:22
<davecheney> Attempting to connect to ip-10-183-142-21.ec2.internal:22
<davecheney> Attempting to connect to 54.91.67.54:22
<davecheney> Attempting to connect to 10.183.142.21:22
<davecheney> Logging to /var/log/cloud-init-output.log on remote host
<davecheney> Installing add-apt-repository
<davecheney> Adding apt repository: deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/cloud-tools main
<davecheney> oh phew
<davecheney> it bootstrapped a precise machine
<davecheney> menn0: https://github.com/juju/juju/pull/127
<wallyworld_> davecheney: are you serios? that printf caused the bug?
<davecheney> wallyworld_: nope
<davecheney> wallyworld_: the printf didn't cause the bug
<davecheney> continuing to use the value of status even though it's value could be nil caused the bug
<wallyworld_> ok, ta. i just skimmed the pr
<wallyworld_> but yes, i see now
<davecheney> i'm looking at the original report
<davecheney> i think the first report was unrelated to the bug in #2
<wallyworld_> when i looked at it briefly, it seemed like another of those call stack differences
<davecheney> not sure, i'm trying on ppc now
<davecheney> if i can reproduce the issue i'll have to propose a branch with some extra debugging information
<menn0> davecheney: just responded. I'm wondering if we should solve this in a different way (described on the PR).
<davecheney> crap
<menn0> wallyworld_: ^^
<davecheney> i already $$Merge$$
<davecheney> i'll propose another branch
<wallyworld_> i can kill the jib
<davecheney> ok
<davecheney> wallyworld_: do that
<menn0> davecheney, wallyworld_: cheers
<davecheney> then i'll push another change
<wallyworld_> sorry menn0
<davecheney> menn0: wallyworld_ PTAL
<wallyworld_> davecheney: can't we stop the double print
<wallyworld_> s/can't/shouldn't ?
<davecheney> we can return nil
<davecheney> when the command will exit with 0
<menn0> that's what I just suggested
<wallyworld_> or not print it in the command?
<wallyworld_> and let the top level command print it?
<davecheney> wallyworld_: then we have two errors to return
<davecheney> the one from the call to get the status
<davecheney> and one from possibly printing the status
<menn0> solution: move the if status == nil above the if err != nil
<davecheney> ok
<menn0> (and keep returning err if status == nil)
<jcw4> fwereade, cmars happy Thursday: https://github.com/juju/juju/pull/128
<jcw4> easy reading: diffstat +92,-0
<wallyworld_> davecheney: menn0 : oh, can status be not nil even with an err?
<davecheney> wallyworld_: traditionally you can make no assertion about the contents of status if err != nil
<menn0> wallyworld_: that's what the comment appears to suggest
<wallyworld_> well that sucks
<wallyworld_> i assumed if err != nil status would be unusable as you just said
<davecheney> wallyworld_: i agree
<menn0> I guess the scenario will be that the status output was partially generated when an error was encountered
<davecheney> i don't know who put in the original logic
<davecheney> that was my original fix
<menn0> it's still better to show something
<davecheney> menn0: you could argue that the contents of status aren't incomplete
<davecheney> they are unknown
<menn0> original logic has been there for a while I suspect (before my time)
<wallyworld_> yeah
<menn0> davecheney: you could argue that but the original author seemed to think it was better to show partial results than nothing at all
<wallyworld_> sure confusing if you don't look in detail
<menn0> which I can see
<wallyworld_> menn0: so, i will be away at the sprint when you are in brisbane :-(
<menn0> wallyworld_: I gathered that from the dates I heard during today's meeting :(
<menn0> wallyworld_: no matter, I'll work from my parent's place.
<wallyworld_> you only here a week right?
<menn0> A little over a week - 5th to the 15th
 * menn0 will be in davecheney's timezone
<davecheney> menn0: you can stay at jools' place, right ?
<menn0> davecheney: my parents live in Brisneyland ... that's the main reason I'll be there
<davecheney> not to visit jools?
<davecheney> he'll be hurt
<menn0> working with Ian was going to be a side benefit
<davecheney> that's an odd turn of phrase
<wallyworld_> menn0: i'll be back morning of the 14th, i won't work that day but maybe we can catch up
<menn0> I don't think I've met jools in person before although we are indirectly connected outside of canonical
<menn0> wallyworld_: that'd be good if we can make it work
<menn0> I'm flying on the 15th so it'd have to be the 14th
<wallyworld_> yup
<wallyworld_> leave it with me
<menn0> davecheney: responded again to the PR
<davecheney> wallyworld_: which version of gccgo is installed on the build machine ?
<davecheney> actaully, maybe I answer that
<wallyworld_> davecheney: sec, otp
<davecheney> nope i can't
<davecheney> need help
<wallyworld_> davecheney: it's an ephemeral image so it pulls down whatever is in the archive
<wallyworld_> the console logs should show it
<davecheney> http://juju-ci.vapour.ws:8080/job/local-deploy-trusty-ppc64/99/console
<davecheney> doesn't show me
<wallyworld_> http://juju-ci.vapour.ws:8080/job/github-merge-juju/203/consoleFull
<wallyworld_> ah
<wallyworld_> you mean the ppc machine
<davecheney> yup
<wallyworld_> sorry
<davecheney> gotta check if it isn't using the broken compiler we shipped with trusty
<wallyworld_> still looking, but i have to duck out to get my son, i'll be back soon
<dimitern> morning
<davecheney> wallyworld_: ping
<wallyworld_> davecheney: hi, just got back
<davecheney> excellent
<wallyworld_> still figuring out how to tell what version
<davecheney> gccgo -v
<davecheney> will do
<wallyworld_> davecheney: gotta figure out the machine ip address, it's not obvious from the job that i can see
<TheMue> Morning
<TheMue> Will start a bit later today, I'm in the garage with my car.
<TheMue> At least some net access via phone.
<davecheney> wallyworld_: i've reproduce the panic on ppc
<davecheney> still need to know the compiler version your running
<davecheney> althought I suspect it is the unfixed versino
<davecheney> because the fixed version has not landed in trusty-updates
<wallyworld_> davecheney: yeah, i still can't find the ip address of the machine running the tests
<davecheney> fuk it
<davecheney> i'm 90% sure that the fix hasn't made it to trusty yet
<davecheney> so we're probably boned
<wallyworld_> davecheney:
<wallyworld_> ubuntu@stilson-07:~$ gccgo -v
<wallyworld_> Using built-in specs.
<wallyworld_> COLLECT_GCC=gccgo
<wallyworld_> COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.9/lto-wrapper
<wallyworld_> Target: powerpc64le-linux-gnu
<wallyworld_> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9-20140406-0ubuntu1' --with-bugurl=file:///usr/share/doc/gccgo-4.9/README.Bugs --enable-languages=c,c++,go --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --
<wallyworld_> enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --enable-secureplt --with-cpu=power7 --with-tune=power8 --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
<wallyworld_> Thread model: posix
<wallyworld_> gcc version 4.9.0 20140405 (experimental) [trunk revision 209157] (Ubuntu 4.9-20140406-0ubuntu1)
<davecheney> yup
<davecheney> hmm
<wallyworld_> finally found the ip address
<davecheney> i've definitely got the dud version on winton-09
<davecheney> https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1304754
<_mup_> Bug #1304754: gccgo has issues when page size is not 4kB <ppc64el> <trusty> <gcc:Fix Released> <gcc-4.9 (Ubuntu):Fix Released> <gccgo-4.9 (Ubuntu):Invalid> <gcc-4.9 (Ubuntu Trusty):Invalid> <gccgo-4.9 (Ubuntu Trusty):Fix Committed by doko> <gcc-4.9 (Ubuntu Utopic):Fix Released> <gccgo-4.9 (Ubuntu Utopic):Invalid> <https://launchpad.net/bugs/1304754>
<davecheney> not fix released
<wallyworld_> :-(
 * davecheney tries throwing ppa's at the problem
<davecheney> wallyworld_: good news and bad news
<davecheney> 1. bad news, compiler bug is not fixed
<davecheney> good news, this isn't the compiler bug
<davecheney> wallyworld_: [LOG] 0:00.458 DEBUG juju.state.apiserver -> [95] machine-0 171us {"RequestId":2,"Error":"objId is empty, dipshit","Response":{}} Machiner[""].Life
<davecheney> server_test.go:77: c.Assert(err, gc.IsNil)
<davecheney> ... value *params.Error = &params.Error{"", "objId is empty, dipshit"} ("objId is empty, dipshit"
<davecheney> so, there is the cause
<sparkiegeek> if I have two units of the same subordinate service "hulk-smashed" onto a single machine, will I get hooks being run concurrently? (e.g. unit/0 hookX and unit/1 hookX being run at the same time)?
<sparkiegeek> I tried asking last night but didn't get a definitive answer :)
<davecheney> sparkiegeek: no
<jam> fwereade: rogpeppe1: ping about interfaces and reflect, I'm trying to fix bug https://bugs.launchpad.net/juju-core/+bug/1331744  I'm pretty sure I understand *why* it is failing, what I can't understand is why it ever worked.
<_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1331744>
<davecheney> wallyworld_: [LOG] 0:00.376 DEBUG juju.state.apiserver <- [95] machine-0 {"RequestId":2,"Type":"Machiner","Request":"Life","Params":{"Entities":[{"Tag":"machine-0"}]}}
<davecheney> [LOG] 0:00.377 DEBUG juju.state.apiserver -> [95] machine-0 184.387us {"RequestId":2,"Error":"objId is empty, dipshit","Response":{}} Machiner[""].Life
<sparkiegeek> davecheney: great, thank you
<rogpeppe1> jam: looking
<jam> fwereade: rogpeppe1: I'm in https://plus.google.com/hangouts/_/canonical.com/juju-sapphire
<jam> rogpeppe1: I can give the context on the hangout
<jam> the logs there like to be formatted as "html" which makes them wrap in horrible horrible ways :)
<davecheney> jam: look at the debug I sent wallyworld_
<davecheney> objId is empty
<jam> davecheney: doesn't matter, I know what the bug is, I'm trying to figure out how to fix it
<voidspace> morning all
<jam> rogpeppe1: a thought about why it might have worked in golang go
<jam> if it puts its methods in sorted order
<jam> and all of our types that were being exposed via interfaces
<rogpeppe1> jam: yeah, if gccgo doesn't, then that's the reason
<jam> didn't actually implement more public methods than just the interface methods
<jam> rogpeppe1: well gccgo could, but it looks like it puts private methods first
<rogpeppe1> jam: right
<jam> and Ping comes before ping depending on how you sort :)
<rogpeppe1> jam: that makes sense
<rogpeppe1> jam: i suspected something like that
<jam> so I might have a good test case for golang go then
<rogpeppe1> sounds like it's not a bug
<jam> rogpeppe1: well its a bug in our code, because of assumptions that only happened to match most of the time
<jam> (well, in all our current use cases :)
<rogpeppe1> jam: yeah, worth adding a test case, sure
<davecheney> jam: if you have a test case
<davecheney> i can submit it to iant
<davecheney> he's pretty receptive to stuff like this
<davecheney> even if it's 'in spec'
<jam> davecheney: so again, it doesn't appear to be a gccgo bug
<davecheney> he knows weird arse shit that makes gccgo act differently drives adoption away
<jam> davecheney: it is a case where we were relying on accidental behavior which isn't even always true in golanggo but happened to be for how we were structuring our code.
<jam> rogpeppe1: yeah, I have a test which shows that it fails if your concrete type has extra methods.
<rogpeppe1> jam: cool
<jam> bugfix for bug #1331744 https://github.com/juju/juju/pull/129
<_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1331744>
<jam> rogpeppe1: ^^ if you want to review it.
<jam> Without the code fix, the test returned "A" instead of "second"
<jam> bbiab
<wallyworld_> mgz: i just got back and need to eat, can i ping you after the team lead meeting?
<mgz> sure thing
<dimitern> fwereade, thanks for reviewing the networking model doc
<voidspace> jam: by the way, rfc 3230 digest headers don't support sha256 :-/ (only sha1 and md5)
<dimitern> fwereade, can you join us on our standup to discuss and agree upon what's not clear?
<voidspace> jam: we could use the digest header and an "officially non-standard" algorithm
<voidspace> jam: Digest: sha256=<base64 encoded hash>
<fwereade> dimitern, yeah, I'm not 100% sure I've finished orthat I'm very coherent today either
<voidspace> jam: that would be slightly more standard than our current X-Content header
<voidspace> jam: which I forgot to fix yesterday
<fwereade> dimitern, ...and hmm we have the leads meeting after the standup, and I have wallyworld_ after that
<fwereade> dimitern, after that maybe?
<dimitern> fwereade, whenever works for you
<jam> voidspace: are we using sha256? we could still stick with sha1
<wallyworld_> mgz: i finished eating, let's do it quickly now if you're free
<jam> dimitern: TheMue: standup?
<TheMue> jam: yep
<jam> vladk: I like that it shows you are thinking about it, and we can discuss how we've solved some of the problems you're bringing up, I just ran out of time.
 * perrito666 is seconds away to having to use git bissect
<voidspace> perrito666: I've changed your backup functions to return a base64 encoded sha1 hash instead of a hex-encoded sha 256 hash
<voidspace> perrito666: I hope you have no objections to that
<perrito666> voidspace: nope, some reason in particular?
<mfoord> perrito666: the only standard http response header (defined by rfc) for sending a file hash
<mfoord> perrito666: uses base64 encoded sha1 hash
<mfoord> perrito666: and doesn't support sha 256
<perrito666> mfoord: I see, I really hope you added a comment there :p
<wwitzel3> perrito666: git biset is really useful .. most people use git in a way that makes it less useful, but I've used it plenty of times to locate bugs.
<mfoord> perrito666: http://www.ietf.org/rfc/rfc3230.txt
<wwitzel3> s/biset/bisect
<mfoord> perrito666: I added as many comments as there were already...
<mfoord> perrito666: j/k - I'll add one
<perrito666> mfoord: "the code was self explanatory"Â®
<mfoord> perrito666: hehe
<mfoord> perrito666: the code is just as easy to read
<mfoord> perrito666: I've added a comment anyway
<perrito666> wwitzel3: yes, git bissect rocks, sadly I have no time to build a run command so it does all the test automatically
 * perrito666 notices gmail header when the email has a flight booking ... creepy
<natefinch> perrito666: have we just cranked up the timeouts and see if that fixes things?  Like making the timeouts 60 minutes or something?
<perrito666> natefinch: I have identified the what is not working, not yet the why
<perrito666> I have narrowed to a breaking commit between 240db2a2 0cbd5b87
<perrito666> so now I am bisecting with hope to obtain the culprit and be able to work a solution from there
<perrito666> luckily I have a setup in place that allows me to re-create what jenkins does, stream included
<natefinch> perrito666: awesome
<mfoord> a lovely simple PR for someone to review
<mfoord> https://github.com/juju/juju/pull/130/files
<perrito666> natefinch: have you decided to stop sleeping? you where here when I left lastnight and are still here when I come back
<wwitzel3> perrito666: he has kids ;)
<natefinch> heh
<natefinch> perrito666: I would say the same to you
<perrito666> natefinch: I gave up sleeping
<perrito666> I stayed late debugging this and woke up to have breakfast with my wife
<mfoord> wwitzel3: thanks
<wwitzel3> that reminds me, I am really hungry .. thanks perrito666
<perrito666> wwitzel3: np
<wwitzel3> mfoord: np
<mfoord> I like the way github diffs highlight the changed *part* of a line that was only modified
<wwitzel3> mfoord: you can get that behavior on the command line too using the diff-highlight script
<mfoord> cool
<wwitzel3> mfoord: you just need to enable it, it should be in your git/contrib
<mfoord> will look, thanks
<wwitzel3> natefinch: should we do our meeting befores standup day since we missed it yesterday?
<natefinch> wwitzel3: sounds good
<jam> cmars: I'd like to send this email, shall we meet up in 5-10 ?
<cmars> jam, sounds good
<bodie_> morning all
<bodie_> jcw4, saw your Actions PR, woot!
<bodie_> this might be useful to others (I know at least jcw4 was asking about it)
<bodie_> https://gist.github.com/piscisaureus/3342247
<perrito666> ok, says git bisect that 4a2f56528641c12f2e80cb17cc84e58d425d73bd is the culprit
<wwitzel3> natefinch: I'm in moonstone
<natefinch> wwitzel3: coming
<TheMue> fwereade, cmars: a PR for review: https://github.com/juju/juju/pull/131 thanks
<natefinch> wwitzel3: you see frozen?
<sinzui> Hi juju devs. Joyent had a storage outage 10 hours ago, that was the cause of the joyent deploy failure. I am stopping CI to reenable publication to joyent. I will restart the current revision.
<perrito666> sinzui: I think I found the offending commit, sadly its a very long one :s
<natefinch> perrito666: link me, maybe I can help
<sinzui> perrito666, I am SO SO sorry for not getting your rev tested. I had a power outage and joyent failed all about the same time.
<perrito666> sinzui: no hurries, I have a pretty good setup for that already
<natefinch> sinzui: I wonder if we could set up some kind of provider baseline test that proves the provider is currently working in an acceptable fashion before running our tests... that way we'd better understand what's failing, and our CI tests would look less spotty.
<sinzui> natefinch, we set that up last november
<sinzui> natefinch, http://juju-ci.vapour.ws:8080/view/Cloud%20Health/
<natefinch> sinzui: oh awesome, I didn't realize
<sinzui> ^ the joyent job has a sad recent history
<natefinch> ericsnow: standup?
<bodie_> blocking on https://github.com/juju/juju/pull/128 if anyone can spare a sec to lgtm
<jcastro> Hey guys do we have Juju API docs on the web anywhere?
<ericsnow> jcastro: I was looking yesterday and couldn't find any
<ericsnow> jcastro: the best thing I could find was bindings for Python: https://launchpad.net/python-jujuclient
<TheMue> jcastro: weâve so far only got a rough text about the general design
<TheMue> jcastro: a developer documentation is currently wip
<natefinch> TheMue: it would make me really happy if this could be a reasonable place to look for docs: http://godoc.org/github.com/juju/juju/state/api
<ericsnow> TheMue: that would be great
<natefinch> TheMue: obviously having something on juju.ubuntu.com would also be good... but the closer you are to the code, the more likely the docs will stay up to date
<TheMue> natefinch: they will be written in markdown, so that they can be rendered directly in GH. additionally they will be rendered for juju.ubuntu.com
<TheMue> natefinch: the docs are no documentation of the individual funcs, that may be indeed better there
<TheMue> natefinch: they are a design documentation about RPC and versioning for maintenance and extension
<TheMue> natefinch: so docs != docs
<natefinch> TheMue: I think when people ask for docs about the API, they mean "what methods does it contain and what do they do?"
<ericsnow> natefinch, TheMue: right
<TheMue> natefinch: thatâs one perspective, yes. another one is design, to get new team members and contributers faster into our system
<TheMue> natefinch: thatâs where Iâm working on
<natefinch> TheMue: cool
<TheMue> natefinch: finding a way to generate also a good overview of the API functions automatically too would be nice, yes. will think about it
<jcastro> TheMue, what's the timeline for API docs? someone is making a production decision based on when we have that
<ericsnow> TheMue: another perspective is people writing bindings--they need both
<natefinch> jcastro: are they looking for docs about what endpoints are exposed and what they do, etc?
<jcastro> yeah
<natefinch> jcastro: this is a good start: http://godoc.org/github.com/juju/juju/state/api
<TheMue> jcastro: which perspective is the interesting one here? I think nates view of the available functions?
<jcastro> they want to integrate with jenkins etc.
<jcastro> he's the guy talking in #juju
<jcastro> I have to run the cloud cross team call, if one of you guys can take over in #juju TheMue or natefinch
<natefinch> jcastro: I'm on it
<natefinch> wwitzel3: can you try helping perrito666 figure out his mongo issue?  It's not fun, but it's quite important
<perrito666> natefinch: well I know I am no fun, but its not like you have to say it on public :p
<natefinch> haha
<natefinch> it's mongo that's no fun
 * fwereade goes to lie down a bit more, back later
<wwitzel3> natefinch: yep
<wwitzel3> perrito666: I'm in moonstone
<perrito666> wwitzel3: hold a sec
<perrito666> wwitzel3: your room is on moonstone
 * perrito666 plays silent cinema with wwitzel3
<wwitzel3> perrito666: lol
<wwitzel3> perrito666: that CI link you sent me 404, can you link it here
<perrito666> http://4.bp.blogspot.com/-5jfw91ZJefw/UvxN4qJNfoI/AAAAAAAATNc/9Jh7whIzWmE/s1600/Cinelists+-+Silent+Movie-+Mel+Brooks+(20).jpg
<perrito666> wwitzel3: http://juju-ci.vapour.ws:8080/job/functional-ha-backup-restore/
<perrito666> sinzui:
<perrito666> this happens only with ha right?
<sinzui> perrito666, I have seen just backup-restore fail, but that passed yesterday
<ericsnow> voidspace:  with the new backup client I see that you are following the lead of AddLocalCharm and UploadTools
<voidspace> ericsnow: in terms of?
<voidspace> ericsnow: what's the link to your PR by the way?
<voidspace> ericsnow: I'm about ready for it
<ericsnow> voidspace: the direct HTTP request stuff rather than using the RPC call machinery
<voidspace> ericsnow: right, indeed
<rogpeppe1> dimitern, natefinch, voidspace, mgz, perrito666, fwereade, jam: mechanical changes here, preparing for adding bundle support to the charm package, review appreciated: https://github.com/juju/charm/pull/7
<ericsnow> voidspace: https://github.com/ericsnowcurrently/juju/pull/1/files
<voidspace> ericsnow: it needs to be, I don't want to read the whole (potentially gigabyte sized) file into memory before writing it to disk
<ericsnow> voidspace: can't you use a different codec with the RPC/websocket code that does it while still using the existing RPC machinery?
<ericsnow> voidspace: WatchDebugLog already does something along these lines
<voidspace> ericsnow: I don't know :-)
<voidspace> ericsnow: ah right, I looked for examples and the first I found was the charm stuff
<voidspace> ericsnow: it isn't much work though
<voidspace> ericsnow: five lines of code to prepare and do the call
<voidspace> ericsnow: or so
<ericsnow> voidspace: I'm guess that those 3 oddball API methods do their own thing because it was the easiest way to get it done :)
<voidspace> right
<voidspace> I'm not sure how far out of our way we should go to find a harder way... ;-)
<ericsnow> voidspace: considering the comments in AddLocalCharm() and UploadTools(), it may be worth factoring at least some of the code into a common binary blob RPC client
<dimitern> rogpeppe1, lgtm
<voidspace> ericsnow: maybe
<ericsnow> voidspace: at which point it may be worth just going the binary-blob-instead-of-JSON codec route
<voidspace> ericsnow: grabbing coffee and then will take a proper look at the code
<ericsnow> voidspace: if I read all that code right (it gets a little twisty in there)
<ericsnow> voidspace: sounds good :)
<ericsnow> BTW, I just put up a doc patch for backup/restore (once the CLI changes land): https://github.com/juju/docs/pull/124
<voidspace> natefinch: ping
<voidspace> actually
<voidspace> natefinch: unping
<voidspace> alexisb: ping
<alexisb> voidspace, pong
<voidspace> ericsnow: as far as I know we can't extend the Client type from another file
<voidspace> ericsnow: which is why we don't break the client up into multiple files
<voidspace> ericsnow: we could move common functionality into a base class and then have several client types
<voidspace> ericsnow: but that seems like extra complexity
<ericsnow> voidspace: oh, I figured intra-package was okay
<voidspace> ericsnow: I *may* be wrong
<voidspace> natefinch: ping? ^^^
<voidspace> ericsnow: there isn't much common code I can see to factor out between the binary blob methods
<ericsnow> voidspace: at least the part around  "resp, err := utils.GetNonValidatingHTTPClient().Do(req)"
<voidspace> ericsnow: right - I intend to do that already, for when we switch to a validating client
<voidspace> ericsnow: (have getting the client be a single method used by all of them)
<ericsnow> voidspace: exactly
<voidspace> ericsnow: WatchDebugLog shows how to do that correctly I think, so I'll just copy that code :-)
<voidspace> ericsnow: except the error handling looks janky - it reads the first line to see if there's an error
<voidspace> ericsnow: I mean, we *could* do that with Backup, assuming a newline appears *somewhere*
<voidspace> ericsnow: but it's a bit yucky
<ericsnow> voidspace: yeah :)
<voidspace> ericsnow: hmmm
<voidspace> ericsnow: that looks a little hard to get round
<natefinch> voidspace: you can put functions for a type in any file in the same package as that type.  files are just an organizational tool, they don't really interact with the language itself.
<voidspace> ericsnow: ah no, I think that API endpoint always sends an error response in the first line
<voidspace> ericsnow: and you tell if there was an error by checking the Error of the unmarshalled json of the first line
<voidspace> ericsnow: so it's not a problem - it's a janky api endpoint, not a feature of websockets
<voidspace> natefinch: ok, cool
<ericsnow> voidspace: good
<voidspace> natefinch: sooo... for the client Backup method, ericsnow is suggesting we put this in a new file
<voidspace> natefinch: especially as Backup will have related methods for restore soon
<natefinch> sure
<voidspace> okey-dokey
<voidspace> ericsnow: I'm going to punt on factoring it out into a different type though
<natefinch> files don't really matter.  It can be helpful to break stuff up.  it's your call
<voidspace> ericsnow: I want to use some of the client methods for obtaining the websocket
<ericsnow> voidspace: no worries (limited resources, etc.)
<voidspace> aye
<voidspace> ericsnow: as I'm away from Saturday I'll get done what I get done (probably most of it bar complete tests)
<voidspace> ericsnow: and hand the rest over if not complete
<ericsnow> voidspace: sounds good
<jcw4> fwereade, cmars : happy Thursday :) https://github.com/juju/juju/pull/132
<jcw4> PTAL
<voidspace> ericsnow: hmmm... it seems like the janky api in WatchDebugLog maybe because websockets don't have a statuscode
<voidspace> ericsnow: and they may not have headers easily accessible either
<voidspace> ericsnow: so this may be a dead end
<voidspace> ericsnow: or we duplicate the janky api to send any error response and the sha
<voidspace> ericsnow: (i.e. send a json response as the first line and *then* the file)
<ericsnow> voidspace: that's what I was thinking :)
<voidspace> ericsnow: I'll look tomorrow
<voidspace> I'm EOD now
<ericsnow> voidspace: alrighty
<voidspace> ericsnow: I pushed the changes that split out the Backup method into its own file at least
<voidspace> ericsnow: I haven't pushed the websocket changes as I'm not sure whether or not to go down that road
<voidspace> see you tomorrow everyone
<voidspace> g'night
<bodie_> blocking on a LGTM for https://github.com/juju/juju/pull/132
<cmars> bodie_, jcw4 not familiar enough with actions or watchers to approve, but I don't see anything wrong with it either
<jcw4> cmars: thanks; this part has nothing new that is inherent to actions... just a new filtered watcher on the actions collection
<jcw4> cmars appreciate your comments!  I don't mind waiting for someone who knows watchers better to LGTM
<jcw4> (isn't that a weird nounification ^^ ?)
<jcw4> or wait... verbification?
<bodie_> I think it's a verbed noun, yes
<bodie_> verbing is the best
<jcw4> haha
<jcw4> I see what you did there
<bodie_> and LGTM itself is a nouned exclamation...
<bodie_> english...
<bodie_> not a well-typed language
<jcw4> ... is why they invented Go
<jcw4> har har
<bodie_> nyuk nyuk
<perrito666> sinzui: will you stop growing that bug?
<sinzui> perrito666, sorry, I am just looking for evidence. since branches are linked to bugs any more. I had to read every commit since the last release. I just happened to see things that looked relevant to the tests failing
<perrito666> just kidding I identified the commit that breaks at least in aws
<sinzui> perrito666, fab, I moved both jobs back to aws this morning
<bac> sinzui: are there any known issues with juju and local providers on utopic?
<sinzui> bac no
<bac> thanks
<sinzui> bac: it has a perfect record in fact *after* the template is created. If you abort the first bootstrap, the template is borked
<perrito666> mm, I think something is really making our tree ugly
<wwitzel3> perrito666: ?
<hazmat> rogpeppe1, one item of concern with machines in the bundle spec is the issues of concurrency around usage of those machines
<perrito666> wwitzel3: something Was not making sense to me so I went into a graphical git thinguie and our tree looks a bit messy but perhaps its what I am using
<hazmat> rogpeppe1, ie. juju will blithely assign a different workload to an unused machine even though it was created for the bundle
<bodie_> in case anyone missed the pr, actions work is blocking on https://github.com/juju/juju/pull/132
<bodie_> pretty simple one
<jcw4> someone with watcher knowledge could review it in just a few minutes ^^
<perrito666> natefinch: lol, what a rant
<perrito666> natefinch: I think the preferred g-apps way is share this as a gdrive attachment
<natefinch> I have a pet peeve about email size limits
<natefinch> some people like pretending we're all still on dialup
<perrito666> heh, I recall some old dev on my team, some time ago telling me "but what if the user has js dissabled" ... "me: who does that" "him: blind people" .."me: for gods sake, we are making a movies guide site, really? blind people?"
<perrito666> and just to make it worse, the discussion was around some js for a button that had the caption "I have seen this"
<natefinch> lol
<TheMue> natefinch: great pic *smile*
<natefinch> :)
<natefinch> thrilled to have a boy.  I know a lot of people with three girls.  Of course, now I have to figure out how to raise a boy.
<perrito666> natefinch: you should have gone througt that process at least once
<natefinch> perrito666: and look how *that* turned out! :)
<perrito666> well, you have your kids go to standups, the apple cant fall so far from the tree
<hazmat> sinzui, which azure regions are being tested?
<sinzui> hazmat, US West...the only one that ever worked
<perrito666> wwitzel3: got any luck?
<perrito666> wallyworld_: lemme know when you come to life please
<wallyworld_> perrito666: hey, having my morning coffee. only 6am here so i have a few things to do to get the kid ready for school so i can't give you my full attention, but i may be able to help
<perrito666> well, I dont want to ruin your morning coffee but https://github.com/juju/juju/commit/4a2f56528641c12f2e80cb17cc84e58d425d73bd#diff-dec2c5aafeb31667d3e3abc2232ec107R50 is most likely the commit that broke restore, I could use some help figuring what exactly it is
<perrito666> so yea, I can wait until your full attention is available :p
<wallyworld_> perrito666: well that sucks :-( do you know what the failure is? a permissions issue?
<wallyworld_> perrito666: note that there was a follow up to that branch that did fix a permissions issue
<perrito666> wallyworld_: I wish, the failure is, there is no failure, there is a part of the restore process that is undone :| Its a bit of a hassle to explain over chat, we can have a quick call whenever you finish your morning setup
<wallyworld_> so if you run with that branch and not the follow up one, it will fail
<wallyworld_> the follow up branch adds a ClusterAdmin permission to user creation
<perrito666> wallyworld_: even if I am running as admin?
<wallyworld_> i think so
<perrito666> ok, what is the branch?
<perrito666> d1e0262efcf878bad24c4235873b0d740f21f320
<sinzui> bodie_, is there anything to announce regarding Actions in 1.19.4?
<wallyworld_> perrito666: https://github.com/juju/juju/commit/94e7f692cc2c145d67de9c1f5d3e6cda53097c41
<jcw4> sinzui: not for 1.19.4
<sinzui> goody
<jcw4> :) okay...
<wallyworld_> perrito666: i have to be afk for a bit, will chek back with you later
<perrito666> tx
<hazmat> sinzui, ack, thanks.. apparently there have been some issues in the azure api in eu region.. was talking to cpc folks
<wallyworld_> perrito666: raining here so i have to drive the kid to school. so i'll bbiab if you need anything
<perrito666> wallyworld_: np, drive safely
<thumper> waigani: I have a guy here quoting on windows, may not be done by 11, can you tell dave?
<waigani> wow, confusing - I just had the same! yep, shall we go ahead without you?
<jcw4> I don't suppose there are any folks down under that want to do a quick review on a new Watcher?
<jcw4> The first part already got merged and this is part 2
<jcw4> https://github.com/juju/juju/pull/132
<thumper> waigani, davecheney: window guy still here, perhaps another 10-15 min
<thumper> ok, here now
<thumper> waigani, davecheney: go now?
<waigani> thumper: we are in hangout now :0
<waigani> :)
<sinzui> WTF, ec2 trusty cannot bootstrap with a recent rev
 * sinzui looks for bad CI
<perrito666> wallyworld_: returned?
<wallyworld_> perrito666: yup, a while ago, sorry
<perrito666> wallyworld_: thats ok, I took a nap, its the night here, wanna do a quick hangout before I go have dinner?
<wallyworld_> thumper: has the window guy taken the window out and put in back in again?
<wallyworld_> sure
<perrito666> wallyworld_: come to https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=3
<thumper> wallyworld_: nah, just quoting at this stage
<perrito666> thumper: so, how much for the licence :p?
<thumper> haha
 * sinzui slaps termination protect on the bootstrap node so juju cannot destroy the evidence
<sinzui> wallyworld_, thumper , if you have bzr-git and qbzr installed, I have found that qlog makes more sense out of what jujubot merged than git itself
<thumper> ha
<sinzui> git log  shows me  many possible revs that can break juju, but qlog shows the real merges
<sinzui> bugger, I wonder if trusty changed its mongo, or the new trusty images used by aws don't work with juju
<sinzui> thumper, wallyworld_ More suck, https://bugs.launchpad.net/juju-core/+bug/1332365
<_mup_> Bug #1332365: trusty EC2: cannot initiate replica set <bootstrap> <ec2> <mongodb> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1332365>
<wallyworld_> :-(
#juju-dev 2014-06-20
<wallyworld_> sinzui: i don't know mongo very well but those errors could be mongo just refusing to start for whatever reason :-(
<sinzui> wallyworld_, that's what I see too. I think something has changed and we might need to adapt juju to it
<wwitzel3> perrito666: no luck yet, the problem is nothing in that commit would seem to have a direct impact on backup and restore in this fashion. It is really odd.
<sinzui> wallyworld_, the current tip of juju is failing the same test
<wallyworld_> sinzui: the other possibility - we set a mongo socket timeout of 21 sec, which is twice the mongo heartbeat interval. those socket connection errors occur about 30 after the sockets are opened. perhaps mongo is closing its client connections because it thinks they areunused
<wallyworld_> the socket timeout was recently increaed from 10s
<wallyworld_> so if anything that should have made it more tolerant
<wallyworld_> but i'm just guessing that the error is due to mongo socket closure, may not be
<sinzui> wallyworld_, I don't think recent juju changes are the problem. We know exactly which change the failure happened with https://github.com/juju/juju/commit/635a06380b2df20f829f205e45e2d3a7e9476d0d
<sinzui> I don't think that is relevant.
<wallyworld_> sinzui: the socket timeout increase happened last week before that change
<wallyworld_> i was trying to make sense of what the most relevant culprit may have been
<wallyworld_> sinzui: but deploy to other clouds works
<sinzui> wallyworld_, only a few intermittent failures caused by timeouts or resources over the last week. This set rarely failed before a few hours ago. It is the only test on aws though that is bootstrapping with juju-monogodb like this
<sinzui> wallyworld_, yep all clouds and all the locals love bootstrapping
<wallyworld_> so just aws
<sinzui> If I could boot utopic there, I bet it would fail the same way
<sinzui> precise doesn't fail...it has mongodb-server
<wallyworld_> hmmm
<sinzui> The ami is two weeks old
<wallyworld> sinzui: i just bootstrapped an amazon env on trusty from my local machine
<sinzui> wallyworld, CI is still trying. Look at this extraordinary effort http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/643/console
<wallyworld> wow
<sinzui> wallyworld, I could kill the job, see if it restart and complete...if so then I think aws was denfintely doing something bad
<wallyworld> sinzui: i wonder if it is region related
<sinzui> hmm
<wallyworld> 2014-06-20 00:57:20 INFO juju.provider.ec2 ec2.go:643 started instance "i-193ae232" in "us-east-1c"
<wallyworld> that is what just worked for me
<wallyworld> it picked az c
<wallyworld> after it was rejected by a and b as being congested
<sinzui> wallyworld, us-east-1a
<sinzui> well, that is the on I left alive anyway
<wallyworld> 2014-06-20 00:57:17 INFO juju.provider.ec2 ec2.go:627 "us-east-1a" is constrained, trying another availability zone
<wallyworld> 2014-06-20 00:57:19 INFO juju.provider.ec2 ec2.go:627 "us-east-1b" is constrained, trying another availability zone
<wallyworld> 2014-06-20 00:57:20 INFO juju.provider.ec2 ec2.go:643 started instance "i-193ae232" in "us-east-1c"
<wallyworld> so i wasn't allowed to use a or b
<sinzui> wallyworld, that one that is taking forever is us-east-1c
<wallyworld> hmmm ok, that's the one that worked for me
<sinzui> and it just failed. now the other aws jobs will start
<wallyworld> not sure what instance type it picked, hw is "hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M"
<wallyworld> m1.small maybe
<wallyworld> so i wonder why mine worked
<sinzui> wallyworld, We get m3.medium by bootstrapping with mem=2G
<wallyworld> i just used the default constraints
<wallyworld> i can try with mem=2G
<sinzui> did I count wrong? I see the test restarting
<sinzui> oh this is wrong, CI is only allow to test this 5 times. It is now doing 7
<perrito666> wwitzel3: well tomorrow is a holiday here so I wont be here, this is your problem for a day :|, I think we need to find out what is re-writing agents.conf and in which documents is that info stored to see which one we are missing, my guess is that wallyworld's commit fixed something and that the fact that restore was working before was actually a bug
<perrito666> we are missing an update somewhee, eiter peergrouper or instancepoller
<perrito666> anyway, its late and I am very very tired
<wallyworld> perrito666: ok. is there info on the bug, i have not much idea what has been done etc
<wallyworld> eg how agents.conf is involved
<perrito666> wallyworld: there is not much info, basically, we are doing some stuff in a bash script embedded in restore.go
<perrito666> which is being undone
<wallyworld> ok, np
<perrito666> that is the issue (in few words
<wallyworld> and running the exact same steps by hand works?
<perrito666> yup
<wallyworld> wtf
<wallyworld> which line does it fail at?
<perrito666> wallyworld: none, that is what makes this wtf of an issue impossible to find
<perrito666> the restore ends succesfully
<wallyworld> hmmm, ok. i've not even looked at the restore script before so not sure how far i'll get
<perrito666> and then when jujud-* starts, it all goes back as it was, courtesy of some worker
<wallyworld> i've got some other issues to deal with as well
<perrito666> wallyworld: in any case wwitzel3 will be working on that too
<wallyworld> ok
<sinzui> wallyworld, something interesting is happening here. AWS doesn't see any sign of the two services being deployed
<perrito666> wallyworld: this is the script https://github.com/juju/juju/blob/master/cmd/plugins/juju-restore/restore.go#L106 just in case you get inspired
<wallyworld> which services, the test ones?
<perrito666> now gentlemen, I really need sleep
<perrito666> cheers
<wallyworld> perrito666: ok,good night
<sinzui> did I mention that joyent manta went down for 5 hours yesterday? I had a power cut so it was difficult to report the outage
<wwitzel3> perrito666: got it, have a good night
<sinzui> ah...
<sinzui> wallyworld, let's say the ec2 issue was region. this test suddenlty came to life and may pass http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/644/console
<wallyworld> sinzui: i just bootstrapped with mem=2G, got same region/zone as before
<wallyworld> 2014-06-20 01:43:22 INFO juju.provider.ec2 ec2.go:627 "us-east-1a" is constrained, trying another availability zone
<wallyworld> 2014-06-20 01:43:24 INFO juju.provider.ec2 ec2.go:627 "us-east-1b" is constrained, trying another availability zone
<wallyworld> 2014-06-20 01:43:25 INFO juju.provider.ec2 ec2.go:643 started instance "i-4a528a61" in "us-east-1c"
<wallyworld>  - i-4a528a61
<wallyworld> and it worked
<sinzui> the test officially passed
<sinzui> And I was watching the moment it got unstalled
<sinzui> I didn't intervene
<wallyworld> so did the failing and passing tests use different regions / zones?
<sinzui> wallyworld, no, the test that passed and the one I kept alive were the same region
<sinzui> but I think your supposition of region or maybe bad machine were at fault
<wallyworld> maybe it is just mongo flakiness
<sinzui> wallyworld, the failed bootstraps, the two timeouts, an the pass were all us-east-1c
<wallyworld> \o/
<sinzui> wallyworld, I don't believe mongo flakiness because there is no prehistory of it in the test
<wallyworld> just seems strangethat mongo starts but then has connection errors
<sinzui> wallyworld, oh...I lie
<sinzui> wallyworld, there are two previous occurrences of this error in the last week. They happened twice in a row, It resolved itself in less than 30 mintutes http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/614/console
<wallyworld> hmmmm
<sinzui> this case though is 4 hours long
<sinzui> anyway. Lets close this bug. maybe I need to walk away from CI and let it mind itself
<wallyworld> sinzui: would have been interesting to use placement to run the tests on a different region/az when the test fails in us-east-1
<sinzui> hmm, well I think I can add such as test after the release, or before if we loose faith that we make juju and CI happy in the next 16 hours
<wallyworld> ok
<sinzui> wallyworld, new info about joyent: https://bugs.launchpad.net/juju-core/+bug/1329123
<_mup_> Bug #1329123: status outage during upgrades in joyent, Juju is broken <joyent-provider> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1329123>
<wallyworld> sinzui: looking into that one now
<sinzui> I am looking for something like termination protection to keep this instance alive
<wallyworld> ok
<sinzui> wallyworld, I have an instance. I clobber something on it to keep it alive when the test ended
<wallyworld> sinzui: ok, i'm bootstrapping a 1.18.4 env now and will see what the upgrade does
<wallyworld> far out joyent is slooooow
<sinzui> wallyworld, it is faster than azure
<wallyworld> surely you jest
<sinzui> as for Hp, it now varies between 9 minutes and 21 minutes
<wallyworld> yay cloud
<sinzui> azure is consistently 18 to 21 minutes
<sinzui> wallyworld, canonistack tests have been passing since I switch the test to pull tools from s3. I suspect swift is the principle cause of speed and out right failures in canonistack
<wallyworld> sigh
<wallyworld> sinzui: so it seems on joyent the api server does not start again after an upgrade
<sinzui> :(
<wallyworld> i think mongo is ok, looking into it
<wallyworld> sinzui: so it's caused by joyent offering up machine addresses that juju doesn't know how to pick out a mongo replicaset peer from. juju's address processing changed in 1.19 and is not compatible with joyent
<sinzui> :(
<wallyworld> i'll see if i can figure out a fix
<wallyworld> i'm somewhat new to this part of juju
<sinzui> wallyworld, I pleased that we know why. I feel relieved that we have really triaged the issue
<wallyworld> yeah, me too
<wallyworld> sorry i had not enought ime earlier to look
<wallyworld> sinzui: sort of argues against that upgrades are generic and can just be tested on one cloud, although i'm confused why a deployment worked as it should have had the same problem
<sinzui> wallyworld, yeah. abentley argued a different perspective that we certify upgrade works. We need to do it for each cloud to gather evidence that things work and that upgrade isn't different.
<sinzui> wallyworld, well maybe the deploy case works because juju is exploring the possible addresses. upgrade doesn' gather addresses.
<wallyworld> sinzui: there's not enough debugging to see the root cause, i'll add some and retest, but first i have to go and pick up my son as he finished school early today
<sinzui> wallyworld, All fine with me. I am going to sleep.
<wallyworld> ok, i'll send an update
<axw> wallyworld: I don't really understand this rsyslog stuff. I can manage to get it to work by changing the default ruleset, but I don't understand why that works... probably going to have to check with wwitzel3 and/or voidspace
<wallyworld> axw: fair enough, i don't fully grok it either
<wallyworld> maybe add a bug comment and we can ping them later
<marcoceppi> where should I be reporting bugs?
<axw> marcoceppi: launchpad
<marcoceppi> even for things like gomaasapi ?
<axw> that's not even on github yet is it?
<axw> I think launchpad too
 * marcoceppi has no idea
<marcoceppi> cool
<axw> maybe not when it's on github. matters for juju for integration points, probably doesn't matter for libraries
<axw> wallyworld: is there anything else pressing I can look at? or just addresses/azure?
<wallyworld> axw: i've made progress with the joyent thing so yeah, just addresses/azure. let's try and wrap up the wip addresses stuff
<axw> ok. gonna write some tests now and propose part of it
<wallyworld> great
<jcw4> clear
<jcw4> derp
<davecheney> wallyworld: axw https://github.com/juju/juju/pull/135
<axw> looking
<wallyworld> bah, beat me to it
<davecheney> wallyworld: the fix ?
<wallyworld> no, looking :-)
<wallyworld> axw: davecheney: might explain some of our mongo test issues
 * wallyworld handwaves
<axw> maybe, not sure. it could cause sockets to not be released
<axw> davecheney: reviewed
<davecheney> bueno
<davecheney> axw: nice review
<davecheney> i don't know what the cost of leaking cursors is
<davecheney> or the rate we were leaking them
<davecheney> but given the usual nonsense we see with mongo
<davecheney> i'm confident to bet it wasn't helping
<voidspace> morning all
<axw> morning voidspace
<voidspace> o/
<axw> voidspace: when you have a moment, can you please cast your eye over https://bugs.launchpad.net/juju-core/+bug/1332358 and my comment on it?
<_mup_> Bug #1332358: creating a local environment stops the syslog (1.19.3) <local-provider> <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1332358>
<wallyworld> axw: small one https://github.com/juju/juju/pull/136
<axw> looking
<wallyworld> fixes last critical for 1.19.4 release
<voidspace> axw: ok
<voidspace> axw: ouch
<axw> voidspace: does that ruleset stuff mean something to you?
<voidspace> axw: yep
<voidspace> axw: I wrote the rulesets
<voidspace> axw: I can switch to looking at this
<voidspace> axw: but today is my last day for a week
<voidspace> axw: so maybe the best thing I can do is write up a quick explanation of the rulesets to help wayne or someone else debug it
<axw> voidspace: sounds good, thank you
<voidspace> axw: wayne did the rest of the rsyslog stuff (but not the ruleset)
<axw> ok
<wallyworld> voidspace: i've moved that bug to 1.19.4 so if there's any way to get it sorted before eod that would be great
<wallyworld> either you or wayne
<wallyworld> as it would be bad to ship 1.20 with that issue still there
<davecheney> axw: wallyworld i THINK i've got all the occurances
<axw> wallyworld: what was setting blank addresses?
<davecheney> i've searched for them a bunch of different ways
<voidspace> axw: is the problem that with local provider, we kill the rsyslog configuration for anything else on the system?
<davecheney> i wanted to use the new pointer analysis feature in godoc 1.3
<axw> davecheney: oracle? :)
<axw> heh
<wallyworld> axw: an old version of the instance poller
<davecheney> but there isn't enough memory in the world to process juju
<axw> wallyworld: ok
<wallyworld> i can't recall the exact bug
<voidspace> axw: Having a bug description with full sentences would help :-/
<davecheney> the stdlib consumes 1.7gb on my machine
<wallyworld> but it rings a bell
<davecheney> axw: i could try the oracle
<axw> voidspace: yes, everything else stops it seems
<axw> davecheney: I have 16GB, I'll see if I can run it.
<voidspace> axw: and you can reproduce it?
<axw> voidspace: yes, trivially
<voidspace> axw: what are the repro steps
<axw> voidspace: bootstrap local provider, wait for rsyslog worker to kick in, /var/log/syslog stops showing other bits
<voidspace> ah
<axw> voidspace: I just did what's in the bug
<voidspace> hah, there are repro steps
<voidspace> axw: it's 8am here and I haven't had coffee :-)
<voidspace> so coffee
<axw> :)
<voidspace> axw: so I guess the problem is that I change the default ruleset to forward all logs to the state server
<voidspace> and the state server only logs juju messages and drops everything else
<voidspace> and on local provider the state server is "the machine"
<voidspace> so all other logs are dropped
<axw> it looked like they both do that though?
<axw> both rulesets I mean
<davecheney> axw: i also have a bunch of junk in my $GOPATH
<davecheney> which upset the analyser, it freaks on first error
<voidspace> axw: one should just forward messages (local) the other should actually log them (remote)
<voidspace> but coffee first
<axw> ok
<voidspace> (so "remote" ruleset is for logs received by TCP - and they should be logged. The "default ruleset" is "what to do with messages generated locally" and we want to forward those to all state servers - so that's the "local ruleset" which forwards messages.)
<voidspace> For local provider we need to be smarter and log messages that aren't juju ones
<voidspace> in fact we can do that for all providers
<voidspace> so it should be a simple change
<wallyworld> thanks davecheney
<voidspace> but I/we need to know how to specify "do what you would have done anyway" for the non juju messages
<voidspace> the remote ruleset just logs messages - which is why switching to remote by default works
<voidspace> but it means that log messages don't get broadcast to other state servers
<voidspace> so it isn't correct
<axw> voidspace: isn't that just for non-juju log messages?
<voidspace> we only want our log file to handle juju messages
<axw> wallyworld: why the "" check in bestAddressIndex too?
<voidspace> axw: the problem is that it is for non-juju log messages too
<voidspace> axw: but yes - we have a tag format for juju messages, so for all *non juju* ones we need to say "just process them as you would have done"
<voidspace> I don't know how to specify that
<wallyworld> axw: because somehow "" addresses still end up in there and i'm not sure how
<axw> nor do I
<voidspace> needs digging into
<voidspace> probably keeping a reference to the normal "default ruleset" before replacing it
<wallyworld> voidspace: axw: there's a ~ syntax i think
<voidspace> or something
<voidspace> yeah ~ means "stop processing"
<wallyworld> or something like that
<voidspace> we only want to do that for juju ones
<voidspace> but we're also replacing the default ruleset, so the old processing rules might not even be used
<voidspace> there must be a way to do it, just needs looking up and trying...
<wallyworld> i'm sure between you and wayne you'll figure it out :-)
<voidspace> heh, thanks
<voidspace> wallyworld: I'll get wwitzel3 up to speed when he comes online if I haven't already fixed it
<wallyworld> voidspace: awesome, thanks.
<wallyworld> voidspace: i'll mark it as in progress to you so if curtis looks he'll know it's being worked on, and you can assign to wayne to finish off if need be
<wallyworld> voidspace: what's you lp id?
<wallyworld> never mind
<wallyworld> found it
<davecheney> ?   	github.com/juju/juju/rpc/rpcreflect	[no test files]
<davecheney> ok  	github.com/juju/juju/state	370.446s
<davecheney> ok  	github.com/juju/juju/state/api	24.052s
<davecheney> what the f has happened to the state package
<davecheney> it was 156 seconds a few days ago
<axw> hm, I just ran it and it took 115.711s
<davecheney> ok, what the f is wrong with the bot ?
<axw> wallyworld: the real problem is in the joyent provider
<axw> instance.go, Addresses method
<axw> it's initialising a slice with len, and then appending to it
<wallyworld> let me look
<wallyworld> so it is
<wallyworld> i'll fix
<wallyworld> thanks
<axw> np
<wallyworld> we did also have that instance poller issue so i jumped to conclusions
 * wallyworld taps fingers impatiently waiting for joyent env to start up
<axw> I thought it was meant to be fast
<wallyworld> not when the instance has to do the apt dance
<davecheney> how come you guys rewrite the apt mirrors ?
<davecheney> are the ec2 mirrors busted ?
<axw> davecheney: dunno, that is inherited from CI I think.
<davecheney> it's probably not that important
<davecheney> 2mb downloaded
<davecheney> the real time is taken writing the data
<davecheney> is that using ephemeral storage ?
<davecheney> that instance
<wallyworld> axw: bollocks, just the provider fix without the other work still fails
<wallyworld> so i'll have to add back the other check
<axw> wallyworld: :(
<axw> davecheney: non capisco. is what using ephemeral storage?
<davecheney> the ec2 instance
<axw> it has some, it just shows up as /mnt
<davecheney> aww crap
<davecheney> ok, ignore my suggestion, won't work
<axw> davecheney: we use /mnt/tmp as $TMPDIR when running the tests
<rogpeppe1> mgz: ping
<wallyworld> axw: i added your fix and retained one of mine (and removed the other) and it all works
<axw> wallyworld: cool. which one of yours did you have to keep?
<wallyworld> the merge addresses one
<axw> okey dokey. I guess that needs to be there cos it was buggered before
<wallyworld> that's my guess but i don't know 100%
<rogpeppe1> because it looks like we're not moving to kr's godep tool that soon, i've just pushed a couple of updates to godeps which should make it a little more pleasant to use
<wallyworld> hard to find out for little gain
<axw> rogpeppe1: what changes?
<axw> wallyworld: no worries, LGTM
<wallyworld> ta
<rogpeppe1> specifically, there's now a -f flag which, if set and an update fails, tries to fetch new changes from the repo before trying again
<davecheney> i did git pull upstream master and the conflicts were horrid
<davecheney> how do I undo that ?
<davecheney> i have no committed
<axw> rogpeppe1: nice, thank you
<davecheney> i have not committed
<rogpeppe1> axw: also (actually this changes has been around for a while) it tries to do as much work as possible in the face of failure
<rogpeppe1> axw: so if one repo is dirty, it doesn't stop others being updated
<axw> davecheney: "git reset HEAD" I think?
<axw> rogpeppe1: ah excellent
<davecheney> axw: nope
<davecheney> sorry
<axw> davecheney: "git checkout ." in the root. I dunno if there's a better way to do it.
<rogpeppe1> axw: i'd appreciate it if you could try it out and tell me if it seems to work ok. i didn't have the energy to write tests :-)
<davecheney> axw: thanks
<axw> rogpeppe1: will do
<davecheney> that worked
<davecheney> git totally fucked the change to state/apiserver/root.go
<rogpeppe1> davecheney: you might find it useful too FWIW
<davecheney> rogpeppe1: will do
<davecheney> much love for godeps
<rogpeppe1> it's funny, i've been thinking for ages i couldn't make the time to do the auto-fetch stuff, and then it only took 30 mins to do :-)
<davecheney> #winning
<wallyworld> wtf
<wallyworld> Updating juju-core dependencies to the required versions.
<wallyworld> launchpad.net/godeps (download)
<wallyworld> # cd .; bzr branch https://launchpad.net/godeps /mnt/jenkinshome/jobs/github-merge-juju/workspace/tmp.PFiIQenwfH/RELEASE/src/launchpad.net/godeps
<wallyworld> bzr: ERROR: exceptions.RuntimeError: if we move self._source_infos, then we need to change all of the index pointers as well.
<wallyworld> Traceback (most recent call last):
<wallyworld>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 920, in exception_to_return_code
<wallyworld> jenkns is busted
<wallyworld> i'll hit the retry button
<axw> rogpeppe1: ^^ did you break it? :)
<axw> we grab the latest godeps I think...
<rogpeppe1> axw: it's quite possible, although i tried to make it so the current behaviour wouldn't change unless explicitly specified
<rogpeppe1> axw: specifically, it doesn't try to fetch stuff unless the -f flag is given
<axw> okey dokey
<axw> hmm actually it looks like it's trying to branch godeps, not run it
<wallyworld> axw: i'm off to soccer, if my 2nd retry fails, and there's a fix to anything, can you type $$merge$$ for me again?
<axw> wallyworld: sure
<wallyworld> ta
<wallyworld> i'll be back later anyway, just want to get this sucker landed
<davecheney> so lp just had a lie down ?
<axw> maybe. I just branched it and it worked fine
<axw> on my machine
<rogpeppe1> well, jenkins is still thinking about godeps...
<rogpeppe1> hmm. *still* thinking. that's not a great sign.
<rogpeppe1> same problem again
<rogpeppe1> looks like it might be a bzr issue
<axw> :(
<axw> I'll jump on the machine and take a peek
<rogpeppe1> axw: try making sure that the godeps repo dir is deleted
<rogpeppe1> axw: that might make a difference, i suppose
<axw> it goes to a tempdir
<rogpeppe1> axw: hmm
<rogpeppe1> axw: it's perhaps indicative of something that it took so long to fail
<rogpeppe1> i'll try fetching it from scratch myself
<rogpeppe1> worked fine for me
<axw> rogpeppe1: works when I do it on the machine too
<axw> le sigh
<rogpeppe1> axw: hrmph
<axw> rogpeppe1: did you do "go get" or "bzr branch"?
<rogpeppe1> axw: go get
<rogpeppe1> axw: which, i hope, is what the bot is doing too
<axw> yeah that works too
<rogpeppe1> axw: in fact, i know it is
<axw> yep
<axw> it is
<rogpeppe1> axw: oh yes, the other new feature in godeps is that it now understands package wildcards just like the go tool
<axw> rogpeppe1: ah nice, now I don't have to remember how to list the packages :)
<rogpeppe1> axw: cudos to github.com/kisielk/gotool - which made it a 2-line change
<rogpeppe1> axw: i could uncommit and push -f if we need to
<axw> rogpeppe1: just going to see if there are any env vars that are influencing this first
<rogpeppe1> axw: good thought
<rogpeppe1> fwereade: if you haven't seen it, i think you'll like this proposal: https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit
<fwereade> rogpeppe1, is that the bundles one? haven't looked at it properly yet I'm afraid
<rogpeppe1> fwereade: no, it's a go proposal
<rogpeppe1> fwereade: but i'd appreciate your thoughts on the bundles thing too, if poss
<rogpeppe1> fwereade: 'cos we're actually implementing it right now :-)
<fwereade> rogpeppe1, I read the first sentence and thought "woohoo!"
<rogpeppe1> fwereade: :-)
<fwereade> rogpeppe1, that's awesome
<rogpeppe1> fwereade: i think so too
<rogpeppe1> fwereade: it means we can have a clear division in juju-core between internal and external APIs
<rogpeppe1> fwereade: i think we could restructure it like that even before the go tool supports it actually
<fwereade> rogpeppe1, yeah, and we can make small packages without annoying you *too* much ;)
<rogpeppe1> fwereade: :-
<rogpeppe1> )
<rogpeppe1> axw: any joy?
<axw> rogpeppe1: nope :( sticking a "bzr branch" in there to see if it makes a difference
<axw> no joy...
<rogpeppe1> axw: i've just retracted my latest commit and overwritten godeps/trunk
<rogpeppe1> axw: let's see if it works again now...
<rogpeppe1> if not, then we're stuffed :-)
<axw> rogpeppe1: thanks, I'll give it another kick
<axw> rogpeppe1: that did it
<rogpeppe1> axw: fuck
<axw> :(
<rogpeppe1> axw: what the hell was going on there then?
<axw> no idea, weird bzr internal badness
<rogpeppe1> axw: i will try another time, but with a fresh commit (and slightly different program text, in case it's a weird sha clash or something)
<axw> ok
<rogpeppe1> axw: pushed, with slightly different changes and commit message.
<axw> rogpeppe1: okey dokey. I'll stop the build and try it again
<rogpeppe1> axw: great, thanks
<axw> does not look promising
<rogpeppe1> axw: darn
<axw> rogpeppe1: would you mind backing it out for now, and we can take another look at it next week?
<rogpeppe1> axw: ok :-\
<axw> sorry. kinda need to get this fix in for 1.19.4
<rogpeppe1> axw: ok, done
<axw> thanks
<rogpeppe1> mgz: you around today?
<dimitern> fwereade, I've responded to comments and updated most of the networking doc, but there are a few open questions left
<dimitern> fwereade, like the ports collection, addresses on the machine doc, port on the address doc, and whether to expose subnet management commands
<dimitern> fwereade, also I'm a bit concerned about how to model ipv4 and ipv6 addresses on the same interface - as described we need 2 interface docs with the same name and different subnet ids (for 4 and 6)
<dimitern> fwereade, but we might have 2 subnetids on the interface doc instead - IPv4SubnetId and IPv6SubnetId
<dimitern> fwereade, thoughts?
<dimitern> TheMue, standup?
<TheMue> dimitern: so late already? coming
<voidspace> axw: wallyworld: ok - I have it so that local messages not originating from juju are no longer dropped
<voidspace> axw: wallyworld: now I need to test that juju messages still get through
<fwereade> dimitern, cheers, I'll take a look at the doc
<fwereade> dimitern, I don't immediately have ideas about 4v6 on the same interface
<dimitern> fwereade, right, thanks
<wallyworld> voidspace: just got back from soccer, great to see you've figured it out. you're now the juju-core rsyslog expert :-)
<bac> hi sinzui, i've been trying to test quickstart on utopic. the gui comes up fine but mediawiki and mysql (the only two i've tried so far) either error or never leave pending.  since bug 1314686 is resolved i would've expected success.
<_mup_> Bug #1314686: Please add support for utopic <packaging> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-core (Ubuntu):Fix Committed by racb> <https://launchpad.net/bugs/1314686>
<rogpeppe1> dimitern, fwereade, mgz: what do you think about making all the Snippet constants in the names package non-capturing?
<rogpeppe1> we just tried to use the snippets to do some parsing, and they're not that useful if they've got capturing groups inside
<mgz> rogpeppe1: I'd favour that
<mgz> I use non-capturing by default
<dimitern> rogpeppe1, then you'll need to change the parsing not to depend on capture groups
<bodie_> morning all
<rogpeppe1> dimitern: yeah
<mgz> rogpeppe1: unrelated, can you push your godeps changes again in a sec when I ask, the bot is getting some bits sorted out
<rogpeppe1> mgz: sure
<rogpeppe1> mgz: do you know what might've been going on there?
<mgz> there seems to be a shared repo across lots of packages, that got a particualr bug tickled, abentley is sorting it now we hope
<abentley> mgz: We are just working around the problem.  We hope.
<ericsnow> perrito666: would https://github.com/juju/juju/pull/135 have had any impact on the restore (plugin) issue?
<natefinch> ericsnow: standup?  Also perrito666 is on holiday
<wwitzel3> ericsnow: perrito666 is out today, I'm looking at the backup and restroe stuff
<ericsnow> natefinch: coming
<voidspace> wwitzel3: https://github.com/voidspace/juju/compare/local-syslog
<rogpeppe1> mgz, dimitern: https://github.com/juju/names/pull/9
<rogpeppe1> makes snippets non-capturing
<rogpeppe1> review appreciated :-)
<dimitern> rogpeppe1, reviewed
<rogpeppe1> dimitern: you're a star, ta!
<dimitern> :)
<voidspace> wwitzel3: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/479592
<rogpeppe1> merged!
<_mup_> Bug #479592: rsyslog doesn't work with property filter 'startswith' <rsyslog (Ubuntu):Confirmed> <https://launchpad.net/bugs/479592>
<rogpeppe1> who needs CI anyway :-)
<mgz> rogpeppe1: yeah, that looks fine
<voidspace> echo 'biggle again' | logger -p local0.notice -t juju-michael-local-
<voidspace> wwitzel3: ^^
<TheMue> dimitern: your suspicion has been a good one. our infrastructure simply only expects strings
<dimitern> TheMue, so if we need to support binary values for service settings that's something to keep in mind :)
<TheMue> dimitern: exactly
<voidspace> natefinch: so I *think* I've fixed the logging issue, wwitzel3 and I are testing
<voidspace> natefinch: the trouble is that we need to verify that logging still works properly with HA and units
<voidspace> natefinch: and you can't test that with local
<voidspace> natefinch: and it takes a while to check
<voidspace> natefinch: with my patch it now works properly again on local
<voidspace> I basically just got rid of the local ruleset - we just add the  rules that do the broadcasting and then drop the juju messages
<voidspace> no need for a new ruleset
<natefinch> voidspace: nice work'
<voidspace> natefinch: well, we'll see
<voidspace> my machine has now bootstrapped
<voidspace> wwitzel3: https://github.com/juju/juju/pull/137
<voidspace> axw: wallyworld_ : https://github.com/juju/juju/pull/137
<axw> voidspace: cool, thanks. so... those rules at the top go into the default ruleset?
<axw> now that there's no "local" one?
<alexisb> natefinch, perrito666 : where do we stand on lp 1332110?
<wwitzel3> alexisb: perrito666 handed that off to me, he is out today (natl holiday)
<alexisb> wwitzel3, ah ok, do you have an update?
<wwitzel3> alexisb: not fixed, I think we've isolated it to an issue with peergroup or instancepoller overwriting the conf, but not confirmed anything yet.
<alexisb> wwitzel3, ack, getting 1.19.4 out is important so if you need additional help/expertise let me know
<wwitzel3> alexisb: thanks, will do
<voidspace> I'm off for the week, have fun without me next week
<natefinch> voidspace: have fun!
<ericsnow> voidspace: \o
<voidspace> thanks
<voidspace> o/
<wwitzel3> voidspace: safe travels
<wwitzel3> natefinch: taking my car in
<natefinch> wwitzel3: ok
<rogpeppe1> mgz: do you want me to push that godeps branch?
<mgz> rogpeppe1: yah, lets do it
<mgz> so we can undo again if the next one borks
<rogpeppe1> mgz: ok, doing. i'll check you've got push rights so you can undo it, cos i'm just off for the w/e
<mgz> thanks
<rogpeppe1> mgz: ok, you're added and i've pushed it...
<rogpeppe1> mgz: now i'm off
<rogpeppe1> happy weekends all
<sinzui> what version of mongodb does juju require 2.4.6?
<sinzui> I see 2.4.9 in ctools, but I have not ported it to juju stable ppa?
<sinzui> natefinch, ^
<natefinch> sinzui: 2.4.6
<sinzui> thank you natefinch
<natefinch> wwitzel3: you around?
<wwitzel3> natefinch: am now
<wwitzel3> natefinch: an oil change and new plugs turned in to $2500 and come get your car next week
<alexisb> wwitzel3, sucky
<bodie_> 'lo alexisb :)
<bodie_> wwitzel3, that is lame
<ericsnow> wwitzel3: ouch
<wwitzel3> yeah :/
<bodie_> anyone have an idea how the canAccess stuff in apiserver works?
<bodie_> I'm trying to figure out whether it's necessary to "canAccess" the Unit that Actions are going to, when I query an Action from State
<bodie_> jcw4 / mgz / fwereade ?
<bodie_> sorry, state/apiserver in case that's too vague
<jcw4> bodie_: I don't know but I can investigate also
<natefinch> wwitzel3: wow suck
<wwitzel3> natefinch: I'm in moonstone
<bac> hi cmars
<alexisb> alrighty all, I am going to use friday afternoon to take down my system and do some much needed upgrades, if you need me call my cell or send me mail
<wwitzel3> alexisb: have a good weekend, will update via the mailing list my progress on the backup and restore when I hit EOD
<alexisb> wwitzel3, thank you!
<alexisb> have a great weekend yourself
<bodie_> oh good, my tests on master are passing again on my workstation
<bodie_> wonder what happened
#juju-dev 2014-06-21
<bodie_> if anyone's around, I have a quick question about some API-related stuff
<bodie_> the map I'm receiving is coming back with the keys in reverse order and it seems to be throwing off gocheck
<bodie_> if that doesn't make sense, I'm referring to the "obtained" and "expected" values of the map that are getting spit back by gocheck
<bodie_> I'm confident the maps are identical
<bodie_> https://github.com/juju/juju/pull/140
<bodie_> Actions API for Uniter
#juju-dev 2014-06-22
<bodie_> if anyone has a few minutes, I could really use a quick review on https://github.com/juju/juju/pull/140 and https://github.com/juju/juju/pull/141 !  Much appreciated :)
<waigani> morning all
<hatch> anyone familiar with creating relations with haproxy?
<hatch> annnnnd I just got it working, of course :)
<rick_h_> hatch: woot
<hatch> :)
 * hatch wants debug log in the gui....
<hatch> rick_h_ *caugh caugh*
<hatch> :P
<rick_h_> hatch: heh yea. It's on the cycle list but after MV
<rick_h_> hatch: so sooner you guys knock out MV :P
<hatch> lol
<hatch> rick_h_ horizontally scaled Ghost blog running with mysql and haproxy http://ec2-54-197-53-11.compute-1.amazonaws.com/ :)
<rick_h_> hatch: nice! :) so now to get proper http caching in place with varnish and it'll scale nicely
<hatch> there is an issue to add memcached, you should make an issue for varish as well :)
<hatch> https://github.com/hatched/ghost-charm/issues
<rick_h_> hmm, since it supports apache I wonder if you can just plug it into there vs ghost itself
<hatch> nooooo idea
<hatch> I haven't even looked at it
<hatch> feel free to leave notes to that effect in the issue :)
#juju-dev 2015-06-15
<davecheney> gocheck fans
<davecheney> is there a method to check []string, contains, string ?
<wallyworld> axw: partial review done, gotta go get coffee, wil finish soon
<axw> wallyworld: thank you
<thumper> davecheney: I've done jujud/agent now
<thumper> davecheney: I don't think there is a checker for that...
<davecheney> yeah, i wrote one myself
<thumper> davecheney: jc.Contains is a substring contains IIRC
<davecheney> urgh
<thumper> davecheney: do you know of a bug number for the gccgo problem comparing interface to struct?
 * thumper sighs...
<thumper> hard to make the tests pass on my branch for python-jujuclient when the tests don't even pass on trunk...
<thumper> meh, blocked by  https://bugs.launchpad.net/python-jujuclient/+bug/1465084
<mup> Bug #1465084: Tests fail with local provider and Juju 1.23.3 <python-jujuclient:New> <https://launchpad.net/bugs/1465084>
<davecheney> thumper: what bug is that ?
<davecheney> thumper: ready for 1:1
<davecheney> ?
 * thumper coming
<davecheney> thumper: https://github.com/go-check/check/issues/43
<davecheney> thumper: https://github.com/juju/juju/pull/2556
<axw> wallyworld: I've made a small change, about to push. added another case to the volumes which are removed on machine removal: unprovisioned machine-scoped
<wallyworld> axw: ok, will look
<thumper> davecheney: could you point Chris on https://github.com/go-check/check/pull/35 in the right direction of the sync call needed for the other read location?
<thumper> axw, davecheney: defers are last in first out right?
<axw> yep
<axw> thumper: ^
<thumper> cheers
<davecheney> thumper: will do
<davecheney> thumper: looks like your jujud/agent fix, didnt
 * thumper grunts
 * thumper looks
<thumper> man...
<thumper> hmm...
 * thumper interrupts his current work
<thumper> haha
<thumper> ha
<thumper> ha
<thumper> hmm
<thumper> not sure why the firewaller isn't starting...
<thumper> but I know why the test is timing out at 20 minutes
<thumper> it is because the rsyslog worker restarts every x seconds
<davecheney> thumper: http://paste.ubuntu.com/11717800/
<thumper> because it can
<davecheney> current state of play
<davecheney> there are new races in there
<thumper> can't write to a dir
<mup> Bug #1465115 opened: api: data race in test <juju-core:New> <https://launchpad.net/bugs/1465115>
<davecheney> thumper: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L187
<davecheney> WTF
 * thumper looks
<davecheney> NewServer prints out the address of the listneing socket
<davecheney> then ignores it
<davecheney> and passes new address to the srv type !?!??
<davecheney> WTFBBQ
<thumper> changes local IP address for localhost?
<davecheney> yes
<davecheney> change tghe listening address, the same port on localhost
<davecheney> i can't even, literally, even
<davecheney> thumper:
<davecheney> https://github.com/juju/juju/blob/master/apiserver/server_test.go#L114
<davecheney> this is nuts
<davecheney> we mask the address the apiserver is listening on
<davecheney> so that we can reliably construct urls pointing to localhost
<davecheney> what's the point of constructing a URL to localhost ?!?!
<thumper> the comment says because it resolves nicely with IPv4 and IPv6
<davecheney> it's wrong
<davecheney> nobody can be using srv.Addr
<davecheney> this is another horrible string in place of typed objects problem
<davecheney> hostname, portString, err := net.SplitHostPort(srv.Addr())
<davecheney> ^ treating the address like a string
<thumper> hmm..
 * thumper has to go and make dinner now
<davecheney> also, the apiserver tests sleep for a minute at the end of the test
<davecheney> because, well, basically, fy
<davecheney> ----------------------------------------------------------------------
<davecheney> PANIC: action_test.go:1: unitSuite.TearDownTest
<davecheney> ... Panic: local error: bad record MAC (PC=0x414746)
<davecheney> /usr/lib/go/src/pkg/runtime/panic.c:248 in panic
<davecheney> /home/ubuntu/juju-core_1.25-alpha1/src/github.com/juju/testing/mgo.go:559 in resetAdminPasswordAndFetchDBNames
<davecheney> /home/ubuntu/juju-core_1.25-alpha1/src/github.com/juju/testing/mgo.go:503 in MgoInstance.Reset
<davecheney> /home/ubuntu/juju-core_1.25-alpha1/src/github.com/juju/testing/mgo.go:605 in MgoSuite.TearDownTest
<davecheney> /home/ubuntu/juju-core_1.25-alpha1/src/github.com/juju/juju/juju/testing/conn.go:113 in JujuConnSuite.TearDownTest
<davecheney> /usr/lib/go/src/pkg/reflect/value.go:345 in Value.Call
<davecheney> /usr/lib/go/src/pkg/runtime/proc.c:1394 in goexit
<davecheney> ----------------------------------------------------------------------
<davecheney> PANIC: unit_test.go:317: unitSuite.TestPublicAddress
<davecheney> ffs
<dimitern> jam, o/ sorry for being late, omw
<jam> dimitern: actually I was looking for you
<jam> it looks like Mark moved the spec meeting to today
<jam> so I've got a conflict
<dimitern> I see
<dimitern> ok, so no meeting then?
<dimitern> :)
<jam> dimitern: I'm happy to reschedule as it seems like we've been missing eachother. But I should also see you at standup I guess.
<dimitern> jam, indeed
<jam> dimitern: but yes, enjoy your breakfast
<dimitern> jam, thanks :)
<mup> Bug #1465157 opened: uniter/filter: FilterSuite.TestUnitRemoval failure in CI <juju-core:New> <https://launchpad.net/bugs/1465157>
<jam> wallyworld: ping
<wallyworld> hi
<wallyworld> thanks for doc comments
<wallyworld> i need to rework examples etc to match changes
<jam> wallyworld: Did you see the changes on the draft spec ?
<jam> wallyworld: mark and I met today and we had some thoughts on the syntax
<wallyworld> jam: yeah, i already acted on them
<jam> wallyworld: which I'm happy to discuss with you via whatever mechanism you prefer :)
<wallyworld> i've got to update doc examples to match
<jam> wallyworld: k, I might have been messing with your changes then, cause I was trying to put them into the use case spec as suggestions
<wallyworld> ah, i haven't updated the se cases yet
<wallyworld> that's on my todo list
<wallyworld> jam: about to go eat dinner, i'll ping you later on
<jam> wallyworld: k
<TheMue> dimitern: now you're frozen
<wallyworld> jam: did you want to talk about CLI syntax?
<voidspace> dimitern: ping
<dimitern> voidspace, omw
<wallyworld> fwereade: hey, are you able to look at and comment on bug 1464470
<mup> Bug #1464470: A subordinate charm hook scheduled to run(but waiting for the principal charm hook to release the lock) goes to an error state after the principal charm hook triggers a reboot. <1.24> <1.25> <hooks> <juju> <reboot> <regression> <subordinate> <windows> <juju-core:Triaged> <juju-core
<mup> 1.24:Triaged> <https://launchpad.net/bugs/1464470>
<wallyworld> some initial analysis has been done
<wallyworld> needs a sme :-)
<fwereade> wallyworld, right, I need to think a bit more about that
<wallyworld> sure np :-)
<fwereade> wallyworld, I think the fix is correct in spirit but I haven't figured out all the actual consequences
<wallyworld> yup
<voidspace> dooferlad: https://github.com/juju/juju/compare/devices-api-maas...voidspace:generate-macs
<voidspace> dooferlad: I can talk to you about that after standup
<dooferlad> voidspace: thanks - sounds good
<dimitern> voidspace, o/
<voidspace> dimitern: omw
<voidspace> dimitern: there
 * Mmike grabs food
<rogpeppe1> axw: any chance you're around? :)
<mup> Bug #1403955 opened: DHCP's "Option interface-mtu 9000" is being ignored on bridge interface br0 <cts> <kvm> <lxc> <network> <juju-core:Triaged> <isc-dhcp (Ubuntu):Confirmed> <https://launchpad.net/bugs/1403955>
<mup> Bug #1465307 opened: 1.24.0: Lots of "agent is lost, sorry!" messages <landscape> <juju-core:New> <https://launchpad.net/bugs/1465307>
<mup> Bug #1465317 opened: Wily builds fail: panic: osVersion reported an error: Could not determine series <packaging> <wily> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1465317>
<dimitern> voidspace, you have a review btw
<voidspace> dimitern: cool
<voidspace> dimitern: I realised there's a bit of code missing though
<voidspace> dimitern: which probably also means missing tests :-/
<dimitern> voidspace, oh really?
<voidspace> dimitern: I need to populate NetworkInfo for kvm broker as well as lxc broker...
<dimitern> voidspace, well, I trust your judgment then :)
<dimitern> voidspace, oh, of course
<voidspace> dimitern: the important code is in configureConatinerNetworking which is used by both lxc and kvm brokers, and just happens to live in lxc-broker.go
<voidspace> so I was only manually testing that mac addresses were used by the lxc broker
<voidspace> when I discovered that NetworkInfo was empty
<voidspace> it's a one line fix, but also needs some test fixes too I think
<voidspace> ah no, everything passes
<voidspace> I'd better add one more test for this though
<voidspace> dimitern: ok, will look at your review - thanks
<voidspace> dimitern: wow, a Ship It! first time
<voidspace> dimitern: shame it wasn't complete ;-)
<dimitern> voidspace, ")
<dimitern> voidspace, :) even
<voidspace> dimitern: updated
<rogpeppe1> i am consistently seeing test failures in worker/provisioner (TestStartInstanceWithStorage and TestStartInstanceLoopMountsDisallowed)
<rogpeppe1> can anyone get those tests to pass, or is it just me?
<rogpeppe1> this is on juju-core tip, BTW
<voidspace> rogpeppe1: there's a data race I believe
<rogpeppe1> voidspace: really?
<voidspace> rogpeppe1: normally those tests just pass silently
<voidspace> rogpeppe1: yes
<rogpeppe1> voidspace: do you know what the race is?
<voidspace> rogpeppe1: startInstance in lxcBrokerSuite calls fakeAPI methods
<voidspace> rogpeppe1: these have an assert in them
<rogpeppe1> voidspace: i've removed the assert
<voidspace> rogpeppe1: ah, that's why you have the problem then
<natefinch> rogpeppe1: both those tests pass for me btw
<rogpeppe1> voidspace: (it always failed anyway)
<rogpeppe1> natefinch: interesting.
<voidspace> the assert failing was halting the test prematurely
<voidspace> natefinch: they will pass until you remove the assert in the fake API
<voidspace> rogpeppe1: this branch fixes it
<voidspace> <rogpeppe1> voidspace: i've removed the assert
<rogpeppe1> voidspace: ah, that makes sense
<voidspace> dammit
<voidspace> rogpeppe1: https://github.com/juju/juju/pull/2565
<natefinch> voidspace: well, rogpeppe1 asked if it passed on tip, and the answer is that it passes on tip for me... not with any changes :)
<voidspace> rogpeppe1: but that's merging onto a feature branch
<voidspace> natefinch: right
<voidspace> fair enough :-)
<rogpeppe1> voidspace: it would be great to submit it is a separate fix if poss
<voidspace> rogpeppe1: I believe that dooferlad is extracting the data race fix as a separate fix and merging it to trunk
<rogpeppe1> voidspace: ah, it's merging already
<voidspace> rogpeppe1: so "in progress"
<rogpeppe1> voidspace: it's not really a race
<rogpeppe1> voidspace: more like a bug in gocheck
<voidspace> rogpeppe1: ok, sounds plausible
<rogpeppe1> voidspace: ok, so i'll ignore the test failures for the time being. hopefully your branch will land.
<rogpeppe1> voidspace: what's the *gitjujutesting.Stub field for in the fakeAPI struct?
<voidspace> rogpeppe1: it's Stub that provides MethodCall, NextErr and SetErrors
<voidspace> rogpeppe1: and CheckCalls
<rogpeppe1> voidspace: ah, so the required interface has grown, i see
<voidspace> rogpeppe1: well, Stub is an implementation not an interface
<rogpeppe1> voidspace: those methods weren't provided before by fakeAPI, so i can only presume that the required interface that it's implementing has grown
<voidspace> rogpeppe1: nope
<voidspace> rogpeppe1: Stub provides useful mocking methods for fakeAPI
<rogpeppe1> voidspace: hmm, i must be missing something then
<voidspace> rogpeppe1: nothing to do with the API that fakeAPI provides
<rogpeppe1> voidspace: ok, i must have missed where they're used
<voidspace> rogpeppe1: they're not required for fakeAPI they're useful for testing
<voidspace> rogpeppe1: grep through that diff to see them in use
<voidspace> rogpeppe1: CheckCalls uses the results of MethodCall
<voidspace> rogpeppe1: NextErr uses the errors set by SetErrors
<rogpeppe1> voidspace: i think it's somewhat misleading to embed Stub as an anonymous field
<rogpeppe1> voidspace: it makes it look like it's being used to expose methods outside of fakeAPI
<voidspace> rogpeppe1: what do you mean by "outside"?
<voidspace> rogpeppe1: it's the intended use of Stub I believe
<rogpeppe1> voidspace: the whole point of fakeAPI is to fulfil the provisioner.APICalls interface
<rogpeppe1> voidspace: by embedding Stub, you make it look as if that is helping to fulfil that interface
<voidspace> rogpeppe1: right, and Stub is a helper to do that
<voidspace> rogpeppe1: the name is a big clue :-)
<rogpeppe1> voidspace: whereas it's actually just an implementation detail *inside* fakeAPI
<voidspace> as well as how it's used
<rogpeppe1> voidspace: i don't understand - none of the methods required by provisioner.APICalls are implemented by Stub
<rogpeppe1> voidspace: so the fact that it's embedded isn't helping at all
<voidspace> rogpeppe1: it's a helper for writing stubs
<voidspace> it doesn't take much beyond knowing [anything about] the API it provides to realise what it's for
<rogpeppe1> voidspace: generally we embed fields for a reason, usually because we need the methods they implement in the method set of the object they're embedded in
<voidspace> rogpeppe1: Stub is regularly embedded in fakes like this
<rogpeppe1> voidspace: in this case, it seems to be embedded just to avoid an explicit field name reference
<voidspace> and knowing what Stub doesn't it isn't reasonable to think that Stub actually provides any methods of the external API that the fake object provides
<voidspace> so you seem to be making a purist point rather than a practical one
<rogpeppe1> voidspace: it would be much more obvious that it wasn't involved if it wasn't embedded
<rogpeppe1> voidspace: i'm saying that it makes the code less readable
<voidspace> and I'm saying I disagree
<voidspace> if it is a confusion it can only be if you haven't seen Stub before, and even then only momentarily
<voidspace> and this is how Stub is used in many places in our code
<voidspace> presumably you're the first to complain
<rogpeppe1> voidspace: the Stub documentation can't agree with itself whether it's supposed to be embedded or not
<rogpeppe1> voidspace: i see that it's used in other places like that, and i think it's a mistake
<rogpeppe1> voidspace: i think it makes a big difference whether the method set of an object is immediately seeable or not.
<rogpeppe1> voidspace: might i ask *why* you think it's a good idea to embed it, rather than using a named field?
<voidspace> I don't think it's a bad idea
<voidspace> and given that fake objects provide a specific interface (that being their point)
<voidspace> and Stub objects provide a different, very specific, set of methods
<voidspace> I don't think there's any reasonable possibility for confusion once you know what Stub does
<rogpeppe1> voidspace: but what's the advantage of embedding?
<rogpeppe1> voidspace: it can only be that it's slightly less code to use, i guess
<voidspace> I don't see any advantage to mandating *not embediding*
<voidspace> which is the direction you want to go
<voidspace> right, slightly extra effort
<rogpeppe1> voidspace: embedding imposes greater cognitive load on the reader of the code
<voidspace> I disagree
<voidspace> as I've already stated
<rogpeppe1> voidspace: "extra effort" being as hard as ".stub"
<rogpeppe1> voidspace: you've said "once you know what Stub does" - that's what i mean by extra cognitive load
<voidspace> extra cognitive load being as hard as "that's a stub method"
<voidspace> to understand the code you *need* to know what it does
<voidspace> you can't get away from that!
<rogpeppe1> voidspace: i don't recognise the term "stub" from normal Go idioms
<voidspace> it's a programming term
<voidspace> :-)
<voidspace> language agnostic
<rogpeppe1> voidspace: it's a terrible name - it means nothing really
<voidspace> getting you a link to the classic martin fowler paper
<voidspace> it's the generally used one
<voidspace> http://martinfowler.com/articles/mocksArentStubs.html
<rogpeppe1> voidspace: it would be better as "APIStub" perhaps
<voidspace> see that article
<voidspace> Stub itself can be used for any interface in juju - not just for APIs
<rogpeppe1> voidspace: by the terminology of that article, i don't think it's either a mock or a stub
<rogpeppe1> voidspace: i think it's a helper
<voidspace> yeah, a helper for writing stubs
<rogpeppe1> voidspace: sure
<voidspace> I didn't write it or name it either by the way
<rogpeppe1> voidspace: i think it's confusing to call it a stub when it's not, especially as "testing.Stub" tells you nothing at all about what it might be useful for
<voidspace> rogpeppe1: ok
<rogpeppe1> voidspace: and i think that embedding is conflating the testing.Stub helper with the stub itself in an unhelpful way
<rogpeppe1> voidspace: i'll stop now. you weren't responsible :)
<voidspace> rogpeppe1: :-)
<rogpeppe1> voidspace: it feels like something implemented by someone that's still thinking in an inheritance-based way, not someone that actually knows Go well
<voidspace> rogpeppe1: I don't object to a named field (with the exception I guess if that has to be a public field if you're writing re-usable stubs)
<voidspace> rogpeppe1: however I don't philosphically disagree with embedding either
<voidspace> it certainly works fine not embedded - at the cost of an extra level of indirection for every use
<rogpeppe1> voidspace: if i was writing a wrapper around Stub that just added some functionality, *then* embedding would be appropriate
<rogpeppe1> voidspace: that's not a runtime cost, of course
<voidspace> I don't care about runtime cost until it's proven to be an issue
<rogpeppe1> voidspace: +1
<voidspace> I'm talking about cognitive overhead for the reader of the code ;-)
<rogpeppe1> voidspace: for me, the "cost" of an extra level of indirection is actually a net benefit to the reader of the code
<voidspace> deliberate winky-smiley as I'm provoking you...
<rogpeppe1> voidspace: because you know exactly which field is being routed to
<voidspace> rogpeppe1: I understand what you're saying
<rogpeppe1> voidspace: BTW you could use Stub as a value in the struct - no need to declare it as a pointer
<voidspace> rogpeppe1: that would probably simplify it a bit
<voidspace> rogpeppe1: just to show that I'm not utterly recalcitrant I'll change it to a field, and a value rather than a pointer
<voidspace> rogpeppe1: in a follow up
<voidspace> rogpeppe1: that branch landed - but only on a feature branch, not on trunk
<rogpeppe1> voidspace: thanks, that would be appreciated
<voidspace> rogpeppe1: dooferlad is working on porting the relevant bits to trunk
<rogpeppe1> voidspace: oh bugger
<rogpeppe1> voidspace: i just pulled, hoping that would fix my tests
<voidspace> rogpeppe1: so you can have exactly the same conversation with him...
<voidspace> rogpeppe1: afraid not, unless you pulled our feature branch!
<voidspace> rogpeppe1: I'll chat to dooferlad about it, I presume he's not around *right now* or he would already have popped up
<voidspace> dooferlad: ping if you're around
<voidspace> rogpeppe1: (I did talk to him this morning about porting these changes across - so I know he's working on it)
<rogpeppe1> voidspace: perhaps this one fix could be ported separately
<voidspace> rogpeppe1: yep
<voidspace> rogpeppe1: he may already be part the way through it
<voidspace> rogpeppe1: it involves changes to lxc-broker_test.go *and* kvm-broker_test.go (as kvm broker uses the fakeAPI as well)
<voidspace> rogpeppe1: so if he's started it would be quicker to get that in than for me to unpick the branch I've just landed
<voidspace> rogpeppe1: but if he hasn't done it I can do it tomorrow (morning hopefully)
<dooferlad> voidspace, rogpeppe1: Hi, was just AFK for 10 minutes saying hello to the family since they just got home. I am just about to push my changes after a quick readthrough. They pass all the tests I have done.
<rogpeppe1> voidspace: thanks. it would be nice to have juju-core tests passing locally
<dooferlad> rogpeppe1, voidspace: http://reviews.vapour.ws/r/1936/
<dooferlad> there will be a 1.4 change landing soon
<dooferlad> s/landing/being proposed/
<rogpeppe1> dooferlad: 1.4 version of what? Go?
<voidspace> dooferlad: looking
<dooferlad> rogpeppe1: juju
<rogpeppe1> dooferlad: ah, i've totally lost track of juju version numbering :)
<rogpeppe1> dooferlad: aren't we at ~1.25 ?
<rogpeppe1> dooferlad: or is this a version for some different aspect of juju?
<voidspace> dooferlad: I presume you mean 1.24...
<voidspace> rogpeppe1: you are correct
<dooferlad> rogpeppe1: oh, 1.24. Just being distracted by a tiny cute person. Sorry!
<rogpeppe1> voidspace: ah, that really confused me!
<dooferlad> OK, need to call it a day. The fix backporting involves a little more than a cherry pick and fixing up the juju/testing version so I will get it done tomorrow morning.
<voidspace> dooferlad: you have a review
<dooferlad> voidspace: thanks
<voidspace> dooferlad: mostly trivial - but there's one test that I think might be wrong
<dooferlad> voidspace: will get to it tomorrow first thing. Thanks for taking a look!
<voidspace> dooferlad: cool
<rogpeppe1> wow, cmd/juju tests now taking 9m to run!
<natefinch> rogpeppe1: is that better or worse than they used to be for you?  (I'm hoping worse)
<rogpeppe1> natefinch: i'm pretty sure it's quite a bit worse
<natefinch> actually,  I guess better is better....  but still.  9m sucks
<rogpeppe1> natefinch: i remember 5 minutes, but 9?!
<natefinch> rogpeppe1: is that on tip?
<rogpeppe1> natefinch: yeah
<rogpeppe1> natefinch: 9m for one package|
<rogpeppe1> !
<rogpeppe1> natefinch: i'm off now, back on wed
<natefinch> rogpeppe1: have fun!
<rogpeppe1> natefinch: will do
<natefinch> rogpeppe1: fwiw, go test in cmd/juju runs in 2m35s  on my machine on tip
<natefinch> note that's go test, not go test ./...  if that makes a difference
<voidspace> rogpeppe1: they time out on my machine
<natefinch> voidspace: doh
<voidspace> yep :-)
<voidspace> natefinch: 2m35! I'm on vivid
<voidspace> I wonder if they're worse on vivid
<natefinch> voidspace: I'm on utopic... it might be my SSD, it's a Samsung 850 pro, itsuper fast.
<natefinch> s/itsuper/it's super/
<natefinch> voidspace: I noticed davecheney complaining about the time tests took, and his numbers were like 30 mins for the whole suite
<natefinch> voidspace: I'm running go 1.3.3 right now (just happens to be what I last switched to), and I run gomaxprocs=8.  Not sure if any of that makes a big difference or not
<voidspace> natefinch: I think my SSD is an 840 - not going to be a *great* deal of difference I don't think
<voidspace> I'll try them on my laptop
<voidspace> natefinch: I'm running go 1.2.1 maybe that hurts
<natefinch> voidspace: newer versions are definitely faster, though I wouldn't think they'd be that much faster
<voidspace> gomaxprocs wouldn't affect the timing of one package, as that will be a single process
<natefinch> voidspace: good point
<voidspace> natefinch: if it makes it faster enough to not timeout that would be progress for me...
<voidspace> updating to 1.3
<natefinch> voidspace: you're on an XPS 15, too, right?
<voidspace> natefinch: this is on my desktop
<natefinch> voidspace: which should be even faster, presumably
<voidspace> natefinch: yeah, but not much
<voidspace> trying now with go 1.3.3
<voidspace> natefinch: I wonder if vivid is the difference
<voidspace> natefinch: my laptop is utopic
<voidspace> natefinch: I'll try on that
<perrito666> man running tests on a bar drives all kinds of odd looks to your screen
<natefinch> heh
 * perrito666 deploys a lot of things on a bar, will start hearing angry people in 3, 2, 1 ....
<perrito666> Brb
<katco> perrito666: natefinch: cherylj: wwitzel3: i need a volunteer to look at bug 1465307
<mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1465307>
<natefinch> mup: infer RandomChoice[{'natefinch', 'howAboutThatNateGuy', 'ummmNate'}]
<mup> natefinch: WolframAlpha request failed. Please try again soon.
 * natefinch sighs
<katco> lol
<natefinch> katco: well, regardless of mup trying to save me from myself, I can volunteer
<katco> natefinch: :p ok ty... please remember to assign yourself to the bug and keep the comments updated w/ progress
<katco> natefinch: fwiw, i don't think it has to do with leadership, i think the messages were just symptoms of something larger not running, but that was just from a very cursory analysis
<natefinch> katco: doesn't look like a happy environment, that's for sure
<katco> natefinch: yeah
<natefinch> dpb1: can you post some logs to #1465307?
<mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1465307>
<dpb1> natefinch: I downloaded everything, let me look through
<dpb1> natefinch: ok, check those, if you want any more let me know
<dpb1> natefinch: so far, I don't really have any issue repeating this.
<natefinch> dpb1: what are the repro steps?
<dpb1> natefinch: I'm deploying a customish bundle.  I could try minimizing it.  I would say, bootstrap + 5 lxc + 3 other nodes.  all with the ubunt charm, that would probably be enough to hit it.
<natefinch> dpb1: I can't reproduce it just deploying the ubuntu charm to a bunch of machines.  If you could get some minimal repro steps, that would be great.
<natefinch> dpb1: I'll be on later to look into it some more.
<dpb1> ok
<voidspace> natefinch-afk: hey, on my utopic laptop cmd/juju takes 248 seconds
<voidspace> natefinch-afk: still slower than your machine (will try again with newer version of go)
<voidspace> natefinch-afk: but they time out on my vivid desktop
<mup> Bug #1465404 opened: worker/provisioner: fail lxcBrokerSuite.TestStartInstanceLoopMountsDisallowed <juju-core:New> <https://launchpad.net/bugs/1465404>
#juju-dev 2015-06-16
<rick_h_> axw: I commented through the resources spec. Please let me know if anything I say makes little to no sense or a chat through would help make things clear/etc.
<rick_h_> axw: well, not the spec I guess, but the use case/design doc which had a lot more interesting details
<axw> rick_h_: ok, wallyworld has been doing that mostly, but I can take a look if you like
<rick_h_> axw: ah np, I was going to ping you both but he's afk from irc atm
<rick_h_> axw: if he comments just let him know I'm happy to be schooled in person/etc.
<axw> rick_h_: heh :)  no worries
<thumper> wallyworld: damn hangouts
<thumper> I could hear you, but you weren't moving
<wallyworld> yeah, tis ok. i'll reply
<thumper> and stuff I typed into the chat window didn't come through
<thumper> cheers
<menn0> axw, wallyworld: i just noticed that our tests prefer the system installed mongod over the Juju one. is that intentional?
<axw> menn0: hrm, I didn't think so. I thought we were meant to use juju-db if it existed, otherwise whatever's available
<wallyworld> um, don't think so
<menn0> axw, wallyworld: getMongod (in juju/testing) tries $PATH first so that one wins if you have the system mongodb package installed
<axw> menn0: oh sorry, the *tests*. I think the reason for that is so we get the javascript-enabled version if it's there
<axw> menn0: IIRC juju-db doesn't have javascript on some arches
<axw> possibly all
<menn0> axw: why do we need a JS enabled monogdb?
<axw> menn0: for charmstore I think
<menn0> axw: ah ok
<menn0> axw: it's just unfortunate that we can end up running tests with the mongodb version that isn't actually used in production
<menn0> axw: it probably doesn't matter most of the time
<axw> menn0: true. perhaps it should be juju-db by default, and configurable (for charmstore)
<menn0> axw: except if we unwittingly take advantage of some newer feature of mongodb
<anastasiamac> davecheney: o/
<anastasiamac> davecheney: what were the problems with importing "time"?
<davecheney> anastasiamac: it is a symptom if a flakey test
<davecheney> kicking off an actoin then waiting for some time to pass
<davecheney> is likely to be flakey
<anastasiamac> so it's only a "symptom" if imported in tests?
<anastasiamac> it's k to import into actual code..
<anastasiamac> davecheney: ?
<davecheney> yes
<davecheney> but imo test files that import "time" tend to be flakey
<anastasiamac> davecheney: :D ty for ur passion! (and answers)
<davecheney> no
<davecheney> np
<davecheney> i say they are flakey because there is in herent uncertainty
<davecheney> the test is usually saing somthing like "I'm going to hope that X happens in under NNN milliseconds, or Y shouldnt take more than NNN milliseconds to happen"
<davecheney> and if uou look at our build bot
<davecheney> neither of those tend to be true
<anastasiamac> :)
<anastasiamac> I am going to add a "r u absolutely sure?!" to a review I am doing based on ur opinion. I would love for us to move away from using actual "time" in tests... whether it will ever happen is a separate question...
 * davecheney bursts into tears of applause
 * anastasiamac can't believe she made Dave cry.. of joy nonetheless.. 
<anastasiamac> :D
<davecheney> it doesn't take much these days
<davecheney> http://gophercon.com/
<davecheney> note the helpful countdown, telling me how much work I haven't done
<anastasiamac> davecheney: it's impressive! well done :D m not going but it's looking to be really exciting!!
<menn0> can i trouble someone for an easy review? http://reviews.vapour.ws/r/1940/
<anastasiamac> menn0: looking ...
<menn0> anastasiamac: thanks
<anastasiamac> menn0: rhetorical question :D...
<anastasiamac> so the deque with max length as 0 will behave as before?
<anastasiamac> dropping from the other side?
<anastasiamac> menn0: neevr mind - re-read and re-understood :D
<menn0> anastasiamac: with a max len of 0, there is no maximum length (as before)
<menn0> ok :)
<menn0> anastasiamac: thanks for the review!
<fwereade> axw, anastasiamac: thanks for the reviews
<fwereade> anastasiamac, about the exported test suites
<axw> fwereade: nps
<fwereade> anastasiamac, do you know why people *avoid* exporting test suites?
<fwereade> anastasiamac, I've seen people do it
<fwereade> anastasiamac, and I've always thought it's a bit weird, but AFAICS it makes no practical difference at all
<fwereade> anastasiamac, so I always chalked it up to matter-of-taste-don't-worry-about-it
<anastasiamac> fwereade: well, I am kind of on the fence of this one...
<anastasiamac> fwereade: i just don not see the point of exporting suite
<anastasiamac> fwereade: and all suites that i have "accidentally" written with Capitals, I was told to change
<anastasiamac> fwereade: :D
<axw> fwereade: it doesn't really make a difference. I would argue if it's an internal test package (i.e. not _test), then not exporting keeps the exports clean for the _test package (not the case here)
<axw> otherwise matter of taste
<fwereade> anastasiamac, (fwiw, exporting "feels" right to me because the tests *are* the reason for the package to exist -- and I know it *really* works by passing it as an interface{} into gc.Suite, but the semantic payload of "this component is important and part of the public expression of the package" feel relevant)
<anastasiamac> fwereade: from practical perspective, I use autocompletion a lot
<anastasiamac> fwereade: and exported tests are visible
<anastasiamac> fwereade: they tempt me to re-use them
<anastasiamac> fwereade: I would rather they were not exported if noone else is meantt o use them :D
<fwereade> anastasiamac, when do you import a foo_test package? I thought you couldn't
<fwereade> anastasiamac, I submit that your autocomplete is buggy if it's pulling in stuff exported from _test packages ;p
<anastasiamac> fwereade: i do not import... I auto-complete.. which tries to import if I select something
<anastasiamac> fwereade: possibly... but it's not a deal breaker either way...
<anastasiamac> fwereade: i guess i wonder why export if it's not re-used?
<fwereade> anastasiamac, semantic payload
<anastasiamac> fwereade: so mayb we should have a consensus - export all suites :D
<fwereade> anastasiamac, possibly a bit of habit from python? I wouldn't keep a test private because I'd expect something like nose to find it for me, and my views on how tests shoudl be expressed are probably coloured by that
<anastasiamac> fwereade: m happy to let it go.. altho "semantics" does not really give an argument a tangible benefit IMHO :D
<fwereade> anastasiamac, heh, I feel it's terribly important
<anastasiamac> fwereade: :D if u feel "terrible" importance, I am happy to go with ur gut feeling
<fwereade> anastasiamac, the set of associations triggered in the developer's mind have a massive effect on how they use the code, and what expectations they have of it
<anastasiamac> and take it up next sprint :D
<fwereade> anastasiamac, the trouble is that it's hard to measure those effects objectively
<fwereade> anastasiamac, and even if you could they'd diiffer across sets of developers
<fwereade> anastasiamac, (sorry I'm not saying that test-exports are terribly important -- but I think the semantic associations of the names we pick *are*)
<anastasiamac> fwereade: mayb because I do not have python goggles on, I m a bit reserved about exporting un-reusable bits of code (or tests for that matter)
<anastasiamac> fwereade: semantics assosciations of names r important...
<anastasiamac> fwereade: exporting or not exporting test suites is an approach (pattern?) not a naming semantics... no? ;))
<fwereade> anastasiamac, (...and I guess the extension of that is that exporting a type itself has semantic associations; and in my mind the "these are the parts someone using this package cares about" associations are stronger, in my own mind, than the "someone will actually want to import this type" ones)
<fwereade> anastasiamac, that's only true because you can't import test packages though
<anastasiamac> fwereade: :D
<fwereade> anastasiamac, if you could then the choice would not be completely academic
<anastasiamac> fwereade: i am happy for an executive decision here :D what would u like to see as a convention - export or not export? to be or not to be?
 * anastasiamac @ school run
<fwereade> anastasiamac, my personal preference would be to export, but I also feel like tastes can legitimately differ, which is why I never made a fuss when I saw people starting to not-export-by-habit
<fwereade> anastasiamac, if we can predict harm caused by unpredictably-exported tests, yeah, we should pick a convention, but I can't really see anyone being inconvenienced either way?
<anastasiamac> fwereade: tyvm for an amazing discussion point :D it's always re-freshing to hear ur thoughts and read ur reasoning :))
<fwereade> anastasiamac, thank you, always a pleasure :)
<TheMue> dimitern: ping
<dimitern> TheMue, pong
<fwereade> anastasiamac, what'd be the advantage of enums for fieldnames?
<TheMue> dimitern: one question regarding API errors. they have a message and a code. if an operation on state returns with an error it's clear to put it, sometimes with additional information, into the message. but do we have a common strategy which codes to use? e.g. when ipaddress.Remove() fails.
<fwereade> oops brb
<dimitern> TheMue, yes, use common.ServerError() to wrap an error as *params.Error
<dimitern> TheMue, btw I couldn't see an update in any of your branches
<TheMue> dimitern: aaaah, the missing puzzle piece
<TheMue> dimitern: yeah, just wanted to finish the remove method
<dimitern> TheMue, ok, cool
<TheMue> dimitern: feeling better with the current state of the code, even if I'm still not happy with our API segmentation :D
<dimitern> TheMue, well, one step at a time :)
<TheMue> dimitern: hehe, yes
<TheMue> wrapping an error into an error result into error results, seems to be a very brittle piece of data
<TheMue> ah, when wanting to use a mock state from inside a mock entity, this field should not be nil *facepalm*
<fwereade> axw, anastasiamac: have several responses on http://reviews.vapour.ws/r/1934/ ; thoughts appreciated
<axw> fwereade: thanks, responding now.
<axw> fwereade: BTW, it makes it much easier to follow up if you reply on the review page, rather than in the diff. your responses came up as new issues
<dimitern> voidspace, fwereade, standup?
<voidspace> dimitern: omw
<fwereade> axw, yeah, sorry about that, will try to remember -- I tend to click through for context and forget to go back
<fwereade> dimitern, oops omw
<axw> fwereade: yeah, it's kind of an annoying interface when replying to comments.
<axw> fwereade: responded. thanks, my primary issues were just misunderstandings. LGTM, thanks!
<fwereade> axw, awesome
<fwereade> axw, it's not ready yet though. not enough tests :)
<axw> fwereade: I know, I just meant the logic itself
<axw> and interface
<fwereade> axw, perfect, tyvm
<jam> voidspace: 7m30s in a trusty vm on my laptop with an SSD, but modest CPU
<fwereade> axw, hey, one thought: I'm becoming convinced that info,EarliestExpiry is an internal implementation detail, and exposing it can only encourage people to DTWT
<fwereade> axw, opinion?
<fwereade> axw, we still need it internally ofc
<axw> fwereade: I think I agree, let me take another look
<fwereade> axw, and then Info is just Holder;Expiry;AssertOp
<axw> fwereade: yes, SGTM
<fwereade> axw, cool, thanks
<dimitern> dooferlad, as you drop that test about allowing loop mounts not returning an error, you might close bug 1465404 as a side-effect
<mup> Bug #1465404: worker/provisioner: fail lxcBrokerSuite.TestStartInstanceLoopMountsDisallowed <juju-core:New> <https://launchpad.net/bugs/1465404>
<dooferlad> dimitern: thanks, will do.
 * dimitern ffs.. it takes more than 30m to run all tests on my machine, even with gt
<dooferlad> dimitern: gt will only help once you have run once. It should now run in about a second
<dooferlad> dimitern: until you change something that is, but it is still much faster not re-running tests on code that hasn't changed.
<dimitern> dooferlad, I can't wait for it to complete so I can see if there will be an improvement the second run
<dooferlad> dimitern: :-)
<dooferlad> dimitern: guess a new machine is needed!
<dooferlad> dimitern: not that I have a problem and buy new computers way too often...
<dimitern> dooferlad, it's high time for a new one; I might not even wait until october for my laptop refresh :)
<dooferlad> dimitern: well, the laptop refresh is just money right? If you can afford to spend now then you still recover the money in october.
<dimitern> dooferlad, yeah, of course - it's now *yet* bugging me that much, but it's close
<dimitern> wow!
<dimitern> it does indeed run in a couple of seconds after the first run - and prints out nice cached panics as well :)
<dooferlad> dimitern: so, perhaps gt needs a cloud option - share the cached results for a particular file hash...
<dooferlad> dimitern: should be really easy to add...
<dimitern> dooferlad, that'll make it reusable a lot easier among teams
<dooferlad> dimitern: exactly. All of juju (or any project) could basically share CPU time across all their machines
<dooferlad> dimitern: new friday labs project then?
<dimitern> dooferlad, sounds like it, yeah - I was just about to say the same :)
<dooferlad> dimitern: https://github.com/rsc/gt/blob/master/main.go already uses sha1 to hash files and packages, so just storing them somewhere that isn't ~/.cache/go-test-cache is all you need
<dooferlad> dimitern: ok, that looks just too simple not to do
<dimitern> dooferlad, :)
<dimitern> dooferlad, but if it takes more time, please put it on hold
<dooferlad> dimitern: oh, I am not doing it *right now*
<dooferlad> dimitern: I have some self control!
<dimitern> dooferlad, I know it's tempting :)
<voidspace> jam: just seen your message
<voidspace> jam: I still don't know the full runtime on this desktop - it timed out after 40 minutes so trying with an even more ridiculous timeout (2 hours)
<voidspace> jam: there's something up on this machine
<jam> voidspace: that sounds more like just a simple deadlock. If you do "go test -timeout" won't it print a panic for you?
<voidspace> jam: well I know *one* test takes 9 minutes so it may not be a deadlock
<voidspace> jam: (one specific test)
<voidspace> jam: yeah, I get the panic - not dug into it
<wallyworld> dimitern: hi
<dimitern> wallyworld, hey
<wallyworld> dimitern: i had on my todo list today bug 1464616 for 1.24.1 but i've only just finished some work in progress. maybe one of your guys could take a look and i'll fix it tomorrow if needed if you don't get to it?
<mup> Bug #1464616: destroy-machine --force no longer forceably destroys machine <destroy-machine> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged by wallyworld> <https://launchpad.net/bugs/1464616>
<dimitern> wallyworld, Iooking
<dimitern> looking even
<wallyworld> ty, see how you go, i'll fix tommorrow if needed
<dimitern> wallyworld, cheers, have a good one
<anastasiamac> fwereade: re enums :D
<voidspace> jam: less than an hour is the answer... 2990.665s :-) definitely something up there.
<anastasiamac> fwereade: my personal guiding force is 1. type protection vs magic strings/numbers; 2. grouping of related constants
<wallyworld> fwereade: hey, could you take a look at perrito666's latest uniter hook work to see if you're happy for the pr to land?
<fwereade> wallyworld, sorry, will do
<wallyworld> ty
<anastasiamac> fwereade: of course, since most of ur consts are unexported and internal to the package, u could say that putting enums might be a bit on the paranoid side...
<fwereade> anastasiamac, sorry phone
<anastasiamac> fwereade: nps :) can be another of these topics we discuss informally over drinks ;D
<fwereade> anastasiamac, I never felt that golang really helped that much there -- and when they're all internal you tend to just trust yourself to use the symbolic constants and not the magic, rather than adding another whole layer of types and validation methods and so forth
<anastasiamac> fwereade: i agree - internally it may not be as useful (unless u forsee more values coming in the future under the same "group", or the need to be exported, etc)
<anastasiamac> fwereade: feel free to drop the issue :)
<fwereade> anastasiamac, yeah -- I'm hoping those will stay static and internal and forgottenn for many years ;p
<anastasiamac> fwereade: (and just for the record, no I don't trust myself as much u trust urself or I trust u)..
<jam> voidspace: your machine got scared when 50 minutes rolled around :)
<jam> makes me wonder if something like shortWait got set to 50s instead of 50ms or something.
<voidspace> jam: no-one else is seeing the same thing
<voidspace> jam: I have this on trunk
<jam> voidspace: you're sure you don't have any local changes, right?
<voidspace> jam: yep
<voidspace> jam: I'll dig in and see where the slowdown is actually occurring and see if I can work out why
<jam> voidspace: so the only thing *I* would get out of the panic is what test was running, you could use that to see what test is slow
<jam> I generally find golangs 200 tracebacks hard to debug since we use so many goroutines
<voidspace> jam: I know at least one test that takes 9 minutes
<voidspace> jam: yep :-/
<voidspace> jam: so I have somewhere to start
<perrito666> internet over 3g here feels a lot like dial up, I am suddenly invaded by nostalgia... and lag, lots of lag
<katco> wwitzel3: standup
<wwitzel3> katco: yes
<mup> Bug #1465694 opened: TestDiesOnFatalError fails <ci> <test-failure> <juju-core:Incomplete> <juju-core db-log:Fix Committed by menno.smits> <https://launchpad.net/bugs/1465694>
<mup> Bug #1465695 opened: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:New> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695>
<perrito666> first internet goes off and now the lights... I feel like in the prelude of a b movie about catastrophes
<katco> "the first reports came from south america"
<perrito666> katco: well I had cellphone signal and 3g inside my house, that was quite apocalyptic
<katco> maybe the usual electrical interference was gone
<perrito666> fantastic, the power outage reset the ISP box for the block and I am back online
<katco> :)
<voidspace> what's the environment variable for setting logging level during tests (alongside -check.vv) ?
<perrito666> katco: also I live in a suburb mostly populated by families or working age people, I am most likely the only person in 100m around me
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<mgz> gsamfira: are you free to talk windows maas images in 10 mins maybe?
<gsamfira> mgz: sure
<mgz> gsamfira: ace, will invite you in a min
<voidspace> dimitern: how do I enable trace logging for a test run?
<dimitern> voidspace, TEST_LOGGING_CONFIG='<root>=TRACE' go test ...
<dimitern> mgz, ping
<mgz> dimitern: hey
<dimitern> mgz, have a look at this http://paste.ubuntu.com/11725493/
<dimitern> mgz, I believe that test should be dropped entirely
<dimitern> mgz, as it will only work as expected when type==manual and AWS_ACCESS_KEY is in os.environ
<natefinch> btw all, we have a customer on #juju who might have hit #1464304 in a production environment
<mup> Bug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju) <cts> <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1464304>
<natefinch> and so juju has happily uninstalled itself, and he sorta needs juju on that machine, since there are services running there...
<voidspace> dimitern: thanks
<dimitern> natefinch, by "uninstalled" what do you mean? apt? upstart?
<natefinch> dimitern: if you send sigabrt to jujud, it wipes out /var/lib/juju/  I presume it also stops the service
<natefinch> this is a "feature" to help manual provider clean up
<mgz> dimitern: do you mean drop the test, or drop the wrapper with the special case?
<mgz> it's intended to just be an extra safety net after destroy-enviroment
<mgz> the test could easily be fixed by overriding the envvar
<natefinch> perrito666: sounds like the guy mostly needs to recover the apipassword... do you happen to know where we can get that for the machine?
<dimitern> mgz, well, the code this tests checks requires both AWS_ACCESS_KEY in os.environ and config,type==manual, so unless both are set in that and the previous test, it will fail
<mgz> dimitern: yup, not overriding the env is wrong
<perrito666> natefinch: context?
<dimitern> mgz, ok, but if it's overridden the it's almost the same as the previous one (safe for e.g. setting the aws_access_key to '')
<natefinch> perrito666: sorry... guy on #juju had his jujud uninstall itself... he's mostly recovered by copying files from other units, but the agent keeps failing saying it has a bad API password....
<mgz> dimitern: but that's the intention of the test I believe
<natefinch> perrito666: wasn't sure if in your work with restore, you might know a way to hack that.
<mgz> ie, assert d_j_i is not called if the envvar is not set
<perrito666> natefinch: well if he is copying the agent.conf from another unit he will have problems because the tag will not be the right one
<natefinch> perrito666: right.
<perrito666> natefinch: and even then I am not sure he could recover the old password
<perrito666> he might need to do some state server side magic
<natefinch> *nod* he said he's been poking at mongo,, which is scary
<dimitern> mgz, sorry, I'm apparently confused :)
<dimitern> mgz, are you saying this test, as written is expected to fail always?
<perrito666> natefinch: when someone says he has been poking at mongo I just raise my hands like a soccer player after a foul
<mgz> dimitern: no, I'm saying it should make sure the envvar is unset, then it would do what it intends
<natefinch> perrito666: yeah....
<mgz> gsamfira: ready to roll?
<perrito666> but yeah, we lack a way to recover it is an interesting feature though
<gsamfira> mgz: in about 10-15 minutes. Got pulled into another meeting
<gsamfira> mgz: will ping you soon
<mgz> gsamfira: cool, thanks
<perrito666> juju --Iswearthatisaunitjustreaprovisionthenecessaryfiles
<natefinch> perrito666: yeah, I mentioned on bug  #1464304 that we should probably not use a signal as our way of telling jujud to commit seppuku and instead use some really arcane jujud command like `jujud DIEPLEASEDIE -y --yesIreallyMeanIt --deleteAllMyStuffForReal`
<mup> Bug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju) <cts> <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1464304>
<perrito666> natefinch: why on the universe we have a commit seppuku command on the first place?
<natefinch> perrito666: that's how manual provider tells a unit to clean itself up (since it can't just de-provision the machine).
<perrito666> and why does it work in any other provider :p
<natefinch> that was going to be my next point, too
<natefinch> but it shouldn't even work on the manual provider... it's just too easy to do by accident, regardless of what signal we use
<dimitern> mgz, you mean instead of 'AWS_ACCESS_KEY' in os.environ; add something like "and os.environ['AWS_ACCESS_KEY'] != '' ?
<mgz> dimitern: I mean like, patch(os.environ, {})
<voidspace> mgz: patch.dict(os.environ, clear=True)
<mgz> or zat.
<dimitern> mgz, that won't work
<mgz> dimitern: I don't see why not?
<dpb1> natefinch: thanks for the look yesterday.  I'll do more work to narrow down the problem.  If I get it live, can you hop on and take a look?
<gsamfira> mgz: ready
<mgz> gsamfira: jog pasting you hangout link
<dimitern> mgz, hmm, ok, it works, sorry for the noise :)
<mgz> dimitern: :P *hugs*
<dimitern> mgz, I rather like the dummy stack actually - I'm extending how it's deployed so it can be used concurrently in pairs
<mgz> dimitern: neat
<dimitern> mgz, e.g. deploy one pair sink/source in a couple of lxc containers, then deploy another pair in a kvm and on a machine (using different service names ofc)
<natefinch> katco: I've been trying to help MrOJ over on #juju but have to run to pick up my daughter at preschool.  Handing off to perrito666 for now.  But wanted you to know I'd spent some time on it.
<natefinch> ericsnow: you around?
<ericsnow> natefinch: yep
<ericsnow> natefinch: just wrapping up a review on your patch
<natefinch> ericsnow: cool.  We have a user on #juju that evidently had a problem with restoring his state server
<natefinch> ericsnow: or rather, he restored and then the agents on all his machines killed themselves
<natefinch> (on all the non-state-servers)
<ericsnow> natefinch: that sounds familiar
<ericsnow> natefinch: perrito666 fixed (?) something like that recently, I believe
<natefinch> ericsnow: he's on 1.23.3, so pretty recent.
<natefinch> perrito666: was helping out, but had to go run an errand... unfortunately that was before I thought to ask how the guy got in this state
<ericsnow> natefinch: well, 1.23 is the first version with the new restore implementation
<natefinch> well at least that
<ericsnow> natefinch: what info do we have?
<natefinch> he said he had some DNS issues during restore, and restore never finished, so he had to kill it.
<natefinch> I presume he has fixed the DNS issues and reran restore (verifying now)
<ericsnow> natefinch: which provider?
<natefinch> ericsnow: maas
<ericsnow> natefinch: lovely
<natefinch> iknorite?
<natefinch> he updated his state servers to 1.24 before trying restore after fixing DNS
<natefinch> I wonder if ^ was the cause of a problem, since now the agents are on the wrong version
<ericsnow> natefinch: I expect it depends on at what point they canceled the restore
<ericsnow> natefinch: restore really shouldn't impact the agents on other machines (other than to make the API unavailable)
<ericsnow> natefinch: so the fact that those agents died implies to me that something in mongo got corrupted (or there was some API timeout that triggered the grim reaper)
<natefinch> ericsnow: yeah, it seems like a manifestation of the bug where if the agent can't get to the state server, it kills itself. Except that I thought we'd fixed that.
<ericsnow> natefinch: yeah, that's what I was thinking of
<ericsnow> natefinch: it may be that it's not fixed in the version(s) he is running
<natefinch> ericsnow: he's on 1.23.3 ... that's the latest release version.  If it's fixed anywhere, it should be fixed there.
<ericsnow> natefinch: it seems like we haven't been backporting as many (any?) fixes to 1.23 as we have to 1.24
<natefinch> ericsnow: looks like it was fixed in 1.20.1: https://bugs.launchpad.net/juju-core/+bug/1339770
<mup> Bug #1339770: Machines are killed if mongo fails <canonical-is> <landscape> <maas-provider> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Won't Fix> <https://launchpad.net/bugs/1339770>
<ericsnow> natefinch: ah, fixed last year so it should be fixed in 1.23
<natefinch> thank god juju uninstalling itself doesn't also blow away its logs
<perrito666> natefinch: so, we have  logs for the restore issue?
<ericsnow> natefinch: FYI, https://github.com/juju/juju/commit/b4e37a8d31bedb56ce46318779c04387f8333026
<ericsnow> natefinch: from what I can tell, the actual fix is on 1 line: https://github.com/juju/juju/commit/b4e37a8d31bedb56ce46318779c04387f8333026#diff-edccfba67a01587c9faca9185781e5dbR289
<mup> Bug #1465844 opened: juju action-set skips values with underscore in the key <juju-core:New> <https://launchpad.net/bugs/1465844>
<thumper> fwereade_: ping?
<alexisb> thumper, that is wishful thinking at this hour :)
<thumper> alexisb: I know, but sometimes he is around
<fwereade_> thumper, pong
<fwereade_> thumper, how's it going?
<thumper> fwereade_: good,
<thumper> fwereade_: many of the CI failures seem to be jujud/agent tests getting deadlocked
<thumper> I *think* this is lease related...
<thumper> you are fixing this yes?
<fwereade_> goddammit that is not at all unlikely
<thumper> some of this is due to the agent not stopping
<fwereade_> that is one of the features of the current implementation that I intend to do differently yes
<fwereade_> thumper, I might even have a fix for it inn a rotted branch somewhere that I didn't realise I hadn't finished
<thumper> fwereade_: was just poking to see if that could be fixed soonish
<fwereade_> thumper, in the short term the core of it is *similar* to the following (and axw made most recent changes so can verfiy I think)
<wwitzel3> ericsnow: you still around?
<fwereade_> thumper, there's an implicit dependency between the api server and the lease manager; and between the lease manager and state
<mup> Bug #1465694 changed: TestDiesOnFatalError fails <ci> <test-failure> <juju-core db-log:Fix Committed by menno.smits> <https://launchpad.net/bugs/1465694>
<fwereade_> thumper, if you shut them down in the right order (apiserver; lease manager; state) then the tests should be safe
<fwereade_> thumper, but to do that you need to get all the way down to the dummy provider
<thumper> fwereade_: jujud/agent calls a.Stop(nil)
<thumper> i think
<fwereade_> thumper, which is what creates the apiserver and state and shuts them down
<fwereade_> thumper, yeah, I can well believe it
<fwereade_> thumper, what I saw was deadlocks on test shutdown
<fwereade_> thumper, but I didn't have a repro that wasn't tied up with other changes
<fwereade_> thumper, specifically what I saw was that the apiserver had started to respond to a leadership request
<fwereade_> thumper, but the lease manager had been shut down already
<fwereade_> thumper, so the api call was blocking forever and preventing the apiserver from completing
<thumper> fwereade_: this timeout is effecting everyone
<thumper> can we priorities the fixing of it?
<perrito666> sinzui: have a moment to help me not make a fool of myself?
<sinzui> perrito666: I am entering the release meeting. I may be distracted for 15-30 minutes
<fwereade_> thumper, not tonight, but send me a mail about it and I should be able to tomorrow
<thumper> sinzui: can we reduce the 1200s timeout on the bot tests runs to be 600s?
<thumper> sinzui: the longest tests only take about 6 or 7 minutes
<thumper> 10 should be enough
<thumper> 20 means we have an extra 10 minutes to work out that we have a problem
<sinzui> thumper: for the maas bootstrap? If so, I did 60 minutes ago
<thumper> no, just the bot unit tests runs
<sinzui> thumper: oh, unit tests. Yes, I think I can
<sinzui> thumper: all series and arch tests should pass in 600s?
<perrito666> sinzui: I intend to propose a CI test buuut I am not sure how to push both repository and juju-ci-tools for that purpose (and am not sure how private all that should be
<sinzui> thumper: I will get this change commit in the next hour
<sinzui> perrito666: juju-ci-tools is public, nothing will be private if we merge it
<perrito666> good
<thumper> sinzui: I'm not sure about all series and arch
<thumper> sinzui: but amd64, for sure
<sinzui> thumper: ok. I think the 386 allows creater timeouts because we only get under pwered machines. and 386 unit tests donât pass in lxc on a fast machine
<sinzui> perrito666: I see your branch, You can use the âPropose for mergingâ link on https://code.launchpad.net/~hduran-8/juju-ci-tools/add_status_ci_tests and I will review it
<perrito666> sinzui: following up with the "I feel like an idiot" series of questions
<perrito666> how do I push repository?
<perrito666> man, this makes me feel like a toddler trying to operate a nuclear reactor
<sinzui> perrito666: you donât push repos. Lp setup each project with a repo with shared branches. All branches are in one plzce to see, no searching
<perrito666> sinzui: yeah but it is lp:juju-ci-tools/repository that I have no clue how to propose a branch to
<sinzui> perrito666: i see your two branches art https://code.launchpad.net/juju-ci-tools
<perrito666> sinzui: I created my work env by using https://github.com/juju/juju/wiki/ci-tests
<perrito666> which suggests to bzr branch repository inside juju-ci-tools
<sinzui> perrito666: at https://code.launchpad.net/~hduran-8/juju-ci-tools/add_status_ci_tests/+register-merge , âtarget branchâ is lp:juju-ci-tools/repository
<perrito666> sweet, tx (the search says repository is a term too generic :p )
<sinzui> perrito666: It isnât a bzr repo. It is the what we set LOCAL_REPOSITORY to
<sinzui> thumper: 1200 is hardcoded in  jujuâs Makefile. See the âcheckâ target
<thumper> ah...
<thumper> haha
<thumper> we can fix that :)
<perrito666> sinzui: I think I didn't mess up, I totally might have :p
<sinzui> thank you perrito666 I will review this after dinner
<perrito666> sinzui: thank you, there is more incomming, storage is on tha making :p
<asanjar> hi all, has anyone else experiencing bundle deployment from charmstore with broken icon or/and no relations?
<arosales> asanjar, are you seeing it with just the spark bundle or even simple bundles like mysql-wordpress
<arosales> asanjar, also what version of juju
<asanjar> arosales: mainly with big-data related bundles.. spark, hadoop or clouderamanager
<asanjar>  juju --version  1.23.3-trusty-amd64
<asanjar> I can reproduce the problem %90 of times on aws just by executing: juju quickstart u/bigdata-dev/apache-hadoop-spark-zeppelin/1
<arosales> asanjar, does juju quickstart u/jorge/wordpress/5 also fail?
<arosales> in aws?
<asanjar> arosales: have not tried jorge/wordpress .. however it looks like the problem is easier to reproduce with complex and time consuming deployments
<arosales> asanjar, gotcha, just wanted to see how prevalent the problem is
<arosales> asanjar, do you have a bug opened on it?
<mup> Bug #1465873 opened: Environment.Users does not take into consideration the current environment <juju-core:Triaged by waigani> <https://launchpad.net/bugs/1465873>
<asanjar> https://bugs.launchpad.net/juju-core/+bug/1460087
<mup> Bug #1460087: quickstart deployment fails to add relations when bootstrap goes "down" <deploy> <quickstart> <juju-core:Triaged> <https://launchpad.net/bugs/1460087>
<arosales> asanjar, but you are seeing this in AWS now with deploy time taking far less than 3 hours, correct?
<asanjar> oh yes..
<asanjar> this might help>> juju debug-log for the last 30+ minutes http://paste.ubuntu.com/11727687/
<thumper> waigani: hello on call reviewer: http://reviews.vapour.ws/r/1943/
<menn0> thumper: mongodb is weird. i just spent ages figuring out what why there were strange 1s pauses in my oplog using tests, but only when I faked the oplog with my own capped collection.
<menn0> thumper: turns out that if I move the fake oplog out of the "local" DB the pauses go away.
<menn0> thumper: makes the tests heaps faster
<waigani> thumper: done. that's a lot of duplicated factory calls.
<thumper> waigani: ta
<thumper> menn0: weird
<wallyworld> perrito666: did you see the conflict in the mp?
<perrito666> wallyworld: just saw it, when I did the PR it said it needed a moment to generate the diff and therefore I left after my attention span timeouted
<perrito666> wallyworld: so, ill not make comments about the aestethic properties of that conflict display but omg, what a dumb merge tool
<perrito666> I think I need to fix that but I presume ill get a shower of comments from reviewer so I should do all that together
<perrito666> wallyworld: sinzui said he would review it after dinner
<wallyworld> perrito666: bestter to fix conflict first
<menn0> thumper: yeah. at first I thought it was related to the timeout I was using (also 1s) but changing it to other values didn't affect the 1s pauses
<wallyworld> perrito666: as most reviewers prefer no conflicts before looing
<mup> Bug #1456714 changed: assignCleanSuite.TearDownTest fails <ci> <intermittent-failure> <unit-tests> <juju-core:Invalid> <https://launchpad.net/bugs/1456714>
#juju-dev 2015-06-17
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: hey
<fwereade_> right, I had intended to go to sleep rather earlier than this, but hey ho. http://reviews.vapour.ws/r/1934/ now has complete logic tests, and enough docs to be worth poking at; I'm now looking to land it if anyone has the bandwidth for it
 * fwereade_ bed
<davecheney>  mwhudson i have an email from the go pm who's asking for contact details for the go packaging maintainers
<davecheney> i'm tempted to just give him your name
<davecheney> that is, unless you can find someone else for me to foist this on
<mwhudson> davecheney: in ubuntu?  me and doko i guess would be a good start
<davecheney> mwhudson: i guess that is my first question
<davecheney> don't ubuntu follow debian
<davecheney> i wonder if I should send him to the debian folks first
<mwhudson> the debain folks are paultag and tianon
<davecheney> tainon
<davecheney> i think I know him/them
<mwhudson> as usual when being asked a question the first response is "what are you trying to achieve"
<davecheney> jason is a pm
<davecheney> he's used to not getting a straight answer
<mwhudson> ah, i think ian cc:ed him on the mail he sent me earlier today
<davecheney> jason b
<davecheney> yeah, all roads lead back to product managment
<mwhudson> yeah
<wallyworld> thumper: 5 min chat?
<thumper> wallyworld: sure
<davecheney> thumper: https://github.com/juju/testing/pull/71
<davecheney> thumper: i have a problem
<davecheney> lucky(~/src/github.com/juju/juju) % go install -v ./...
<davecheney> ../../../gopkg.in/juju/charm.v5/testing/mockstore.go:18:2: cannot find package "gopkg.in/check.v1" in any of: /home/dfc/go/src/gopkg.in/check.v1 (from $GOROOT) /home/dfc/src/gopkg.in/check.v1 (from $GOPATH)
<davecheney> juju depends ont he charmstore
<davecheney> the charmstore depends on gopkg.in/check.v1
<davecheney> and I believe rog will block any landing into that repo
<thumper> sure...
<thumper> but since we aren't running tests against it, why is it a problem?
<davecheney> i *think* this will be ok
<davecheney> yes, that
<davecheney> but it might also be a blocker
<davecheney> i need to point this out
<thumper> in theory, gocheck should end up being in any non test dependencies right?
<thumper> are we using any *testing packages from the charm package?
<thumper> ...
<thumper> mockstore?
<davecheney> yes
<davecheney> so if that package provides checkers that we're using
 * thumper grunts
<davecheney> we're boned
<davecheney> if it's just using the types
<davecheney> we're probably ok
<thumper> ok
<thumper> let me know
 * thumper goes to make coffee
<davecheney> we might still be ok, i think gocheck uses an interface
<davecheney> or reflection to figure out which of the arguments are checkers
<davecheney> and there is no requirement that a cheker implemetns an interface
<davecheney> or embeds a checker base type
<davecheney> so this might be ok
<davecheney> if a bit ropey
<davecheney> worker/uniter/runner/jujuc/testing/networking.go:23: cannot use checkers.DeepEquals (type "gopkg.in/check.v1".Checker) as type "github.com/juju/check".Checker in argument to c.Check:
<davecheney>         "gopkg.in/check.v1".Checker does not implement "github.com/juju/check".Checker (wrong type for Info method)
<davecheney>                 have Info() *"gopkg.in/check.v1".CheckerInfo
<davecheney>                 want Info() *"github.com/juju/check".CheckerInfo
<davecheney> opps, spoke too soon
<natefinch> ...and that's why you avoid using custom types in interfaces
<davecheney> yup
<davecheney> thumper: nope
<davecheney> i'm screwed
<davecheney> we have a gordian knot between juju/juju, juju/testing and check.v1 and charm.v5
<davecheney> i cannot complete this change unless the charmstore owners agree to also switch to our fork
<natefinch> luckily they work for us, so that should not be that hard?  Maybe?
<davecheney> thumper: i'm shelving this card, I cannot complete it at thsi time
<thumper> davecheney: ack
<thumper> man...
<thumper> that seems screwed up
<davecheney> thumper: what do you want to do ?
<thumper> davecheney: I'm unclear as to why the checker is using gopkg.in checker...
<davecheney> its a suite
<davecheney> check/v.5 uses suites from juju/testing
<davecheney> juju/testing expects a "github.com/juju/check".Checker, this is a gc.C
<davecheney> check.v5 suites expects a "gopkg.in/check.v1".Checker gc.c
<davecheney> check.v5 suites expects a "gopkg.in/check.v1".Checker gc.
<davecheney> C
<davecheney> hmm, that wasn't quite right
<davecheney> some of the names of the gocheck types aren't right in that explanation
<davecheney> but the effect is the same
<natefinch> because charm.v5 uses gopkg.in/check.v1 and everything else uses github.com/juju/check  ... .and the interfaces aren't compatible because they contain package-specific types.
<wallyworld> waigani: do you gave time for a chat about simplestreams branch?
<waigani> wallyworld: yep sure
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<thumper> davecheney: ah poo
<thumper> davecheney, natefinch: can we change juju/check to not expect package specific types?
<thumper> however
<davecheney> natefinch: is gc.C a type or an internface
<thumper> that'll only work for checkers
<davecheney> thumper: the problem is suites
<thumper> not the C
<thumper> right?
<thumper> yeah
 * thumper gets it
<davecheney> well, there are several problems
<thumper> as frustrating as it is
<thumper> even if we could fix juju/check
<davecheney> charm.v5 is using check.v1 as it's definition of gc.C passed to suites
<davecheney> and juiju/testing is using our fork
<thumper> with the charms.v5 using gopkg.in, it means it can't use us
 * thumper nods
<thumper> double poo
<davecheney> TL;DR, everyone has to upgrade
<thumper> this is go types done wrong IMO
<thumper> davecheney: I think the fastest way to progress would be to provide the upstream gocheck with the exact patch we want
<thumper> and apply pressure to get it in
<davecheney> i agree
<thumper> did that other Chris fella respond to the PR comment?
<thumper> an aside should be for us to learn from this when designing bits of code
<davecheney> nope
<davecheney> thumper: i agree
<davecheney> but there is no value in having that conversation on IRC
<davecheney> it will be lost
<davecheney> please take it to the juju-dev mailing list
<thumper> can you propose a PR to gocheck upstream that has the fix we need, based on the work Chris did?
<thumper> davecheney: ?
<davecheney> yes, on it
<thumper> cheers
<waigani> anastasiamac: I started reviewing your branch but need to run sorry, I've added a few comments, will continue later if it's still up.
<davecheney> thumper: oh, THATS's right
<davecheney> the gocheck tests dont pass
<davecheney> i forgot that
<davecheney> oh well
<davecheney> fuck it
<thumper> WT actual F?
<davecheney> yeah, i logged that bug a year or so ago
<davecheney> alst time I made a fix to a checker
<davecheney> well, maybe i logged a bug
<thumper> wallyworld: http://reviews.vapour.ws/r/1948/
<thumper> wallyworld: sorry
<wallyworld> looking
<thumper> was after waigani
<thumper> but he isn't here
<thumper> w-TAB
<thumper> fail
<thumper> wallyworld: I can get someone else that is more familar with the code if you like
<wallyworld> thumper: maybe that's better?
<wallyworld> i 'm about to go do school pickup
<thumper> wallyworld: sure, np
<davecheney> git push --set-upstream origin fix-data-race-on-status
<davecheney> fatal: https://gopkg.in/check.v1/info/refs not valid: is this a git repository?
<davecheney> reason 2^63 why I don't like gopkg.in
<davecheney> "oh,you downloaded this repo, but I'm not going to tell you where origin _really_ is"
<davecheney> thumper: https://github.com/go-check/check/pull/44
<thumper> davecheney: thanks
<davecheney> confirmed the race in worker/provisioner is fixed
<thumper> awesome
<thumper> laters peeps
<wallyworld> axw: if you have 15 minutes, would love a small review for a 1.24.1 bug fix http://reviews.vapour.ws/r/1947/
<axw> wallyworld: looking
<wallyworld> ty
<axw> wallyworld: when is a unit in "maintenance"? that's when the machine is being provisioned?
<wallyworld> axw: Unknown during allocation
<wallyworld> maintenance during install hook
<wallyworld> door, be back in a sec
<dimitern> wallyworld, hey
<dimitern> wallyworld, re bug 1464616 we talked about yesterday
<mup> Bug #1464616: destroy-machine --force no longer forceably destroys machine <destroy-machine> <regression> <juju-core:Triaged> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1464616>
<wallyworld> dimitern: http://reviews.vapour.ws/r/1947/
<dimitern> wallyworld, I couldn't figure out what might be the issue without logs, but it seems you've got it
<wallyworld> axw is looking
<wallyworld> yeah :-)
<dimitern> wallyworld, awesome :)
<wallyworld> axw: part of the complicating factor now is that we need to look at both agent and unit status to see what's going on. before it was all just unit status
 * axw nods
<dimitern> wallyworld, reviewed
<wallyworld> ty
<wallyworld> axw: with the "...OrError" - it would be an error whn running the install hook, so you could argue it's still installing, hence i left it off the name. is that ok, or wuld you prefer the name change?
 * dimitern is itching to write some usable docs around the various CI python classes / tools
<axw> wallyworld: it could also be in error unrelated to installing
<axw> wallyworld: so not really
<wallyworld> could be but the other checks imit it to installing
<wallyworld> i'll change the name
<axw> wallyworld: the other asserts do, but that means you have to know about the asserts together in context
<wallyworld> that is true
<axw> wallyworld: completely unrelated: I changed tack on volume destruction a bit. I undid what I was talking about in the standup, and have simplified the worker so it just destroys volumes/filesystems when they're Dead. then in state we'll mark a volume/filesystem as Dead when it has no more dependents
<axw> so the worker no longer has to track dependencies
<wallyworld> simplicity is nice
<wallyworld> sounds better
<dimitern> wallyworld, axw, can a subordinate have actions of its own?
<dimitern> fwereade_, ^^
<wallyworld> not sure tbh
<dimitern> I'm thinking of creating a simple subordinate charm that has actions returning various networking settings - iptables, routes, etc.
<axw> dimitern: sorry no idea
<dimitern> no worries, will rtfm :)
<wallyworld> dimitern: i don't understand the code review comment about "ErrAborted handling below"
<dimitern> wallyworld, well, any txn.Op with an Assert can trigger ErrAborted
<wallyworld> sure. which one are you referring to?
<dimitern> the unitAgentAllocatingOrInstalling
<wallyworld> that's the Assert, sorry i mean which ErrAborted handler?
 * dimitern actually looks at the full source of that method
<wallyworld> it's all takne care of AFAIK. the txn will just be retried as normal
<wallyworld> either the unit was not installed or it was when the txn was started
<wallyworld> it's called from line 289 func (u *Unit) Destroy() (err error)
<dimitern> wallyworld, yeah, I can't see anything wrong with it off hand, but I'd recommend fwereade_ having a look
<wallyworld> ta
 * dimitern now really likes the idea of multi-series charms in the face of cross-series CI tests
<dimitern> jw4, are you around by any chance?
<wallyworld> jam: i've reworked the resource document a fair bit. the resource-path is i think improved as is the CLI. rick is tied up fixing their production issue, but i've answered is questions and posed a few of my own in new comments.  when we are satisfied that the doc is "good enough" to show more people i'll link into the main spec. note that it's not complete, but the aim is for a WIP with enough defined to allow development to start
<dimitern> voidspace, jam, fwereade_, standup?
<voidspace> dimitern: omw
<mup> Bug #1466011 opened: apiserver tests fail on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1466011>
<fwereade_> wallyworld, I'm afraid http://reviews.vapour.ws/r/1947/ does not lgtm, does my comment make sense?
<fwereade_> wallyworld, I think you probably want to look at (*State).obliterateUnit
<dooferlad> voidspace: success?
<lazyPower> omg i think i'm going to cry... i had a trapped upgrade charm pending after i wrote an entire refactor of a hook (~ 250 lines) .. just to have it wiped out by upgrade-charm ;_;
<voidspace> dooferlad: nope
<fwereade_> lazyPower, owww :(
<voidspace> dooferlad: using dhcp seems to overwrite the dns-nameservers option
<voidspace> dooferlad: using static (with the correct values) just plain doesn't work
<lazyPower> fwereade_: that awkward moment i wish we were still git based so i could have recovered
<voidspace> dooferlad: I suspect it's a bad interaction with the bridging config for br0
<fwereade_> lazyPower, haha :(
<fwereade_> lazyPower, you *should* be able to stop a pending upgrade that hasn't started yet by upgrading back to the original
<dooferlad> voidspace: do you actually need br0?
<lazyPower> fwereade_: my changes were remote, not local. so i had no backup and forgot i sent the upgrade-charm like an hour prior.
<lazyPower> exited the hook thinking "Yes, now i can sync back"
<lazyPower> doh
<fwereade_> lazyPower, bad luck :(
<lazyPower> indeed
<voidspace> dooferlad: I'll try getting rid of it and see what breaks :-)
<dooferlad> voidspace: ahh, fun with networking :-)
<lazyPower> it was too late, by the time upgrade_charm was trapped in tmux, i knew i was taking a stroll through "trololol" land
<voidspace> dooferlad: apparently I do need it
<voidspace> dooferlad: without it, no network
<voidspace> dooferlad: I'll dig into where it comes from
<voidspace> dooferlad: statically configuring br0 doesn't work - it has a bunch of bridge options set
<voidspace> dooferlad: http://pastebin.ubuntu.com/11729739/
<voidspace> dooferlad: it's to do with kvm (br0)
<voidspace> dooferlad: docs here imply I ought to be able to statically configure
<voidspace> https://help.ubuntu.com/community/KVM/Networking
<voidspace> dooferlad: I was missing gateway before which is why I think statically configuring br0 didn't work
<dooferlad> voidspace: oh, yes, you will need that!
<dimitern> dooferlad, you've got a review; btw add an Overhead card for it please
<voidspace> dooferlad: but dns-nameservers seems to be ignored now
<dooferlad> dimitern: thanks, already acting on it
<dooferlad> dimitern: overhead card?
<dimitern> dooferlad, for that PR
<dooferlad> dimitern: don't all PRs go through review though?
<dimitern> dooferlad, i'd like to track all PRs that land with cards
<dimitern> dooferlad, yes, indeed
<dimitern> dooferlad, we're doing a lot of overhead tasks and a few actually planned, so I'd like to keep track of this
<voidspace> dooferlad: it seems like I need to have the dns-nameservers section in eth0 not in br0
<dooferlad> voidspace: oh, interesting!
<voidspace> dig now reports the correct nameserver
<voidspace> doesn't *seem* to have improved connection speed
<voidspace> I'll try running the tests though
<dooferlad> if you "dig nanosheep.org" or some other server you haven't looked at recently, does it take long?
<dooferlad> voidspace: ^^
<voidspace> dooferlad: that returned quickly enough
<voidspace> I think this means that dns isn't the issue
<dooferlad> voidspace: is quickly sub 200ms? From 127.0.0.1? If so, yea, that looks fine.
<voidspace> dooferlad: hmm... 599ms
<voidspace> cmd/juju tests are no quicker
<dooferlad> voidspace: http://paste.ubuntu.com/11729870/
<voidspace> :-/
<dooferlad> voidspace: ping response time from an upstream DNS server?
<voidspace> dooferlad: for lots of other sites I'm getting really quick responses
<dooferlad> voidspace: it has to be a site you haven't looked up or you will get a cached response
<voidspace> dooferlad: cached ones return in 0ms :-)
<dooferlad> voidspace: I get 1ms cached responses
<voidspace> dooferlad: response times for other domains really vary
<dooferlad> voidspace: could just be a one-off slow response
<voidspace> yeah
<dooferlad> OK, other stuff. Do other machines on your network have the same slow browsing problem?
<voidspace> no
<dooferlad> anything unusual about that machines network connection? Could you try another cable/
<dooferlad> ?
<voidspace> the connection speed is fine
<voidspace> and that wouldn't affect locally running tests
<dooferlad> indeed
<voidspace> it's not slow browsing, it's slow initial connection
<voidspace> (which really sounds like dns but I'm fairly sure isn't now)
<voidspace> and that particular problem started after we changed iptables
<voidspace> I might try removing those rules to see if it changes again
<dooferlad> sounds like a plan
<voidspace> I don't *know* that cmd/juju got slow then, it may just be a coincidence
<voidspace> so removing them and trying again will let me know
<voidspace> I might go back to some real work for a bit first
<dooferlad> removing those iptables rules is kind of trivial though - just comment them out of the saved rules file and restore the rules from it
<dooferlad> dimitern: review responded to.
<dimitern> dooferlad, cheers, looking
<dimitern> dooferlad, let's drop the second failing StopsInstances() call from that test then
<dooferlad> dimitern: we already test StopInstances, I was just seeing if there was anything interesting that would come up around doing it twice. The entire test is pointless if we drop the second call.
<dimitern> dooferlad, it would be good to figure out why it's reporting some PathError, when it should return something like "no such container" etc.
<dooferlad> dimitern: that is because the first thing it does is try to delete some files and directories, then it calls lxc-destroy
<dooferlad> dimitern: so the first error it returns it just what comes back from those delete calls
<dimitern> dooferlad, right, that's seems wrong
<dooferlad> dimitern: calling lxc-destroy first would seem sane to me, then tidying up.
<dimitern> dooferlad, yeah, let's go back to this at some point
<dooferlad> dimitern: on the 1.24 branch, I was using AssertFileContains rather than AssertFileContains because I figured having both functions was probably overkill.
<dooferlad> dimitern: was going to ask about removing AssertFileContains
<dooferlad> dimitern: happy to keep both and use them though. AssertFileContains does seem to be the most common use case, so having a convenience function seems OK.
<dimitern> dooferlad, I like the more generic AssertFileContents, but since asserts with jc.Contains on files are fairly common, having a simple wrapper around the more generic assert is nice
<fwereade_> waigani, axw: you're both online, and have contributed to state/collections.go; can either of you ballpark estimate the hassle of extracting it (and multiEnvRunner ...and whatever else has to come with it) into its own state subpackage, so I can make use of it from another state subpackage?
<fwereade_> waigani, axw: my gut feeling is "difficult"?
<fwereade_> jam, sorry, 5 mins
<jam> fwereade_: k
<jam> alexisb isn't here yet either
<waigani> fwereade_: actually I don't think it would be that bad
<waigani> fwereade_: menno and I worked on it originally when we migrated the collections to multi envs
<waigani> menno wrote the original collections.go and would be most familiar with it
<fwereade_> waigani, yeah, I ask because you're online ;p
<waigani> but off the top of my head, I can't think of any "got yas". state/txn.go would have to import the subpackage but that should be fine
<waigani> fwereade_: I can bring it up in the standup - 9hrs from now. I'd be happy to look at extracting it - but it'll depend on tim and priorities etc
<jw4> dimitern: probably too late, but you pinged?
<dimitern> jw4, no worries; I had some questions re actions, but I figured it out from the docs :)
<jw4> dimitern: cool
<TheMue> dimitern: could you paste a rough outline how you would use the remover with IP addresses? it's no entity, so would you implement an EntityFinder taking a tag but looking for the IPAddress by id?
<TheMue> dimitern: even if it's a nice component for entities it's more code than the direct implementation
<dimitern> TheMue, that's a good question
<TheMue> dimitern: or alternatively make the IPAddress to a valid entity too (with adding an according kind to juju/names).
<dimitern> TheMue, which reminds me we don't have tags for addresses
<TheMue> dimitern: reading a bit of remover code and how it works on entities it's really a nice mixin
<TheMue> dimitern: exactly
<dimitern> TheMue, let's do this - propose a juju/names PR that introduces IPAddressTag
<dimitern> TheMue, this should be a separate, overhead card btw
<dimitern> TheMue, tags need a kind (used as prefix), let's use "ip-<value>"
<TheMue> dimitern: btw, one little aspect of mixins is that you inherit fields and methods you don't directly aware of, a bit like OOP. here composition and explicit method passing Foo() { my.plug.Foo() } would be better (long term)
<TheMue> dimitern: OK, will add the tag as quick one and add it with a second PR to the remover
<dimitern> TheMue, that's true, but if the embeddable type is intended to be embedded, this shouldn't be a problem (fields/methods "creeping in" unobserved :)
<dimitern> TheMue, yeah, it's easy to do the juju/names PR first
<TheMue> dimitern: it's more an effect of visibility
 * TheMue loves DVCSes for simple switching between branches
<dimitern> TheMue, hmm.. but I can see a problem with address tags
<dimitern> TheMue, just the value won't be enough to make a transformation from network.Address to names.AddressTag and back (e.g. in the case Scope was set to something else, rather than "discovered" automatically from the value)
<dimitern> fwereade_, ping
<fwereade_> dimitern, pong
<TheMue> dimitern: ic
<dimitern> fwereade_, hey, so it's high time to introduce tags for ip addresses
<TheMue> dimitern: could we by this way find a better name than just "value"?
<dimitern> fwereade_, but since it's a struct, just using the Value is not loseless wrt transforming from tag to address
<TheMue> dimitern: could we by this way find a better name than just "value"?
<TheMue> ouch, twice
<dimitern> TheMue, yeah, I'm thinking of "ip-<type>-<scope>-<network>-<value>"
<dimitern> fwereade_, ^^ ? or perhaps "<type-kind>-<scope>-<network>-<value>" e.g. ipv4-public-juju-private-10.3.2.1
<TheMue> dimitern: value is the address itself in standard notation, isn't it?
<dimitern> TheMue, yeah, but it also holds extra metadata about its scope, type, and network
<dimitern> it can even be a hostname
<fwereade_> dimitern, that feels wrong
<fwereade_> dimitern, having all that jammed into a tag
<dimitern> fwereade_, the unique _id for ipaddressesC is DocID, which can be used in a tag, but it'll contain the envuuid
<TheMue> dimitern: the field value, the rest has extra fields, is only the address/hostname. hmm, sadly don't have a better name than "value" :/
<fwereade_> dimitern, all that metadata is, well, metadata
<dooferlad> dimitern: I have a ship it on http://reviews.vapour.ws/r/1941/ but not the original code on trunk (http://reviews.vapour.ws/r/1936/). Could you press the magic button?
<dimitern> fwereade_, we *could* go only with the value in the tab, *but* this won't work if you're trying to serialize e.g. "public:10.0.3.1" as "ip-10.0.3.1", as on the reverse path with network.NewAddress(tag.Id()) the scope will be "guessed" as local-cloud not public
<fwereade_> dimitern, right
<dimitern> dooferlad, looking
<dimitern> fwereade_, or "ip-localhost" for that matter looks weird
<fwereade_> dimitern, so the reason to jam all that into the tag is for uniqueness?
<dimitern> fwereade_, use a single tag type and multiple sub-kinds? "ip<kind>-<value>" ? e.g. "iphostname-localhost" or (iphost-?) "ipv4-10.0.3.1", "ipv6-2001:db8::1"
<fwereade_> dimitern, if those bits are all immutable per address (which I imagine they are), how about `address-<sha256-of-immutable-attributes>`?
<TheMue> that feels strange
<dimitern> fwereade_, not for uniqueness, as the value + envuuid is the _id, so it's unique, but for better carrying out the original intent
<dimitern> fwereade_, hmm we need to know what to hash back on FindEntity though
<jam> dimitern: I think fwereade's idea is that what you really want is a document with a lot of data in it, and not have to shove all of that information into the tag
<jam> what about "ip-<RANDOM>" and then that just gives you what doc you have?
<fwereade_> dimitern, well, you store the hash in the doc and look up by that, right?
<fwereade_> jam, indeed
 * jam disappears to go shopping
<dimitern> fwereade_, just for the sake of having a sha256 hash in the tags?
<fwereade_> dimitern, more for the sake of not jamming a whole struct into a field
<TheMue> so we could take a meaningless but unique uuid too
<dimitern> fwereade_, hmm
<fwereade_> TheMue, indeed, equally
<fwereade_> dimitern, opaque identifiers are good things
<dimitern> fwereade_, I'd rather hash the DocID and use that - it's already in the doc and can be found
<fwereade_> dimitern, sure, that sounds fine too
<TheMue> +1
<dimitern> fwereade_, address-<sha256(_id)>
<waigani> wallyworld: ignoring unknown tools metadata: http://reviews.vapour.ws/r/1955/
<TheMue> dimitern: address-<docID>
<fwereade_> dimitern, that sgtm, you'll still have to store the hashed docid to look it up :)
<mup> Bug #1465695 changed: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695>
<TheMue> or event better ipaddress-<docID>, ipaddress represents the real type (if we have other addresses in the future, like mac-address), docID is already in the document
<dimitern> fwereade_, yeah, or perhaps Find all for the current env and iterate? :)
<TheMue> and docID is unique
<dimitern> TheMue, it's not just an ip address, as it can be a hostname
<dimitern> fwereade_, why not use the docId unhashed indeed?
<TheMue> dimitern: we talk about a tag identifying a type, and the typename is IPAddress. otherwise we should rename the type too *iiirks*
<dimitern> dooferlad, ship it :)
<dooferlad> dimitern: click!
<TheMue> dimitern: that's why I would take ipaddress-<docID>
<dimitern> TheMue, I agree the name can be better, but let's not change everything at once :)
<TheMue> dimitern: and other address types later, mac addresses, addresses for bills, whatever, can use their type as part of the tag
<TheMue> dimitern: no no, I don't want to change it, only want to have it in the tag
<TheMue> dimitern: so it's 1:1
<dimitern> fwereade_, with the "address-<docID>" format we'll have tags like "address-fedcba98-7654-4321-ba98-76543210beef:10.0.3.1"
<TheMue> dimitern: you surely wanted to write "ipaddress-<docID>" *scnr*
<dimitern> fwereade_, or, maybe even better to just use the value and rely on the magical append of "envuuid:" that happens in state/collections.go for a naked FindId()
<dimitern> TheMue, I don't mind *that* much
<dimitern> :)
<TheMue> hehe
 * dimitern reads back what he've written earlier *facepalm*
<fwereade_> dimitern, the only *really* important thing about a tag is that it be unique within an environment
<dimitern> we don't need to care for tag-to-ip conversion based on the format of the tag at all
<mup> Bug #1465695 opened: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695>
<dimitern> fwereade_, yes, but none of the tags (except the environment tags obviously) carry the envuuid prefix that make them unique
<fwereade_> dimitern, yeah: sometimes that's a convenient feature, but I think the only thing that really really depends on info encoded in ids is the watcher logic in state
<fwereade_> dimitern, I think it's fine for a tag to be unique only within the scope of a given environment
<dimitern> fwereade_, yeah, they report local ids
<dimitern> not docIDs
<dimitern> TheMue, fwereade_, ok, as I need to go out for a while, can we agree on "ipaddress-<value>" for the tag format and live with it?
<TheMue> dimitern: so in our case it would be "ipaddress-<value>"?
<TheMue> h5
<dimitern> yeah
<fwereade_> dimitern, can we really guarantee uniqueness per environment there?
<fwereade_> dimitern, it's causing my "changes stakeholders will ask for" spidey sense to tingle
<TheMue> hmm, in an env with multiple subnets sharing the same addresses? possible?
<fwereade_> TheMue, I think it's *currently* specced that subnets can't overlap
<dimitern> fwereade_, yes we can as you can only use such tags once you've logged into a given environment
<fwereade_> TheMue, dimitern: I just feel like that's an unreasonable restriction in a complex network environment
<dimitern> fwereade_, we're only talking about how to access ipaddress entities we already have in the db for the current env
<fwereade_> TheMue, dimitern: why can't isolated subnets use overlapping ranges?
<TheMue> fwereade_: but can an environment have multiple disjunct subnets, having the same address range
<dimitern> fwereade_, isolated like in a separate space?
<fwereade_> dimitern, yes
<dimitern> fwereade_, TheMue, subnet CIDRs for a given space should NOT overlap
<fwereade_> dimitern, I know that juju will refuse to allow it
<dooferlad> as soon as you get >1 network associated with a machine you can get up to all sorts of fun.
<TheMue> dimitern: should or must?
<dimitern> fwereade_, TheMue, that's the whole point of the subnets being equal within a space
<fwereade_> dimitern, within a single space, yes, you don't want subnets to overlap
<dimitern> TheMue, fair enough - it must not overlap
<TheMue> dimitern: ok, so we ensure that we can have multiple subnets but even then each IP is only used once
<dimitern> fwereade_, the case you're describing sounds like having a machine in two separate, disjoint spaces
<fwereade_> dimitern, but if you're modelling two spaces, that are completely distinct, and happen to use overlapping ranges, juju will fail
<mup> Bug #1465695 changed: StorageAddSuite setup fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1465695>
<TheMue> dimitern: so in this case using the address value as part of the tag seems to be fine
<mup> Bug #1466087 opened: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087>
<fwereade_> dimitern, right?
<dimitern> fwereade_, now it won't as that's not yet enforced, but I think it should anyway
<fwereade_> dimitern, you're saying that any organisation that has more than one network using 10.0. is Doing It Wrong? ;p
<dimitern> fwereade_, the problem is with a given machine's single routing table overlapping ranges will lead to issues with routing
<fwereade_> dimitern, I don't care about machines
<fwereade_> dimitern, I care about tags being unique
<TheMue> *lol*
<dimitern> fwereade_, you can't have a machine with 2 NICs, each on the same overlapping (even not completely) rfc1918 subnets and expect it to work without extra care (static routes, metrics, etc.)
<mup> Bug #1466087 changed: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087>
<dimitern> fwereade_, right, what I'm proposing is not worse that what we have already in the face of multiple envs in the same state db
<TheMue> dimitern: two machines, one nic each, one ip each, each in a different subnet in the same env, both having the same IP. possible?
<fwereade_> TheMue, thank you :)
<dimitern> fwereade_, machine tags (or others) are only unique within their env
<fwereade_> dimitern, I know
<fwereade_> dimitern, I'm saying address tags should too
<fwereade_> dimitern, you seem to either be saying that they shouldn't, or that there are whole classes of networks we shoould refuse to model because it's a bit inconvenient re tag format
<dimitern> I don't believe we should model all possible cases like this
<dimitern> what's the use of having enclaves of machines like that in the same env?
<dooferlad> dimitern, fwereade_, TheMue: https://docs.google.com/a/canonical.com/drawings/d/1UAZEYOi1LcBgDyokAdlJAFQuDxpOL98DeHpFT-q1HbU/edit?usp=sharing
<dooferlad> I think this is easier with diagrams!
<fwereade_> dooferlad, good diagram, thank you
<TheMue> dimitern: one enclave for one business service backend, one for another, and a public one as a frontend and routing between them (naive idea)
<dimitern> dooferlad, great, thanks
<fwereade_> dimitern, I reject the notion that we should bake the impossibility of encoding that topology into juju forever
<fwereade_> dimitern, not doig it today is one thinng
 * dimitern needs to think about this
<fwereade_> dimitern, picking a tag format that renders it really damn hard to fix is another
<TheMue> dooferlad: yeah, good one
<dimitern> fwereade_, I totally get your point and agree the described scenario is not well modeled with what i'm suggesting
<fwereade_> dimitern, "address-<space>-<value>" might address my concerns but I'm still a bit iffy there too
<dimitern> fwereade_, but I seem to recall in the model somewhere we said we won't allow that
<fwereade_> dimitern, yeah
<fwereade_> dimitern, I agree that it's fine not to do that yet
<TheMue> fwereade_: dimitern: we always used meaningless IDs, like UUIDs, to make a record unique while the rest of the data can be double. if that's not wanted additional constraints help.
<fwereade_> dimitern, but picking a tag format that makes it harder to do in the future is a decision that's harder to undo than just "let's not do it this week/cycle/year"
<TheMue> fwereade_: to the ID of an IP address simply should be a UUID, the tag "ipaddress-<id>"
<dimitern> fwereade_, agreed
<fwereade_> TheMue, yeah, I'm totally comfortable with (not to mention keen on) opaque primary keys
<TheMue> fwereade_: dimitern: so it doesn't care how we model networks and it is still identifyable
<dimitern> fwereade_, TheMue, let's go with "ipaddress-<space>-<value>" the "space" part can be safely hardcoded to "default" I think
<dimitern> at least initially
<mup> Bug #1466087 opened: TestAllInstances fails <ci> <test-failure> <juju-core:Incomplete> <juju-core devices-api-maas:Triaged> <https://launchpad.net/bugs/1466087>
<natefinch> I don't know what we're talking about, but I'm always +1 on UUID for primary IDs over some concatenated mess.
<dimitern> dooferlad, have a look at http://reports.vapour.ws/releases/2784/job/run-unit-tests-precise-amd64/attempt/2970 btw - it seems devices-api-maas needs your fixes too
<fwereade_> dimitern, yeah, I think we do need a bit more justification for address-<space>-<value>
<fwereade_> dimitern, what are the advantages over address<opaque>?
<dimitern> fwereade_, 1) a lot easier to implement, 2) more readable, 3) just as unique .. come to mind
<TheMue> fwereade_: IMHO only better human readable, but that's all
<TheMue> dimitern: why easier to implement?
<dimitern> TheMue, also much easier to follow in the logs when debugging
<natefinch> if you have to read IDs, you're doing something wrong
<TheMue> hehe
<fwereade_> natefinch, +1
<TheMue> dimitern: I would log myAddress.String() giving a good readable string representation of my address
<dimitern> TheMue, because what fwereade_ is suggesting means 1) add the hashed compound id to ipaddressesDoc, 2) make sure we set and update it as needed, 3) upgrade step to set it on existing ipaddressDocs
<dimitern> I'm very good at following logs like that and figuring out what happened :P
<TheMue> dimitern: sure, we act on existing data.
<dimitern> and almost forgot - 4) a lot shorted in 90% of the cases for both IPv4  and IPv6 values
<dimitern> shorter
 * dimitern really needs to go now, might be back later
 * TheMue has to think about it too, but still feels a bit better with UUIDs
<fwereade_> dimitern, you don't *have* to use a uuid, remember
<fwereade_> dimitern, other formats can be both unique and opaque
<mup> Bug #1466100 opened: TestManageEnvironServesAPI fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core db-log:Triaged> <https://launchpad.net/bugs/1466100>
<TheMue> fwereade_: and even in full printed form (not as [16]byte) a UUID has 36 bytes. need a lot of addresses then to make a database sweat.
 * TheMue is afk to swap location, bbiab
<fwereade_> TheMue, indeed, "uuids are too big" is not generally an argument that impresses me much :)
<alexisb> dooferlad, I will be a few minutes late
<alexisb> but I will be there
<natefinch> dpb1: we can't repro your bug https://bugs.launchpad.net/juju-core/+bug/1465307 have you found a way to reproduce it?
<mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>
<dpb1> natefinch: sorry, I worked on it in the afternoon that day and I got close but not there.  I'm being pulled on something else.  I'll circle back as soon as I can.  For now, I totally understand the "incomplete" status on there.  thanks.
<natefinch> dpb1: cool, just wanted to make sure we were on the same page.
<natefinch> ericsnow: I was wrong about that rsyslog bug, I do understand why it happened, though not precisely the best way to fix it
<ericsnow> natefinch: k
<natefinch> ericsnow: it was my fault - I changed where the rsysog certificate is (as stated by Menno in the comments of the bug).
<ericsnow> natefinch: is it the way menn0 described it
<natefinch> yep
<ericsnow> natefinch: k
<ericsnow> natefinch: I'll look into the fix
<katco> natefinch: moving card for bug 1465307 to "DONE"
<mup> Bug #1465307: 1.24.0: Lots of "agent is lost, sorry!" messages <blocker> <landscape> <regression> <juju-core:Incomplete> <https://launchpad.net/bugs/1465307>
<natefinch> katco: huzzah
<katco> natefinch: ty for following up
<natefinch> katco: can you bring up the "process for proposing a new repo in github.com/juju/" in the leads meeting tonight?  I'm hoping we can just post the process on a page on the wiki.
<katco> natefinch: sure thing
<natefinch> katco: thanks
<katco> gsamfira: hey, were you looking at bug 1464470?
<mup> Bug #1464470: A subordinate charm hook scheduled to run(but waiting for the principal charm hook to release the lock) goes to an error state after the principal charm hook triggers a reboot. <1.24> <1.25> <hooks> <juju> <reboot> <regression> <subordinate> <windows> <juju-core:Triaged> <juju-core
<mup> 1.24:Triaged> <https://launchpad.net/bugs/1464470>
<ericsnow> natefinch: do you have the revision of the change you made for the location of the certificate?
<natefinch> ericsnow: I can find it
<ericsnow> natefinch: thanks
<natefinch> ericsnow: https://github.com/juju/juju/commit/3a6ebe0b6a24a8c5f80a7dbcb78937755540839e
<jw4> ericsnow: were you thinking github PR or reviewboard link?
<ericsnow> jw4: either is fine, though I think putting the RB link also more clearly sends the message that the patch was reviewed :)
<jw4> ericsnow: cool :)
<natefinch> ericsnow: got a minute to talk about the plugin package?
<ericsnow> natefinch: sure
<ericsnow> natefinch: moonstone?
<natefinch> ericsnow: ya
<voidspace> dimitern: ping
<voidspace> dimitern: currently, the network interface information returned by PrepareContainerInterfaceInfo populates MACAddress with the NIC of the interface it allocated the address on
<voidspace> dimitern: i.e. the host NIC MAC
<voidspace> dimitern: so my change is a semantic change here.
<voidspace> dimitern: as the method is documented to return "information for configuring networking on a container" I think that's ok
<voidspace> dimitern: we always overwrite the MAC address anyway
<voidspace> dimitern: but it might be slightly surprising to someone reading the code
<dooferlad> TheMue/voidspace: could you take a quick look at this fix: https://github.com/dooferlad/juju/commit/aeb9acf964cbdb04abd957f49e2303a65cc5d240
<dooferlad> The rest of the change (http://reviews.vapour.ws/r/1941) has got a ship-it, but this caused the test bot to fail
<voidspace> dooferlad: looking
<voidspace> dooferlad: what was the failure?
<dooferlad> The test is looking for a particular config change. The problem is the initial set up can generate a change on the channel it is watching.
<voidspace> dooferlad: is this because the code is running in a goroutine and you don't want to use an assert?
<dooferlad> no, an assert would be fine
<voidspace> ah ok
<voidspace> dooferlad: but you need to repeat the read on cfgObserver
<voidspace> dooferlad: looks good to me
<dooferlad> voidspace: yea, just need to keep reading cfgObserver until the expected change arrives, or time out.
<voidspace> yep, LGTM
<dooferlad> voidspace: thanks. Will push the go button again.
<dooferlad> voidspace: and port to trunk.
<dooferlad> voidspace: could you take a look at that same change, just this time is is a review for trunk. No changes vs the other branch.
<dooferlad> http://reviews.vapour.ws/r/1958/
<dooferlad> TheMue: since voidspace is offline, could you take a look ^^
<voidspace> dooferlad: LGTM
<dooferlad> voidspace: how I love IRC clients. You are apparently both offline and online.
<dooferlad> voidspace: once that lands you probably want the changes in devices-api-maas. Hopefully it will result in less $$stupidtests$$
<dooferlad> voidspace: yell if you want a hand
<voidspace> dooferlad: cool, thanks
<voidspace> dooferlad: heh, my IP address changed just at that instance
<voidspace> dooferlad: so I was briefly offline and reconnected
<mup> Bug #1466152 opened: [RFE] log locks and other relevant information when jujud receives SIGUSR1 <juju-core:New> <https://launchpad.net/bugs/1466152>
<rogpeppe1> natefinch: just took a look at deputy. nice idea. you should probably document that Timeout isn't compatible with StdoutPipe or StdinPipe
<natefinch> rogpeppe1: ahh yeah good point
<natefinch> rogpeppe1: ironically, we're probably not going to be using it for what I wrote it for, but I figured we run enough executables, we might want a consistent way to give them a timeout.... and get better errors than we usually get running commands (exit code 1 or whatever it is)
<rogpeppe1> natefinch: yeah, i think it's a reasonable idea
<natefinch> rogpeppe1: I'm sure it needs some work, it's just an initial draft.
<rogpeppe1> natefinch: tbh i'm not that keen on the Option thing. it's cute, but i'd actually prefer to see an explicit options struct
<rogpeppe1> natefinch: also, i think you've got a potential race condition
<rogpeppe1> natefinch: not sure of a decent way to work around it though
<rogpeppe1> natefinch: i think you probably need to allow only one of either stderr or stdout as error
<natefinch> rogpeppe1: I'd thought about what happens if you use both stderr and stdout as errors.... allowing only one is probably better
<natefinch> rogpeppe1: and you may be right about the option thing.
<mup> Bug #1466167 opened: debug-hooks no longer works with 1.24-beta6 <juju-core:New> <https://launchpad.net/bugs/1466167>
<katco> wwitzel3: ericsnow: natefinch: do you guys need anything?
<ericsnow> katco: I'm good for now
<natefinch> ericsnow: nope, I'm good
<wwitzel3> katco: a new nasal passage
<katco> wwitzel3: hm.
<katco> wwitzel3: i have a hammer, a phillips screw driver, and a lawyer's phone number.
<wwitzel3> katco: no duct tape? sounds sketchy
<katco> wwitzel3: i assure you, the screw driver is the highest quality stainless steel
<katco> wwitzel3: it shouldn't stain my screwdriver at all
<wwitzel3> well in that case ...
<perrito666> wwitzel3: runny nose?
<katco> anastasiamac: ping
 * perrito666 wonders what he did this time to have reviewboard ignore him
<anastasiamac> katco: pong?
<katco> anastasiamac: hey got time for a chat?
<anastasiamac> katco: sure. tanzanite?
<katco> anastasiamac: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<katco> anastasiamac: don't have the link for tanzanite anymore =/
<anastasiamac> omw
<perrito666> katco: that is cruel
<alexisb> katco, word on the street is anastasiamac and wallyworld will be looking for tanzanite when they are next in Capetown SA
<alexisb> katco, you will have to one up them by getting moonstone in Missouri
<perrito666> alexisb: you know, there are easier way to do things :p http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0.Xtanzanite.TRS0&_nkw=tanzanite&_sacat=0
<katco> alexisb: lol i'll have to do that :)
<katco> alexisb: all jokes aside, i find moonstones to be prettier than tanzanite :)
<anastasiamac> alexisb: wallyworld will be looking for tanzanite in SA. anastasiamac will twidlling her thumbs in Aus :D
<anastasiamac> katco: combine the two and u'll get an even better value :D
<katco> anastasiamac: haha :D
<wallyworld> ebay? you'll end up buying purple glass
<wallyworld> a jeweller friend of mine has so many customers who bring in rings bought off ebay that are just straight out fakes
<perrito666> wallyworld: better? http://www.amazon.com/s?ie=UTF8&field-keywords=tanzanite&index=blended&link_code=qs&tag=wwwcanoniccom-20
<wallyworld> yes :-)
<perrito666> ow, interesting, I had not noticed the tag= part
<wallyworld> did you use a scope?
<perrito666> wallyworld: nope, my browser amaz<tab>
<perrito666> my browser being chrome
<perrito666> that quick search might be rigged ot do the same
<anastasiamac> alexisb: running a bit late...will ping after standup..
<alexisb> anastasiamac, ack
<anastasiamac> alexisb: m grabbing a drink (& coffeeeee) and will b there! tyvm for waiting :D
<thumper> wallyworld: do you have a few minutes to talk about leases?
<thumper> axw: you around?
<wallyworld> thumper: give me 5?
<thumper> ack
#juju-dev 2015-06-18
<waigani> wallyworld: can you cast your eyes over this when you have a moment: http://reviews.vapour.ws/r/1955 (ignoring unknown tools)
<wallyworld> already looking
<waigani> thanks :)
<thumper> davecheney: got a minute?
<thumper> davecheney: nm...
<wallyworld> thumper: free now
<thumper> wallyworld: let me try something first...
<wallyworld> ok
<mwhudson> davecheney: do you know why this happens? http://paste.ubuntu.com/11733285/
<mwhudson> (trivial is a GOARCH=arm binary)
<davecheney> thumper: whats up
<thumper> davecheney: I was going to talk to you about dumping the logs on timeouts, but I have another approach right now
 * thumper is deep in it
<davecheney> mwhudson: first guess, alignment
<davecheney> hmm, not that, that's aligned properly
<mwhudson> mm
<mwhudson> yeah, no functions that have the same alignment get disassembled ok
<mwhudson> bah grammer
<mwhudson> it seems everything before main.main gets disassembled ok
<mwhudson> maybe thumb/arm confusion?
<mwhudson> http://paste.ubuntu.com/11733349/ <- i wonder what that ... is hiding
 * mwhudson reads binutils, is not enlightened
<davecheney> that never helps
<thumper> FFFAAAAARRRRRKKKKKK
<thumper>  (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<davecheney> ??
<thumper> I think I have found the cause of the deadlock test
<thumper> and it harks back to a worker not created properly
<thumper> not using the agent config for the logdir
 * mwhudson has a super bad feeling
<thumper> damnit...
<thumper> perhaps not...
 * thumper digs some mroe
<davecheney> thumper: surely we don't need the rsyslog worker churning in the background all the time
<mwhudson> davecheney: i think it's 'marker symbols'
<mwhudson> to indicate thumb, data or arm
<davecheney> mwhudson: O_O
<thumper> no...
<mwhudson> $a/$t/$d
<davecheney> oh those buggers
<thumper> davecheney: while that sucks, it isn't the cause of this problem
<mwhudson> davecheney: they end up in the stuff from runtime/cgo
<davecheney> and their friends $f and $t
<thumper> davecheney: this is a naked channel write
<mwhudson> and the last one is a $d i guess?
<axw> thumper: I'm here now
<thumper> ok this is definitely the problem
<thumper> axw: that's ok, don't need you now :)
<axw> excellent
<mwhudson> davecheney: yes, that's the problem
<thumper> I'm pretty sure I can make the tests pass and not block, but I have a feeling the blocking may still happen in the wild
<mwhudson> i guess i can use objcopy to remove them all...
<davecheney> mwhudson: what do marker symbosl do ?
<davecheney> shift obdump into another 'mode' or something ?
<mwhudson> yes, exactly
<mwhudson> $a == what follows is arm insns
<mwhudson> $d == what follows is data
<mwhudson> $t == what follows is thumb
<mwhudson> i don't know if anything other than objdump cares about them
<mwhudson> given that GOARCH=arm uses constant pools after the insns, would be nice to generate them
<mwhudson> i'll file a bug and see what minux says :-)
<davecheney> i think we already go to some length to strip them out
<mwhudson> ah!
<mwhudson> this is external linking only i bet
<mwhudson> yeah, ldelf ignores them
<mwhudson> well not $t, that's a bug i guess
<mwhudson> alternatively, i wonder if we can stop gcc making them
<axw> wallyworld: hey sorry I missed the standup. I'll set aside volume destruction today and work on that relation-set bug for 1.24.1
<wallyworld> axw: np, ty. just reviewing the last branch so you could land those also in the background
<thumper> damn...
<thumper> that isn't it
<axw> wallyworld: cool, thanks
<axw> wallyworld: shouldn't be too far off now. need to update state to mark entities as Dead (possibly another big branch), and then the last big piece will be adding the lifespan binding
<axw> then a couple of bits and pieces
<wallyworld> and CLI for persistent volume mgmt
<axw> wallyworld: oh yeah, UI should be fairly trivial I think.
<wallyworld> i think so too
<davecheney> thumper: how do I turn up the logging output fora tes
<davecheney> i tried -gocheck.v
<davecheney> how do I get the debug output thta we get when a test fails ?
<thumper> -gocheck.vv
<thumper> two v's means send it straight out
<thumper> this is what I'm going through now
<natefinch> you need test.v too, or check.v doesn't do anything
<thumper> natefinch: wrong
<thumper> natefinch: it does do stuff, just perhaps also different with test.v
<natefinch> thumper: hrmph... I've definitely had test.v be the difference between no output and some output, when specifying check.vv    ..but maybe it was a different scenario
<natefinch> thumper: I was t hinking about proposing adding something like the hookLogger directly to loggo, since I want to do the same thing for the workload process plugins (i.e. redirect stdout to a loggo log).  What do you think?  Here's the hookLogger for reference: https://github.com/juju/juju/blob/master/worker/uniter/runner/logger.go#L23
<thumper> natefinch:  I'm kinda deep in debugging right now
<natefinch> thumper: np
<axw> wallyworld: in your review you said "update the CI tests" -- are they in already?
<wallyworld> axw: no yet but soon. i should have added "when they're done"
<axw> wallyworld: ok
<wallyworld> we'll create a card for next week
<axw> wallyworld: can't do a feature test until we have the last two big pieces done. I'll make a card for it
<wallyworld> np, ty. i expected we may need to wait
<mup> Bug #1466269 opened: bootstrap instance started but did not change to Deployed <bootstrap> <maas> <windows> <juju-core:New> <https://launchpad.net/bugs/1466269>
<mup> Bug #1466272 opened: Remove{Volume,Filesystem} etc. should behave like other Remove methods w.r.t. NotFound <storage> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1466272>
<davecheney> thumper: fix coming for 1466011
<davecheney> it's a problem with the test suite helper that sets up the apiserver and creates a mock api.Info
<wallyworld> axw: so with that worker loop log change - won't that mean we log twice in production?
<axw> wallyworld: yes. I can remove it, I'll just add it back in if I need to when testing
<wallyworld> ty
<wallyworld> maybe we can change test setup to show error
<axw> wallyworld: with rootfs's DestroyFilesystems, it could be made into a no-op but I don't know if we should. it could remove the directory we create in the agent's storage dir. I think sabdfl wanted stuff to be left behind though, for post-mortems
<wallyworld> axw: won't unmount be sad though if you try and use it against a dir that is not mounted?
<davecheney> thumper: https://github.com/juju/juju/pull/2590
<davecheney> menn0: https://github.com/juju/juju/pull/2590
<axw> wallyworld: I don't understand your question. I'm not talking about Detach (which does umount), I'm talking about Destroy. currently Destroy does nothing.
<wallyworld> axw: oh sorry, thought we were taling about detach
<axw> wallyworld: bad segue :)
<axw> wallyworld: Create will create a directory in the agent's storage dir. Attach will bind-mount (if possible). Detach will umount. Destroy does nothing atm
<wallyworld> that sounds reasonable for rootfs
<axw> wallyworld: only risk with that is that people will fill up their rootfs with crap, and it'll never get cleaned up even if they destroy the storage
<wallyworld> axw: bind-mount is used to map to different user specified location. but what if they don't ask for that mapping, then they acess the dir on rootfs directly right?
<axw> wallyworld: we create something like "/var/lib/juju/agent/<x>/storage/<backing>", then "mount --bind" that into the location specified in the charm, or the path that juju generates
<axw> wallyworld: if mount --bind fails (e.g. strict LXC/AppArmor), then we just give them the latter location if (a) it's on the rootfs, and (b) it's empty
<wallyworld> axw: right, so my question is if there's no locaton specified in the charm, we just hand that created dir straight to the charm i think don't we
<axw> wallyworld: we do the bind-mount-or-else regardless of whether hte location is specified
<axw> wallyworld: we could probably skip it if the location is unspecified, but the code's a bit simpler this way
<wallyworld> ok, that i couldn't recall off hand. i was worried about if we didn't bind mount, then detach would fail when we tried to unmount
<axw> wallyworld: that's why we check whether the location has the same mount-point as its parent dir. if it does, then it's not a bind mount
<axw> wallyworld: and in that case detach is a no-op
<wallyworld> sounds good
<axw> wallyworld: that also covers the case where we *did* bind mount, but we already detached; i.e. detach is idempotent
<wallyworld> and that's all tested?
<wallyworld> yep
<axw> wallyworld: I have tested that in the past. the latest code is only tested in unit tests. I'll test it more rigorously when the bits are in place to mark things as dying etc.
<wallyworld> sure, ok
<axw> wallyworld: oops, I already merged the log message. I'll do another branch to take it out
<wallyworld> axw: just do it as a driveby
<wallyworld> not that critical
<axw> wallyworld: ok, I'll do it when I update the code to destroy filesystems
<wallyworld> sounds good
<axw> wallyworld: would you mind also reviewing http://reviews.vapour.ws/r/1952? pretty straight forward one
<wallyworld> sure
<menn0> davecheney: looking
<wallyworld> axw: why remove environmanager = true?
<axw> wallyworld: it's set by default in SetUpTest
<wallyworld> ok
<wallyworld> axw: done
<axw> wallyworld: thanks
<thumper> davecheney: I think since you referenced a previos reviewboard thingy, it didn't add a new one
<thumper> davecheney: reviewing on GH
<thumper> davecheney: shipit
<davecheney> thumper: sorry lost contex
<davecheney> my machine rebooted
<thumper> davecheney:  https://github.com/juju/juju/pull/2590
<davecheney> thumper: please review the comments here http://reviews.vapour.ws/r/1962/
<davecheney> specifically my claims that we never write a bind all address into the jenv files
<thumper> ah fuckit
 * thumper is a dumb arse
<davecheney> ?
<thumper> the blocking
<thumper> that I thought I fixed
<thumper> I realised why my fix didn't
<thumper> davecheney: yes we never write bind all addresses to teh jenv
<jw4> waigani: thanks :)
<davecheney> thumper: that's what I though
<davecheney> the test had caused the code to change to accomodate it
<waigani> jw4: np
<thumper> davecheney: am I right in recalling there is no way to see if a channel is closed before trying to send stuff down it?
<davecheney> thumper: that is correct
<davecheney> but the cororraly is only the sender should close a channel
<davecheney> if you have a channel, which you don't own (don' thave the rights to close), then that is the bug
<thumper> the tests are hanging because the cert updater is trying to tell the api server that the cert has changed
<thumper> but I don't think the apiserver is listening any more
<thumper> it is a buffered channel, with 1 entry
<thumper> and this is the second change event...
<thumper> so it blocks
<thumper> which means the certupdater worker doesn't finish
<thumper> which means the agent doesn't finish
<davecheney> thumper: if a channle is closed the sender will panic
<davecheney> do you want a non blockgin send ?
<thumper> no, I want to work out why the apiserver isn't consuming the change event
<thumper> I can make the tests pass by not running the cert change worker
<thumper> which a number of other tests do
<davecheney> fair
<thumper> but I want to know why, because this may happen in the real world
<davecheney> thumper: can I press you for a review of http://reviews.vapour.ws/r/1962/
<davecheney> sorry menn0, no offence
<menn0> davecheney: i've just responded to and dropped those issues.
<menn0> davecheney: but another set of eyes wouldn't hurt
<davecheney> cooll
<davecheney> thanks for the review
<davecheney> if I submit this
<davecheney> how can I check
<davecheney> when will I know if it's fixed ?
<thumper> it looks ok to me...
<thumper> I am curious though
<thumper> about '127.0.0.1' vs localhost
<thumper> AIUI localhost will be [::] with IPv6
<davecheney> false
<davecheney> it is ::1
<thumper> ah
<thumper> anyway...
<davecheney> the problem is if uou have a net.Listner
<davecheney> no
<davecheney> you do
<thumper> do we need the listener in the base test to support ipv4 and v6?
<davecheney> l, _ := net.Listen("tcp", ":0")
<davecheney> the address reported by l.Addr(), will be a wildcard address
<davecheney> there is no way to convert that into a dialable addresss
<davecheney> see my second comment
<davecheney> we can bind to a wildcard address and then assume localhost points back to the wildcard (safe assumption) if you like
<davecheney> what confuses me, is whatever logic writes out the jenv file, must not use server.Addr(), because that was previosly hard coded to be "localhost:35687" (port number guessed)
<thumper> have I mentioned recently how completely fucking crazy our codebase is?
<thumper> I'm feeling the need to go to the gym and pound on a heavy bag
 * thumper feels the rage rising
 * davecheney pats thumpers shoulder, soothinglu
 * thumper breathes deeply
<davecheney> thumper: what can I do to help ?
<thumper> nothing right now
<davecheney> i have my shotgun at the ready
<thumper> davecheney: in which case, shoot our watcher infrastructure
<thumper> because it is truly shite
 * thumper crosses fingers
<thumper> I *think* I may have it
<thumper> ok...
<thumper> for the first time since I started looking, I got the test to pass 5 times in a row
<thumper> previous failure rate was 20-33%
<thumper> running 20 times now
<thumper> BTW, our code is shite
<thumper> and distributed, asynchronous, parallel, real life network systems are fucking hard to get right
<thumper> I feel the likelihood of success raising
<thumper> 9 passes in a row
 * thumper submits fix
<thumper> http://reviews.vapour.ws/r/1964/
<thumper> for the curious
<thumper> davecheney: you are reviewer right?
<davecheney> reviewing
 * thumper runs out to collect daughter
 * thumper pauses
 * thumper runs again
<davecheney> thumper: i dunno
<davecheney> this looks like it's fixing the symptoms, not treating the cause
<menn0> thumper: I agree with davecheney, that fix seems like a band aid to me
<menn0> thumper: great that you figured out the problem though. that's friggin awesome.
<davecheney> thumper: i'm also concerned that the pr description metnionds channel sends and bare writes
<davecheney> but the patch doesn't make any change in that respect
<davecheney> either the code, or the diagnosis, or the description are wrong
<menn0> thumper: i've just had a dig and i see that fixing this properly is going to be somewhat harder
<menn0> thumper: i reckon merge the fix so far and then add a card to do a better fix next iteration
<menn0> thumper: Susanna has a meeting now so I have dad duties
<menn0> thumper: but I will do some more work later tonight.
<wallyworld> axw: whenever you get a chance http://reviews.vapour.ws/r/1965/
<axw> wallyworld: awesome! looking
<thumper> davecheney: part of the problem was that the way the notify workers are, they don't pass the tomb in to the handle method
<thumper> so we can't select on it
<thumper> that is a somewhat bigger refactoring
<thumper> but perhaps worthwhile
<thumper> davecheney: I think one of the biggest issues was trying to work out what the problem is
<thumper> davecheney: and the more I think about it, the more I think we should pass the tomb into the handler functions
<thumper> davecheney: because anyone doing any channel work in the workers should use it
 * thumper enfixorates
<axw> wallyworld: reviewed
<wallyworld> ty
<thumper> davecheney: http://reviews.vapour.ws/r/1964/diff/# now passing the tomb dying channel to the handle func
<thumper> davecheney: so to treat the problem not just the symptom
 * thumper heading out to dinner now
<thumper> back later for meetings
<davecheney> meanwhile, reviews from the future http://dave.cheney.net/paste/wat.png
<dimitern> *lol* "3 minutes from now"
<TheMue> good morning and happy birthday, dimitern
<dimitern> TheMue, thank you! and good morning indeed :)
<TheMue> dimitern: want to continue our ipaddress id discussion?
<TheMue> dimitern: the current id may not be unique for future solutions, so we have to change it anyway. and the output for logging could be done by a fine String() on IPAddress
<TheMue> dimitern: also the id has the only role to identify one record, finding those matching some criteria is task of a query
<TheMue> dimitern: so far ok?
<dimitern> TheMue, I think we should get "ipaddress-<space>-<value>" implemented as a tag, space can be hardcoded to "default" for now
<TheMue> dimitern: where value is the ip address or hostname?
<TheMue> dimitern: could it be possible to have multiple same named spaces in one database in the future?
<thumper> davecheney: still around?http://reviews.vapour.ws/r/1964/
<dimitern> TheMue, the value is either an ip or hostname, yes
<TheMue> dimitern: so my questions remains, while a value is unique for a space, could the combination of space and value be double in one database?
<dimitern> TheMue, however... hmm to make it easier to parse (as space names can have dashes in them, as can hostnames), let's use "ipaddress-<space>@<value>" ?
<dimitern> TheMue, no it should not be possible
<dimitern> TheMue, we can have "ipaddress-default@localhost", but that's just stupid to store in state
<dimitern> a local-machine scoped address/hostname cannot participate in a space
<thumper> fwereade: ping
<TheMue> dimitern: ok, reasonable
<thumper> fwereade: https://plus.google.com/hangouts/_/canonical.com/chat and  http://reviews.vapour.ws/r/1964/diff/#
<dimitern> as it defeats the purpose of the space being a collection of interchangeable subnets which can see each other
<TheMue> dimitern: thought about fwereade 's arguments for having a generated unique key, may be UUID but also could be  different one?
<thumper> o/ dimitern and TheMue
<TheMue> dimitern: it will always be unique, regardless what we think about in the future
<TheMue> thumper: o/
<dimitern> thumper, hey there
<dimitern> TheMue, for one, space names are unique - even across environments, as they can be reused by multiple environments once created
<thumper> dimitern: really? are you sure?
<dimitern> TheMue, about which part?
<dimitern> thumper, sorry ^^
<thumper> space names unique across environments
<thumper> I'm not entirely sure that makes sense
<thumper> consider this...
<fwereade> thumper, o/
<dimitern> yes, as the point is for the admin to set them up once and then they can be discovered for new envs
<thumper> bob in environment A in system B creates space C
<TheMue> dimitern: if env foo has space bar and env yadda has space bar?
<thumper> mary in environment D in system E creates space C
<thumper> bob's env A migrated to system E
<thumper> boom
<thumper> fwereade: in the hangout
<dimitern> spaces are bound to the underlying substrate, not to an environment per se
 * TheMue still prefers keys with global unique ids
<dimitern> e.g. space "foo" means in AWS a bunch of subnets with tag "juju-space-foo"
<dimitern> however, if we have environments on different substrates, they can have the same space names I guess
<fwereade> dimitern, please just use an opaque key
<dimitern> TheMue, ok, I'm convinced - let's go with: 1) add a UUID field to ipaddressesDoc (and a unique index on it), 2) upgrade step to generate one if missing, 3) use "ipaddress-<uuid>" for tag format, 4) finish the addresser and change other workers that use api + addresses to use tags
<TheMue> dimitern: +1, will do (and add cards)
<dimitern> TheMue, cheers
<TheMue> omw btw, but hangput dislikes me :(
<TheMue> dimitern: voidspace: dooferlad: same troubles with hangout?
<dimitern> TheMue, no, just joined
<dooferlad> TheMue: no, but make sure you are using the right link. It isn't the same every day...
<TheMue> dooferlad: I've used the one from the mail notification
<dooferlad> TheMue: OK, that is odd
<TheMue> dooferlad: it hangs at "try to joining the call"
<dimitern> jam, fwereade, standup?
<TheMue> dooferlad: will restart my browser
<jam> on our way
<anastasiamac> dimitern: ... Â¸Â¸â¬Â·Â¯Â·â©Â¸Â¸âªÂ·Â¯Â·â«Â¸Â¸Happy Birthday To YouÂ¸Â¸â¬Â·Â¯Â·â©Â¸Â¸âªÂ·Â¯Â·â«Â¸Â¸ ...
<dimitern> anastasiamac, thank you so much :)
<anastasiamac> :D
<wallyworld> fwereade: http://reviews.vapour.ws/r/1968/
<fwereade> wallyworld, LGTM with a trivial
<wallyworld> fwereade: actually, i'm testing on the scenario outlined in the bug and it's broken again with this fix. i've done an install hook that never exists. i'm wondering if this wold have worked in 1.21
<fwereade> wallyworld, force-destroy machine always should have, yes
<wallyworld> hmmm. i can't see off hand how the latest fix is different from 1.21
<fwereade> wallyworld, I suspect that something about the status changes has made possible a db state which breaks unit.Destroy
<fwereade> wallyworld, the fact that it's triggering in obliterateUnit is coincidental
<wallyworld> hmmm. i'll need to look at the logs i guess
<fwereade> wallyworld, if you've got a repro you should look at the actual transactions we tried to run against that unit
<fwereade> wallyworld, and it sounds like a stable broken state it gets into
<fwereade> wallyworld, that way you can at least see what ops the chain of failed build attempts produced
<fwereade> wallyworld, see if they're changing (there's a race we've missed) or stable (we've fucked up the memory/db assertion equivalence)
<wallyworld> yup
<wallyworld> sigh
<wallyworld> so i guess there's another problem somewhere besides the one just fixed
<fwereade> yeah
<fwereade> wallyworld, if we're seeing reproducible ErrExcessiveContention we should at least be able to repro it in unit tests and have a fix that rests on something more durable than mere painstaking analysis ;p
<wallyworld> tests pass, i've got to figure out failure senario
<wallyworld> i don't know that we have a unit test for a hanging hook
<wallyworld> fwereade: oh, i'm a dick - i forgot --upload-tools. just verified and it's fine
<fwereade> wallyworld, phew :)
<wallyworld> fwereade: i replied to yout comment. also, we don't define a slice of statuses so hard to cycle through them
<fwereade> wallyworld, yeah, I thought so
<wallyworld> but so long as it's != Allocating that's all we need
<fwereade> wallyworld, and, ah yes, ofc, I'm dumb
<fwereade> wallyworld, ship it :)
<wallyworld> i just added thoses extras just because
<wallyworld> ty
<wallyworld> at least caus ei forgot upload tools i reproduced it :-)
<mup> Bug #1466498 opened: serverSuite.TestStop fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1466498>
<mup> Bug #1466498 changed: serverSuite.TestStop fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1466498>
<mup> Bug #1466498 opened: serverSuite.TestStop fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1466498>
<mup> Bug #1466513 opened: destroyTwoEnvironmentsSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1466513>
<mup> Bug #1466514 opened: TestCertificateUpdateWorkerUpdatesCertificate fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1466514>
<mup> Bug #1466520 opened: serviceSuite setup fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1466520>
<mup> Bug #1466525 opened: restore fails due to mongo login failure <backup-restore> <ci> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1466525>
<katco> wwitzel3: lmk if you would like to skip our 1:1
<fwereade> wallyworld, don't suppose you're awake?
<wwitzel3> katco: right, I was planning to take some medicine and lay down for a bit, unless you had something specific we needed to cover
<katco> wwitzel3: get some rest
<katco> ericsnow: natefinch: do you need anything?
<natefinch> katco: not currently :)
<ericsnow> katco: no, thanks
<ericsnow> katco: other than a LGTM on that metadata patch :)
<katco> ericsnow: done :)
<ericsnow> katco: thanks!
<rogpeppe1> i'd very much like a review of this from someone in juju-core please. moving towards having an client-inspectable schema for juju environment config: https://github.com/juju/juju/pull/2597
<alexisb> perrito666, I had fun playing with the new service status yesterday
<alexisb> it is mightily useful
<alexisb> I especially like the status-history
<perrito666> I am glad :D I had fun playing with it too :p
<mramm> hey, quick question perhaps somebody here knows the answer
<mramm> does juju use some sort of connection pool for mongodb? or is a new connection established for each query?
<mramm> perrito666: ^^^
<voidspace> mramm: it creates a new session for each connection
<voidspace> mramm: *but*
<voidspace> mramm: mgo is supposed to do connection pooling for us
<voidspace> mramm: including disposing of dead connections
<mramm> voidspace: so there is connection pooling in mgo?
<voidspace> mramm: yes
<mramm> thanks!
<fwereade> perrito666, was just looking at your github PR, one question:
 * perrito666 braces
<fwereade> perrito666, this is just testing the existing behaviour, right? in which update-status fires only when the timer ticks?
<perrito666> fwereade: yes, as that pr does not add the new behaviour
<fwereade> perrito666, great, so that is why I can't see any changes in startupHooks despite the addition of update-status to baseCharmHooks :)
<perrito666> I split both things after you suggested it yesterday
<perrito666> fwereade: yes :)
<fwereade> perrito666, ok, LGTM with some naming quibbles, but check back with ian about the idle timer
<perrito666> fwereade: I will tx
<fwereade> perrito666, I'm pretty confident it shouldn't be below 5s
<fwereade> perrito666, even if everything responds super-fast
 * perrito666 uses randInt(2,10)
<fwereade> perrito666, relation-set gets written when hook completes
<fwereade> perrito666, it could easily take 5s before a counterpart even sees that
<fwereade> perrito666, and even if *that* unit runs a hook with a response really fast
<fwereade> perrito666, we won't see it until 5s after it did at best
<fwereade> perrito666, and more likely 10s
<perrito666> fwereade: this https://github.com/juju/juju/pull/2586#discussion_r32743555
<fwereade> wallyworld, this conversation is worth reading back when you're around
<fwereade> perrito666, wallyworld, I'd actually say that it's more like 15s of idleness before you can have confidence in your idleness
<perrito666> it is because as the logic stands now the default is inactive until and unless the call to getMetricsTimer(charm) says otherwise
<perrito666> fwereade: Ill make sure wallyworld gets to this conversation tonight
<fwereade> perrito666, think of the timerchooser on its own
<fwereade> perrito666, what makes the inactive one "default"?
<fwereade> perrito666, you must at least have "active" and "inactive" as well as "default"
<fwereade> perrito666, otherwise "default" is just another name for "inactive"
<fwereade> perrito666, but I maintain that inactive is *not* the default
<perrito666> fair
<fwereade> perrito666, would you implement a BoolChooser with methods True and Default?
<fwereade> ;p
<fwereade> perrito666, wallyworld: if you think this is reason enough to tweak the watcher resolution, so we can detect idleness early, I'm prepared to investigate that but we'd need to stress-test it pretty hard
<fwereade> perrito666, wallyworld: (and I think there are UX considerations too -- ISTM that traffic lights that flicker back and forth will inspire less confidence than those that take a little longer to go solid green and stay there)
<perrito666> fwereade: I definitely would compare this with hdd light rather than traffic lights
<perrito666> back when hdd light was useful
<mup> Bug #1466565 opened: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1466565>
<fwereade> perrito666, that's what solid yellow indicates
<fwereade> perrito666, "I'm doing stuff, leave me be"
<fwereade> perrito666, solid green indicates "everything is configured and working as it should"
<perrito666> ill agree nevertheless that entreing and leaving iddle too fast feels a bit like whack-a-mole
<fwereade> perrito666, if our units look like they can't decide which state they're in we all look dumb
<fwereade> perrito666, look at it this way
<fwereade> perrito666, status needs to represent things users care about
<fwereade> perrito666, they will pay attention to, and react to, changes in status
<fwereade> perrito666, but every status change they don't need to react to dilutes the value of the data stream
<fwereade> perrito666, (and IMO yellow->green should inspire the reaction "great, now I can relax")
<mup> Bug #1466570 opened: Juju add-unit stuck on new lxc containers <sts> <juju-core:New> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1466570>
<rogpeppe> fwereade: here's another step along the provider schema thing. i didn't change the EnvironProvider interface yet because i didn't want to potentially break external provider implementors yet. http://reviews.vapour.ws/r/1969/
<fwereade> rogpeppe, nice
<fwereade> rogpeppe, queued it :)
<rogpeppe> fwereade: ta!
<rogpeppe> fwereade: i won't hold my breath :)
 * fwereade considers rogpeppe to be a wise man
<natefinch> heh, the deputy repo I made 2 days ago under github.com/juju already has 12 stars
<rogpeppe> mramm: there is connection pooling *but* it's likely that each concurrently running operation uses one connection
<rogpeppe> mramm: which is something we've been dealing with in the charm store recently
<rogpeppe> mramm: see https://github.com/go-mgo/mgo/issues/124
<rogpeppe> natefinch: i was thinking of suggesting for someone recently, but the stderr output needed too much massaging for it to be useful as is
<rogpeppe> natefinch: i wonder if it might be good to have an optional TransformStderrToError([]byte) error (or something) function that can be used to cope with situations like that
<natefinch> rogpeppe: you can always get the error string and massage it afterward, if you really need to.   That seems a little too specialized to broaden the API.  Generally the stderr-as-error is only good if you know the command produces reasonably sized stderr output.
<rogpeppe> natefinch: that's true
<rogpeppe> natefinch: in the case above, we really wanted just the first line
<rogpeppe> natefinch: i wish there was some nice way of dealing with multiline errors
<natefinch> gah, I wish loggo had non-f methods
<natefinch> katco: so, with a bunch of people already watching the repo I created (github.com/juju/deputy), I'm hesitant to follow through with my previous plan of deleting it in order to follow our new process.  Maybe we can make this the exception, and just make all future work on the repo via PRs?
<katco> natefinch: that's fine. but we still need the code reviewed
<natefinch> katco: absolutrely
<natefinch> rogpeppe: btw, updated the deputy package to not use the cute options thingy anymore.  I think it's a lot more understandable without it.  Also added a way to have it pipe the output to a logging function, similar to how we do hook output.
<rogpeppe> natefinch, katco: what's the "new process" ?
<katco> rogpeppe: first, you like 3 and a half candles
<natefinch> rogpeppe: create the repo with readme & license only, then add all code via PRs
<katco> rogpeppe: then, you place a blue lotus from the slopes of mt. kilimanjaro in the middle
<rogpeppe> katco: well good start, i already like candles
<natefinch> lol
<katco> rogpeppe: er, what nate said. it will be on the wiki soon
<rogpeppe> katco: ha, i'd forgotten we even had a wiki :)
<natefinch> the candles and lotus are optional but recommended
<natefinch> rogpeppe:  we started using the wiki after I got annoyed with the state of our developer documentation
<natefinch> rogpeppe: the github wiki that is
<rogpeppe> natefinch: where is it?
<natefinch> rogpeppe: https://github.com/juju/juju/wiki
<rogpeppe> natefinch: what are the interface{} arguments to StdoutLog and StderrLog ?
<rogpeppe> natefinch: wouldn't that be better as just a single string arg?
<mattyw> I need an adult if there's one around?
<natefinch> rogpeppe: it's a concession to the way most log packages work, e.g: http://golang.org/pkg/log/#Print
<rogpeppe> mattyw: i can pretend
<rogpeppe> natefinch: i think it would be better a func(string)
<rogpeppe> as
<mattyw> ah rogpeppe you might be just the man - you're name is on the file I'm interested in
<rogpeppe> mattyw: i'm afraid that might be true of quite a few files :)
<natefinch> rogpeppe: I started that way... I can put it back.  It means you need to wrap most log package's logging functions, but it is a lot more clear what it'll send
<rogpeppe> natefinch: yeah, i think it's worth it.
<rogpeppe> natefinch: and it's easier to use if you want to add a prefix, for example
<mattyw> rogpeppe, for acme fans: apiserver/charms/client_test.go:L120 for github fans https://github.com/juju/juju/blob/master/apiserver/charms/client_test.go#L120
<natefinch> rogpeppe: yeah, I agree, after looking at a consumer using loggo
<rogpeppe> mattyw: not *quite* :)
<rogpeppe> mattyw: no L
<mattyw> rogpeppe, that call seems to be testing the CharmInfo function in the client, but as it's in the charms facade package I'd be expecting it to test that one right?
<mattyw> rogpeppe, ah yeah - sorry
<rogpeppe> mattyw: it's quite usual to test the server side functions by calling the client side functions
<rogpeppe> mattyw: because the client side functions work by invoking the server side functions
<mattyw> rogpeppe, but it shouldn't it be calling the charms facade client?
<mattyw> rogpeppe, there are two charminfo functions one in the charms facade, and another in the enormous client
<rogpeppe> mattyw: ah, i guess
<rogpeppe> mattyw: that stuff is well after my involvement in this area
<rogpeppe> mattyw: i've no idea why there are two implementations of the same call
<mattyw> rogpeppe, I'm not looking for blame - I'm looking for another set of eye to check my sanity
<rogpeppe> mattyw: looks like you're probably right
<rogpeppe> mattyw: i've no idea why the duplication; i guess all the tests need to be duplicated too
<mattyw> rogpeppe, there is some dubiousness added by the basecharmSuite and charmSuite stuff
<mattyw> rogpeppe, duplication is probably a wip attempt at moving away from the huge client
<rogpeppe> mattyw: i would guess that too
<rogpeppe> mattyw: fat lot of difference it makes to the understandability or maintainability of the code though :)
<katco> if a state server is in a bad way, is it safe to recommend cycling it? or is juju going to do something weird like uninstall itself?
<rogpeppe> katco: restarting it should be just fine
<rogpeppe> katco: restarting the service, that is
<rogpeppe> katco: in case you had something else in mind
<katco> rogpeppe: i was just suggesting to cycle the container (it's local)
<rogpeppe> katco: reboot it?
<katco> rogpeppe: yes
<rogpeppe> katco: you should probably be ok. how is the server in a bad way?
<katco> rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1466565
<mup> Bug #1466565: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1466565>
<katco> rogpeppe: it looks to me like somehow juju got in a bad node in its state machine
<rogpeppe> katco: the log linked to in that issue doesn't look like it shows the issue
<rogpeppe> katco: it says it's restarting because an upgrade is available
<katco> rogpeppe: it never comes back up though, wondering if it actually shut down
<rogpeppe> katco: if you just restart the state server service, do you just get the same thing?
<katco> rogpeppe: waiting to hear from sparkiegeek
<katco> rogpeppe: if you're interested, #juju@canonical
<mattyw> It's been so long since I've done some juju stuff I have no idea what I'm doing
<natefinch> mattyw: just write if err != nil { return err } a bunch of times, and it'll come back to you ;)
<rogpeppe> lol
<mattyw> natefinch, go is fine, it's the facades that do it :)
<natefinch> mattyw: yeah, juju is a beast of a codebase.  Just the pure LOC make it hard to get a handle on
<mattyw> natefinch, ah ha! I've just remembered the magic
<mattyw> (the juju in juju you could say)
<mup> Bug #1466565 changed: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Invalid by cox-katherine-e> <https://launchpad.net/bugs/1466565>
<natefinch> How come my software updates all get shown with the description instead of the name of the package?  e.g.: http://i.imgur.com/E4Q3uBV.png  Is that an ubuntu bug, or some weird setting I set by accident?
<mup> Bug #1466565 opened: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Invalid by cox-katherine-e> <https://launchpad.net/bugs/1466565>
<mup> Bug #1466565 changed: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Invalid by cox-katherine-e> <https://launchpad.net/bugs/1466565>
<natefinch> ericsnow: unintended nice side effect of using json for plugin output - it's easy to output without line returns
<ericsnow> natefinch: yay
<katco> is anyone familiar with the FORCE-VERSION file?
<perrito666> natefinch: ah, same happened today
<perrito666> perhaps the name is collapsed?
<mup> Bug #1466565 opened: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Confirmed for cox-katherine-e> <https://launchpad.net/bugs/1466565>
<mup> Bug #1466565 changed: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Confirmed for cox-katherine-e> <https://launchpad.net/bugs/1466565>
<natefinch> katco: I think that's what gets included when you use --upload-tools
<perrito666> I think it is necessary to allow juju to use the uploaded version of juju (for which there is no stream)
<katco> perrito666: apparently not only then. was installed by default by just bootstrapping 1.23.3
<katco> natefinch: ^^
<mup> Bug #1466565 opened: Upgraded juju to 1.24 dies shortly after starting <landscape> <upgrade-juju> <juju-core:Confirmed for cox-katherine-e> <https://launchpad.net/bugs/1466565>
<mup> Bug #1466629 opened: Containers fail to get ip when non-maas dhcp/dns is used <dhcp> <dns> <lxc> <maas> <openstack-installer> <openstack-provider> <ubuntu-engineering> <ubuntu-openstack> <juju-core:New> <https://launchpad.net/bugs/1466629>
<natefinch>  ericsnow: how do I upload a patch to reviewboard?
<alexisb> thumper, not that you need any distractions today, but when you have a moment I need your help today
<thumper> heh
<thumper> ok, will ping you when I have time
<natefinch> ericsnow: if you have time before EOD, could you take a look at the deputy repo?  I made a PR to a branch that shows all the code: https://github.com/juju/deputy/pull/1   I don't know how to get that onto reviewboard or if we care (can always review on github)
<natefinch> (or anyone else up for a review ^ )
<mup> Bug #1466660 opened: Unable to create hosted environments on EC2 <juju-core:New for cherylj> <https://launchpad.net/bugs/1466660>
 * fwereade would like to express a brief moment of rage to discover that we're still just crapping charm.Meta et al into the database
 * fwereade is sure that multiple people have promised to fix that over the last year
<alexisb> fwereade, you should be sleeping, but if it makes you feel better I am listening
<katco> wallyworld: thumper: if anyone in your half of the world gets some bandwidth, this bug is targeted for 1.24.2: bug 1466565
<mup> Bug #1466565: Upgraded juju to 1.24 dies shortly after starting <cts> <landscape> <sts> <upgrade-juju> <juju-core:Confirmed> <juju-core 1.24:Confirmed> <https://launchpad.net/bugs/1466565>
<fwereade> alexisb, I have subsided to mild background grumpiness :)
<fwereade> menn0, ping
<menn0> fwereade: hi
<thumper> what happened to 1.24.1?
<alexisb> thumper, what do you mean what happened to it?
<thumper> alexisb: katco says it is targetted to 1.24.2? I thought we just released 1.24.0
<alexisb> thumper, we are going to cut 1.24.1 soon
<katco> thumper: we have a 1.24.1 as well
<alexisb> so new bugs may be targeted to 1.24.2 instead of 1.24.1
<fwereade> menn0, re the stateCollection interface
<fwereade> menn0, what motivated the set of methods we picked?
 * menn0 looks
<menn0> fwereade: they were what was in use with Juju at the the time of writing
<menn0> fwereade: it's grown a few methods since it was created as people have wanted more
<katco> ericsnow: do you know what have we forked because of lack of 1.4? was it just the stdlib?
<menn0> fwereade: why do you ask?
<ericsnow> katco: the only things of which I'm aware are govmomi and that package for windows
<fwereade> menn0, I wanted to use it myself from a state subpackage to take advantage of the env-aware bits
<fwereade> menn0, and I found myself thinking "hmm, I'm pretty sure we shouldn't ever Insert"
<fwereade> menn0, and I found where we inserted and GAAAH WTF in more than one way
<katco> ericsnow: looks like sys package from stdlib: http://reviews.vapour.ws/r/1897/diff/#
<fwereade> menn0, so I got scared and I looked for Update and couldn't spot it
<menn0> fwereade: AddCharm is one place we do where we shouldn't
<ericsnow> katco: that's not the stdlib sys package, is it?
<katco> ericsnow: i believe so
<fwereade> menn0, and then I just found UpdateId and got grumpy again because I'm damn sure I told thumper *not* to do txn-layer-skipping writes into docs that use txns, and to please put LastLoginTime somewhere else
<katco> ericsnow: golang.org/x/sys --> github.com/gabriel-samfira/sys
<ericsnow> katco: there's a syscall in the stdlib, but no sys
<fwereade> menn0, so, ehh, anyway
<thumper> fwereade: I think we agreed to disagree on that point...
<thumper> and I felt that the overhead of putting it elsewhere wasn't worth it
<thumper> and no one watches it
<katco> ericsnow: sorry, supplemental library
<fwereade> thumper, I apologise then for my lack of clarity
<ericsnow> katco: regardless, yeah, that's the one
<fwereade> thumper, the txn system is a layer as much as the api is
<fwereade> thumper, and now we've got a document with a magic field that needs as much documentation as everything else in that serialization thing
<fwereade> thumper, and depends on people reading and understanding and remembering and eschewing the temptation to just autocomplete something that looks like a good idea
<fwereade> thumper, there are times when we want txn and times when we don't
<fwereade> thumper, but we need very very good reasons to mix them
<fwereade> thumper, the relation data cleanup ones are bad enough and they only touch documents known to be unreferenced by the rest of the system
<fwereade> thumper, mixing txn-aware and non-txn-aware fields in the same document just triggers my twitch-froth-gesticulate reflex
 * thumper watches fwereade twitch
 * fwereade is indeed something to behold
<fwereade> thumper, I'm also suffering residual grumpiness from observing that the charm document schema is still largely coming from a different repository
<thumper> fwereade: ENOCONTEXT
<fwereade> thumper, ehh, this is all coming from our chat this morning
<fwereade> thumper, trying to get the stateCollection interface out of state so I could consume things that implemented it and get useful env-awareness in my lease bits
<thumper> environment based lease collection?
<fwereade> thumper, I think most of the lease namespaces will be per-environment, yes
<fwereade> thumper, I could hand-hack it but that would be dumb
<thumper> agreed
<fwereade> thumper, so anyway I started looking at what we actually did with that interface and that led me to the naked Insert of the charm document and then I looked at the charm serialization and gibber-gibber-flail-moan
<fwereade> thumper, menn0: so, what I want to do is
<thumper> the serilization structure isn't in the state package?
<thumper> that seems like a fail
<fwereade> thumper, is is a goddam massive fucking failure and I am certain that more people than just those working on metrics and actions ahve promised to (1) DTRT themselves and (2) fix the legacy shittiness
<fwereade> thumper, and yet it has somehow failed to occur in both those instances
<fwereade> alexisb, huh, it looks like I did have a rant in me after all :/
<thumper> haha
<thumper> I'm thinking my fix I landed yesterday should probably be ported to 1.24
<redelmann> hi, it's normal to get without space on juju machine-0???
<redelmann> im using aws default constraints on bootstrap
<redelmann> juju is using 7.5G of 8Gb
<perrito666> redelmann: check the logs
<perrito666> as in, check if the logs are overly sized
<perrito666> oversized
<redelmann> perrito666, 36M of logs
<fwereade> thumper, and even more infuriatingly
<redelmann> perrito666, /var/libs/juju/db is using 3.7Gb
<fwereade> thumper, there's a *bit* of input sanitization for *one* of those fields
 * thumper chuckles
<fwereade> thumper, but that just munges the *Config into a different one
<fwereade> thumper, and just for fun that only happens on *one* of the two code paths that can lead to config data being written to the document
<thumper> haha
<thumper> fwereade: were you around yesterday when I said how shite our codebase was?
<thumper> nothing surprises me any more
<perrito666> redelmann: could you provide a detailed du -shc /var/lib/juju/*
<perrito666> redelmann: pastebin :)
<fwereade> thumper, so, I do not think that graduating reviewers has done us any good
<thumper> fwereade: I don't think that is the source of the problem to be honest
<fwereade> thumper, it is all too easy for these things to happen when both the coder and the reviewer have only passing familiarity with the code
<fwereade> thumper, I think it was an attempt to enforce tighter controls and has not really worked out on that front
<redelmann> perrito666, http://paste.ubuntu.com/11737759/ and http://paste.ubuntu.com/11737763/
<katco> fwereade: architectural documentation pls
<perrito666> redelmann: looking
<katco> fwereade: the code doesn't convey all the knowledge needed to review
<thumper> fwereade: there are too many devs to push all reviews through the relatively few people who know more how things hang together
<thumper> katco: agreed
<fwereade> katco, it is hard to bring oneself to do that when the stuff I have written seems to be completely ignored
<thumper> fwereade: we need a wiki page of "distilled fwereade ranting"
<redelmann> perrito666, mhh.. look at this: almost 1 hour of this "ps -aux" http://paste.ubuntu.com/11737765/
<fwereade> katco, that is no doubt at least partly a perception issue
<thumper> wallyworld: did you fix 1452745 in master too?
<wallyworld> bug 1452745
<mup> Bug #1452745: 386 constant 250059350016 overflows int <386> <blocker> <ci> <regression> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1452745>
<wallyworld> i think so
<wallyworld> i'll check
<thumper> (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
<wallyworld> thumper: yes, it got ported forward
<thumper> https://bugs.launchpad.net/juju-core/+bugs?field.tag=intermittent-failure&field.tags_combinator=ALL
 * thumper sadface
<anastasiamac> thumper: ow! that's a lot of "intermittent" failures...
<thumper> anastasiamac: yeah...
<thumper> something for the bug squad to focus on
<anastasiamac> :D
<thumper> I'm hoping my team will have some time next cycle
<thumper> s/cycle/iteration/
<anastasiamac> well, dave is living in the future - he must have more time than anyone :D
<anastasiamac> according to rb at least :D
<davecheney> yup, living in the future, three minutes at a time
<anastasiamac> make it 8 and u'd be almost like the sun :))
<fwereade> thumper, menn0: oh, yeah, before sleep: I want to make that interface smaller and at least force the questionable bits to go via .Underlying() so they know they're being bad
<fwereade> thumper, menn0: objections?
<fwereade> thumper, menn0: and I know it doesn't cover everything and you can write via Query but one thing at a time :)
<fwereade> thumper, menn0: (I refer to state.stateCollection)
<menn0> fwereade: that sounds reasonable to me
<thumper> fwereade: I defer to menn0 on this
<fwereade> menn0, thumper: cool, thanks, and happy weekends both :)
<thumper> cheers
#juju-dev 2015-06-19
<wallyworld> axw: sorry, finger slipped :-)
<axw> wallyworld: bye :p
 * thumper is done
<thumper> laters
<dooferlad> dimitern: hangout?
<voidspace> dimitern: http://reviews.vapour.ws/r/1970/
<dimitern> TheMue, LGTM
<TheMue> dimitern: thx
<voidspace> dooferlad: thanks
<voidspace> dooferlad: failing tests, so I'll have to investigate and resubmit
<voidspace> dooferlad: on my branch (thought I'd run the tests - but obviously not)
<dimitern> voidspace, TheMue, dooferlad, guys, I'm not feeling well and need to get some rest, so I might be back later in the evening
<TheMue> dimitern: oh, hope you'll get well soon
<dimitern> thanks
<rogpeppe> anyone know how to bootstrap a local provider without apt-get installing juju-local
<rogpeppe> ?
<rogpeppe> i really don't want to have juju-local installed because i never ever want to use /usr/bin/juju
<rogpeppe> fwereade: ^ ?
<fwereade> rogpeppe, afraid not
<fwereade> rogpeppe, I don't mind having a /usr/bin/juju hanging around :)
<rogpeppe> fwereade: problem is, i can remove /usr/bin/juju but it keeps on *coming back*
<rogpeppe> fwereade: i like being able to do go install juju/... and then running "juju". it always surprises me when it chooses /usr/bin/juju
<mgz> rogpeppe: curtis has a fake juju-local package
<mgz> that you can install, plus the real deps of juju-local
<rogpeppe> mgz: ha, that would be great (although, wtf!)
<rogpeppe> ISTM that juju should check for the actual deps it needs, not juju-local per se
<fwereade> rogpeppe, to be fair it's not optimal: I do have a mild `ll $(which juju)` habit
<rogpeppe> mgz: know where i can get it from?
<mgz> trying to find it again
<rogpeppe> mgz: ta
<mgz> rogpeppe: forwarded you mail
<rogpeppe> mgz: thanks!
<mgz> I presume it still works, is a hack from a year ago
 * rogpeppe tries to remember how to install debs directly
<mgz> dpkg -i
<rogpeppe> ah dpkg
<rogpeppe> i should do it more often
<rogpeppe> mgz: thanks, that worked nicewly
<rogpeppe> nicely, even
<mup> Bug #1464356 changed: TestCloudInit fails <blocker> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1464356>
<tasdomas> hi
<tasdomas> soulc somebody take a look at http://reviews.vapour.ws/r/1116/ and tell me if it's a bad idea?
<mgz> is dimitern off today?
<mgz> if so, probably want someone else to fix the 1.24 branch
<tasdomas> s/soulc/could
<mgz> see bug 1464356
<mup> Bug #1464356: TestCloudInit fails <blocker> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1464356>
<natefinch> ug, why the heck does juju/errors/NewErr return a value that does not satisfy the error interface? :/
<perrito666> natefinch: because satisfying the interface is too mainstream
<natefinch> perrito666: It just means that you can't use that function to directly embed the value into another error type... which is the only reason that function even exists.
<katco> natefinch: standup
<katco> wwitzel3: not sure if you're here yet, but standup if you are
<natefinch> katco: coming'
<pmatulis> hello, re restrictions (block/unblock), does an unblock override a restriction set in environments.yaml ?
<fwereade> is anyone who worked on status-history aroound?
<perrito666> fwereade: I am
<fwereade> perrito666, so, we seem to do things quite strangely there
<perrito666> tell me
<fwereade> perrito666, ISTM that we destroy history before we're finished with it
<fwereade> perrito666, and that unit.Destroy now runs 2 transactions in flagrant violantion of sense or sanity
<perrito666> fwereade: mmm, destruction of history  was one of the things that I was unsure of
<perrito666> fwereade: wanna hangout?
<fwereade> perrito666, sure, start one
<perrito666> fwereade: come to https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand it is a deserted land at this time of the day
<fwereade> perrito666, by which I mean "please, good sir, would you be so kind as to start a hangout and invite me to join it" :)
<mup> Bug #1466269 changed: bootstrap instance started but did not change to Deployed <bootstrap> <maas> <windows> <juju-core:New> <https://launchpad.net/bugs/1466269>
<natefinch> ericsnow, katco:  I'm not going to be able to get this landed before I get back, which will be in approximately 2 hours.  Sorry, the rebase caused some conflicts, and I evidently did the wrong thing when merging them (i.e. I had removed plugin.go from the process dir in my branch, and it looks like more was added to that file in eric's branch).
<ericsnow> natefinch: if you don't mind, I can take a stab at getting it merged...
<katco> ericsnow: natefinch: we can wait since our planning meeting is on mon
<ericsnow> katco, natefinch: k
<natefinch> ericsnow: you're welcome to.
<katco> natefinch: but we do need that landed today i think
<natefinch> katco: yep
<natefinch> katco:  it's a matter of putting back the plugin.go file and removing the launch details struct from it, I believe.
<natefinch> ericsnow: ^
<ericsnow> natefinch: if it can wait it will probably be better for you to sort it out
<natefinch> ericsnow: that's fine
<natefinch> I should have time
<natefinch> gotta run
<ericsnow> natefinch: also, considering merging rather than rebasing
<ericsnow> natefinch: take care
<mup> Bug #1466951 opened: juju no-proxy does not work with apt-http-proxy <juju-core:New> <https://launchpad.net/bugs/1466951>
<moqq> i have the machine-0 jujud agent consuming our entire cpu on both of our environments, independantly
<moqq> has anyone here seen this before?
<mup> Bug #1466969 opened: Upgrading 1.20.14 -> 1.24.0 fails <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1466969>
<perrito666> moqq: not me, is there any logging that we can see?
<moqq> after startup everything appears idle from the logs, strace reveals its spending a lot of time on futex
<moqq> i can grab the startup logs one sec
<moqq> mongo also is spiking a lot with it
<perrito666> moqq: juju version?
<moqq> less consistently, but there seems to be a lot of activity between them
<moqq> 1.23.3-trusty-amd64
<moqq> perrito666: https://gist.github.com/tysonmalchow/765ed773a7edfc0a2f96 is the startup log
<perrito666> moqq: weird, I see nothing out of the ordniary :(
<moqq> :(
<moqq> i really dont want ot have to scrap juju 1 month after getting it into our production envâ¦ but unless i can fix this weâre going to have to :(
<perrito666> moqq: sadly it is friday afternoon so not many people around to help either, if you can hold it is very likely that more of us around could solve your issue
<moqq> okay well thatâs comforting to hear
<perrito666> moqq: though the last link they passed in #juju seems relevant
<moqq> yeah iâve tried as many permutations of the advice on that thread as possible to no avail so far
<natefinch> ericsnow: doing the fixup now.  I noticed your LaunchDetails validate method errored if status is empty.... do we really want to error in that case?  Seems like ID should be required, but status is just a nice to have.
<ericsnow> natefinch: one key motivation for this feature is to display the current status of a managed workload process, so I'm leaning toward always requiring it
<natefinch> ericsnow: fair enough
<natefinch> ericsnow: so, thinking about this some more.. it's somewhat problematic.  We've told the plugin to launch a process, and presumably it has.  It has returned an ID, but no status.... returning an error from Launch would probably make the rest of the system think that no process was launched, even though one was.  I'm worried that'll leave people in a weird state.
<natefinch> ericsnow: I guess the error from launch would cause whatever hook is firing to go into an error state... which might be good enough, since it should only happen at dev time
<natefinch> (hopefully)
<ericsnow> natefinch: that sounds right
<fwereade> yay, I got the most totalitarian rb id yet
<fwereade> http://reviews.vapour.ws/r/1984/
<perrito666> fwereade: loooool
<natefinch> fwereade: double plus good
<mup> Bug #1466984 opened: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
<perrito666> means we had at least that amount of reviews in a year
<natefinch> perrito666: less than a year, really
<perrito666> less?
<perrito666> mm true, was around july right?
<natefinch> perrito666: something like that... I forget exactly when it went live.. .august even, I thought
<natefinch> perrito666: I dunno, it took ericsnow forever to get that thing deployed ;)
<perrito666> I do recall we showcased it in the induction sprint for ericsnow and katco
<ericsnow> natefinch: :)
<perrito666> and at that point it was near the 4th of july because we had this very cool trip to boston with many patriotic things going on
<katco> perrito666: ericsnow: we decided to move to RB at my induction sprint. implementation was that winter.
<katco> perrito666: ericsnow: sometime between oct.-dec.
<mup> Bug #1466984 changed: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
<ericsnow> katco, perrito666: first one (mid-September): http://reviews.vapour.ws/r/18/
<mup> Bug #1466984 opened: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
<natefinch> ericsnow: what do you think about the proc-register command needing to pass the same format as launch returns?  i.e. id and status both in a json blob?
<natefinch> ericsnow: would let us reuse more code and keeps the API consistent
<ericsnow> natefinch: makes sense
<natefinch> ericsnow, katco:  I'm going to have to finish up this merge tonight.... there's just a ton of places where we're using the old process.LaunchDetails that need to be modified to use plugin.ProcDetails.
<ericsnow> natefinch: k
<natefinch> also ericsnow - env_test.go:80: envSuite.TestUnparseEnvOkay    - this is relying on map ordering... you need to use jc.SameContents
<katco> natefinch: k please make sure it gets done
<ericsnow> natefinch: k
<natefinch> katco: I will.  Sorry, been busting my butt, but there was a lot more to the merge than I had hoped.
<natefinch> katco: I have a couple more hours of work time to get it done tonight and I think I'n really close right now.
<natefinch> katco: just gott arun for dinner.. natives are restles
<mup> Bug #1466984 changed: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
#juju-dev 2015-06-20
<mup> Bug #1467037 opened: Cannot remove an environment user with upper case characters <juju-core:New> <https://launchpad.net/bugs/1467037>
<fwereade> jam, if you pass by: did I remember you creating a standard unwrap-tomb.ErrDying-for-worker-loop-invoker-funcs, and if so, where is it?
#juju-dev 2015-06-21
<jam> fwereade: you would remember that we discussed writing something like that, but I don't think we ever actualyl did
<fwereade> jam, ah right :)
<jam> fwereade: what are you doing around now ? :)
<fwereade> jam, taking the opportunity to code a little while (almost) nobody's around ;p
<jam> understood
<fwereade> jam, (although if you fancy reviewing either of my branches (or just conversing on the open issues in the first one) I'd be most grateful
<fwereade> jam, hey, I thought I needed something like this: http://paste.ubuntu.com/11749789/ ...but it turns out it's not quite as simple as that
<fwereade> jam, but that general structure looks very familiar
<fwereade> jam, do you think there's a place for a worker that just serializes ops onto a single goroutine and lets us focus on the op implementation?
<fwereade> jam, possibly I should be calling them commands not ops?
<mup> Bug #1467331 opened: configstore lock should use flock where possible <juju-core:Triaged> <https://launchpad.net/bugs/1467331>
<mup> Bug #1467331 changed: configstore lock should use flock where possible <juju-core:Triaged> <https://launchpad.net/bugs/1467331>
<mup> Bug #1467331 opened: configstore lock should use flock where possible <juju-core:Triaged> <https://launchpad.net/bugs/1467331>
<thumper> wallyworld: https://github.com/juju/juju/pull/2613
<thumper> wallyworld: review board seems to be not picking up new pulls
<wallyworld> thumper: will look after standup
<wallyworld> thumper: lgtm
<thumper> wallyworld: cheers
<thumper> wallyworld: the other thought I had was the 1 second timeout
<thumper> wallyworld: do you think they might be hitting that?
<wallyworld> thumper: which timeout? is that mentioned in the bug report?
<thumper> no... but it is the timeout that that fslock uses
<thumper> the lock is only held during the duration of a read or write of the file
<thumper> so I originally thought 1s should be more than enough
<thumper> however if there are many ops running concurrently, they are serialized through this file
<thumper> so perhas 2s?
<thumper> I'm not sure
<thumper> could just leave it as it is for now
<thumper> I suppose
<thumper> pretty sure we never hit this before
 * thumper asks the bot to merge
<thumper> will forward port to master
<thumper> damn it is going to be cold at the gym
 * thumper psychs himself up
<wallyworld> thumper: yeah leave it for now if we haven't seen it before. but if the system has lots to do. may be a factor. i had to introduce reties to lxc ops due to i/o ontention recently
<thumper> meh, just noticed bug 1464356
<mup> Bug #1464356: TestCloudInit fails <blocker> <ci> <gccgo> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1464356>
 * thumper off to the gym
#juju-dev 2016-06-20
<mup> Bug #1594211 opened: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211>
<menn0> thumper: client side api for the previous PR: http://reviews.vapour.ws/r/5106/
<menn0> thumper: SortStringsNaturally does exactly what I need without modification
<thumper> cool
<menn0> thumper: move it to juju/utils?
<thumper> sure
<wallyworld> menn0: not sure if you care, i left a comment or two on the pr
<wallyworld> i do disagree with declaring the domain object in the api layer
<menn0> wallyworld: ok cheers. i'll take a look.
<mup> Bug #1594232 opened: Inconsistent capitalization in juju command help <juju-core:In Progress by cherylj> <https://launchpad.net/bugs/1594232>
<cherylj> wallyworld: did you and / or axw see bug 1593761 ?
<mup> Bug #1593761: Cannot bootstrap in gce using jsonfile in credentials <add-credential> <blocker> <bootstrap> <ci> <gce-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1593761>
<wallyworld> saw it float past yeah, will need to fix it
<menn0> thumper, wallyworld: the reason that diff is messed up is that I forgot to switch branches when doing this work
<menn0> thumper, wallyworld: that's why the PR description doesn't match the work
<wallyworld> \o/
<menn0> wallyworld: thanks for your comments. I'll address them after I fix something else.
<wallyworld> ok, if you agree
<menn0> wallyworld: in most cases yes. I'm not sure of the value of moving those structs in this case. would you be ok with them being in core/migration?
<cherylj> ok, thanks wallyworld - just wanted to make sure it was on your radar
<wallyworld> menn0: that's where i think they should be yes
<menn0> wallyworld: ok will do that
<wallyworld> cherylj: yeah, not sure when it broke exactly
<wallyworld> menn0: thanks, hopefully you agree with the benefit of managing that domain logic outside of the api layer
<cherylj> wallyworld: ok, I'll take a look tomorrow if it's still needing attention
<wallyworld> cherylj: it probably is broken still, just need to get a minute to look at it
<menn0> wallyworld: well there's no domain "logic" per se, just data.
<wallyworld> but that data is consumed elsewhere
<wallyworld> by other business logic
<menn0> wallyworld: sure
<wallyworld> and the data is migration specific and generally not related to any api concerns
<wallyworld> thumper: the diff is a bit messed up - it claims manifold.go files have been deleted - i'm guessing that's due to cherry picking from master?
<mup> Bug #1570791 changed: ERROR wait: no child processes with juju run on ppc64el <run> <juju-core:Expired> <https://launchpad.net/bugs/1570791>
<thumper> wallyworld: um.. no
<thumper> which manifold?
<thumper> I have just pushed some extra test fixes
<thumper> wallyworld: machinelock worker is entirely deleted
<thumper> as it isn't needed
<wallyworld> ok
<thumper> wallyworld: my machine is currently just taking its time on state and uniter tests
<thumper> but all else now good
<wallyworld> ok, all loos good so far, there will be a lot of happy people with this fix
<thumper> sometimes you forget how far we have come since 1.25
<thumper> geez
<wallyworld> yeah, i can't use 1.25 now :-)
<thumper> hmm 1 failure in worker/uniter
<thumper> looks intermittent
<thumper> trying again
<wallyworld> thumper: lgtm
<thumper> hmm... seems like it might be real
 * thumper digs some
<thumper> ah crap
<thumper> there is a race in this test... I'm sure of it
<thumper> but not one I've added
<menn0> babbageclunk: would you mind taking a look at this? http://reviews.vapour.ws/r/5108/
<babbageclunk> menn0: sure
<menn0> babbageclunk: no rush, just some time during your day
 * menn0 is about to stop again
 * fwereade passes by briefly to say: please, someone, look at http://reviews.vapour.ws/r/5042/ -- it's almost all s/common/facade/ and the only tricky bit is the facade.Factory interface change, which is transparent to almost all the actual facade registrations
<dimitern> frobware: ping
<frobware> dimitern: hi
<dimitern> frobware: hey, so I'm adding tests for --keep-source-stanzas to the bridge script
<dimitern> frobware: and I've realized the TestBridgeScriptWithUndefinedArgs might be wrong
<dimitern> frobware: it looks like we're expecting an error without arguments, but assuming the configFile exists, it actually passes ok
<frobware> dimitern: ahh :(
<dimitern> frobware: and passing "# no config" as config file path doesn't work
<dimitern> frobware: I suggest we drop that test, as we're already testing the 'default prefix' and 'explicit prefix' cases
<frobware> dimitern: ok
<dimitern> frobware: alternatively, we can just fold the 'no prefix' tests into one of the others
<frobware> dimitern: it was always an odd-ball test anyway - you can see that as it's really the only one that doesn't follow the existing pattern
<dimitern> frobware: yeah.. I've refactored runScript to take args struct
<dimitern> frobware: and discovered that
<dimitern> frobware: and it seems the 'default prefix' cases are already testing the 'no prefix' (no args) case
<dimitern> frobware: so dropping the 'undefined args' test is ok
<dimitern> babbageclunk: standup?
<babbageclunk> oops, sorry!
<mup> Bug #1594290 opened: Duplicate key error on juju.txns.stash creating model <juju-core:New> <https://launchpad.net/bugs/1594290>
<dimitern> frobware: updated http://reviews.vapour.ws/r/5087/
<dimitern> frobware: do you think it's ok to land now?
<frobware> dimitern: I was just updating my images to daily and was going to try again
<dimitern> frobware: ok
<frobware> dimitern: the issue with --keep-source-stanzas is that this is now fixed in cloud-init
<frobware> dimitern: can we HO briefly?
<dimitern> frobware: ok
<dimitern> frobware: standup HO?
<frobware> yep
<dimitern> i'm in
<dimitern> frobware: which curtin version was supposed to have the fix?
<frobware> dimitern: 389
<dimitern> frobware: I see curtin/trusty 0.1.0~bzr385-0ubuntu1 all
<frobware> dimitern: yep, you'll need -proposed
<frobware> aim@maas19:~$ dpkg -l |grep curtin
<frobware> ii  curtin                                0.1.0~bzr389-0ubuntu1~14.04.1         all          Library and tools for the curtin installer
<frobware> ii  curtin-common                         0.1.0~bzr389-0ubuntu1~14.04.1         all          Library and tools for curtin installer
<frobware> ii  python-curtin                         0.1.0~bzr389-0ubuntu1~14.04.1         all          Library and tools for curtin installer
<dimitern> frobware: after apt update & full-upgrade, xenial-proposed is enabled
<dimitern> frobware: ooh, sorry this is on my maas 1.9.3 / trusty actually
<frobware> dimitern: I also added http://pastebin.ubuntu.com/17587166/
<frobware> dimitern: and then explicitly installed with -t trusty-proposed to limit the damage
<dimitern> frobware: yeah, just enabled trusty-backports and trusty-proposed, that got me curtin 389
<dimitern> frobware: now updating the images to the dailies, rebooting, then bootstrapping trusty and xenial
<frobware> dimitern: I didn't need dailies
<dimitern> frobware: wanted to make sure everything is up-to-date
<frobware> dimitern: seems like adding to the entropy pool
<dimitern> frobware: well, we'll see :)
<dimitern> frobware: fyi, I'm using commit https://github.com/juju/juju/commit/605940de5f0311a23080bb7ceaad51b370bca4bd#diff-37e8df194cdfac21c9809d60711b5b26 (the equivalent to the one you pasted, but for 1.25)
<frobware> dimitern: yep, good.
<dimitern> frobware: so far I managed to bootstrap on a node with a bond (using balance-alb) and 1 vlan on it, on both trusty and xenial
<frobware> dimitern: so maybe needs real h/w
<dimitern> frobware: however, I wasn't able to bootstrap with mode balance-tlb on xenial, just trusty
<frobware> dimitern: heh, so the other way around. :/
<frobware> wow
<frobware> what a mess
<dimitern> frobware: also in after bootstrap there's no dhclient in sight
<frobware> dimitern: because of curtin 389
<dimitern> frobware: yeah, I think so
<frobware> dimitern: well, you're also using ifdown which will DTRT
<dimitern> frobware: so now what - deploy trusty & xenial without juju on those same nodes, then try running the bridge script manually?
<frobware> dimitern: the interesting case has not arisen (i.e., LACP)
<frobware> dimitern: though the balance-tlb failure on xenial was unexpected
<dimitern> frobware: it did deploy fine (according to maas ui), but no connectivity
<dimitern> frobware: I don't have a 1.9 hw maas anymore, only 2.0
<frobware> dimitern: want to use mine?
<dimitern> frobware: I could, but not sure what that will prove - you can do it more easily anyway..
<frobware> dimitern: true
<frobware> dimitern: I was trying to avoid working on the same issue
<dimitern> frobware: should I try without juju on t & x, then apply the patches to ifenslave / ifupdown, then run the bridge script manually?
<frobware> dimitern: for the balanace-tlb issue?  I would say yes
<dimitern> frobware: ok, I'll change the modes to be balance-tlb on both nodes
<dimitern> frobware: but I need to know what patches to apply
<frobware> dimitern: pick the difs out of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742410 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791906
<dimitern> frobware: ok, looking
<dimitern> frobware: it looks like those two: http://anonscm.debian.org/cgit/collab-maint/ifenslave.git/diff/?id=c4ce52c and http://anonscm.debian.org/cgit/collab-maint/ifenslave.git/diff/?id=d97b18d
<dimitern> frobware: anything else?
<rogpeppe> dimitern: ping
<dimitern> rogpeppe: pong
<rogpeppe> dimitern: hiya
<rogpeppe> dimitern: have you got a moment for a chat, by any chance?
<frobware> dimitern: don't think so
<dimitern> rogpeppe: is it ok if we do it in ~1h?
<rogpeppe> dimitern: sure np
<dimitern> rogpeppe: I'm kinda in the middle of something
<rogpeppe> dimitern: that's fine
<dimitern> rogpeppe: thanks, will ping you then
<rogpeppe> dimitern: ta
<dimitern> frobware: which patches then should I use?
<dimitern> frobware: ah, sorry
<dimitern> frobware: got it, doing it now
<mup> Bug #1594332 opened: Unit reports status about agent before machine is available <juju-core:New> <https://launchpad.net/bugs/1594332>
<frobware> dimitern: actually, given that you do have a failure it would be worthwhile verifying/understanding/experimenting with --no-scripts
<dimitern> frobware: it's worth noting that even though trusty deployment with mode=balance-tlb succeeded, I can see issues
<frobware> dimitern: is that with those patches applied?
<dimitern> frobware: unlike with xenial, where I see no issues, with the trusty node I see considerable lag on the ssh connection
<frobware> dimitern: I thought xenial failed
<dimitern> frobware: no patches yet, but every few keystrokes it appears frozen for a few secondes, then it's ok, then again lagging..
<dimitern> frobware: it failed with juju
<frobware> dimitern: ah, ok
<dimitern> frobware: I'm applying the patches now and trying the bridge script
<babbageclunk> dimitern: What's the apiserver/client package all about? It seems oddly named.
<dimitern> babbageclunk: it's the server-side implementation of the client api facade (i.e. the one used by CLI commands, not using another client api facade, like application)
<babbageclunk> dimitern: Ok, thanks - it seems like that's where I need to add my field to the unit status info.
<dimitern> babbageclunk: unless it's in the status facade?
<dimitern> babbageclunk: well, see what gets used for cmd/juju/commands/status?
<frobware> dimitern: lockfile-create /var/lock/ntpdate --< this is what I seen on trusty and deadlocked/locked/stopped/broken/the-end.
<frobware> dimitern: let me retract that.... ^^
<frobware> dimitern: do you have a version of the script from March but with the reduced iface options?
<babbageclunk> dimitern: ooh, good idea.
<dimitern> frobware: yeah, I was seeing that as well, with more than 1 vlan
<frobware> dimitern: it does eventually go away
<babbageclunk> dimitern: also, another random question - trying to bootstrap against aws, I get this error: ERROR failed to bootstrap model: cannot start bootstrap instance: missing controller UUID
<dimitern> babbageclunk: that's a known bug introduced recently - not sure if it's fixed
<frobware> babbageclunk: this was mentioned on friday. I went back a few commit to make local progress
<dimitern> frobware: what do you mean 'reduced iface options' ?
<dimitern> frobware: the changes moving addresses to the bridge?
<babbageclunk> dimitern: Ah, ok, thanks. Thought it might have been something I'd broken in my config.
<dimitern> frobware: I don't have such version yet
<frobware> dimitern: ok, np
<dimitern> frobware: slightly modified patches with fixed paths: http://paste.ubuntu.com/17589198/ (ifenslave-2.5.patch), and http://paste.ubuntu.com/17589204/ (ifenslave-2.7.patch)
<dimitern> applying now
<frobware> dimitern: dang! Just forget (again!) my 1.9 h/w maas is NOT using curtin 389
<dimitern> frobware: that's why it breaks for trusty w/o juju I guess
<frobware> dimitern: yep
<mup> Bug #1594335 opened: Juju possibly confuses account with credential in add-model <juju-core:New> <https://launchpad.net/bugs/1594335>
<dimitern> frobware: bad news..
<frobware> dimitern: it works? :)
<dimitern> frobware: just the opposite :)
<dimitern> frobware: applying those 2 patches on xenial wasn't quite clean (only 2 hunk out of 6 hunks succeeded, the others were already applied)
<dimitern> frobware: pretty much the same on trusty as well
<dimitern> frobware: however, I rebooted the xenial node and now it never gets out of "Started Raise network interfaces."
<dimitern> frobware: now rebooted the trusty node to see if it will be the same..
<dimitern> frobware: well, I can (barely) ssh after the reboot into the trusty node
<frobware> dimitern: the trouble is we don't know if your really laggy connection is because of an ethernet USB dongle... not acting like a real h/w nuc
<frobware> nic
<dimitern> frobware: the lag I was describing earlier got a lot worse even before the reboot, and it's still there (freezes for about ~10s constantly, ssh feels like on a 300 baud serial link)
<dimitern> frobware: this is purely on kvm - 2 nics on each node, connected to the same bridge (maas internal network)
<frobware> dimitern: oh
<dimitern> frobware: so if anything the patches made things unusable on xenial, and made no difference on trusty
<frobware> dimitern: round and round and round ... :/
<dimitern> frobware: I can try using balance-alb on both an see..
<dimitern> frobware: at this point I don't think running the bridge script will make any difference..
<frobware> dimitern: agreed
<dimitern> frobware: trying with balance-alb on both nodes
 * dimitern steps out for ~30m
 * frobware too - 389 and daily images gives me an eth0.cfg still...
<voidspace>  dimitern: frobware: babbageclunk: an easy one - http://reviews.vapour.ws/r/5110/
<babbageclunk> voidspace, dimitern, frobware: review board's being weird for me - slow requests and losing comments. Anyone else seeing that?
<dimitern> babbageclunk: not today, but I've just started reviewing voidspace's PR now
<babbageclunk> dimitern: Seems to have come right now.
<dimitern> voidspace: reviewed
<dimitern> frobware: so with balance-alb there's no lag on trusty like before, xenial is the same
<dimitern> frobware: however I manged to break everything by running the bridge script after applying both ifenslave patches and rebooting (hug at 'ifdown -a --exclude=lo'); reboot didn't help
<dimitern> frobware: now redeploying and will run the script in a tmux session to let if finish
<dimitern> s/if/it/
<dimitern> rogpeppe: hey, I have some time now if you wanna chat?
<rogpeppe> dimitern: yeah, please
<dimitern> rogpeppe: HO or IRC ?
<rogpeppe> dimitern: i'm in https://hangouts.google.com/hangouts/_/canonical.com/gogogo?authuser=1
<dimitern> rogpeppe: omw
<mup> Bug #1588143 changed: cmd/juju/controller: send on a closed channel panic <blocker> <race-condition> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1588143>
<dimitern> frobware: ping
<frobware> dimitern: pong
<dimitern> frobware: so with the patches the bridge script seems to hang on ifdown --exclude-lo on both xenial and trusty
<frobware> dimitern: :(
<dimitern> frobware: and even though it shouldn't have made any changes, rebooting does not restore connectivity
<dimitern> frobware: instead it gets into 'waiting 120 seconds for network device'
<dimitern> frobware: so I guess the patches are not sufficient (rebooting after applying them causes the same issue, so not related to the bridge script)
<frobware> dimitern: seems so
<dimitern> frobware: perhaps we need to patch more than just ifenslave (and its scripts)
<dimitern> frobware: on xenial, there are /sbin/ifenslave and /sbin/ifenslave-2.6; apt list reports ifenslave is 2.7 (on trusty, as expected - 2.4)
<dimitern> frobware: retrying again, but this time I'll enable console login with 'ubuntu' before I reboot
<dimitern> frobware: so running the bridge script from the console on xenial, after installing bridge-utils (which was missing) worked, connectivity ok, incl. after a reboot
<frobware> dimitern: yeah, the lack of brctl is a pain if you forget
<dimitern> frobware: on trusty (as I didn't install bridge-utils first), no connectivity
<frobware> dimitern: so to be expected
<dimitern> frobware: oops, sorry - so trusty is fine, xenial isn't
<dimitern> frobware: to restore connectivity on xenial, I replace /e/n/i with /e/n/i-before-add-juju-bridge and rebooted
<dimitern> frobware: now it was ok, installed bridge-utils, then ran the script - it was ok, incl. after reboot
<frobware> dimitern: so both t & x == OK?
<dimitern> frobware: interestingly, I see no address on bond0, just on juju-br0 (xenial and trusty both)
<frobware> dimitern: and that's without us removing all the options (e.g., "address") from ENI?
<dimitern> frobware: yeah, now both are working, and no duped addresses
<dimitern> frobware: correct, using the bridge script from https://github.com/juju/juju/blob/605940de5f0311a23080bb7ceaad51b370bca4bd/provider/maas/add-juju-bridge.py
<frobware> dimitern: or is the lack of duplication because you know have curtin doing the right thing?
<dimitern> frobware: the only thing I needed to fix is to use #!/usr/bin/env python3 (on xenial)
<frobware> dimitern: so it's all good -- as in around March Xth it was all good anyway?
<dimitern> frobware: yeah, March, 7th
<frobware> dimitern: we beat release date then :-)
<dimitern> frobware: I'll try now to restore /e/n/i before the script, reboot, then run it with --bridge-prefix=br- to see how it works for the multi-bridge case
<frobware> dimitern: this is my observation too - the only screw up seems to be if you have a LACP bond
<dimitern> frobware: no issues with the multi-bridge case, both t & x
<natefinch> gsamfira: got a a few minutes?  I want to talk about that npipe bug again
<gsamfira> natefinch: sure :)
<dimitern> frobware: so to recap: we need bridge-utils installed (we do that in juju), either apply those patches to ifenslave or install 2.7 or later from ppa, run the script; optionally reboot
<frobware> dimitern: ahh... so I missed the "the patches help" - they do?
<dimitern> frobware: I still think it's good to apply the changes to the script so it renders a cleaner /e/n/i, but no need for fancy dynamic reconfiguring
<frobware> dimitern: so want me to try locally with my LACP config?
<frobware> dimitern: (before we celebrate)
<dimitern> frobware: yes, let's do that
<frobware> dimitern: ok, let's HO to ensure I do this right
<dimitern> frobware: meanwhile I'll try the same, without the patches to see if it's different
<dimitern> frobware: joining standup HO
<natefinch> gsamfira: so here's my thoughts... there's an obvious race condition in the code... that's easily fixable by being more broad with how we use the mutex in the pipelistener.  However, it seems like there may also be the problem we talked about last week, where the pipe gets closed in the middle of an accept from another process or another goroutine that happens to use the same fd but different in-memory pipelistener.  it would
<natefinch> gsamfira: it would seem like the answer to that latter problem might best be described as "don't do that"
<natefinch> gsamfira: as in - maybe the problem is that we're doing that in a test and should not
<gsamfira> natefinch: its not only a matter of doing that in a test. A named pipe can be closed by anyone that has a handle on it. We need a better way to test if the pipe is still open before doing a Connect/WaitForSingleObject on it
<natefinch> gsamfira: there's no way to do that without a race condition
<gsamfira> silly named pipes
<natefinch> gsamfira: silly windows api... it's the waitforcomlpetion call that doesn't have a way to ensure that you're waiting on what you expect you're waiting on.
<gsamfira> natefinch: yeah...unfortunately. We may have to resort to polling...which sucks
<marcoceppi> need help, getting some macaroon error on deploy? http://paste.ubuntu.com/17595425/
<marcoceppi> rick_h_: ^?
<rick_h_> marcoceppi: looking
<rick_h_> marcoceppi: sec, let me ask a couple of questions please
<marcoceppi> rick_h_: ask away
<rick_h_> marcoceppi: sorry, asking the other folks that run the macaroon index of the world
<marcoceppi> cool
<marcoceppi> this is on gmaas if it helps
<rick_h_> marcoceppi: hmmm, shouldn't that I can think of. Shouldn't be unique that is.
<mup> Bug #1594415 opened: Juju register should offer a name for the controller <juju-core:New> <https://launchpad.net/bugs/1594415>
<redir> katco: yt?
<babbageclunk> dimitern: do you know if there's a util somewhere for picking the most common from a set of values?
<dimitern> babbageclunk: most common like how ?
<babbageclunk> dimitern: If I've got 20 units, and 15 of them say they have version 1.2.3, I want to use that as the value (with a * indicating mixed) at the application level.
<mup> Bug #1555815 changed: register allows for controller name confusion <2.0-count> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1555815>
<dimitern> babbageclunk: is this for upgrade-juju --upload-tools?
<dimitern> babbageclunk: or upgrade-charm ?
<babbageclunk> dimitern: no, for status - adding workload version
<dimitern> babbageclunk: I'm not aware of an existing tool you could use.. it should be easy to script it though..
<babbageclunk> dimitern: ok - I've coded it up now.
<babbageclunk> dimitern: It ended up being fairly specific anyway.
<babbageclunk> dimitern, frobware: sorry, can't make it to the network hangout today
<frobware> babbageclunk: ok
<dimitern> babbageclunk: np
<marcoceppi> rick_h_ https://bugs.launchpad.net/juju-core/+bug/1594440
<mup> Bug #1594440: juju gives weird errors about macaroons when a read-only user <juju-core:New> <https://launchpad.net/bugs/1594440>
<mup> Bug #1594440 opened: juju gives weird errors about macaroons when a read-only user <juju-core:New> <https://launchpad.net/bugs/1594440>
<natefinch> cmars: you around?
<katco> redir: here now, what's up?
<bdx> hey whats up guys, is openstack provider currently broken for 2.0?
<bdx> I am finding a bunch of bugs revolving around bootstrapping the openstack provider .... none of them are resolved ... I seem to be hitting the "index file has no data for cloud" no matter what I do .... can anyone give some insight on this? thx
<alexisb> bdx, that we are aware of
<alexisb> bdx, are you working off beta9??
<bdx> alexisb: I haven't gotten a successfull bootstrap of an openstack cloud using any 2.0 yet ...
<bdx> alexisb: yes
<alexisb> :(
<bdx> alexisb: have you personally bootstrapped to openstack provider using 2.0?
<alexisb> bdx, not openstack (I use mostly maas and lxd providers), but we do have passes in testing
<alexisb> not sure if someone else on the channel has personal experience with openstack recently on 2.0
<bdx> alexisb: nice, ok. ... I feel like it must be operator error seeing as no one else is causing a stink about it ...
<bdx> I mean ... pretty straight forward though ..... I get my openstack cloud and credentials added, but get the "index file" error no matter what
<balloons> bdx, are you attempting to bootstrap a charm or bundle on an existing openstack?
<balloons> I want to make clear if you are attempting to deploy openstack itself, or are attempting to use an openstack with juju 2 and deploying applications on it
<bdx> balloons: I have a grizzly stack, liberty stack, and mitaka stack. I have the same issue trying to bootstrap any of them
<bdx> balloons: bootstrap to existing private openstack(s)
<balloons> bdx, can you provide a log of your attempted deployment?
<natefinch> bdx: what's the word after "index file has no data for cloud" ?   That error seems like it's failing to find the cloud in the simplestreams data
<bdx> natefinch, balloons: http://paste.ubuntu.com/17603992/
<natefinch> bdx: seems like a simplestreams issue. Can you manually verify that http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson has a region called RegionOne with that endpoint URL?
<bdx> natefinch: the region is not my openstack "OS_REGION_NAME" ?
<bdx> operator error
<natefinch> bdx: I am not super familiar with openstack setup... so I'm not sure
<natefinch> heh, well I fixed this test hang... evidently it never happens if you just enable verbose output :/
<bdx> natefinch, alexisb, balloons: I think I see what I'm doing wrong, the region specified in clouds.yaml should be a simplestreams region, not an "OS_REGION_NAME"
<bdx> testing this now
<bdx> thanks for your help you guys
<alexisb> bdx, keep us posted if it works
 * natefinch is happy to be a rubber duck whenever needed. :)
<balloons> bdx, :-)
<bdx> aaawwwe
<bdx> it so is not what I thought
<bdx> http://cloud-images.ubuntu.com/releases/streams/v1/index.sjson
<bdx> there is no "openstack" cloud there
<bdx> thats why I think the region must be "OS_REGION_NAME"
<bdx> so, the reason I think the region should be os-region-name is carried over from the region type in 1.x -> http://paste.ubuntu.com/17604538/
<bdx> thats why I think the region must be "OS_REGION_NAME"
<mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
<mup> Bug #1593838 changed: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1593838>
<natefinch> bdx: sounds like it's a documentation and/or naming problem?
<natefinch> (combined with a changed definition from 1.x, without a change to the name)?
<bdx> natefinch: I guess ....
<alexisb> redir, redir_, ping
<cherylj> bdx: there was some bug recently about metadata-source not working
<cherylj> let me see if I can pull it up
<cherylj> bdx: bug 1591488
<mup> Bug #1591488: remove deprecated option --metadata-source <cpe-sa> <juju-core:Triaged> <https://launchpad.net/bugs/1591488>
<cherylj> though, I'm not sure what conversation happened to lead to the conclusion in comment #2
<coreycb> I can't seem to get credentials right for openstack provider with beta9.  anyone have some tips?  http://paste.ubuntu.com/17612374/
<cherylj> coreycb: you'll need to put in some auth-type into your cloud definition in order to add-credential for it.
<cherylj> coreycb: something like this:  http://paste.ubuntu.com/17613239/
<cherylj> lmk if that doesn't work for you
<mup> Bug #1172814 changed: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814>
<mup> Bug #1172814 opened: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814>
<mup> Bug #1172814 changed: Need a way to run an end-to-end test on a juju environment. <testing> <juju-core:Opinion> <https://launchpad.net/bugs/1172814>
<davechen1y> thumper: of all the failed test runs I looked at this morning
<davechen1y> 90% of the are caused by mongo shitting the bed
<thumper> hmm
<davechen1y> http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-xenial-arm64/build-1021/consoleText
<davechen1y> http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-trusty-ppc64el-go1-6/build-793/consoleText
<davechen1y> http://data.vapour.ws/juju-ci/products/version-4076/run-unit-tests-precise-amd64/build-4397/consoleText
<alexisb> thumper, ping
<thumper> coming
<mup> Bug #1594578 opened: state: test failure in race build <juju-core:New> <https://launchpad.net/bugs/1594578>
<mup> Bug #1594580 opened: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1594580>
<alexisb> natefinch, ping
<katco> natefinch: he usually leaves for dinner pretty sharply -46m ago
<marcoceppi> dear core team: http://paste.ubuntu.com/17620137/ this is amazing, thank you!
<anastasiamac> marcoceppi: :)
<anastasiamac> marcoceppi: thank you for feedback \o/
<wallyworld> axw: perrito666: you guys around for standup?
<perrito666> Sorry didn't see that, it's a holiday here
<perrito666> Wallyworld: but if you really need it I can dig up my laptop (and you can explain to my wife next week)
<wallyworld> perrito666: ah, no worries, it's not on the calendar :-)
<perrito666> From your perspective I presume the calendar says the holiday was yesterday
<perrito666> It's still yesterday here
<wallyworld> perrito666: it's not on the juju team calendar
<perrito666> Strange, I'll check before next, now I'll go back to doing nothing
<wallyworld> have fun
<menn0> thumper: easy one: http://reviews.vapour.ws/r/5111/
<menn0> thumper: swapping out the natural sorting implementation in juju for the one in juju/utils
<thumper> looks fine
#juju-dev 2016-06-21
<menn0> thumper: next one (small): http://reviews.vapour.ws/r/5112/
<davechen1y> menn0: re: the conversation we had at standup
<wallyworld> redir: sorry, network dropped
<davechen1y> menn0: increasing the timeout, i'm having trouble finding the place to make that change
<redir> wallyworld: meeting timeout:)
<wallyworld> redir: yeah, sorry, network dropped out
<wallyworld> i think we had finished?
<redir> sure
<redir> I've got enough rope...
<menn0> davechen1y: I was thinking that testWatcher.NumDeltas should be changed to take a timeout
<menn0> davechen1y: and then change the 2 calls to it so that AssertNoChanges passes ShortWait and AssertChanges passes LongWait
<davechen1y> There are millions of AssertNoChanges
<davechen1y> and something about a stringsWatcher
<menn0> davechen1y: the 2 places where NumDeltas is called
<davechen1y> is that a test mock ? or the usual strings watcher
<davechen1y> oh creap
<davechen1y> https://bugs.launchpad.net/juju-core/+bug/1594578
<menn0> testWatcher.AssertNoChange and
<mup> Bug #1594578: state: test failure in race build <juju-core:New> <https://launchpad.net/bugs/1594578>
<davechen1y> I was looking at the wrong bug
<davechen1y> sorry, it should make sense now
<menn0> davechen1y: looks to be a special mock/fake for these tests
<menn0> it's all a bit ropey
<menn0> davechen1y: the whole NumDeltas thing a bit crap... maybe there's a better way.
<wallyworld> thumper: does maas 1.9 support arbitary tags on machines? maas 2 does right - that tag slice on gomaasapi/machine can have anything added to it we want during StartInstance() ?
<thumper> wallyworld: no
<thumper> the tag slice at the moment is maas tags
<thumper> not user defined tags
<thumper> I don't think gomaasapi exposes the user tags yet
<wallyworld> damn ok
<wallyworld> was hoping to add controller uui etc
<thumper> nope
<thumper> sorry
<wallyworld> ok :-(
<wallyworld> still need that provider-state file then
<thumper> for now
<wallyworld> was hoping to avoid an upgrade step
<davechen1y> menn0: wow, AssertNoChange is nuts
<davechen1y> start sync, look, and hope that nothing changed
<davechen1y> so you dn't know if you looked to quickly
<davechen1y> or if nothing happened
<davechen1y> or something else went wrong
<wallyworld> menn0: you got a minute?
<wallyworld> or thumper
<wallyworld> got a migration question
<menn0> wallyworld: hi, yep
<wallyworld> menn0: quick hangout?
<menn0> wallyworld: sure
<wallyworld> https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
<wallyworld> axw: ^^^
<mup> Bug #1594290 changed: Duplicate key error on juju.txns.stash creating model <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1594290>
<davechen1y> menn0: thanks for your suggetiosn
<davechen1y> i have  PR that makes that test a little less crackful
<menn0> davechen1y: awesome. let me know if you need a review.
<thumper> menn0, wallyworld: trivial fix http://reviews.vapour.ws/r/5114/
<wallyworld> ok
<menn0> thumper: double ship it
<wallyworld> thumper: jeez, what a bad assert
<thumper> cheers
<thumper> I'll just backport to 1.25
<natefinch> who wants to review some windows code?  Fun for young and old! https://github.com/natefinch/npipe/pull/21
<natefinch> (also short and easy)
<davechen1y> menn0: allwatcher_internal_test.go:3106: c.Assert(len(d), gc.Equals, 0)
<davechen1y> ... obtained int = 1
<davechen1y> ... expected int = 0
<davechen1y> yay
<davechen1y> i fixed it
<davechen1y> now the other test fails ...
<davechen1y> fml
<menn0> davechen1y: progress! ;-)
<davechen1y> sorta
<davechen1y> also, witness the brilliance of gocheck
<davechen1y> http://paste.ubuntu.com/17630317/
<davechen1y> which of the six calls to AssertNoChange on this page failed ?
<davechen1y> there is a prize if you guess the correct one
<davechen1y> 'cos I sure af don't know
<wallyworld> axw: oh yeah, also, there's currently no exposed method to get the name of the model's cloud that i can see; there's st.Cloud() but that doesn't expose the nme from the cloudDoc
<wallyworld> did we want to use a bespoke struct which maybe embeds cloud.Cloud
<axw> wallyworld: State.ControllerInfo() has it
<wallyworld> ah rightio
<axw> wallyworld: I think we'll end up adding it to Model tho
<wallyworld> i thiknk so yeah
<axw> a new method, CloudName() string
<wallyworld> i'll stick with what we have for now
<natefinch> davechen1y: it's not fair to blame bad tests on the framework.  It would be just as bad with the default test infrastructure
<wallyworld> can iterte
<davechen1y> natefinch: false
<davechen1y> t.Errorf(...) // will print this exact line
<davechen1y> it does mean you cannot write test helpers
<davechen1y> but that was something that rob pike hates
<davechen1y> for reasons that I don't understand
<natefinch> my general approach to tests is that DRY is an extreme anti-pattern in tests.   You want the code right in your face as much as possible.
 * thumper looks at how to reapply a diff
<natefinch> this kind of failure message is one reason why I hate table driven tests. You have to be really really careful about how you code them, or they are super confusing when they fail.  The latest addition to the go test framework makes that significantly better, but not perfect.
<davechen1y> thumper: FUK FUK FUK
<davechen1y> now i've broken the test the other way
<thumper> heh
<davechen1y> AssertNoChange now randomly reports some bullshit results
<thumper> oops
<davechen1y> this is like when you're working on the car
<davechen1y> you;ve got the engine disconnected from the transmission and you discover you need a part from the store
<davechen1y> and you've just taken your car apart
<natefinch> davechen1y: http://www.dailymotion.com/video/x2gp98t
<thumper> wallyworld: http://reviews.vapour.ws/r/5118/ serialization tag reintroduction
<thumper> wallyworld: what did I get wrong last time?
<wallyworld> storagesize
<thumper> wallyworld: can I get you to cast your eyes over the diff
<thumper> and just open issues for all wrong bits?
<wallyworld> yep looking
<thumper> I'll fix before landing
<thumper> cheers
<wallyworld> thumper: diff looks like you got branches mixed up
<thumper> wat?
 * thumper looks
<wallyworld> hmm maybe not
<wallyworld> just saw the first few changes
<wallyworld> looked unrelated
<thumper> no
<thumper> there were issues where the api was doing bad things
<thumper> like using its own structs
<thumper> or passing through state structures
<wallyworld> gawd
<thumper> wallyworld: also, if testing was inside a goroutine
<thumper> I ended up changing the Asserts for Checks
<thumper> because you souldn't assert in a go routine
<wallyworld> yay, good catch
<thumper> full test suite run is running locally for that branch
<thumper> making my fan howl
<menn0> wallyworld: so as fwereade pointed out in a review yesterday, it's a bug that the client side watchers (in api/watcher) could still be doing stuff (like calling the Stop API for a watcher) after the client side watcher has indicated it is done
<menn0> wallyworld: I think I know how to fix it (using catacombs) but it's a non-trivial amount of work
<wallyworld> menn0: which bug? sorry lack context
<menn0> wallyworld: http://reviews.vapour.ws/r/5106/ the remaining open issue
<menn0> wallyworld: the test is even worse than it needs to be because it the Stop call happens in a goroutine that might still be running after the client side watcher is dead
<wallyworld> menn0: i reckon land it and fix later, it's not like this PR introduces the bug
<menn0> the problem is the way commonWatcher (api/watcher) integrates with the specific watcher types
<menn0> wallyworld: i've already landed the PR ... just wondering about fixing the problem in a separate PR
<menn0> I might just do Will's suggestion and have the worker take a watcher constructor
<menn0> and file a bug about the broken watcher behaviour
<wallyworld> sgtm, incremental progress
<menn0> kk
<menn0> wallyworld: thanks for being a rubber duck :)
<wallyworld> quack quack
<natefinch> anyone care to rubberstamp a deps update that fixes a blocking bug? http://reviews.vapour.ws/r/5119/diff/#
<wallyworld> natefinch: lgtm
<wallyworld> thumper: i marked the typo in the pr
<thumper> wallyworld: cool
<davechen1y> thumper: menn0 https://github.com/juju/juju/pull/5676
<davechen1y> took the easy way out
<menn0> davechen1y: looking
<menn0> davechen1y: not sure if that's a good idea
<menn0> davechen1y: that makes the testWatcher.AssertNoChange calls take 10s right?
<menn0> if the code is behaving correctly and there is in fact no change
<menn0> davechen1y: that's why I was suggesting that there might need to be a more invasive change
<menn0> davechen1y: maybe NumDeltas should go away, and AssertNoChange and AssertChange should have independent implementations
<davechen1y> menn0: i tried that
<davechen1y> it jsut make a mess
<davechen1y> i did that
<davechen1y> menn0: http://paste.ubuntu.com/17632486/
<davechen1y> now AssertNoChange fails reliably ... :(
<menn0> davechen1y: hmmm
<menn0> davechen1y: i'm not exactly sure what's happening there
<menn0> davechen1y: is len(d) > 0 when a change is detected?
<menn0> (where d is the actual deltas)
<davechen1y> yup
<davechen1y> if there is no change, then nothing should be deliverd on tw.delta
<menn0> davechen1y: could it be that there's deltas not being completely consumed from the previous change?
<menn0> davechen1y: FWIW I'm pretty sure AssertChanges in your diff should be using LongWait, not ShortWait
<davechen1y> menn0: this is all rubbish
<davechen1y> make a chage
<davechen1y> wait to see if anything happened
<davechen1y> maybe something happened, maybe didn't wait long enough
<davechen1y> reverse the logic for _not_ expecting a change
<davechen1y> there is no synchonisation, only waiting
<davechen1y> i'm amazed this works at all
<menn0> welcome to watchers
<davechen1y> what a bunch of bollocks
<mup> Bug #1594663 opened: Client side watchers may still be active when they report themselves as dead <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1594663>
<mup> Bug #1594665 opened: reboot-executor is missing from the list of workers <juju-core:New for fwereade> <juju-core model-migration:New> <https://launchpad.net/bugs/1594665>
<menn0> thumper or wallyworld : addresses an issue fwereade raised in a previous PR: http://reviews.vapour.ws/r/5106/
<wallyworld> ok
<menn0> wallyworld: sorry, wrong PR: http://reviews.vapour.ws/r/5121/
<wallyworld> tis ok, found it already
<menn0> wallyworld: at least it was the one where fwereade raised the issue :)
<wallyworld> menn0: i just had a quibble / question about end-end test coverage, but it does look far less complicated
<menn0> wallyworld: and I don't think we really lost any coverage here... the API call was fake before
<menn0> wallyworld: it's just avoiding testing stuff that is actually in another package and tested there
<wallyworld> rightio
<menn0> wallyworld: agreed on the end-to-end test. there will be a feature tests added, and CI tests of course, as everything comes together
<wallyworld> sgtm
<menn0> wallyworld: veebers is on the case with the CI test
<wallyworld> \o/
<davechen1y> menn0: this is terrible
<davechen1y> menn0: thumper https://github.com/juju/juju/pull/5678
<davechen1y> attempt #2
<frobware> dimitern: want to skip 1:1? I want to go through some of the things we discussed with jay last night before standup.
<dimitern> frobware: sure, np
<dimitern> frobware: I've picked up bug 1594580 anyway
<mup> Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580>
<frobware> dimitern: one useful tidbit is: sudo cat /proc/net/bonding/bond0
<frobware> dimitern: the info in there (and must run as root) tells you whether the LACP setup actually happened.
<dimitern> frobware: that's useful to know indeed!
<menn0> davechen1y: reviewed
<dimitern> frobware: I've decided against trying to set up bonding on the nucs for now
<frobware> dimitern: makes sense in absence of h/w :)
<dimitern> frobware: yeah :)
<frobware> dimitern: I woild not suggest the nuc I bought - too slow and the lack of AMT is a pain
<dimitern> frobware: what cpu did it have? dual-core celeron?
<frobware> dimitern: yep, though it may have threads, so 4.
<dimitern> frobware: but still.. celeron :)
<davechen1y> menn0: thanks, i'll try to integrate some more "wait this long, max" logic
<menn0> davechen1y: cool
<axw> wallyworld: this change I'm working on is excruciating, and unlikely to be ready by beta10. I think I'll take a break tomorrow and fix some of the bugs raised on beta9
<axw> and when I say "unlikely", I mean "almost certainly not"
<anastasiamac> axw: is this json for gce?
<axw> anastasiamac: not working on that yet, will probably look tomorrow
<axw> anastasiamac: hve been looking at some fundamental changes to model config / cloud / credential separation
<anastasiamac> axw: k. thnx \o/
<mup> Bug #1594720 opened: 2.0 b9: Fail to deploy LXD container in restricted network <juju-core:New> <https://launchpad.net/bugs/1594720>
<jam> dimitern: voidspace: standup
<jam> ?
<dimitern> sorry, omw
<babbageclunk> dimitern, voidspace: hmm - why didn't this PR get a review created? Is it because I ended with a comment in parens? https://github.com/juju/juju/pull/5679
<voidspace> babbageclunk: no idea...
<voidspace> babbageclunk: ask ericsnow when he comes online
<voidspace> babbageclunk: every now and then this happens
<babbageclunk> voidspace: ugh, that's ages away
<voidspace> babbageclunk: yep
<babbageclunk> voidspace: I'll try a little chicken-slaughtering to see if that helps.
<babbageclunk> voidspace: Yeah! I'm the boss of computers!
<babbageclunk> voidspace: I mean, it could just have been a coincidence, but that superstition is sticking from now on!
<TheMue> morning
<babbageclunk> dimitern, voidspace, frobware: reviews welcomed! http://reviews.vapour.ws/r/5123
<dimitern> babbageclunk: I'll have a look in a bit
<babbageclunk> dimitern: cool thanks - no big rush
<babbageclunk> niemeyer1: ping?
<voidspace> babbageclunk: heh, I didn't realise chicken sacrifices helped
<voidspace> babbageclunk: I don't have any chickens but I do have two children, maybe I could spare one of them...
<babbageclunk> I think children are worth between 5-10 chickens.
<voidspace> babbageclunk: so worth waiting for a really serious bug
<voidspace> babbageclunk: hmmm... I wonder if sacrificing both would fix our issues with /en/n/i
<voidspace> might actually be worth it...
<voidspace> we can always grow some more
<babbageclunk> voidspace: tsk
<frobware> voidspace: well, no chickens or children needed. A sleep of 0.5s between ifdown/up seems to cure it. \o/
<babbageclunk> frobware: yay!
<babbageclunk> frobware: that's better than a 10min reboot.
<frobware> babbageclunk: give or take, about 10mins. :)
<frobware> babbageclunk: I cut & paste the commands we run and ran them "by hand" in the shell.. it was then I noticed that it worked. Put the same commands back in a shell script and it all fails.
<babbageclunk> frobware: dumb computers doing stuff too fast for themselves.
<frobware> babbageclunk: agreed. if we would all slow down we'd get there faster :P
<voidspace> frobware: that's great
<mup> Bug #1571053 opened: container networking lxd 'invalid parent device' <ci> <lxd> <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1571053>
<natefinch> cherylj: have a bug you'd like me to work on?
<cherylj> natefinch: Of course!  Want to take a look at bug 1593299 ?
<mup> Bug #1593299: HA recovery fails in azure <azure-provider> <blocker> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1593299>
<natefinch> cherylj: I figured that might be your answer, being the only blocker not in progress.  Sure thing.
<cherylj> I'm sorry I'm so predictable
<cherylj> ;)
<natefinch> :)
<natefinch> oh azure, that special flower...
<frankban> cherylj: hi, do you know more or less when master will be unblocked so that I can merge a couple of little contributions I have?
<cherylj> frankban: if you send me the PRs, I'll evaluate and merge it for you
<frankban> cherylj: http://reviews.vapour.ws/r/4936/ and http://reviews.vapour.ws/r/5124/ (though the latter could wait for another review)
<mup> Bug #1571053 changed: container networking lxd 'invalid parent device' <ci> <lxd> <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1571053>
<alexisb> frobware, just need a few minutes for a cup of coffee
<alexisb> brt
<dimitern> frobware, voidspace: a tiny-ish review fixing bug 1594590, please take a look - http://reviews.vapour.ws/r/5125/
<mup> Bug #1594590: [needs packaging] arc-theme <Ubuntu:In Progress by fossfreedom> <Debian:New> <https://launchpad.net/bugs/1594590>
<dimitern> oops not that one
<voidspace> dimitern: I don't believe you ever produce small reviews
<voidspace> but I'm willing to be surprised
<dimitern> voidspace: :) you might be surprised
<dimitern> let's try again mup.. bug 1594580
<mup> Bug #1594580: lxd container invalid parent device name <blocker> <bundles> <ci> <lxd> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1594580>
<cherylj> frankban: I kicked off the merge for the first PR.  Let me know when you get another review for the second
<natefinch> OMG https://jujucharms.com/docs/devel/help-azure
<natefinch> sudo apt-get install -y nodejs-legacy npm
<natefinch> WTF
<frankban> cherylj: ty!
<cherylj> natefinch: you can grab the CI creds and not have to do all that
<voidspace> dimitern: LGTM
<natefinch> cherylj: thanks... I have azure set up from forever ago, so in theory, I just need to grab those values off the website or something... it's just... do we really expect someone to follow this 15 (yes, I counted) step process
<dimitern> voidspace: cheers!
<frankban> perrito666: could you please take a look at replies at http://reviews.vapour.ws/r/5124/ ? what do you think?
<perrito666> frankban: I see, well we can always change if we need something else in the future, as roger says
<frankban> perrito666: so can I go ahead and ship it?
<perrito666> frankban: you have a shipit from roger :p he just forgot to click the button
<perrito666> frankban: is master unlocked?
<frankban> perrito666: no, I'll handle that, I'd like to have a ship it from a core dev
<perrito666> frankban: sure, ship it
<perrito666> (I added the shipit to the pr)
<frankban> perrito666: thanks
<mup> Bug #1594855 opened: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:New> <https://launchpad.net/bugs/1594855>
<katco> ericsnow: standup time
<cherylj> natefinch: would you be able to port your fix for bug 1581157 to 1.25?
<mup> Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157>
<dimitern> cherylj: hey, re 1.25.6 - still planned to ship tomorrow?
<natefinch> cherylj: yeah. it's just a deps change
<cherylj> thanks, natefinch
<cherylj> dimitern: I don't think it'll be tomorrow
<cherylj> dimitern: but we should try for this week
<dimitern> cherylj: ok, cheers
<cherylj> dimitern: are you asking for bug 1594855?
<mup> Bug #1594855: MAAS provider bridge script on trusty does not handle LACP bonds <addressability> <maas-provider> <network> <trusty> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1594855>
<dimitern> cherylj: yeah, exactly :)
<dimitern> cherylj: it's affecting a customer
<mup> Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
<cherylj> dimitern: k, do you have an ETA on the fix?
<dimitern> cherylj: likely tomorrow - frobware is testing a fix already
<dimitern> cherylj: we've (more or less) established the root cause at least
<cherylj> ok, cool
<cherylj> dimitern: did someone ask you about bug 1590598 too?
<mup> Bug #1590598: ipv6 interfaces configured on a machine (in maas) are not added to lxc containers deployed to that machine <sts> <juju-core:Confirmed> <MAAS:Invalid> <https://launchpad.net/bugs/1590598>
<dimitern> cherylj: nope, looking..
<cherylj> dimitern:  you had a comment in there that "we'll address this soon", and wanted to know if this was still on your radar
<dimitern> cherylj: ah, I remember this one
<dimitern> cherylj: yeah, it's a known limitation atm
<cherylj> dimitern: is it something we want to commit to for 2.0?  or does it need more time and should be deferred to 2.1?
<dimitern> cherylj: I'd say 'good to have for 2.0', but realistically - 2.1
<cherylj> dimitern: is it large enough that it needs to be sized and budgeted for (headcount wise)?
<dimitern> cherylj: it's not inherently difficult, there are more serious issues we're focusing on first
<cherylj> dimitern: k, thanks
<mup> Bug #1593838 changed: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
<mup> Bug #1593838 opened: juju beta9 does not support "lxc" notation in bundles <blocker> <bundles> <cdo-qa> <cdo-qa-blocker> <ci> <regression> <juju-core:Fix Committed by natefinch> <https://launchpad.net/bugs/1593838>
<mup> Bug #1594865 opened: 2.0 beta8: deployment with sphere as provider - bootstrap node - no space left on /  <oil> <juju-core:New> <https://launchpad.net/bugs/1594865>
<natefinch> cherylj, sinzui: where are the juju 2.0 CI credentials for azure stored?  In cloud-city somewhere, I presume?
<cherylj> natefinch: yeah, in cloud-city
<cherylj> natefinch:  need a refresher on how to access?
<natefinch> cherylj: no... I just forgot I hadn't updated my branch of it in like a year
<natefinch> cherylj: credentials.yaml looks promising :)
<sinzui> natefinch: cloud-city, look in credentials.uaml
<natefinch> ahhhh azure is so slow
<natefinch> whoever added model/controller/cloud/version to juju status, thank you!
<natefinch> cherylj: do you know who did the updates to juju status?  looks like it's fixed in current master, but the bug hasn't been updated: https://bugs.launchpad.net/juju-core/+bug/1571792
<mup> Bug #1571792: Juju status should show controller and model names <juju-release-support> <rc1> <status> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1571792>
<cherylj> natefinch: that was thumper, I think
<mup> Bug #1594875 opened: Please alias 'relate' to 'add-relation' <juju-core:New> <https://launchpad.net/bugs/1594875>
<tvansteenburgh> wallyworld: you around?
<tvansteenburgh> wallyworld: i'm working on getting jujuclient working with beta9. looks like top-level status keys were switched to lowercase, is that right? is it only the top level keys?
<tvansteenburgh> anyone else know? ^
<tvansteenburgh> nevermind, i think i found the answer
<mup> Bug #1594883 opened: initial juju status is really ugly <status> <juju-core:New> <https://launchpad.net/bugs/1594883>
<alexisb> tvansteenburgh, you should have a mail in your inbox that provides some input, thumper can provider more backgroun to qs when he comes online
<alexisb> natefinch, thank you for  you input on lp 1594883
<tvansteenburgh> alexisb: thanks
<rogpeppe1> here's a fun review if anyone wants to take a look: https://github.com/juju/juju/pull/5684
<rogpeppe1> it adds redirect support when making API connections
<perrito666> Rogpeppe1 I'll review after lunch
<alexisb> rogpeppe1, for your PR, did you work with anyone on the techboard, or someone else on the core team?
<mup> Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
<mup> Bug #1594924 changed: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
<mup> Bug #1594924 opened: resource-get is painfully slow <juju-core:New> <https://launchpad.net/bugs/1594924>
<ejat> axw: r u there
<perrito666> bbl
<Yash1> katco: Hey :)
<katco> Yash1: o/
 * redir steps out for some air. bbiab.
<aisrael> sinzui: Do you know if it's possible for the juju devel ppa to keep copies of previous beta versions? In this case, I need to rollback to beta 8 in order to run bundletester, but I autoremove'd my apt cache after upgrading to beta 9.
<sinzui> aisrael: debian/ubuntu does not permited
<sinzui> aisrael: users can copy packages to less volitile ppas
<sinzui> aisrael: for CI, we keep a copy of all the clients we release so we can do compatability testing
<natefinch> aisrael: you can always just copy the binaries to a new folder. put them in a beta8 directory or something
<aisrael> sinzui: natefinch: is there a way I can get a copy of the beta8 release then?
<aisrael> I'll start backing them up from now on. :)
<natefinch> sinzui: do we store the linux binaries somewhere?  I see centos and osx and windows on launchpad, but not linux
<natefinch> er not ubuntu
<sinzui> aisrael Lp has a record of most of what it historically built. I think this helps https://launchpad.net/~juju/+archive/ubuntu/devel/+packages?field.name_filter=juju-core&field.status_filter=superseded&field.series_filter=
<sinzui> natefinch: QA team stores all clients we release to do client compatability testing.
<aisrael> sinzui: That's perfect, thanks!
<mup> Bug #1594958 opened: Bootstrapping on OpenStack fails with juju 2 <juju-core:New> <https://launchpad.net/bugs/1594958>
<natefinch> it's kind of amusing that we have different builds for different ubuntu series.. as if they're actually any different.  If the go tool did it right, they'd probably be bit for bit identical/
<perrito666> its the debian way, which is in the exact oposite of static binary compilations
<natefinch> hell, the CentOS one I'm sure is also identical.  It runs just fine on my machine.  Go doesn't care what flavor of linux you're compiling on
<perrito666> mm, what is the API call to delete a model
<natefinch> hmm... kill-controller is kind of a confusing command when you're in HA
<natefinch> I guess if you think of it like the cluster is the controller, not each machine is a controller
<natefinch> sigh... naming is hard
<wallyworld> katco: ericsnow: quick catch up?
<wallyworld> https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
<katco> wallyworld: brt
<thumper> anyone want this? http://reviews.vapour.ws/r/5129/diff/#
<perrito666> thumper: rb just display errors
<thumper> because it doesn't show deletions well
<thumper> summary says deleted
<perrito666> yes github says so too :-
<perrito666> :p
<perrito666> ship it
<mup> Bug #1594977 opened: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
<mup> Bug #1594977 changed: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
<bdx> hey whats up guys? - Quick question, will there be a 'destroy-machine' command in the future?
<mup> Bug #1594977 opened: juju-1 bootstrap forgets about  metadata-source argument <v-pil> <juju-core:New> <https://launchpad.net/bugs/1594977>
<bdx> On that, would it be wise, or confusing to refactor references to "DestroyMachine" or "DestroyedMachines" or whatever variation of 'destroy machine' to a similar variation of 'remove machine'?
<thumper> bdx: there will be a command that removes a machine
<bdx> thumper: you mean "destroys"
<thumper> I think we called it 'remove-machine'
<thumper> destroy was always an alias
<thumper> we went for naming consistency
<bdx> I see, yea
<bdx> so should references in the code base like "DestroyMachine" be refactored to "RemoveMachine" ?
<bdx> 'destroying' machine operations are carried out by the code, but 'destroying' a machine is not a user facing command?
<bdx> thumper: what I'm getting at is the inconsistency between destroy-machine ops in the codebase, and the fact that destroying a machine isn't really an operation that can be performed
<bdx> thumper: should "destroy-machine" references in the codebase be refactored to "remove-machine", also the naming of the functions and classes that reference "destroying" a machine ...?
<thumper> not entirely sure right now, my head is elsewhere
<cherylj> menn0: thank you for the review! :)
<menn0> cherylj: No problems. I confess to not checking every single change in detail.
<cherylj> ha, I won't tell
<wallyworld> axw: perrito666: be right there
<perrito666> going
<anastasiamac> wallyworld: axw: there too :)
<perrito666> menn0: thumper any of you know off hand what is the API call to delete model?
 * wallyworld has coffee emergency, bbiab
#juju-dev 2016-06-22
<menn0> perrito666: do you mean the DestroyModel method on the Client facade?
<perrito666> menn0: ah, Its there, that explain, I was looking for it in ModelManager
<perrito666> menn0: tx a lot
 * perrito666 takes a moment to learn how to use expensify
 * perrito666 fails
<menn0> thumper: rogpeppe1 has a PR up to do API login redirection. I haven't looked in detail yet but it looks like what we also need for migrations.
<wallyworld> menn0: any reason why destroy model is not on model manager facade?
<wallyworld> or should not be?
<axw> wallyworld: can talk now if you're free
<wallyworld> sure, let's. standup ho will do
<menn0> wallyworld: no idea. I had very little to do with that. thumper/
<thumper> um... yes
<thumper> there was a good reason
<axw> anastasiamac: #1167616 is still valid
<mup> Bug #1167616: state.SetEnvironConfig should take old and new config values <config> <state> <juju-core:Triaged> <https://launchpad.net/bugs/1167616>
<axw> there's a TODO in the code
<thumper> it had more to do with who could call it
<wallyworld> natefinch: 1 minute late
<thumper> but perhaps that isn't a great reason
<thumper> but it made sense at the time
<axw> thumper: only admins can use the controller facade, right? but shouldn't a non-admin model owner be able to destroy their own model?
<thumper> axw: they can
<thumper> through the client facade
<thumper> the controller facade allows admins to kill other people's models
<axw> I see
<axw> IMO we should have it on modelmanager, but just do an auth check if auth-user != owner
<wallyworld> exactly
<axw> check if they're an owner, or a controller admin
<wallyworld> and now is the time to make that breaking change. the gui guys will love us
<axw> wallyworld: I already broke the ability to create new models, so seems like a good time to change it :)
<axw> can't destroy if you can't create
<wallyworld> :-)
<thumper> do it before beta 10
<thumper> then they can't really complain more
 * menn0 is drowning in reviews
<menn0> wallyworld: I'm looking at http://reviews.vapour.ws/r/5126/
<wallyworld> menn0: sorry :-(
<menn0> wallyworld: post-bootstrap will there be any way to change the cloud config stored in the controller?
<wallyworld> menn0: yes, there will be a command but not done yet
<menn0> wallyworld: ok cool
<wallyworld> menn0: note that mdels fork (copy) the common config so changing will only affect new models
<menn0> wallyworld: that was going to be be my next question :)
<wallyworld> in effect, there's no user visiblw change with this work currently therefore
<menn0> wallyworld: so if you had something like http-proxy set on a bunch of models
<wallyworld> ie stuff works for the user the same as now, except that they don't need to use --config for the shared stuff
<menn0> wallyworld: and you wanted to change it
<wallyworld> ypu'd need to change all models
<menn0> wallyworld: you would have to change it on all the existing models
<menn0> ok
<menn0> wallyworld: will there be a way to do a mass change across all models?
<wallyworld> last week it was inherited, but that got nixed
<wallyworld> the ux will need to be discussed, yes
<menn0> wallyworld: I guess it's easier to understand if there's no inheritance
<wallyworld> exactly
<wallyworld> menn0: https://docs.google.com/document/d/1PWUwx9kITQajQQgvHnweUuqTGmBo9p35bVwd-uLKAi4/edit?ts=57626636#heading=h.ppor8yz4jan0
<wallyworld> that's from mark
<menn0> (well it's prototypical inheritance I guess)
<wallyworld> there will be various sources of shared config
<wallyworld> right now, we've just the 2 of them
<wallyworld> menn0: i have to pop afk for 30 minutes to relocate (long story), will be online again in a bit
<menn0> wallyworld: no problems. you've answered my questions. that doc helps too.
<wallyworld> excellent
<davecheney> menn0: i've fixed your review comments and stress tested my patch
<davecheney> i'm going to try landing it
<menn0> davecheney: awesome
<natefinch> ahh full stack external tests... change one line of code, get 4 tests failing in incredibly obscure ways
<wallyworld> axw: i can't do the settings write and model source updates in one txn - the settings is a separate struct which completes in own work before existing
<wallyworld> settings.Write()
<natefinch> wallyworld: well, that fix worked perfectly well in a manual test, but it breaks 4 tests in bizarre ways.
<axw> wallyworld: settings.Write() is implemented in terms of txn.Ops...
<wallyworld> it is, but it's a method on a separate struct with its own semantics
<axw> wallyworld: so if you split the txn.Op building from transaction running, you can do them in one transaction
<wallyworld> that breaks encapsulation
<axw> wallyworld: so? you can still compose transactions. they either all run or none
<natefinch> wallyworld: we don't have any other way to compose multiple actions into a transaction
<wallyworld> so in this case, there's no harm spliting them as per my comment in the code
<axw> wallyworld: we're inside the package, there's no encapsulation. having an inconsistent model is worse than exposing the ops
<natefinch> we should really have most of our actions like this returning ops rather than running their own transaction
<wallyworld> natefinch: so you'll just have to fix the tests i guess
<wallyworld> except when we want to provide a fully encapsulated access to state
<axw> wallyworld: nobody's suggesting we expose ops *outside* of state. I'm saying that UpdateModelSettings should either update the settings *and* the sources, or *neither*
<axw> if we update the settings and then later the sources, we leave ourselves open to having lies in the model
<wallyworld> ok, i'll need to break apart settinsg.Write()
<wallyworld> moving ModelDestroy() off client is a pita - all the call sites in shared code use *state.State instead of interfaces, sigh
<natefinch> I spent a lot of time fixing service creation and unit assignment so that we can't get into an inconsistent state.... and there's still some improvements to make... but the most obvious takeaway was that returning ops is composable, and hiding the ops is not.  Hopefully they can be encapsulated into a single state method call, so no one outside of state needs to worry about it... but inside of state... defaulting to returning ops rather than
<natefinch> executing a transaction should probably be the default for most code.
<axw> wallyworld: I've been looking at the GCE issue, and it's a bit of a pain. the issue is that we assume there's a one-to-one mapping between credentials.yaml contents and credentials in model config
<axw> wallyworld: so not sure what I should do. it will be fixed hwen my in-progress stuff is done, but that's a ways off
<wallyworld> natefinch: yeah, so long as we are on mongo it seems that's what we must do
<axw> wallyworld: there's a workaround: don't use jsonfile
<wallyworld> axw: damn. using json file will be the most common case, especially when people use autoload
<wallyworld> i wonder if we can special case something for beta 10
<axw> wallyworld: perhaps, just wondering if it's worthwhile expending the effort.
<wallyworld> axw: the issue AFAICT is that our users would be using autoload-credentials mostly
<wallyworld> and they will be screwed with this beta
<axw> wallyworld: I'll fix the empty auth-types one, and then come back to this
<wallyworld> ok
<thumper> wallyworld: hi ho
<wallyworld> yo
 * wallyworld relocating back home, bbiab
<natefinch> axw: I made a tiny change to the azure provider's StartInstance to fix a bug Ian had added to it when he split out the controller config... and now I'm getting this weird test failure (and 3 others similar to it): http://pastebin.ubuntu.com/17679429/
<natefinch> axw: any ideas what is going on?  The bug was that we weren't setting the apiport unless it was during bootstrap, which obviously falls down for machines added for HA: https://github.com/juju/juju/pull/5590/files#diff-8a18f1cda410ddced1438bf9bc8e8eb9R476
<natefinch> axw: I just don't understand the error from the test
<natefinch> wallyworld: do you understand the azure tests?
<wallyworld> have never looked at them
<wallyworld> axw does
<wallyworld> you getting failures right
<natefinch> yeah
<natefinch> wallyworld: http://pastebin.ubuntu.com/17679429/
<natefinch> that's one of them... the others look pretty similar, so probably same root cause
<wallyworld> my guess off the top of my head is that the test does not set apiport in start instance params
<wallyworld> hence the correct security groups are not created
<wallyworld> but just a guess
<menn0> thumper: http://reviews.vapour.ws/r/5132/
<mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
<axw> natefinch: sorry was having lunch, reading backlog now
<axw> natefinch: the azure tests set up a list of expected requests. they're not matching. you'll probably need to modify some calls to "startInstanceSenders" to pass true instead of false
<axw> natefinch: i.e. that a controller instance is being started
<natefinch> axw: oh yes, I see
<natefinch> axw: though I don't really understand why that needs to change due to the change I made to the code
<axw> natefinch: if you push the change I'll take a look, if you like
<natefinch> axw: https://github.com/natefinch/juju/commit/3534aa71f7aac1eb364ecdb32e51e3c8220c163e
<axw> natefinch: we shouldn't be doing it unless it's a controller. so check "else if args.InstanceConfig.Controller != nil"
<axw> natefinch: possibly we can ignore the Bootstrap case, I forget if APIInfo is set at bootstrap time
<axw> natefinch: if it is, we should do that
<mup> Bug #1589774 opened: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
<natefinch> mna, I hate the way we use pointers in our config options and you just have to know if they're expected to be nil or not
<mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
<wallyworld> axw: there's other places in the code where we use that args.InstanceConfig.Bootstrap != nil check - they all probably need to be cleaned up a bit
<wallyworld> some do use the isController() check
<axw> wallyworld: quite possibly. I think in some cases it is valid, e.g. in gce I think we set up a firewall rule that applies to all machines in the model
<mup> Bug #1594211 changed: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211>
<wallyworld> axw: yeah, i think it's just a 2 i did - ec2 and openstack. i'll do a drive by in the current pr
<wallyworld> *this
<natefinch> wallyworld: we really should put helper methods on that struct, rather than relying on institutional knowledge of what it means for one of the values to be nil or non-nil
<wallyworld> no argument there, is tech debt
<wallyworld> axw: you even have a todo in the rwckspace proviser
<wallyworld> damn, can't type
<axw> wallyworld: yeah it was broken before I think?
<wallyworld> i think so
<axw> I think I added a bug for it
<wallyworld> axw: i'll fix now and push to the model config pr so we can get it landed
<natefinch> axw: thusly? http://pastebin.ubuntu.com/17681411/  Also, do we need to check the length of ports or is it safe to assume it's non-empty?
<axw> natefinch: it should always be one-and-only-one. I just noticed that instancecfg.ControllerConfig's Config field has an APIPort() method tho, that's probably more appropriate to use
<axw> wallyworld: is ^^ set at bootstrap time?
<axw> (I think it should be, if it's not)
<wallyworld> axw: i think so, i'm double checking now
<wallyworld> as i am doing
<wallyworld> 		if isController(args.InstanceConfig) {
<wallyworld> 			apiPort = args.InstanceConfig.APIInfo.Ports()[0]
<wallyworld> 		}
<wallyworld> i deleted the bootstrap bit
<natefinch> wallyworld: I tried that and get index out of range at bootstrap.. ports is zero-length
<natefinch> wallyworld: at least in the azure tests
<wallyworld> the tests may not set things up correctly
<axw> wallyworld: tests probably need updating, but I was talking about args.InstanceConfig.Controller.APIPort()
<axw> sorry, Controller.Config.APIPort()
<wallyworld> jeez we have so many bit of duped data
<axw> tell me about it
<axw> natefinch: I think you just want this: http://paste.ubuntu.com/17681608/
<axw> err, you'll need to assign and take pointer, but you get the idea
<wallyworld> axw: yeah, that should work with the recent landing the past few days
<natefinch> axw: ControllerConfig doesn't have a Config field
<natefinch> unless I'm out of date?
<axw> natefinch: must be, it's there on master
<natefinch> ha, I guess I anm
<axw> https://github.com/juju/juju/blob/master/cloudconfig/instancecfg/instancecfg.go#L160
<axw> wallyworld: your branch LGTM, let me know when you've added the fixes
<wallyworld> ty, testing live on aws now
<natefinch> -y
<natefinch> I have to run to bed.  The tests pass, but I don't have time to do a manual test right now... also we should probably add a test that'll ensure this doesn't break again, but I have no clue how to do that with the code as is.
<natefinch> will do more manual tests in the morning and see if I can put a unit test in there to catch this if it breaks again.
<mup> Bug #1559299 changed: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Invalid> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
<mup> Bug #1575940 changed: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
<mup> Bug #1482074 changed: worker:  environSuite.TestInvalidConfig fails on go 1.6 <ci> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1482074>
<mup> Bug #1581579 changed: resource-get fails with duplicate key error <juju-core:Incomplete> <https://launchpad.net/bugs/1581579>
<mup> Bug #1588784 changed: juju/state: intermittent test failure in SubnetSuite with mongod 3.2 <mongodb> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1588784>
<wallyworld> axw: pushed, i tested enable-ha on ec2. i also changed azure with no failing tests, not sure what nate was seeing
<axw> wallyworld: reviewed
<wallyworld> ta
<wallyworld> axw: i hit the commit button too soon, that error is fixed. i'll remove the IsController helper - that was there i guess before we had a Controller attribute and had to check jobs
<wallyworld> axw: i'm down a rabbit hole with moving DestoryModel() to apiserver/modelmanager. all the stuff in common.modeldestroy.go uses state.State and the tenticles reach into metrics and everywhere. i may have to type cast the api.state attribute on modelmanager facade to state.State for now
<urulama_> wallyworld, axw: good evening ... looking at what perrito666 mentioned as a breaking change. is there anything else besides https://github.com/juju/juju/commit/9933a39c799639084bd822ea3ee8e6345131bac7 ?
<wallyworld> urulama: well hello. another change we discovered today - i am looking to move DestroyModel() off the client facade onto the ModelManager facade.
<wallyworld> i didn'tt hink you wer ehere today?
<urulama> wallyworld: i am just happy to have 2 days off :D
<wallyworld> that destoy model api is the only one on the client facade, it just should not be there
<wallyworld> we have create and list model on the model manager facade already
<wallyworld> 2 days off, luxury
<axw> wallyworld: there's also a breakage of the CreateModel API call, which I've mailed Francesco about
<axw> err urulama^^
<axw> urulama: would you like me to forward the details to you?
<wallyworld> axw: i did already :-)
<axw> ok cool
<urulama> ok, thanks, will sync with frankban|afk ... see, even 2 days off is a risk! :D
<urulama> wallyworld: do you have a track of all the breaking changes somewhere? as in a list? if not, we'll make it so we don't miss anyone and share it with other clients as well
<wallyworld> urulama: it will be complicated by tim's work - there's only one api change as such - create model. well 2 if i can get detroy model landed. but then tim's stuff potentially alters the json attributes all over. i can get a diff of the tag changes
<wallyworld> add model i mean
<urulama> wallyworld: no, no, not in such detail. tim's change is well defined ... no worries, i'll make a list
<rogpeppe> axw: what's changed in the CreateModel API call?
<axw> rogpeppe: no more ConfigSkeleton for one thing
<rogpeppe> axw: great!
<rogpeppe> axw: is the new API documented anywhere?
<axw> rogpeppe: there's a "name" field on the params struct now, and it's an error to have it in the config bag
 * rogpeppe goes and generates the API docs again
<axw> rogpeppe: and you can specify a region and/or credential name, but they'll have defaults if you're an admin
<rogpeppe> axw: this has landed, right?
<anastasiamac> axw: wallyworld: m meant not to be able to bootstrap maaas on tip of master? m getting with auth-type "oauth1" is not supported (expected one of ["empty"])
<axw> rogpeppe: yes, post beta9
<anastasiamac> for maas deployment that worked before..
<axw> anastasiamac: I'm fixing it
<anastasiamac> \o/
<axw> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1593566
<mup> Bug #1593566: Bootstrap reports oath1 not supported with maas 2.0 <bootstrap> <cdo-qa> <cdo-qa-blocker> <maas-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1593566>
<wallyworld> anastasiamac: you need to add auth type to your cloud
<axw> rogpeppe: https://github.com/juju/juju/blob/master/apiserver/params/internal.go#L86
<anastasiamac> axw: tyvm - trying now
<rogpeppe> axw: http://s3.amazonaws.com/rogpeppe-scratch/juju-api-doc.html#ModelManager :)
<axw> rogpeppe: nice!
<axw> wallyworld anastasiamac: http://reviews.vapour.ws/r/5133/
<wallyworld> ok
<wallyworld> axw: ty, lgtm
<anastasiamac> axw: looking (and workaround worked)
<anastasiamac> wallyworld: is it a state of origin night again? \o/
<wallyworld> yes indeed
<anastasiamac> :)
<frankban> wallyworld: this is the mega-wather response I am getting from current master: {'RequestId': 1, 'Response': {'watcher-id': '1'}}
<frankban> wallyworld: so it seems that we still have some CamelCase there?
<wallyworld> frankban: i think RequestId / Response may be part of the api infrastructure, so maybe missed tim's changes, not sure
<frankban> wallyworld: same for the request top level fields, like Params, Request, RequestId, Type, Version
<wallyworld> thumper: ^^^^ ?
<thumper> that is a different level
<thumper> :(
<thumper> didn't touch that bit
<frankban> thumper: are you going to handle that as well?
<thumper> I hadn't thought about it, but could do
<thumper> we probably should... right?
<frankban> thumper: I think so, as otherwise the API style is still inconsistent
<thumper> frankban: ack, will look at it tomorrow
<frankban> thumper: thanks!
<axw> thumper: I think atm you can connect to a 2.0 server with a 1.25 client, and you'll be told that the client is incompatible. If we totally change the arg casing, that would be broken... or we'd need to handle both
<dimitern> frankban: FWIW those RequestId and Response fields are not part of the API contract, but the RPC layer
<thumper> axw: yeah... interesting
<dimitern> thumper: I was unable to add a machine after your API changes landed
 * thumper will consider
<dimitern> thumper: some of the decisions re adding omitempty seem inconsistent
 * urulama has a feeling that should end up as a breaking test somewhere :-/
<dimitern> thumper: and there are a few omissions, e.g. an embedded Entities gets a `json:"entities"` (IIRC GetAgentEntitiesResults?), while an embedded Address in HostPort doesn't
<frankban> dimitern: from clients perspective you still get some CamelCase fields and other lower-case ones, which feels inconsistent, and consistency is teh only reasoning for this change
<dimitern> frankban: agreed, just saying simply tagging all params types/fields explicitly does not apply to the RPC transport layer
<thumper> but we could
<thumper> urulama: correct, there should be a test for that
<thumper> dimitern: was it an existing controller and a new client?
 * thumper should leave
<thumper> it's late
<frankban> thumper: I am starting the GUI API migration today, should I consider all lower-case then? including RPC top level fields?
<thumper> frankban: let's say yes, and I'll let you know if I break too much and can't do it
<frankban> thumper: sounds good, thanks a good night
<urulama> night, thumper
<thumper> night
<thumper> urulama: what days are you at the sprint next week?
<urulama> thumper: from Sunday evening to Wednesday noon
<thumper> cool
<thumper> urulama: see you sunday then
<thumper> laters
<dimitern> thumper: no, newly bootstrapped controller
<axw> wallyworld: I'm running out of ideas for a quick-fix for gce. I could do a nasty hack in cmd/juju/commands/bootstrap.go, to convert jsonfile to oauth2
<wallyworld> axw: yeah, i was thinking that may haveto be the temporary answer
<wallyworld> frankban: moving DestrroyModel off client facade is a pita - but we need to do it. it will likely miss the beta10 cutoff tomorrow
<frankban> wallyworld: ah so it will be beta11 ModelManager.Destroy() ?
<wallyworld> frankban: i fear so, i will get it done later tonight but then it needs review etc
<wallyworld> i will try
<frankban> wallyworld: no problem, the GUI will not work for beta10 tomorrow, so there is no rush on our side
<wallyworld> ok, let's aim for beta 11. i'll let you know how i go. i first need to debug another issue as well
<dimitern> frobware: when you can, please have a look at http://reviews.vapour.ws/r/5134/
<frankban> wallyworld: FYI it seems that also all the mega-watcher fields are still CamelCased: for instance http://pastebin.ubuntu.com/17686685/
<wallyworld> damn
<wallyworld> i'll tell tim
<dimitern> frobware, voidspace, jam: standup?
<frobware> dimitern: will do
<axw> wallyworld:  please to be reviewing: github.com/juju/juju/pull/5692
<axw> wallyworld: tested live, bootstrapped gce successfully with a jsonfile cred
<wallyworld> sure borat
<wallyworld> axw: i'm retesting the api port fix on ec2, am seeing both slave controllers stay pending. seems to be intermittent
<axw> wallyworld: hrm, anything in cloud-init-output.log?
<wallyworld> just started looking, added debuggin and trying again
<axw> wallyworld: ok. I need to go make dinner, will be back in a little while
<wallyworld> ok
<frobware> dooferlad: please could you try http://reviews.vapour.ws/r/5136/ on your h/w - thanks!
<dimitern> frobware: you've got a review btw
<frobware> dimitern: ah, yes. will do
<dimitern> frobware: ta!
<dooferlad> frobware: on it
<babbageclunk> dimitern: updated http://reviews.vapour.ws/r/5123/ - have another look?
<babbageclunk> cherylj: ping?
<dimitern> babbageclunk: I did look briefly, looks much better, thanks!
<babbageclunk> dimitern: cheers!
<dimitern> babbageclunk: LGTM
 * dimitern is out for a while
<axw> wallyworld: how goes it?
<wallyworld> qld behind 2-4
<wallyworld> oh, you mean work
<axw> wallyworld: heh yeah :)
<wallyworld> axw: have interfaces / mocks more or less sorted for moving destory model. having a mix of state.State and interfaces sorta sucks
<axw> wallyworld: the api-port thing though? sorted?
<wallyworld> axw: yeah, so this is an existing issue - config that comes via an api call has ints unmarshalled as float64 and mustInt() fails
<wallyworld> we just have never come across it
<axw> wallyworld: I just saw your change. I'm sure we handle that in schema.Coerce. maybe related to the recent introduction of controller.Config?
<axw> does that *always* go through schema.Coerce, or only at bootstrap time?
<wallyworld> the latter i think
<wallyworld> i can do a better change for beta 11 if needed
<axw> wallyworld: yeah that's what I thought. I think we can back that change out when controller config is fully separated
<wallyworld> yep, will do for now to unblock the beta
<axw> wallyworld: yeah no worries, I'd just like to simplify later if possible. all good for now
<wallyworld> +1
<babbageclunk> dimitern: ping?
<dimitern> babbageclunk: pong
<babbageclunk> dimitern: hey - I was trying to understand the tests in https://github.com/juju/juju/blob/master/cmd/juju/status/status_test.go#L338
<babbageclunk> dimitern: Why are they written like this (as series of steppers) instead of function calls?
<dimitern> babbageclunk: they're almost like defined in their own DSL
<dimitern> babbageclunk: well, I did that after getting excited about how the uniter tests were written at that time
<dimitern> babbageclunk: but now I wouldn't have done it like this
<babbageclunk> dimitern: But why not just function calls for the different kinds of steps?
<babbageclunk> dimitern: ok - I think I follow.
<dimitern> babbageclunk: as for debugging tips - since everything is one big table-based test, it's best to comment out all cases you don't care about (temporarily)
<babbageclunk> dimitern: yeah, that sounds v useful
<dimitern> to reduce the insane amount of cruft you need to sift through on failure
<babbageclunk> dimitern: should be ok though - my new fields only show up if they're populated, so adding them shouldn't break any other tests.
<dimitern> babbageclunk: yeah, it sounds like you need to add 2 cases only - to exercise application workload-version w/ and w/o '*' suffix
<babbageclunk> dimitern: Do you think I need to test the suffix again here? I'm not doing any formatting at the command level.
<dimitern> babbageclunk: however, if 'workload-version' is not json-tagged as ',omitempty', you'd need to change all existing cases to include an empty w-v
<babbageclunk> dimitern: It seemed right to tag workload-version as omitempty, though - otherwise it'll be noise for all the charms that don't set it (all of them at the moment).
<dimitern> babbageclunk: I think it's good to test both cases, for completeness, and they can act like functional/integration tests for the feature
<babbageclunk> dimitern: Yeah, fair enough. Not very hard to.
<dimitern> babbageclunk: charms won't be affected - mostly tests with pre-canned 'expected' responses could be affected
<mup> Bug #1592101 changed: Error connecting with cached addresses <juju-core:Fix Released> <https://launchpad.net/bugs/1592101>
<mup> Bug #1575940 opened: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
<mup> Bug #1595155 opened: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
<mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
<frankban> wallyworld: FYI Client.CharmInfo response is still in camel case, maybe I should write an email to Tim with my findings
<wallyworld> frankban: that would be most excellent
<frankban> wallyworld: doing that, I'll send it before my EOD
<dimitern> frankban: try adding a machine as well
<frankban> dimitern: do you want me to try if it works?
<dimitern> frankban: I found that to be broken; e.g. 'juju add-machine --series trusty' or 'add-machine lxd:0'
<frankban> dimitern: ok I'll look if I can add a machine through the API
<dimitern> frankban: yes, please, if you can - I'm still not sure if the above is maas-specific (where I've seen it after thumper's change) or not..
<mup> Bug #1575448 opened: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
<frankban> dimitern: it seems to be working on lxd: http://pastebin.ubuntu.com/17693847/
<mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
<dimitern> frankban: hmm.. is that the correct version for 2.0 btw?
<dimitern> frankban: thanks for confirming though, it seems it might be maas-specific
<frankban> dimitern: what do you mean correct version for 2.0?
<dimitern> frankban: I though all API facade versions where incremented in juju 2.0
<dimitern> frankban: so seeing Version: 1 in your paste seemed wrong, but I'm not sure if the Client facade version was also bumped
<frankban> dimitern: I am not aware of any version bump in juju2, here are the facades returned when logging in: http://pastebin.ubuntu.com/17694260/
<perrito666> wow the test suite really kills my laptop
<dimitern> frankban: well, comparing this to 1.25 you'll notice the bumps
<dimitern> frankban: but I've just remembered Client was originally Version: 0
<frankban> dimitern: sure, but Client is version 1
<frankban> dimitern: cool ok
<frobware> cherylj: do I need extra extra extra magic runes for landing in 1.25? - https://github.com/juju/juju/pull/5693
<cherylj> frobware: you just have to really mean it
<cherylj> $$__JFDI__$$
<frobware> cherylj: ohhhhhhhhhh
<frobware> duh
<frobware> ok
<cherylj> :)
<dimitern> it still looks like $$__JEDI__$$ to me :D
<frobware> dimitern: remind me again... do I care about removing "vlan_id" from the iface options?  Just porting from 1.25 and want to make sure I don't drop anything along the way.
<dimitern> frobware: no, because it's invalid anyway and will be ignored
<dimitern> frobware: curtin is to blame for adding it
<fwereade> babbageclunk, katco: https://github.com/juju/juju/pull/5695 doesn't seem to have been picked up by RB, but should be trivial
<dimitern> frobware: updated http://reviews.vapour.ws/r/5134/
<dimitern> voidspace, babbageclunk, dooferlad: I'd appreciate a second look on the above as well
<frobware> dimitern: done
<dimitern> frobware: thanks!
<perrito666> I am getting a lot of timeouts on my tests, did the mongo --nojournal fix land in master?
<dimitern> frobware: ping
<frobware> dimitern: pong
<dimitern> frobware: let me know what you think about my response on your review
<frobware> dimitern: does the last or first 'search' win?
<dimitern> frobware: the last apparently
<frobware> dimitern: <shrug> - ok
<dimitern> frobware: how about those 4 points btw?
<frobware> dimitern: looking. everthing is so well defined. Not.
<dimitern> frobware: yeah, that's the issue I think - not completely defined spec leads to permissive implementations :)
<frobware> dimitern: is this valid "nameserver 8.8.4.4 4.4.4.4" without trailing comments?
<dimitern> frobware: no
<dimitern> frobware: (as far as 'host' is concerned at least.. nslookup as well, haven't tried all dns clients :)
<frobware> dimitern: so is search the only one we should then consider as it seems more permissive (e.g., "search foo foo.bar maas. ;baz #bad (baz and bad are ignored)")
<frobware> dimitern: any /etc/resolv.conf I edit by hand I always put nameserver entries on a line by themselves.
<frobware> dimitern: search not so, hence why I was asking
<dimitern> frobware: neither search nor nameserver are defined as allowing comments after the values.. interestingly enough vim's syntax highlighting seems to catch most of the corner cases I tried
<frobware> dimitern: whodathunkit!
<dimitern> frobware: so, anyway - if those 4 suggestions for changing the behavior seem reasonable, I'll do them and let's get it landed
<frobware> dimitern: I responded in the review - ok for some, the others I simply dunno.
<dimitern> frobware: '(2.1) disagree' - meaning it should be a parse error out of ParseResolvConf() or we should allow multiple values and not ignore the whole line?
<frobware> dimitern: I don't think we should allow multiple values per nameserver entry. separate lines, but this is just based on the way I've always done it.
<frobware> dimitern: what a mess
<dimitern> :)
<frobware> dimitern: drop all searches, use 8.8.8.8. :-D
<dimitern> frobware: It was surprising for me that IPv6 addresses are not allowed for nameserver btw
 * frobware thinks the problem with free form text is you now have two problems
<dimitern> yeah..
<dimitern> https://xkcd.com/927/
<frobware> dimitern: it's missing several orders of magnitude.
<dimitern> frobware: hmm.. so re IPv6 it's deeper than that
<frobware> dimitern: or wider. :-D
<natefinch> OMG azure is so slow
<dimitern> `With BIND 8.3.3, the DNS client can connect to IPv6 DNS servers using an IPv6 transport. To enable such a connection, enter an IPv6 address after nameserver in the resolv.conf file.`
<dimitern> ffs..
<dimitern> nothing can be easy, can it
<frobware> dimitern: what does "after" mean here/
<dimitern> frobware: after 'nameserver'
<frobware> dimitern: on a new line?
<frobware> dimitern: so you need context whilst parsing?
<dimitern> frobware: ha:)
<dimitern> frobware: well it seems to accept 'nameserver ::1' (it doesn't listen there, so it gets ignored)
<frobware> dimitern: given where we are with IPv6 I would concentrate on rock-solid IPv4.
<dimitern> frobware: but not '2001:db8::1' (fair enough - it's from the range reserved for examples)
<dimitern> frobware: I vote for accepting single value IPv6 nameservers
<frobware> dimitern: me too, that catches ::1
<dimitern> frobware: but return parse errors in the other 3 sub-cases of 2)
<frobware> dimitern: how bad/common is 2.3?
<dimitern> frobware: rather than ignoring them
<frobware> dimitern: 2.4 should be harmless - we do nothing
<dimitern> frobware: dunno.. but it can be an honest mistake I guess
<frobware> dimitern: but there's nothing for us to add so we accept and move on
<frobware> dimitern: if I have 'search    #oops I forgot!' - we add parse but add no domain, correct?
<frobware> dimitern: *nix is hard to tool sometimes... :(
<dimitern> frobware: so missing values are definitely not allowed (explicitly stated in resolv.conf(5)) and cause parse errors
<natefinch> why oh why do I have to switch to the controller model to run enable-ha?  It's not a model command, it's a controller command :/
<frobware> dimitern: well, that helps!
<frobware> dimitern: dem da rulez!
<dimitern> frobware: re 'search #oops I forgot' - the same as no value as far as 'host' is concerned
<dimitern> frobware: and I'd rather return an error in all cases of 2), but still allow 2.2) (ipv6 addrs)
<frobware> dimitern: do we consider the "domain" keyword at all?
<dimitern> frobware: there are 2 additional limitations, which I won't even bother to handle specifically - more than 3 nameserver and more than 6 domains in 'search' (or len of all values >256)
<frobware> dimitern: ah, well I think we should leave the limitations up to resolvconf
<dimitern> frobware: not yet ('domain' is mutually exclusive with 'search' per the spec)
<frobware> dimitern: if those rules change we would have to change juju - which seems wrong
<dimitern> frobware: exactly
<dimitern> frobware: and returning parse errors is better than silently ignoring a bad resolv.conf (when we can tell the user about it)
<frobware> dimitern: ok, but I think 'domain' is something we should consider - last one wins (either search or domain)
<katco> natefinch: standup time
<dimitern> frobware: yeah, when we add support for 'domain', that's what we should do I think
<frobware> dimitern: with the additional DNS support in MAAS 2.0 is this something we can potentially get?
<dimitern> frobware: that depends on whether maas/cloud-init/curtin renders resolv.conf including 'domain' (not seen this thus far)
<frobware> dimitern: me neither
<frobware> dimitern: but I don't use MAAS 2.0 very much
<dimitern> frobware: I mostly test on 2.0 now
<frobware> dimitern: which is good because between us we cover both
<natefinch> cherylj: want me to look at https://bugs.launchpad.net/juju-core/+bug/1595155 ?
<mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
<cherylj> natefinch: we're talking about that now and it may not be an issue
<cherylj> natefinch: can you backport the fix for bug 1581157?
<mup> Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157>
<natefinch> cherylj: sure
<perrito666> bbl
<frobware> dimitern, babbageclunk, dooferlad, voidspace: forward port of the bridge script changes from 1.25: http://reviews.vapour.ws/r/5140/
<dimitern> frobware: will look shortly
<frobware> dimitern: thanks; will check back later
<babbageclunk> frobware: looking now
<frobware> babbageclunk: the essence of the change is 1) revert to using ifdown and 2) that means the real diff is like this: http://pastebin.ubuntu.com/17704158/
<frobware> babbageclunk: the revert to using ifdown is commit http://pastebin.ubuntu.com/17704158/
<frobware> babbageclunk: and the other change is http://pastebin.ubuntu.com/17704233/
<frobware> dimitern: ^^
<dimitern> frobware: LGTM
<mup> Bug #1595252 opened: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:New> <https://launchpad.net/bugs/1595252>
<natefinch> cherylj: backport is pending merge into 1.25.  Anything else I should look at?  I have limited time left today, due to taking a half day, but willing to start work on something that is ok to finish tomorrow.
<cherylj> natefinch: I'll find something for you to pick up when you come back tomorrow :)
<dimitern> frobware: still there?
<frobware> dimitern: nope
<frobware> dimitern: well, very briefly
<dimitern> frobware: I'm finally done with the changes, pushing hopefully the final version, as discussed - wanna have a last look before I set it to land?
<frobware> dimitern: might have to be later - we can land tomorrow
<dimitern> frobware: ok
<frobware> dimitern: did you push the changes?
<dimitern> frobware: any minute now..
<dimitern> frobware: done
<mup> Bug #1595276 opened: TestDestroyControllerErrors failure with out of order errors <azure-provider> <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1595276>
<mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1593812>
<mup> Bug #1595278 opened: Openstack invalid port range 0:0 <blocker> <ci> <openstack-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1595278>
<jhobbs> Is there a working juju daily ppa somewhere? https://launchpad.net/~juju/+archive/ubuntu/daily looks like it's out of date. I need to get a close to tip juju and I was hoping for a PPA so I don't need to learn how to build it
<mup> Bug #1595252 changed: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:Invalid> <https://launchpad.net/bugs/1595252>
<cherylj> jhobbs: you can get the binaries built from our last CI run:  http://reports.vapour.ws/releases/4092/binaries
<jhobbs> thanks cherylj
<cherylj> katco: would you be able to review this today?  https://github.com/juju/juju/pull/5057
<katco> cherylj: let me see how big it is
<katco> cherylj: errrr a bash script...
<katco> cherylj: i'll give it a go
<katco> cherylj: wow, i'm not well versed enough in bash to do this thing justice
<katco> cherylj: sorry, someone who knows bash will have to TAL.
<mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
<mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
<mup> Bug #1593394 opened: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
<mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
<mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
<mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
<mup> Bug #1595314 opened: maas controller.go:80 read version failed: &errors.Err{message:"", cause:(*json.SyntaxError)(0xc82040a1a0), previous:(*errors.Err)(0xc8202b6c30) <juju-core:New> <https://launchpad.net/bugs/1595314>
<cherylj> jhobbs: ping?
<jhobbs> hi cherylj
<cherylj> hey there.  Regarding bug #1594958
<mup> Bug #1594958: Bootstrapping on OpenStack fails with juju 2 <v-pil> <juju-core:Incomplete> <https://launchpad.net/bugs/1594958>
<cherylj> are you using exactly "--config image-metadata-url=<url>" ?
<jhobbs> cherylj: the command i ran is in the pastebin
<jhobbs> http://paste.ubuntu.com/17713435/
<jhobbs> i'm using --config --image-metadata-url
<jhobbs> i see
<jhobbs> doh
<jhobbs> thanks for pointing that out
<cherylj> ah yeah, sorry.  Missed the link
<jhobbs> i will try again with the right argument, thanks
<cherylj> np, feel free to ping me here if you have other problems.
<wallyworld> ericsnow: it seems there's a core issue about recording last sent id vs timestamp - once sorted out, we're close to being able to land stuff?
<ericsnow> wallyworld: yep
<mup> Bug #1595330 opened: When deploying a bundle, num_units defaults to zero if not specified <bundles> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595330>
<wallyworld> ericsnow: i do like id - if they are monotonically increasing, it's unambiguous
<ericsnow> wallyworld: yep
<katco> wallyworld: i was ocr today; spent first half reviewing, then worked on observer PR. making good headway there
<wallyworld> awesome
<redir> katco: are you accessing user info anywhere for auditing?
<katco> redir: kind of. the observers for auditing hold current api user in state
<katco> redir: but just the tag's name
<redir> katco and there's no way that you would lookup a user after the fact, IIUC.
<redir> katco: making sure there's no impending need to access deleted user information.
<redir> and auditing is the only place I can think of where that might happen in the near future.
<katco> redir: no, i don't think so. the audit message would include the user name as a string, so no dereferencing needed
<alexisb> thumper, ping
<redir> going for some air. bbiab.
<anastasiamac> natefinch: ping
<wallyworld> menn0: very tiny change to modify slightly a previous fix if you have a sec (blocker for beta 10) http://reviews.vapour.ws/r/5143/
<menn0> wallyworld: looking
<menn0> wallyworld: ship it
<wallyworld> menn0: tyvm
<mgz> wallyworld: I think you're misreading the bug
<mgz> you don't need to set the port everywhere, you just can't pass an uninitialised int over the api
<mgz> because that's a zero
<wallyworld> mgz: i just reverted to previous behaviour
<mgz> wallyworld: yeah, the fix is fine. the review description is just perplexing
<mgz> non-controllers don't need the api port opened
<mgz> they just need to not be told to open an invalid port range
<wallyworld> which we were always doing
<wallyworld> ie opening port
<wallyworld> so least risk just to go to old behaviour for now
<mgz> wallyworld: yeah, I agree
<wallyworld> but i agree with you too
<mgz> the right fix is presumably to change SetUpGroups or something though
<mgz> but that doesn't need to happen here
<wallyworld> mgz: yeah, it's all a bit messed up
 * thumper crosses fingers
<alexisb> thumper, ??
<thumper> alexisb: trying to get something to work
<thumper> btw, it isn't working
<alexisb> should I cross my fingers too?
<alexisb> would that help
<thumper> maybe...
<thumper> I'm pleased that lxd bootstraps so fast...
<thumper> if 2 minutes is fast
 * thumper waits some more
<thumper> hmm...
<thumper> kinda working
<thumper> but I have surprising data...
<alexisb> surprising how
<thumper> unexpected
<thumper> I need to work out how to pull this apart...
#juju-dev 2016-06-23
<jhobbs> cherylj: got bootstrap to work, hitting another issue trying to deploy an instance https://bugs.launchpad.net/juju-core/+bug/1595360
<mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
<cherylj> jhobbs: try restarting jujud on the controller
<cherylj> the "lease manager stopped" error has been seen recently and usually a restart of jujud brings things back
<mup> Bug #1595360 opened: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
<jhobbs> cherylj: that made the lease manager stopped errors go away, but it's still failing. It looks like it's trying to go back to the internet for the image stream instead of using the image-metadata-url i bootstrapped with
<jhobbs> cherylj: do i have to set the image-metadata-url for non bootstrap stuff some other way?
<cherylj> jhobbs: it may be falling back because it can't access the streams from the client
<cherylj> and by client I mean machine
<mup> Bug #1595360 changed: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
<cherylj> let me look at the output again, one sec
<mup> Bug #1595360 opened: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
<cherylj> jhobbs: can you attach /var/log/cloud-init-output.log for one of the machines that's in "waiting for agent initialization"?
<jhobbs> cherylj: there is no machine
<cherylj> bleh, sorry
<cherylj> anastasiamac: would you be able to help jhobbs with bug 1595360?  I need to eod
<mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New> <https://launchpad.net/bugs/1595360>
<anastasiamac> cherylj: jhobbs: sure.. gimme 30 mins to catch up :)
<cherylj> thanks, anastasiamac!
<jhobbs> cherylj: anastasiamac: thanks, i need to EOD too, if you comment on the bug i will pick it up tomorrow
<anastasiamac> jhobbs: will do \o/
<anastasiamac> jhobbs: is there any chance, you could also attach the other file from machine-0 log directory?
<anastasiamac> jhobbs: and if u get a chance, could you pleas also send `juju status --format=yaml` output?
<jhobbs> anastasiamac: http://paste.ubuntu.com/17727508/
 * anastasiamac wondering how jhobbs got machine-0 log if there are no machines according to status :D
<anastasiamac> jhobbs: have u been able to bootstrap juju 1.25 on the same cloud?
<jhobbs> anastasiamac: ah well that's for the model i added, here is the juju status for the controller model http://paste.ubuntu.com/17727730/
<jhobbs> anastasiamac: i did bootstrap with 1.25 (and 2.0 now) but I didn't try deploying anything after bootstrapping on 1.25
<jhobbs> oO do i need to set image-metadata-url as config on the model i added maybe?
<anastasiamac> jhobbs: i think it would help
<anastasiamac> jhobbs: atm  m not seeing images being picked at all and we are falling throught to trying to pull images from streams-canonical and getting gpg error - signature differences..
<jhobbs> can't juju set-model-config image-metadata-url, get "WARNING key "image-metadata-url" is not defined in the current model configuration: possible misspelling
<anastasiamac> hmm
<anastasiamac> jhobbs: m not sure that it will help on already created model.. I would have thought it makes a difference at bootstrap..
<jhobbs> anastasiamac: it did make a difference at bootstrap - i wasn't able to bootstrap without passing that as a config option
<jhobbs> it's like it's forgotten about it after bootstrap though
<anastasiamac> jhobbs: it shouldn't have, these images (metadata) would have been put into controller db
<anastasiamac> jhobbs: is there another file in logs directory that u could attach to the bug?
<anastasiamac> jhobbs: besides the machine-0 one
<anastasiamac> ?
<jhobbs> logsink.log
<anastasiamac> yep
<jhobbs> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1595360/+attachment/4688820/+files/logsink.log
<mup> Bug #1595360: 2.0beta9.1: Can't deploy an instance after bootstrapping against OpenStack <v-pil> <juju-core:New for anastasia-macmood> <https://launchpad.net/bugs/1595360>
<anastasiamac> jhobbs: is there anyway, u could do a db dump before u eod so that I can have a look at what u have there?
<anastasiamac> jhobbs: tyvm for logsink :)
<jhobbs> anastasiamac: yeah, how do i do a db dump?
<anastasiamac> jhobbs: gimme a sec, I'll dig it up :)
<anastasiamac> jhobbs: I'll email u details :)
<jhobbs> anastasiamac: k
<axw> wallyworld: looks like my neighbours are getting their power line sunk today, so if I go AWOL it's because I've got no power
<wallyworld> no worries
<thumper> fuckity fuckity fuck fuck
 * thumper sighs
<wallyworld> axw: the current destroy semantics are to nuke the model to which the incoming connection belongs. thus destroy-model -m foo establishes a connection to model foo and kills it. introducing a bulk api sounds ok but does it make sense to allow models to be destoryed over a different connection. for whatever reason, sadly model create is not bulk either :-(
<wallyworld> thumper: do you know why model create api is not bulk?
<thumper> reasons
<axw> wallyworld: true, but I think you're more likely to destroy multiple models at once rather than create multiple at once...
<thumper> and probably not good ones
 * wallyworld sighs
<axw> wallyworld: doesn't seem like a huge change, but if it is, defer
<wallyworld> axw: let me land it as is, and i'll follow up with a change to look at making create and delete bulk
<wallyworld> at least it will allow the gui to be updated
<axw> wallyworld: thanks
<axw> wallyworld: my upcoming cloud rejiggering changes will conflict with yours I think, so the sooner it lands the better anyway
<wallyworld> yep
<wallyworld> thumper: why were you headesking?
<thumper> wallyworld: converting apiserver/params structs with embedded charm.v6-unstable structures to things that don't use those structures
<thumper> would have been so much easier if we caught it when they were created
<wallyworld> thumper: should we change the charm.v6 stuff in that repo then
<wallyworld> it is still unstable
<thumper> no
<thumper> we shouldn't be using external structs
<thumper> fullstop
<thumper> too easy for things to change without us catching it
<wallyworld> yes true
<thumper> it is just boring work
<thumper> work we should do
<thumper> but boring
<thumper> well... it builds now
 * thumper wonders how many tests fail
<thumper> bored
<thumper> bored
<thumper> bored
 * thumper waits
<blahdeblah> Boredom is a delicious luxury; use it wisely.
<mup> Bug #1571477 changed: juju 1.25.3: juju-run symlink to tmpdir <landscape> <juju-core:Expired> <https://launchpad.net/bugs/1571477>
<thumper> :)
 * thumper is trashing this laptop's cpu
<thumper> load 20, cpu 100%
<davecheney> engineer reports 105% on the reactor is possible, but not recommended
<thumper> wallyworld: http://reviews.vapour.ws/r/5148/
<wallyworld> looking
<thumper> munging types
<thumper> mostly trivial but annoying
<wallyworld> thumper: i had one thing to fix and a suggestion or 2
<thumper> k
<axw> wallyworld: FYI: http://reviews.vapour.ws/r/5149/
<axw> no rush I guess, probably need to rebase on your changes
<wallyworld> ok
<wallyworld> we have meeting soon then i have soccer
<axw> wallyworld: I've gotta go get Charlotte soon, will miss the beginning of the meeting
<wallyworld> axw: ok, btw we gotta hide those certs http://paste.ubuntu.com/17734075/
<axw> yup
<axw> wallyworld: I think we can just add them to SecretAttrs for now, I'll go ahead and do that
<wallyworld> axw: maybe also authorized keys
<wallyworld> not secret but annoying
<wallyworld> we don't need to see those in get-config
<axw> wallyworld: yeah. I kinda think they shouldn't be in config, since they're not managed through config... but not sure
<wallyworld> maybe that will break stuff though
<voidspace> babbageclunk: ping
<babbageclunk> poong
<babbageclunk> voidspace: ^^
<voidspace> babbageclunk: I sent you a PM
<dimitern> voidspace, babbageclunk: morning :) if you can, please take a look at http://reviews.vapour.ws/r/5134/
<dimitern> frobware: ^^
<babbageclunk> dimitern: morning! looking now.
<dimitern> babbageclunk: thanks!
<frobware> dimitern: taking a look
<dimitern> frobware, jam, fwereade, dooferlad: standup?
<frobware> dimitern: LGTM. thanks
<dimitern> frobware: tyvm
<_thumper_> night all
<fwereade> axw, http://reviews.vapour.ws/r/5151/ should be trivial if you have a moment
<TheMue> hello to my former colleagues ;)
<dimitern> TheMue: o/ ;)
<TheMue> dimitern: heya, are all our British colleagues voting? I hope they do vote #remain.
<dimitern> TheMue: yeah, same here! today's a bit quiet, not completely though :)
<TheMue> dimitern: btw, my try to return to Canonical doesn't look so good. currently extreme few potential matching positions
<dimitern> TheMue: yeah? :/ well, I'm sure something will come up sooner or later!
<dimitern> babbageclunk: review poke? :)
<TheMue> dimitern: I'll keep up looking, but I've already got other interesting contacts. so we'll see.
<dimitern> TheMue: good luck though!
<TheMue> dimitern: thanks
<hoenir> could anyone merge it ? http://reviews.vapour.ws/r/4924/
<hoenir> I think now the CI is not locked down http://juju.fail/
<dimitern> hoenir: done - it should land soon, I'll keep an eye on it
<hoenir> dimitern, thanks !
<dimitern> np :)
<babbageclunk> dimitern: Sorry! Got distracted! Doing it right now.
<dimitern> babbageclunk: no worries, ta!
<babbageclunk> dimitern: done, sorry for the holdup
<dimitern> babbageclunk: thanks!
<babbageclunk> dimitern: just bootstrapping, noticed the gui installation message - does that mean that the gui is available straight away in a newly bootstrapped controller?
<babbageclunk> dimitern: How do I get to it?
<dimitern> babbageclunk: haven't tried, but there is 'juju help gui' you can check
<babbageclunk> dimitern: ooh, will try it once this bootstrap finishes.
<dimitern> babbageclunk: YMMV though, as the bundled gui might still be broken due to thumper's recent API rename changes
<babbageclunk> dimitern: oh, of course
<babbageclunk> dimitern: Yup, you're right: "unknown object type: Client". Pretty slick up until then though - will be a really nice experience once it works! ;)
<dimitern> babbageclunk: it works if you switch to a commit earlier than https://github.com/juju/juju/commit/769aeb4b45068389a88f9fef34f3d61915d28562
<babbageclunk> dimitern: thanks - mostly just curiosity after seeing the message scrolling past in a few bootstraps..
<anastasiamac> macgreagoir: cherylj: standup?
<voidspace> babbageclunk: my headphones arrivedd
<voidspace> babbageclunk: they're huuuuuuge. Headphone quality and build quality seem reasonable though.
<babbageclunk> voidspace: ooh, exciting
<voidspace> babbageclunk: they're very white
 * babbageclunk goes for a run.
<axw> fwereade: sorry for the delay, LGTM
<mup> Bug #1595514 opened: destroy-controller fails <juju-core:New> <https://launchpad.net/bugs/1595514>
<fwereade> axw, ta
<mup> Bug #1595514 changed: destroy-controller fails <juju-core:New> <https://launchpad.net/bugs/1595514>
<dimitern> frobware: sync?
<babbageclunk> cherylj: ping?
<frobware> dimitern: power just restored
<dimitern> frobware: we're still in the call btw
<frobware> dimitern: omw
<cherylj> babbageclunk: what up
<babbageclunk> cherylj: oh hey - I just wanted to check about the email about blocking master you sent the other day.
<cherylj> I was surprised no one responded :)
<cherylj> did you have a specific question?
<babbageclunk> cherylj: I've got something that I'd like to get into the rc - is it legit to JFDI it?
<cherylj> babbageclunk: yes, provided you have done manual testing, run with -race, etc.
<babbageclunk> cherylj: (it's the state changes for workload version)
<cherylj> babbageclunk: yeah, that's fine
<babbageclunk> cherylj: ok, great - that's how I was interpreting the email, just checking.
<cherylj> np, thanks for asking :)
<babbageclunk> :)
<mup> Bug #1581157 changed: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by natefinch> <juju-core 1.25:Fix Released by natefinch> <https://launchpad.net/bugs/1581157>
<mup> Bug #1591290 changed: serverSuite.TestStop unexpected error <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Fix Released by thumper> <juju-core 1.25:Fix Released by thumper> <https://launchpad.net/bugs/1591290>
<natefinch> cherylj: whatchoo got for me?
<natefinch> cherylj: and go easy on me, it's my birthday ;)
<cherylj> natefinch: in that case, let me see what the worst one is!
<cherylj> ;)
<marcoceppi> hey
<marcoceppi> I've shared a model with someone
<marcoceppi> but they can't ss
<marcoceppi> ssh*
<natefinch> cherylj: haha... as long as you wait until my next birthday for the next really bad one ;)
<marcoceppi> how do I get their keys into the system
<cherylj> natefinch: did you see anastasia's email about 1595155
<cherylj> bug 1595155
<mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
<natefinch> cherylj: oh yeah, I'll jump on that, forgot about that.
<cherylj> marcoceppi: is it a perm denied error?  or a timeout?
<marcoceppi> cherylj: perm denied
<marcoceppi> tvansteenburgh: ^^
<marcoceppi> cherylj: I ran: `juju import-ssh-keys lp:tvansteenburgh` after I added tvansteenburgh as a user and shared a model with him
<marcoceppi> cherylj: he can juju status, but not ssh
<perrito666> fwereade_: can you go back to your usual nickname so I can privmsg you without having 2 different logs plz?
<tvansteenburgh> cherylj: i have lots of ssh keys, how does `juju ssh` know which one to use? is there a way to tell it?
<fwereade> perrito666, sorry :)
<cherylj> tvansteenburgh: it uses a lot of keys.  You can see the actual ssh command if you run:
<cherylj>  JUJU_LOGGING_CONFIG="<root>=TRACE" juju ssh <machine>
<cherylj> tvansteenburgh:  you'll see something like this:
<cherylj> 2016-06-23 14:55:22 TRACE juju.utils.ssh ssh_openssh.go:131 running: ssh -o "StrictHostKeyChecking no" -o "ProxyCommand /usr/bin/juju ssh --proxy=false --pty=false 52.10.231.18 nc %h %p" -o "PasswordAuthentication no" -o "ServerAliveInterval 30" -t -t -o "UserKnownHostsFile /dev/null" -i /home/cherylj/.juju/ssh/juju_id_rsa -i /home/cherylj/.ssh/id_rsa ubuntu@172.31.46.40
<cherylj> (this is a 1.25 example, but the same should work for 2.0)
<tvansteenburgh> cherylj: http://pastebin.ubuntu.com/17749178/
<cherylj> tvansteenburgh: sorry, you need --debug
<cherylj> JUJU_LOGGING_CONFIG="<root>=TRACE" juju --debug ssh <machine>
<tvansteenburgh> http://pastebin.ubuntu.com/17749251/
<tvansteenburgh> cherylj:  ^
<cherylj> oh...  it's not even getting to running the ssh command
<cherylj> there have been changes to store keys in state
<cherylj> tvansteenburgh: I'm on a call right now, but will dig into this after
<tvansteenburgh> cherylj: thanks!
<babbageclunk> voidspace, frobware: review please? http://reviews.vapour.ws/r/5152/
<katco> natefinch: oh happy birthday! just saw that :)
<katco> ericsnow: lol sorry
<katco> ericsnow: i heard "oh w-"
<ericsnow> katco: was just going to see about a ship-it on that patch
<katco> ericsnow: gave it one
<ericsnow> ta
<katco> ericsnow: provisional to other issues i opened
<ericsnow> katco: yep
<katco> elmo: hey re. bug 1425808, what version were you experiencing this problem on?
<mup> Bug #1425808: OpenStack provider doesn't try another AZ if the scheduler fails to find a valid host <openstack-provider> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1425808>
<elmo> katco: err, it's been a while since we tried so probably early 1.2x's
<katco> elmo: i did some work on that in early april; would anyone have bandwidth to test with 2.0 and provide fresh logs?
<elmo> katco: unfortunately it's a little hard to test - if we create a private host aggregate on prodstack, it'll break all juju 1.2x users :)
<mup> Bug #1595600 opened: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
<elmo> katco: we'd have to spin up a test cloud - but if you think it's fixed in 2.x, I'll ask someone to do that
<katco> elmo: i just updated the bug with relevant info/code. it does look like we try and handle that properly; just a flaw in some error checking probably
<alexisb> btw natefinch Happy Bday!
<katco> elmo: but we need to reconfirm that this is still happening.
<natefinch> alexisb: thanks :)
<mup> Bug #1595600 changed: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
<ericsnow> natefinch: yeah, happy happy happy
<redir> happy bday natefinch
<mup> Bug #1292156 changed: add-machine help docs don't mention kvm <bitesize> <docs> <juju-core:Fix Released> <https://launchpad.net/bugs/1292156>
<mup> Bug #1595600 opened: bundle parsing rejects strings containing hex values <juju-core:New> <https://launchpad.net/bugs/1595600>
<natefinch> thanks everybody
<redir> ericsnow: got a minute for a HO?
<ericsnow> redir: sure
<redir> moonstone
<redir> ?
<babbageclunk> natefinch: happy birthday!
<natefinch> babbageclunk: thanks :)
<TheMue> natefinch: Oh, just seen it, Happy Bday also from the other side of the Atlantic. o/
<mup> Bug #1595617 opened: Subordinate charm dies when deployed with --storage option <juju-core:New> <https://launchpad.net/bugs/1595617>
<cherylj> oh yay
<cherylj> cloud-images.ubuntu.com is down
<rick_h_> cherylj: yes, and some others are noting other urls
<rick_h_> so probably something DC related
<cherylj> wish I hadn't destroyed my previous env :(
<cherylj> perrito666: ping?
<perrito666> cherylj: pong, gimme a sec otp
<cherylj> natefinch: any luck with bug 1595155?
<mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
<mup> Bug #1595636 opened: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
<perrito666> cherylj: sorry, phone was not letting me
<perrito666> cherylj: here now
<natefinch> cherylj: no... it's weird, because the original bug was reported before that change was made :/
<cherylj> hey perrito666 - just wanted to see if the message in this bug is improved with your ACL work:  bug 1594440
<mup> Bug #1594440: juju gives weird errors about macaroons when a read-only user <juju-core:Triaged> <https://launchpad.net/bugs/1594440>
<perrito666> cherylj: checking
<perrito666> cherylj: nope, I dont think so :( (at least not conciously)
<mup> Bug #1595636 changed: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
<mup> Bug #1595636 opened: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
<natefinch> man, I hate that I have to remember to pass in configuration values every time I bootstrap now
<rick_h_> natefinch: good thing there's work to allow you to set it in the cloud settings
<natefinch> rick_h_: oh thank goodness
<cherylj> hey natefinch, sorry I didn't get back to you earlier - was on a call
<cherylj> natefinch: regarding the HA bug
<cherylj> natefinch: the original problem was something else
<cherylj> natefinch: and that godbus / systemd bug from anastasia was raised as something they hit when trying to verify the fix we gave them for the HA issue
<cherylj> does that make sense?
<redir> anyone free for a review? http://reviews.vapour.ws/r/5153/
<natefinch> cherylj: trying to understand it.  Sounds like there was a bug, and that got fixed, but then the deps update I did somehow re-broke it?
<cherylj> natefinch: it didn't re-break it.  It broke things in a different way such that we can't confirm the HA fix works on xenial
<natefinch> cherylj: Maybe there's something special about MAAS?  It works fine on Azure and LXD, at least.  I've tested those in the last couple days.
<cherylj> natefinch: it could be
<natefinch> er... at least on master, not 1.25
<natefinch> sinzui, mgz: do we have CI tests that test HA on MAAS?
<sinzui> natefinch: No. It will not take much effort to add one...when our mass comes back
<natefinch> lol
<natefinch> classic
<sinzui> natefinch: the outage took out all of the canonical host machines
<sinzui> natefinch: munna and silcoon are still not operational
<natefinch> sinzui: ouch
<sinzui> natefinch: is maas 2.0 or maas 1.9 the substrate that needs the test?
<mgz> sinzui: did we run it on maas before? we've had the terminate code for maas for agest
<sinzui> mgz: several bundles use HA. but we never had a regular test for ha recovery on maas
<natefinch> sinzui: the bug I'm looking at is using maas 1.9
<sinzui> mgz: this related to the current pressure to stop testing on all substrates
<perrito666> bbl
<sinzui> natefinch: okay, when munna returns, I will add the test
<natefinch> why is there pressure to stop testing on all substrates?
<natefinch> that seems like the opposite of what we want
<sinzui> natefinch: testing is fast if we only test on lxd...but there are two many substrate nuances for that to be realistic
<sinzui> the same is true for arch and series
<natefinch> sinzui: in theory they should all be able to run in parallel, right? So the only problem is the one slowest test.  Which, granted, will be slower than LXD, but the benefits would seem to outweigh the problems
<sinzui> natefinch: exactly what I wrote today :)
 * redir goes for lunch
<sinzui> natefinch: the test is added. We are just waiting for the host to comeback to life
<natefinch> sinzui: thanks
<alexisb> thumper, do you know when menn0 will be around today?
<thumper> alexisb: normally sometime in the next hour
<alexisb> thumper, ok
<alexisb> natefinch, how long on you on todya?
<natefinch> alexisb: one more hour... I could make time for a meeting later, but it's both my birthday and my wife's birthday, so working late before the kids go to bed is a no-go.
<alexisb> you and your wife have the same bday?
<natefinch> alexisb: yep :) and my twin sister :)
<alexisb> lol
<alexisb> makes it harder to forget :)
<alexisb> natefinch, nevermind
<alexisb> enjoy your bday
<natefinch> alexisb: met my wife on a dating service, I got her to notice me by mentioning we had the same birthday ;)
<alexisb> heh
<alexisb> I leaned some interesting finch trival today
<natefinch> :)
<natefinch> makes for fun when we all go out to eat and they ask whose birthday it is :)
<katco> natefinch: what is the plural of finch? finches? finchii?
<natefinch> katco: finches :)
<katco> natefinch: happy birthday to the finches
<natefinch> btw the collective noun is a charm of finches :)
<katco> lol
 * natefinch doesn't know who makes up this crap.
<natefinch> katco: and thanks :)
<mup> Bug #1595636 changed: Cannot kill manual cloud controller <juju-core:New> <https://launchpad.net/bugs/1595636>
<mup> Bug #1595686 opened: Cannot get status after restore is denied <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1595686>
<katco> does anyone know if the modelUUID is something that could change without restarting the machine agent? or ever for that matter?
<natefinch> katco: good god I hope not
<natefinch> katco: it's stored all over the DB, I can't imagine it's mutable
<katco> natefinch: kk ta
<cherylj> tvansteenburgh: FYI - bug 1595720
<mup> Bug #1595720: Problems using `juju ssh` with shared models <ssh> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595720>
<tvansteenburgh> cherylj: thanks
<mup> Bug #1595720 opened: Problems using `juju ssh` with shared models <ssh> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595720>
 * redir pokes the review queue again. http://reviews.vapour.ws/r/5153/
<menn0> alexisb: internet troubles?
<menn0> alexisb: you just sounded like a very unhappy robot :)
<alexisb> menn0, yes
<alexisb> yes I am
<alexisb> lol, yes I am not happy with my internet provider at the moment
<menn0> alexisb: shall we finish on IRC? how much did you get before your link went bad?
<alexisb> they keep trying to "fix" bandwidth issues by changing to different frequencies and it makes things very unreliable
<alexisb> sure
<redir> unhappy robot makes me think of Marvin the paranoid android
<menn0> redir: alexis did sound somewhat like marvin on the call :)
<alexisb> the last I got was that there where some potential issues with read only mode, and it was unclear if all the watchers were actually being stopped
<alexisb> but that overall progress was good this week
<alexisb> and htat you were going to work on status next
<menn0> alexisb: workers not watchers but yes
<alexisb> sorry, yes workers
<menn0> alexisb: yes, status and tidying up some loose ends with the read-only mode
<menn0> alexisb: and it looks like voidspace has already done the ssh host key import work
<menn0> which is great
<alexisb> nice
<redir> heh
<menn0> alexisb: it would be great to have fwereade back but he seems to be getting pulled onto other things
<menn0> alexisb: it's great that he landed the read-only mode work though. that's a big step forward.
<alexisb> menn0, yes and unfortunately I dont see that changing
<menn0> alexisb: ok, well I'll keep plugging away. it's getting better every day.
<menn0> alexisb: oh and another good development
<menn0> alexisb: ... rogpeppe has done work to do controller login redirections
<menn0> alexisb: which is very close to what we need for login redirections after a model has migrated
<alexisb> nice
<menn0> alexisb: so that's going to take some work off our plate
<alexisb> free help is always good :)
<menn0> alexisb: indeed :)
<menn0> alexisb: so the summary is: good progress but there's still plenty to do, could do with more people
<alexisb> menn0, understood
<alexisb> we will roll folks back on MM as they free up, but we are struggling with many high priority peices for 2.0
<wallyworld> katco: quick catchup?
<katco> wallyworld: sure sec
<katco> wallyworld: i'm in tanzanite
<wallyworld> ah ok sec
<alexisb> well I have solid bandwidth again now
<alexisb> but it will probably only lsat so long
<perrito666> alexisb: having issues with your isp?
<alexisb> perrito666, yes
<perrito666> alexisb: sorry to hear
 * thumper afk for some pre-sprint errands
<katco> wallyworld: aforementioned pr pushed: http://reviews.vapour.ws/r/5154/
<wallyworld> ty
#juju-dev 2016-06-24
<axw> wallyworld: I was thinking we'd have a separate command and API to revoke credentials
<wallyworld> axw: no worries, wasn't sure as both approaches can be used
<katco> wallyworld: hey sorry that patch you reviewed is kind of a mess. it's WIP and dependent on 2 other PRs, so some of the stuff you've commented on are covered in other PRs
<wallyworld> katco: no worries, just wanted to give some initial feedback
<katco> wallyworld: i'm not sure why review board doesn't do the diff between a branches parent
<katco> wallyworld: yeah ta
<axw> wallyworld: can you please see my reply, I'm just live testing one last time
<wallyworld> ok
<wallyworld> axw: lgtm
<axw> wallyworld: ta
<marcoceppi> still no shared filesystems in Juju?
<wallyworld> marcoceppi: that got bumped in lieu of other feature work
<marcoceppi> it basically makes every web application impossible to charm still without some storage subordinate janky charm
<marcoceppi> wordpress, mediawiki, django apps, anyhting storing uploads is just garbage
<wallyworld> marcoceppi: i hear you. people with higher pay grades mae those priority calls
<marcoceppi> i hear you, wish it was different
<wallyworld> me too
<axw> wallyworld: ok for me to land this cloud change right?
<thumper> marcoceppi: it is our unique funding model :)
<axw> before beta
<axw> ... because they'll just pick another rev if I break things
<wallyworld> axw: let's just check that the previous CI run passes
<axw> ok
<wallyworld> axw: a minute late
<wallyworld> axw: sorry, thumper won't stop talking
<thumper> :(
<axw> heh
<wallyworld> menn0: you arriving sat arvo? anastasia will be there alredy and i arrive sat evening, so let's do something sunday, unless you have other plans
<axw> wallyworld: reviewed
<wallyworld> ta
<menn0> wallyworld: sounds good. I haven't made any plans for sunday.
<menn0> wallyworld: I arrive sat afternoon
<wallyworld> menn0: ok, i arrive at airport around 20:30
<wallyworld> will catch up for breakfast if not before - maybe you'll be at bar drinking :-)
<menn0> wallyworld: it has been known to happen :)
<wallyworld> to the best of us
<menn0> wallyworld: although I might hit some of my old haunts instead of the hotel bar
<menn0> wallyworld: it's my old hood
<wallyworld> nice
<menn0> wallyworld: i'll have data so ping me on twitter or something
 * wallyworld doesn't do social mendia
<wallyworld> *media
<menn0> wallyworld: of course, I forgot :)
<wallyworld> i'll be at breakfast first thing
<menn0> wallyworld: email then
<wallyworld> or hangout message
<menn0> even better
<menn0> and failing that I'll be at breakfast in the morning too
<axw> wallyworld: http://reviews.vapour.ws/r/5156/
<wallyworld> looking
<axw> wallyworld: I think I'll look at splitting model/controller config schemas
<axw> now
<wallyworld> sgtm, hopefully won't take much
<mup> Bug # changed: 1414890, 1460685, 1491578, 1506338
<axw> wallyworld: I'm really not fond of that code I took out. I don't think it's needed, because we always generate SSH keys for the client anyway.
<wallyworld> ok, we can always change if needed
<ericsnow> wallyworld: FYI, I have a WIP in for the "final" patch (the one that actually adds the worker)
<ericsnow> wallyworld: http://reviews.vapour.ws/r/5157/
<ericsnow> wallyworld: now I need to be asleep :)
<mup> Bug #1414890 opened: Network security tests fail, all ports open when using the local provider <charms> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1414890>
<mup> Bug #1414890 changed: Network security tests fail, all ports open when using the local provider <charms> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1414890>
<mup> Bug #1414890 opened: Network security tests fail, all ports open when using the local provider <charms> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1414890>
 * babbageclunk sighs.
<babbageclunk> dimitern: ping?
<babbageclunk> dimitern: I hacked up the postgres charm last night - it's pretty neat!
<dimitern> babbageclunk: hey
<dimitern> babbageclunk: sorry, still reading the headlines...
<babbageclunk> dimitern: man, tell me about it.
<dimitern> babbageclunk: so what about the charm?
<dimitern> babbageclunk: you added bindings?
<babbageclunk> dimitern: No, just in reference to your email about charming - I was hacking workload version into the postgresql charm.
<dimitern> babbageclunk: ah :) I see
<babbageclunk> dimitern: but it was fun, and easier than I'd anticipated
<babbageclunk> dimitern: hmm - about bindings - are we (or maybe charmers) going to need to come up with standard names for spaces so that bindings match up between different charms?
<dimitern> babbageclunk: it is neat, getting into charming for sure is - I was surprised, and as they say here 'appetite grows along with eating more of it' :)
<babbageclunk> dimitern: ha
<babbageclunk> dimitern: ...or is there a way to say "this binding corresponds to this space" when deploying?
<dimitern> babbageclunk: yeah - `juju deploy .. --bind '<ep1>=<sp1> <ep2>=<sp2> ..'`
<babbageclunk> dimitern: Ah, hadn't seen that. Cool.
<dimitern> babbageclunk: or just --bind '<sp>' to bind all to the same (can also mix those 2)
<babbageclunk> dimitern: Would you be able to look at this review? It's pretty straightforward. http://reviews.vapour.ws/r/5152/
<dimitern> babbageclunk: sure
<dimitern> babbageclunk: LGTM
<voidspace> dimitern: babbageclunk: be at standup in 5
<dimitern> ok
<dimitern> frobware: standup?
<aim__> dimitern: yep, trying...
<frobware> dimitern: did you see the latest missing 'search' comments in /etc/resolv.conf. https://bugs.launchpad.net/juju-core/+bug/1575940
<mup> Bug #1575940: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1575940>
<dimitern> frobware: looking
<dimitern> frobware: that's beta9 though..
<frobware> dimitern: right, the changes you landed will only be available in 10 or a daily ppa
<dimitern> frobware: yeah, but I'll try to repro those last steps with b10 + 1.9.3 and 2.0b8 maas
<frobware> dimitern: great, thanks
 * dimitern thinks .. at least brexit didn't happen just before a release.. that would've been bad.. oh wait a minute! :/
<andrey-mp> jamespage: Am I right that next release of OpenStack charms will be 07/16? If it so - when last changes can be made for this release? Is it possible to merge my changes for nova-compute https://review.openstack.org/#/c/331249/ ?
<jamespage> andrey-mp, hey!
<jamespage> andrey-mp, https://launchpad.net/charms/+milestone/16.07 due 07/28
<andrey-mp> hi!
<jamespage> we freeze two weeks in advance of that date - so I think that's the 14th
<jamespage> for features to land; I have your review on my todo list
<andrey-mp> good, thanks )
<jamespage> andrey-mp, do you have an example ephemeral backend charm as well?
<andrey-mp> will wait for comments
<andrey-mp> yeah - https://jujucharms.com/u/cloudscaling/scaleio-openstack
<andrey-mp> this is charm for connecting ScaleIO storage as ephemeral to nova-compute
<andrey-mp> this charm also connects ScaleIO storage to cinder via storage-backend
<dimitern> frobware: ping
<frobware> dimitern: pong
<dimitern> frobware: re bug 1575940
<mup> Bug #1575940: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:In Progress by dimitern> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1575940>
<dimitern> frobware: I've reproduced it, working on a fix
<frobware> dimitern: what's the issue?
<dimitern> frobware: good we caught this before beta10 is out, and I strongly suspect it affects 1.25 too
<frobware> ooh
<dimitern> frobware: adding a comment to the bug now - basically the issue is with `if !haveDNSConfig { // parse resolv.conf }` (in worker/provisioner/broker.go
<dimitern> frobware: i.e. it happens if we only have dns servers (which is the only thing we can get from MAAS 1.9 API), but not search
<dimitern> easy to fix at least - just need to check whether we have both fields set
<frobware> dimitern: bleh
<frobware> dimitern: that's horrible
<dimitern> frobware: yeah :/
<mup> Bug #1595937 opened: there is no way to configure the availability zone for neutron's dhcp agents <juju-core:New> <https://launchpad.net/bugs/1595937>
<frobware> dimitern: do you have some time to talk about the fan?
<dimitern> frobware: yeah, but can it be a bit later?
<dimitern> frobware: I need to go to the bank now (again)
<frobware> dimitern: yep sure - np.  Selling sterling? :-D
<dimitern> :D
<dimitern> frobware: I wish
<frobware> dimitern: I'm just going to invent myown
<dimitern> frobware: there's the fix for dns search missing: http://reviews.vapour.ws/r/5159/
<dimitern> voidspace, babbageclunk: ^^ please take a look
 * dimitern steps out, back in ~30m hopefully
<voidspace> dimitern: LGTM
<dimitern> voidspace, babbageclunk, frobware: thanks guys!
<dimitern> frobware: hey, you wanted to sync re the fan?
<mup> Bug #1588575 changed: allwatcher_internal_test has intermittent failure <intermittent-failure> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1588575>
<babbageclunk> dimitern, frobware, voidspace: review please? http://reviews.vapour.ws/r/5161/
<dimitern> babbageclunk: looking
<babbageclunk> Thanks!
<dimitern> sinzui: hey, did we cut 2.0 beta10 yet?
<dimitern> sinzui: FWIW there's a fix landing as we speak, which will be good to be in beta10
<sinzui> dimitern: yes we have
<dimitern> sinzui: ok, then the fix will be in beta11 I guess
<sinzui> dimitern: yep. We will release next week
<dimitern> ok
<alexisb> katco, ping
<katco> alexisb: pong
<alexisb> perrito666, ping, you still around today??
<cherylj> dimitern: what fix?
<mup> Bug # changed: 1467331, 1486712, 1567951, 1567963, 1568090, 1571792, 1576003, 1593299, 1593566, 1593761, 1593838, 1594232, 1594335, 1594580, 1594855, 1594875, 1595278
<dimitern> cherylj: for bug 1575940
<mup> Bug #1575940: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1575940>
<natefinch> welp.... our meals will be cheaper at the sprint at least.
<cherylj> dimitern: oh, you figured it out?!  awesome!
<dimitern> cherylj: yeah :)
<perrito666> alexisb: I am intermittently
<cherylj> dimitern:  I bet ahasenack is relieved that he wasn't going crazy with that bug.
<cherylj> dimitern: thanks for tracking it down
<dimitern> cherylj: :) yeah - if I looked more carefully earlier I would've been able to repro and fix it earlier..
<ahasenack> cherylj: :)
<natefinch> sinzui: has your MAAS come back up?  Wondering how the HA CI test fared
<dimitern> ahasenack: sorry ;)
<sinzui> natefinch: yes, let me see if I can find you two results. master consistently fails, but model-migrations passed
<ahasenack> I was the last standing witness, since cgregan wasn't seeing it anymore
<katco> does anyone know if we can still accept patches from people in the UK?
<dimitern> I bet he didn't go and set dns servers on subnets directly though, and it can't be repro'd with a default maas installation
<natefinch> katco: lol
<dimitern> katco: don't be nasty to the poor guys :D
<sinzui> natefinch: on master, HA is never reached: http://reports.vapour.ws/releases/4099/job/functional-ha-recovery-maas-1-9/attempt/8
<natefinch> sinzui: ok.  Does the same test pass on other substrates?
<sinzui> natefinch: the model-migrations branch passes http://reports.vapour.ws/releases/4097/job/functional-ha-recovery-maas-1-9/attempt/6
<katco> dimitern: lol wasn't meant to be a jab. commentary on isolationism, ramifications of that vote
<sinzui> natefinch: Yes, the test passes on aws, azure, and openstack
<dimitern> katco: :) jk
<katco> dimitern: how are you btw
<natefinch> sinzui: ok, good. That jives with my manual testing.
<dimitern> katco: tired.. I'm looking forward to getting back from the sprints hehe
<dimitern> but also for some beers while at them
<katco> dimitern: :)
<natefinch> sinzui: interesting that it passes on the model migration branch... thanks for that info, that could be very useful
<dimitern> somebody didn't use the pre-push hook recently..
<dimitern> checking: go vet ...
<dimitern> provider/openstack/firewaller.go:234: arg c.environ.Config().UUID() for printf verb %s of wrong type: (string, bool)
<dimitern> provider/openstack/firewaller.go:354: arg c.environ.Config().UUID() for printf verb %s of wrong type: (string, bool)
<dimitern> provider/openstack/firewaller.go:368: arg c.environ.Config().UUID() for printf verb %s of wrong type: (string, bool)
<dimitern>  
<natefinch> dimitern: I never use the pre-push hook.  If we don't enforce it on the bot, it's not a real rule.  But my editor runs go vet on save, so....
<dimitern> natefinch: good point, it should be part of what 'make check' does
<natefinch> dimitern: I also never use the makefile :)
<dimitern> natefinch: but the merge bot does ;)
<natefinch> dimitern: indeed.
<babbageclunk> forgot - I need to go home now while my wife goes to the doctor, but I'll be back online from there.
<katco> redir: standup time
<alexisb> all I will be out for a bit this morning, call my cell if somehting is urgent
<perrito666> bbl mail me if you need me urgnently ill be on and off all day
<perrito666> is there a way to ask state if a model is controller model?
<mup> Bug #1594865 changed: 2.0 beta8: deployment with sphere as provider - bootstrap node - no space left on /  <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1594865>
<voidspace> frobware: simple-ish one if you're still around http://reviews.vapour.ws/r/5162/
<frobware> voidspace: remind me again... what's the deal with omitempty and time?
<voidspace> frobware: it just doesn't work...
<voidspace> frobware: it gets omitted all the time
<voidspace> frobware: even when it's there - so you have to use a pointer
<frobware> voidspace: asked for an explanation in the review.
<frobware> voidspace: as in we add something explainging what doesn't work
<voidspace> ok
<frobware> voidspace: I'm rushing this; will look on monday as I need to go out
<perrito666> K going to London bbl
<katco> perrito666: safe travels
<voidspace> frobware: perrito666: bye o/
<perrito666> Man this referendum really broke my 1us 1eu chain :p
<mup> Bug #1596038 opened: typo in cloud definition yields "ERROR cloud <foo> does not require credentials" <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1596038>
<mup> Bug #1596039 opened: juju add-cloud should tell you what it did <landscape> <usability> <juju-core:New> <https://launchpad.net/bugs/1596039>
<mup> Bug #1596045 opened: Juju says windows mongo: invalid version <blocker> <ci> <mongodb> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1596045>
<perrito666> oi, I am partially back, now from the airport
<alexisb> perrito666, either that was a very short flight to london or something happened wtih your travels
<perrito666> alexisb: Cordoba airport
<perrito666> I was here incredibly early
<perrito666> exiting my lovely country requires bureaucracy so I decided that I wanted room just in case
<natefinch> yeah, I prefer to be super early, too.  Much rather mess around in the airport for an hour or so, than be running and scared I'm going to miss my flight.
<perrito666> ouch my screen is starting to show some serious screen burn I hope it will ive until laptop refresh
<katco> perrito666: what's the period on laptop refreshes?
<perrito666> katco: 3ys I believe
<katco> perrito666: cool
<natefinch> yeah, 3 years
<perrito666> that would be march for me
<katco> ericsnow: ping
<natefinch> July for me :)
<ericsnow> katco: pong
<katco> ericsnow: hey, trying to use the stub framework, but when i do .CheckCall i get this: "... mismatch at .FuncName: unequal; obtained "github.com/juju/juju/apiserver/observer/fakeobserver.(*Instance).Join"; expected "Join""
<katco> ericsnow: is there a way to make it not care about the namespace + type? what am i doing wrong?
<ericsnow> katco: it uses whatever you passed to Stub.AddCall()
<katco> ericsnow: ah ok. see if i can clean that up a bit, thanks
<ericsnow> katco: I'd recommend using a string literal in that call
<katco> ericsnow: i'm using reflection; seems more robust
<alexisb> anyone on the channel used dave's pprof command?
<mup> Bug #1596066 opened: Juju never achieves HA on maas 1.9 with trusty <blocker> <ci> <maas-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1596066>
<natefinch> alexisb: https://medium.com/@tjholowaychuk/profiling-golang-851db2d9ae24#.vlmpkj2tg
<mup> Bug #1596066 opened: In some configurations, juju never achieves HA on maas 1.9 with trusty <blocker> <ci> <maas-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1596066>
<mup> Bug #1596071 opened: api documentation should be written from a user perspective <landscape> <juju-core:New> <https://launchpad.net/bugs/1596071>
<natefinch> ericsnow: it looks like we don't ever call Priority.decode?
<ericsnow> natefinch: hmm, I thought there was a test that roundtripped it
<ericsnow> natefinch: thanks for that review :)
<marcoceppi> rick_h_ alexisb what's the over under on the api changing agian for beta11?
<rick_h_> marcoceppi: I'd not take any odds on that
<marcoceppi> rick_h_: I really /really/ want to update bundletester/amulet/deployer/python-jujuclient but if beta11 is likely to have more breakage I don't want to have developers constantly patching to keep up
<rick_h_> marcoceppi: I'd really hoped to have things frozen but it's not worked out that way and I've learned my lesson that I just don't think I can say anything with a really firm commitment there.
<rick_h_> marcoceppi: the big rename branch of Tim's missed some areas of the code that we're debating if it needs to be done or not now
<rick_h_> marcoceppi: so I know if several chunks that aren't determined as "go" or "no go" yet that will be breaking api changes
<marcoceppi> rick_h_: cool, I wasn't looking for a promise, just if there were still murmors
<rick_h_> marcoceppi: lots of murmors
<marcoceppi> rick_h_: cool, we'll evaluate the level of work, and keep an eye out for the next few days next week if there's any announcement of changes
<marcoceppi> +1 to the mails that have gone out so far announcing changes before they land
<marcoceppi> it's really helped us from getting soured when betas drop
<rick_h_> marcoceppi: yes, we'll be continuing that for sure. It's a case of "the least we can do" :)
<marcoceppi> \o/
<babbageclunk> ericsnow, natefinch: would either of you be able to review a bugfix for me? http://reviews.vapour.ws/r/5163/
<ericsnow> babbageclunk: sure
<babbageclunk> ericsnow: thanks!
<ericsnow> babbageclunk: LGTM
<babbageclunk> ericsnow: awesome.
<babbageclunk> ericsnow: See you on Monday!
<katco> oh dear god. emacs truly can do anything: https://github.com/Fuco1/clippy.el
<babbageclunk> katco: ha ha, I should install that.
<katco> babbageclunk: it looks like you're trying to install clippy.el
<babbageclunk> ericsnow: mind reviewing the dependency change for that too? http://reviews.vapour.ws/r/5164/
<babbageclunk> or katco, would you have a moment to review this? http://reviews.vapour.ws/r/5164/
<katco> babbageclunk: ship it
<babbageclunk> katco: sweet, thanks
<mup> Bug #1596104 opened: Can't kill a controller if the substrate is gone <v-pil> <juju-core:New> <https://launchpad.net/bugs/1596104>
<katco> anyone still around?
<redir> katco: :)
<katco> redir: yay! i have a small review for you
<redir> k
<katco> redir: http://reviews.vapour.ws/r/5165/
<katco> redir: it doesn't require any juju knowledge, so if you're comfortable, i think you can +1 it. it's gating some of my other work
<katco> redir: and i am just now seeing i should have implemented Increment and Decrement in terms of Add(n)
<redir> should I look later?
<katco> redir: no, new version up
<mup> Bug #1596104 changed: Can't kill a controller if the substrate is gone <v-pil> <juju-core:Invalid> <https://launchpad.net/bugs/1596104>
#juju-dev 2016-06-25
<perrito666> Hi reporting from Brazil on free wifi
#juju-dev 2017-06-19
<menn0> wallyworld or axw: https://github.com/juju/juju/pull/7512 pls
<wallyworld> sure, will do straight after standup
<wallyworld> menn0: lgtm, really great that this ForModel stuff is going away
<menn0> wallyworld: thank you
<wallyworld> axw: i forgit to ask you about bug 1680523 - could the issue the user is still having be cause he might need to upgrade to 2.2?
<mup> Bug #1680523: add-credential azure fails <juju:Triaged> <https://launchpad.net/bugs/1680523>
<axw> wallyworld: the latest reporter, Ali, is using 2.2 - you can tell by the "subscription (optional)" in the output
<axw> wallyworld: I have no idea why that issue is happening
<wallyworld> ok
<wallyworld> axw: is there any way we can ask him to provide azure cli logs or something, to allow us to see what might be happening or to pass on to ms if we need help diagnosing?
<axw> wallyworld: we got as much logging as we could from Tommy who had the same issue, and that wasn't helpful
<wallyworld> damn, ok
<axw> wallyworld: I've provided him a workaround for now. I've already asked MS for help, but so far they haven't come back with anything
<wallyworld> ok
<axw> I'll see if Uros can poke them
<menn0> jam: I'm back from the doc and need to take care of dinner and the kids so I can't make stand up
<menn0> jam: my wife is quite sick
<menn0> jam: I'll jump back on later though
<jam> menn0: k, take care of the family
<jam> menn0: will you be around for 1:1? or just later tonight/
<jam> I'm going to assume you're busy, but you can ping me if you're not
<jam> I'm happy to meet with you whenever you're around
<menn0> jam: i'm around now. it turns out my son has it too now.
<jam> menn0: but not the rest?
<menn0> jam: well my daughter had it when we were on holidays and I've had it as a child, so that's everyone I guess
<jam> menn0: full house... :)
<jam> menn0: so I have another phone call in 15, I'm happy to chat now, or if you'll still be around, in ~1hr?
<menn0> jam: indeed.
<menn0> jam: babbageclunk's family stayed with us over the weekend so hopefully they don't get it
<jam> menn0: my son was vaccinated for it when he was young, but it did make rounds around his school a couple years ago
<menn0> jam: it isn't part of the UK or NZ schedule
<menn0> jam: ironically it will be in NZ as of next week
<menn0> jam: regarding your comment here: https://github.com/juju/juju/pull/7513
<jam> menn0: I was wondering if we would actually want to change ForModel to just be "grab it from the pool"
<menn0> jam: that's not so straight forward
<menn0> jam: the only StatePool exists on apiserver
<jam> ah ok
<menn0> jam: I'm +1 on the name change though
<menn0> jam: StatePool *calls* ForModel when it needs to create a new one
<menn0> jam: I believe axw is pulling up the apiserver's StatePool so it can be used more widely by other controller workers
<menn0> jam: I actually wanted to discuss your comment about forward porting
<menn0> jam: I'm not against the idea of mass merging 2.2 into develop
<menn0> jam: my main concern is, that's a departure what we've usually done
<menn0> jam: who owns making sure that the merge happens?
<jam> menn0: its what we did (I did maybe primarily) for 2.0 to 2.1
<jam> I think Ian did some as well
<jam> menn0: Its mostly that when you land something on 2.2 is the point where you then merge it up
<jam> rather than someone doing it async, we just do it as part of landing your full patch
<menn0> jam: who do you mean when you say "we"?
<jam> menn0: each person when they work on something that lands in 2.2 then merges 2.2 into develop rather than proposing a different branch to develop
<menn0> jam: ok fair enough
<jam> menn0: I'm off the phone if you'd like to chat
<menn0> jam: sure, give me 2 mins
<menn0> jam: actually, make that 10
<jam> k
<menn0> jam: ok
<jam> menn0: https://hangouts.google.com/hangouts/_/canonical.com/john-menno?authuser=1
<thumper> FYI, taking swap day today
<veebers> thumper: glad to see you made it home safe, finally
<thumper> it was a long trip that's for sure
<thumper> I'm not really here
<thumper> :)
#juju-dev 2017-06-20
<menn0> wallyworld: easy review: https://github.com/juju/juju/pull/7516
<menn0> wallyworld: also, jam would prefer it if we did bulk merges from 2.2 to develop instead of targeted PRs for each forward port
<blahdeblah> Can anyone explain to me what's happening here when I try to upgrade juju 2.1.3 controllers to 2.2?  https://pastebin.canonical.com/191338/
<blahdeblah> It seems like 2.2 client -> 2.1.3 controller connections are fairly fundamentally broken.
<menn0> blahdeblah: hmmm, that doesn't look good. let me do some digging
<blahdeblah> thanks menn0
<blahdeblah> menn0: confirmed on another controller which has been working fine up until now:
<blahdeblah> [master*]paulgear@peleg:~$ juju status
<blahdeblah> ERROR unable to connect to API: malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16"
<menn0> ok
<blahdeblah> seems like it's trying to do http to an https port or something
<blahdeblah> I remember jam looking at something kinda similar with me recently, and I think it had something to do with some API requests being proxied and some going direct.
<menn0> blahdeblah: I'm setting up a repro. in case it is proxy related, do you have $http_proxy etc set on the client machine?
<blahdeblah> menn0: yep
<blahdeblah> https_proxy=http://127.0.0.1:3128/
<blahdeblah> http_proxy=http://127.0.0.1:3128/
<blahdeblah> no_proxy=localhost,127.0.0.0/8,::1
<blahdeblah> ftp_proxy=http://127.0.0.1:3128/
<menn0> blahdeblah: works fine for me without a proxy
<menn0> blahdeblah: trying with a proxy in the mix
<blahdeblah> menn0: No difference to me whether I do it with or without those proxy settings
<menn0> blahdeblah: very strange. I haven't been able to replicate yet.
<menn0> blahdeblah: brb
<menn0> blahdeblah: aha... if I have proxy settings set I get the same thing
<blahdeblah> that's progress, I guess; strange that it affects me when I unset them, though
<menn0> blahdeblah: it took about 10mins from the connection attempt to the "malformed HTTP response" error though
<blahdeblah> yeah - that's about how long it is for me
<menn0> blahdeblah: now that I look at the timestamps I see that you get that too
<blahdeblah> yep
<menn0> blahdeblah: I'll do some more digging
<blahdeblah> thanks - do you want a bug about this?
<menn0> blahdeblah: yes please
<menn0> blahdeblah: one likely cause is that we switched websocket libraries between 2.1 and 2.2
<blahdeblah> that would seem a strong candidate
<menn0> blahdeblah: to fix various issues
<menn0> blahdeblah: perhaps there's a difference in proxy handling
<blahdeblah> Seems like it :-)
<blahdeblah> https://bugs.launchpad.net/juju/+bug/1698989 created
<mup> Bug #1698989: Can't connect to controllers, juju status hangs for 10 minutes <juju:New> <https://launchpad.net/bugs/1698989>
<menn0> blahdeblah: thank you
<blahdeblah> thank you! :-)
<menn0> blahdeblah: I can definitely repro it when https_proxy is set, and it goes away with https_proxy is unsety
<menn0> blahdeblah: can you double check at your end?
<blahdeblah> Already did, and mentioned that in the  bug
<blahdeblah> Doesn't matter whether I set or unset the vars, it doesn't work
<blahdeblah> Which suggests to me that it's hiding a proxy setting somewhere else
<menn0> blahdeblah: you don't have transparent redirect to the proxy or something set up?
<blahdeblah> nope
<blahdeblah> Is there a way I can curl/wget the API endpoint directly to verify with/without the _proxy settings?
<menn0> I suspect you'll need a websocket client
<menn0> blahdeblah: hmmm... I just did some packet sniffing and it looks like the client is trying to send a proxy CONNECT straight to the Juju API server port
<blahdeblah> LOL
<blahdeblah> If we're using a proxy, ignore the proxy and try to use our API server as the proxy! :-)
<menn0> maybe something like that
<menn0> blahdeblah: it's still a mystery why disabling the proxy env vars doesn't work for you
<blahdeblah> indeed
<blahdeblah> but it should work with, regardless
<menn0> blahdeblah: for sure
<blahdeblah> (and did work on 2.1.3...)
<menn0> blahdeblah: I'm just wondering that's there's more to this
<menn0> blahdeblah: anyway, I'll do some digging through the gorilla websocket code
<blahdeblah> enjoy
<wallyworld> jam: here's a PR to improve update status hook firing. sadly, having the uniter efficiently be able to listen to just changes to that value and pick up the new one is somewhat non-trivial, so not done for now https://github.com/juju/juju/pull/7519
<jam> wallyworld: looking, found at least 1 typo so far, will finish review after standup
<wallyworld> ok, thanks
<wallyworld> jam: i fixed one, so refresh before looking again
<jam> wallyworld: kk, 'greater' vs 'less than'
<wallyworld> yup
<wallyworld> sigh
<jam> wallyworld: reviewed
<wallyworld> urty
<jam> ?
<wallyworld> jam: sorry, typo
<wallyworld> i responded to some comments
<wallyworld> the listen for changes thing is a lot of work potentially
<wallyworld> so you need to use --config when bootstrapping or adding a model really
<wallyworld> at least with the random times, existing models still get benefit
<wallyworld> that was my thinking anyway
<wallyworld> in any case, we can land this and follow up with work to listen for changes if there's time
<wallyworld> by we only have 1 day or so till release
<jam> wallyworld: do we have a way to change it during upgrade?
<wallyworld> whenever agents bounce, they will read any current value, but you can't set the value before upgrade because juju 2.2.0 foesn't know about the setting
<jam> wallyworld: juju upgrade-juju should take --config
<wallyworld> maybe, but it doesn't :-)
<wallyworld> would be nice though
<jam> wallyworld: I think we're missing it on upgrade-charm as well, essentially we need all the 'deploy' flags for upgrade
<wallyworld> it definitely would be nicd to add
<wallyworld> maybe something for the sprint
<wallyworld> jam: i think the issue last time with mandatory config was people using a newer client with an older juju?
<wallyworld> the trouble with accepting "" is that it hides config errors
<wallyworld> jam: i've added a second bit of bespoke default handling with a todo to remove later, and some testing for the timer value. could you PTAL? I've also pushed another PR to fix the monfig-config feature request for 2.2.1. off to soccer for a bit but back later
<jam> k
<stub> wallyworld, jam : https://bugs.launchpad.net/juju-core/+bug/1244841 is adding --config (and other deploy flags) to upgrade-charm. It also came up as part of storage, where if there are deployments of your charm you can never add mandatory storage because there would be no way to upgrade the existing deployments.
<mup> Bug #1244841: support atomic upgrade-charm --config var=val ... <canonical-webops> <config> <upgrade-charm> <juju:Triaged> <juju-core:Won't Fix> <https://launchpad.net/bugs/1244841>
<menn0> blahdeblah, jam: I found the proxy bug
<menn0> blahdeblah, jam: updating the ticket
<jam> menn0: I didn't see an update yet, so I might as well ask here what you found
<menn0> jam: it's there now
<jam> thanks menn0
<jam> I think we just kill the DNS cache
<menn0> jam: I'm beginning to agree
<menn0> jam: I was just reading your PR where you had reservations about the feature
<menn0> jam: the commentary seems to indicate the cache is important for cert validation
<menn0> is that actually true?
<jam> menn0: my understanding was that they needed to change what we were doing because of cert validation
<menn0> jam: I'll continue with this tomorrow
<menn0> jam: too tired to think too hard about it now
<menn0> jam: it seems like "killing the cache" will have to be done carefully
<jam> menn0: maybe, I'm happy to chat specifically about my understanding of it
<jam> Rog's patch seems more about ultimately dealing with slow DNS but otherwise handling the fact that we were tracking addresses in a way that conflicted with them wanting to force hostnames for JAAS controllers
<menn0> jam: that's why I said "carefully". we have to not break the JAAS requirements when winding some of this feature back.
<jam> menn0: yeah, my guess is that if we just don't do internal DNS caching, it will use existing DNS and just work
<jam> but testing, etc.
 * menn0 nods
<menn0> jam: and this is quite important to fix. I almost marked the bug as Critical
<jam> burton-aus: are you around?
<jam> we just got a weird failure in CI trying to land a patch
<jam> and it looks like a buggy script
<jam> http://juju-ci.vapour.ws:8080/job/github-merge-juju/11160/artifact/artifacts/windows.log
<jam> ['scp', '-oStrictHostKeyChecking=no', '-oServerAliveInterval=120', '-oUserKnownHostsFile=/tmp/tmpTtb9OC', '-i', '/var/lib/jenkins/cloud-city/staging-juju-rsa', 'juju-core_2.3-alpha1.tar.gz', 'Administrator@developer-win-unit-tester.vapour.ws:\'\nimport tempfile\nprint tempfile.mkdtemp(prefix=\'"\'"\'workspace-runner-\'"\'"\')\nc:\\users\\administrator\\appdata\\local\\temp\\workspace-runner-r1g7mn/ci\'/']
<jam> ' returned non-zero exit status 1
<jam> why would you have "scp" .... "import tempfile\nprint"
<jam> that looks like it is mixing 'ssh' and run python with 'scp' working files back out
<burton-aus> jam no idea, but I just triggered a re-run.
<burton-aus> jam nicholas was working on the windows machine.
<jam> k, I was looking to file a bug in case
<jam> burton-aus: offhand that looks like it interpreted a string wrong
<jam> burton-aus: like maybe that was supposed to decide what the name of the temp directory was
<jam> but instead it interpreted the literal string that was generating it
<jam> as the path
<burton-aus> jam I don't have knowledge on the windows slave. Nicholas was updating ssh key or something in the past several days.
<burton-aus> jam and by looking at several previous jobs they were not involved in windows run.
<burton-aus> jam from the latest email I received, nicholas is working on migrating and updating windows slaves.
<jam> burton-aus: rerun failed in the same way: http://juju-ci.vapour.ws:8080/job/github-merge-juju/11161/artifact/artifacts/windows.log
<burton-aus> jam maybe you want to draft an email to nicholas?
<burton-aus> jam he must know more details about that windows slave.
<jam> k
<jam> burton-aus: emailed
<burton-aus> jam got it.
<babbageclunk> wallyworld: ping? I saw that bug about subordinates and upgrading - looks like anastasiamac's working on it? jam wanted me to do some stress testing on the status history pruning so I'll do that otherwise.
<wallyworld> babbageclunk: sgtm, ty. just in release call. we may need you to help with the subord thing depending on how it goes. first up though, could you pretty please do a review of a yucky cmr pr? https://github.com/juju/juju/pull/7522
<babbageclunk> wallyworld: sure, looking now
<wallyworld> sorry in advance
<babbageclunk> ugh
<babbageclunk> ;)
<wallyworld> it's a lot of paper shuffling
<wallyworld> babbageclunk: assuming you get some scale testing done and your pr landed, could you take a look at this bug 1649936? it should be a straight logic error hopefully
<mup> Bug #1649936: Resources are getting deleted when juju remove-unit is issued <eda> <resources> <juju:Triaged> <https://launchpad.net/bugs/1649936>
<babbageclunk> wallyworld: ok
<menn0> babbageclunk: easy review pls? https://github.com/juju/juju/pull/7524
<babbageclunk> menn0: ok
<babbageclunk> menn0: approved
<menn0> babbageclunk: thanks
<thumper> ugh...
<thumper> brain fuzz starting already
<menn0_> thumper: insert more coffee
<thumper> I did
#juju-dev 2017-06-21
<wallyworld> menn0_: jeez, those dns caching prs affect the semantics of address / endpoint mgmt a fair bit, plus it seems a lot is required for cert validation. i wonder if a quick fix is just to poke in the no-op dns cache and leave the rest
<menn0_> wallyworld: I suspect it won't be so simple but I'm open to a quick fix if there is one. we should discuss at tech board.
<wallyworld> yep
<wallyworld> john will know more
<wallyworld> i was being optimistic
<menn0_> wallyworld: i've added this to the agenda
<wallyworld> sgtm
<babbageclunk> I really need to start reading reviews from bottom to top - things are made much harder by trying to understand api and apiserver changes before seeing the worker changes.
<thumper> I'll be able to make some of the tech board, but due to kid related taxiing, I'll miss the end
<wallyworld> thumper: do you think you'll get to this today? https://github.com/juju/juju/pull/7520 it's a request you made at comcast, so i'd figure i'd ask you to review :-)
 * thumper looks
<axw> wallyworld: I couldn't repro the resources bug, so I've marked Invalid and asked them for steps if it persists in 2.2.1
<wallyworld> ok, ta
<wallyworld> might have been fixed as part of other work
<wallyworld> i know stuff had been done in that area
<axw> yeah, possibly
<babbageclunk> wallyworld: approved
<wallyworld> babbageclunk: u r oarsome, ty
<axw> wallyworld: shall I look at the proxy bug?
<wallyworld> axw: on the tech board agenda, i feel john might know a bit of the top of his head. would be good if you took a peak before hand to get context
<axw> ok
<thumper> wallyworld: sorry for the dealy, had sparkies and visitors
 * thumper looks again
<wallyworld> tis ok
<thumper> I'm about to turn into a taxi again shortly...
<wallyworld> no worries, i'll deal
<axw> wallyworld: https://cloudplatform.googleblog.com/2017/06/Google-Cloud-Region-in-Sydney.html <- should try and get this in for 2.2.1?
<wallyworld> axw: yeah, although just need publicclouds.yaml update as we know, but should be trivial to add to code so it works ootb
<axw> yep
<axw> I'll send a PR shortly
<axw> hm, cloud-images needs updating
<thumper> wallyworld: a few questions
<thumper> and this https://github.com/juju/juju/pull/7525
<wallyworld> sure
<thumper> I'm about to drop kids at aerobics, and back for the tech board
<wallyworld> ok
<babbageclunk> wallyworld: I'm pausing for dinner, but I'll get the upgrade step done later tonight.
<axw> jam: https://github.com/juju/juju/pull/7529 is the small/short-term fix for the proxy issue. AFAICT, this is not unit-testable, because https_proxy is ignored if the target address is a loopback address
<jam> axw: can you do a lookup to get a non loopback address for your local machine?
<jam> most machines have them
<axw> jam: I have verified it on my machine. I guess I could do a lookup and skip the test if it can't find one
<jam> axw: seems like something like that would help us avoid regressing.
<axw> yeah. I'll have another shot in a sec, just reviewing a PR
<jam> most CI machines and developer laptops will have more than just localhost
<jam> wallyworld: I have a question about an upgrade test if you come online.
<jam> One of your tests isn't asserting what you think it is, but I'm not quite sure how to fix it
<wallyworld> jam: i'm here but a bit distracted or another 20 minutes
<jam> wallyworld: I emailed you, but if you want to ping me about it when you're aroud
<jam> ah, I have to go in 5min to take my son to piano, I'll be back in ~1hr but that may be too late. You can just respond to the email
<jam> it can probably wait till tomorrow
#juju-dev 2017-06-22
<wallyworld> babbageclunk: standup?
<babbageclunk> wallyworld: oh, sorry
<axw> wallyworld: "The remotefirewaller facade is removed and the ingress address watcher moved to the crossmodelrelations facade."  <- that's meant to say firewaller, not crossmodelrelations, right?
<wallyworld> axw: yeah, sorry, typo
<wallyworld> i'll correct the pr description
<axw> wallyworld: can we go over this PR together next week? does it need to land yet? I'm super foggy and struggling to consume it all at once
<wallyworld> axw: no worries, i'll just brnach off it for the next one
<wallyworld> the core firewaller change is 100 lines or so but there's the boilerplate all around it
<axw> wallyworld: thanks. I've left a few minor comments, just struggling to separate refactor from functional change atm, and don't want to let bits slip through the cracks, especially in the firewaller worker
<wallyworld> no worries.
<wallyworld> luckily the core of the worker itself for non-cmr is unchanged
<wallyworld> plenty of time next week
<wallyworld> can even pair review etc
<babbageclunk> wallyworld: can you take a look at https://github.com/juju/juju/pull/7542 please?
<wallyworld> sure
<babbageclunk> wallyworld: QAing it now
<thumper> ah fark
<wallyworld> babbageclunk: a couple of small things
<babbageclunk> wallyworld: thanks
<thumper> jam: https://github.com/juju/juju/pull/7543
<babbageclunk> wallyworld: The other IsBlahError functions in that file all take interface{} - I'm alright to change mine, but I wonder whether there's a reason for it.
<wallyworld> hmmm, not sure, let me look
<wallyworld> babbageclunk: i think it's just poor code tbh
<wallyworld> i can't see a reason for it
<babbageclunk> wallyworld: yeah, looking at other places they all take error - I'll change them.
<wallyworld> sgtm
<jam> thumper: lgtm
<thumper> jam: awesome
<thumper> jam: your pinger branch looks good to me, mostly comments about comments
 * thumper out
<babbageclunk> wallyworld: hmm, QA hitting problems - uniter is throwing errors with the new error message - tracking it down now.
<wallyworld> righto
<wpk> wallyworld: will you be merging 2.2 into develop anytime soon? There are some CMR conflicts there and I don't want to break it
<wallyworld> wpk: yes, as soon as final changes land
<wpk> wallyworld: kk
<wallyworld> don't worry about breaking thinhs, i can deal with it
<wpk> is the proces of moving issues from 'fix commited' to 'fix released' automatical?
<wallyworld> wpk: manual, but there's a script they can adapt to help
<wpk> https://github.com/juju/cmd/pull/52 anyone?
<babbageclunk> wallyworld: I think I've cracked it.
<babbageclunk> wa..
<babbageclunk> doh
<babbageclunk> wallyworld: I have not cracked it, I'm afraid. I need to discuss with you about it tomorrow. Sorry!
<wallyworld> babbageclunk: what's theissue
<babbageclunk> wallyworld: I keep finding more places that assume you can call relation.Unit for any unit of an application, which isn't really right, but I've made it an error.
<wallyworld> ah
<wallyworld> babbageclunk: so worst case, we just need to tell people to upgrade to 2.2.0 first
<wallyworld> and we haven't made it worse since it's broken anyway right now
<babbageclunk> It's not right because those RelationUnits are nonsensical - eg a wordpress subordinate logging unit in a mysql-logging relation.
<babbageclunk> Rught
<babbageclunk> Oops, right
<babbageclunk> but my PR is a fair bit away from being releasable
<babbageclunk> I mean, the one that isn't landed yet.
<wallyworld> babbageclunk: right, but in 2.2.1 everything is fixed right?
<wallyworld> so the only issue is people upgrading from 2.1.x
<wallyworld> and if they go via 2.2.0 they will be ok
<wallyworld> or have i missed something?
<babbageclunk> wallyworld: yeah, I think so - the errors I see are coming from things like unit.RelationsInScope, which constructs nonsensical RUs to call InScope on them, in which case it returns false so everything's fine.
<wallyworld> babbageclunk: ok. ideally of course we'd be able to go from 2.1.x straight to 2.2.1 but at least we have a work around
<wallyworld> we should still get the fix done asap
<babbageclunk> wallyworld: So maybe rather than having relation.Unit throw an error (which breaks lots of places that currently create nonsensical RUs), I could add an IsValid() and check that in the uniter API EnterScope.
<babbageclunk> wallyworld: make the sensibility check opt-in.
<wallyworld> babbageclunk: hmmm, that might work. is that unit API enterscope the the only vector via which the upgrade issue manifests itself?
<babbageclunk> wallyworld: I think so - might just be the only place I/we've noticed it.
<babbageclunk> wallyworld: I think I'm too zonked to think about it now though.
<wallyworld> babbageclunk: no worries
<babbageclunk> wallyworld: night!
<wallyworld> ttyl
<thumper> babbageclunk: is bug 1696509 fixed?
<mup> Bug #1696509: status-history-pruner fails under load <adrastea> <performance> <pruning> <statuseshistory> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1696509>
<babbageclunk> thumper: nope - I haven't had a chance to do the load testing that jam wants yet.
<thumper> ok
<thumper> I'll push it off
<babbageclunk> wallyworld: hey, so do you think I should pursue that IsValid thing I was talking about yesterday?
<wallyworld> babbageclunk: we were'nt going to but now it looks like a race needs fiing
<wallyworld> maybe see if there's a quick win
<babbageclunk> wallyworld: ok - the race is holding up the release anyway?
<wallyworld> at this stage, yeah
#juju-dev 2017-06-23
<wallyworld> axw: quick HO? 1:1
<wallyworld> thumper: you around?
<axw> wallyworld: just got back, brt
<babbageclunk> axw: take a look at https://github.com/juju/juju/pull/7547?
<babbageclunk> wallyworld: too late?
<wallyworld> babbageclunk: no, there's a unit test failure we're trying to fix
<wallyworld> i'll look
<babbageclunk> wallyworld: thanks
<wallyworld> babbageclunk: yeah, i think that looks good. a small surface area
<babbageclunk> wallyworld: cool, thanks - hopefully makes it in!
<wallyworld> it will :-)
<wallyworld> axw: interestingly, i now see the test fails without --race but succeeds with --race. it seems likely related to the mutex i added to fix the race failures
<axw> wallyworld: it doesn't matter whether you use -race or not, it's just time sensitive. I *think* the issue is due to flushing on ErrDying
<axw> not sure tho yet
<wallyworld> ok, i'll check back in soon hopefully
<wallyworld> axw: you may need to pull my branch and re-propose  if you get a fix done before i get back
<axw> wallyworld: ok
<wallyworld> tyvm
<wallyworld> axw: yeah, if we don't flush on dying that test passes and another fails
<axw> wallyworld: I think the test is kinda bogus, and shouldn't assume it'll return an error
<wallyworld> and now i can't get it to faio anymore
<wallyworld> *fail
<wallyworld> axw: i kinda agree
<wallyworld> i might just tweak the test not to check for that error
<wallyworld> it still checks that sync returns on shutdown
<wallyworld> axw: done that, will land now
<axw> wallyworld: we should probably have another tests that checks that that error is returned after the PingBatcher has completely stopped
<wallyworld> probably
<wallyworld> done
<thumper> wallyworld: for now
<wallyworld> thumper: tis ok
<thumper> ack
<wallyworld> axw: landing now, could you keep an eye out while i pop out and remerge if there's a spurious failure?
<wallyworld> babbageclunk: your pr failed
<babbageclunk> wallyworld: I saw - looks spurious
<wallyworld> faaaark
<wallyworld> yeah it does :-(
<axw> wallyworld: yep np
<babbageclunk> Running it under race detector now just to see
<wallyworld> babbageclunk: tempted to merge by hand
<wallyworld> so we can unblock the release
<wallyworld> but i gotta run out for an hour]
<wallyworld> veebers: burton-aus: race fix landing now. there's another pr from babbageclunk which just failed with a spurious error - we could merge that directly since CI will run the tests anyway
<wallyworld> i'll check back in a bit
<veebers> wallyworld: ack sounds good. Let us know which lands last, we'll check the build make sure everything is in there and watch the CI run
<axw> babbageclunk: I have to go out for a little while too, can you please let veebers know when your branch has landed? wallyworld's just finished
<babbageclunk> axw: wilco
<babbageclunk> Everyone's going out. I think I'll go out in a bit.
<blahdeblah> anyone able to give me a quick update on https://bugs.launchpad.net/juju/+bug/1676279 ?
<mup> Bug #1676279: canceling destroy-model prevents further calls to destroy-model to succeed <destroy-model> <list-models> <juju:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1676279>
<blahdeblah> anastasiamac: ^
 * anastasiamac looking
<anastasiamac> blahdeblah: yes, it would have been included in 2.2.0 as it was committed back in time for 2.2-b3.. I'll answer on the bug as well
<blahdeblah> thanks anastasiamac
<blahdeblah> also, any idea when 2.2.1 will be out?
<blahdeblah> Also, any clarification on https://bugs.launchpad.net/juju/+bug/1699050 as to whether the workaround which wgrant tested needs to be applied to each model?
<mup> Bug #1699050: remove-application regression on 2.1 -> 2.2 upgrade with subordinates <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1699050>
<blahdeblah> babbageclunk: ^
<babbageclunk> veebers: Hey, my PR's just landed: https://github.com/juju/juju/pull/7547
<anastasiamac> blahdeblah: aiming to release 2.2.1 today (last i've heard)
<blahdeblah> babbageclunk: that's the one for the last bug above?
<babbageclunk> blahdeblah: yup
<blahdeblah> cool - thanks
<blahdeblah> Anyone able to comment on https://bugs.launchpad.net/juju/+bug/1669046 as well?
<mup> Bug #1669046: juju-db very high load on primary controller unit <juju:Confirmed> <https://launchpad.net/bugs/1669046>
<veebers> babbageclunk: sweet
<babbageclunk> blahdeblah: I was answering your second question. (Just in case you weren't sure.) It'll be in 2.2.1.
<blahdeblah> yep
<veebers> babbageclunk: that went in after Ians pingbatcher fix right?
<babbageclunk> blahdeblah: so hopefully you don't need to apply the workaround?
<babbageclunk> veebers: I think so - just checking...
<blahdeblah> babbageclunk: Once 2.2.1 comes out?
<babbageclunk> veebers: yup
<babbageclunk> blahdeblah: yes
<blahdeblah> We're hoping that 2.2.x will resolve a number of our load issues, but since it was never confirmed that the root cause in 1669046 is 1676279, I wonder whether the former needs more diagnosis.
<veebers> babbageclunk: cool, once it gets a revision build we'll monitor it for release
<babbageclunk> Are we going to do a mass-merge from 2.2 to develop at some point, or should I be forward-porting things myself?
 * babbageclunk goes for a run for a bit
<wallyworld> babbageclunk: no, we will merge 2.2 into develop. i was waiting for all the things to land
<babbageclunk> wallyworld: yeah, I thought we'd probably be doing that again
<wallyworld> babbageclunk: yeah, all done :-)
<babbageclunk> wallyworld: nice one!
<babbageclunk> Booking my shuttle for the sprint - when are people mostly leaving the place? Don't want to be hanging out all by myself in Mooloolaba when everyone's already left! My flight's not until 7.
<babbageclunk> (on the Saturday)
<veebers> babbageclunk: I've only booked my shuttle from airport -> venue. Was going to book the return during the week
<babbageclunk> veebers: but you're missing out on a $6 saving!
<veebers> babbageclunk: hah true. But something better might pop up. In the past I've been able to hitch rides with people heading to the airport etc. Although I geuess this time around it's a bit more of a trip
<babbageclunk> veebers: Actually, I like your plan, I'm going to do the same.
<babbageclunk> And then say it was my idea all along.
<veebers> babbageclunk: well, if we get stranded and miss our flights you can take all the credit you want ^_^
<babbageclunk> Yay!
<veebers> babbageclunk: any idea how many hours (or days) your supposed to be at BNE before your flight?
<babbageclunk> Oh no - that's a good point, I'd forgotten to factor that into my return booking anyway.
<veebers> hmm
 * veebers needs to make sure he has enough clean cloths to pack
<veebers> Will have to break the shorts out of storage, that is if it's not frozen shut
<blahdeblah> You folks aren't coming in via MCY?
<blahdeblah> Much nicer :-)
<veebers> blahdeblah: I'm just glad there is a direct flight from Dunners and I don't need to be waiting around for hours between flights :-)
<blahdeblah> Yeah - pretty unlikely to get MCY direct to there, I guess.
<blahdeblah> veebers: BTW, standard in .au is 2 hrs for intl. flights; they might be a bit more lenient with NZ flights - not sure.
<blahdeblah> (that was re: being there before your flight)
<veebers> blahdeblah: ack thanks. That's about what I expected
<veebers> (considering the flights only 4 hours :-P)
<axw> wallyworld: whenever you're free, https://github.com/juju/juju/pull/7550 and https://github.com/juju/juju/pull/7551
<wallyworld> ok
<axw> wallyworld: so how do you did the forward port? branch off develop, merge 2.2, revert whatever things you don't want like version bump?
<wallyworld> axw: yeah. i only normally revert the version number in 3 places
<wallyworld> babbageclunk: i think we can close pr 7542
<wallyworld> as it is obsolete with the new, smaller fix
<babbageclunk> wallyworld: Yup yup
#juju-dev 2017-06-25
<mup> Bug #1697664 changed: Juju 2.X using MAAS, juju status hangs after juju controller reboot <juju:New> <https://launchpad.net/bugs/1697664>
