#juju-dev 2012-11-19
<rogpeppe> dimitern: mornin'
<dimitern> rogpeppe: morning :)
<dimitern> rogpeppe: say, where can I get the 'propose' command to setup lbox for goose?
<rogpeppe> dimitern: i think you can just apt-get lbox, assuming you've added the right repository
<rogpeppe> dimitern: except... what's goose?
<dimitern> rogpeppe: the go openstack exchange - lp:goose
<rogpeppe> dimitern: ah
<rogpeppe> dimitern: have you already got lbox?
<dimitern> rogpeppe: no, just apt-getting it
<rogpeppe> dimitern: i think you can just use it - no setup required
<dimitern> rogpeppe: ok, I got lbox now, but looking into juju-core, there's the .lbox file, containing: propose -cr -for lp:juju-core
<rogpeppe> dimitern: that's actually optional, but you probably want to create it and commit it
<dimitern> rogpeppe: if I create a similar one for goose in the root dir, it should be "propose -cr -for lp:goose" right?
<rogpeppe> dimitern: yup
<dimitern> rogpeppe: and then how do I actually use it? just run $ lbox propose ?
<rogpeppe> dimitern: yeah. i usually do "lbox propose -wip" first, so i can look at the changes on codereview before sending mail to people
<rogpeppe> dimitern: you might also want to copy the .lbox.check file
<rogpeppe> dimitern: which makes some checks before allowing the proposal
<rogpeppe> dimitern: in particular it doesn't allow you to propose code that's not gofmt'd
<rogpeppe> dimitern: which is a Good Thing
<dimitern> rogpeppe: ok, now after committing, running lbox propose -wip opens chrome at some lp authorize token url, which is blank..
<rogpeppe> dimitern: hmm, nothing you can enter your lp id/password into?|
<dimitern> rogpeppe: nah, just an empty Untitled page
<rogpeppe> dimitern: weird. what has it printed?
<rogpeppe> dimitern: lbox, that is
<dimitern> rogpeppe: hmm.. it seems the chrome-unstable i'm using is borked today
<dimitern> rogpeppe: in ff it works and asks what perms should I give to lpad
<dimitern> rogpeppe: Change Anything?
<rogpeppe> dimitern: i guess so
<TheMue> God morning, gophers.
<rogpeppe> TheMue: hiya
<dimitern> rogpeppe: any idea why lbox is insisting on launching chrome, when ff is my default browser?
<dimitern> TheMue: hey
<TheMue> rogpeppe, dimitern: Hi.
<rogpeppe> dimitern: no idea, sorry - it never launches any web browser for me
<TheMue> dimitern: Interesting, here it also never opens any browser. You do a "lbox propose" and it opens?
<dimitern> TheMue: I did propose -wip, and it says:  Go to your browser now and authorize access to Launchpad.
<dimitern> Press [ENTER] after authorization is confirmed...
<dimitern> TheMue: after which it opens a somehow broken chrome window with an authorize token link, but the page is empty, in fact any other page I try to open in the same chrome window is empty, but if I copy the url to firefox, it works and I authorized "lpad" there, but "lbox propose -wip" then still opens chrome!
<TheMue> dimitern: That's indeed strange. Have to dig into my old notices how I authorized access to LP.
<dimitern> TheMue: so, digging into lp:lpad's go source it seems it tries to call something called "sensible-browser" - never heard of it :) but that's the broken chrome
<TheMue> dimitern: Me neither.
<TheMue> dimitern: My notes sadly only say that lbox asks for access to LP. But it seems it found the right browser when I've done it. Because I haven't made any further notices.
<dimitern> TheMue: I fixed it! it seems even though firefox is a default browser, chrome managed to set itself as a gnome-www-browser and x-www-browser :)
<TheMue> dimitern: So there are multiple default browsers, interesting behavior.
<dimitern> rogpeppe: when I try "lbox propose -wip" now, after doing the oauth stuff successfully, it says: error: Failed to load data for branch lp:~/goose/client-auth-refactoring: resource not found (and I did push the branch)
<rogpeppe> dimitern: hmm, odd
<rogpeppe> dimitern: have you tried running it with --verbose --debug ?
<dimitern> no, i'll
<dimitern> rogpeppe: so it produces a whole lot of logs, but what to look for?
<rogpeppe> dimitern: good question - i haven't debugged it for ages :-)
<dimitern> rogpeppe: wanna see the paste of it?
<rogpeppe> dimitern: go on then.
<rogpeppe> dimitern: i probably won't be able to help though, i'm afraid
<dimitern> rogpeppe: http://paste.ubuntu.com/1369607/
<fwereade> morning all
<dimitern> fwereade: morning
<rogpeppe> fwereade: yo!
<dimitern> fwereade: maybe you can help me with lbox?
<fwereade> dimitern, perhaps :)
<dimitern> :)
<fwereade> dimitern, what's up with it?
<dimitern> so I installed it, added the .lbox and .lbox.check from juju-core, changed to lp:goose in .lbox, and then did propose -wip, launched a browser, I authorized it and then wanted to propose that branch (which has only these 2 files added)
<dimitern> and the verbose output I got, along with the error is pasted above
<fwereade> dimitern, lp:~dimitern/goose/client-auth-refactoring?
<dimitern> fwereade: well, it seems correct to me
<dimitern> and the branch is there
<fwereade> dimitern, oh hold on, it has lp:~/goose/...
<rogpeppe> fwereade: well spotted
<fwereade> rogpeppe, I'm suspicious that it doesn't actually matter though
<dimitern> fwereade: yes, but before I did bzr push lp:~/something... and it worked, i mean it resolved it to ~dimitern
<fwereade> dimitern, ah!
<rogpeppe> dimitern: it's quite possible that lbox doesn't work properly with that
<fwereade> dimitern, ok, cool, I had no idea you could do that :)
<rogpeppe> fwereade: neither me
<dimitern> fwereade: I asked jam and the guys before that bzr supports the ~ shortcut
<fwereade> dimitern, nice
<dimitern> fwereade: anyway, I should use the full name then probably, how to change it? .bzr/ something?
<rogpeppe> dimitern: try push --remember lp:~dimitern/goose/client-auth-refactoring
<rogpeppe> dimitern: and propose again and see what happens
<fwereade> +1
<dimitern> rogpeppe: well, did that, and then lbox propose -wip -v -debug and it again tried to push lp:~/goose/client-auth-refactoring :(
<rogpeppe> dimitern: hmm.
<rogpeppe> dimitern: how about deleting the branch within launchpad
<rogpeppe> dimitern: what does bzr info print?
<rogpeppe> dimitern: hmm, it's possible that the ~/ was baked into the original oauth request, i suppose
<dimitern> dimitern@kubrik:~/work/goose$ bzr info
<dimitern> Lightweight checkout (format: 2a)
<dimitern> Location:
<dimitern>   light checkout root: .
<dimitern>    checkout of branch: .bzr/cobzr/client-auth-refactoring
<dimitern>     shared repository: .bzr/cobzr
<dimitern> Related branches:
<dimitern>     push branch: lp:~/goose/client-auth-refactoring
<dimitern>   parent branch: .bzr/cobzr/master
<dimitern> and I did delete the branch and launched lbox propose again, same error, but the branch was pushed
<rogpeppe> dimitern: i know almost nothing about oauth though
<rogpeppe> dimitern: hmm, looks like it hasn't remembered properly
<dimitern> rogpeppe: seems so yes, but how to fix it?
<rogpeppe> dimitern: are you using cobzr?
<dimitern> rogpeppe: yes
<fwereade> dimitern, ~/.lpad? something like that to clear the stored auth, perhaps?
<fwereade> dimitern, delete it I mean
<rogpeppe> dimitern: in that case, try editing .bzr/cobzr/<branch name>/.bzr/branch/branch.conf
<rogpeppe> dimitern: and delete the push location. (in fact, what does the push location say there?)
<dimitern> push_location = bzr+ssh://bazaar.launchpad.net/~dimitern/goose/client-auth-refactoring/
<rogpeppe> hmm, that looks fine
<dimitern> :( man, these things always happen to me
<rogpeppe> dimitern: yeah, try deleting $HOME/.lpad_oauth
<rogpeppe> dimitern: they happened to me a lot until i learned not to tickle lbox's bugs
<dimitern> rogpeppe: I did delete it, run it again, same error
<rogpeppe> dimitern: did it ask you to authenticate again?
<dimitern> rogpeppe: yes, and I did
<rogpeppe> dimitern: was it still talking about ~/goose ?
<dimitern> 2012/11/19 09:40:04 Pushing branch: lp:~/goose/client-auth-refactoring
<dimitern> 2012/11/19 09:40:08 Branch pushed successfully.
<dimitern> and later on: 2012/11/19 09:40:09 Loading data for branch lp:~/goose/client-auth-refactoring...
<rogpeppe> dimitern: what does your .lbox file hold?
<dimitern> which fails
<dimitern> propose -cr -for lp:goose
<rogpeppe> dimitern: has a merge proposal been created in launchpad?
<dimitern> rogpeppe: no, does it have to be?
<rogpeppe> dimitern: no
<rogpeppe> dimitern: that's what lbox should create
<rogpeppe> dimitern: i'm just grasping at straws here
<dimitern> rogpeppe: maybe because -wip was passed?
<rogpeppe> dimitern: -wip shouldn't make any difference here
<rogpeppe> dimitern: it's failing before it gets to that stage
<dimitern> rogpeppe: so I don't have to propose it first from lp
<rogpeppe> dimitern: nope
<rogpeppe> dimitern: lbox should do all that
<dimitern> rogpeppe: yeah, I thought so
<rogpeppe> dimitern: hmm, i still think the root problem is that bzr info is printing the ~/ url
<dimitern> rogpeppe: ok, but even so it lbox still manages to push it correctly
<rogpeppe> dimitern: that'll be because it's using bzr to push it, and bzr understands the ~/ syntax
<dimitern> rogpeppe: so I found a but in lbox, as such
<dimitern> :)
<dimitern> s/but/bug/
<rogpeppe> dimitern: i am just speculating here. i don't know for sure.
<dimitern> rogpeppe: I think the problem is around here: http://bazaar.launchpad.net/~niemeyer/lpad/trunk/view/head:/branch.go#L16
<rogpeppe> dimitern: yeah, i'm looking in that area
<rogpeppe> dimitern: it's quite possible that launchpad doesn't handle the ~/ prefixes in getByUrl
<dimitern> rogpeppe: so then patching lpad slightly to cater for lp:~ -> lp:~user before calling getByUrl should work?
<rogpeppe> dimitern: i'm not sure it's the right fix, but i'd try it anyway - if it works, we know we're on the right track
<rogpeppe> dimitern: just hack it so it replaces ~/ by ~dimitern/
<rogpeppe> dimitern: 'cos i don't know that the Root knows the user name at that point
<rogpeppe> dimitern: what happens if you pull the branch under a different name?
<rogpeppe> dimitern: i.e. bzr branch lp:goose/trunk test-branch
<rogpeppe> dimitern: bzr switch test-branch
<rogpeppe> dimitern: lbox propose -for lp:goose -wip
<rogpeppe> dimitern: i wonder if that might work
<dimitern>  rogpeppe: I'm trying to patch lpad branch.go first
<rogpeppe> dimitern: ok
<dimitern> rogpeppe: after I change it, how can I recompile it?
<rogpeppe> dimitern: go install
<rogpeppe> dimitern: rather, go install launchpad.net/lbox
<dimitern> rogpeppe: but it's lpad actually
<rogpeppe> dimitern: if you've changed lpad, go instlling lbox will use the changed lpad
<dimitern> rogpeppe: ok, it worked so far
<dimitern> rogpeppe: It works with the patch!
<rogpeppe> dimitern: cool
<rogpeppe> dimitern: so we know what the culprit is!
<rogpeppe> dimitern: in the meantime, you could work around it, i think, by re-branching
<dimitern> rogpeppe: yeah
<dimitern> rogpeppe: rebranching?
<rogpeppe> dimitern: doing a cobzr branch, as i suggested above
<dimitern> rogpeppe: ok, btw it asked for www.google.com password at some point, and I used my @canonical one, but it seems it didn't like it
<rogpeppe> dimitern: hmm, have you used codereview.appspot.com before?
<dimitern> rogpeppe: no
<rogpeppe> dimitern: try going to that site - you may need to authorize with it separately
 * TheMue has to test code with root rights, somehow not nice.
<TheMue> Ah, found it, a little script is helping.
<TheMue> fwereade: ping
<fwereade> TheMue, pong
<fwereade> TheMue, sorry, didn't see the notification
<fwereade> TheMue, what can I do for you?
<TheMue> fwereade: NP, good morning btw.
<fwereade> TheMue, and yourself :)
<TheMue> fwereade: If I'm right you share Arams interest in a container abstraction between machine and unit in the state package. Am I right?
<fwereade> TheMue, yeah, I think so
<TheMue> fwereade: Could you please tell me more about your motivation behind it?
<fwereade> TheMue, it's mostly based on a feeling that it is a more "correct" model of the actual situation
<fwereade> TheMue, and that the principal stuff is kinda tacked on to unit
<fwereade> TheMue, and that it would probably be happier in its own type
<fwereade> TheMue, but I understand that such a change will have other consequences, and I'm open to being convinced otherwise
<fwereade> TheMue, what's your position?
<fwereade> TheMue, (I can also see advantages to the principal stuff on unit, so it's not 100% clear cut)
<TheMue> fwereade: One moment, I'm coming back in a few minutes here. Just helping my daughter, sorry.
<fwereade> TheMue, np
<TheMue> fwereade: So, back again, sorry again.
<fwereade> TheMue, np :)
<TheMue> fwereade: To me having the container as an extra type is more natural.
<TheMue> fwereade: Today the assignments of units are distributed, but a container could group them better and a machine could then manage/run/contain one or more containers.
<TheMue> fwereade: Additionally the implementation of the watchers would be more easy.
<fwereade> TheMue, doesn't the unit already have a list of its subordinates?
<fwereade> TheMue,     Subordinates   []string
<fwereade> TheMue, and the machine has a list of principals already
<fwereade> TheMue, so in either case a watcher can be implemented by watching a single entity (and then death-watching its dependants)
<fwereade> niemeyer, heyhey
<TheMue> fwereade: Yes, and the new approach would be that a Machine has a slice of Containers and each Container has a slice of units.
<niemeyer> fwereade: Good morning!
<fwereade> TheMue, I understand that, but I'm not sure that this change allows for a better implementation
<fwereade> TheMue, I'm with you on the "more natural" argument
<TheMue> fwereade: Each container would have one principal and the according subordinates.
<fwereade> TheMue, in this instance I don't see what we gain from the additional layer
<TheMue> fwereade: That's why I'm collecting different views and opinions, just to see, if it's worth to change it.
<fwereade> TheMue, personally I would like to change it but can't really justify it ;)
<TheMue> fwereade: As I understood Aram the implementation of watchers would be by far more simple.
<fwereade> TheMue, so if it were up to me I think I would regretfully resist the temptation :)
<niemeyer> TheMue: So all it takes is to explain why that's the case
<TheMue> niemeyer: Good morning.
<niemeyer> TheMue: Morning
<fwereade> TheMue, in either case it's a matter of a single entity watch -- the only difference is whether we're watching the unit (we can already do this) or adding a whole new type to watch
<TheMue> niemeyer: Yes, and that's why I'm currently collecting different views.
<fwereade> niemeyer, btw, this is roughly what I was babbling on about last week in the meeting
<fwereade> niemeyer, what the MA does to principals is the same as what a principal UA does to subordinates
<fwereade> niemeyer, the points of difference are (1) how to deploy and (2) what entity needs to be watched to detect new deployees
<niemeyer> fwereade: Yeah, I can see the correlation
<TheMue> fwereade: As Aram said the watching of machine and unit in one watcher is somehow, hmmm, bad maintainable.
<fwereade> niemeyer, this feels to me like a task
<niemeyer> fwereade: I just don't yet see the fallout of that
<niemeyer> fwereade: (how we use that fact in a way that's not trivial)
<niemeyer> TheMue: It doesn't matter how many people like it or don't like it.. we need to know the reasoning for doing it or not
<TheMue> niemeyer: Yep, that's why I'm simply collecting those pros and cons. To see if it's worth to change it or better to just keep it.
<niemeyer> TheMue: Do you have *any* reasoning for changing it yet that you could tell us about clearly?
<TheMue> niemeyer: Right now I'm only have some kind of gut feeling. That's not enough.
<fwereade> niemeyer, well, IMO the thing it would be nice to keep a single implementation of is the watching (notify of alive additions; watch each independently for death)
<fwereade> niemeyer, to do that we need (1) entity watchers not to return ids, because machine and unit watchers can't currently satisfy the same interface
<fwereade> niemeyer, and (2) machine and unit to have a common DependantUnits() []*Unit method
<TheMue> niemeyer: We're collecting it in https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit in "Add container abstraction" - "Motivation".
<fwereade> niemeyer, that feels to me like it's worth the effort
<niemeyer> fwereade: Yeah, but what then?
<niemeyer> fwereade: How do we use that in a way that is common?
<fwereade> niemeyer, and if we have a Container abstraction for deploying stuff (which we do, even if no containers are involved; it's the Deployment abstraction we had in py)
<fwereade> niemeyer, the Machiner already takes a Container, doesn't it?
<niemeyer> fwereade: Not sure.. looking
<fwereade> niemeyer, so it's the difference between fixing Machiner to do the right thing [wait, ECONTEXT, that might have changed], and turning it into a Placer which does the
<fwereade> niemeyer, ...right thing in both cases
<fwereade> niemeyer, yeah, machiner is still using Added/Removed
<niemeyer> fwereade: Yeah, that's in review
<fwereade> niemeyer, ah ok
<niemeyer> TheMue: There's no clear motivation there
<niemeyer> TheMue: Saying it simplifies "foo" requires a leap of faith that I'm not willing to concede on without further analysis
<TheMue> niemeyer: One moment
<niemeyer> TheMue: The change being suggested isn't free.. it's not *less* code
<niemeyer> TheMue: It's *more* code, *more* logic, *more* entities
<niemeyer> fwereade: Sounds good re. that stuff
<niemeyer> fwereade: I don't think the ids are specially interesting so far
<niemeyer> fwereade: I think we have perhaps a couple of places that actually use them
<niemeyer> fwereade: and that's in testing
<fwereade> niemeyer, yeah, and if you started a watch you know what you're watching anyway
<fwereade> niemeyer, yep
<niemeyer> fwereade: Right, we can always bundle the id in when we really care
<TheMue> niemeyer: As I understood Aram the code is simple and would lead to less and better maintainable code, especially for the watchers.
<niemeyer> TheMue: Repeating things doesn't make them true :-)
<niemeyer> TheMue: What we need is a clear analysis of why that is so
<niemeyer> TheMue: If you're not able to articulate why that is the case, it means you don't understand it yourself
<TheMue> niemeyer: That's what I'm trying. Collecting pros and cons and imlementation details.
<niemeyer> TheMue: So you should try to convince Aram that this isn't the case, until you do understand why
<niemeyer> TheMue: It's more important to be able to talk about things like that in a way we can brainstorm on, than to file up a bullet list
<TheMue> niemeyer: Did you read the docuument? What do you say about the details there so far?
<niemeyer> <niemeyer> TheMue: There's no clear motivation there
<niemeyer> <niemeyer> TheMue: Saying it simplifies "foo" requires a leap of faith that I'm not willing to concede on without further analysis
<TheMue> niemeyer: So would be less and clearer code with better maintainability an argument for you?
<niemeyer> TheMue: I'm concerned we're getting side-tracked onto that kind of detail that doesn't really make a difference at the moment and not making any significant progress towards implementing support for what we have to
<niemeyer> TheMue: Definitely would
<niemeyer> TheMue: But saying "you don't need to write that watcher" isn't it
<fwereade> niemeyer, (hey, a sudden thought: there is one case where we *do* want something out of an entity watcher: that's the TxnRevno for config settings)
<niemeyer> TheMue: Because you need to add a whole new entity to the system with everything it takes instead
<niemeyer> TheMue: So "less code" must include everything you need to *add* as well
<fwereade> niemeyer, (how would you feel about standardizing entity watchers on that?)
<niemeyer> fwereade: Do we ever use that value for entities?
<fwereade> niemeyer, only if you consider a settings node to be an entity :)
<niemeyer> fwereade: Right :-)
<TheMue> niemeyer: Sure, my feeling so far is, that we may reach todays features with less and more clear code, but I'm not yet sure. That's why I'm collection different opinions to discuss it with Aram when he's back.
<niemeyer> fwereade: I wasn't considering that yet
<niemeyer> <niemeyer> TheMue: Repeating things doesn't make them true :-)
<niemeyer> <niemeyer> TheMue: If you're not able to articulate why that is the case, it means you don't understand it yourself
<fwereade> niemeyer, I'm working from a perspective from which I perceive single-thing watchers, and many-thing watchers, and feel that their respective commonalities are worth enhancing
<niemeyer> TheMue: Which is fine on itself
<fwereade> niemeyer, hey wait
<niemeyer> TheMue: But it means you should try to understand why *you* want it to be done
<fwereade> niemeyer, if we *did* return txnrevno, perhaps we can have only one single-thing watcher implementation
<niemeyer> TheMue: Because so far it feels like "Hey, I want to build my own house.. please tell me why I should do that."
<TheMue> niemeyer: Yes, absolute. That's why I wrote "gut feeling" and why I try to understand it instead of saying "We have to change it.". And here your, Williams and Arams input do help me (beside reading the code.).
<niemeyer> fwereade: I'm slightly concerned with the idea of binding txn-revno to it
<niemeyer> fwereade: Watchers don't necessarily have a 1-to-1 event-to-revno-change correlation
<fwereade> niemeyer, I *think* that single-entity watchers do, don't they?
<niemeyer> fwereade: Perhaps they do for now, but that's not necessarily the case
<niemeyer> fwereade: We could easily decide to fire a, say, unit's watcher based on a correlated value
<fwereade> niemeyer, yeah, granted
<fwereade> niemeyer, cheerfully withdrawn for now
<fwereade> ;)
<niemeyer> fwereade: I think settings are the exception on that
<niemeyer> fwereade: I do appreciate your core motivation, though
<fwereade> niemeyer, cheers :)
<rogpeppe> niemeyer: based on your comments in a later CL, i've decided to use "CA" for everything related to the root CA certificate, and i'm losing the "root" qualifier entirely. does that sound reasonable?
<rogpeppe> niemeyer: morning, BTW!
<rogpeppe> niemeyer: for example: http://paste.ubuntu.com/1369804/
<niemeyer> rogpeppe: It does
<niemeyer> rogpeppe: I think it's a short and unambiguous way to talk about the concept internally and on docs
<rogpeppe> niemeyer: there's also the potentially interesting thing that it might not necessarily be a root
<niemeyer> rogpeppe: Indeed
<fwereade> lunch, bbiab
<niemeyer> fwereade: Enjoy!
<rogpeppe> niemeyer: what do you think about CAPEM vs CA_PEM vs ... ?
<rogpeppe> niemeyer: actually... maybe just CACert is sufficient.
<niemeyer> rogpeppe: +1 on the latter
<fss> niemeyer: morning :-)
<niemeyer> fss: Heya
<fss> niemeyer: how is that iam CL going?
<niemeyer> fss: Haven't seen much attention, has it
<niemeyer> fss: I'll try to give it some love this morning still
<niemeyer> fss: After the currently going batch of reviews
<fss> niemeyer: great, thanks! :)
<niemeyer> fss: You've got a review there, thanks for the change btw
<fwereade_> rogpeppe, does this look familiar?
<fwereade_> ----------------------------------------------------------------------
<fwereade_> FAIL: bootstrap_test.go:42: bootstrapSuite.TestBootstrapKeyGeneration
<fwereade_> bootstrap_test.go:45:
<fwereade_>     c.Assert(err, IsNil)
<fwereade_> ... value *errors.errorString = &errors.errorString{s:"cannot generate CA certificate: canot create certificate: ASN.1 structure error: PrintableString contains invalid character"} ("cannot generate CA certificate: canot create certificate: ASN.1 structure error: PrintableString contains invalid character")
<fwereade_> OOPS: 17 passed, 1 FAILED
<fwereade_> --- FAIL: Test (8.12 seconds)
<fwereade_> FAIL
<fwereade_> FAIL	launchpad.net/juju-core/juju	8.171s
<rogpeppe> fwereade_: hmm, i don't think i've seen that before
<rogpeppe> fwereade_: you've just pulled from trunk, i presume
<fwereade_> rogpeppe, yeah
<fwereade_> rogpeppe, haven't tried trunk directly yet, just a mo
<rogpeppe> fwereade_: it might be a problem in 1.0.3 but not in tip i suppose
 * niemeyer => lunch
<rogpeppe> fwereade_: i'm just building 1.0.3 to test
<rogpeppe> fwereade_: yup, that's the issue
<rogpeppe> fwereade_: will fix, one mo
<fwereade_> rogpeppe, lovely, thanks
<rogpeppe> fwereade_: hmm, i'm not sure what the best solution is here. looks like it's issue 3791, fixed by this CL https://codereview.appspot.com/6348074
<rogpeppe> fwereade_: however i'm not entirely sure i *want* the string to turn into a utf-8 string
<fwereade_> rogpeppe, ehhh, yes, tricky
<rogpeppe> fwereade_: i'll check it works against mgo
<rogpeppe> fwereade_: if it does, i'll go with it
 * rogpeppe can't believe quite how crap x509/asn1 is
<fwereade_> niemeyer, fwiw, http://paste.ubuntu.com/1370176/ just happened
<rogpeppe> niemeyer, fwereade_: fix trunk: https://codereview.appspot.com/6842065/
<rogpeppe> niemeyer, fwereade_: one alternative would be to use single-quotes, i suppose
<rogpeppe> niemeyer: which i believe are allowed
<fwereade_> rogpeppe, LGTM
<rogpeppe> fwereade_: i'll submit it now, and we can change it later if someone disagrees
<rogpeppe> fwereade_: done
<fwereade_> rogpeppe, cheers
<fwereade_> TheMue, rogpeppe: what (if anything) has been your involvement in recent machine unit watching discussions?
<fss> niemeyer: thanks, i will take a look later today
<fwereade_> TheMue, rogpeppe: because I'm a bit confused about unassignment
<TheMue> fwereade_: Only talked with Aram about implementation details so far. About how a container would make it more simple.
<TheMue> fwereade_: In which way confused?
<fwereade_> TheMue, well, we're watching for unassignments that never happen and don't matter, but ignoring the deaths that do happen and do matter, or so it seems to me
<fwereade_> TheMue, I was hoping someone would explain why we're watching for them when there's no forseeable use case
<fwereade_> TheMue, ATM, once the machiner is properly done, it will be (indirectly) responsible for the unassignment
<fwereade_> TheMue, if other things unassign, which one day perhaps they may, that should also be watched for, but as it is they don't
<fwereade_> TheMue, (also, UnassignFromMachine probably shouldn't even exist at the moment... it should be rolled into any unit destruction transaction)
<TheMue> fwereade_: Yo see me puzzled.
<fwereade_> TheMue, no worries :) is aram on holiday atm?
<TheMue> fwereade_: Let's try to sort it again.
<TheMue> fwereade_: Yes, he is to a memorial. :(
<fwereade_> :(
<TheMue> fwereade_: No good reason.
<TheMue> fwereade_: Or better said: A sad reason.
<fwereade_> TheMue, ha, yeah, the first formulation is unhelpfully ambiguous
<fwereade_> TheMue, ok, can I explain what I think should be going on? please jump in if I say anything that gives you pause
<TheMue> fwereade_: Exactly. In the moment I read it I felt so.
<TheMue> fwereade_: Yes, let's do so
<fwereade_> TheMue, the MA and the UA are both responsible for the lifetimes of other units
<fwereade_> TheMue, the MA for its principals and that UA for its subordinates
<fwereade_> TheMue, in each case, the agent is responsible for 2 things
<fwereade_> TheMue, 1) detecting new, alive units, and deploying them
<fwereade_> TheMue, 2) detecting Dead units and destroying them
<fwereade_> TheMue, any uncertainty/ambiguity thus far?
<TheMue> fwereade_: So far e'thing ok.
<fwereade_> TheMue, cool
<fwereade_> TheMue, hum, actually, I think I need to go back further
<TheMue> fwereade_: Adam and Eve?
<fwereade_> TheMue, can you explain to me the deal with assignment in general? specifically why it's separate from unit creation, and whether it actually should be
<fwereade_> s/creation/creation and destruction/
<fwereade_> TheMue, ie I'm not so interested in historical reasons unless they still apply
<fwereade_> TheMue, is there any time it makes sense for a principal unit not to be assigned to a machine?
<TheMue> fwereade_: In the firewaller the machineData, which represents one machine, watches for its units. This is needed to see, if ports on the mache have to be opened/closed.
<fwereade_> TheMue, I understand that units need to be assigned to machines
<fwereade_> TheMue, I don't see why we're not doing the assignment/unassignment in the unit add/remove transactions
<TheMue> fwereade_: Yes, here the new (currently in review) approach of Aram shall watch all assignments. Today only the principals are watched.
<fwereade_> TheMue, subordinates can't be assigned
<niemeyer> fwereade_: Cheers
<TheMue> fwereade_: Sorry, I'm lost in the last step.
<fwereade_> TheMue, assignToMachine will barf if you pass it a subordinate
<fwereade_> TheMue, subordinates are in fact deployed on machines but they're not "assigned" to them
<TheMue> fwereade_: OK
<fwereade_> TheMue, wait, there's the principals watcher currently in review
<fwereade_> TheMue, the firewaller's all-units watcher is a separate problem I think
<TheMue> fwereade_: Aram has a change to the watchers in review, one also leads to a change in the firewaller.
<TheMue> fwereade_: Which problem do you address if it's not the usage of Machine.WatchUnits() inside the Firewaller?
<fwereade_> TheMue, I'm talking about the principals watching that is in review
<dimitern> fwereade_: quick go question: I need to pass io.Reader as the request body, and I have data []byte, how to get io.Reader for []byte?
<dimitern> rogpeppe: maybe? ^^
<rogpeppe> dimitern: see bytes.Reader
<rogpeppe> dimitern: or bytes.Buffer
<dimitern> rogpeppe: 10x!
 * niemeyer has to step out for appointment
<niemeyer> See y'all later
<TheMue> CU
<fwereade_> TheMue, rogpeppe: either of you free to talk about the machiner a little bit more?
<rogpeppe> fwereade_: np
<fwereade_> TheMue, rogpeppe: ISTM that the machiner will need to be a little bit stateful
<TheMue> fwereade_: One moment, just want to propose a golxc branch.
<rogpeppe> fwereade_: how so?
<fwereade_> TheMue, rogpeppe: ie it will need to know what it's deployed so it can reconcile when the process bounces
<rogpeppe> fwereade_: can it not tell what it's deployed by looking at the upstart services?
<fwereade_> rogpeppe, scan all upstart processes for names that look right? I guess so
<fwereade_> rogpeppe, feels a bit icky though
<rogpeppe> fwereade_: i dunno. it's gotta have control of that name space anyway, and it's the one that's adding or removing from it.
<rogpeppe> fwereade_: if we didn't do that, we'd only be mirroring that information somewhere else
<fwereade_> rogpeppe, I'd prefer to mirror that information somewhere I explicitly control rather than assume that nothing else will cause a juju-* upstart job to be created
<rogpeppe> fwereade_: if something else causes a juju-* upstart job to be created, we might well be shafted anyway
<rogpeppe> fwereade_: what if someone else does that and then we try to actually start a job with that name?
<rogpeppe> fwereade_: i think it's fair to say "mess with juju-* upstart services at your own risk"
<rogpeppe> fwereade_: and we could obfuscate the name space if we want
<rogpeppe> fwereade_: e.g. use a uuid prefix or something
 * rogpeppe prefers to keep one canonical source for information
<fwereade_> rogpeppe, my point is really that the machiner doesn't take anything like that into account
<rogpeppe> fwereade_: agreed. it definitely should.
<rogpeppe> fwereade_: it's been on the cards for ages
<fwereade_> rogpeppe, ok, this feels like something that is also basically common between the UA and the MA
<rogpeppe> fwereade_: definitely.
<rogpeppe> fwereade_: i definitely think we should use the same code for both
<dimitern> rogpeppe: is there something like "if elem in slice", given elem int, slice []int ?
<rogpeppe> dimitern: a for loop :-)
<dimitern> ideally, w/o iterating over the slice with range?
<dimitern> ok :)
<rogpeppe> dimitern: it's only three lines
<fwereade_> dimitern, you'll get used to it -- it's a simpler, happier life :)
<dimitern> rogpeppe: yeah, i'm just lazy :)
<mgz> it's not really laziness dimitern, fear of newlines maybe :)
<dimitern> mgz: :D
 * rogpeppe has reached the end of day.
<rogpeppe> g'night all
<niemeyer> fwereade_: Wow, consolidate-entity-watcher is impressive
<fwereade_> niemeyer, yeah, was a great surprise :)
<niemeyer> fwereade_: A nice one even :-)
<fwereade_> niemeyer, great in both senses :)
<niemeyer> fwereade_: +1 (or -N  depending on the perspective ;)
<fwereade_> niemeyer, haha :)
<fwereade_> niemeyer, btw, you were suggesting I shepherd aram's branch in while he's away?
<niemeyer> fwereade_: Yeah, if you're feeling like you'd benefit from it being in, it feels like it's pretty much done
<fwereade_> niemeyer, I have fairly significant issues with the Machiner in that proposal but they're all things I anticipate needing to address anyway
<fwereade_> niemeyer, and none of them are regressions
<fwereade_> niemeyer, so, ok, I'll branch that and see what I can pull together from the old comments
<niemeyer> fwereade_: Cool, I'd be certainly be delighted to see that polished with more context
<rogpeppe> fwereade_: what's consolidate-entity-watcher?
#juju-dev 2012-11-20
<fss> niemeyer: ptal https://codereview.appspot.com/6823060/
<niemeyer> fss: Will do, but tomorrow! :)
<fss> niemeyer: np
<fss> :-)
<fss> niemeyer: time to sleep
<niemeyer> fss: Yeah, here too
<fss> niemeyer: see you
<fss> niemeyer: adios
<niemeyer> fss: Have a good one
<fss> niemeyer: thanks, you too
<wallyworld_> jam: hi, got time for a chat?
<jam> sure wallyworld_
<jam> wallyworld_: here or on mumble?
<wallyworld_> mumble easier
<TheMue> Morning.
<fwereade_> TheMue, heyhey
<TheMue> fwereade_: Hello.
<fwereade_> TheMue, how's it going?
<TheMue> fwereade_: Fine, having first progress with LXC.
<TheMue> fwereade_: And you?
<fwereade_> TheMue, not bad, kinda still drawing together the threads of everything I have to do, but getting there
<TheMue> fwereade_: Oh, reminds me of Marks mail. Have to continue with it.
<fwereade_> TheMue, yeah, me too :)
<TheMue> fwereade_: At least I already entered my vacation. But not yet my Copenhagen travel costs.
<rogpeppe> fwereade_, TheMue: morning
<TheMue> rogpeppe: Hiya.
<fwereade_> rogpeppe, heyhey
<rogpeppe> fwereade_: i saw niemeyer mention consolidate-entity-watcher last night. is that a branch of yours? i couldn't see it anywhere.
<fwereade_> rogpeppe, yeah, it also went in last night
<fwereade_> rogpeppe, unit/machine/service watchers are now all just EntityWatcher
<rogpeppe> fwereade_: cool
<rogpeppe> fwereade_: i searched for "consolidate-entity-watcher" and it didn't find anything
<fwereade_> rogpeppe, hum, I think it's -watchers
<fwereade_> rogpeppe, https://codereview.appspot.com/6856060
<rogpeppe> fwereade_: yeah, that's my point - i found it just now, but i didn't find it last night
<rogpeppe> fwereade_: gmail isn't so good at approximate searches
<fwereade_> rogpeppe, ah, got you
<rogpeppe> fwereade_: really nice to see that go in, thanks for doing it!
<fwereade_> rogpeppe, cheers, a pleasure :)
<fwereade_> bah, I said I'd take over a branch of aram's but it's got a prereq I didn't spot
<TheMue> fwereade_: Which one?
<fwereade_> TheMue, https://codereview.appspot.com/6814108/ depends on https://codereview.appspot.com/6820112/
<TheMue> fwereade_: Will take a look.
<fwereade_> TheMue, I think they may actually be independent enough that I can just focus on the one I need; we'll see
<fwereade_> TheMue, I don't think they need anyone else to look, I'm just grumbling :0
<TheMue> fwereade_: Hehe
<TheMue> fwereade_: I've been involved in discussions about the second one.
<TheMue> fwereade_: The changing of the firewaller lead to a breaking test.
<TheMue> fwereade_: It's the test for the global mode.
<fwereade_> TheMue, ah, yes, I overheard some of them but wasn't following closely
<fwereade_> TheMue, that just increases my determination to avoid that branch if I can ;p
<TheMue> fwereade_: :D
<jam> wallyworld_: we're on mumble whenever you're back around
<fwereade_> ok, this is really just starting to drive me mad
<fwereade_> can anyone think of any problematic consequences to just changing the type of machine and relation id to string?
<fwereade_> rogpeppe, TheMue: ^?
<rogpeppe>  fwereade_: there are few places where the relationship between machine id and instance id might become less clear
<rogpeppe> fwereade_: but in general i'm +1
<TheMue> fwereade_: Do we use them numerical, e.g. by auto-incrementing it for new instances?
<fwereade_> TheMue, ah, hmm
<fwereade_> TheMue, yes, but that shouldn't be a problem
<TheMue> fwereade_: Then I see no problem. Typically I prefer alphanumerical identifier.
<fwereade_> TheMue, rogpeppe: cool, thanks, I think I'll give it a go then :)
<TheMue> fwereade_: old school for me is, that numbers should only be used for calculating :)
<rogpeppe> fwereade_: it'll be a fairly substantial job - juju status might be awkward
<fwereade_> TheMue, sounds like a solid rule to me :)
<TheMue> fwereade_: cheers
<rogpeppe> fwereade_: i'd be tempted to add a prefix that indicates the machine-id-ness of the id
<rogpeppe> fwereade_: but that would be bad for backward compatibility
<fwereade_> rogpeppe, yeah, I don't *really* like the pure-number id but at least it makes it easy to distinguish in the places where there's ambiguity
<fwereade_> rogpeppe, eg juju status, actually :)
<fwereade_> rogpeppe, (I don't think the type change should be a big issue there... biggest consequences seems to be that we'll drop the jsonify func, which feels like a hack itself)
<rogpeppe> fwereade_: yeah, i think it should end up cleaner
<fwereade_> rogpeppe, (although I might hold off until I have a word with niemeyer...)
<rogpeppe> fwereade_: maybe a good plan
<niemeyer> Morning all!
<TheMue> niemeyer: Morning.
<niemeyer> TheMue: Yo
<dimitern> niemeyer: morning
<fwereade_> niemeyer, heyhey
<fwereade_> niemeyer, what would be your reaction to an attempt to just turn all machine/relation ids into strings?
<niemeyer> fwereade_: Hmm
<niemeyer> fwereade_: I'd of course resist before you actually explain the idea :-)
<fwereade_> niemeyer, this was primarily motivated by observing that AFAICT the services and machines watchers are trying to do the same thing, but actually don't
<niemeyer> fwereade_: Trying to do the same thing in which sense?
<fwereade_> niemeyer, watch a collection for life changes
<niemeyer> fwereade_: So you're saying that if we made them the same type, we'd get rid of another watcher?
<fwereade_> niemeyer, yeah
<fwereade_> niemeyer, I also suspect that anther couple *might* collapse into nothingness as well but it's not entirely clear whether that's a winning move
<fwereade_> niemeyer, I'd prefer not to get ahead of myself there ;)
<niemeyer> fwereade_: I'd be fine with that.. it's been suggested before, but it was more of a gut feeling than a practical advantage
<niemeyer> fwereade_: Although, hmm
<niemeyer> fwereade_: There's some reasonable benefit in using ids in the database too, I guess
<niemeyer> I mean, ints
<fwereade_> niemeyer, I wouldn't be too opposed to that in principle, but I'm not sure how significant the benefit will be in practice... would yu expand, I might be missing something?
<fwereade_> niemeyer, if it's significant then ofc it beats local convenience
<niemeyer> fwereade_: Well, it's indeed hard to say how relevant it will be in practice, taking everything else into account, but there's some nice benefits of using ints in fields and indexes
<niemeyer> fwereade_: 4B machines in four well-aligned bytes
<fwereade_> niemeyer, how about units? if the cost of string keys is significant, we should maybe be thinking about int ids for everything...
<fwereade_> niemeyer, we'll have roughly the same number of units as we do machines (at a minimum)
<niemeyer> fwereade_: Units need composed keys?
<niemeyer> fwereade_: Agreed
<niemeyer> fwereade_: But is your argument that we should use the lowest denominator for all? :)
<fwereade_> niemeyer, my argument is that using different types for different entity ids is unhelpful at the state level, because we end up with unnecessary complexity that's almost certainly significant enough to harbour bugs
<niemeyer> fwereade_: I was referring to this, specifically:
<niemeyer> <fwereade_> niemeyer, how about units? if the cost of string keys is significant, we should maybe be thinking about int ids for everything...
<fwereade_> niemeyer, it may be that some aspect of some entity is enough at odds with this to sink the whole idea, but if so I don't yet see it
<niemeyer> fwereade_: I'm still playing devil's advocate
<niemeyer> fwereade_: Maybe we should change, but it's important to acknowledge those differences and take them into account
<fwereade_> niemeyer, my argument is that we should use any type we can find that has acceptable tradeoffs across the board, but that we should ideally go with a single id type
<fwereade_> niemeyer, sorry, that was poorly stated, hopefully still clearish
<niemeyer> fwereade_: Yes, but I haven't seen many positive tradeoffs so far
<niemeyer> fwereade_: The MachineWatcher has ~30 lines
<niemeyer> fwereade_: ~40 maybe
<niemeyer> fwereade_: What else are we obtaining by changing it?
<fwereade_> niemeyer, the Machine*s*Watcher has ~110 and Service*s*Watcher has nearly as much
<fwereade_> niemeyer, that's the only significant direct benefit I can see at the moment
<fwereade_> niemeyer, but I have a suspicion that it will also make it possible to consolidate ServiceRelationsWatcher, ServiceUnitsWatcher, MachinePrincipalUnitsWatcher and the forthcoming UnitSubordinatesWatcher
<fwereade_> niemeyer, all of which are/will do very similar things and have differences in implementation that I suspect are suboptimal
<fwereade_> er, is there a ServiceUnitsWatcher
<fwereade_> niemeyer, ah, there is, it's just not used
<niemeyer> fwereade_: Okay, if you think it's useful, it's fine with me
<niemeyer> fwereade_: I think rogpeppe had already raised that argument before for other reasons as well
<fwereade_> niemeyer, awesome, thanks :)
<niemeyer> fwereade_: (reusing channels)
<fwereade_> niemeyer, there have certainly been little irritations related to it in the past
<fwereade_> niemeyer, ah, yes, nice
<fwereade_> niemeyer, (and then it would actually be trivial to reinstate EntityWatcher ids and thereby allow them to share channels if necessary
<TheMue> lunchtime, biab
<rogpeppe>  niemeyer: morning!
<niemeyer> rogpeppe: Heya
<rogpeppe> niemeyer: i think this should be good to go now: https://codereview.appspot.com/6846066/
<niemeyer> rogpeppe: Cheers
<niemeyer> It's about meeting time
<niemeyer> I'll fire the hangout
<jam> niemeyer: thanks, can you link it here?
<niemeyer> https://plus.google.com/hangouts/_/500aec429367cf0688b60916ad5b255544d9bef8
<niemeyer> jam: ^
<jam> dimitern, wallyworld ^^
<rogpeppe> fwereade_: meeting?
<fwereade_> rogpeppe, joining
<niemeyer> fwereade_: Coincidently, Matt (mattyw) has been doing some questions about how subordinates work this morning
<niemeyer> fwereade_: I suggested hanging around here so we can add some freshness to our real-world use cases :)
<mattyw> I'll try to remember to hang around here for the rest of the week as well
<fwereade_> niemeyer, ah, cool
<niemeyer> rogpeppe: CL looks good
<rogpeppe> niemeyer: cool
<niemeyer> rogpeppe: One question: it looks like the generation of certs doesn't match the use of certs now on the config side of things?
<rogpeppe> niemeyer: i'm working towards reconciling the two
<niemeyer> rogpeppe: Super
<rogpeppe> niemeyer: but i'm interested what particular aspect you're thinking about there
<niemeyer> rogpeppe: The single pem vs. multiple pems
<rogpeppe> niemeyer: that's actually the same in both state info and config. the place it's different is in Bootstrap
<rogpeppe> niemeyer: and cloudinit.Config
<rogpeppe> niemeyer: i'm talking about Environ.Bootstrap, not juju.Bootstrap BTW
<niemeyer> rogpeppe: That's what I was talking about.. it's Bootstrap that generates the certs, isn't it
<rogpeppe> niemeyer: juju.Bootstrap currently generates two certs, but we're moving towards making it generate only one - the cert and key for the bootstrap instance
<rogpeppe> niemeyer: the root cert and key are going to be generated in environs, i think
<niemeyer> rogpeppe: That's not what I was talking about, but why?
<niemeyer> rogpeppe: Why would we change the place the cert is generated?
<rogpeppe> niemeyer: that's what we were talking about yesterday
<rogpeppe> niemeyer: (or was it the day before?)
<niemeyer> rogpeppe: I don't know
<niemeyer> rogpeppe: I don't recall about either
<niemeyer> rogpeppe: Why would we change the place the cert is generated?
<rogpeppe> [13:46:25] <niemeyer> rogpeppe: Why is that different from Bootstrap?
<rogpeppe> [13:47:04] <niemeyer> rogpeppe: The whole thing is starting to feel a bit hackish, to be honest..
<rogpeppe> [13:47:21] <niemeyer> rogpeppe: We have a mechanism to read the environment data from disk abstracted away
<rogpeppe> [13:47:34] <niemeyer> rogpeppe: and then we take that data, and go back to disk to look for more
<rogpeppe> [13:47:46] * niemeyer looks at some code
<rogpeppe> [13:48:18] <rogpeppe> niemeyer: we need to be able to save something to disk and then recover that, and that's what this is about
<rogpeppe> [13:49:04] <rogpeppe> niemeyer: the thing that i think is most hackish is the interface in the juju package, which really shouldn't know about $HOME stuff really, probably.
<rogpeppe> [13:49:12] <niemeyer> rogpeppe: This looks like the wrong place to be doing this
<rogpeppe> [13:49:15] <niemeyer> rogpeppe: Exactly
<niemeyer> rogpeppe: Indeed, thanks, the point is $HOME
<niemeyer> rogpeppe: So, my original point wasn't about that, though
<niemeyer> rogpeppe: I was referring to the fact Bootstrap seems to generate a single PEM file, while config uses two, of different names
<niemeyer> rogpeppe: But I guess you'll sort that out at the same time
<rogpeppe> niemeyer: yeah, that's because mgo uses a single one, and that's how the one in Bootstrap is used, but we can easily make bootstrap take two arguments and split the field in cloudinit.Config too
<rogpeppe> niemeyer: then cloudinit will just join them together
<niemeyer> rogpeppe: mgo doesn't do anything about either..
<rogpeppe> niemeyer: sorry mongod
<rogpeppe> niemeyer: mongod expects a single file with them both in
<niemeyer> rogpeppe: That's irrelevant as well, I think.. all of that logic sits at the client
<rogpeppe> niemeyer: the whole point of the cert that's passed to bootstrap is that it's used by mongod, no?
<rogpeppe> niemeyer: (i'm not saying that we shouldn't split it up for consistency's sake, though)
<rogpeppe> niemeyer: to cert that's passed to Environ.Bootstrap, i mean, just to be clear
<niemeyer> rogpeppe: It's irrelevant.. mongod never ever sees whatever we do at the client side
<rogpeppe> s/to/the/
<niemeyer> rogpeppe: And mongod never ever sees the CA certificates
<rogpeppe> niemeyer: i'm not talking about the CA certificates
<niemeyer> rogpeppe: The private key and the cert file are handled as separate files in the configuration
<rogpeppe> niemeyer: i'm not talking about those either
<niemeyer> rogpeppe: Yes, but that conversation started because of what I was talking about, I think :-)
<niemeyer> rogpeppe: If you want to go in other directions we can do that too, but then we have to agree to change subjects :)
<niemeyer> <niemeyer> rogpeppe: One question: it looks like the generation of certs doesn't match the use of certs now on the config side of things?
<rogpeppe> niemeyer: sorry, i thought i'd confirmed that you were talking about Environ.Bootstrap
<rogpeppe> niemeyer: i agree about juju.Bootstrap - that argument is going away
<rogpeppe> niemeyer: and it'll come from the Environ
<rogpeppe> niemeyer: so all those []byte(testing.RootCertPEM + testing.RootKeyPEM) will go away too
<niemeyer> rogpeppe: environ.Bootstrap doesn't generate certificates, so the whole discussion wouldn't make sense
<niemeyer> rogpeppe: But cool, I guess we're in sync now
<rogpeppe> niemeyer: yup
<rogpeppe> niemeyer: i'd like to have a chat about how we want the generation of certs and environments.yaml to work from the user's p.o.v.
<rogpeppe> niemeyer: at some point, hopefully soon
<niemeyer> rogpeppe: Cool
<rogpeppe> niemeyer: here's one possibility: http://paste.ubuntu.com/1372497/
<niemeyer> rogpeppe: I still prefer the plan we discussed yesterday
<niemeyer> rogpeppe: On bootstrap, generate a sample file
<niemeyer> rogpeppe: if it doesn't exist
<niemeyer> rogpeppe: For now, ec2 info only, uncommented
<rogpeppe> niemeyer: the problem i see with that is that the sample config is for one provider, which may not be the one that the user wants
<niemeyer> rogpeppe: Some day, local uncommented, plus everything else commented
<niemeyer> rogpeppe: There's only a single provider today
<rogpeppe> niemeyer: and when they want another one, there's no way of getting that
<rogpeppe> niemeyer: there will be many providers
<niemeyer> rogpeppe: Either the user wants that, or she/he may go home
<niemeyer> <niemeyer> rogpeppe: Some day, local uncommented, plus everything else commented
<niemeyer> rogpeppe: We can have all of them
<niemeyer> rogpeppe: Commented out
<niemeyer> rogpeppe: Plus local uncommented
<niemeyer> rogpeppe: Which is ubiquitous
<rogpeppe> niemeyer: BTW the current python doesn't generate any commented lines
<niemeyer> rogpeppe: Not sure how that's relevant
<rogpeppe> niemeyer: just saying
<niemeyer> rogpeppe: Me too :)
<rogpeppe> niemeyer: what happens if a new provider is added and the user wants a sample config for that?
<rogpeppe> niemeyer: it seems pretty hackish to require them to remove ~/.juju/environments.yaml in order to get a sample
<niemeyer> rogpeppe: Jeshh.. can we please get something going?
<niemeyer> rogpeppe: We have ONE PROVIDER TODAY
<niemeyer> rogpeppe: WriteFile(sample)
<niemeyer> done!
<rogpeppe> niemeyer: ok. i'm just wondering whether to have it as an entry point to EnvironProvider or not
<niemeyer> rogpeppe: We can improve the situation ad-infinitum
<rogpeppe> niemeyer: e.g. EnvironProvider.SampleConfig() *config.Config
<niemeyer> rogpeppe: I could literally have implemented the feature we want today and pushed for review in the time we took to discuss this so far
<niemeyer> rogpeppe: We can improve APIs and make it super fancy once we have 10 providers and 10 million users
<rogpeppe> niemeyer: so you're happy with this behaviour happening on any juju command? (i thought it might be better if it was only done on bootstrap)
<niemeyer> <niemeyer> rogpeppe: On bootstrap, generate a sample file
<rogpeppe> niemeyer: ok. python version does it on any command.
<niemeyer> rogpeppe: I'm happy with either, though.. whatever users find the most convenient
<niemeyer> rogpeppe: Ask Jorge
<rogpeppe> niemeyer: will do
<niemeyer> Alright, lunch time here
<rogpeppe> niemeyer: can you remind me of his irc nick?
<rogpeppe> niemeyer: enjoy!
<niemeyer> rogpeppe: jcastro
<rogpeppe> niemeyer: thanks
<rogpeppe> niemeyer: submitted, thanks. which means i can propose the next in line: https://codereview.appspot.com/6855054
<rogpeppe> s/propose/re-propose/
<TheMue> *: anyone interested in the first lxc steps? https://codereview.appspot.com/6852065/ and https://codereview.appspot.com/6853075/
<rogpeppe> TheMue: looking
<TheMue> thx
<rogpeppe> TheMue: any particular reason that run returns bytes.Buffer rather than []byte ?
<TheMue> rogpeppe: Oh, no, took it from the original command that I used before wrapping it. Yes, a change makes sense.
<dimitern> why is an Instance Id string and a machine ID - int?
<TheMue> dimitern: Can you scroll about 5h back? There's a discussion about this topic and possibly harmonizing them between fwereade_ and niemeyer.
<fwereade_> dimitern, I'm just making machine IDs into strings as we speak :)
<dimitern> TheMue: I see
<dimitern> fwereade_: Cool! :)
<fwereade_> it's rather uglier than I imagined, but hey ho
<dimitern> fascinating! That seems like a massive simplification
<niemeyer> dimitern, fwereade_: FWIW, having instance id and machine id having different types was actually a plus :)
<rogpeppe> TheMue: you've got a review
<dimitern> niemeyer: to define better, fine-grained architecture?
<niemeyer> dimitern: No, because they're not interchangeable
<TheMue> rocheers
<TheMue> rogpeppe: cheers *grmpf*
<rogpeppe> niemeyer: yeah, it's a pity. we *could* make instance ids have their own type actually. that might be better.
<dimitern> niemeyer: I see. But nevertheless, the polymophism in this case still rocks..
<rogpeppe> type InstanceId string
<rogpeppe> in environs
<rogpeppe> then we'd get the best of both worlds
<dimitern> rogpeppe: how about MachineId
<rogpeppe> dimitern: no
<rogpeppe> dimitern: machine != instance
<rogpeppe> dimitern: and that's why it's a good idea to keep the types separate - it's a very easy category error to make
<rogpeppe> fwereade_: what do you think?
<dimitern> rogpeppe: like passing one instead of the other?
<rogpeppe> dimitern: yeah. thinking they mean the same thing
<dimitern> rogpeppe: that's sounds very useful, Go-ish :)
<rogpeppe> dimitern: yeah, it's a useful thing to be able to do
<fwereade_> rogpeppe, honestly, I'm not sure the problem is really in the types
<rogpeppe> fwereade_: why are you changing the types then?
<dimitern> rogpeppe: my concern was the int/string distinction, while despite both being strings, having separate types is even better
<fwereade_> rogpeppe, the problem is that we have instance and machine ids, and they sound like the same thing until you come to understand the model
<rogpeppe> fwereade_: exactly. which is why it's useful to distinguish them by giving them different types
<rogpeppe> fwereade_: even if the underlying type of both of them is string
<fwereade_> rogpeppe, I dunno -- what's the distinction here between that and, say, giving a unit name its own type?
<fwereade_> rogpeppe, that will prevent people passing service names when they mean unit names
<rogpeppe> fwereade_: because we want to be able to use entity ids in an interchangeable way
<dimitern> fwereade_: probably it's not as easy to mix up unitids with others
<rogpeppe> fwereade_: otherwise why are you making machine id into a string?
<fwereade_> rogpeppe, sorry [hone
<rogpeppe> fwereade_ has an alien phone :-)
<dimitern> the new iGotcha ]I[
<dimitern> ok, so in the environs/interface.go there is this comment: http://bazaar.launchpad.net/~gophers/juju-core/trunk/view/head:/environs/interface.go#L113
<dimitern> can somebody give me an example of the described inconsistency of the provider?
<niemeyer> fwereade_: Slightly more sensitive in that case, since they both are seen as a "machine" in some senses.. not suggesting it's a show stopper at this point, though
<rogpeppe> niemeyer: what do you think of giving instance id its own type?
<rogpeppe> dimitern: for example, if you launch a machine, you might not be able to see any information on that machine for a while
<dimitern> rogpeppe: you mean, e.g. calling StartInstance successfully, then calling AllInstances won't return the new machine in the result set?
<rogpeppe> dimitern: or if you change something in a storage, that change might not be visible for a while. or it may be visible, then become invisible again.
<rogpeppe> dimitern: yup
<rogpeppe> dimitern: or it might
<rogpeppe> dimitern: no way to know
<rogpeppe> dimitern: it depends (presumably) on which server you're talking to.
<dimitern> rogpeppe: but that's the eventual consistency thing of the cloud
<rogpeppe> dimitern: yeah
<niemeyer> rogpeppe: It's an interesting idea, but I'd rather see how we feel about the machine id change on itself first
<rogpeppe> niemeyer: i'd prefer to keep the types consistently separate actually
<rogpeppe> niemeyer: i think that's easier to do than merge then separate.
<rogpeppe> dimitern: there's no way to get around it
<niemeyer> rogpeppe: Let's please not change everything at once
<niemeyer> rogpeppe: There's no reason to do that
<niemeyer> rogpeppe: fwereade_ is suggesting a huge change
<rogpeppe> niemeyer: i wasn't suggesting that
<niemeyer> rogpeppe: Which doesn't require anything *else* in addition to it
<rogpeppe> niemeyer: i'd do the int->InstanceId change first
<niemeyer> Let's have a look at it, and ponder calmly
<niemeyer> No hurry there
<rogpeppe> niemeyer: i mean string->InstanceId of course
<rogpeppe> niemeyer: then int->string
<niemeyer> rogpeppe: Yes, and I mean int=>string, *stop*, *think*
<rogpeppe> niemeyer: the problem is that makes it harder to move on from there because then we've got instance id and machine id being identical
<niemeyer> rogpeppe: They'd have the same type, which is not a show stopper at all
<rogpeppe> niemeyer: sure, it's not hard. it's just a little harder.
<niemeyer> rogpeppe: It's no harder.. instance id is completely independent
<niemeyer> Anyway, unfortunately I need to step out now for the daily errand I mentioned over email
<niemeyer> Tomorrow is the last day
<niemeyer> Back later to continue
<fwereade_> rogpeppe, sorry, back, that took longer than expected
<fwereade_> rogpeppe, I want to change ids to strings primarily so we can strip out some of the watcher duplication (within which bugs will lurk, I think)
<rogpeppe> fwereade_: that's what i thought
<fwereade_> rogpeppe, I'm not necessarily opposed to a special InstanceId type but it is completely orthogonal AFAICT
<rogpeppe> fwereade_: yeah - i just wondered if it might be better to keep the two types rigorously separate through the change process
<fwereade_> rogpeppe, and honestly it feels to me akin to having `type MaxInt int; type MinInt int; type Range{Max MaxInt; Min MinInt}`
<rogpeppe> fwereade_: i.e. leverage the type system to make sure we don't mix 'em up at some point in this large change
<fwereade_> rogpeppe, they're two different things
<rogpeppe> fwereade_: it's totally different from that
<rogpeppe> fwereade_: we never want to operate on an instance id and a machine id together
<fwereade_> rogpeppe, they're both numbers; they both define one end of a range; if people don't understand ranges they might get it wrong
<rogpeppe> fwereade_: which is not the case for MinInt and MaxInt
<fwereade_> we'd better separate them
<fwereade_> but people might get it wrong! ;p
<rogpeppe> fwereade_: bad analogy
<fwereade_> rogpeppe, ok, GrossProfit and NetProfit?
<rogpeppe> fwereade_: those are both numbers that can be used in similar ways
<rogpeppe> fwereade_: instance id and machine id can never be used in similar ways
<rogpeppe> fwereade_: it's more similar to the difference between rune and int
<fwereade_> rogpeppe, I dunno -- by that token, just about every string we use should actualy be typed
<rogpeppe> fwereade_: i don't think so
<rogpeppe> fwereade_: how many of the strings we use represent a distinctive thing that doesn't make sense to be combined with other strings?
<fwereade_> rogpeppe, don't get the "combined" bit -- is that a consideration? if so we'd better untype a bunch of things :)
<rogpeppe> fwereade_: i think the main consideration should be: does it work well as a separate type?
<fwereade_> rogpeppe, I guess it will be pretty much opaque to juju itself, and basically only want to be translated on the way in/out
<rogpeppe> fwereade_: exactly
<rogpeppe> fwereade_: outside of the provider, it could be anything - it's entirely provider-defined.
<dimitern> rogpeppe: well, if it's type InstanceId string it's not exactly provider defined
<fwereade_> rogpeppe, so, ok, we get a change at a small amount of extra safety if we add an InstanceId type; but this remains independent of entity id considerations, right?
<rogpeppe> dimitern: the contents are, but yeah
<fwereade_> dimitern, (yeah, indeed, I was wondering about non-string ones, but they should be trivial to translate anyway)
<rogpeppe> fwereade_: it does. except that i *think* that keeping the types separate throughout the change will make things easier.
<fwereade_> rogpeppe, ISTM that machine and instance IDs rarely actually come into direct contact, but you certainly know that stuff betterthan me
<rogpeppe> fwereade_: i suspect there are a fair few places where it's only the type that makes it clear what's being returned (machine id or instance id)
<rogpeppe> fwereade_: i'm sure i've written a few such things myself (i'm returning an int - it's obvious i must be returning a machine id not an instance id)
<rogpeppe> afk for 10 mins
<rogpeppe> back
<TheMue> rogpeppe: Thx for your review, it has been very valuable and I simplified the whole stuff a lot.
<rogpeppe> TheMue: cool
<fwereade_> gents, I need to pop out for a while; calling it a day for now, but I'll probably be around again laterthis evening
<TheMue> Funny, just detected that Sidney has DST but Brisbane not. So Dave and Ian have one hour difference.
<TheMue> fwereade_: Enjoy.
<TheMue> rogpeppe: Thanks again. ;)
<TheMue> So, I'm off for today, dinner time. CU tomorrow again.
<rogpeppe> niemeyer: branch enabling on-demand certificate generation when certificate not found by config: https://codereview.appspot.com/6782094/
<rogpeppe> which brings me neatly to the end of the day
<rogpeppe> g'night all
<rogpeppe> see y's tomorrow
#juju-dev 2012-11-21
<jam> wallyworld: /wave, how's it going today?
<wallyworld> hi, going well. going to put up a mp soon. i have all tests except one working (but that fails in trunk also). i keep finding more refactoring to do but will draw the line so i can get something merged in. next thing to do is add a lot of missing tests
<jam> wallyworld: sounds good. I fully support ratcheting the changes into trunk as much as possible.
<wallyworld> yeah, i don't want to make it perfect but i also don't want to have duplicated code blocks and such. so it will be fairly clean
<wallyworld> i'm wishing Go had infrastructure for IOC and such
<wallyworld> this is the type of project hat would really benefit from those patterns
<jam> wallyworld: isn't that what interfaces are for?
<wallyworld> sure, but you need an infrastructure to cleanly to the dependency injection
<wallyworld> eg Spring in the Java world
<TheMue> Morning
<rogpeppe> mornin' all
<TheMue> rogpeppe: Hiya.
<TheMue> Iiirks!
<TheMue> My test just stopped my VM.
<fwereade__> hey all
<TheMue> fwereade__: Morning.
<rogpeppe> davecheney95: sorry about trunk breakage. looks like i hadn't broken a test in the right way before checking that it passed.
<rogpeppe> davecheney95: will fix asap
<rogpeppe> fwereade__: hiya
<davecheney95> rogpeppe: it's not broken per 'se
<rogpeppe> davecheney95: it is!
<davecheney95> i just copied some of the other cert files that juju generated into the right place and it worked fine
<rogpeppe> davecheney95: it's quite badly broken
<rogpeppe> davecheney95: i've got some code that generates cert and key in a single file, but the new config stuff expects it in two
<davecheney95> rogpeppe: orly;
<davecheney95> i got it to work with only one
<rogpeppe> davecheney95: i thought it was ok 'cos my tests would've caught a problem, but it was masked
<davecheney95> anyhoo: flick me a CL and i'll give it a review
<davecheney95> file stuff on disk is hard
<rogpeppe> davecheney95: yeah, it'll work if the cert is already there
<rogpeppe> davecheney95: it's just these big changes - i've got quite a bit up in the air currently
<davecheney95> rogpeppe: yup, that is what I did, i copied a pem file that juju generated from a previos revision into the right place and it worked
<davecheney95> which was promising
<rogpeppe> davecheney95: hopefully it'll all be reconciled soon - the CL will be a temporary patch before the code goes away
 * davecheney95 is uncomfortable about the cheques we're writiing for the juju tool to do as a setup agent
 * davecheney95 proposes a new command, juju setup
<davecheney95> which is also run by default in some situatoins
<TheMue> Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaargh!
<TheMue> ErrorSitsInFrontOfTheScreenException
<TheMue> *ashamed*
<davecheney95> -EFACEPALM ?
<TheMue> davecheney95: Exactly! *grmblx*
<TheMue> Too dumb to use a self written command correct.
<wallyworld> jam: i need a little bzr advice. i have ditched my usual co-location workflow and directory layout to try cobzr. i have set in location.conf "public_branch:policy = appendpath" but this causes .bzr/cobzr to appear in the branch paths. what's the correct config?
<jam> wallyworld: I don't use cobzr, so I can't say for sure. One option is to use 'appendpath' but set the containing location to include .bzr/cobzr
<jam> So instead of [/path/to/branches] you use [/path/to/branches/.bzr/cobzr]
<jam> wallyworld: I think abentley worked on a 'just take the last name' rather than appendpath
<wallyworld> ah ok, will try thanks. i should have just stuck to what worked :-)
<jam> but I don't remember how that ended up.
<wallyworld> ok
<jam> Also, you might try something with nick, let me look at the code abit.
<jam> wallyworld: just to mention, I just use a lightweight checkout pointing to my normal locations for branches.
<jam> which gives you the same functionality as cobzr, but the branches don't exist in a subdir.
<wallyworld> yes, that's what i normally do too
<wallyworld> i think i'll ditch cobzr and revert to that
<wallyworld> jam: actually, your idea aboce to add .bzr/cobzr to the containing locations seems to work
<rogpeppe> davecheney95: are you talking about the certificate generation stuff?
<rogpeppe> davecheney95: (which, BTW is more broken than i realised, dammit - the fix isn't quite as trivial as i want)
<rogpeppe> wallyworld: FWIW i use cobzr but i've never touched location.conf AFAIR
<davecheney95> rogpeppe: all i can say is what was in the email
<davecheney95> i went to use a environment i hadn't used about 10 revisions ago
<davecheney95> and it whinged that I didn't have the magic certificate poop
<wallyworld> rogpeppe: i use to to save me typing the full urls each time i push etc
<rogpeppe> davecheney95: that's because i broke it, not necessarily because it's fundamentally the wrong design
<rogpeppe> wallyworld: ah, that sounds useful actually
<wallyworld> rogpeppe: it's quite awesome. i just type "bzr push" and it knows what to do
<wallyworld> i can pastebin my relevant config if you like
<rogpeppe> davecheney95: that happens for me too - i just rely on lbox to work out where it wants to push to, then it remembers is
<rogpeppe> it
<rogpeppe> wallyworld: please
<wallyworld> ok, sec
<rogpeppe> wallyworld: that 2nd last remark should've been addressed to you.
<wallyworld> ok. i'm just trying lbox now for the first time
<rogpeppe> davecheney95: BTW the certificate generation stuff is moving from the juju package to the environs package
<wallyworld> why don't we use lp for mps? isn't that the company standard? did we get an exception?
<rogpeppe> wallyworld: we do
<rogpeppe> wallyworld: but we use codereview too
<rogpeppe> wallyworld: because it's considerably awesomer :-)
<wallyworld> ok, i'm still ramping up on juju processes
<davecheney95> wallyworld: i should have mention, ping me if you need help in your timezone
<wallyworld> i'll see real soon now what's it's like :-)
<wallyworld> davecheney95: thanks, will do
<davecheney95> your timezone is like my timezone, except we're not scared of confusing the livestock
 * wallyworld wishes we had daylight saving
 * davecheney95 wishes we didn't
<wallyworld> lol
<jam> wallyworld: really? The 2h time shift with the rest of the world tends to be very disruptive
<davecheney95> i'm already getting grief about the tuesday meeting 'cos it's slipped to 11pm
<jam> poolie had it, and it was quite annoying
<davecheney95> it's great to get 2 hours more with the yanks
<rogpeppe> davecheney95: what time is it for you now?
<wallyworld> excepting collaboration, i really like it
<davecheney95> 19:30
<wallyworld> 18:30 for me
<davecheney95> when I worked at the trading company, daylight saving sucked
<davecheney95> we had to work til 9pm to cover the indian market
<wallyworld> it makes it really nice for family time at the end of the day
<davecheney95> wallyworld: which part of brisvegas are you in ?
<wallyworld> fig tree pocket
<wallyworld> western suburbs
<wallyworld> you?
<davecheney95> wallyworld: latte sipping inner west sydney
<wallyworld> bondi?
<wallyworld> oh, that's east
<wallyworld> balmain maybe
<wallyworld> i don't know sydney that well
<davecheney95> ashfield, almost the same
<davecheney95> bit further south from the river
<rogpeppe> davecheney95: hmm, good thing you can work a bit late often, 'cos otherwise our working days have no overlap at all, unless i get up at 6.30am
<wallyworld> rogpeppe: https://pastebin.canonical.com/78813/   - i just have it set up for goose right now. i could promote the common config items like public_branch:policy to a [/home/ian/juju] section
<wallyworld> when i add juju-core or other projects
<wallyworld> so now bzr info gives:
<wallyworld> Related branches:
<wallyworld>   public branch: bzr+ssh://bazaar.launchpad.net/~wallyworld/goose/client-using-identity
<wallyworld>     push branch: bzr+ssh://bazaar.launchpad.net/~wallyworld/goose/client-using-identity
<wallyworld>   parent branch: .bzr/cobzr/master
<wallyworld>   submit branch: bzr+ssh://bazaar.launchpad.net/~gophers/goose/trunk
<wallyworld> so stuff it cares about is set correctly
<rogpeppe> wallyworld: cool, thanks
<wallyworld> np
<rogpeppe> wallyworld: and you put that in ~/.bzr/locations.conf ?
<wallyworld> ~/.bazaar
<wallyworld> locations.conf
<rogpeppe> ha, that's funny
<rogpeppe> i did actually set up a locations.conf file once
<jam> rogpeppe: in the non-go world, I have all of my branches roughly mirroring launchpad as: ~/dev/$PROJECT/$BRANCH, which lets me set a policy like the one above, except it works across all of my projects, rather than configuring each one.
<rogpeppe> jam: yeah, i did have that setup originally
<rogpeppe> jam: my current locations.conf has a push_location of  lp:~rogpeppe/ensemble :-)
<jam> that sounds like it has been a while :)
<rogpeppe> jam: blast from the past
<wallyworld> save me looking up docs, if lbox says gofmt is sad, do i have to run gofmt against each file individually, or do we have a tool to them all at once?
<rogpeppe> wallyworld: in the root juju directory, run "go fmt ./..."
<wallyworld> cool, thanks
<rogpeppe> wallyworld: or, from any directory, run "go fmt launchpad.net/juju-core/..."
<wallyworld> i was typing gofmt
<rogpeppe> wallyworld: or to do it in the current directory only, run "go fmt"
<wallyworld> worked, thanks
<wallyworld> i didn't appreciate the difference between gofmt and go fmt
<rogpeppe> wallyworld: (the go command always uses the package in the current directory by default)
<wallyworld> ok
<rogpeppe> wallyworld: gofmt allows access to a few features that go fmt doesn't
<rogpeppe> wallyworld: for example the -r flag (which can be awesome BTW)
<rogpeppe> wallyworld: go fmt does actually just call gofmt, i think
<wallyworld> gofmt  seemed to print the file to stdout
<wallyworld> files
<rogpeppe> wallyworld: yeah, that's the default. although you can use gofmt -w too
<wallyworld> iw works with ./... ?
<wallyworld> -w
<rogpeppe> wallyworld: no.
<jam> wallyworld: I'm pretty sure gofmt doesn't support './...' but 'go fmt' does
<wallyworld> ok, thanks
<rogpeppe> wallyworld: the go tool is the one that understands package wildcards etc
<rogpeppe> wallyworld: gofmt just knows about files
<rogpeppe> wallyworld: i almost always use go fmt
<wallyworld> ok
<rogpeppe> wallyworld: except when i'm editing - then i'll often pipe a section of a file (or the whole thing) through gofmt
<wallyworld> i might look at setting up my IDE to use it in the background
<wallyworld> i already have code inspections but not fully go fmt compliant
<rogpeppe> wallyworld: for instance if you use vim, you can do :1,$!gofmt
<rogpeppe> wallyworld: i know various people set their editors up to automatically gofmt on save
<wallyworld> i use Intellij with a golang plugin
<wallyworld> i'll look into it
<jam> rogpeppe: yeah, I tried to set up vim with it, but my simple method meant that every write triggered a reload of the working buffer, shoving me all the way to the top of the file. Loosing my place made it impractical.
<rogpeppe> wallyworld: and i'm pretty sure that some people (fwreade__ ?) change tabs to spaces on load, and back to tabs on save.
<wallyworld> i'm just waiting on integrated debugging to be supported. i really miss that from Java and Python
<jam> So instead, I just do "go fmt ./... && go test ./..." so every test run reformats.
<rogpeppe> jam: yeah i can see how that might be annoying
<jam> wallyworld: ISTR that gdb works with go code
<wallyworld> i really dislike the use of tabs - everyone i mentioned it to is quite incredulous
<jam> Losing
<jam> *sigh* too easy to get that one wrong
<rogpeppe> wallyworld: what don't you like about them?
<wallyworld> i've not used gdb - will have to learn, i rely on my ide
<jam> wallyworld: well, I would guess if gdb works, many ides might use that on the backend.
<rogpeppe> yeah, gdb does work (i checked once) but i never use it
<jam> Which means you could have intellij integration earlier than later.
<wallyworld> rogpeppe: i can't quite put it into words easily why i dislike tabs, no other language i know of ides it
<wallyworld> does
<jam> wallyworld: I worked on a project in C/C++ that mandated tabs so that people could configure their preferred indent.
<jam> Most python projects mandate no tabs.
<wallyworld> and Java too
<jam> IME
<rogpeppe> wallyworld: i've used tabs for a very long time, so i'm always interested to know why people don't like them
<rogpeppe> jam: with python it's understandable, because getting the indentation right is crucial
<jam> rogpeppe: yeah, the main problem in python is that you *can* mix spaces and tabs, and that way lies madness. :)
<rogpeppe> wallyworld: i like the fact it's just a single character to type to add or remove a level of indentation
<wallyworld> rogpeppe: i guess because the spacing becomes variable for everyone, depending on their setup
<rogpeppe> jam: yeah
<wallyworld> rogpeppe: my IDe does all that - i hit tab and it inserts saces on thre fly
<jam> rogpeppe: sure but I use << >> in vim anyway, so indentation is a simple select and move regardless the characters used to indent.
<wallyworld> and it auto indents according to the code style in use
<rogpeppe> wallyworld: yeah - that's a problem if people rely on beautiful code alignment. you can't do that in go though :-)
<wallyworld> so i never type lots of spaces
<wallyworld> rogpeppe: and the preference for tabs = 8 is madness IMO
<wallyworld> way too much
<davecheney95> wallyworld: for python, probably
<rogpeppe> wallyworld: don't you need to type a few delete characters to remove a level of indentation
<rogpeppe> ?
<wallyworld> nope, IDe does it
<davecheney95> but it could be a million, it just depends what your editor is set too
<jam> rogpeppe: I know vim can be configured to know when you are deleting indent chars vs regular spaces.
<wallyworld> it knows whatr the code style is and handles all that
<jam> However, I use <<, I imagine wally does "shift + tab"
<jam> ISTR doing that in VC in the long distant past.
<wallyworld> Backspace deletes all the white space unti lthe next indentation block
<wallyworld> just like if tabs were used
<rogpeppe> wallyworld: i don't think go has a preference for tabstop=8 particular
<rogpeppe> y
<rogpeppe> ly
<wallyworld> i think i read it somewhere
<wallyworld> but i've crammed a lot of Go docs in the past few days
<rogpeppe> wallyworld: personally, i'm a heretic because i use a proportionally spaced font
<jam> wallyworld: so you can always set your tab stop if 8 is too much. Which isn't true if you use spaces. For *me* I just adapt between them.
<wallyworld> really????
<jam> rogpeppe: there is a slight preference if go fmt ends up aligning something with spaces on a continuation line, etc.
<wallyworld> jam: yeah, but as you said, it may mess with alignment
<jam> I thought, I could be wrong.
<rogpeppe> jam: yeah. i don't mind much though.
<jam> wallyworld: occasional mis alignment could be a lot better than constant extra depth for you
<rogpeppe> jam: i don't find it affects readability
<wallyworld> rogpeppe: why proportional spaced font?
<rogpeppe> wallyworld: but i get more readable text per pixel with a proportionally spaced font
<jam> rogpeppe: does it do fixed width spaces for aligned tables?
<rogpeppe> jam: yeah, i can switch trivially if i need to
<rogpeppe> jam: aligned tables are pretty rare though
<jam> rogpeppe: except for all of the inline comments in structs :) and `json:content` stuff
<rogpeppe> jam: yeah. but the alignment there is just prettification. it doesn't make much difference if it's not aligned.
<rogpeppe> jam: unlike a table
<jam> sure
<rogpeppe> if i used an equivalent font size in fixed with, i'd see much less code. and i like the way proportionally spaced text looks.
<rogpeppe> anyway, excuse me, i need to un-break trunk :-)
<wallyworld> jam: i just ran lbox and it created the lp mp, but i got this error: "error: Failed to send patch set to codereview: diff is empty"
<wallyworld> lp can take a little time to generate the code diff
<wallyworld> how do i send the diff to codereview once lp has calculated it?
<jam> wallyworld: sounds odd, offhand sounds like an incorrect submit branch.
<jam> wallyworld: lbox computes the diff and proposes it for you
<rogpeppe> wallyworld: what does "bzr diff --old lp:goose/trunk" print?
<wallyworld> jam: the lp mp says the submit branch is https://code.launchpad.net/~gophers/goose/trunk
<wallyworld> jam: that command prints the diff as expected
<rogpeppe> hmm, odd
<rogpeppe> wallyworld: what does lbox propose -v print?
<wallyworld> lp also shows the preview diff, let me type the the above and see
<wallyworld> rogpeppe: that time it send the diff to codereview, or so it says. it also marked the mp as neews review since i created initially as wip
<rogpeppe> wallyworld: that sounds like it all worked
<rogpeppe> wallyworld: did it print a codereview url?
<wallyworld> yeah, i have no idea what happened the first time
<wallyworld> rogpeppe: ah no, my apologies - it still failed: error: Failed to send patch set to codereview: diff is empty
<rogpeppe> wallyworld: could you paste the lbox output?
<wallyworld> rogpeppe: https://pastebin.canonical.com/78814/
<wallyworld> rogpeppe: i have to go and put my son to bed and read him a story, i'll be back in a bit
<jam> wallyworld: Diffing branches for codereview: /home/ian/juju/go/src/launchpad.net/goose => /home/ian/juju/go/src/launchpad.net/goose/.bzr/cobzr/lbox-805004725/lbox
<jam> It looks like lbox is treating your goose checkout as the submit target.
<jam> And doing a diff of the code against itself.
<jam> obviously that is an empty diff.
<jam> I don't know where lbox gets the URL of the branch to diff against.
<jam> I would have thought that would be in .lbox, which uses "propose -cr -for lp:goose"
<jam> Maybe it is looking up something else in your config?
<jam> rogpeppe: do you know where lbox gets the target to diff against?
<rogpeppe> jam: it should get it from the -for flag, which in this case is set in .lbox
<rogpeppe> jam: it looks like that worked too, but i'm not sure why it changed.
<rogpeppe> jam: it looks like the FetchRemote logic is failing somehow
<rogpeppe> jam: erm, no it doesn't - it all looks ok to me
<jam> the fact that it is diffing against 'lbox' something makes me think it is fetching the remote branch to a temp location and then trying to diff against it, but it also feels like it might be failing to get the actual files to diff against for some reason.
<rogpeppe> jam: hmm, it worked fine for me: https://codereview.appspot.com/6858050
<rogpeppe> except that testservices/identityservice/util.go needed gofmting, which makes me suspicious
<rogpeppe> i'm not sure how the lbox check could have succeeded if that branch really was current
<davecheney95> rogpeppe: speaking of gofmt
<davecheney95> there are some small changes, and larger ones coming that make gofmt 1.0 and gofmt 1.1 incompatible
<rogpeppe> davecheney95: really? in what way?
<davecheney95> there is a small change already that affects the padding of comments on struct members
<davecheney95> and gri is about to commit a change that makes
<davecheney95> for i := range s { i++ }
<davecheney95> valid
<rogpeppe> davecheney95: orly?!
<davecheney95> which is going to upset our .lbox.check hook
<rogpeppe> davecheney95: oh, you mean the formatting
<davecheney95> yes
<rogpeppe> davecheney95: i thought you meant that you could influence a range variable within the body
<davecheney95> the syntax is not changing, just the canonical format
<rogpeppe> davecheney95: i guess we'll have to standardise on 1.0.3 gofmt
<davecheney95> rogpeppe: i agree
<rogpeppe> davecheney95: until 1.1 is released
<davecheney95> although it'll be 1.0.2
<davecheney95> 'cos that is what is in precise or quantal
<rogpeppe> davecheney95: same difference, i think
<davecheney95> for this, yes
<rogpeppe> davecheney95: only problem is: can we get the tip go tool to use a different gofmt?
<rogpeppe> davecheney95: i.e. does it just use the gofmt in $PATH or not?
<wallyworld> rogpeppe: jam: thanks for looking, i'll poke around and see what might be happening. certainly something must be correctly setup since launchpad's mp diff is there ok
<davecheney95> go space format from memory
<davecheney95> for people like me that live on tip
<rogpeppe> wallyworld: i did the propose myself, and it worked, except that it required a gofmt, which seems odd
<davecheney95> we could add optoinal support for a GO_1_x path (making up a name)
<wallyworld> hmmm. when i first did it it complained and then i fixed all the issues
<davecheney95> review request: https://codereview.appspot.com/6851081/
<davecheney95> ^ i think this is gettig pretty resonable
<jam> wallyworld: I should have a review for you in a bit.
<wallyworld> jam: using the lp diff?
<davecheney95> eww
<rogpeppe> davecheney95: go fmt just uses gofmt from $PATH, so there's no difficulty chopping and changing if we need to
<jam> wallyworld: yeah, I'm still perfectly comfortable reviewing from LP.
<davecheney95> rogpeppe: nice, I can make that work
<jam> and/or from a raw branch when necesasry.
<wallyworld> \o/
<jam> I have to go in about 20min, so I'd rather get you a review than nothing today.
<wallyworld> thanks
<jam> wallyworld: review submitted. Probably the start of a conversation, though at this point, we can land what you are comfortable with and iterate from there, rather than iterating pre landing.
<wallyworld> jam: ok, will look. thanks
<rogpeppe> davecheney95: you've got a review
<davecheney95> ty
<dimitern> wallyworld: a tiny comment from me as well, not really a full review (since I did the original code, more or less I don't think will be appropriate to review).
<wallyworld> dimitern: thanks, i'll look after replying to jam's lengthy review
<wallyworld> which i'm doing now
<dimitern> wallyworld: feel free to blame the initial ugliness on me :)
<wallyworld> prototype code!
<wallyworld> not meant to be perfect
<dimitern> yeah
<wallyworld> dimitern: there is that one failing test - any idea?
<dimitern> GetObject?
<wallyworld> yeah
<wallyworld> TestObjects
<dimitern> wallyworld: not really, I struggled with it a bit, but even though the Put was ok and no error reported, Get returned empty data and also no error... probably a sleep of a few secs is in order - the eventual consistency thing of the cloud
<wallyworld> could be. will be nice to know
<wallyworld> so we can plan around it for other things
<dimitern> wallyworld: also, it seems you're not yet a member of The Go Language Gophers team and you should be
<wallyworld> ah, haven't checked that. thanks, i'll follow up
<niemeyer> Good morning ladies and gentlemen
<TheMue> Binjour Monsieur Niemeyer
<TheMue> s/Binjour/Bonjour/
<niemeyer> TheMue: Merci beaucoup
<niemeyer> "beaucoup" must be my favorite word in French
<niemeyer> I picture imagined language designers saying "Hey, why don't we just throw a few more letters there, just for the fun of it?"
<dimitern> niemeyer: yeah, the same applies to irish, scottish and manx :)
<TheMue> niemeyer: Hehe, indeed, just discovered the number of vowels in "beaucoup".
<rogpeppe> dimitern: perhaps you could put your initial commit up for review before we put ian's changes on top?
<rogpeppe> niemeyer: yo!
<niemeyer> rogpeppe: Heya
<dimitern> rogpeppe: well, since it's already in trunk, how can I do this?
<rogpeppe> dimitern: hmm, good question. erase trunk and start again? :-)
<dimitern> rogpeppe: done! :D
<dimitern> rogpeppe: that's what I meant yesterday by wanting someone to take a look at goose/client/client.go first
<rogpeppe> dimitern: yeah, it would be a good idea i think
<dimitern> rogpeppe: I'd really appreciate if you take a look then
<rogpeppe> dimitern: the only problem with starting from scratch is that wallyworld's branch becomes divergent, but i don't think that's too much problem actually. apart from jam's review. gotta start somewhere tho.
<rogpeppe> dimitern: will do when i see the CL
<mgz> rogpeppe: that does make sense for future, but as this is mostly initial experimental hacking that will get replaced in pretty short order
<rogpeppe> mgz: i'm not sure. it looks to me like the core of something that will shortly be expanded, with no time to go back to get the core right.
<rogpeppe> mgz: there are lots of things there that can easily be got right from the word "go"
<mgz> do I have to hit you for that pun? :)
 * rogpeppe was blithely oblivious
 * rogpeppe apologises
<rogpeppe> i dunno, maybe it doesn't need a review, but... niemeyer, what thinkest thou?
<niemeyer> rogpeppe: I tend to agree with you
<niemeyer> If it's indeed scratch, it can be moved aside
<dimitern> rogpeppe, mgz: yeah, I'll feel better once we have a routine CL/review/land process in place, but the code now in trunk will be there for a short while and be reviewed in chunks
<wallyworld> niemeyer: hey can you add me to gophers so i can push to goose trunk?
<niemeyer> Even more if there's no review process in place
<niemeyer> This is a major eye-opener
<dimitern> niemeyer: absolutely, I agree, so how do we handle the gap between the no-review code and the refactoring of it, which is reviewed as usual in steps
<rogpeppe> dimitern: i think we should add code to a blank trunk, in steps
<mgz> niemeyer: there is review, it's just we're integrating the two initial stabs dimitern and jam did during UDS
<mgz> which were not reviewed, they just got written
<niemeyer> rogpeppe++
<mgz> so, jam had some comments about dimitern's code from then, which wallyworld is refactoring into the common set now
<niemeyer> Although, I'll leave that to you guys.. the important thing is that there's certainty that the code that is in trunk was looked over and is sensible and tested
<mgz> so, it's essentially the same as having an unmerged feature branch that some parts of which are now being cherrypicked it, and that cherrypick is being reviewed
<rogpeppe> niemeyer: unfortunately you were totally right about your config misgiving last night. a test wasn't working properly, and as a result trunk is now broken in a way that's not easy to fix. am v sorry about this.
<rogpeppe> pwd
<niemeyer> rogpeppe: If we can't fix it promptly, we should revert it so other people can continue to use it
<rogpeppe> niemeyer: i think reverting it is the best plan (i do have a fix, but it's ugly and bigger than i'd like)
<rogpeppe> niemeyer: how would you go about reverting it? apply a reverse patch?
<niemeyer> rogpeppe: Right
<mgz> rogpeppe: then in your feature branch, merge trunk after the revert but keep the existing tree state, so it's ready to reland
<rogpeppe> mgz: would you do that just by copying the tree out and back in? or is there a clever way to merge without updating the tree?
<niemeyer> Yeah, the obvious "re-apply" doesn't work after the reverse
<niemeyer> wallyworld: That's done
<mgz> rogpeppe: basically switch to feature, then bzr merge trunk (or whatever branch layout you're using), then `bzr revert .`
<wallyworld> niemeyer: thanks!
<mgz> and commit
<mgz> so, you keep the merge marker but reject the trunk changes
<rogpeppe> mgz: doh! of course
<rogpeppe> mgz: i was thinking that reverting would lose the merge merker
<mgz> if there are intermediate things on trunk that need saving, you want to do it in two steps, but there shouldn't be in this case
<niemeyer> mgz: I don't think that works
<niemeyer> Because revert reverts
<niemeyer> Including the merge
<mgz> if you pass . it reverts the tree contents, not the merge marker
<wallyworld> mgz: dimitern: my changes should be pushed
<niemeyer> mgz: Ah, I missed the .
<dimitern> wallyworld: thanks
<rogpeppe> me too
<mgz> wallyworld: thanks!
<wallyworld> np
<wallyworld> i'll address the refactorings tomorrow
<rogpeppe> mgz: that's a very subtle distinction!
<rogpeppe> hmm, my irc client says it's dead, but i still saw wallyworld's messages
<mgz> right, it's less obvious than the inverse which is `bzr revert --forget-merges` which keeps the tree state but loses the marker
<rogpeppe> niemeyer: https://codereview.appspot.com/6845070
<rogpeppe> perhaps i should just submit it - it's entirely automatic
<niemeyer> rogpeppe: Yep, sounds sane
<niemeyer> rogpeppe: I'm wondering about the best plan to get that in now.. it'd be nice to have that branch mostly unchanged when it comes back, so we can more easily get it in
<rogpeppe> niemeyer: i agree, but it's not an easy fix
<rogpeppe> niemeyer: trying to make a fix made me realise a few issues with my current plan
<niemeyer> rogpeppe: Sure, but it can be done on top of it, rather than *in* it
<rogpeppe> niemeyer: i'm not sure.
<niemeyer> rogpeppe: ?
<rogpeppe> niemeyer: it's difficult to make the original cert generation work properly
<rogpeppe> niemeyer: because you need to know the name of the environment to generate the certificate, but you can't know the name of the environment until you've parsed it.
<rogpeppe> niemeyer: and you can't parse it without the certificate
<niemeyer> rogpeppe: I still don't understand how that makes it hard to make the change on top of the branch, rather than mixing stuff up
<rogpeppe> niemeyer: it's not easy to make that branch pass tests.
<rogpeppe> niemeyer: (when the tests aren't broken)
<rogpeppe> niemeyer: it's quite chicken-and-eggy
<niemeyer> rogpeppe: I see
<rogpeppe> niemeyer: my ugly fix was to generate the certificate into a file with a known name
<rogpeppe> niemeyer: then the generation can be separated from the parsing
<rogpeppe> niemeyer: in the new scheme, we can make the config parse error return the name of the environment in the error, so we at least know the correct name to use to generate the cert
<rogpeppe> niemeyer: a much easier alternative would be to use the same root cert for all environments
<niemeyer> rogpeppe: Much easier yet non-reasonable, I think
<rogpeppe> niemeyer: yeah, i thought so
<niemeyer> rogpeppe: Where is that config parsing error taking place?
<rogpeppe> niemeyer: the first line of BootstrapCommand.Run
<rogpeppe> niemeyer: well, that's currently.
<rogpeppe> niemeyer: the plan is to have it handled somewhere within environs.NewFromName
<rogpeppe> niemeyer: but that's another issue actually
<rogpeppe> niemeyer: in our current scheme, we parse all environments when we read the environments.yaml file
<niemeyer> rogpeppe: I'm kind of lost in the overall plan I think.. why do we need an error telling us about a name that we have as a variable?
<niemeyer> rogpeppe: Kind of
<niemeyer> rogpeppe: What you're saying is that we parse the environments.yaml file when we read the environments.yaml file, which seems self-defining
<rogpeppe> niemeyer: yeah. but there are two levels of parsing - reading the environments.yaml file itself and turning each section into a *config.Config
<rogpeppe> niemeyer: currently we do both
<rogpeppe> niemeyer: and NewFromName simply calls ReadEnvironsBytes and returns one of the environs
<niemeyer> rogpeppe: So, what's the issue?
<rogpeppe> niemeyer: one issue is that ReadEnvironsBytes doesn't know the name that we have as a variable
<rogpeppe> niemeyer: so we'd need to change the scheme we use in some way
<niemeyer> rogpeppe: Why?
<niemeyer> rogpeppe: I think ReadEnvironsBytes is fine as it is
<niemeyer> rogpeppe: What are you thinking of doing?
<rogpeppe> niemeyer: how can ReadEnvironsBytes work without generating a certificate if needed for each environment section?
<niemeyer> rogpeppe: To build the certificates
<rogpeppe> niemeyer: i'm thinking of doing the config parsing at a later stage.
<niemeyer> rogpeppe: You're assuming other things that I can't tell yet
<rogpeppe> niemeyer: so then we can always call ReadEnvironsBytes even if the certificates aren't in place yet
<niemeyer> rogpeppe: It works today, so without knowledge of what other changes you have in mind, I can easily say that it doesn't have to do anything
<niemeyer> rogpeppe: We can do that today
<rogpeppe> niemeyer: how? the CA cert is required by the config.
<niemeyer> rogpeppe: By not making it required by the config, for example.. this is the change you've just reverted
<rogpeppe> niemeyer: we could do that. but it is really required in the end...
<rogpeppe> niemeyer: perhaps that's ok though. we can insert checks in all the relevant places.
<niemeyer> rogpeppe: Where do we want to generate the certificates?
<rogpeppe> niemeyer: our plan, i think, was to do it in NewFromName. but actually i'm not sure that's right. i think it should happen on bootstrap only.
<niemeyer> rogpeppe: NewFromName is definitely not the right place.. this is a trivial wrapper
<rogpeppe> niemeyer: in my branch fix this morning, i added a function in juju: GenerateCACertificateIfNecessary
 * niemeyer observes rogpeppe getting Javaeske
<rogpeppe> niemeyer: which actually seemed like a reasonable way of doing things
<rogpeppe> niemeyer: yeah, i know. it was only a temporary name :-)
<rogpeppe> niemeyer: if the Environ we get back from NewFromName might not have a root CA cert, where *might* a good place to generate it be?
<niemeyer> rogpeppe: I think it should have a root cert for sure
<niemeyer> rogpeppe: And config.New may also require the availability of the cert, actually
<niemeyer> rogpeppe: The logic you had in place looks good
<rogpeppe> niemeyer: in juju?
<niemeyer> rogpeppe: ?
<rogpeppe> niemeyer: sorry, which logic?
<niemeyer> rogpeppe: config.New?
<rogpeppe> niemeyer: ok, cool
<rogpeppe> niemeyer: yeah, i think it's ok
<rogpeppe> niemeyer: the problem being that we need to generate the certificate some time before calling config.New
<rogpeppe> niemeyer: and i don't think we can do it before calling NewFromName (assuming that's what cmd/juju does in bootstrap)
<niemeyer> rogpeppe: I think we should just change type environ to be struct { attrs }
<rogpeppe> niemeyer: ooh, radical
<rogpeppe> niemeyer: isn't that a huge change?
<rogpeppe> niemeyer: assuming you mean environs.Environ
<niemeyer> rogpeppe: I don't
<rogpeppe> niemeyer: oh yeah
<rogpeppe> niemeyer: phew
<rogpeppe> niemeyer: yes, i agree
<rogpeppe> niemeyer: that was my suggestion earlier
<niemeyer> rogpeppe: There are still issues, though
<niemeyer> rogpeppe: Oh, I hadn't noticed the suggestion before
<rogpeppe> [12:25:29] <rogpeppe> niemeyer: i'm thinking of doing the config parsing at a later stage.
<rogpeppe> [12:25:32] <niemeyer> rogpeppe: You're assuming other things that I can't tell yet
<rogpeppe> [12:25:51] <rogpeppe> niemeyer: so then we can always call ReadEnvironsBytes even if the certificates aren't in place yet
<niemeyer> rogpeppe: I see.. you mean something else by parsing, okay
<rogpeppe> niemeyer: yeah, sorry. it's checking rather than parsing.
<niemeyer> rogpeppe: It's still not enough, though
<rogpeppe> niemeyer: no, we need something that actually generates the certs
<niemeyer> rogpeppe: More than that, we need a place to generate the certs
<niemeyer> rogpeppe: ReadEnvironsBytes is purely in memory
<rogpeppe> niemeyer: i was wondering about environs.BootstrapEnviron()
<rogpeppe> niemeyer: something explicitly in environs that returns an environment suitable for bootstrapping, generating certs if necessary
<rogpeppe> BootstrapEnviron isn't right tho
<niemeyer> rogpeppe: How many Bootstrap functions do we need? :)
<rogpeppe> it sounds too active
<rogpeppe> niemeyer: yeah
<rogpeppe> niemeyer: this is something we only want to happen at bootstrap time though.
<niemeyer> rogpeppe: Yeah, that's something interesting to take into account
<niemeyer> It's fine to error in other situations
<rogpeppe> niemeyer: i'm wondering how things would be if we put all the $HOME-related logic into the juju package
<rogpeppe> niemeyer: then it would be logical that juju.Bootstrap could generate certificates and write them to $HOME.
<niemeyer> rogpeppe: Feels like fiddling without solving the underlying issue
<niemeyer> rogpeppe: juju.Bootstrap is already bogus, I think
<niemeyer> rogpeppe: It should be environs.Bootstrap
<niemeyer> rogpeppe: We're loosing sight of what that package was supposed to be
<rogpeppe> niemeyer: environs.Bootstrap works for me
<rogpeppe> niemeyer: in which case, perhaps we could have environs.BootstrapWithName which would generate the certificates if necessary
<niemeyer> rogpeppe: The problem isn't the name
<niemeyer> rogpeppe: We have the environment name
<rogpeppe> niemeyer: but we can't get an Environ without its certificate, so the existing juju.Bootstrap interface doesn't work
<rogpeppe> niemeyer: so BootstrapWithName would read environments.yaml, generate certificates if necessary, then call environs.Bootstrap
 * rogpeppe has thought of a very quick and easy way of getting that branch in without breaking trunk
<niemeyer> rogpeppe: BootstrapWithNameAndMaybeWithoutCertificates
<rogpeppe> niemeyer: arf
<niemeyer> rogpeppe: I'm pretty convinced that config.New shouldn't barf if there are no certificates
<rogpeppe> niemeyer: hmm, so that logic is wrong now?
<niemeyer> rogpeppe: There's no such logic now?
<rogpeppe> niemeyer: true, it's just been reverted
<rogpeppe> niemeyer: i meant the logic you said looks good earlier
<niemeyer> rogpeppe: The points that should barf are the points that need the certificate (novel idea!)
<rogpeppe> niemeyer: that seems fine
<niemeyer> rogpeppe: environs.Bootstrap shouldn't even try to create the certs
<rogpeppe> niemeyer: that still doesn't solve to problem of who *does* try to create the certs though
<niemeyer> rogpeppe: The bootstrap command can do that by itself, I believe
<niemeyer> rogpeppe: Which is one of the few control points that can actually relate BuildCerts (or whatever) to $HOME to the fact that Bootstrap is in progress
<rogpeppe> niemeyer: i'm not sure. i'd prefer not to duplicate that logic in every piece of client code that calls Bootstrap
<rogpeppe> niemeyer: but actually, maybe most client code (builddb included) should not actually be calling Bootstrap
<niemeyer> rogpeppe: Hmm.. good point
<niemeyer> rogpeppe: I mean the former one, not the latter
<dimitern> mgz: I'm back
<niemeyer> rogpeppe: What about having environs.Bootstrap taking a certsDir parameter?
<niemeyer> rogpeppe: "" defaults to ~/.juju/
<niemeyer> rogpeppe: Use for writing only.. never reads from it
<niemeyer> Used
<rogpeppe> niemeyer: we'd want a way of doing an environs.Bootstrap *without* generating certificates
<niemeyer> rogpeppe: Why?
<rogpeppe> niemeyer: because we might want to use it in an environment with no writable directories.
<niemeyer> rogpeppe: Erm?
<niemeyer> rogpeppe: Do you have a realistic use case?
<rogpeppe> niemeyer: i'm thinking of platforms like google appengine (not that that's currently a realistic target of course)
<niemeyer> rogpeppe: I don't think that even makes sense.. if you don't have a way to write the certificate down to disk, the certificate should be provided upfront otherwise it's simply not usable
<rogpeppe> niemeyer: i suppose you can always provide a nonsense name in that case
<niemeyer> rogpeppe: Why do we need a nonsense name?
<rogpeppe> niemeyer: because you need to call environs.Bootstrap even if you're providing the cert up front
<rogpeppe> niemeyer: and it requires a name
<niemeyer> rogpeppe: I don't understand the obsession with the name.. it doesn't require a name.. it requires an environment, that has a name, at all times
<niemeyer> rogpeppe: environ Environ
<rogpeppe> niemeyer: sorry, the certDir name
<niemeyer> rogpeppe: LOL, okay
<niemeyer> rogpeppe: It's a red-herring really.. if there are zero paths writable, it can't work without a certificate, and that's fine.
<rogpeppe> niemeyer: so presumably environs.Bootstrap would use SetConfig to set the certificate on the environment passed in
<rogpeppe> niemeyer: i can imagine a case where you might not want to provide a path (e.g. running as root and wanting no side-effects)
<niemeyer> rogpeppe: Seems pretty fictitious
<niemeyer> rogpeppe: You're bootstrapping but want no side effects? :-)
<rogpeppe> niemeyer: there are all kinds of places i could save stuff that are not on disk
<niemeyer> rogpeppe: juju needs a certificate to work.. that's the only invariant we have
<rogpeppe> niemeyer: or, not on the local filesystem at any rate
<niemeyer> rogpeppe: If people don't want juju to generate the certificate for them, it's their problem to generate it
<rogpeppe> niemeyer: yeah, true
<rogpeppe> niemeyer: alternatively, forget about the "" meaning ~/.juju thing, and define environs.JujuDir = os.Getenv("HOME") + "/.juju"
<rogpeppe> .or ConfigDir or whatever
<rogpeppe> niemeyer: i think that would be my preference - more explicit
<rogpeppe> niemeyer: another possibility: provide an interface{WriteFile(name string, data []byte)error}, and when nil, use a type that writes to ~/.juju
<rogpeppe> niemeyer: i like that even better - nil is slightly easier to type than "" :-)
<rogpeppe> niemeyer: and it makes it easier to test too
<rogpeppe> niemeyer: func Bootstrap(env Environ, certWriter FileWriter) error
<rogpeppe> niemeyer: also makes it easy to encrypt the certificate/key if desired
<rogpeppe> although of course, then we'd want a converse in config.New
<niemeyer> rogpeppe: Sounds good, but the certWriter should be func(name string, data []byte) error
<niemeyer> rogpeppe: What converse?
<rogpeppe> niemeyer: ok.
<rogpeppe> niemeyer: ReadFile
<niemeyer> rogpeppe: I don't think that's necessary
<rogpeppe> niemeyer: not for the time being anyway
<rogpeppe> niemeyer: at some point it would be nice to be able to hook into the ubuntu keyring mechanism
<rogpeppe> niemeyer: (i'm not sure how that works at all)
<rogpeppe> niemeyer: so that people can avoid storing their juju environment keys in plaintext
<mgz> dimitern: can you glance over a branch for me?
<dimitern> mgz: sure
<mgz> dimitern: https://code.launchpad.net/~gz/goose/client_identity_refactor_fix/+merge/135394
<dimitern> mgz: pretty straightforward, LGTM
<mgz> thanks! will land.
<niemeyer> Lunch!
<rogpeppe> niemeyer: here's the config CL updated so that it's not broken anymore. (i made certificates optional in config and it doesn't use juju.Bootstrap in cmd/juju) https://codereview.appspot.com/6846066/
<rogpeppe> niemeyer: i guess i'll need to create another merge request, but the changes are more obvious in this one
<rogpeppe> mgz: i'm not sure your technique of merging, then reverting works that well
<rogpeppe> mgz: because the changes i'd reverted to have already been applied in trunk, so they'll be ignored when i come to merge.
<rogpeppe> mgz: i think i should've just copied the tree
<mgz>  rogpeppe: I did give a warning, there's an extra step if there have been intermediate unmerged landings
<rogpeppe> mgz: i'm not sure exactly what you mean by "intermediate unmerged landings"
<mgz> rereading what you wrote, I'm not sure I understand what your problem was either...
<mgz> have you tried a test merge to trunk locally? it will probably just work.
<rogpeppe> mgz: i'll try
<TheMue> rogpeppe: You've seen, I reproposed our both CLs after fixes based on your reviews.
<mgz> the issue with just merging trunk and reverting is you need to check that the tree changes you're discarding with that are only the ones from the trunk reversion of the feature
<mgz> if there have been changes made to trunk since the feature branch last merged trunk, but before the trunk merge that reverted the feature merge, you need to be careful not to chuck them out
<rogpeppe> mgz: ah, i see
<mgz> depending on how you normally work, that's either very unlikely, or will pretty much always be the case
<rogpeppe> mgz: yeah, it seems to work. i was slightly confused by the way the CL on codereview didn't show all the diffs
<rogpeppe> mgz: that would've been the case if there'd been any significant time, 'cos i do tend to merge trunk as i go along
<mgz> and what you need in that case is just to merge trunk from just before the revert on trunk, keep those changes, then merge and discard the next trunk revsion that contains the revert
<rogpeppe> mgz: luckily, i don't *think* that was an issue
<mgz> the diff when relanding on trunk will be clear regardless
<TheMue> fwereade__: I'm currently in https://codereview.appspot.com/6852080/. You removed the empty line between standard and our packages in the import. So the sorting changes. Is that wanted?
<fwereade_> TheMue, whoops, those changes were not conscious
<fwereade_> TheMue, are we standardising on that behaviour?
<TheMue> fwereade_: Btw, so far it looks like a great simplification.
<TheMue> fwereade_: I'm not sure, I only recognized it twice now.
<fwereade_> TheMue, I've noticed it once or twice and have no very string feelings either way -- but my own habit is to do a single block of imports, so sometimes I "fix" them without noticing
<rogpeppe> fwereade_: where i've seen the two groups, i've thought it looked nice
<rogpeppe> fwereade_: i don't think we need to apply a standard too rigorously
<fwereade_> rogpeppe, yeah, I'm not actually in opposition, just occasionally thoughtless
<TheMue> fwereade_, rogpeppe: I don't need that kind of rule too.
<TheMue> fwereade_, rogpeppe: But indeed, it looks nice. ;)
<rogpeppe> niemeyer: here's the full CL for the config fixes. https://codereview.appspot.com/6843100
<rogpeppe> niemeyer: https://codereview.appspot.com/6846066/ makes it much easier to grasp
<niemeyer> rogpeppe: Brilliant, thank you!
<niemeyer> rogpeppe: So, is the 66 still valid now?
<rogpeppe> niemeyer: yes, but i'm not sure about submitting a CL twice...
<niemeyer> rogpeppe: I has a single LGTM
<rogpeppe> niemeyer: i'd use it on 3100
<rogpeppe> niemeyer: but they're the same thing
<rogpeppe> niemeyer: the branch is identical
<niemeyer> rogpeppe: Okay, I se
<niemeyer> e
<niemeyer> rogpeppe: So it's just the 3100
<rogpeppe> niemeyer: yeah
<niemeyer> rogpeppe: Superb, thanks
<rogpeppe> niemeyer: except the 66 shows just the changes that you need to see
<niemeyer> rogpeppe: I'll have a look once I'm back from my daily driver duties, which are finishing today luckily
<rogpeppe> niemeyer: np
<niemeyer> rogpeppe: I don't get that part
<rogpeppe> niemeyer: it's unexpected but useful in this case
<rogpeppe> niemeyer: presumably it's something to do with lbox's logic. i don't pretend to understand.
<niemeyer> rogpeppe: I've already reviewed the 66, and that's not it
<niemeyer> rogpeppe: Well, we should, because that's a monster branch
<niemeyer> rogpeppe: Saying it's the same as a tiny branch isn't clear
<rogpeppe> niemeyer: the launchpad branches *are* the same
<niemeyer> rogpeppe: If it's the same let's make it the same
<rogpeppe> niemeyer: the CL is just shown differently in both cases
<rogpeppe> niemeyer: it is really a monster branch
<niemeyer> rogpeppe: Yes, because you reverted tons of changes, and this branch is adding them back!
<rogpeppe> niemeyer: yeah
<rogpeppe> niemeyer: i don't know why the 066 isn't showing the monster
<niemeyer> rogpeppe: Because it was already submitted, and was done previously
<niemeyer> rogpeppe: Why is it adding the changes back?
<rogpeppe> niemeyer: but it's useful because it shows just the changes i've made on top of the original
<niemeyer> rogpeppe: I don't get it, sorry
<niemeyer> rogpeppe: You've just reverted tons of changes, and now is proposing a branch that adds it back exactly as it was
<rogpeppe> niemeyer: no exactly as it was. the 066 branch shows you the changes that i made on top of the original (unreverted) changes
<rogpeppe> s/no/not/
<niemeyer> rogpeppe: And asking me to review it, and saying you don't know what's going on.. I'm not very comfortable
<mgz> niemeyer: do you just want the original branch as a prerequiste so you can see what's changed?
<mgz> clearly the branch itself will contain much the same changes (plus whatever fixup was needed), so the default diff will
<rogpeppe> mgz: hmm, maybe that'll work. except that... i'm not sure it can.
<niemeyer> rogpeppe: The 66 is the 66.. it shows the changes you made that *went in*
<niemeyer> rogpeppe: It was submitted
<rogpeppe> niemeyer: no, i've reproposed it
<rogpeppe> niemeyer: which might've been the wrong thing to do, admittedly :-)
<niemeyer> rogpeppe: Yes, the same branch, wiht the same changes
<niemeyer> rogpeppe: Including what was reverted
<rogpeppe> niemeyer: i'm not sure i understand.
<rogpeppe> niemeyer: we've got one branch which, now, includes all the unrevert changes, and a few changes i made on top of those.
<mgz> niemeyer: the reverted stuff does still want to land, it was reverted so it could be fixed up, not because the change was rejected
<mgz> so, the new proposal naturally includes many of the same things as the original proposal that got reverted
<rogpeppe> yeah, that's it
<niemeyer> Yeah, so it's not the same thing
<rogpeppe> the new proposal is almost the same as the old proposal. the 066 branch conveniently says exactly how it's different
<niemeyer> mgz: <rogpeppe> niemeyer: the launchpad branches *are* the same
<niemeyer> Sorry guys, I really have to leave now
<niemeyer> I'll be back later
<mgz> I think he means the branch (name/location) is the same, it now includes a few more changes over last time though
<rogpeppe> mgz: no, they really are the same
<rogpeppe> mgz: http://paste.ubuntu.com/1375040/
<rogpeppe> mgz: well, with that one change (i'd accidentally reverted dave cheney's trunk change)
<mgz> that's a big paste...
<rogpeppe> mgz: oops!
<mgz> okay, so you did basically what I would have, but in a slightly different order
<rogpeppe> mgz: i accidentally pastebinned my entire shell window
<mgz> you've got one proposal with basically the previous changes, and then another one on with that as a prereq and specifically has been fixed since last landing?
<rogpeppe> mgz: this is what i meant to paste: http://paste.ubuntu.com/1375042/
<mgz> you can fix the accidental trunk revert by just cherrypicking that rev again I think
<rogpeppe> mgz: i think i'll do that. it might make it easier to explain.
<rogpeppe> mgz: currently i have no prereq in the fix branch
<rogpeppe> mgz: i did a patch to fix the accidental trunk revert, which was probably the wrong approach
<mgz> that's also fine.
<rogpeppe> mgz: but i thought it wasn't too much problem for two lines...
<mgz> provided it's fixed in the feature branch, it doesn't matter that it briefly went walkies
<rogpeppe> mgz: i thought so too
<rogpeppe> right, i'll try again with a prereq
<mgz> yeah, and just refer the inital proposal to the identical previous one, and mention fixups are following
 * rogpeppe wishes launchpad prereqs were more flexible
<TheMue> fwereade_: You've got a review.
<rogpeppe> mgz: ha, now i've got a nice branch with prerequisite (https://codereview.appspot.com/6843101), but the original branch isn't showing any changes, because of course it's been submitted. gah!
<dimitern> hey, my first CL in juju-core! :) https://code.launchpad.net/~dimitern/juju-core/openstack-stub-provider-config/+merge/135454 - anybody could take a look?
<rogpeppe> dimitern: can you propose it in codereview?
<dimitern> rogpeppe: lbox is broken for me
<rogpeppe> dimitern: what happens?
<TheMue> fwereade_: So you could review https://codereview.appspot.com/6852065/ and https://codereview.appspot.com/6853075/ for me.
<fwereade_> TheMue, a pleasure
<dimitern> it worked all the way until rietveld push, then: panic: runtime error: invalid memory address or nil pointer dereference
<TheMue> rogpeppe: I've changed ^^ after your reviews.
<dimitern> rogpeppe: wanna see the full paste?
<rogpeppe> dimitern: go on then
<TheMue> fwereade_: Cheers.
<dimitern> dimitern: http://paste.ubuntu.com/1375072/
<rogpeppe> dimitern: hmm, this looks suspicious to me: http://paste.ubuntu.com/1375082/
<mgz> dimitern: do you want me to review on launchpad, or are you going to put up on cr too?
<mgz> ...I guess the answer to that question depends on if you can get lbox fixed
<dimitern> mgz: exactly, I'd rather have lbox working
<rogpeppe> dimitern: could you try this:
<rogpeppe> dimitern: at launchpad.net/goetveld/rietveld/auth.go:181
<rogpeppe> dimitern: change the logf line to this:
<rogpeppe> 	logf("Login on %s successful; error %v (%T)", rietveldURL, err, err)
<rogpeppe> dimitern: then run lbox propose -v
<dimitern> rogpeppe: ok
<rogpeppe> dimitern: after go installing lbox
<rogpeppe> dimitern: (make sure you're using the lbox from your GOPATH, not /usr/bin/lbox)
<dimitern> rogpeppe: ok, so it still fails, but at least with some other error: http://paste.ubuntu.com/1375096/
<mramm2> Anybody need anything before I sign out for the evening? If not I'll see you all after thanksgiving.
<dimitern> rogpeppe: I swear I authorized rietveld to use my @canonical account few days ago, and it seems it forgot, because initially login failed, but then I went to appspot and enabled it again, the result is in the last paste
<mramm2> I was able to get a lot of organizational work done on today, and will be back working Monday
<mramm2> monday/tuesday next week I'll be working on setting up blueprints for this cycle
<mramm2> so I may ask for some help from folks on that that here and there -- just an FYI ;)
<dimitern> mramm2: have a good thanksgiving ;)
<rogpeppe> dimitern: are you sure that's using the lbox you just changed?
<dimitern> rogpeppe: well, I changed the code in goetveld, did go install launchpad.net/lbox and then run lbox propose -v
<rogpeppe> dimitern: are you sure you're not running /usr/bin/lbox?
<dimitern> rogpeppe: dimitern@kubrik:~/work/juju-core$ which lbox
<dimitern> /home/dimitern/work/go/bin/lbox
<rogpeppe> hrmph
<rogpeppe> dimitern: ok, how about inserting a line after the client.Get in the same function:
<rogpeppe> 	logf("client.Get returned %#v, %#v", r, err)
<rogpeppe> dimitern: 'cos i can't quite see how it can get to call Cookies without printing the "Login successful" message.
<dimitern> rogpeppe: I'm doing it now
<dimitern> 2012/11/21 17:18:16 RIETVELD client.Get returned (*http.Response)(nil), &url.Error{Op:"Get", URL:"http://example.com/marker", Err:(*errors.errorString)(0xf8400a26d0)}
<rogpeppe> dimitern: you might check the mtime on the lbox binary to verify that it has actually been rebuilt too
<dimitern> 2012/11/21 17:18:16 RIETVELD Login on https://codereview.appspot.com successful; error Get http://example.com/marker: redirect blocked (*url.Error)
<dimitern> 2012/11/21 17:18:16 RIETVELD Login failed: Get http://example.com/marker: redirect blocked
<dimitern> rogpeppe: ^^ it is rebuilt
<rogpeppe> dimitern: could i see the whole paste?
<dimitern> rogpeppe: sure - http://paste.ubuntu.com/1375114/
<dimitern> rogpeppe: what's that redirect blocked crap? it seems the same error is carried over from a previous call
<rogpeppe> dimitern: i dunno.
<dimitern> rogpeppe: william is mentioning something similar happened to him before, but then he used lbox from some ppa and was fixed
<rogpeppe> dimitern: ah, i wonder if there are two url fetches happening concurrently...
<rogpeppe> dimitern: that would explain a lot
<dimitern> rogpeppe: hmm.. ok, how to fix that?
<rogpeppe> dimitern: well, it *should* be just fine
<rogpeppe> dimitern: but it explains why i'm seeing the Login failed message after the Login successful message
<dimitern> rogpeppe: i c
<dimitern> rogpeppe: why lbox keeps asking me to login each time? any way to cache this?
<rogpeppe> dimitern: out of interest, i wonder if it makes a difference if you're using a different go version
<rogpeppe> dimitern: what does "go version" print?
<dimitern> go version go1.0.3
<dimitern> rogpeppe: I got it from golang.org and have it locally installed, rather than from apt
<rogpeppe> dimitern: hmm, 1.0.3 *should* be fine
<rogpeppe> dimitern: how about trying to replace the end of the function with this: http://paste.ubuntu.com/1375133/
<dimitern> rogpeppe: will do
<rogpeppe> dimitern: that should stop the crash, but i'm thinking it won't fix your problem :-)
<rogpeppe> dimitern: in fact, here's a better thing, that should confirm the concurrent hypothesis too: http://paste.ubuntu.com/1375137/
<dimitern> rogpeppe: it seems there is an auth issue
<rogpeppe> dimitern: yeah, your authorisation is failing somehow
<rogpeppe> dimitern: in a way not anticipated by lbox...
<dimitern> rogpeppe: I applied the last patch and retrying now
<dimitern> rogpeppe: http://paste.ubuntu.com/1375145/
<dimitern> rogpeppe: this time, it didn't crash (and the last patch didn't - as you said), but it asked me twice for creds
<rogpeppe> dimitern: ah, i think i understand now
<rogpeppe> dimitern: there were two concurrent auth requests. the auth caching will block out one of them
<rogpeppe> dimitern: then one crashes and the other manages to step in and do something before the panic hits
<dimitern> rogpeppe: hmm..
<rogpeppe> dimitern: something like that, anyway
<dimitern> rogpeppe: do you see a solution?
<rogpeppe> dimitern: i'd be interested to see if it fails against go tip
<rogpeppe> dimitern: try going to your $GOROOT/src, running hg update tip, then all.bash
<dimitern> rogpeppe: ok
<rogpeppe> dimitern: then go install launchpad.net/lbox again
<dimitern> rogpeppe: there's no .hg repo there
<rogpeppe> dimitern: oh i thought you'd done an hg get from golang.org
<dimitern> rogpeppe: no, it seems I got a tarball
<rogpeppe> dimitern: you might wanna do that. it's useful to have.
<dimitern> I can check it out in another dir and change paths to use it - feels safer anyway
<rogpeppe> dimitern: see https://code.google.com/p/go/source/checkout
<rogpeppe> dimitern: yeah, i keep two go roots around
<rogpeppe> dimitern: but it's actually safer to always build a given tree against the same GOROOT
<rogpeppe> dimitern: so that mtime comparison works properly
<dimitern> rogpeppe: ok, I'm checking out go tip, then I'll run ./all.bash in src and then get to lbox, right?
<rogpeppe> dimitern: yeah. you can usually interrupt after the tests have begun in all.bash BTW
<rogpeppe> dimitern: it makes rebuilding quite a bit faster
<dimitern> rogpeppe: ok
<rogpeppe> dimitern: although it's worth running the tests at least once, probably
<rogpeppe> dimitern: they only take a couple of minutes
<dimitern> rogpeppe: couple of minutes i can handle :) when it's not 2h
<rogpeppe> dimitern: yeah, we're spoilt with go
<dimitern> rogpeppe: it's done - all tests passed, and I changed $GOROOT to point to go-tip, but left $GOPATH the old value, so I don't have to move everything
<dimitern> rogpeppe: then did go install launchpad.net/lbox, and now I'm doing lbox propose -v again
<rogpeppe> dimitern: that should work
<dimitern> rogpeppe: yes! it worked this time!
<rogpeppe> dimitern: ah, i thought that might be the case
<rogpeppe> dimitern: there's some weird shit going on with http requests, and i know gustavo's unhappy with something about it in 1.0.3
<dimitern> rogpeppe: now would you care to review? :) https://codereview.appspot.com/6858052/
<rogpeppe> dimitern: looking
<dimitern> rogpeppe: hmm, but now, once I have lbox compiled and running, I should switch back to go 1.0.3, right?
<rogpeppe> dimitern: personally i run against tip most of the time
<rogpeppe> dimitern: but i test against 1.0.3 too
<dimitern> rogpeppe: I'll try to do that as well then
<rogpeppe> dimitern: there's actually no reason you can't switch back to 1.0.3
<rogpeppe> dimitern: just don't recompile lbox against it
<dimitern> rogpeppe: yeah, for sure I won't :) now that I have it working finally
<TheMue> So, have to leave, no lunch, but now is dinnertime. CU tomorrow.
<rogpeppe> dimitern: you have a review
<dimitern> rogpeppe: thanks!
<rogpeppe> niemeyer: here's another version of the CL, hopefully easier to understand what's going on now: https://codereview.appspot.com/6843101
<rogpeppe> niemeyer: it has the old branch as a prereq
<rogpeppe> niemeyer: (you can see the contents of the old branch by clicking on the comments)
<mgz> dimitern: also reviewed.
<dimitern> mgz: thanks! 2 reviews now - so I'll fix what was suggested
<rogpeppe> niemeyer: hmm, maybe you'll still be unhappy.
<rogpeppe> mgz: secret attrs is for attributes that can't be pushed in cloudinit, and will be pushed over a secure connection on the first connection after bootstrap
<dimitern> mgz: what I didn't get is are you generally happy or sad with the review :)
<mgz> dimitern: it's a stub, so most of the comments are just comments :)
<dimitern> mgz: yes, but the config is basically as it will be
<mgz> I'd rename the config vars now though
<dimitern> mgz: fair enough, that I'll do yes
<rogpeppe> yeah, we try to go for python config compatibility except where necessary
<mgz> identity-url -> auth-url and probably tenant-id -> project-name (but that one we'll want to fiddle with later anyway, as want to cope with being given either name or id)
<dimitern> mgz: so the CredsFromEnv in the refactored code from ian is now in goose?
<mgz> it predates that, but the client code now uses that identity code, yes
<mgz> I note rogpeppe also commented on the envvar overriding in your config_test.go file (module? what's the right term in go?), so that may be worth tackling now as well
<rogpeppe> mgz: file
<rogpeppe> mgz, dimitern: yeah, if there are potentially more env vars to come, it's definitely worth doing
<dimitern> mgz, rogpeppe: so tenant-id -> project-name or tenant-name
<rogpeppe> dimitern: i'm sorry, i'm not familiar with the openstack config names
<mgz> dimitern: it's a long story :)
<dimitern> rogpeppe: well the env var is OS_TENANT_NAME
<mgz> "tenant" is what the thing is called in the keystone code at present, but they keep threatening to rename it
<rogpeppe> mgz: if in doubt, do what python does now
<dimitern> so I'll change it to tenant-name
<mgz> it used to be called project, and may again at some point, because it's not actually a tenant
<mgz> and whenever people talk about, for instance, multi-tenancy in openstack they mean a different kind of 'tenant'
<mgz> so, it's an overloaded term, which is why I used 'project-name' in the original implementation (the having both name an id is an additional complication...)
<rogpeppe> niemeyer: finally, here's a version that you might possibly be happy with: https://codereview.appspot.com/6850087/
<mgz> see for instance this line in your novarc:
<mgz> export NOVA_PROJECT_ID="${OS_TENANT_NAME}"
<rogpeppe> niemeyer: it has the original branch as a prereq (in a different CL, so all the changes are visible)
<dimitern> mgz: not sure i want to couple the openstack/config with the goose/identity just yet though
<mgz> dimitern: that's probably fine to leave for later, but I'd add some comments about what goes where
<dimitern> mgz: won't it be better to leave the dummyAuth for now, until ..
<dimitern> mgz: yeah, just started writing the same thing
<dimitern> ok, I'll go back to my place and work on the CL some more, see you guys tomorrow!
<mgz> later!
#juju-dev 2012-11-22
<wallyworld_> jam: g'day, can haz mumble?
<TheMue> Good morning.
<fwereade_> mornings
<TheMue> fwereade_: Thx for your reviews. And yes, so far I've concentrated on positive testing. I will harden it now.
<TheMue> fwereade_: Btw, over night I found a little trouble with your regex for valid machine ids.
<TheMue> fwereade_: Right now leading zeros are ok, like "000000001".
<TheMue> fwereade_: I don't think that's wanted.
<fwereade_> TheMue, hmm, interesting
<fwereade_> TheMue, yeah, thank you, good catch
<TheMue> fwereade_: Cheers.
<fwereade_> morning rogpeppe1
<TheMue> rogpeppe1: Good morning.
<fwereade_> hm, I appear to be nutritionally challenged, need to pop out for a croissant or something, bbs
<rogpeppe1> fwereade_, TheMue: morning!
<TheMue> rogpeppe1: Hiay.
 * TheMue has somewhat crooked fingers again this morning.
<rogpeppe1> fwereade_, TheMue: if you've a moment at some point, i would quite like a review of a branch that fixes an earlier trunk-reverted branch. this CL is exactly the changes that were LGTM'd, submitted and reverted: https://codereview.appspot.com/6852081/. this CL holds the changes that i've made to fix it: https://codereview.appspot.com/6850087/
<TheMue> rogpeppe1: *click*
<TheMue> rogpeppe1: Could you please tell me more about the current state of the fake home?
 * fwereade_ looks
<rogpeppe1> TheMue: i'm not sure what you mean, sorry
<TheMue> rogpeppe1: As far as I remember the discussion about the fake home has been controversal. But I may be wrong.
<rogpeppe1> TheMue: in this case it's just a local helper function
<TheMue> rogpeppe1: Ah, ok.
<rogpeppe1> TheMue: the controversial thing was making it into a test fixture
<TheMue> rogpeppe1: Yes, now I remember.
<fwereade_> rogpeppe1, sorry, but I'm having a bit of difficulty orienting myself -- I haven't been paying close attention to your discussions
<rogpeppe1> fwereade_: ok, brief summary:
<rogpeppe1> fwereade_: the original branch made ca-cert and ca-private-key keys in the config.Config
<rogpeppe1> fwereade_: with logic to read them from ~/.juju/<envname>-cert.pem and ~/.juju/<envname>-private-key.pem if necessary
<rogpeppe1> fwereade_: (similar to the authorized-keys behaviour)
<rogpeppe1> fwereade_: that branch was approved and submitted, but...
<rogpeppe1> fwereade_: unfortunately it interacted badly with another parallel change, and a bad test meant i didn't catch it
<rogpeppe1> fwereade_: so, after discussion with gustavo, this pair of CLs a) reapplies all the changes that were reverted and b) applies a fix
<fwereade_> rogpeppe1, can we drill down into the bad interaction a little?
<rogpeppe1> fwereade_: ok. the bad interaction was with juju.Bootstrap
<rogpeppe1> fwereade_: which expected the old scheme of putting both certificate and key in the same file
<rogpeppe1> fwereade_: the problem was that i was expecting juju.Bootstrap to generate a certificate that the config could read
<rogpeppe1> fwereade_: but it didn't
<rogpeppe1> fwereade_: (i did have an explicit test for that, but it wasn't working, which is the cause of all these problems)
<rogpeppe1> fwereade_: so this is a temporary band-aid fix that gets this huge branch in without breaking trunk so i can fix juju.Bootstrap in the next iteration.
<rogpeppe1> fwereade_: (the config stuff will remain as proposed)
<rogpeppe1> fwereade_: i really don't to pile more changes into this CL if at all possible
<fwereade_> rogpeppe1, I remain confused about whether we're expecting one file or two
<fwereade_> rogpeppe1, that []byte in juju/bootstrap.go implies one; the config stuff implies 2
<rogpeppe1> fwereade_: this CL leaves us in a half-way house - juju.Bootstrap expectes one; the config expects two
<rogpeppe1> fwereade_: but nothing in this branch relies on juju.Bootstrap to generate a certificate
<rogpeppe1> fwereade_: or to read a certificate
<rogpeppe1> fwereade_: (because all tests explicitly pass in the cert/key pair)
<fwereade_> rogpeppe1, ok... but what about actually running juju?
<rogpeppe1> fwereade_: that's fine. we don't use juju.Bootstrap.
<rogpeppe1> fwereade_: the cert/key pair isn't used anyway
<rogpeppe1> yet
<rogpeppe1> fwereade_: note the changes here: https://codereview.appspot.com/6850087/diff/3003/cmd/juju/bootstrap.go
<rogpeppe1> fwereade_: i have tested it live - it works
<fwereade_> rogpeppe1, yeah, that was the source of my confusion really :)
<rogpeppe1> fwereade_: yeah, the whole thing is a little confusing - two independent branches interacting badly.
<rogpeppe1> fwereade_: (i'd abandoned the config change 'cos gustavo said it was crack, but he later changed his mind and said that was just what we wanted)
<fwereade_> rogpeppe1, heh :)
<dimitern> rogpeppe, mgz, jam: please have a look https://codereview.appspot.com/6858052/ - after fixing what was suggested
<mgz> dimitern: sure.
<fwereade_> rogpeppe, so... to follow up, you're going to cause [some bootstrap machinery] to generate cert/key where required, and make it mandatory again in config; and then subsequently start depending on it on the server side?
<rogpeppe> fwereade_: yes to the first, but actually the cert will remain optional
<rogpeppe> fwereade_: because otherwise we can't read a config file without first generating the certificates
<fwereade_> rogpeppe, ok, but the cert will not be optional on the server side?
<rogpeppe> fwereade_: no indeed. it'll be a required flag in cmd/jujud, and required when creating a cloudinit MachineConfig too.
<fwereade_> (grumble grumble, user config and state config are not the same)
<rogpeppe> fwereade_: yeah
<fwereade_> rogpeppe, ok; and what you're really interested in is review of the second branch, on the basis that the first one has in fact already been LGTMed?
<rogpeppe> fwereade_: precisely
<mgz> hm, how do to I get the interdiff on cr? or should I just branch this locally...
<rogpeppe> mgz: the interdiff?
<rogpeppe> mgz: you can get a diff between any two stages in cr by adjusting the "Left" and "Right" popup menus
<mgz> dimitern updated his merge proposal, I want to see what changed... I guess I can just use lp.
<mgz> the whats?
<dimitern> mgz: well, I did the changes in the same branch, pushed and then lbox propose - did I do it wrong?
<fwereade_> mgz, look in the "Delta from patch set" column
<rogpeppe> mgz: if you're in the "Side by Side Diff" page, there's are two buttons at the top left, labelled "Left" and "right"
<mgz> dimitern: nope, I just don't know how to use cr
<rogpeppe> mgz: Each one holds one iteration of the review. You can adjust as you like, then click "Go" to see the differences
<mgz> there's only '1' listed in that column
<fwereade_> mgz, so that is then the diff from patch set one, right?
<rogpeppe> mgz: i see two: for instance: https://codereview.appspot.com/6858052/diff2/1:5002/environs/openstack/config.go
<rogpeppe> davecheney: yo!
<mgz> ah, so it's 0 otherwise
<rogpeppe> mgz: "j" and "k" are convenient keyboard shortcuts for moving forward and backwards between files
<fwereade_> mgz, yeah, if you expand Patch Set 1 you will see the column is empty
 * rogpeppe never uses the "Delta from patch set" column, other than as informational content.
<dimitern> cool! I was looking for that too - the delta column is great
<rogpeppe> what i usually do is click on a comment, then adjust the "Right" button to point to the latest iteration.
<rogpeppe> 'cos i'm almost always interested in what's changed since a given comment
<wallyworld_> dimitern: mgz: jam: standup?
<TheMue> rogpeppe: You've got a review.
<niemeyer> Morning!
<rogpeppe> TheMue: thanks!
<rogpeppe> niemeyer: yo!
<TheMue> niemeyer: Hiya.
<dimitern> mgz, jam: wallyworld_ and me are in mumble
<mgz> jam is off again today I think, I'll be with you guys shortly
<wallyworld_> dimitern: mgz: https://pastebin.canonical.com/78914/
<fwereade_> niemeyer, morning
<TheMue> lunchtime
<mgz> that odd "Get http://example.com/marker" bit is the same as dimitern had, but you're not getting the crash
<niemeyer> mgz: This is an issue introduced in 1.0.3
<niemeyer> mgz: and unfortunately there isn't a workaround
<niemeyer> mgz: Even more unfortunately, I perceived that in advance of the release, and we fixed it
<niemeyer> mgz: But luck wanted the bug to be cherrypicked for the release, and not the fix
<rogpeppe> i'm having an extended lunch break today, back in about 3 hours
<dimitern> rogpeppe: cool :)
<niemeyer> rogpeppe: Enjoy
<niemeyer> rogpeppe: We should catch up when you're back, to sync up on the branches that should go in
<rogpeppe> niemeyer: yes please
<rogpeppe> niemeyer: in case you manage to get to it before i return, here's a summary of the one i'm most concerned about:
<rogpeppe>  this CL is exactly the changes that were LGTM'd, submitted and reverted: https://codereview.appspot.com/6852081/. this CL holds the changes that i've made to fix it: https://codereview.appspot.com/6850087/
<niemeyer> rogpeppe: Ah, great.. so the former one is just the revert reverted :-)
<rogpeppe> niemeyer: yeah
<niemeyer> rogpeppe: Thanks, that makes things a lot easier
<rogpeppe> niemeyer: i hoped it might help :-)
<dimitern> fwereade_: ping
<dimitern> niemeyer: so now, after having 2 positive reviews, how's the process to land the CL into lp:juju-core?
<dimitern> niemeyer: just merge the branch into trunk and push it?
<dimitern> TheMue: maybe you can help? ^^
<TheMue> dimitern: You're working with lbox?
<niemeyer> dimitern: No
<niemeyer> dimitern: lbox submit
<dimitern> niemeyer: I see, just that?
<niemeyer> dimitern: That said, can you please wait a moment on that one
<niemeyer> dimitern: Since this is the bootstrap, I'd like to follow at least the first few steps on it
<dimitern> niemeyer: sure, I'd like that
<niemeyer> dimitern: I'll look up right now so I don't block you
<dimitern> niemeyer: thanks!
<niemeyer> dimitern: What's "tenant-name"?
<dimitern> niemeyer: that's one of openstack's auth credentials
<dimitern> niemeyer: it's a bit controversial - sometimes called project-name, and in the api it's called tenant id
<niemeyer> dimitern: Cool
<niemeyer> dimitern: SO why do we go in the middle?
<niemeyer> :)
<niemeyer> dimitern: tenant-name isn't either of them :)
<dimitern> niemeyer: but the env var is called OS_TENANT_NAME or NOVA_PROJECT_ID
<niemeyer> dimitern: Wow, okay
<mgz> it's a little more complicated...
<niemeyer> Seriously diverse
<mgz> what exactly it is depends across versions and deployments, we probably want some fancier logic here in future
<niemeyer> mgz: Can you describe a bit more of the issue?
<mgz> want the long fairy tale? :)
<mgz> so, in the beginning there was nova
<dimitern> niemeyer: from the openstack docs: "Credentials are a combination of your username, password, and what tenant (or project) your cloud is running under. " (http://docs.openstack.org/api/quick-start/content/)
<niemeyer> Thanks, it would be useful to picture what we should do
<mgz> it had code for handling authentication itself#
<mgz> and that had support added for using 'project' as a sort of group id for resources, so multiple users could share control of a resource
<mgz> with the growth of the project, various things that used to be in nova started getting pulled out into seperate codebases
<mgz> the new auth stuff is keystone... which is a complicated history itself... the initial version wasn't accepted but got rewritten as keystone-lite just in time for being a core component of essex
<mgz> for... not very good reasons, they use 'tenant' for the same concept, so you as a user are a member of one or more tenants
<mgz> which are then the things that own particular resources, and when you request an access token, that token is (generally) associated with a particular tenant
<mgz> so, all api calls using that token are scoped to that tenant
<mgz> the confusing thing is 'tenant' was already in use as a term for a different concept, particularly with regards to multi-tenancy
<niemeyer> Gosh :(
<mgz> so, they keystone guys were threatening to rename back to 'project' again... but that's probably too disruptive now
<mgz> the name vs id thing is simpler
<mgz> the old way of refering to a project in nova was by an integer (basically a unique id straight from the db I think)
<mgz> ...is that right?... it might have been a string
<mgz> at any rate, the new style is all objects have a UUID associated
<niemeyer> mgz: Okay, and how did "name" get in there?
<mgz> and any that used to have a unique name still have that, and some api calls take a name rather than the UUID
<niemeyer> mgz: Is it a uuid or something else?
<mgz> it was originally a string name in the first versions of the code, so eg, my username is gz, the default tenant that gets created just for me is gz_project
<mgz> that's nice because you can see at a glance what the tenant is about
<mgz> but... when constructing urls and such like, the style is /object/UUID/stuff
<niemeyer> OMG
<niemeyer> :)
<niemeyer> It's hard to believe such a trivial concept can get so involved
<mgz> for keystone and tenants, this diversion doesn't matter too much, as there's basically only one api call juju needs to use (everything else is admin related)
<mgz> and these days it accepts either the name or the id
<mgz> you just need to know which you have.
<mgz> the fun part only comes when supporting deployments based on older versions
<niemeyer> mgz: I see
<mgz> generally though, we always have one way of refering to a tenant, and should be able to tell from the envvar whether it's a name or an id.
<niemeyer> mgz: So what's name? :)
<niemeyer> mgz: "gz_project"?
<mgz> yup.
<niemeyer> mgz: and that's automatically assigned by the provider?
<niemeyer> mgz: or can you customize it?
<mgz> it's part of the keystone user account management stuff
<mgz> so, the cloud admin sets it, and you'll get one in your account details from them
<mgz> eg, on my hp cloud api keys page,
<mgz> there's a "Tenant" heading that lists both an id (...which is an integer not a uuid, hp is special) and a name (which is <username>-default-tenant)
<niemeyer> mgz: i see
<niemeyer> mgz: What about "container"?
<mgz> in what context?
<niemeyer> mgz: Does it have such an involved history as well? :)
<niemeyer> mgz: THe setting
<dimitern> niemeyer: the container is the equivalent of control-bucket for aws
<mgz> ah, I think I just used bucket-name for that in the python as there's no useful reason to distinguish it from S3
<niemeyer> Can we use "control-bucket" then?
<mgz> that's the thingy.
<dimitern> mgz: but in the python version, the s3-compatible api is used, not swift where there are no buckets
<mgz> dimitern: both are supported
<mgz> and both use control-bucket for the key name as that's then less confusing (except for the person writing the swift api code)
<mgz> I wonder what the benefit fo expecting the user to configure that is though
<dimitern> mgz: exactly, the swift api uses containers instead of buckets
<mgz> have had people having issues because they used "yourrandombucketname" literally... as did someone else
<dimitern> niemeyer: sure, we can use "control-bucket", but won't it be confusing for people who know openstack swift?
<mgz> dimitern: that can safely be assumed to be a minority of people :)
<niemeyer> dimitern: I'd prefer to not confuse people that know juju
<dimitern> niemeyer: ok, I can change container->controlBucket then
<niemeyer> dimitern: I don't like control-bucket either, to be honest.. I hope we can kill it soon, on both providers
<mgz> right, having it manually configured is... not pretty
<niemeyer> mgz: Yeah, it's actually automatically generated in Python at the moment.. we should do that for openstack too
<niemeyer> mgz: So a sample file is generate with the field pre-filed
<mgz> the issue is it always appears in the example juju configs
<niemeyer> mgz: Eventually, juju will not require any external storage
<niemeyer> mgz: and then we can kill this for good
<dimitern> niemeyer: apart from this, other things look ok to you?
<mgz> people too often don't seem to use the pre-fill logic when setting up juju for the first time
<niemeyer> dimitern: Btw, I just noticed you have a review from Roger pending
<niemeyer> dimitern: I'm providing a review.. nothing large so far
<dimitern> niemeyer: pending? he did it yesterday and I fixed what he proposed..
<mgz> I think you can carry over the lgtm, it's just marked him as he looked at the previous version
<niemeyer> dimitern: Yes, but once someone reviews your code and asks for changes, you should wait for a LGTM from them
<niemeyer> dimitern: Or at least an explicit dismissal saying "wait for someone else"
<niemeyer> dimitern: "LGTM" is the special key there
<dimitern> niemeyer: I see, I just assumed he generally liked it, once I do the changes it will be "LGTM", maybe I'm wrong here
<mgz> niemeyer: do you have a lgtm-and-I-trust-you-to-change-these-trivial-things-before-landing concept?
<mgz> or are things generally always re-reviewed?
<niemeyer> mgz: No, we do have that
<niemeyer> mgz: "LGTM with the following:"
<niemeyer> mgz: That assumes the reviewer trusts it to go in, assuming the suggestions are sensible and are applied
<dimitern> niemeyer: Ok, I see, I'll ping roger later for re-review
<niemeyer> mgz: Sometimes it doesn't quite fly because the author doesn't think they are sensible, which causes talks and re-reviews
<niemeyer> mgz: But that's the exception
<mgz> thanks.
<niemeyer> No problem
<dimitern> niemeyer: in the mean time, I started another related branch to implement private/public addresses in the provider
<niemeyer> dimitern: Super
<niemeyer> dimitern: You can even push that to review if you get to completion, by using -req
<niemeyer> dimitern: on lbox
<dimitern> niemeyer: yeah, that's my plan
<niemeyer> dimitern: Review sent
<niemeyer> dimitern: Very nice bootstrap
<dimitern> niemeyer: thanks!
<dimitern> niemeyer: updated as suggested https://codereview.appspot.com/6858052/
<niemeyer> dimitern: Thanks!
<dimitern> niemeyer: so now, as soon as roger gives his final LGTM, I can lbox submit it?
<niemeyer> dimitern: Yep!
<dimitern> super, thanks
<dimitern> niemeyer: one more question about the lbox process - so, after I have a review I see I can reply to each inline comment (done or reply), once I do that I send my replies, should I do lbox propose again, or I need just to push the branch changes only?
<niemeyer> dimitern: You need to do propose again
<dimitern> ok
<niemeyer> dimitern: Otherwise the diff in Rietveld isn't updated
<dimitern> niemeyer: so I shouldn't worry I'm sending too many emails for a CL :)
<niemeyer> dimitern: Note that if you write down drafts after the comments (done, reply, etc), you can do "lbox propose" and it'll publish your drafts as well
<dimitern> niemeyer: nice! so I don't need to publish them from the site myself
<niemeyer> dimitern: Thta's right
<fwereade_> dimitern, sorry, just back from lunch
<dimitern> fwereade_: np, just got some reviews flowing :)
<fwereade_> dimitern, cool
<dimitern> fwereade_: if you want to take a look: https://codereview.appspot.com/6858052/
 * fwereade_ looks
<fwereade_> dimitern, just a quick thought: can you at least check that the region != ""? or can even that be valid?
<dimitern> fwereade_: good point, I can check for this
<dimitern> fwereade_: I has to be set to something at least
<fwereade_> dimitern, maybe also worth checking that auth-url is actually a valid URL?
<dimitern> fwereade_: I thought about this, but was not sure of an easy way to parse/check it - anything in go like urlparse?
<fwereade_> dimitern, net/url
<dimitern> fwereade_: cool, I'll check it out
<fwereade_> dimitern, has a Parse func
<fwereade_> dimitern, and if I'm being really picky I might suggest positive tests for changing the values that can/should change... and I'm suspicious of making the firewall mode changeable
<fwereade_> rogpeppe, TheMue, niemeyer: *should* firewall-mode be mutable? (and should it even maybe be common to all providers?)
<dimitern> fwereade_: don't know about the firewall mode
<fwereade_> dimitern, nor do I really, hence my question above :)
<TheMue> fwereade_: Hard to say. For sure it would be implementable, but with a lot changes. And which reason?
<TheMue> fwereade_: OK, maybe if we reach the limit of EC2 dynamically switch to global mode.
 * TheMue thinks.
<TheMue> fwereade_: Why do you think about making it changable?
<fwereade_> TheMue, just because it appears that it is
<fwereade_> TheMue, and I was wondering whetherthat was sane
<TheMue> fwereade_: It is? Have to take a look.
<fwereade_> TheMue, it appears to be in dimitern's CL; haven't looked at EC2
<niemeyer> fwereade_: I think it shouldn't be allowed
<niemeyer> fwereade_: One of the reasons why I didn't suggest restricting yet is because it's handy for tests to be able to change it
<fwereade_> niemeyer, both are perfectly reasonable, but somewhat in conflict :)
<fwereade_> niemeyer, do you have an opinion on making it part of config.Config rather than provider-specific?
<niemeyer> fwereade_: They are in conflict indeed, and the behavior on changes isn't user friendly, so you're right.. the final implementation should reject changes
<niemeyer> fwereade_: Making what part of config.Config? (it is already there?)
<fwereade_> niemeyer, I don't think so; it seems to be in danger of being duplicated across ec2/openstack
<fwereade_> niemeyer, (fwiw, ISTM that it's not *overwhelmingly* handy to change it in tests when we could have separate env setup for separate tests...)
<niemeyer> fwereade_: FirewallMode and the respective settings are all in config.. what are you referring to, more exactly?
<fwereade_> niemeyer, ok, perhaps I am smoking crack, I had expected that if it were handled in config.Config we wouldn't need to touch it in provider-specific configs
<niemeyer> fwereade_: Sorry, I still don't know what you're referring to
<fwereade_> niemeyer, I am talking about FirewallMode, but it appears I'm being dumb -- it is properly handled in config.Config, but it seems it also needs to be checked in Validate for each provider
<niemeyer> fwereade_: Ah, yes, it does
<niemeyer> fwereade_: Only because each provider offers its own idea of what is possible or not, and what's the default
<niemeyer> fwereade_: But I think that's inherent to the problem
<niemeyer> fwereade_: (IOW, we can't avoid it)
<fwereade_> niemeyer, yeah, that makes sense
<fwereade_> niemeyer, sorry noise :)
<niemeyer> fwereade_: np at  all
<fwereade_> so, dimitern, looks like the firewall handling is just fine
<fwereade_> dimitern, niemeyer: but when we tighten it up and make it unchangeable we should be sure to do so in each Validate method
<dimitern> fwereade_: cool, well I just replicated the ec2 tests there - I supposed should be there
<fwereade_> dimitern, yeah, seems sane
<TheMue> fwereade_: I also looked and it seems that ec2 allows to change/set it in SetConfig() of environ. But The overall EnvironmentProvider and Environment interfaces doen't provide that method. The â¦Provider only takes the Config at Open().
<dimitern> so, when I have something for review, should I always post it here, or somebody will see it and pick it up?
<fwereade_> TheMue, Environ certainly does expose SetConfig
<fwereade_> dimitern, I don't think it ever does any harm to announce it here
<dimitern> cool :) so here it is: https://codereview.appspot.com/6843106
<TheMue> fwereade_: Ooops, indeed. *facepalm*
<TheMue> fwereade_: Btw, review, I've hardened code and tests after your last review for the first CL and now doing the same for the second one.
<TheMue> dimitern: I'll take a look.
<fwereade_> TheMue, cool, I'll take a look now
<dimitern> TheMue: 10x
<TheMue> dimitern: You've got a review.
<dimitern> TheMue: thank you!
<TheMue> dimitern: YW.
 * niemeyer => lunch
<dimitern> TheMue: the EC2 docs describing metadata is the only reference document, also implemented in openstack, the first one is a mistake (forgot to change the comment) - will fix it
<TheMue> dimitern: Ah, IC. Something learned. ;) Thanks.
<fwereade_> TheMue, https://codereview.appspot.com/6852065/ reviewed
<TheMue> fwereade_: Thanks.
<TheMue> fwereade_: Good ones, will change it.
<fwereade_> TheMue, cheers :)
<dimitern> fwereade_: it seems url.Parse is too lenient - "some url" is valid for it and it parses it as Path="some url", other fields empty
<fwereade_> dimitern, ha!
<fwereade_> dimitern, I guess you could check for presence of other fields
<fwereade_> dimitern, but I'm not too worried about it tbh
<dimitern> fwereade_: ok, I'll dig in a bit more
<rogpeppe> back
<dimitern> rogpeppe: heya, can you please recheck my CL: https://codereview.appspot.com/6858052/
<rogpeppe> dimitern: i'm on it
<rogpeppe> dimitern: LGTM
<rogpeppe> dimitern: get it submitted!
<dimitern> rogpeppe: thanks! so now I can submit it
<dimitern> yeah
<dimitern> rogpeppe: and the other related one: https://codereview.appspot.com/6843106/
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: thanks!
<dimitern> rogpeppe: about whether it's too early - well, there are the tests, and we might forget about it much later - when we get to deploying stuff, that's why
<rogpeppe> dimitern: you won't forget about it - your code will panic on the server side and it'll be obvious.
<rogpeppe> dimitern: what might be less obvious is if the code is subtly broken for some reason and it doesn't work live - then you'll not be entirely sure which bit of the system is broken.
<rogpeppe> dimitern: that's why i prefer to see code go in that can be tested for real (obviously it's not always possible, but in this case i think it might be worth it)
<dimitern> rogpeppe: so you suggest to shelve it for now, but when will it be appropriate to land it?
<rogpeppe> dimitern: when you've got a working bootstrap (i.e. something will actually call PrivateAddress or PublicAddress for real on the server side)
<rogpeppe> dimitern: until then, it's fine to leave as a stub, i think
<rogpeppe> dimitern: but if others think it should go in, i'm happy with that too.
<dimitern> rogpeppe: I see, ok then I'll just fix the comments for now
<TheMue> fwereade_: You've got a very critical eye (Do you say so?) - and that's very good. ;) I hope https://codereview.appspot.com/6852065/ now gets approved.
<fwereade_> TheMue, it's one of those useful phrases that can be positive or negative :) I will take in the spirit in which it is intended ;)
<TheMue> fwereade_: You, absolute positive meant. Is there a better phrase for it?
<TheMue> Argh, my fingers again!
<TheMue> s/You/Yes/
<fwereade_> TheMue, hmm, I can't think of any way of expressing that quality that doesn't critically depend on the tone of voice ;)
<TheMue> fwereade_: Maybe I have to use diacritical chars next time. :D
<fwereade_> TheMue, LGTM :)
<TheMue> fwereade_: *hug*
<fwereade_> TheMue, I don't seem to be able to officially Approve it, but you have your 2 :)
<TheMue> fwereade_: Ah, and instead of diacritics I meant phonetics.
<fwereade_> TheMue, ah, yes, true, my pedantry isn't quite as advanced as that :)
<TheMue> rogpeppe: Hmm, still the stderr. So far the lxc commands return error codes I return too as Go errors.
<rogpeppe> TheMue: don't they print anything when something goes wrong?
<rogpeppe> TheMue: for example, if i run lxc-start not as root, it prints "lxc-start: Not running with sufficient privilege"
<rogpeppe> TheMue: but your code will return the error "exit code 255"
<rogpeppe> TheMue: guess which one would be easier to debug? :-)
<TheMue> rogpeppe: The 255. *lol*
<TheMue> rogpeppe: OK, gotcha, will change it.
<rogpeppe> TheMue: you might want to experiment with the lxc commands to see how to make the output into nicer Go errors. for example, you probably want to strip off the "lxc-[^:]*: " prefix.
<TheMue> rogpeppe: Good idea, thx.
<TheMue> rogpeppe: Any idea on how to skip a whole suite, not just one test?
<rogpeppe> TheMue: call Skip inside SetUpSuite, i believe
<TheMue> rogpeppe: Yes, just found it in the docs.
<TheMue> rogpeppe: Thx.
 * niemeyer respawns
<TheMue> rogpeppe: Works.
<niemeyer> rogpeppe: This is up for review, despite the fact it has been submitted already: https://codereview.appspot.com/6846066/
<niemeyer> rogpeppe: What's its actual status?
<rogpeppe> niemeyer: now back to Merged status
<niemeyer> rogpeppe: Cheers
<dimitern> niemeyer: I'd like your view on this as well please: https://codereview.appspot.com/6843106/
<niemeyer> dimitern: Sounds good, just let me clean the queue for roger and will back to you
<dimitern> niemeyer: sure, no rush
<niemeyer> rogpeppe: Review sent
<rogpeppe> niemeyer: thanks
<dimitern> niemeyer: ping
<niemeyer> dimitern: Pongus
<dimitern> niemeyer: sorry :) ^^
<niemeyer> dimitern: I'm on it
<dimitern> niemeyer: thanks
<niemeyer> dimitern: Done!
<dimitern> niemeyer: cool, 10x
<dimitern> niemeyer: how about rogpeppe's comment, i think he could right that it's too soon to land this
<fwereade_> ok, I've got to dash
<niemeyer> fwereade_: Have a good.. hmm.. dashing? :)
<dimitern> fwereade_: see ya :)
<fwereade_> niemeyer, I'm on holiday tomorrow but I will pop on for a brief discussion of the machine thing
<niemeyer> dimitern: I thought you actually added the tests in the branch itself?
<fwereade_> niemeyer, I think I will know in my own heart whether it's worth it sometime later, but I'll need to run it by you too :)
<fwereade_> dimitern, I just remebered we're having an early dinner with someone, might ping you later and see if you're up for a drink
<niemeyer> fwereade_: Sounds good.. we should have a voice call, just to sync up
<dimitern> niemeyer: yeah, the tests with a locally served canned metadata work the same
<dimitern> fwereade_: sgtm
<fwereade_> niemeyer, sgtm, I'll grab yu when I can
<fwereade_> gn all
<niemeyer> fwereade_: Night!
<niemeyer> dimitern: Yeah, I think it's fine.. rogpeppe?
<rogpeppe> niemeyer: i kinda think it's a bit early but i don't mind much. it's going to be long time until this code is actually tested for real.
<dimitern> rogpeppe: not too long i hope :) we're picking up speed
<rogpeppe> dimitern: ok :-)
<rogpeppe> dimitern: but seriously, you'll have done almost all the provider by the time this gets used
<niemeyer> rogpeppe: Early for what?
<dimitern> rogpeppe: well, basically all the code is there, but it's being refactored at the moment
<niemeyer> rogpeppe: It's necessary code, with some testing alongside
<rogpeppe> niemeyer: ok, fair enough
<rogpeppe> dimitern: i see. in that case, LGTM
<dimitern> rogpeppe: cool, 10x, i'm submitting it then
<niemeyer> dimitern: ping
<dimitern> niemeyer: pong
<niemeyer> dimitern: I noticed that the suggested change wasn't done there
<dimitern> niemeyer: which one?
<niemeyer> dimitern: The one that was part of the review
<dimitern> niemeyer: oops, sorry, how to revert it?
<niemeyer> dimitern: Don't have to revert it.. just propose a new CL that does the trivial
<dimitern> niemeyer: I see, ok i'm on it
<niemeyer> dimitern: Thanks
<niemeyer> dimitern: The change is actually not *that* important.. I'm mainly worried about getting used to the workflow
<niemeyer> dimitern: So I think it's worth fixing
<dimitern> niemeyer: sure, I think is very useful
<dimitern> mapping the process :)
<niemeyer> dimitern: Yeah :)
<dimitern> niemeyer: it seems it worked: https://codereview.appspot.com/6843106/
<TheMue> So, have to step out. Second CL will be updated tomorrow. Have a nice evening.
<niemeyer> dimitern: Oops
<niemeyer> dimitern: It kind of worked
<niemeyer> dimitern: It should be a different banch
<niemeyer> branch
<niemeyer> dimitern: This one was submitted already
<dimitern> niemeyer: I see
<dimitern> niemeyer: so it won't work like this
<niemeyer> dimitern: Nope
<dimitern> niemeyer: I'll branch it and repost
<niemeyer> dimitern: It's just a matter of changing the branch name, though
<dimitern> niemeyer: with cobzr: bzr branch . new-name ?
<dimitern> or checkout -b and push
<niemeyer> dimitern: bzr branch -m old-name new-name
<niemeyer> dimitern: Assuming cobzr
<dimitern> niemeyer: yep, it worked: https://codereview.appspot.com/6782102
<niemeyer> dimitern: Almost there
<niemeyer> dimitern: ("cannot get %q: %v", uri, err)
<dimitern> niemeyer: ok
<dimitern> niemeyer: done
<niemeyer> dimitern: LGTM with the fix
<dimitern> niemeyer: thanks, should I submit it?
<niemeyer> dimitern: Yes, please
<niemeyer> dimitern: This is a follow up on the previous, and trivial as well
<dimitern> niemeyer: ok
<niemeyer> dimitern: Thanks!
<dimitern> niemeyer: thank you! i had a proper kick-start today with the workflow :)
<niemeyer> dimitern: Indeed, and well done :)
<dimitern> niemeyer: i'm off for today then, thanks again, and good night!
<niemeyer> dimitern: Thanks, you too!
<rogpeppe> niemeyer: if you're still around, i think this should be better now. the file reading behaviour took a bit more thought than i expected. https://codereview.appspot.com/6850087
<niemeyer> rogpeppe: Checking out
<niemeyer> rogpeppe: Documentation still feels pretty hard to grasp
<rogpeppe> niemeyer: darn
<rogpeppe> niemeyer: i thought it was better now
<niemeyer> rogpeppe: Do you have any automated realignment tool, btw?
<niemeyer> rogpeppe: I've noticed the out of shape comments with some frequency
<niemeyer> rogpeppe: Let me try to have a go at the docs
<rogpeppe> niemeyer: the documentation for config.New or for the internal maybeReadFile function?
<niemeyer> rogpeppe: The internal one
<rogpeppe> niemeyer: yeah, i do. i just don't use it as much as i should
<niemeyer> rogpeppe: Semantic also seem to have changed in the new version
<rogpeppe> niemeyer: the semantics of maybeReadFile have changed, yes. that's because they didn't match the documented behaviour of config.New.
<rogpeppe> niemeyer: (i realised that as i looked into it)
<rogpeppe> niemeyer: actually, that reminds me - there are some tests i've forgotten to add.
<rogpeppe> (testing what happens when both ca-cert and ca-cert-path are both set
<rogpeppe> )
<niemeyer> rogpeppe: Disabling the default behavior via setting things to empty strings is unlike anything else we have so far, I believe
<niemeyer> rogpeppe: and I do recall fwereade being explicitly interested on that behavior
<rogpeppe> niemeyer: i think it's important that we be able to specify a certificate only without having the private key read from a file
<niemeyer> rogpeppe: Why?
<niemeyer> rogpeppe: This is part of the configuration.. if you don't like the file, take it off
<niemeyer> rogpeppe: That kind of fine tunning via vague rules is pretty unfriendly to actual users
<rogpeppe> niemeyer: you might not have control of the name space. that's true of our tests for example
<niemeyer> rogpeppe: Not to mention that it's really hard to grasp what that documentation is saying
<niemeyer> rogpeppe: If this, but that, and not that other thing
<niemeyer> rogpeppe: I don't understand..
<niemeyer> rogpeppe: We have entire control of everything we do
<niemeyer> rogpeppe: It's our code base, our disk, our data, our configuration
<rogpeppe> niemeyer: we don't necessarily want to set up a fake home for every single test
<niemeyer> rogpeppe: Yes, let's not do that.. (?)
<rogpeppe> niemeyer: and a configuration is perfectly valid (and potentially more common) without the private key in the config
<rogpeppe> niemeyer: if we don't allow this kind of behaviour, we're saying that there is no way to force the config to create a configuration with no private key without it hitting the disk
<niemeyer> rogpeppe: No, what I am saying is that it feels bad to reuse behavior that in every other case works in a *different* way
<rogpeppe> niemeyer: for example, i want to allow people to create an app that manages its own CA keys without storing them on disk
<rogpeppe> niemeyer: ok. we could potentially allow a special value for an unspecified key or cert, such as "none".
<niemeyer> rogpeppe: Coincidently, yaml has such a null value
<rogpeppe> niemeyer: what do you think CACertPEM should return if there's no certificate specified?
<rogpeppe> niemeyer: should we make it return a []byte rather than a string, perhaps?
<niemeyer> rogpeppe: We can make it return ""?
<rogpeppe> niemeyer: so CACertPEM returns "", but the attributes don't contain "" ?
<niemeyer> rogpeppe: The attributes contain "", but CACertPEM doesn't return ""?
<rogpeppe> niemeyer: i think i'd expect CACertPEM to return the same as attrs["ca-cert"]
<niemeyer> rogpeppe: I'm not sure I understand the point you're making
<niemeyer> rogpeppe: So you don't want to read it from disk?
<rogpeppe> niemeyer: yup. i want to be able to create a config with, for instance, no cert and no key, and have it work independently of what the disk contents are
<niemeyer> rogpeppe: What I mean is that the logic you're suggesting already doesn't make attrs["ca-cert" and CACertPEM be the same thing
<rogpeppe> niemeyer: i also want configs to round-trip correctly in all circumstances
<niemeyer> rogpeppe: And it also changes the behavior of what defaults do
<niemeyer> rogpeppe: i'm finding it surprisingly difficult to get something that looks straightforward going
<niemeyer> rogpeppe: We need something to get started
<niemeyer> rogpeppe: Something that looks like what we already do
<rogpeppe> niemeyer: i'm not sure my "special value" suggestion is any good
<niemeyer> rogpeppe: Something that is understandable, well documented, etc
<niemeyer> rogpeppe: Let's not do special value.. let's implement exactly the same thing we do with ssh..
<niemeyer> rogpeppe: Just not enforcing its presence
<rogpeppe> niemeyer: question: if i do config.New(otherConfig.AllAttrs()), should i always end up with the same thing i started with?
<niemeyer> rogpeppe: Yes
<rogpeppe> niemeyer: how do you plan to enable that?
<niemeyer> rogpeppe: How do we do that today?
<rogpeppe> niemeyer: we always require authorized-keys
<rogpeppe> niemeyer: and that's the only current field we have that potential problem with
<niemeyer> rogpeppe: Okay, and how's that a problem in the new world?
<rogpeppe> niemeyer: if we create a config with no certificate, that's a valid certificate, but (assuming we don't allow the ""-means-unspecified behaviour), AllAttrs cannot return a value for the ca-cert attribute.
<niemeyer> rogpeppe: There's a very good way to say that a key is not present in the configuration.. and that's to have the key not present in the configuration (!)
<rogpeppe> niemeyer: if the key isn't present in the configuration, then we hit the disk
<rogpeppe> niemeyer: which means that config.New(otherConfig.AllAttrs()) might *not* return the same configuration
<niemeyer> rogpeppe: Okay
<niemeyer> rogpeppe: So what's the problem with nulling it out?
<rogpeppe> niemeyer: having an explicit null value in the map?
<niemeyer> rogpeppe: Yes
<rogpeppe> niemeyer: we could do that. but clients will just compare the return value of CACertPEM against "" anyway, so it doesn't seem worth it.
<niemeyer> rogpeppe: This actually sounds bogus
<niemeyer> rogpeppe: We've been pretty good at not allowing invalid values to be handled as valid ones
<rogpeppe> niemeyer: i dunno. we guarantee that CACertPEM contains a valid certificate
<niemeyer> rogpeppe: If CACertPEM can return an invalid certificate, we should return a pair
<niemeyer> (cert, ok)
<niemeyer> rogpeppe: Do we? Where?
<rogpeppe> niemeyer: (if it's present, i mean)
<niemeyer> rogpeppe: "" is not a valid certificate
<niemeyer> rogpeppe: We allow that
<rogpeppe> niemeyer: indeed. it seems a reasonable way to say "no certificate" to me
<niemeyer> rogpeppe: It's also a reasonable way to saying "default", as far as our configuration goes
<niemeyer> rogpeppe: It's poor engineering to have both side-by-side
<rogpeppe> niemeyer: do we use "" to mean default anywhere?
<niemeyer> rogpeppe: Read that function again please
<rogpeppe> niemeyer: which function?
<niemeyer> rogpeppe: The one you're suggesting changes to
<rogpeppe> niemeyer: what about it?
<niemeyer>         if c.m["default-series"].(string) == "" {
<niemeyer>                 c.m["default-series"] = version.Current.Series
<niemeyer>         }
<niemeyer>         if path != "" || keys == "" {
<niemeyer>                 c.m["authorized-keys"], err = authorizedKeys(path)
<niemeyer>         switch firewallMode {
<niemeyer>         case FwDefault,
<niemeyer>         FwDefault FirewallMode = ""
<rogpeppe> oh yeah
<rogpeppe> :-)
<niemeyer> rogpeppe: :-(
<niemeyer> <rogpeppe> niemeyer: do we use "" to mean default anywhere?
<niemeyer> YEEEES
<rogpeppe> gotcha
<rogpeppe> niemeyer: ok, so... how about we make CACertPEM return []byte, and nil when not set.
<rogpeppe> niemeyer: and have an entry in the map, nil when explicitly not set.
<niemeyer> rogpeppe: No, (cert string/[]byte, ok bool), please
<niemeyer> rogpeppe: nil in the map sounds fine
<rogpeppe> niemeyer: i'm slightly concerned that it won't be obvious what type of thing is expected in the map (which is part of our public interface, after all)
<niemeyer> rogpeppe: That's why we have an interface on that type
<rogpeppe> niemeyer: there are quite a few tests that do a DeepEqual on the attributes returned from AllAttrs
<niemeyer> rogpeppe: It doesn't have to be obvious.. people shouldn't be poking on the map
<rogpeppe> niemeyer: maybe they're bogus
<niemeyer> rogpeppe: Because that's our tests implementing it
<niemeyer> rogpeppe: The tests are fine
<niemeyer> rogpeppe: We're verifying that our logic is sane
<rogpeppe> niemeyer: i'm talking about tests in state
<niemeyer> rogpeppe: Me too
<rogpeppe> niemeyer: ok
<niemeyer> rogpeppe: I'd like to move forward.. that sounds like a pretty reasonable way to move forward
<rogpeppe> niemeyer: what would the YAML-marshalled representation look like?
<niemeyer> rogpeppe: ?
<niemeyer> rogpeppe: I don't understand the question.. the YAML-marshalled representation will look like YAML
<rogpeppe> niemeyer: of a ca-cert that's explicitly not present
<rogpeppe> niemeyer: presumably yaml has null or something like it
<niemeyer> rogpeppe: Yes, and it's called null :-)
<rogpeppe> niemeyer: great
<rogpeppe> niemeyer: ok, i'll see how it goes
<niemeyer> rogpeppe: Thanks.. I think the defaults should be "", btw, because we'll be checking for that
<niemeyer> rogpeppe: (rather than omit)
<niemeyer> rogpeppe: Makes both the logic and the consistency better, I believe
<rogpeppe> niemeyer: and we have the type as OneOf(String, nil)
<rogpeppe> niemeyer: ?
<niemeyer> rogpeppe: Right
<niemeyer> rogpeppe: I think we'd need that anyway, or it'll barf on the nil
<niemeyer> rogpeppe: (not there != nil)
<rogpeppe> niemeyer: this all seems fine. sorry it's taken a while to discuss, but it is surprisingly subtle...
<niemeyer> rogpeppe: I can see it is indeed
<niemeyer> rogpeppe: Glad we found an alternative
 * rogpeppe dives once more into the breach
<niemeyer> :)
<niemeyer> I'll step out to get some food meanwhile
<rogpeppe> niemeyer: darn, there's no schema.Null
<rogpeppe> niemeyer: i'll make one
<rogpeppe> niemeyer: enjoy!
<niemeyer> rogpeppe: Const(nil)
<rogpeppe> niemeyer: argh! of course.
<rogpeppe> niemeyer: done, i hope: https://codereview.appspot.com/6850087/
#juju-dev 2012-11-23
<rogpeppe> fwereade_: morning!
<TheMue> Morning
<rogpeppe> TheMue: hiyta
<rogpeppe> hiya
<TheMue> rogpeppe: I'm now returning a more detailed error containing the stderr output.
<rogpeppe> TheMue: cool
<TheMue> rogpeppe: Could you take a look again?
<rogpeppe> TheMue: yeah, in a little bit
<TheMue> rogpeppe: Thx.
 * rogpeppe loves it when he starts implementing something, then realises it's unexpectedly done already, as a natural consequence of earlier changes.
<rogpeppe> davecheney, dimitern: hiya
<davecheney> rehowdy
<dimitern> rogpeppe: hey
<TheMue> davecheney, dimitern: Morning.
<TheMue> rogpeppe: Any chance to take a look?
<rogpeppe> TheMue: sorry, i'm on a roll this morning - i don't want to derail for the moment, sorry
<TheMue> rogpeppe: OK
<rogpeppe> TheMue: i'll take a look after i've dealt with this branch
<TheMue> rogpeppe: Would be great, thank you.
<dimitern> TheMue: morning
<rogpeppe> TheMue: you've got a review
<TheMue> rogpeppe: Thx
<dimitern> wallyworld: mgz and me are on mumble
<TheMue> rogpeppe: Read it and the first two points are relative simple, ok. But the multi-line stderr is indeed a problem. I don't know if it should be part of the one-liner error string. For those who wnat to use it it's in the error as a field.
<rogpeppe> TheMue: i know. there's no easy answer i'm afraid, but i'm not sure it's right as is.
<rogpeppe> TheMue: (and i've seen lxc print multi-line error messages, so i know it definitely is an issue)
<TheMue> rogpeppe: My problem also is, that the scope of that CL moved. The intention has been to add "first tests" to extend it later. ;)
<rogpeppe> TheMue: i think the error handling is rightly part of the first tests
<rogpeppe> fwereade_: ping
<TheMue> rogpeppe: Aaargh, found an interesting behavior. The error message of lxc is written to stdout, not stderr. Will change the code according, os/exec supports it.
<rogpeppe> TheMue: ha.
<rogpeppe> TheMue:  it depends on the command maybe
<rogpeppe> TheMue: the command i tried printed it to stderr
<rogpeppe> TheMue: which command did you try?
<TheMue> rogpeppe: Yes, maybe. Strange. But I should get it with the combined output.
<TheMue> rogpeppe: I took lxc-create
<rogpeppe> TheMue: the problem is that some commands might print an error *and* some expected standard output
<rogpeppe> TheMue: lxc-start prints to stderr...
<rogpeppe> TheMue: yuck
<rogpeppe> TheMue: and lxc-create doesn't prefix its error lines either
<TheMue> rogpeppe: I'll find my way. So far I already test most stuff before I even start a command and I'll add a root check too. ;)
<TheMue> rogpeppe: Yes, that's what Aram said, it's inconsistent.
<rogpeppe> TheMue: yeah, it's badly done
<rogpeppe> TheMue: perhaps we should file a bug report
<TheMue> rogpeppe: I'll make a note, yes.
<rogpeppe> TheMue: i think there might be a pattern. i suspect that the lxc commands that are shell scripts print errors to stdout; the ones that aren't print errors to stderr
<rogpeppe> TheMue: and their errors are totally inconsistent too. check out this one:
<rogpeppe> 	echo "E: lxc-info - no such file" >&2
<TheMue> rogpeppe: I just take all output for debugging, additionally to the returned ExecError of exec.Command
<rogpeppe> TheMue: yeah, i don't think there's much else you can do actually
<rogpeppe> TheMue: even some of the commands that are expected to produce stuff to stdout still print their errors to stdout.
<rogpeppe> TheMue: what a friggin' mess. i don't think people know how to use shell scripts any more.
<TheMue> rogpeppe: Hehe, yep.
<rogpeppe> TheMue: https://sourceforge.net/tracker/?func=detail&aid=3589389&group_id=163076&atid=826303
<TheMue> rogpeppe: Great
<TheMue> rogpeppe: Thx, I would have done it later. ;)
<rogpeppe> TheMue: it annoyed me enough that i wanted to do it there and then :-)
<TheMue> rogpeppe: You're using it @home?
<rogpeppe> TheMue: no, just the principle of it :-)
<TheMue> rogpeppe: Hehe :D
<TheMue> lunchtime, brb
<rogpeppe> niemeyer: yo!
<rogpeppe> niemeyer: i'm just passing the ca-cert to jujud, and i'm not quite sure of the best way to do it. i could use a flag or a file.
<niemeyer> rogpeppe: Heya
<rogpeppe> niemeyer: i've just done it as a flag, but i'm not sure that's right.
<niemeyer> rogpeppe: I'm not quite sure either.. it should be a file
<niemeyer> rogpeppe: But we could pass as a flag, or hardcode the path
<rogpeppe> niemeyer: currently my best thought is to hard-code the path (inside datadir)
<rogpeppe> niemeyer: the flag is awkward because i'm not sure how the upstart config copes with multi-line strings
<rogpeppe> niemeyer: ah, you mean pass the filename as a flag
<rogpeppe> niemeyer: that could be better actually (and marginally easier to test, possibly)
<rogpeppe> niemeyer: i think i'll go with that for the time being.
<niemeyer> rogpeppe: Sounds good
<rogpeppe> niemeyer: this branch might finally be ok now, i'm hoping: https://codereview.appspot.com/6850087/
<rogpeppe> niemeyer: and i'm hoping this one too: https://codereview.appspot.com/6855054/
<niemeyer> rogpeppe: Cool, I'll be there son
<niemeyer> soon
<rogpeppe> niemeyer: "son" works too, in a slightly patronising kinda way :-)
<TheMue> rogpeppe: So, changes are in.
<rogpeppe> TheMue: ok
<rogpeppe> TheMue: reviewed
<TheMue> rogpeppe: Great, thank you.
<niemeyer> rogpeppe: Closer, review sent
<rogpeppe> niemeyer: quick crack test: is what i'm doing in TestPackage here ok, or crackful? the alternative is to add something in every SetUpSuite. https://codereview.appspot.com/6842088/diff/1/cmd/jujud/main_test.go
<rogpeppe> niemeyer: thanks
<rogpeppe> "What if the path is != "" and m[attr] is nil, shouldn't it stay nil?"
<rogpeppe> niemeyer: i don't *think* so
<rogpeppe> niemeyer: i deliberately chose that behaviour
<rogpeppe> niemeyer: to follow the documentation
<rogpeppe> niemeyer: in particular "The ...-path key is translated into "..." by loading the content from the respective file"
<rogpeppe> niemeyer: i thought that meant that it's best to honour the path value if it's set
<rogpeppe> niemeyer: note that providing a nil value still prevents it from "reading the standard paths"
<niemeyer> rogpeppe: I'm not sure I see what you're trying to achieve
<niemeyer> rogpeppe: I thought you had suggested yesterday that it shouldn't change if it's nil?
<rogpeppe> niemeyer: i'm trying to come up with something that's not too surprising to someone that reads the docs on New()
<rogpeppe> niemeyer: path always overrides value
<rogpeppe> niemeyer: (currently)
<rogpeppe> niemeyer: if you've explicitly specified a path, i think it would be surprising if it was ignored
<niemeyer> rogpeppe: Okay
<niemeyer> I'll get a quick lunch
<mgz> dimitern: can I bother you for a review of the swift fixup stuff?
 * rogpeppe should probably get lunch too
<rogpeppe> niemeyer: PTAL  https://codereview.appspot.com/6850087
<rogpeppe> dimitern: i'm seeing an openstack test failure in trunk
<rogpeppe> dimitern: http://paste.ubuntu.com/1379598/
 * dimitern looks
<dimitern> rogpeppe: hmm.. strange, why didn't it fail before when I run the test..
<rogpeppe> dimitern: i know not
<dimitern> rogpeppe: it's a trivial fix, I'm on it
<rogpeppe> dimitern: it might be possible that you're relying on map-traversal order
<rogpeppe> dimitern: (which is random)
<dimitern> rogpeppe: maybe, anyway it was the last change
<mgz> reminds me, I should actually get the juju-core suite passing here
<mgz> it was unhappy last time I ran it
<rogpeppe> mgz: when you have a test failure, pastebin it, and i'll let you know if it's a common one or not
<rogpeppe> mgz: there are still a few sporadic test failures
<rogpeppe> mgz: mostly to do with unreliability of external components, i think
<dimitern> rogpeppe: strange, I cannot see the openstack provider code at all in trunk
<rogpeppe> dimitern: that's odd
<dimitern> rogpeppe: it should be there, right? it was yesterday
<rogpeppe> dimitern: i see it
<rogpeppe> dimitern: what do the last few entries of the revision log look like?
<mgz> rogpeppe: well, problem #0 is what command to use to run the tests, and problem #1 is what I think I should use runs some, but then has:
<mgz> go build launchpad.net/juju-core/cmd/juju: signal 9
<mgz> FAIL    launchpad.net/juju-core/cmd/juju [build failed]
<mgz> which seems non-passy
<dimitern> rogpeppe: well, mostly yours - up to rev 734
<rogpeppe> mgz: to run all the tests, go to the juju-core root dir, and type "go test ./..."
<mgz> okay, so that is the convention. any ideas on the build fail?
<dimitern> rogpeppe: and doing either bzr up or bzr pull does not get me anything new
<rogpeppe> dimitern: trunk is up to revision 737
<rogpeppe> dimitern: what does bzr info print?
<mgz> dimitern: are you in the right branch, and what's the parent?... what rogpeppe said
 * rogpeppe really goes for some lunch now
<dimitern> mgz: I'm at the master branch (as cobzr names trunk)
<dimitern> dimitern@kubrik:~/work/juju-core$ bzr up
<dimitern> Tree is up to date at revision 734 of branch /home/dimitern/work/go/src/launchpad.net/juju-core/.bzr/cobzr/master
<dimitern> dimitern@kubrik:~/work/juju-core$ bzr pull
<dimitern> Using saved parent location: /home/dimitern/work/go/src/launchpad.net/juju-core/
<dimitern> No revisions or tags to pull.
<mgz> okay, so that's the problem
<dimitern> mgz: what?
<mgz> the parent branch is a local mirror, not lp:juju
<mgz> *lp:juju-core
<dimitern> mgz: I see, so how to change that?
<mgz> use `bzr pull --remember lp:juju-core`
<dimitern> mgz: nice, 10x
<dimitern> mgz, rogpeppe: PTAL https://codereview.appspot.com/6843109
<mgz> dimitern: I still get failures on those tests, but from a different issue
<dimitern> mgz: can I see the paste?
<dimitern> I don't get any errors, and I run the tests like 30 times in a row
<mgz> it's likely because this box is set up differently to yours, and the tests are not well isolated from home
<mgz> so, specifically there are no keys in ~/.ssh
<dimitern> mgz: so it's just happening on yours
<mgz> and your test stuff doesn't pass authorized-keys or similar
<dimitern> no, it's not at all to do with ssh
<mgz> the failures I'm seeing :)
<dimitern> mgz: got you :) so not in the OS provider tests
<mgz> yes, those tests, but different failures from the one you're fixing
<niemeyer> rogpeppe: LGTM
<rogpeppe> niemeyer: YAY!
<dimitern> mgz: can I still see the paste?
<mgz> when pastebin starts responding...
<mgz> http://pastebin.ubuntu.com/1379685/
<dimitern> :)
<dimitern> mgz: I see, but that's from environs/config or something beneath
<hazmat> rogpeppe, re the cert work, how does the client know the endpoint / cert fingerprint is valid for the endpoint?
<rogpeppe> hazmat: the client has a CA public cert
<mgz> full run with some failures from outside the openstack dir:
<mgz> http://pastebin.ubuntu.com/1379695/
<rogpeppe> hazmat: i'm not sure how that works from a web-browser perspective
<mgz> guess I'll fix up some of these
<dimitern> mgz: so put an ssh pubkey then :)
<hazmat> rogpeppe, k, but where is the private cert for the CA?
<mgz> dimitern: if the test is loading stuff from your homedir to work, it's not a very good test
<mgz> tests should pass on a clean box, not just are carefully set up development environment
<dimitern> mgz: i agree, sure, so which test is actually the root cause?
<rogpeppe> mgz: until recently there have been a few tests like that. i've fixed them, hopefully in some of my latest branches
<mgz> rogpeppe: any that still need reviewing/landing?
<mgz> if so, point me at 'em
<rogpeppe> mgz: yeah, quite a few
<dimitern> rogpeppe: take a look please: https://codereview.appspot.com/6843109 - since it's trivial one LGTM should suffice, right?
<rogpeppe> mgz: look at the juju-core active reviews
<mgz> dimitern: it's a general bad assumption
<mgz> rogpeppe: will do
<rogpeppe> dimitern: will do, in a little while
<dimitern> rogpeppe: thanks
<hazmat> rogpeppe, for the web we'll need to have a webserver with the same cert serve up the html so the browser user can ack it, the websocket is considered a subresource, and won't get loaded if the cert isn't already known to the browser.
<mgz> rogpeppe: are there any fixes for these tests that aren't nacked by niemeyer?
<niemeyer> brb
<mgz> for what it's worth, bzr has a few different test classes, any test that's going to touch disk is given an isolated home directory to work in
<mgz> and lp:~rogpeppe/juju-core/141-test-HOME-independence fixes failures.
<rogpeppe> mgz: we've moved away from that branch. i've been fixing on a see-it-and-fix-it basis.
<rogpeppe> mgz: tbh i'm juggling too many subtly interrelated branches at the moment - i can't remember what goes where!
<rogpeppe> it'd be good to have a go-ahead for this trivial: https://codereview.appspot.com/6847091/
<rogpeppe> mgz: ^
<rogpeppe> mgz: and this followup: https://codereview.appspot.com/6782103
<rogpeppe> dimitern: LGTRM
<rogpeppe> LGTM
<rogpeppe> dimitern: one LGTM is fine for that
<dimitern> rogpeppe: cool, 10x
<rogpeppe> dimitern: if you submit now, i've got two branches that i need to submit in quick succession
<rogpeppe> pwd
<dimitern> rogpeppe: just submitted
<rogpeppe> dimitern: thanks
<rogpeppe> TheMue, fwereade_, dimitern: please don't submit anything for a minute or so
<TheMue>  rogpeppe Ey, ey
<dimitern> how does submitting interfere, i'm curious when you're done
 * TheMue leaves now, has a whisky tasting in 50 minutes
<rogpeppe> TheMue: enjoy!
<TheMue> I wish you all a wonderful weekend and thanks for the helpful feedback.
<TheMue> rogpeppe: I'll do. SlÃ inte!
<rogpeppe> TheMue: np. thanks for going along!
<rogpeppe> dimitern: done now.
<rogpeppe> dimitern: submitting pulls down a copy of the branch you're submitting against, merges against that, then pushes
<rogpeppe> dimitern: so if someone submits in the meantime, you may get a "branches diverged" error
<dimitern> rogpeppe: I see, good to know
<rogpeppe> dimitern: and in this case, one of the branches was breaking trunk, so i didn't want to get into that state
<rogpeppe> mgz: i'm just putting together a branch that fixes the various HOME-dependencies
<mgz> rogpeppe: ace, will look at those other movey branches too
<rogpeppe> niemeyer: oh dear, it look like Settings.Write doesn't work properly in the face of nil keys. i only discovered when running the tests having done "chmod 0 ~/.ssh ~/.juju"
<niemeyer> rogpeppe: Hmm
<rogpeppe> niemeyer: am currently working on a fix
<niemeyer> rogpeppe: What's the deal there?
<rogpeppe> niemeyer: the nil keys are disappearing
<rogpeppe> niemeyer: sorry, the nil values
<rogpeppe> niemeyer: it looks ok at a glance, but that's not what i'm seeing
<niemeyer> rogpeppe: Hmm
<rogpeppe> niemeyer: yeah, this test fails: http://paste.ubuntu.com/1379890/
<niemeyer> rogpeppe: I think that's what we represent as lack of value
<rogpeppe> niemeyer: maybe i should back out my submits
<rogpeppe> niemeyer: again :-(
<niemeyer> rogpeppe: What about using your prior idea of changing the behavior of ""
<rogpeppe> aargh
<niemeyer> rogpeppe: Would that work?
<niemeyer> rogpeppe: arghÂ²
<rogpeppe> niemeyer: i believe it would :-)
<niemeyer> rogpeppe: I still don't think it's great, but we can't spend weeks on how to load a value from disk
<rogpeppe> niemeyer: i know
<rogpeppe> niemeyer: we could change the behaviour of "" throughout - it's really just an implementation convenience
<niemeyer> rogpeppe: No, let's please not cascade this further
<niemeyer> rogpeppe: Otherwise Monday we'll be talking about this again
<rogpeppe> niemeyer: yup
<rogpeppe> niemeyer: i thought i might get tls actually working today too
<rogpeppe> niemeyer: (i've got a branch that almost does)
<niemeyer> rogpeppe: Let's keep the current branch mostly unchanged, and try to just adapt the logic so it works with ""
<rogpeppe> niemeyer: ok
<rogpeppe> niemeyer: could you draft the doc comment for New while i fix the code?
<niemeyer> rogpeppe: I'm on it
<rogpeppe> niemeyer: thanks
<mgz> hm, is lgtm actually used as a magic string for anything?
<rogpeppe> mgz: i don't believe we do that (the go core does, i think)
<rogpeppe> pwd
<mgz> ~
<mgz> rogpeppe: reviewed those movey branches
<rogpeppe> mgz: thank you
<mgz> the second one I trust you on the design of, I'd probably have made a cert object that had create and parse constructors and accessors for cert/private key, and made the code create one how they wanted before passing to bootstrap
<niemeyer> rogpeppe: I think the easiest for the moment is to just remove the second to last paragraph
<niemeyer> rogpeppe: It turns out that everything else is still true
<rogpeppe> niemeyer: ok. will have a look when i've got these pesky tests passing again
<niemeyer> rogpeppe: We could try to explain, but it feels like it'll make it harder to read and understand than otherwise
<rogpeppe> niemeyer: that sounds reasonable
<niemeyer> fwereade_: I know you're on holiday, but you demonstrated interest in talking yesterday. In case you need me, I'm around, but no rush.. we can talk on Monday too
<rogpeppe> niemeyer: https://codereview.appspot.com/6854088
<niemeyer> rogpeppe: Looking
<niemeyer> rogpeppe: Uh, what happened to the rest?
<rogpeppe> niemeyer: the rest?
<niemeyer> rogpeppe: I mean, the branch that was already in review?
<rogpeppe> niemeyer: it got submitted
<rogpeppe> niemeyer: before i realised the problem
<niemeyer> rogpeppe: Oh?
<niemeyer> rogpeppe: Ouch
<niemeyer> rogpeppe: Okay, hopefully that'll fix it.. looking
<rogpeppe> niemeyer: i was trying to fix another problem when i found out
<rogpeppe> mgz: the above branch should fix your $HOME-dependency problems too
<rogpeppe> mgz: i've run all tests successfully with: mkdir /tmp/x; chmod 0 /tmp/x; HOME=/tmp/x go test ./...
<rogpeppe> mgz: apart from the state tests, which need a writable .ssh, because ssh *always* writes to your home directory, regardless of the setting of $HOME
<niemeyer> rogpeppe: That change in file bootstrap.go feels bogus
<niemeyer> rogpeppe: I've been looking at the change that puts it back where it should be on every other branch
<rogpeppe> niemeyer: i think it might be because i'm using a different version of gofmt
<rogpeppe> niemeyer: i.e. the one in tip
<mgz> rogpeppe: looking
<niemeyer> rogpeppe: Maybe, but we need to stabilize the situation
<niemeyer> rogpeppe: I've seen *several* branches fixing this
<niemeyer> rogpeppe: We shouldn't change it back
<niemeyer> rogpeppe: Or we'll continue to see it
<rogpeppe> niemeyer: yeah. i'll put 1.0.3's version in my bin
<rogpeppe> pwd
<niemeyer> rogpeppe: In state_test.go, it's curious that a few lines were not there before
<niemeyer> rogpeppe: THey weren't nil, and now they're being set to ""
<niemeyer> rogpeppe: That means the behavior of the test is actually changing rather than just being moved on the nil/"" situation
<niemeyer> rogpeppe: Was the test borked?
<rogpeppe> niemeyer: the test was relying on the fact that ca-private-key did not exist in $home/.juju, yeah
<rogpeppe> niemeyer: i smoked out these things by running the tests with an inaccessible home
<niemeyer> rogpeppe: Cool
<niemeyer> rogpeppe: So LGTM
<rogpeppe> niemeyer: thanks
<niemeyer> rogpeppe: The gofmt issue is the only detail worth changing before submit
<rogpeppe> niemeyer: i've done it
<niemeyer> rogpeppe: I wonder if that's an accident
<niemeyer> rogpeppe: I mean, the gofmt behavior change
<rogpeppe> niemeyer: it doesn't look right
<rogpeppe> niemeyer: i agree
<niemeyer> rogpeppe: We should report it.. hopefully it can be fixed before the next major
<rogpeppe> niemeyer: submitted.
<niemeyer> rogpeppe: Thanks a lot
<rogpeppe> niemeyer: davecheney says there are other gofmt changes coming
<rogpeppe> niemeyer: in tip
<niemeyer> rogpeppe: Hmm
<rogpeppe> niemeyer: i think we should standardise on 1.0.3
<niemeyer> rogpeppe: Not sure how that affects things.. it feels like an unintended bug
<niemeyer> rogpeppe: (that might be caused by these other changes)
<rogpeppe> niemeyer: until 1.1 is released
<mgz> rogpeppe: lgtm
<rogpeppe> mgz: ta. it's in. i'd like to know if that fixes your problems.
<mgz> ah, I should have mentioned, most of the failures are gone
<mgz> there's still the odd build thing, and I need to pull to get dimitern's fix
<niemeyer> http://code.google.com/p/go/issues/detail?id=4428
<niemeyer> mgz: That's related to your comment on the branch too ^
<mgz> niemeyer: right, I saw the discussion here after hitting submit
<mgz> right, that's it for me
<rogpeppe> niemeyer: here's the branch that implements the --ca-cert-file flag: https://codereview.appspot.com/6842088
<rogpeppe> niemeyer: i've gotta go now, but i'm really hoping you might be able to go through my active reviews before monday :-) it's feely pretty unwieldy atm, although getting that config branch in is a big weight off.
<rogpeppe> niemeyer: thanks a lot for bearing with me with these large branches. i'm hoping that there won't be much more in the way of config changes for a while now...
<rogpeppe> night all
<niemeyer> rogpeppe: Thanks a lot, and have a nice night and weekend
<rogpeppe> niemeyer: and you
<rogpeppe> niemeyer: hope your house decoration is going/has gone well
<niemeyer> rogpeppe: It's pretty much done now.. today was the last day of furniture installation, and the cable/internet guys were around too to upgrade the network
<niemeyer> rogpeppe: Slightly less crappy bandwidth now, hopefully video will suck less on our meetings now
<niemeyer> rogpeppe: I can't handle that anymore, so I'm glad it's over
#juju-dev 2012-11-24
<rogpeppe> fwereade_, davecheney: any change you could give me a trivial LGTM (one line change)? https://codereview.appspot.com/6842094
<rogpeppe> hmm, i think it's probably worth submitting anyway
<rogpeppe> TLS works!
<rogpeppe> at least, all local tests pass. haven't tried live tests yet; i'm on a train.
<fss> can anybody help me with go version? I'm getting "error: cannot find tools: no compatible tools found" and I don't know what to do
<fss> ops, just forgot to specify public-bucket :-)
#juju-dev 2013-11-18
<wallyworld> thumper: you around?
<thumper>  wallyworld hey
<wallyworld> thumper: want a hangout?
<thumper> sure
<wallyworld> https://plus.google.com/hangouts/_/72cpi2rmduripigvi5lgv18b7c
<axw> wallyworld: sorry, I guess I took one person's preference on US spelling for policy :)
<wallyworld> axw: no worries :-)
<wallyworld> no need to apologies
<axw> and certainly no need to apologize
<axw> hur hur
<wallyworld> ha ha ha
<wallyworld> axw: did my review on your bootstrap tools change make sense?
<axw> yes, just makign some changes now
<axw> thanks for that
<wallyworld> np. just wanted to check you were unblocked
<wallyworld> thumper: there's a potential issue with checking if a host machine can run a container. we currently support "juju add-machine lxc" which means create a new machine and add an lxc container. in that case, it's not possible at add-machine time to know if a container is supported or not. there was talk at one stage of removing the syntax allowing just "lxc" or "kvm" and forcing <containertype>:<machineid>
<wallyworld> do you think we could remove the add-machine <containertype> syntax?
<wallyworld> since i think there was feedback we should be explicit about where containers go
<wallyworld> but even in that case, add-machine <container>:<machine> may need to block for a while if the machine is not up yet
<wallyworld> eg if the user has scripted add-machine followed by add-machine container
<thumper> wallyworld: I think it is reasonable for someone to request it
<thumper> wallyworld: even though it may not be fully actionalbe
<thumper> so if there is a pending machine for a particular machine
<thumper> and that machine on starting says "I don't support containers"
<wallyworld> i guess we could relfect in status
<thumper> we need to be able to put that container into an error state
<thumper> since we are operating asyncly
<wallyworld> yes, ok
<thumper> we need to be able to handle this cleanly
<thumper> or at least
<thumper> cleanish
<thumper> o/ axw
<wallyworld> i can do a retry strategy to allow a little waiting if supported containers not known
<axw> heya thumper
<thumper> wallyworld: nah don't do that
<thumper> just expect it to be ok
<thumper> it is up the juju to manage conflicts
<wallyworld> ok
<thumper> don't block
<wallyworld> in many cases, we will hopefully know
<thumper> ack
<wallyworld> and can error immediately
<wallyworld> well, reject the add-machine command i mean
 * thumper nods
<axw> wallyworld: I had to merge cmd/juju/bootstrap_test.go, and some other minor things. I forgot to remove the --source flag from cmd/juju
<axw> if you want to re-review let me know, otherwise I'll just push and land
<wallyworld> axw: otp, but i trust you :-)
<axw> ta
<wallyworld> jam: yeah, looks like it may be about to hail, go to race and get my son from cricket training
<jam> wallyworld: try not to get hurt :)
<wallyworld> will do :-)
<axw> jam: I'm looking at that uninstall-script thing again. What do you think about this alternative: store the agent's upstart service name in agent.conf, as well as a list of subordinate services (for the moment, just juju-db)
<axw> then we just stop/remove them
<axw> and rm -fr config.DataDir()
<axw> no opaque script, so upgrading should be simpler
<jam> axw: can't we just derive the upstart service name? We derive it when we create the service in the first place?
<jam> I will admit I don't know exactly what steps need to be done, I'm mostly just thinking about (a) how much can we just do so that when we change that list it is easy to do so
<axw> jam: could do that too. we'd need to tell the agent that it's a state server some way other than through the state database
<jam> axw: why is that?
<jam> I thought the idea for manual teardown was that the state machines go down last, so we still have the database a bit before their dead (I think)
<axw> yes.. hmm, maybe that's ok
<jam> axw: at the very least, we determined what jobs we were running at startup, right?
<axw> I'll need to look at the conditions for ErrTerminateAgent again
<axw> yes
<jam> given we needed to, ya know, *do* them :)
<jam> axw: this *might* even make it clearer for the HA w/ manual stuff. If you add another node, that one may not start out as a state server, but become one later
<jam> so deciding what needs to be cleaned up just before you do it, *sounds* better to me.
<axw> hmm true, good point
<axw> jam: ErrTerminateAgent requires a state conn anyway (makes sense; db err could be transient), so yes, that'd be fine
<jam> axw: in general my experience with upgrades and Upstart is that we don't have a good way to change Upstart config once we've installed. So I'd like to avoid putting stuff in at that level. If it looks plausible to have the "this is how I clean myself up" clearly expressed inside the thing that is running, that sounds the best to me.
<jam> Actually, the best is to have the newest thing possible know how that thing should clean up (like Upgrade should do the clean up in the New code, etc) but some of that is tricky to do.
<axw> jam: I never would've modified upstart config itself, but agent.conf maybe. But anyway, it looks like it's all doable at runtime, without config changes.
<axw> I'll dig in
<jam> axw: so as for the specifics, I don't care if it is a script file that we generate and then run, vs commands we run directly, or whatever
<jam> I don't quite understand why setUninstallScript has a restore function
<jam> is that so it happens in a defer avoiding panic conditions?
<axw> jam: that was just so changes to AgentEnvironment are contained
<axw> after Configure returns, the original value is restored
<jam> axw: so I think I now understand *what* it does, but I don't quite understand why you don't want AgentEnvironment to stay changed
<axw> jam: it's only of philosophical value - I prefer input variables to be considered immutable
<jam> axw: so I can see where we may not want to mutate what the caller thinks, except if its the whole point of the function :)
<jam> o
<jam> axw: it is suspicious that configure takes and returns a cloudinit.Config which is the same object
<jam> but it appears to be the whole point of the function to mutate the c that is passed in.
<jam> otherwise we should copy it, and return a new one
<jam> which I do prefer
<jam> but it would still be important that we don't unset the thing we just configured
<axw> jam: AgentEnvironment belongs to the MachineConfig (input), not cloudinit.Config
<axw> agreed that the c being input and output is odd - I changed that in another branch the other day :)
<axw> (removed the output)
<jam> axw: the only reason you might want in & out is because you want the caller to nil their object if there is an error, but it does seem like you either want an INOUT var or an IN and OUT but not an INOUT and an OUT
<jam> and if you *really* need the caller to nil, then take an **obj
<jam> cloudinit_test.go is the only place that doesn't pass it back into the same object (as far as I can tell0
<jam> morning fwereade and dimitern
<dimitern> morning
<rogpeppe> mornin' all
<axw> morning
<axw> jam: do you think it'd be horrible to just attempt stopping/removing the juju-db service, and ignore the ENOENT?
<axw> i.e. no check for state server
<rogpeppe> axw: what's the context?
<axw> rogpeppe: uninstalling mongo (juju-db) when destroying a manual provider env
<axw> currently the machine agent just removes its own upstart config, and exits
<rogpeppe> axw: when will it get ENOENT?
<axw> rogpeppe: if the machine agent is not a state server, then juju-db won't exist
<fwereade> jam, dimitern, rogpeppe,axw: mornings
<rogpeppe> fwereade: hiya
<axw> ahoj
<rogpeppe> axw: i *think* it sounds reasonable
<rogpeppe> axw: but i'd've thought it might be just as easy to check for state-serverness
<axw> yeah it probably is. just looking at the options
<axw> blind removal is tempting, because it keeps it all in one spot
<rogpeppe> axw: which spot is that?
<axw> rogpeppe: func (m *MachineAgent) uninstallAgent() error
<axw> cmd/jujud/machine.go
<rogpeppe> axw: presumably you could just pass isStateServer into that function (or machine.Jobs())
<axw> rogpeppe: there's an error condition that the agent deals with  that would cause termination, where the agent wouldn't be able to determine its jobs
<axw> i.e. the machine entry does not exist in state
<axw> but hey, maybe we don't care about nonsense like that :)
<rogpeppe> axw: hmm, i wondered if something like that was possible
<rogpeppe> axw: in that case, i think just delete and ignore ENOENT
<rogpeppe> axw: but...
<rogpeppe> axw: how can we know to destroy things if we can't get the jobs?
<rogpeppe> axw: don't the jobs arrive in the same reply as the machine life status?
<axw> rogpeppe: yes. if that returns not found or unauthorized, the agent terminates
<rogpeppe> axw: ah, of course
<rogpeppe> axw: in which case, i think that ignoring ENOENT is preferable to the alternative (caching locally whether we *did* have state server jobs)
<rogpeppe> axw: in a sense, the upstart config *is* that local cache
<axw> yeah, I'm thinking that too
<rogpeppe> axw: my only hesitation is whether there might be something else with a juju-db service that might get annoyed, but i think enough things will break in that case that we can safely ignore the possibility
<axw> rogpeppe: indeed, I came to the same conclusion
<rogpeppe> fwereade: i think launchpad.net/juju-core/agent/bootstrap.go:123 is crackful and that it should use config.DefaultSeries. what do you think?
<rogpeppe> fwereade: although... hmm, maybe not
<rogpeppe> fwereade: in fact, no i think it's right
<rogpeppe> fwereade: ignore me :-)
<jam> axw: As long as what we are getting rid of is *clearly* a juju script (juju-db, juju-machine-0, etc) I think we're fine.
<jam> we can't run 2 juju's on a given machine without a lot of other pain
<rogpeppe> jam: yeah. it's a pity, that, really.
<jam> (You *might* be able to run a unit of one environment and the state server of another environment, but that just sounds terrible)
<jam> rogpeppe: well, we'd have to put namespaces to do tat
<jam> that
<axw> jam: you can with local, but these changes just won't work with local (which I think is reasonable)
<jam> /etc/init/juju-env-X-machine-0
<rogpeppe> jam: yeah - we'd probably put the env uuid in there
<jam> axw: I'd think we'd want local to clean up properly
<axw> why? env.Destroy does that anyway
<jam> axw: well, we still want local environments to clean up properly, right? (it may be done in a different layer, but we might want to consider how to avoid redundancy as well)
<axw> jam: I consider this to be like freeing memory before exiting a process
<axw> there may be some use case in the future, but I don't see one right now
<axw> handling the local provider with non-standard service names takes us back to modifying agent.conf
<axw> jam, rogpeppe: https://codereview.appspot.com/28270043 -- take a look, let me know if you think it's worthwhile involving agent.conf to fix the local provider case
<mgz> mornin'
<jam> morning mgz
<jam> standup time
<jam> fwereade, rogpeppe, TheMue, https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<mattyw> fwereade, thanks for the reviews :)
<jam> fwereade: you seem to be having connection issues
<fwereade> jam, ha, even my g+ chats don't seem to be getting though
<fwereade> ian, ok, will do
<fwereade> wallyworld, ^
<jam> fwereade: I got your "isn't that just 2" but that was the last one
<fwereade> grar, v quick break, we'll see if it's happier in 3 mins
<fwereade> wallyworld, fwiw, a watcher for "kinds of containers this machine is expected to run" wouldbe easy, and was the originalplan a while ago
<jam> fwereade: well we have "containers this machine is runinng"
<fwereade> jam, I thought that was container-type-specific
<jam> fwereade: right, that is what we are talking about. making one that is non-container type specific, but just doing "all" and reporting back errors for ones it doesn't support
<fwereade> jam, wallyworld: isn't the simplest way to do that to launch a provisioner task with a broker that always just errors on provisioning?
<jam> fwereade: the concern is that you're launching 5 different provisioners that will never do anything
<jam> and a lot of duplicate code
<jam> why not just run 1 that can handle N container types
<fwereade> jam, because watcher->broker is a simple clean chunk of functionality that already exists
<fwereade> jam, that is the *point* of a provisioner -- it watches a specific set of machines and provisions them using a specific broker
<fwereade> jam, adding multiple brokers into the mix complicates that unnecessarily
<fwereade> jam, compared to starting one provisioner for each kind of machine, and using a, ha, "null broker" when that machine kind is not known
<jam> fwereade: but why multiple watchers?
<jam> why not watch all possible containers?
<fwereade> jam, to avoid complicating the provisioner task, mainly
<jam> (it may be the internal DB structure don't support it well)
<fwereade> jam, I'm not sure it's in a great position to have 1->N-ness poked into it
<jam> fwereade: but what would an LXC provisioner do differently than a KVM one?
<jam> the commands are different, but that is a lower level
<fwereade> jam, talk to a different broker, where the two brokers are independent and needn't blockone another
<jam> fwereade: overloading your system because you start an LXC and a KVM and an OpenVZ and a doesn't seem a better User Experience :)
<jam> I agree in the external vs local provisioning case
<fwereade> jam, seriously, a provisioner overloads the system?
<fwereade> jam, if that's actually the case then fair enough
<jam> fwereade: starting up a container does
<jam> apt-get update
<jam> starting 10 of them is actually quite bad (from reports I've seen)
<jam> somone did the local provider and really hosed his sytem
<fwereade> jam, sure, that was jorge doing deploy -n 50, but that was still with one single provisioner in play, so I think not germane
<fwereade> jam, the problem was that he asked for his system to be overloaded
<fwereade> jam, and besides the provider/container distinction I think holes your argument -- you're asking for two kinds of provisioner, a 1->1 and a 1->N one
<fwereade> jam, a single provisioner, that maps from machine-set to broker, seems like the clearest model
<jam> fwereade: I personally don't see why machine-set needs to split by type
<jam> I guess
<fwereade> jam, it doesn't *need* to be, but doing so extracts extraneous functionality from the provisioner, which doesn't need any additional complexity imo
<wallyworld> jam: fwereade: so at the moment, there's an lxcBroker which acts as a provisioner task, as well as a cloud instance provisioner task. i'm sure we'll iterate to get the best model, whether that's one provision task for all container types or one per container type. the kvm provisioner code is not done yet. let's see how it falls out. in the meantime, we will achieve the required user facing functionality wrt containers and all that
<wallyworld> ie users will be able to start supported containers, and get sensible errors if they try and start non-supported ones
<fwereade> wallyworld, ok, that's cool -- I'm just saying I will get a bit shirty if the kvm code requires a single kvm-specific line in the provisioner task itself ;p
<wallyworld> fwereade: as will i. don't fret too much. all i'm saying, it's a work in progress :-)
<fwereade> wallyworld, don't worry, I won't, I know you know what you're doing :)
<wallyworld> sometimes :-)
<wallyworld> fwereade: one of my aims is to get rid of the switch statements in the current provisioner so that the kvm/lxc logic is isolated behind an interface
 * fwereade cheers at wallyworld
<wallyworld> scaling as discussed in the backscroll is a valid concern. we will have to look at that also as part of the solution
<wallyworld> and there's always a trade off between conceptual complexity, number of moving parts etc
<jam> fwereade: so the other logical thoughts are "what about new types", having to add yet-another-thing to monitor for another type that is normally not doing anything, etc.
<jam> we know today that people want openvz, vagrant, vmware, ...
<fwereade> jam, that it the last thing I want
<jam> fwereade: so the nice thing about having 1 "ContainerProvisioner" is that it can also not think about types it doesn't know, but it can still say "I don't know about that type, so here is your error", rather than nothing listening for the OpenVS container type, so when you go to deploy it just sits in pending forever.
<jam> It seemed to smooth things out to have a generic one
<fwereade> jam, the machine agent asks for the types of the containers it's meant to be running; starts provisioners with appropriate brokers for those it understands, and null-broker provisioners for the ones it doesn't
<jam> but it does depend on how things align
<fwereade> jam, null brokers just error on StartInstance
<jam> fwereade: sure, though that does mean Machine Agents run N watchers and N brokers for however many types that we might support
<fwereade> jam, no, it means they run one provisioner for every container type they are currently using
<fwereade> jam, plus one task that starts/stops them
<jam> fwereade: "and null-broker provisioners for the ones it doesn't" is still N
<fwereade> jam, it's a very small N compared to the number of possible container types out there
<jam> I'm not sure I follow.
<fwereade> jam, it's only for those cases where someone deployed an invalid container before the machine came up and was able to setits supported types
<fwereade> jam, most machines just run a container-types watcher
<fwereade> jam, no containers? no types, thus no provisioners
<fwereade> jam, kvm and lxc and vagrant containers added? start 3 of them
<fwereade> jam,one of which is null
<jam> fwereade: I do finally see, though I don't think that has been reflected in the discussions so far.
<jam> wallyworld: does that make sense to you/ ^^
<fwereade> jam, although with a bit of cleverness in state we should be able to auto-error the unsupported ones *anyway* I think
 * wallyworld reads
<jam> I haven't heard about the container-types as a separate thing being watched.
<fwereade> jam, that was the original idea a while back
<jam> fwereade: wel, defense-in-dept is always useful. (how will this thing act if we poke something that could be construed as invalid)
<wallyworld> jam: yes, it makes sense as that's how i've implemented it. when a machine agent starts up, it determines what container types the host can support
<fwereade> jam, that's a benefit of having a null broker for unknown ones that might slip through
<wallyworld> it then watches for containers of those types to be requested
<wallyworld> once a container of a type is first requested, a provisoner task is started
<fwereade> jam, in the ideal case we should be able to squish those weird ones before they even make it to the agent anyway
<wallyworld> the provisioner task for a container type may well then do other stuff to prepare for the firt contaner of a type to start
<fwereade> jam, the types watcher implementation on the server side could filter those out and error them itself, or possibly the SetSupportedContainers stuff could do so itself with a bit of nasty state prestidigitation
<rogpeppe> natefinch: any chance of seeing your proposed package interface, please?
<natefinch> rogpeppe: yeah, sure
<rogpeppe> natefinch: godoc output would be ideal
 * fwereade lunch
<natefinch> rogpeppe: let me just whip up some godoc comments :)
<rogpeppe> natefinch: always write your doc comments before writing the code :-)
<natefinch> rogpeppe: :)  I usually do... this was kind of exploratory coding, so I didn't.  *shrug*
<rogpeppe> natefinch: np
<rogpeppe> natefinch: at this point i'm mostly interested to see if you've got AddPeer or SetPeers
<natefinch> rogpeppe: add and remove
<natefinch> rogpeppe: I could do set, that's actually easier than add or remove
<rogpeppe> natefinch: i'm wondering if set might be more appropriate for our use case
<rogpeppe> natefinch: although you might want to leave add and remove since you've already implemented them
<jam> fwereade, wallyworld: your models don't actually match. wallyworld starts by introspecting the machine, fwereade has a list of requested-container-types that you watch
<jam> so once you have the list, then they mostly match
<wallyworld> i introspect the machine to determine what container types are supported, then watch those only
<jam> wallyworld: which is *not* watching a list of requested container *types*
<jam> and it *is* starting watchers for each type the machine might support
<jam> rather than only ones that have already been requested
<wallyworld> till the first container is requested, it's a strings watcher for the first container instance yes
<jam> thats the key bit that I was missing at least. It may be that I'm misunderstanding the things you've said, but I do feel there is a communication gap between what fwereade is actually describing and what you have
<wallyworld> which then starts a suitable provisioner task
<jam> wallyworld: "first container instance" ?
<wallyworld> afaik, all we have at the moment is the ability to call WatchMachineContainers
<wallyworld> which triggers whenever a container is added to a machine
<jam> which requires a list of container types, right ?
<wallyworld> yes
<jam> wallyworld: so what fwereade is describing, is another watcher
<jam> which is watching the list-of-requested-container-types
<jam> rather than the list-of-known-supported-types
<jam> so we would still have a startup "these are the types I know how to support"
<wallyworld> i currently call WatchMachineContainers - what it gives when it triggers is the container ids
<jam> we actually ask back "and what types would you like me to run"
<jam> wallyworld: right, that is something we *also* need, but fwereade is giving us a layer where we don't start provisioners until the list of *requested* containers now contains them
<wallyworld> that's right, i only start a provisioner when the first conainer of a type is requested
<wallyworld> until then, it's a simple strings watcher
<jam> so WatchMachineContainers would be run by *each* of the LXCProvisioner and KVMProvisioner, with their personal subset. *But* we don't start one until this other field includes that type in the list.
<wallyworld> no
<jam> wallyworld: but what happens when you have another one
<wallyworld> the provisioners are not started
<jam> or one that is a type you didn't probe for
<jam> or
<jam> etc
<wallyworld> well, the machine agent has to know what possible containers to probe for
<wallyworld> cause there's different initialisation code required for each type
<wallyworld> so it has to be baked in to the system
<wallyworld> we can't suddenly support new container types
<wallyworld> without the code which knows how to set up for that
<wallyworld> which packages to apt-get install etc
<jam> wallyworld: to give a hypothetical. Wouldn't it be nice if someone could request an OpenVZ which Juju 2.2 knows about, it goes into the DB, but the agent on machine-2 is only running Juju 2.0 and can just say "sorry, container type X not supported"
<jam> wallyworld: I'm certainly not saying we support things we don't know how to support
<jam> but what about being able to give error messages about things we haven't heard about before
<wallyworld> i can certainly modify the code to do that
<wallyworld> that would be easy to do
<wallyworld> it would only be a small tweak
<wallyworld> actually
<wallyworld> that's how it woeks now
<wallyworld> when the machine agent starts up
<wallyworld> it sets the supported container list
<jam> wallyworld: and I *think* it actually handles the "you asked for KVM which I know about but I don't actually support that" as well as "you asked for OpenVZ which I know nothing about"
<wallyworld> and if juju client 2.2 comes along
<wallyworld> and asks for something new, it will error immediately
<jam> wallyworld: except if the machine hasn't finished starting yet, which means it will go off into lala land because nobody is checking for a type that wasn't baked in.
<jam> which is why the "give me the list of types that have been requested, so I can start things for them, and oh, these ones I don't know about so put them into error state"
<wallyworld> no, cause i'm still writing that code
<jam> similar to "these ones I know about but don't actually support"
<wallyworld> and i will be checking for requested stuff that's not supported
<wallyworld> in fact, the code i have does do that already
<jam> it isn't hard to say "if I don't know about it, it isn't supported"
<wallyworld> yes
<natefinch> rogpeppe: http://pastebin.ubuntu.com/6437236/
<wallyworld> jam: the code in progress i have iterates over all requested containers, and sets status if not supported
<wallyworld> so that will pick up new container type XYZ
<jam> wallyworld: but it only does that at startup time ?
<adeuring> rogpeppe: could you have a look athis MP: https://codereview.appspot.com/28310043 ?
<rogpeppe> natefinch: why ...[]ReplsetMember ?
<rogpeppe> adeuring: looking
<wallyworld> jam: yes, but the iteration happens after the block has been established to prevent unknown containers from being reuested
<adeuring> thanks!
<jam> and aftewards it starts watching for only the types that it does support
<rogpeppe> natefinch: wouldn't  ...ReplsetMember be sufficient?
<jam> but it starts watching for *all* things that it might support
<wallyworld> yes
<natefinch> rogpeppe: sorry, I just changed that... yeah, that's what I meant
<wallyworld> jam: but only a strings watcher, not a provisioner
<jam> the model from fwereade is to put a Watcher on actually requested types, for those that are requested, start a provisioner watching for containers of that type. When the list of requested types change, the first one first and starts a new provisioner which may be a "not supported provisioner"
<natefinch> rogpeppe: I always forget the exact syntax for the variable params arrays
<wallyworld> jam: i don't plan on starting any "not supported provisioners"
<rogpeppe> adeuring: LGTM
<wallyworld> no point
<jam> wallyworld: my point is if we do the fwereade one, we don't ever end up in a race condition where we might not notice when someone requests something we don't support, even if the client is buggy and doesn't actually respect the supported types field
<adeuring> rogpeppe: thanks!
<rogpeppe> natefinch: ... replaces []
<wallyworld> buggy client, never :-)
<adeuring> fwereade: could you have a llok here: https://codereview.appspot.com/28310043 ?
<natefinch> rogpeppe: yeah, I remembered that after you mentioned it.
<wallyworld> jam: the back end is the thing that looks at the supported types field
<jam> so while we *could* write it the other way, this way handles the cases we do care about, saves resources internally (doesn't have to even start watchers for supported types that aren't in use), and handles failure more gracefully
<wallyworld> jam:  the client just gets an error
<wallyworld> here's no logic in the client
<wallyworld> there's
<jam> wallyworld: buggy code
<jam> regardless client
<natefinch> rogpeppe: I'd add SetReplicas that just takes an array of ReplsetMember and replaces the set in the mongo document
<jam> anyway, your model can be made to work, the other just seems more robust and actually consumes less resources because you aren't even starting Watchers until one is requested
<wallyworld> jam: the client asks for a container xyz, that goes to the server side, the server side is the thing that error's
<jam> you start A watcher
<jam> and never N watchers
<rogpeppe> natefinch: i think i'd prefer to see bools rather than *bools in ReplsetMember, even if it means having another type for marshalling
<wallyworld> jam: from memory, i start oen strings watcher per supported container type, after the suported container types have been set, preventing new unsupported ones from being rwquested
<jam> wallyworld: anyway, your design can certainly be made to work. My #1 point is that it doesn't actually match what fwereade is saying, and his does have an interesting benefit.
<wallyworld> i don't see the benefit just yet
<wallyworld> my current implementation doesn't allow unsupported containers, is robust to old clients, and doesn't start unnecessary watchers
<wallyworld> s/old/new
<jam> wallyworld: benefit #1, for 90% of all machines that don't run any containers, they start 1 watcher of requested-container-types, even when we support 10 different Virtualization types
<natefinch> rogpeppe: the only problem with that is that buildindexes defaults to true if unset, which is annoying to do in go marshalling .... doable, but annoying.
<jam> so you *could* deploy to any of those types (say you are running on MaaS so you have full support for whatever you want). but then you still have only 1 watcher because you aren't actually using any of them.
<wallyworld> jam:  the current WatchContainer method doesn't take a list
<rogpeppe> natefinch: then have NoIndexBuilding or something?
<wallyworld> it just takes a single container to watch for
<jam> wallyworld: absolutely. It needs code written
<wallyworld> hence right now I need N
<jam> the stuff we have today doesn't match the design fwereade stated we were trying for
<wallyworld> i could change it yes
<natefinch> rogpeppe: hrm... I sorta hate to modify the API for replicasets away from the Mongo documentation.
<jam> we need another Watcher to watch the list-of-requested-container-types
<jam> fwereade's claim is that was the design
<jam> so the data may already be present in the DB
<wallyworld> jam: so whether we start 1 initial watcher or N, it's essentially the same design
<wallyworld> jam: not  list-of-requested-container-types, but list of supported container types
<rogpeppe> natefinch: we're still having the same defaults, so i think it's reasonable. (I think it would be quite unintuitive if the zero value of some of those *bools implied true and others false)
<wallyworld> no need to watch for those we don't support
<rogpeppe> natefinch: i think we can be go-idiomatic even while sticking reasonably close to mongo docs
<rogpeppe> natefinch: even better, we can include links to the relevant parts of the doc
<rogpeppe> s/can/could/
<natefinch> rogpeppe: I'm just going off the defaults of what Mongo gives you.  Not my faults they're inconsistent ;)  To me, the point shows that they're optional, and the default is whatever mongo says the default is.
<natefinch> s/point/pointer
<rogpeppe> natefinch: i think it's going to be really awkward to build a ReplsetMember
<jam> wallyworld: sure, but if we don't support them they likely won't end up in the requested set either.
<rogpeppe> natefinch: i'd much prefer if it didn't need pointers to bool
<jam> wallyworld: the point is to handle failure modes "oh it *did* end up in the requseted set somehow"
<rogpeppe> natefinch: or float, for that matter
<natefinch> rogpeppe: I guess pointers to booleans are annoying, it's true.
<jam> and still be able to respond to it
<wallyworld> jam: sure, my code does that now
<jam> rather than just staying in Pending forever
<jam> wallyworld: sure, but it *also* starts N watchers when there are 0 requested containers
<wallyworld> by my code i mean the stuff in progress
<natefinch> rogpeppe: the problem is that the defaults aren't zero for Priority or Votes.
<wallyworld> jam: it has to start a watcher (or N currently)
<jam> wallyworld: it *has* to start 1
<jam> yes
<jam> but 1 != N
<wallyworld> so it knows when to kick off a new provisoner and prepare for that container type to be deployed
<rogpeppe> natefinch: tbh, i don't mind if we don't have defaults for those
<wallyworld> jam: sure, but with the api we have now, i have to start N
<jam> wallyworld: you were asking for fewer moving parts
<wallyworld> i can change that
<wallyworld> i'm just using what we have to get it working
<wallyworld> in  user visible sense
<wallyworld> can iterate behind the scenes once it's running
<jam> wallyworld: mostly it felt like you didn't quite understand the design fwereade was talking, because you certainly weren't designing it in the same fashion. I wanted to make sure we are actually having the same conversation
<natefinch> rogpeppe: now who's making it more difficult to create replica members?  As it is, all you have to specify is the Host (actually that's something I shold work out - the Ids of the members are really just their index i nthe list... I probably shouldn't expose them)
<jam> steps along the way, as long as we're actually headed in the same direction
<rogpeppe> natefinch: one possibility is to have a separate type, say MemberSettings, and have a value, say DefaultMemberSettings
<rogpeppe> natefinch: which holds all the usual defaults
<wallyworld> but i am designing it in the same way - just differ initially on the initial watcher
<wallyworld> 1 vs N
<wallyworld> or at least i think so
<natefinch> rogpeppe: likely, most people will only use Host as a value.  The rest are rarely used, other than ArbiterOnly
<wallyworld> jam:  i haven't actually talked to fwereade about this at all, just going by scanning the scrol back
<natefinch> rogpeppe: (at least from what the documentation says, it seems unlikely they're options that are used very often, since the doc says stuff like "generally you shouldn't change this" etc)
<jam> wallyworld: you aren't watching a list-of-requested-container-types at all, which is quite different from what he described.
<wallyworld> the core concepts though i think are in alignment - doesn't start provisoners until needed, delay host init until needed etc
<jam> I think after you have a watcher of something requested
<jam> you're doing the same thing
<wallyworld> maybe you and i differ on terminology
<wallyworld> i think i am watching a list of supported continer types
<jam> (15:16:00) fwereade: wallyworld, fwiw, a watcher for "kinds of containers this machine is expected to run" wouldbe easy, and was the originalplan a while ago
<natefinch> rogpeppe: I like the default value of the struct.. that's not a bad idea.  I just think it's less straightforward than just doing it the way I have it.
<jam> wallyworld: no, you are starting N watchers on each type that you support
<jam> which is not a watcher of "what types have been requested for this machine"
<wallyworld> jam: yes - alist of supported contsiner typrs = a list of kinds this is expected to run
<wallyworld> jam: no 1 watcher on each type = N
<wallyworld> not N watchers on each type
<wallyworld> and that's only because there's no the api to support one watcher for all supported typrs
<wallyworld> yet
<jam> so, yes we were talking past eachother a bit
<jam> N watchers, 1 for each type you support
<jam> vs
<jam> wallyworld: you are starting N watchers
<jam> vs
<jam> starting 1 watcher that gets a list of things that it should then start watchers for
<wallyworld> i don't get the last line, but
<wallyworld> i would only like to start 1 watcher for the N container types
<wallyworld> when the api supports that
<wallyworld> it would be a small change to what we do now
<jam> wallyworld: if I have a doc in the DB, that aggregates all container types requested for this machine, which is just a list of [LXC, KVM], though in the common case is just []
<jam> fwereade's contention was that "that was the original design"
<jam> which was clear didn't match what is being implemented
<wallyworld> ok, i see now
<jam> and I was trying to be clear about where he at least thought we were going
<wallyworld> i watch for cotainer ids
<wallyworld> and on the first one, start yje provisoner
<wallyworld> essentially the same thing
<wallyworld> with less moving parts
<wallyworld> cause the db model is simpler
<jam> wallyworld: except in the common case each machine-agent starts up N watchers, which is resources in the API server
<jam> to watch for things that will never actually have chanegs
<jam> changes
<wallyworld> yes, but will be one
<wallyworld> when the api is fixed
<jam> wallyworld: so I was proposing that, but fwereade seemed to think it was bad
<jam> and prefered the "original design"
<jam> which is why this thread got started
<jam> so I've at least illuminated where you two differe
<jam> and I will happily step back and let fwereade and you finish the conversation
<wallyworld> seems so :-) sorry, i was not getting it at first
<jam> wallyworld: neither did I. I just got it slightly sooner than you.
<wallyworld> well, i've had a few glasses of wine here by now, it's almost 11pm :-)
<jam> It wasn't until (15:53:01) jam: wallyworld: does that make sense to you/ ^^
<jam> that I got what the difference was
<wallyworld> i think i skimmed that bit, sorry :-)
<wallyworld> in any case, i'd like to finish what i currently have - it works, is robust to different client versions
<jam> wallyworld: np, I didn't catch that you weren't understanding the "starting N watchers, 1 of each type" thing
<wallyworld> and we can argue about how to tweak it
<wallyworld> jam: yeah, i would have preferred to have only 1 watcher, but thought getting the new api done would take too much time
<wallyworld> and i wanted to try to have kvm done for this week
<wallyworld> cause the new api may we involve back end changes
<wallyworld> to the watcher infrastructure
<jam> wallyworld: sure. I think the discussion is just whether we have a higher-level watcher that then fires off these sub ones, or an aggregate watcher across them.
<wallyworld> yeah. once the provisioner is started, it essentially becomes that watcher
<wallyworld> s/that/the
<jam> yeah
<wallyworld> all the work to add the supported containers db model, and the code to update status etc is essentially independent of the initial watcher thing
<wallyworld> hence i can get that done and provide the user visible functionality up front
<wallyworld> and tweak the behind the scenes stuff later
<rogpeppe> natefinch: why does InitReplicaSet need to be run on the same machine when initially setting up a replica set?
<natefinch> rogpeppe: hmm.. I thought it had to be so mongo would know to replicate the stuff in this mongo instance, but it looks like I was wrong.  The docs don't mention that, so I'll remove it.
<rogpeppe> natefinch: i actually didn't think it was possible to change an existing mongo to use a replica set without restarting it, but presumably you found out a way?
<natefinch> rogpeppe: oh, no... this code is outside that.  I didn't write the restarting code yet, since that's outside the scope of what mgo can do.  But that's pretty trivial, a couple exec commands
<natefinch> rogpeppe: which is to say, yes, you have to restart mongo
<rogpeppe> natefinch: i think that perhaps we can ignore that - we'll perhaps use a different upstart name, and make sure that the old one is removed before ensuring the new one exists.
<rogpeppe> natefinch: do we actually need an InitReplicaSet call then?
<natefinch> rogpeppe: you have to do both, the flag on mongo startup and initreplicaset
<natefinch> rogpeppe: brb
<jam> natefinch, rogpeppe: do you have to restart mongo anytime you change the replica set ? It looks like you have to set the startup flag, but we could just do that always, right?
<rogpeppe> jam: no you don't
<jam> rogpeppe: so http://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/ certainly says you can't take a running service and make it HA without stopping it
<rogpeppe> jam: we need to pass in the replica set name, but otherwise i think there's no need to restart
<jam> unless we default to always starting in a replica set with just 1 entry
<rogpeppe> jam: that's what we'd do, i think
<rogpeppe> jam: unless you can think of a reason that's a bad idea
<natefinch> jam, rogpeppe:  so are you saying, always start mongo with the flag, but then just don't do replsetinitiate?
<rogpeppe> natefinch: i think so. i'm not quite sure what your InitReplicaset function is doing though.
<jam> rogpeppe: http://paste.ubuntu.com/6437458/
<jam> ah, "we'd do"
<jam> not "thats what we already do"
<natefinch> rogpeppe: its what actually sets up the replica... it passes in the list of replicas.  I don't know what it does behind the scenes.  I can test what happens if you start mongo with --repl and try to use it as an individual database
<rogpeppe> natefinch: from an API user's p.o.v., i'd prefer not to have to call InitReplicaset ever
<jam> natefinch: so it sounds like we'd really like to do all of that work in "bootstrap-state"
<jam> so that we have *a* replica set with just 1 entry
<jam> natefinch: rs.initiate() takes an *optional* configuraiton
<jam> which sure sounds like the intial value can just be 1 node
<natefinch> jam: good point
<rogpeppe> my experiments seemed to show it worked fine with just one node in the replica set
<rogpeppe> there's one slight problem though
<rogpeppe> in bootstrap-state, we don't necessarily know the machine's address
<rogpeppe> or... do we?
<jam> rogpeppe: again rs.initialize() can just be started without passing in anything
<jam> let mongo sort it out
<jam> we can change it later when we expand it
<rogpeppe> jam: it might not sort it out correctly
<rogpeppe> jam: at least on my laptop, it got the wrong address
<jam> rogpeppe: there is a warning that you shouldn't use localhost for a member unless all entries are on localhost
<jam> rogpeppe: *but* couldn't we do that when expanding?
<jam> certainly it doesn't matter when there is no entries
<rogpeppe> jam: yeah, you're probably right
<jam> well, when there are no *other* mongod's
<jam> mongods ?
<jam> natefinch: extra exciting is that the docs *explicitly* say you shouldn't use mongorestore to seed the new guys, but you *could* snapshot the filesystem when mongo is in a consistent state.
<jam> sounds like "stop mongod, snapshot the filesystem, then start it again"
<jam> which is pretty terrible.
<jam> I'm hoping as long as you haven't written data you don't *have* to
<jam> it just needs a really long oplog
<jam> yeah, while earlier in http://docs.mongodb.org/manual/tutorial/expand-replica-set/ it says "you can seed it this way", the next section says "you should not have any data already"
<natefinch> jam: It should just sync
<natefinch> jam: yeah, adding replicas with data in them would be bad
<jam> so a little Schizophrenic
<natefinch> brb, diaper
<jam> natefinch: so it sounds like as long as you have an exact FS snapshot, then you'd be ok
<jam> probably mongodbrestore doesn't preserve some oplog property
<jam> it does sound like you just want to start empty
<jam> I don't think we want to try producing a stable snapshot to copy on our own
<rogpeppe> natefinch: here's an idea for a possible package interface. it's pretty close to what you have now, semantically, but with somewhat different names: http://paste.ubuntu.com/6437493/
<rogpeppe> natefinch: need to go to lunch, back soon
<jam> rogpeppe: interestingly, it does look like you have to add replica set members one by one, and they must already be started
<natefinch> jam: pretty sure I've tried adding them before they were started, but I should double check
<jam> natefinch: it does appear that you could set the configuration
<jam> and then they should come online "by magic" as the command doesn't look to be synchronous
<jam> but the docs certainly tell you to start them first
<jam> presumably you could add them, and it would just go into non-quorum state
<jam> which might be pretty bad if you are going from 1-3
<jam> 1 to 3
<jam> rather than adding 1, waiting for the sync to finish, then adding another
<natefinch> jam: isn't 2 a problem either way?
<jam> natefinch: might be worth trying. create a bunch of data, start 1, add 2 and see if it accepts more data while it is bringing 2 and 3 up
<jam> natefinch: so if you start with 1, and add 1, you still work, though if either one fails you've lost quorum
<jam> I tihnk
<jam> but at least it should still take writes (i would think)
<jam> as it knows it is the elected master
<jam> if you start 1 and add 2d
<jam> 2
<jam> maybe it is still true
<jam> that it knows it is the master by election process
<jam> worth trying to see if adding 2 immediately puts it into "unavailable until sync is don"
<jam> don'
<jam> done
<jam> natefinch: anyway, if you add 2 and they aren't up yet
<natefinch> jam: it definitely says it re-elects when you remove a replica, but doesn't say it does when you add... so it's possible it'll just work
<jam> it should refuse writes
<jam> "should"
<natefinch> jam: yeah, lotta shoulds.  I'll do tests and figure out what it *does* do :)
<jam> they may get put in some sort of "pending" nodes that don't actually change quorum
<jam> natefinch: hopefully you don't have to test across version permutations
<natefinch> jam: versions of mongo?
<jam> natefinch: right
<natefinch> jam: well, they just released 2.4 recently, and it looks like they're on about an 18 month cycle, so I think we're good for a while
<jam> natefinch: http://engineering.foursquare.com/2011/05/24/fun-with-mongodb-replica-sets/ is interesting, though I don't think we'll actually be setting up hidden backup nodes
<jam> natefinch: except we're running 2.2.? in production today :)
<natefinch> jam: oh.
<jam> so we know we need at least 2 version
<jam> versions
<natefinch> jam: I guess testing 2.2.x and 2.4 is probably a good idea.  Are we likely to start using 2.4 soon?  What determines that?
<jam> natefinch: #1 thing is what version will be in Trusty
<jam> but I'm quite sure we're stuck with 2.2 for precise->saucy for a while
<jam> if we want to go to 2.4 we probably have to get it into trusty real-soon-now
<jam> jamespage: ^^ do you know the plans for upgrading MongoDB version? I'm guessing we don't want to be using mongodb 2.2 in 3 years
<jam> anyway, dinner time here
<jam> see you all later
<jamespage> jam: trusty already has 2.4
<jamespage> so did saucy
<natefinch> jamespage: cool, thanks
<jamespage> natefinch, np
<jam> natefinch: so in other words, we already deploy to 2.2 and 2.4
<jam> given ppa:juju/stable is running 2.2
<jam> for P
<jam> jamespage: unless my "apt-cache madison" is lying somehow :)
<jamespage> jam: yes - but juju auto-adds cloud-tools which contains 2.4
<rogpeppe> natefinch: do you know if there's any way of asking whether replica set members are up to date with the log?
<adeuring> jam: could you have another look here: https://codereview.appspot.com/28310043/ ?
<natefinch> rogpeppe: I'm not sure
<rogpeppe> natefinch: i've just found it
<rogpeppe> natefinch: http://docs.mongodb.org/v2.2/reference/replica-status/#repl-set-member-statuses
<rogpeppe> natefinch: what do you think of my proposed package interface, BTW?
<rogpeppe> natefinch: i tried to formulate it from the top down as something i'd like to use rather than from the bottom up
<rogpeppe> natefinch: http://paste.ubuntu.com/6437493/ in case you missed it
<natefinch> rogpeppe: saw it
<natefinch> rogpeppe: mostly looks good to me. The one problem I have with memberdefaults is that if anyone just constructs members to pass in without noticing they should use the defaults... they'll get pretty bad defaults (no votes, 0 priority, and no indexes)
<rogpeppe> natefinch: yeah; i think that's ok though. the defaults are there and obvious.
<natefinch> rogpeppe: hrmph. It's not horrible, but not my favorite thing.  The defaults on the struct are not what the struct actually defaults to.
<sinzui> fwereade, rogpeppe: can either you of help me triage this bug? Do we is it really in Juju? Do we commit to fix it in the next 6 months? Bug #1250965
<_mup_> Bug #1250965: Loopback mounts do not work with local provider <local-provider> <juju-core:New> <swift-storage (Juju Charms Collection):New> <https://launchpad.net/bugs/1250965>
<rogpeppe> natefinch: yeah, maybe better to leave out the "defaulting to" remarks and just rever to MemberDefaults in the Member doc comment
<rogpeppe> sinzui: looking
 * rogpeppe looks up "loopback mounts"
<rogpeppe> sinzui: by my very limited understanding of the issue, it looks like something we could probably fix soon and easily
<rogpeppe> sinzui: and that we should do
<sinzui> thank you!
<rogpeppe> sinzui: but there might be security or other issues that i'm not aware of
<sinzui> understood.
<dimitern> rogpeppe, ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe, what's the preferred way to get an the environ from an api connection?
<rogpeppe> dimitern: juju.NewConnFromState
<dimitern> rogpeppe, if I use NewAPIClientFromName I only get the api client, not the underlying APIConn, which has both state and environ
<rogpeppe> dimitern: best to avoid the necessity if possible though
<rogpeppe> dimitern: which call is this that needs it?
<dimitern> rogpeppe, I need something like NewConnFromState, but connecting to the API and returning the APIConn
<dimitern> rogpeppe, upgrade juju needs an environ in order to call FindTools with it
<rogpeppe> dimitern: oh, i see, as an agent
<dimitern> rogpeppe, as a client
<dimitern> rogpeppe, right now conn.Environ is used to get the environ in the command
<rogpeppe> dimitern: cfg, err := st.EnvironConfig(); env, err := environs.New(cfg)
<dimitern> rogpeppe, ah, ok, so I can call client.EnvironmentGet() and use that to construct and environ object
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, cheers
<rogpeppe> dimitern: although...
<rogpeppe> dimitern: we might possibly want to provide a way for a client to find tools without necessarily providing them with the whole environ config
<rogpeppe> dimitern: so there may well be an argument for a new API call here
<rogpeppe> fwereade: what thinkest thou?
<dpb1> fwereade: ping
<dimitern> rogpeppe, I realized I don't need to implement anything else than client.SetEnvironAgentVersion() in the API, and use EnvironmentGet() initially
<rogpeppe> dimitern: sounds good
<jcsackett> sinzui, abentley: either of you free to look at https://code.launchpad.net/~jcsackett/charmworld/better-jobs/+merge/195443 ?
<abentley> jcsackett: sure.
<jcsackett> also, do we have a new "ping the team" word, since we're not orange anymore?
<jcsackett> thanks, abentley.
<abentley> Maybe juju-qa?
<abentley> jcsackett: It looks like you've added tests for your github changes, but not askubuntu.
<jcsackett> abentley: that's true, since i didn't think it was really changing askubuntu execution.
<jcsackett> abentley: oh wait, the backoff thing should have a test.
<abentley> jcsackett: That's what I was thinking.
<jcsackett> abentley: dig, i'll add that.
<sinzui> fwereade, I see a report using the 1.16.4 potential client has a problem when the state-server is 1.16.3. ERROR no such request "DestroyMachines" on Client.
 * sinzui is attempting to reproduce
<fwereade> sinzui, oh *shite*
<fwereade> sinzui, ofc it's reproable, I am an idiot, I even thought of it and then forgot it
 * rogpeppe sees 1.16.5 arriving pronto
<fwereade> sinzui, *unless* I convinced myself that it was an expected and transient error
<fwereade> rogpeppe, that'll have the same problem
<sinzui> fwereade, we do not normally see this in tests because they assume you are savvy enough to upload your tools if you have a release candidate, or we have release the actual tools
<rogpeppe> fwereade: unless 1.16.5 rolls back some client changes i guess
<fwereade> rogpeppe, and thus rolls back the bugfix
<rogpeppe> fwereade: the bugfix can't apply client-side? i guess not unless you factor out stuff to statecmd
<sinzui> 1.16.4 is not out, We are going to release today I think.
<rogpeppe> fwereade: sorry, i should have thought of this in my review
<sinzui> fwereade, caribou reported the issue.
<fwereade> rogpeppe, or tangles the source tree by introducing a 1.16-only statecmd bit
<sinzui> I gave him the script that make a package
<fwereade> sinzui, all praise to caribou
<rogpeppe> fwereade: i'm not quite sure what you're thinking of there
<fwereade> sinzui, I don't suppose it's reasonable to ask people to upgrade both server and client if they want the bugfixes?
<fwereade> rogpeppe, the more 1.16 diverges from the shape of trunk the harder it will be to maintain -- I don't want to make that experience suck until we have 1.18 out, at which point we needn;t worry about 1.16 so much anyway
<sinzui> fwereade, I consider a bug if the client ever selects a newer server.
<fwereade> sinzui, yeah, normal use will lead to breakage
<rogpeppe> fwereade: ah, bit==piece, not 1-or-0
<sinzui> fwereade, I do think it is reasonable to say upgrade your client, then upgrade the server
 * fwereade kicks himself around a bit
<jcsackett> abentley: tests are pushed up.
<fwereade> sinzui, new server with old client still works, but doesn't allow for --force, right?
<fwereade> sinzui, it's just old server with new client?
<sinzui> fwereade, I am not sure, caribou has stepped away for a bit
<abentley> jcsackett: This also adds remove_server_start_time.py.  Is that deliberate?
<sinzui> fwereade, this is the background I have about the issue: after the report of the error: http://pastebin.ubuntu.com/6438018/
<abentley> Oh, I guess that's a merge.
<abentley> jcsackett: r=me.
<sinzui> fwereade, "even without the --force it fails"
<sinzui> fwereade, basic "juju terminate-machine 1" fails with the message mentioned previously
<fwereade> sinzui, I think it is clear -- I backported the DestroyMachines and DestroyUnits API methods to 1.16.4, so 1.16.3 client still works by talking direct to the db
<fwereade> sinzui, but 1.16.4 client expects the APIs to exist, and a 1.16.3 server does not have them
<fwereade> sinzui, FWIW this will also break destroy-unit in the same circumstances
<sinzui> fwereade, This issue might also be alleviated with "best practice". I have advised "juju upgrade-juju --version=1.16.4" to be clear about putting everything on the same version
<fwereade> sinzui, well, if we can be very clear about it in the release notes, it *does* expose very useful new functionality
<rogpeppe> natefinch: here's the replicaset package interface suggestion with status added, FWIW: http://paste.ubuntu.com/6438102/
<jcsackett> abentley: thanks.
<dimitern> fwereade_, rogpeppe: upgrade-juju + api https://codereview.appspot.com/21940044/ PTAL
<natefinch> rogpeppe: reading it
<natefinch> rogpeppe: are you running Mongo 2.2 or 2.4?
<rogpeppe> natefinch: 2.2.4
<rogpeppe> natefinch: ah, i was looking at the 2.2 docs when i was doing that package description
<natefinch> rogpeppe: yeah, figured. I was poking at mongo and noticed some more info in status, but it must be added in 2.4
<rogpeppe> TheMue: ping
 * fwereade_ will bbl
<TheMue> rogpeppe: pong
<rogpeppe> TheMue: i've just been looking at https://codereview.appspot.com/24040044 again
<TheMue> rogpeppe: yep
<rogpeppe> TheMue: it still doesn't seem quite right to me, unless i'm missing something
<TheMue> rogpeppe: ok, I'm listening
<rogpeppe> TheMue: if a connection drops, what cleans up the pingTimeout?
<TheMue> rogpeppe: if it drops Ping() isn't called, so the timer isn't reset, after 3 minutes there's a timeout which calls the passed action. and here rpcConn.Close() is called, which also call Kill() on the root (it implements the killer interface, but that already existed)
<TheMue> rogpeppe: in the inital code Ping() already existed, but with no code inside, only a comment
<natefinch> rogpeppe: I'm going to go with your suggestion and move the code I have over to it (it's really just some minor changes). I don't have the status code written, but that should be easy.
<rogpeppe> natefinch: cool, thanks.
<natefinch> rogpeppe: one thing - is it really that useful to return maps of statuses and members
<rogpeppe> TheMue: so if a client drops a connection, the goroutine will remain around for up to 3 minutes. that seems a bit wrong to me - surely we can clean it up?
<rogpeppe> natefinch: i dunno, i wondered about that
<rogpeppe> natefinch: it nicely suggests the fact that there's only one entry per address
<rogpeppe> natefinch: and it *might* work out more nicely in the actual agent code
<TheMue> rogpeppe: eh, until those 3 minutes are done we're not sure that the connection is dropped (or the agent on the other side is just blocked)
<rogpeppe> TheMue: what if the client explicitly drops the connection?
<natefinch> rogpeppe: seems like it just makes it a little more annoying to iterate... it's also a difference from the way the data is input.  It's not too hard to construct a map from a list if you need a map... it just doesn't seem like it actually fits the data model (other than, yes, there's only one per host... but that's generally more useful on input than output)
<TheMue> rogpeppe: how is apiserver notified about that today?
<rogpeppe> TheMue: the Kill method is called
<rogpeppe> natefinch: the scenario i'm thinking about is you get info, then you want to see how the info corresponds with info you already hold.
<rogpeppe> natefinch: but if you really think it doesn't fit very well, then slices could be fine, probably
<TheMue> rogpeppe: ok, so I should stop the goroutine here too, but as Kill() is called in Close() I have to ensure that it doesn't deadlock
<rogpeppe> TheMue: yup
<TheMue> rogpeppe: do you add a note in the review? otherwise I'll do it ;)
<rogpeppe> natefinch: having CurrentMembers return the same thing as is passed to replicaset.Set and Add seems like a reasonably strong argument for returning a slice actually
<rogpeppe> TheMue: i will
<TheMue> rogpeppe: great, thx
<natefinch> rogpeppe: that was my thinking
<rogpeppe> natefinch: and CurrentStatus should be similar to CurrentMembers, so yeah, go with slices all round
<natefinch> rogpeppe: plus, there's only a max of 12 items in the list, so even if you have to do naive N^2 logicm it isn't going to hurt anything
<natefinch> rogpeppe: cool
<rogpeppe> natefinch: performance was not part of my considerations
<natefinch> rogpeppe: going to be out for about an hour.  Turning into a late working day for me, but so be it.  I should have that code all set by EOD, and hopefully some tests too.
<rogpeppe> natefinch: brilliant, thanks!
<TheMue> rogpeppe, natefinch: anybody knows that error that made my merge fail: https://code.launchpad.net/~themue/juju-core/054-env-more-script-friendly/+merge/191838
<rogpeppe> TheMue: sporadic failure
<rogpeppe> TheMue: just mark as approved again to try once more
<TheMue> rogpeppe: ah, already wondered
<TheMue> rogpeppe: thx
<sinzui> fwereade_, do you have a moment to discuss terminate-machine from new client to old server?
<rogpeppe> right, done for the day
<rogpeppe> g'night all
<rogpeppe> off to see Gravity at the local 3D imax; should be good if the reviews are anything to go by.
<mramm> rogpeppe: have fun!
<natefinch> rogpeppe: night.  Supposed to be good, yeah.
<thumper> morning
<natefinch> thumper: morning
<thumper> natefinch: o/
<sinzui> thumper, could you read and reply to the message "Geting bug 1222671 into 1.16.4" that I sent to juju-dev
<_mup_> Bug #1222671: Using the same maas user in different juju environments causes them to clash <cts-cloud-review> <maas-provider> <Go MAAS API Library:Fix Committed> <juju-core:Fix Committed by thumper> <juju-core 1.16:In Progress by sinzui> <https://launchpad.net/bugs/1222671>
<thumper> hi sinzui
<thumper> sinzui: it was my understanding that the merge that rog did into the 1.16 branch fixed that
<thumper> which is why I marked it fix committed or fix released in that series
<sinzui> Fab. Thanks thumper
<thumper> I may be mistaken, but that is what I thought
<thumper> fwereade_: you around?
<fwereade_> thumper, heyhey
<thumper> fwereade_: hey dude
<thumper> got time for a hangout?
<fwereade_> thumper, how's it going?
<fwereade_> thumper, sure
<thumper> good,
 * thumper starts one
<thumper> fwereade_: https://plus.google.com/hangouts/_/7ecpjvqj508h694vc55hjnqsvo?hl=en
<thumper> wallyworld: so... we don't have any shared storage any more?
<thumper> wallyworld: I could remove a config key from the local provider
<thumper> shared-storage-port
<wallyworld> nope, cause only ec2 and openstack had it anyway
<wallyworld> and now we have simplestreams it's not needed
<wallyworld> i guess so, not sure what shared-storage-port did
<thumper> wallyworld: we should really fix the tools uploading for the local provider
<wallyworld> yes
<thumper> wallyworld: also, fwereade_ wants to chat with you
<wallyworld> i'm available
<fwereade_> wallyworld, heyhey
<wallyworld> yello
<wallyworld> fwereade_: did you want a hangout?
<fwereade_> let's have a go
<fwereade_> google has started hating me again after a goodish week
<wallyworld> https://plus.google.com/hangouts/_/72cpil41gfi1iafo9ljflprqds
 * thumper pokes the local provider with a long stick to see if it moves
 * thumper opens up the beast again for more surgery
<wallyworld> fwereade_: google does hate you
<wallyworld> fwereade_: so, some remaining issues. i thought it best to keep the notion of managing the container dependencies out of the provisioner - those are separate concerns to me. the model is: wait until a container type is required, ensure stuff is set up, then start the provisioner to manage the creation of the containers
<fwereade_> wallyworld, I'm +1 on that
<wallyworld> so, the initial watcher does then kill itself once it has done that job
<fwereade_> wallyworld, what you have does a solid job of starting the appropriate provisioner at the appropriate time
<thumper> um...
<wallyworld> cause it has served its purpose
<thumper> do we have an initial watcher for each type of container?
<wallyworld> yes, but only because the api only allows that
<wallyworld> the api needs to change
<fwereade_> wallyworld, I'm just saying that the setup bit is not implemented
<wallyworld> and that involves uknown unknowns
<wallyworld> fwereade_: it is in a downstream mp
<wallyworld> the next one in the pipe
<wallyworld> fwereade_: https://codereview.appspot.com/22980045/
 * thumper fetches the paddles to shock the local provider back to life
<thumper> CLEAR
<wallyworld> lol
<wallyworld> fwereade_: so, each container package is responsible for knowing how to set itself up so containers of that type can be started on a given host. the machine agent calls out when required to do that and then starts a suitable provisioner. i still want to get the hammer out and fix the provisioner task as previously discussed
<wallyworld> my main goal this week is to get kvm supported with what apis we currently have
<wallyworld> once that user facing functionailty is delivered, then we can tweak the behind the scenes things to clean it up
 * thumper wondered why the local provider wasn't starting the machine
<thumper> network traffic is spiking
<thumper> last line in the log file
<thumper> 2013-11-18 22:44:33 DEBUG juju.container.kvm container.go:32 Synchronise images for precise amd64
<wallyworld> thumper: we need user feedback on that shit :-)
<thumper> wallyworld: not sure how...
<wallyworld> to eliminate the wondering
<wallyworld> we need to establish a channel back to the client
<wallyworld> and the service business logic can pop progress events into that channel
<thumper> machine provisioning failed...
<thumper> now to figure out why
<fwereade> wallyworld, everything to do with computers hates me
<fwereade> wallyworld, thanks for that link though
<fwereade> wallyworld, for some reason it makes it all look less objectionable
<fwereade> wallyworld, do you think there's a reasonable evolution that lets us drop all the frickin' switching though?
<wallyworld> fwereade: one sec.  otp
<fwereade> wallyworld, because I'm still feeling that if we're going to be lazy we should be really lazy
<fwereade> wallyworld, install the packages only when we're actually trying to run a container and find missing deps
<fwereade> wallyworld, separating out the thing that takes the decision on whether to start a provisioner is a great step
<fwereade> wallyworld, so that is a win in itself, no argument there
<fwereade> wallyworld, but smearing the specific-container-related logic out so widely stresses me out a little, because it introduces subtle dependencies
 * thumper sighs
 * thumper pulls apart the threads looking for the issue
 * thumper opens the patient up again
<fwereade> wallyworld, I am cool with the watcher strategy though
<wallyworld> fwereade: sorry, just about finished phone cll, one more sec
<fwereade> wallyworld, and while I would love to have further discussions about SOA I am flagging a little -- so I'm off for a quick ciggie, then a short chat before bed
<wallyworld> ok, ill read you r comments while you kill your lungs
 * thumper frowns
<wallyworld> fwereade: we do only install packages when the first container is needed to be run, so we are really lazy
<fwereade> wallyworld, they're still twitching a bit
<wallyworld> all the container logic is in one place - the containers package. the agent (for setup) provisioner task (for running) calls into that
<fwereade> wallyworld, but codewise the actual invocation of the setup has a very tenuous and distant connection to the actual launching of the container
<wallyworld> set up and launching are separate
<wallyworld> you could use the same argument when we used cloud init
<fwereade> wallyworld, how about if we jammed the setup bits it into broker creation? that feels much closer
<wallyworld> eg just efore this branch
<wallyworld> we always apt-get installed lxc in cloud init
<wallyworld> which is the lxc container set up
<fwereade> wallyworld, indeed I could :)
<wallyworld> that is very distant
<wallyworld> now, all related container logic is at least together
<wallyworld> and the worker task that uses it can call into it
<fwereade> wallyworld, I'm certainly not defending that practice -- it was expedient but rather hairy really
<fwereade> wallyworld, and it caused us problems ;p
<fwereade> wallyworld, I agree it's closer now, and better than before
<wallyworld> the containers package exposes 2 main sematics - setup and management
<wallyworld> and the task uses those 2 main concenpts
<wallyworld> by management, i mean runtime - start/stop etc
 * thumper falls foul to wallyworld's hack on debug levels
<wallyworld> i *think* we have separate of concerns ok, if not heading in the right direction
<fwereade> wallyworld, it just seems reasonable that (say) broker creation be a decent signal implying the need for setup, ratherthan having broker creation either sane or not depending on the action of distant code
<wallyworld> fwereade: so that implies there's some flag somewhere which records if setup has been done
<fwereade> thumper, heh, I thought that'd cause trouble, but I couldn't think of anything better and you were on holiday
<fwereade> thumper, if you're of a mind to fix it please correspond with davecheney, whose use cases we were trying to support
<fwereade> wallyworld, it's definitely going in the right direction
 * thumper nods
<wallyworld> thumper: i did tell you about it and the need to fix it :-)
<thumper> wallyworld: yeah I know
<thumper> I just hadn't gotten around to it
<fwereade> wallyworld, I'm just complaining because it feels like almost virgin soil, and that we could get further
 * thumper puts it on the stack of shit to fix
<wallyworld> i know, just pressing buttons :-P
<fwereade> wallyworld, however, I remind myself, progress not perfection :)
<fwereade> wallyworld, and as I said I'm pretty happy with how it looks in the context of the followup
<wallyworld> fwereade: understood. the way i see it - we have container setup and management "nicely" packaged. we have stuff that calls it. we can adjust the stuff that calls it
<thumper> heh, oops, found a weirdness...
<wallyworld> fwereade: if you wanted to +1, or +1 with fixes, i can do that today
<fwereade> wallyworld, yeah, I'm just rereading my whining
<wallyworld> lol
<wallyworld> thanks for staying up late todo this
<fwereade> wallyworld, don't suppose I can convince you of a SetSupportedContainers call? I'd still prefer that to the mooted result from UpdateSC
<fwereade> wallyworld, that's the only bit that still feels really wrong, and isn't amenable to easy fixes by virtue of being part of the api
<wallyworld> fwereade: actually, in the current branch, i think i'm going to have to go to that api anyway, at least at the service level
<fwereade> wallyworld, sweet :)
<wallyworld> fwereade: so i did the Add api in isolation
<wallyworld> and then as the implementation has evolved, it needs to be changed i think
<wallyworld> so i could kand what's there, and it will be reworked in my current branch
<wallyworld> fwereade: thanks for +1. i am fully aware it's not yet perfect, but is a step along the way :-)
<wallyworld> and we are delivering new functionality to users
<fwereade> wallyworld, no worries -- and my concern about the Set/Add bit is that if 1.17 goes out with Add it will be waaay more tedious to make Set work without ugliness
<fwereade> wallyworld, so if you're confident that can be proposed today I can handle it
<wallyworld> yeah. i was thinking with Add, we would be less immune to races
<wallyworld> cause i wasn't sure if we would have multiple callers each adding their own
<wallyworld> and add is more robust to that
<fwereade> wallyworld, I'm not so bothered about those, because I feel we can restrict it to a single caller quite naturally
<wallyworld> but i think callling Set will be limited to machine agent at start up
<fwereade> wallyworld, yeah
<wallyworld> that wasn't clear at the time initially
<fwereade> understood :0
<wallyworld> thanks again, go get some sleep :-)
<fwereade> wallyworld, cheers, enjoy your day
<wallyworld> i'll try :-)
 * thumper is stonewalled by kvm tools
 * thumper needs to email robie to get answers
<thumper> perhaps I'll look at the logging stuff while I wait
<wallyworld> thumper: or you could do this for me :-D https://codereview.appspot.com/28190043/
 * thumper goes to have lunch first
#juju-dev 2013-11-19
<axw> davecheney: how does the GUI know to hide NRPE relationships?
<axw> NRPE-to-Nagios I mean
<davecheney> subs are not shown
<davecheney> thye are just a little marker on the sevice
<davecheney> when you hover over them
<davecheney> the links from the subs to their 'provides' peers are shown
<rick_h_> heh, I work on the gui and didn't realize that was updated. I know there's some upcoming work for making relations show better though
<rick_h_> just had to go try it out in jujucharms.com and see
<davecheney> :)
<rick_h_> there's been a lot of talk of 'visualization layers' though. one day
<axw> cool
<axw> hmm, I don't find the nrpe hover thing very intuitive
<wallyworld> thumper: that test you didn't like needs to be in one method because it's testing multiple operations with some succeeding and others failing. i'll see if i can make it clearer by adding comments or whatever
<wallyworld> since it's a bulk api, there's no point testing one machine at a time
<thumper> it's been a shit day for getting things done
 * thumper back later to talk to robie
<hazmat> i just had to do something fairly dirty for removing  ghost machines.. direct db surgery.. fwiw, http://paste.ubuntu.com/6441072/
<hazmat> should be unesc come 1.16.4 with terminate-machine --force
<davecheney> hazmat: bad news
<davecheney> that feature won't make it into 1.16.4
<davecheney> it breaks upgrades
<davecheney> so sinzui told me
<hazmat> davecheney,  that seems odd, re garbage cleanup breaking upgrades.. haven't looked at fwereade's patch for it though.
<davecheney> hazmat: something about the fix relies on an api call which is not present in 1.16.3
<hazmat> ah
<rogpeppe> mornin' all
<jam> morning rogpeppe
<jam> rogpeppe: I never did get your email
<jam> let me check my spam folder just in case
<rogpeppe> jam: oh, hmm
<rogpeppe> jam: weird, looks like i never sent it
<rogpeppe> jam: sent now
<jam> nope, not there either :)
<rogpeppe> jam: you should get it in a mo
<jam> got it
<rogpeppe> jam: cool. dunno how that happened...
<jam> rogpeppe: its a big graph :)
<rogpeppe> jam: yeah
<jam> its interesting to see the simple ones off to the right, and the really big convoluted mess on the left
<rogpeppe> jam: yeah
<rogpeppe> jam: note how all the stuff on the left comes in through the API (the reflect.Call right at the top)
<jam> yep
<jam> handleRequest
<TheMue> rogpeppe: thx for your review yesterday evening
<rogpeppe> jam: note: when you see =0x[0-9a-f]+, that's when there's only a single value for that parameter in all the calls
<rogpeppe> jam: otherwise the count is the number of distinct values for that parameter
<rogpeppe> TheMue: np
<jam> rogpeppe: "sync.runtime_Semacquire" with 14642 callers and 4922 distinct values
<jam> I'm curious how that works
<jam> I would have thought you'd have, like 1 lock object they were blocking on
<rogpeppe> jam: i think it is, mostly - it's probably to do with the implementation of semacquire
<jam> rogpeppe: well on the other hand if you had different objects talking about something similar, I would expect 14,000 different values
<rogpeppe> jam: i'm also interested in the big sync.Mutex.Lock called by sync.RWMutex.Lock
<jam> I'm curious that we would have some ratio there
<jam> rogpeppe: that's the acquireSocket call
<jam> which is "I want to ask Mongo something, let me have the socket to write to it"
<rogpeppe> jam: the former has 4196 different values but the latter has only one
<jam> hmmm.. why would we be calling RLock, though
<jam> I would have thought we would need the WLock
<jam> "acquireSocket" says "Read-only lock to check for previously reserved socket"
<rogpeppe> jam: well, there are 9720 blocked on the same semaphore
<jam> I haven't found 9720 yet
<jam> but I do see 8478 calling sync.RLock
<jam> and 6159 calling sync.Lock
<jam> and the former has only 1 object
<jam> the latter has 4916 objects
<jam> so yeah, probably it is just that we have a couple different things going on, some of which are on a shared lock, some are on distributed locks
<jam> I'm guessing the results from a mgo query
<jam> are blocked on a sync lock
<jam> unique to that queury
<jam> query
<jam> given SimpleQuery is blocked on 4916 different locks
<jam> while acquireSocket is 2866 calls blocked on 1 object
<jam> and the other 5612 calls from Find
<jam> blocked on that same object
<rogpeppe> jam: 14642 -  4922 = 9720
<jam> rogpeppe: I think you're numbers are actually a bit wrong. 8478 are blocked on the same one, 4 are blocked on one side, and 4916 are blocked on unique objects
<jam> specifically, acquireSocket and Find both use a session.m mutex to handle global state stuff
<jam> session.queryConfig AFAICT
<jam> and s.masterSocket
<jam> rogpeppe: so if a bunch ofthings are blocked on a sync.RWMutex.RLock doesn't that mean that something else has the Lock of that object?
<jam> otherwise the RLocks are mutually compatible, right?
<rogpeppe> jam: yup
<rogpeppe> jam: the RLock seems to be just to get the default query parameters
<jam> rogpeppe: so in Find yes, in acquireSocket it is to get the masterSocket
<jam> which then has its own Lock
<jam> rogpeppe: right, so SimpleQuery has N locks (each call creates a new mutex which will be unlocked when the replyFunc gets the response from mongo
<rogpeppe> jam: looks like the whole thing is blocked trying to write to the mongo socket
<jam> rogpeppe: well all of those are blocked waiting for response
<jam> responses
<jam> they should have already written their requests
<jam> rogpeppe: *lots* of things are blocked on the global session lock. Which all *should* be using RLocks, but something is taking out the other lock
<rogpeppe> jam: look at the 1-wide trail coming out of mongoSocket.Query
<rogpeppe> jam: leading to tls.Conn.Write
<rogpeppe> jam: and eventually to net.netFD.Write
<rogpeppe> jam: i think it's likely that's the path that actually has the lock
<rogpeppe> jam: hmm, mind you, the write lock should not block the readers
<jam> rogpeppe: a write lock does block read locks
<jam> I thihnk
<jam> think
<jam> since it is saynig "I'm changing the data you want to read"
<rogpeppe> jam: no, sorry, i meant something different there
<jam> rogpeppe: but the lock in mongoSocket.Query should be the mongoSocket mutex *not* the Session mutex
<rogpeppe> jam: i meant the lock on the io.Writer shouldn't block the io.Readers
<jam> rogpeppe: so digging around mgo/session.go I don't see many code paths that take the session.m.Lock
<jam> Login does
<jam> and Clone
<rogpeppe> jam: and indeed mongoSocket.readLoop is blocked on tls.Conn.Read as expected
<jam> rogpeppe: sure, I'd expect that, but it doesn't explain why the Session.m is write Locked blocking all the acquireSocket and Find calls
<rogpeppe> jam: there are quite a few Clones around
<jam> rogpeppe: session.Clone
<jam> there is only one going via sync.RWMutex.Lock
<jam> ah, nm, there are 1136 of them
<jam> probably only 1 of them is trying to execute
<rogpeppe> jam: that doesn't feel quite right - if one was executing, it wouldn't be in Lock, i think
<jam> maybe
<rogpeppe> jam: except fleetingly
<jam> so if you look at Clone, and then follow it down to sync.RWMutex.Lock
<jam> you'll notice that all of them are called with the same object
<jam> and 1135 of them are stuck in sync.*Mutex.Lock
<jam> and *1* of them is in sync.runtime_Semacquire
<jam> well, directly vs indirectly
<rogpeppe> jam: so perhaps that's just spinning fast
<jam> rogpeppe: yeah, its possible, it does have 1136 Lock requests to chew through and another 8478 RLock requests concurrently
<jam> rogpeppe: so it *looks* like our transaction logic is requiring a Clone which requires a write Lock on the session object
<jam> runTransaction leads down into mgo.Query.Apply which ends up at session.Clone
<rogpeppe> jam: yeah, i don't know what Query.Apply does
<rogpeppe> jam: ah: 	session.SetMode(Strong, false)
<rogpeppe> jam: that's why it does the Clone
<jam> rogpeppe: what I'm getting out of this is that the txn logic gums up a lot of the internals :)
<jam> we have 3307 calls to state.runTransaction
<jam> mostly from SetAgentVersion calls
<jam> which *do* write to the DB
<rogpeppe> jam: it's what i expected
<jam> so a unit agent coming up does a bunch of writes
<rogpeppe> jam: the txn stuff is marvellously inefficient
<jam> SetPrivateAddress, SetPublicAddress, SetAgentVersion are the big ones
<jam> rogpeppe: you know what would be interesting, being able to poll runtime.Stack and generate this graph "live"
<jam> and watch it evolve
<rogpeppe> jam: i've been thinking about this, yes
<rogpeppe> jam: the question is how to relate two graphs in the sequence
<rogpeppe> jam: because the layout may be very different
<jam> rogpeppe: I *think* you can see something like dot with existing locations
<jam> but yeah, it doesn't guarantee they'll stay put (AFAIK)
<jam> morning fwereade
<rogpeppe> jam: but it would not be hard to make an api call to get the current stack
<fwereade> jam, heyhey
<rogpeppe> jam: (or the summary of the current stack, which would incur considerably less network traffic)
<rogpeppe> fwereade: hiya
<jam> rogpeppe: I would probably just grab the stack and dump it out to a local place/socket/whatever and have that process do the CPU work of collapsing it
<rogpeppe> jam: just make the API call locally
<rogpeppe> jam: or perhaps from another adjacent machine, so the processing doesn't mess too much with progress
<fwereade> hey rogpeppe
<axw> jam: https://codereview.appspot.com/28270043/ updated to use agent.conf; a bit less awkward now, I think.
<dimitern> fwereade, rogpeppe: poke from yesterday :) https://codereview.appspot.com/21940044/ - upgrade-juju + api
<rogpeppe> dimitern: will look after i've finished looking at axw's
<axw> thanks rogpeppe
<dimitern> rogpeppe, cheers
<rogpeppe> axw: could you remind me why we need configurable agent and mongo service names?
<axw> rogpeppe: local provider, so different users can each have an environment on the same machine
<rogpeppe> axw: ah right.
<rogpeppe> axw: i guess we could just put the uuid in there
<axw> rogpeppe: tho ideally, they'd go into user-level upstart jobs
<rogpeppe> axw: but that's a bigger change
<axw> rogpeppe: true, could do that across the board
<rogpeppe> axw: that would be better still
<axw> an even bigger change ;)
<rogpeppe> axw: (and not possible currently AFAIK)
<axw> yeah, I don't know the status of that
<rogpeppe> axw: reviewed
<axw> ta
<axw> rogpeppe: yeah, I started down the road of len(errors)==1 (actually a switch), but it started getting ugly
<rogpeppe> axw: yeah.
<axw> the error message will only go into the machine log anyway.
<rogpeppe> axw: true 'nuff
 * rogpeppe sometimes wonders about a MultiError type
<axw> heh, I did consider it :)
<axw> didn't feel like burdening this CL with a one-size-fits all error list
<wallyworld> fwereade: hi, don't feel obliged to look unless you are interested - these follow on from our conversations https://codereview.appspot.com/28790043/ https://codereview.appspot.com/28890043/
<fwereade> wallyworld, thanks, I *might* get to them before the standup
<wallyworld> no hurry or obligation
 * rogpeppe reboots, sigh.
<jam> mgz: rogpeppe, natefinch standup? https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<jam> wallyworld: ^
<jam> dimitern: I understand William's concern about an API that goes unused almost immediately, but I think we'd still have a "tell me what tools you can find" API, and then follow that with a maybe-upload, and then a "now set your Agent Version", so we still need the api
<dimitern> jam, sounds reasonable
<dimitern> jam, except that the actual tools selection for the upgrade will happen in the command still
<jam> dimitern: https://codereview.appspot.com/21940044/ reviewed
<dimitern> jam, ta
<mattyw> rogpeppe, fwereade I've got a cl for you to take a quick look at: https://codereview.appspot.com/28970043. (it's better to ask forgiveness than permission)
<fwereade> mattyw, LGTM
<fwereade> mattyw, actually
<fwereade> mattyw, would you copy the addresses slice instead of returning the internal one?
<mattyw> fwereade, sorry - I'm not sure I understand
<fwereade> mattyw, allocate a new slice of the same type/size, copy the contents, return the fresh one
<fwereade> mattyw, lest a client alter the returned slice and mess with the config's internals
<mattyw> fwereade, isn't []string a value anyway?
<rogpeppe> mattyw: a slice is a reference type
<fwereade> mattyw, slices are references -- http://play.golang.org/
<rogpeppe> mattyw: the slice itself is like a struct containing a pointer to the underlying array, the length and the capacity
<mattyw> rogpeppe, fwereade sorry - just reading go-slices and internals and realised - thanks - I'll sort it out
<fwereade> mattyw, no worries, easy to miss
<mattyw> rogpeppe, oh yes - of course, I probably have to be reminded of that every week ;)
<rogpeppe> mattyw: that said, i don't care too much in this instance; the config isn't an immutable type. still, probably best to copy to avoid unexpected behaviour
<rogpeppe> trivial code move review anyone? https://codereview.appspot.com/28980043
<rogpeppe> fwereade, jam, dimitern: ^
<mgz> fwereade seems to have reviewed it alreadyu
<mgz> rogpeppe: seems good to be as well though
<dimitern> rogpeppe, reviewed
<mattyw> rogpeppe, I've updated https://codereview.appspot.com/28970043. I'm afraid I didn't notice your comment until I'd pushed the change for fwereade's comment so the delta from patch set might be a bit mixed up -but it's hopefully small enough a change to not matter
<rogpeppe> mattyw: reviewed
<rogpeppe> fwereade: looking at AssignToNewMachineOrContainer, it seems to me that the logic isn't quite right when there are several clean machines
<fwereade> rogpeppe, oh yes?
<rogpeppe> fwereade: at the end of that function, it seems to assume that because the machine it tried to choose isn't now clean, that there are no clean machines
<rogpeppe> fwereade: but i think it should probably just recurse into AssignToNewMachineOrContainer or something like that
<rogpeppe> fwereade: i.e. look for another clean machine
<adeuring> rogpeppe: a trivial MP: https://codereview.appspot.com/29000043
<rogpeppe> adeuring: looking
<adeuring> thanks!
<rogpeppe> adeuring: LGTM
<rogpeppe> adeuring: thanks
<fwereade> rogpeppe, yeah, we should probably iterate through the clean machines, well soptted
<adeuring> rogpeppe: thanks!
<TheMue> rogpeppe: https://codereview.appspot.com/24040044/ is in again after handling your review
<rogpeppe> fwereade: i don't think we can just iterate through the clean machines
<rogpeppe> fwereade: because a new clean machine might be created during the iteration
<TheMue> rogpeppe: there's still an open question regarding the passing of timeouts from the clients to the apiserver
<rogpeppe> TheMue: looking
<TheMue> rogpeppe: thx
<fwereade> rogpeppe, I'm not too bothered by that case -- isn't that always a possibility? any time we decide there aren't any clean machines and create a new one, a sufficiently annoying and precise demon could create a new clean machine and say "why didn't you use that? lol u idiots"
<rogpeppe> fwereade: true enough
<fwereade> rogpeppe, in practice I think we'd need a whole bunch of clean machines for the iteration to take a long time *and* for all of those to be sniped *and* for a new clean one to be created in that window, which probably isn't *that* wideopen in the first place
<rogpeppe> fwereade: i've been sporadically tempted to fact out the unit machine-assigning stuff to addmachine.go too, BTW, but i keep swithering
<rogpeppe> s/fact/factor/
<fwereade> rogpeppe, yeah, AssignToNewMachine is definitely related, the rest is a bit less clear
<rogpeppe> fwereade: another thing i just noticed: the logic inside the "if machineIdSpec != """ test inside juju.Conn.AddUnits really looks as if it should be living inside state - do you concur?
<fwereade> rogpeppe, not immediately clear to me, anyway -- expand?
<fwereade> rogpeppe, in particular handling lxc:3 inside state seems like it's definitely a bad idea
<fwereade> rogpeppe, the "lxc:" ought to be handled by something more like an environ (ok, a pseudo-environ backed by state, but still)
<rogpeppe> TheMue: you've got a review
<TheMue> rogpeppe: ta
<rogpeppe> fwereade: sorry, only just saw your remarks
<rogpeppe> fwereade: thinking
<rogpeppe> fwereade: why does state need to be ignorant of the lxc:3 syntax?
<rogpeppe> fwereade: i'm probably just ignorant of the underlying rationale behind that syntax
<rogpeppe> fwereade: and where it sits in the set of juju abstractions
<fwereade> rogpeppe, the name we've been using is "placement directives"
<fwereade> rogpeppe, provider-specific languages for instance locations
<rogpeppe> fwereade: I'm having conceptual difficulties reconciling lxc:3 with ec2:us-east-1c.
<rogpeppe> fwereade: The former is saying "an lxc container within machine 3" AFAICS and the latter "the us-east1c region within the ec2 provider".
<rogpeppe> fwereade: The container/contained relationship seems to be different in each one.
<rogpeppe> fwereade: Is there a nice way of thinking about these things?
<fwereade> rogpeppe, consider lxc a provider -- something that gives you new instances
<fwereade> rogpeppe, the domain it has access to happens to be the set of machines already in the environment
 * rogpeppe twists his brain
<rogpeppe> fwereade: also, wondering why lxc:3:lxc:2  is equivalent to lxc:3/lxc/2
<rogpeppe> fwereade: or if it is - i may well be missing something
<fwereade> rogpeppe, if there's a lxc:3:lxc:2 in there that's just a mistake I think
<rogpeppe> fwereade: i'm looking at this line: mid = strings.Join(specParts[1:], "/")
<fwereade> rogpeppe, lxc:3/lxc/2 would be "a new lxc container inside 3/lxc/2"
<fwereade> rogpeppe, <provider>:<directive>
<fwereade> rogpeppe, where the lxc provider accepts machine ids as directives
<rogpeppe> fwereade: but it splits the whole thing on ":" then joins it again on "/"
<rogpeppe> fwereade: so AFAICS lxc:3:lxc:2 will be transformed into lxc:3/lxc/2
<rogpeppe> fwereade: perhaps it's not deliberate
<fwereade> rogpeppe, I suspect it's just an oversight
<rogpeppe> fwereade: ok
<fwereade> rogpeppe, in general the plan is to extract the bit before the first colon and hand the bits after the colon off to the provider unchanged
<fwereade> rogpeppe, good catch, thank you
<rogpeppe> fwereade: ah, i think they probably just want to SplitN
<fwereade> rogpeppe, +1
<natefinch> wow, I just noticed mongo's replset flag is actually replSet (capital S).... who uses camelcase in their command line flags? :/
<mattyw> rogpeppe, is there a way I can get the name of the current envname for passing to juju.NewAPIClientFromName?
<rogpeppe> fwereade: still looking at Conn.AddUnits, getting closer to why I thought some of it at least should live in state, what's to stop the newly added machine (the AddMachineWithConstraints line) being grabbed by some random other service with a container=lxc constraint?
<rogpeppe> mattyw: just pass ""
<mattyw> rogpeppe, that uses the defauly - all sorts of craziness happens if I use juju switch
<rogpeppe> mattyw: ah, i see
<rogpeppe> mattyw: what's the context?
<fwereade> rogpeppe, nothing, I've always hated all that stuff :(
<fwereade> rogpeppe, I think I'm with you on the non-lxc: bits being better off as single txns
<rogpeppe> fwereade: i'd hoped to get away without touching this stuff
<fwereade> rogpeppe, sadly the state of state is such that changes almost invariably involve fixes as well
<rogpeppe> mattyw: i think we probably want to factor out the juju switch logic somewhere
<rogpeppe> fwereade: most of the dubious stuff is relatively recent :-(
<fwereade> rogpeppe, but I don't think that particular stuff is in scope -- pre-existing bugs shouldn't pull you out of your way unless fixing them actually helps you
<fwereade> rogpeppe, the add-unit/add-machine stuff was always a problem, and I'm sure the machine-sniping problem always existed too
<fwereade> rogpeppe, the current arrangement of the code maybe brings the problems into clearer focus
<rogpeppe> fwereade: the --to and containers stuff has added a great deal of difficult-to-reason-about code
<rogpeppe> fwereade: at least, i find it hard to reason about :-)
<fwereade> rogpeppe, but the real problem is that we've never really had a coherent state model for machines, and so we built on a shaky foundation without firming it up underneath us
<fwereade> rogpeppe, yay pressure
<rogpeppe> fwereade: yeah
<rogpeppe> mattyw: i think we probably want a DefaultEnvironName function inside juju
<rogpeppe> mattyw: inside the juju package, that is
<fwereade> rogpeppe, mattyw: hmm, I don't think we should be talking about environs' names at all inside state -- except where we really cannot help it
<fwereade> rogpeppe, mattyw: and those should always be for historical reasons
<rogpeppe> fwereade: so how do you think an external command that calls NewAPIClientFromName should work?
<rogpeppe> fwereade: given that it wants to respect the usual conventions for finding an environment
<rogpeppe> fwereade: JUJU_ENV, switch value
<fwereade> rogpeppe, mattyw: ok, I misread somehow, because I am an idiot
<fwereade> rogpeppe, mattyw: I'd been thinking of Conn as something server-side
<fwereade> rogpeppe, mattyw: and think of juju as primarily there for the Conn
<fwereade> rogpeppe, mattyw: client-side that's fine... I guess the juju package itself should just be split up at somepoint
<rogpeppe> fwereade: what part of the juju package isn't intended for client side?
<fwereade> rogpeppe, Conn?
<rogpeppe> fwereade: that's definitely client-side, isn't it?
<rogpeppe> fwereade: ah, except that it's used by the API these days
<fwereade> rogpeppe, that state+environ combo is most certainly not ;p
<fwereade> rogpeppe, once, indeed, it was
<fwereade> rogpeppe, but, eh, different bits evolve at different rates and things end up in surprising places
<rogpeppe> fwereade: you're right - it should be again
<rogpeppe> fwereade: the client api has really taken on the role of juju now
<fwereade> rogpeppe, yeah
<rogpeppe> fwereade: the state-connection stuff should probably be moved somewhere under apiserver
 * rogpeppe grabs some lunch
<mattyw> rogpeppe, fwereade for now it looks like I can use cmd.ReadCurrentEnvironment() to solve my issue
<rogpeppe> mattyw: that doesn't respect $JUJU_ENV, unfortunately
<mattyw> rogpeppe, I don't seeme to have JUJU_ENV set on my machine - where does that come from?
<rogpeppe> mattyw: you don't need it set, but it's an optional thing
<rogpeppe> mattyw: it overrides juju switch
<mattyw> rogpeppe, but I can do if os.Getenv("JUJU_ENV") == "" { envName := cmd.ReadCurrentEnv() } ?
<mattyw> rogpeppe, I guess what you're saying is all of that logic should be put somewhere in juju?
<natefinch> rogpeppe: so I'm trying to write tests and I realized that we have testing.mgo ... but it's all set up to be a single instance of mongo.  Seems like it should be refactored to allow N instances... probably by just making it all methods on a type rather than package level functions.  What do you think?
<rogpeppe> natefinch: i was wondering when you'd come up against that issue...
<rogpeppe> natefinch: (sorry for slow response - my irc client is declining to run my notification script again)
<natefinch> rogpeppe: no big deal.  Was getting lunch anyway
<rogpeppe> natefinch: i agree, although to save churn perhaps we should keep the existing entry points the same, but as a thin layer on top of the multiple-mongo layer
<rogpeppe> natefinch: perhaps a testing/mongo package?
<natefinch> rogpeppe: yeah, that's doable, though I could refactor the current file without modifying the existing entry points.  Either way is fine.
<rogpeppe> natefinch: go with whatever you feel like.
<rogpeppe> natefinch, fwereade: trivial code review BTW: https://codereview.appspot.com/29130043/
<natefinch> rogpeppe: I can get it.  I have been slacking in the review dept
<natefinch> rogpeppe: ahh yeah, this is what you guys were talking about earlier
<rogpeppe> natefinch: yeah
<natefinch> rogpeppe: I wish that machine id parsing code were broken out into its own function
<natefinch> rogpeppe: would be a lot easier to test in isolation
<rogpeppe> natefinch: it's not really machine id parsing
<rogpeppe> natefinch: but yes, i agree
<natefinch> rogpeppe: right, sorry, bad choice of words
<rogpeppe> natefinch: but i'm not fixing everything now
<natefinch> rogpeppe: now is the best time to fix everything ;)    Well, not everything.  But little things, sure.  Anyway, LGTM.
<jcastro> any core devs joining in the juju sessions at UDS?
<jcastro> http://summit.ubuntu.com/uds-1311/meeting/22011/t-cloud-juju-destroy-machines-by-default/
<natefinch> jcastro - I can join
<jcastro> https://plus.google.com/hangouts/_/7acpimg327ft0ld2qto6rnffgk?authuser=0&hl=en
<rogpeppe> jcastro: sorry, if i'd seen your msg above, i'd have joined
<rogpeppe> jcastro: to my shame, i didn't know about this at all
<jcastro> rogpeppe, ok I can post a reminder
<natefinch> jcastro: thanks... I didn't know about it either.
<jcastro> There is a juju-core update for trusty tomorrow that we'll need some of you guys for
<jcastro> mainly a "what's coming in 14.04" kind of thing
<rogpeppe> jcastro: interesting discussion
<rogpeppe> jcastro: i think my view would be: if we created the machine automatically, we should destroy it automatically.
 * jcastro nods
<rogpeppe> jcastro: but if you used add-machine explicitly, i'm not sure we should
<natefinch> rogpeppe: honestly, add-machine doesn't really fit the way juju is supposed to work anyway.
<rogpeppe> natefinch: but that's the way it does work, and we have to, um, work with that
<jcastro> hah, we have add-machine?
<jcastro> never needed it
<natefinch> rogpeppe: commands can be removed as easily as they're added.  More easily, even.  But even if not... I'd hate to see add-machine causing more complexity percolating through the system.
<natefinch> jcastro: exactly. There
<natefinch> jcastro: there's very little need for it
<jcastro> yeah, if I need a new machine it's `juju deploy ubuntu`
<mattyw> rogpeppe, you still there?
<rogpeppe> mattyw: i am
<rogpeppe> mattyw: (lucky i saw your msg - my irc client has stopped notifying me again dammit)
<rogpeppe> mattyw: what's up bro?
<mattyw> rogpeppe, can I be a pain and ask for another look at https://codereview.appspot.com/28970043/?
<rogpeppe> mattyw: np
<mattyw> rogpeppe, thanks - you sure you didn't turn of notifications ;)
<rogpeppe> mattyw: in general if i say LGTM i mean you can make the change and submit
<rogpeppe> mattyw: yeah, unfortunately so
<mattyw> rogpeppe, I thought that was probably the case - but part of my contract says to keep rogpeppe 100% happy though
<rogpeppe> mattyw: i don't use the magic acronym if i don't mean it :-)
<rogpeppe> mattyw: aw
<rogpeppe> mattyw: LGTM says "i'm happy"
<mattyw> rogpeppe, you cheated though - you said LGTM with a tiny simplification
<mattyw> wanted to make sure you were happy with the simplification
<rogpeppe> mattyw: given that it's exactly what i suggested (apart from that mistake i made), i should hope so :-)
<mattyw> rogpeppe, sweet
<mattyw> I don't have permission to mark it approved - I guess someone else will pick that up
<rogpeppe> mattyw: i'll approve it
<mattyw> rogpeppe, thanks - another question then while I've distracted you
<rogpeppe> mattyw: done
<mattyw> thanks
<rogpeppe> mattyw: go on
<rogpeppe> mattyw: make it quick - i just saw the car arrive back and i'll need to go and have supper...
<mattyw> on 1.16 - when I'm "WatchingAll" throught the api and I call add-unit, i seem to get updates about all the state changes for the new unit - then after the new unit gets to started I see another update about the existing unit
<mattyw> rogpeppe, you can go
<mattyw> we can talk about this tomorrow
<rogpeppe> mattyw: ok, ping me
<mattyw> and I'll work out some proper details and some pastes
<rogpeppe> mattyw: cool.
<mattyw> rogpeppe, enjoy supper
<rogpeppe> mattyw: see ya tomoz
<rogpeppe> g'night all
<mattyw> night
<thumper> morning
<natefinch> thumper: morning
<thumper> hi natefinch
<thumper> reading your experiences with high res desktops :)
<natefinch> thumper: haha... the answer is "you're gonna have to wait".... which I think is pretty bad.
<thumper> well...
<thumper> hangout?
<thumper> there are a few things you could try
<thumper> natefinch: https://plus.google.com/hangouts/_/76cpi5uan67mdgbaass8rvt83o?hl=en
<thumper> gah...
<thumper> I need to fix syslog for the local provider
 * thumper pokes rsyslog with a stick
 * thumper cringes inside
<sidnei> thumper: please do!
<sidnei> thumper: actually, that's something i wanted to bring up
<thumper> :)
<sidnei> thumper: because the local provider pokes into lxc rootfs, but with lvm the container root is not under rootfs
<sidnei> so that's a blocker for me
 * thumper nods
<thumper> I've got kvm machines working with my local provider
<thumper> but it has no mounting like lxc
<thumper> so I need to get the log files out
<thumper> however...
<thumper> I'm trying to work out how we can have a general juju local rsyslog conf file
<thumper> so we don't block the non-sudo bootstrap that may happen later
<thumper> since we need sudo to add the rsyslog conf and restart the rsyslog service
<thumper> although I guess you could do the horrible bit of encoding sudo into the command running
<thumper> not sure how that would work though
<thumper> but anyway,
<thumper> I suppose I could fix the syslog bit independently
<thumper> ugh...
<thumper> multiple local environments would be a pain
<thumper> I have that now
<thumper> I have "local" and "local-kvm"
<thumper> both running
<thumper> but we'd need to filter syslog messages nicely
<thumper> can do this with some syslog tags
<thumper> but needing multiple filenames...
<thumper> etc
<thumper> the problem there is the line: UDPServerRun 514
<thumper> so perhaps...
<thumper> we'd have to move the rsyslog port into config...
<thumper> ick
<sidnei> thumper: multiple rsyslog processes running under the user with different ports? inject the port config via cloudinit?
<thumper> sure, that isn't the problem
<thumper> and I guess, this is only a value that the user needs to change if they want multiple local jujus running
<thumper> but it is just the whole "need to put it into config" that makes me go ugh
<thumper> but easy enough to add
<thumper> I am also very concious that the logging is a single point of failure
 * thumper considers briefly making rsyslog put logging messages into a real db that we can spread around...
 * thumper sighs
#juju-dev 2013-11-20
 * thumper takes a deep breath
 * thumper dives into local provider syslog
 * thumper shakes his head
 * thumper sighs
 * thumper thinks...
<axw> what'cha doing thumper?
<thumper> axw: trying to make the syslog udp port configurable
<thumper> all done for the machines
<thumper> but the deployer is a problem
<thumper> as we need api calls to work it out
<thumper> then I notice that the deployer makes multiple api calls instead of just one specialist call
<thumper> trying to work out how far to go with this...
<thumper> the State address calls methods are icky
<thumper> since we ask for Addresses and APIAddresses, we get the environment config twice
<thumper> since I also want to get the SyslogPort from config
<thumper> that would be another
<thumper> ideally we should just have one call...
<thumper> I don't want to shave the whole yak
<axw> heh
<thumper> we are incredibly inefficient in the calls
<thumper> but it is way less than the network lag
<thumper> so noone cares
<thumper> aargghh...
<thumper> stabby stabby
<thumper> state/address.go:103 c.f. :89
 * thumper sighs
 * thumper gets out the mega-razor with the number one clip
<axw> thumper: I'm looking at finishing off synchronous bootstrap, specifically the cancellation behaviour
<axw> I'm thinking of modifying the Environ interface to be like this: http://paste.ubuntu.com/6446222/
<axw> does that look sensible?
 * thumper looks
<axw> the returned function will do the synchronous bit, and cmd/juju will install a signal handler to tomb.Kill
<thumper> so the finalisation function is to call back to kill the environment instance
<axw> no, it's to SSH to the machine and install the agent
<axw> but it takes a tomb so it can be cancelled
<axw> thumper: I made it a callback so the signal handling can be in the CLI
<thumper> ok, I think
<thumper> yeah, seems ok to me
<axw> okey dokey, will plough ahead - ta
<thumper> well, that is the hind quarters shaved
<thumper> I should stop shaving
 * thumper is reminded yet again how terrible our cloudinit tests are
<thumper> I'm almost prepared to pay someone to fix these tests
<thumper> fark
 * thumper has a nearly hairless yak
<thumper> wow...
<thumper> that "simple" refactoring is: 25 files changed, 194 insertions(+), 58 deletions(-), total diff size of 846 lines
<thumper> and that is before I start what the branch needs
 * thumper creates another pipe
 * thumper takes a breath again and tries to work out what the original aim was before the hairy yak raised its ugly head
 * thumper goes swimming
<wallyworld> thumper: how close are you to pushing a kvm broker implementation?
<thumper> wallyworld: FWIW, I was able to deploy ubuntu to a local kvm environment
<thumper> but no logging
<wallyworld> \o/
<thumper> so I need to fix that
<wallyworld> ok, just checking
<thumper> wallyworld: a day or two
<wallyworld> i have a branch ready to plug into that
 * thumper nods
<wallyworld> ie the NewKvmBroker() is a place holder
<thumper> :)
<wallyworld> and just now pushed a ranch to clean up provisioner
<thumper> coolio
 * thumper has swimming coaching in 15 minutes, so I need to get a move on
<thumper> ciao
<wallyworld> later
<jam> mgz: poke
 * fwereade is experiencing some intestinal discomfort and is going to lie down for a bit
<TheMue> fwereade: get well soon
<jam> fwereade: rest well, feel better
<rogpeppe1> rebooting
<jam> standup time: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<jam> fwereade: (if you're feeling better) ^^
<jam> mgz, TheMue, rogpeppe, dimitern: ^^
<jamespage> hey juju devs - I'm seeing this issue in one of the QA labs:
<jamespage> https://bugs.launchpad.net/juju-core/+bug/1178312
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<jamespage> whenever I bootstrap a server
<jam> jamespage: have you set "ssl-hostname-verification: false" in your env config ?
<jamespage> jam: makes no difference - its a verification failure between the juju client and mongodb
<jam> jamespage: so do you actually match the description of "you have an outdated .pem on a second machine from the one that did the actual bootstrap" ?
<jamespage> jam: no this is all on a single client endpoint
<jam> if you're doing a fresh bootstrap and it still fails, then it isn't exactly that bug
<jam> though we might have another one
<jamespage> jam: probably a new bug then
<jam> you *might* have a local ".pem" file that is actually invalid
<jamespage> jam: where do I find those?
<jam> jamespage: it would be in ~/.juju/$ENVNAME.pem I believe. New versions of Juju put the cert contents into the $ENVNAME.jenv file
<jam> but I *think* it tries to use a .pem if it already existed
<jam> I would have thought you couldn't bootstrap if you had an invalid one, but there have been weirder things
<jam> jamespage: a pastebin of the output of "juju bootstrap --debug && juju status --debug" might be helpful
<jam> jamespage: for example, is someone trying to hijack your connection and redirecting you do another machine, or running HTTP on a HTTPS port etc
<jamespage> jam; http://paste.ubuntu.com/6447597/
<jamespage> jam: and http://paste.ubuntu.com/6447604/
<jamespage> jam: I could see stuff in the .jenv
<jamespage> so I scrubbed .juju/environments and re-tried - same problem
<jamespage> jam: I can see the client connections being rejected by mongod on the bootstrap node once its up
<jamespage> (i.e. I can ssh to it)
<jam> jamespage: can you paste the /var/log/cloud-init-output.log
<jam> and possibly /var/log/juju/machine-0.log
<jamespage> jam:sure - can do
<jam> and if we're being complete /var/lib/juju/**/agent.conf (i think it is /var/lib/juju/agents/machine-0/agent.conf but I'm not positive)
<jam> jamespage: This is a little bit concerning: 2013-11-20 11:09:15 DEBUG juju.environs.configstore disk.go:77 Making /var/lib/jenkins/.juju/environments 2013-11-20 11:09:15 INFO juju.environs open.go:156 environment info already exists; using New not Prepare 2013-11-20 11:09:15 DEBUG juju.provider.maas environprovider.go:33 opening environment "maas".
<jam> "Using New not Prepare"
<jam> I'm guessing that is because you have to sync-tools first?
<rogpeppe> jam: ~/.juju/$ENVNAME.pem is no longer used AFAIK
<rogpeppe> jam: it's all kept in the .jenv file now
<jam> rogpeppe: I realize we don't create it, but I thought we might use it if it existed
<jam> as part of the migration strategy
<jam> rogpeppe: as in, if it exists, we'll put it into the .jenv when we create it
<jamespage> jam: http://paste.ubuntu.com/6447635/
<rogpeppe> jam: hmm, yes we probably do, if there's no .jenv file
<jamespage> cloud-init-output
<jam> jamespage: so I think I can get what I was looking for from cloud-init. Maybe the .jenv next (unless you've already nuked it)
<rogpeppe> jamespage: i understand the issue here - we should do a better job of knowing when to retry a connection
<jam> rogpeppe: well the problem is that we just bootstrapped and then failed
<jam> to do status
<rogpeppe> jam: from a different machine, right?
<jam> rogpeppe: no, from the same machine
<jamespage> jam: http://paste.ubuntu.com/6447662/
<jamespage> jenv
<jam> as in "juju bootstrap && juju status" => bad TLS cert
<rogpeppe> jamespage: ah, ok, i'm looking at bug #1178312 - is that not what we're talking about here?
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<jamespage> rogpeppe, I thought so but it appears not
<jam> rogpeppe: so bug #1178312 is about "I bootstrapped again and now other people can't talk to it because the cert doesn't match"
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<jam> rogpeppe: *but* I think james has a different bug which is "I bootstrapped, and I can't connect to the thing I just started"
<rogpeppe> jam: if that's the case, that definitely is a bug
<jam> jamespage: so if I decode the data in cloud-init-output.log it *doesn't* match the data in your .jenv file
<jamespage> jam: well that sucks :-)
<jam> jamespage: you're sure this is a matching "destroy-environment" into "bootstrap" into "status" ?
<jam> If you just nuke the file and bootstrap again, it may fail to bootstrap but still generate a new cert, etc.
<jamespage> jam: cloud-init-output and jenv definately match
 * rogpeppe wishes that certificates were encoded in opaque asn1 format
<rogpeppe> s/were/were no/
<rogpeppe> t
<jamespage> http://paste.ubuntu.com/6447671/
<jamespage> thats status
<jamespage> the bootstrap was already OK
<jam> jamespage: "was already ok" ?
<jamespage> jam: I'd given you the output of the environment I just boostrapped already
<jam> jamespage: if you nuked ~/.juju/environments/* then we don't have the cert recorded anymore
<jamespage> jam: no - that was prior to this run through
<jam> jamespage: k, so you nuked it, then ran bootstrap and status
<jamespage> yup
<rogpeppe> i agree with jam - the cert and private key in the cloudinit output don't seem to match the .jenv contents
<rogpeppe> jamespage: you didn't just check the first few lines, did you?
<jamespage> OK - lemme teardown, scrub and do it again
<jam> rogpeppe: but does it match the stateserver key or does it match the cacert key
<jam> I'm checking that one
<rogpeppe> jam: the certificate should be the same in both cases, i think
<jam> rogpeppe: I thought we had a CA key that then generated other keys for all the agents
<jam> regardless something funny
<rogpeppe> jam: we do, but i'm just looking at the certificate which signs that key
<jam> because .jenv(ca-cert) matches the first ~5 lines of cloud-init-output cacert.decode('base64')
<jam> but they *don't* match the remaining lines
<jam> which seems surprising
<rogpeppe> jam: i mean which is signed by that key, i guess
<rogpeppe> jam: the first 5 lines are boilerplate
<rogpeppe> jam: the actual rsa key comes later on in the cert data
<rogpeppe> jam: that's why it would be nice to have human-readable certs...
<jamespage> jam, rogpeppe: http://paste.ubuntu.com/6447700/
<jamespage> bootstrap-jenv-status - all appear to be a consistent key
<rogpeppe> jamespage: so is it working now?
<jamespage> just waiting for the bootstrap unit to startup
<jamespage> (its is maas on physical hardware)
<jam> rogpeppe: well, I can load it into python and OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cacert)) but I'm not sure that helps much :)
<rogpeppe> jam: i've used openssl before, i think
<jam> rogpeppe: I just mean I can get it into a parsed form, but I'm not really sure what to do from there
<rogpeppe> jam: dump it out as text...
<rogpeppe> jam: it would be really nice if we generated the env uuid client-side and encoded in the certificate somewhere
<jamespage> wtf - now its working
<rogpeppe> jam: here's the textual form of the cert, BTW: http://paste.ubuntu.com/6447718/
<jamespage> the bootstrap node landed on a different machine
<jamespage> wonder if we have something wonky in DNS/DHCP world
<rogpeppe> jamespage: i have a faint suspicion as to what might have been going on for you
<rogpeppe> jamespage: or... maybe not :-)
<rogpeppe> jamespage: if you really were trying to talk to the wrong machine, then everything was working as designed.
<rogpeppe> jamespage: except that it would be nice to have some better error messages
<jamespage> rogpeppe, I don't think that was the case
<jamespage> all of the other servers in the lab are powered off apart from the bootstrap node
<rogpeppe> jamespage: that's a fair indication :-)
<rogpeppe> jamespage: so, i suspect that you accidentally bootstrapped twice
<rogpeppe> jamespage: each bootstrap generates its own CA cert
<rogpeppe> jamespage: if you wipe ~/.juju/environments, it can't know that it's a bad idea to try to bootstrap again
<rogpeppe> jamespage: (if a .jenv file already exists, it won't recreate CA cert, BTW)
<jamespage> sure
<jamespage> maybe
<jamespage> lets see
<jam> rogpeppe: but if you actually wiped it, then it wouldn't know what machine was started earlier, and it would either (a) look up the provider-state to see if it already existed or (b) generate a new control bucket which means it would bootstrap another machine)
 * jamespage runs the full test cycle again
<rogpeppe> jamespage: it would look up the provider-state, which in this case would have the old machine, right?
<rogpeppe> s/jamespage/jam/
<jamespage> phew
<jamespage> :-)
<rogpeppe> jam: which makes me think that it would be good to keep the env uuid in the provider state for sanity checking
<rogpeppe> jam: not that we can do that currently, of course
<jam> rogpeppe: but *bootstrap* would fail with "already bootstrapped" not succeed and just have generated new cruft
<jam> rogpeppe: I have no problem with the sanity checks.
<rogpeppe> jam: it would, yes, but if you ignored that error message and typed "juju status", wouldn't you get the symptoms we've seen above?
<jam> rogpeppe: and certainly for bug #1178312 we should notice that it is a TLS error (not a failed to connect but a I didn't get what I thought would be there) and die immediately rather than retrying
<_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <config> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
<jam> rogpeppe: you would if james hadn't already pasted the bootstrap output without a failure message
<rogpeppe> jam: which also comes back to: if we've generated a .jenv file when bootstrapping, and the bootstrap fails, we should remove the .jenv file
<jam> rogpeppe: the original bootstrap: http://paste.ubuntu.com/6447604/
<jam> rogpeppe: I'm a little concerned about: juju.provider.maas environ.go:193 picked arbitrary tools
<jam> but that shouldn't affect anything with mongo
<rogpeppe> jam: presumably that's not the *original* bootstrap, otherwise there wouldn't have been a .jenv file already there
<jam> rogpeppe: so to follow the conversation, james had done one in the past, then nuked it and deleted everything from ~/.juju/environments then did it again, and the bootstrap + status + cloud-init-output (etc) were all from that pristine try
<jamespage> urg - its back
<rogpeppe> jamespage: you've got the same problem again?
<jamespage> juju/maas picked a different node (the one that it picked earlier) and I get this issue
<jam> jamespage: how are you killing the system ?
<jam> with "juju destroy-environment" /
<jam> ?
<jamespage> yes
<rogpeppe> jam: there's actually something useful we can determine from the certs - we can find out when the cert was created
<jam> jamespage: so if all of this is fresh, the contents of cloud-init-output.log and .jenv give us enough info to see if they are actually not matching.
<rogpeppe> jamespage: ok, so, from scratch now: could you paste the contents of the .jenv file and the contents of the cloud-init-output log file on the bootstrap node, please?
<jam> preferably in the same paste so we don't get confused later :)
<jamespage> http://paste.ubuntu.com/6447758/
<jamespage> jenv
<jamespage> cloud-init-output: http://paste.ubuntu.com/6447759/
<jamespage> jam, rogpeppe: all yours ^^
<rogpeppe> jamespage: the bootstrap node was bootstrapped on the 8th november
<rogpeppe> jamespage: it has not just been created
<rogpeppe> jamespage: i guess that means that destroy-environment has not destroyed it correctly
<TheMue> rogpeppe: any chance to take a quick look on https://codereview.appspot.com/24040044/
<TheMue> ?
<rogpeppe> jamespage: which is, i suppose, only to be expected, because we're using the new metadata to try to destroy the old environment
<jamespage> urgh - OK - lemme go check wtf is going on
<jamespage> its being powercycled but it looks like its not being re-isntalled
<rogpeppe> jam: would it be a terrible security hole if we allowed unauthenticated access to an API to find out its uuid?
<jam> rogpeppe: the clietn would still have to allow a TLS connection to a machine it doesn't recognize
<rogpeppe> jam: not necessarily
<rogpeppe> jam: we could allow http access for just that info
<rogpeppe> jam: although... https and http are on different ports, aren't they?
<rogpeppe> jam: or, actually, it's just a client-side thing isn't it?
<jam> so I think you can technically do both on the same port, but it is really hard to do
<jam> because https is just TLS and raw HTTP underneath
<jam> and I *think* the server inits the TLs data
<rogpeppe> jam: we could just provide a UUID method alongside Login, and the client could fall back to trying https allowing any cert to make a decent error message
<jam> rogpeppe: well, we can assume that the UUID is wrong if the TLS cert doesn't match
<jam> I don't think reporting a UUID actually helps *users*
<jam> as they don't know WTF
<jam> it is
<rogpeppe> jam: well, if the TLS cert doesn't match, it may be because someone's trying to break in, i suppose
<jam> rogpeppe: if they can break in, then unauthenticated UUID isn't going to help us
<rogpeppe> jam: another possibility is that the client could look at the certificate presented by the server and use it to tell the user when the environment was bootstrapped
<rogpeppe> jam: that's probably more useful
<rogpeppe> jam: but i do think that env uuids will become more useful (and recognised) as time goes on and multi-environment setups become more common.
<jam> rogpeppe: it is still a UUID which means random hex bytes
<jam> not "my environment named X"
<jam> I think env name + timestamp might make way more sense to the user
<rogpeppe> jam: we have to think carefully about the role of environment names
<rogpeppe> jam: currently there's nothing stopping an environment having different names for different clients, i think
<rogpeppe> jam: s/for/when used by/
<rogpeppe> jam: currently an environment certificate does include the name that the environment was given, but that's by no means unique
<jam> rogpeppe: sure, but it isn't quite about uniqueness, it is about giving them something that they can understand
<jam> and UUID is not that
<jam> they can lookup a UUID somewhere, and kind-sorta-squint to see if it looks like this other one
<jam> but it doesn't have *meaning*
<rogpeppe> jam: i'm concerned it might be misleading
<rogpeppe> jam: for example, if i send someone a .jenv file and they store it as "foo.jenv" but the original bootstrapper named it "bar.jenv", the messages will print "bar" but the user would expect "foo"
<rogpeppe> jam: because that's their local name for the environment
<jam> rogpeppe: if you send it to them, it has a name already
<jam> so "yes" with a big "but not really"
<rogpeppe> jam: depends how you send it to them
<jam> rogpeppe: 90% of all ways involve a filename  (yes you could paste it somewher)
<rogpeppe> jam: yeah, i was thinking pastebin
<rogpeppe> jam: and i might *need* to rename it - for example, if you sent me an "ec2.jenv", i'd need to rename it so it didn't clash with my own env of that name
<rogpeppe> jam: i think this may tie in with user auth stuff
<rogpeppe> jam: for instance, if the name was "john meinel's ec2", that would be more useful
 * TheMue => lunch
<bac> hi jam, i have some questions about juju local's use of mongo.  do you know much about how it works?
<jam> bac: I know a bit at least
<jam> what's up?
<adeuring> rogpeppe: could please you have a look here: https://codereview.appspot.com/29680043 ?
<jam> adeuring: I reviewed it already
<jam> though you're welcome to ask for another
<bac> jam i see it creates /etc/init/juju-db-bac-blah.  is that supposed to be removed when the environment is destroyed?
<bac> jam i ask b/c it lingered and upon reboot prevented my *real* /etc/init/mongdb.conf from launching the mongo i need for other work
<adeuring> jam: thanks, that was fast.-- should haved looked at the page first ;)
<jam> bac: I believe so. I know axw__ has been doing some work in that area.
<jam> adeuring: I just happened to see the email come in
<bac> jam: if that mongo instance is ephemeral, why put entries in /etc/init?
<jam> bac: because it isn't
<jam> bac:  that is the central DB talking about all of the instances you have on your machine
<jam> if you reboot, it is supposed to come up again
<bac> jam, ah, ok
<bac> jam, well it needs to play nice with real mongo
<bac> jam, now that i understand more i can file a better bug.  thank you.
<jam> bac: so you can certainly file a bug that we shouldn't be setting something in /etc/default/mongodb. We *do* it because everywhere but local that machine isn't running a mongo otherwise
<jam> and installing the mongodb-server automaticlaly starts an instance we won't use
<jam> without that line
<jam> bac: I believe the fix is to have juju depend on a "juju-db" package which is mongo without the default instance
<jam> bac: you can poke jamespage for more details there
<bac> jam, i don't thing /etc/default/mongodb is the problem but the /etc/init/juju-db-<user> one
<jam> bac: we write "don't start" to /etc/default/mongodb when we create ours
<bac> jam: a good bug report is descriptive not prescriptive so i'll leave the solution to y'all.  :)
<bac> (or so preaches bigjools)
<jamespage> jam, bac: yeah - not done that yet
<jam> jamespage: but you agree on the proposed "how it should be fixed" ?
<jam> (we stop writing to /etc/default/mongodb, but depend on a different package)
<jamespage> jam: broadley yes
<jamespage> binary only package +1
<jam> bac: so even if we do/don't remove that file, you need to fix /etc/default/mongodb
<jam> if you want an actual Mongo running
<jam> they *can* coexist, but we have the problem that on "normal" nodes we were starting 2 processes and only wanted 1
<jam> but that does impact a local test when you actually do want the other one to run
<bac> jam, i have not /etc/default/mongodb.
<bac> jam the problem i see is /etc/init/juju-db starts before /etc/init/mongodb and the latter sees an instance running and does nothing
<bac> s/have not/have no
<jam> jamespage,bac: ok, so this is slightly different. I know we do write /etc/default/mongodb but that *might* only be triggered in non-local.
<jam> jamespage: the issue bac is pointing to is that the default /etc/init/mongodb just uses 'start-stop-daemon'
<jam> which seems like it just does a ps to see if anything named "mongodb" is running
<jam> and doesn't notice that the one that is running is using a different config
<jamespage> hmm
<rogpeppe> bac: i'm slightly surprised that /etc/init/mongodb sees an instance running - how does it know that?
<jamespage> that sucks a bit
<bac> jam, jamespage: bug 1253084 files.  please augment as needed.
<_mup_> Bug #1253084: local use of mongo prevents default mongodb from starting <juju-core:New> <https://launchpad.net/bugs/1253084>
<rogpeppe> jamespage: ah, i see
<rogpeppe> s/jamespage/jam/ !
<jam> rogpeppe: right "man start-stop-daemon"
<rogpeppe> jam: that sounds like definite crack to me
<jam> rogpeppe: it works well if you have things controlled by one file and really want just one running
<rogpeppe> jam: if /etc/init/mongodb will only work properly if there's no other mongodb started anywhere, then we have a problem
<jam> jamespage: so if we called the binary only thing /usr/bin/jujudb we would get aroud that, but I 'm not sure that is great, either
<jamespage> jam: its fixable
<rogpeppe> why is /etc/init/mongodb using start-stop-daemon anyway?
<rogpeppe> it *is* the daemon... or should be
<jam> rogpeppe: cause its a shortcut for doing that sort of thing
<jam> it handles the pid file, etc.
<jam> rogpeppe: it is "/etc/init/mongodb.conf" which isn't a daemon
<rogpeppe> jam: it bypasses all the nice namespacing that upstart gives you
<jam> rogpeppe: I can imagine it was because someone ported an /etc/init.d scripte
<jam> script
<rogpeppe> jam: sounds very plausible
<rogpeppe> jam: i suppose what i mean is that upstart should be the one keeping track of started processes and daemons.
<jam> rogpeppe: sounds like, but I think jamespage would know best here
<jamespage> rogpeppe, yup
<rogpeppe> jamespage: that /etc/init/mongodb uses start-stop-daemon seems pretty much like a straight-up bug to me
<jamespage> the fix is a hack - you just tell start-stop-daemon to look for a process name that will never exist
<jamespage> rogpeppe, that is not
<jamespage> a bug
<jam> jamespage: that doesn't prevent it from double starting, does it?
<jamespage> upstart manages the process via start-stop-daemon just fine
<jam> so if you did "start mongodb; start mongodb" you'd end up with 2 of them ?
<jamespage> all its doing is changing the uid
<jamespage> (unlike the juju mongodb which just runs as root :-))
<jamespage> jam: ^^ that will get picked up in the MIR work this cycle
<jam> jamespage: k. Because juju mongodb doesn't need root (AFAICT)
<jamespage> yup
<jamespage> I think I raised that bug :-)
<jam> jujud probably does
<jamespage> agreed
<jamespage> that's OK tho
<jcastro> http://summit.ubuntu.com/uds-1311/2013-11-20/
<jcastro> rogpeppe, or fwereade ^^^
<jcastro> we have a session in 2 hours
<rogpeppe> jcastro: "juju code dev update" ?
<jcastro> yeah basically what users can expect for 14.04
<rogpeppe> jcastro: fwereade has a better bird's eye view than me at this point
<jam> jamespage: so there isn't a way to ask upstart to change the UID ?
<rogpeppe> jamespage: so could mongodb.conf just use sudo -u mongodb /usr/bin/mongodb ... ?
<jamespage> rogpeppe, that is exceptionally bad as it starts a user session
<jamespage> (try shutting down a desktop when you do that)
<jam> rogpeppe: http://superuser.com/questions/213416/running-upstart-jobs-as-unprivileged-users
<jam> new versions can use "setuid"
<jamespage> jam: there is bit globally for the configuration
<rogpeppe> jamespage: no way to avoid that?
<jam> but maybe we need to still support P?
<jamespage> so you can do mkdir -p /var/lib/mongodb in pre-start
<jam> (which it does)
<jcastro> fwereade, are you available in 2 hours?
<rogpeppe> jcastro: he wasn't too well earlier. i'm ok doing it if he can't make it.
<rogpeppe> jcastro: or perhaps jam might want to
<jcastro> I don't care who it is as long as they can just talk about juju
<jcastro> jam is fine! :)
<jam> rogpeppe: jcastro: its pretty late for me
<fwereade> jcastro, rogpeppe: well, I just crawled up to tell people I wasn't likely to come back today
<jcastro> ok
<rogpeppe> fwereade: np
<jcastro> is there anyone available?
<rogpeppe> fwereade: could you maybe link me to our current roadmap document, if there is one?
<rogpeppe> fwereade: i'm not quite sure what's likely to get in 14.04 currently
<fwereade> rogpeppe, I'm pulling all that back together into something resembling sanity but it's not currently a oc
<jam> jcastro: so the ones you want someone are for 16:05 UTC and 18:05UTC, except there are 2 Juju ones at 18:05 (I guess one is GUI)
<fwereade> rogpeppe, I will give you the overview
<rogpeppe> fwereade: thanks
<jam> rogpeppe: there is also https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0At5cjYKYHu9odDJTenFhOGE2OE16SERZajE5XzZlRVE&usp=drive_web#gid=0
<jam> which isn't 100% up to date, but can give some hints
<jam> rogpeppe: the one at 18:05 looks more like a jamespage one
<jam> "what do we need to do to get Juju into main"
<jam> http://summit.ubuntu.com/uds-1311/meeting/22112/juju-core-development-update/ looks like a summary of what is going on
<natefinch> jam, rogpeppe, fwereade: I'm also available to go to meetings, since they're more in my time zone
<rogpeppe> jamespage, jam: ISTM that another and slightly easier fix to /etc/init/mongodb.conf would be to pass "-u mongodb" to start-stop-daemon
<jamespage> rogpeppe, "--name mongodb-server" will also work as no process will ever be named mongodb-server
<jamespage> which avoids problems if someone wants to run multiple mongod processes under the mongodb user
<rogpeppe> jamespage: it's not clear to me how --exec interacts with --name interacts with --start
<jcsackett> sinzui, abentley: can one of you look at https://code.launchpad.net/~jcsackett/charmworld/better-sparklines/+merge/195972 when you have time?
<abentley> jcsackett: looking
<jcsackett> abentley: thanks
<abentley> jcsackett: r=me.
<jcsackett> abentley: thanks!
<rogpeppe> jcsackett: have you got a hangout link?
<rogpeppe> oops
<rogpeppe> s/jsackett/jcastro/
<rogpeppe> jcastro: ^
<jcsackett> :-P
<jcsackett> happens all the time. :-)
<rogpeppe> jcsackett: i can see why
<jcastro> sec
<jcastro> https://plus.google.com/hangouts/_/7ecpjmodidvjime8kk2kb7s28k?authuser=0&hl=en
<jcastro> rogpeppe, he's the good looking one
<jam> good job rogpeppe
<rogpeppe> jam: thanks. did i sound reasonably coherent?
<jam> yeah
<jam> I felt you did well
<rogpeppe> jam: phew :-)
<jamespage> who from the juju-dev team is attending the Juju activities for 14.04 session starting shortly?
<natefinch> jamespage: I can attend
<jamespage> excellent
<jamespage> #ubuntu-uds-servercloud-1
<rogpeppe> g'night all
<natefinch> night roger
<sinzui> natefinch, I think Bug #1057665 is fix committed in trunk
<_mup_> Bug #1057665: juju destroy-environment is terrifying; please provide an option to neuter it <canonical-webops> <destroy-environment> <pyjuju:Fix Committed by hazmat> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1057665>
<jam> sinzui: it depends how you interpret that bug. I think they are actually asking for a sort of "termination protection" so that you can't just destroy-environment it
<jam> we do make it slightly better by requiring you to name it
<jam> we could spin off another bug about termination protection
<sinzui> jam, I agree with what is being asked for, but my understanding was that we decided on an argument change
<sinzui> jam, why are you awake?
<jam> it isn't midnight here yet
<jam> 30 min to go
<sinzui> natefinch, jam, I need to decide if the bug is fix committed, or deferred to the next milestone.
<sinzui> moving it to the next is easy
<jam> sinzui: I'm fine closing that one, but I'd like to capture the thought about a second command
<jam> whether we *do* that one we can decide later
<sinzui> jam, do you know if Bug #1236691 is really In Progress?
<_mup_> Bug #1236691: null provider bootstrap fails if default-series does not match target <ssh-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1236691>
<jam> I think axw was looking at it
<jam> but it shouldn't block the release if it doesn't land
<sinzui> thank you
<jam> sinzui: have a good night
 * jam heads to bed
<sinzui> goodnight
<natefinch> sinzui: hey, I stepped out for a bit.  Sounds like you and jam figured it out, though
<natefinch> sinzui: in my opinion, the change I made addresses the problem they stated they had.  I didn't implement their solution to the problem, but that's a different story, as jam said.  I think the feature they proposed is interesting, but problematic to implement, and therefore seems unlikely to be implemented any time soon, with the priorities and manpower we have right now.
<sinzui> natefinch, I agree. I prefer bugs reports to state the problem, not prescribe a solution. The later is almost always a unique feature. While the former, is easily grouped and duped to form a solution
<natefinch> sinzui: yep, exactly
<thumper> o/
<natefinch> thumper: howdy
<thumper> hey
<natefinch> thumper: do you know if the mouse pointer will resize along with the font setting?  I haven't rebooted since I changed the font setting, so it might not have gotten applied... but that's one thing that is surprisingly annoying on the high res screen - trying to find and use a really tiny pointer.
<thumper> IIRC the mouse pointer is special, and drawn by the graphics driver, most likely fixed size
<natefinch> thumper: boo.  I looked for an accessibility thing for that and also failed... hoped there'd be a "bigger mouse pointer for people with bad eyesight" but no luck
<hazmat> is there api support yet for deploy ... more specifically charm upload?
<hazmat> hmm..
<hazmat> conn.PutCharm
<natefinch> hazmat: https://blueprints.launchpad.net/juju-core/+spec/t-cloud-juju-cli-api
<natefinch> says dimiter is working on deploy
<thumper> HA!
<thumper> I think I found the bug where the local provider doesn't start properly
<thumper> just encountered it.
 * thumper adds it to the FIX IT stack
<hazmat> natefinch, thanks
<natefinch> hazmat: no problem
<natefinch> gah... mgo refuses to dial into mongo if I pass it --replSet ... mongo sees the connection and then the connection is immediately dropped.  Sigh.  Gotta figure out what's going on in mgo.
<natefinch> ... but not today.   later all
<davecheney> sinzui: ping
<davecheney> you were going to send me details on the jenkins setup
<davecheney> <gentle:reminder/>
<sinzui> yep
<davecheney> sinzui: ta muchly
#juju-dev 2013-11-21
<thumper> fark!!!!
<thumper> rsyslog is fiddly
<axw> indeed, and the config format is arcane
<thumper> hmm...
<thumper> I think I broke something
<thumper> a bugger
<thumper> ugh
<thumper> copy and paste error
 * thumper does the destroy, make, bootstrap dance
<axw> make?
<axw> oh, you use make to build?
<thumper> make install
<thumper> just does: go install ./...
<thumper> but easier to type
<thumper> make check does: go test ./...
<thumper> axw: so... when is debug-log going to use the API
<thumper> axw: I have a feeling we need this backchannel that wallyworld keeps talking about
<axw> thumper: it uses it now for getting the SSH address, but I guess that's not what you mean :)
<thumper> axw: so the api server looks at all-machines.log and filters, streaming info back to the client
<thumper> right
<axw> yeah, I don't know - still slogging through destroy-env atm
<thumper> axw: when we get it working properly streaming data over the api, then it'll work with the local provider
<axw> what back channel?
<thumper> I'm getting all-machines.log working for local
<thumper> there isn't one
<thumper> but we should have one
<axw> sorry, what does that mean in this context?
<thumper> it means we could get meaningful informational stuff back to the user
<thumper> probably easier to explain in a hangout :)
<axw> sure
<thumper> \o/
<thumper> it works
<thumper> IT'S ALIVE!!!1!11!!
<axw> :)
<axw> hangout now, or are you busy atm?
<thumper> what a fucking mission that has been
<thumper> about to go and make a coffee and have a quick sit-down with Rache
<thumper> l
<thumper> but I'll be back after that
<axw> okey dokey
<thumper> and we can chat
<axw> sounds good, ttyl
<thumper> I could also talk you through these two branches I'll propose
<axw> cool
<thumper> one to make the rsyslog udp port configurable
<thumper> and the other to get the local provider to use rsyslog and all-machines.log
<thumper> I've also changed the output, so instead of just %HOSTNAME%, we get things like 'machine-1' and 'unit-ubuntu-0'
 * thumper goes for a bit
 * thumper goes to fix all the broken tests...
<thumper> dumb script checking in cloudinit
<axw> thumper: is there a reason why we don't delete the bootstrap state file if bootstrap fails?
<thumper> um... because we might be 'kinda set up' ??
<axw> hmm I guess. it does stop the instance if it screws up (it's easier to tell that it failed once it's synchronous)
<thumper> local provider isn't as good, but could be made so
<thumper> axw: hangout?
<axw> sure, just a mo
<axw> thumper: https://plus.google.com/hangouts/_/76cpiq5hco79gtjcr755e8jsok?authuser=1&hl=en
 * thumper is happy that he has figured out some live kvm tests
 * thumper is done for now, back for the team meeting
<axw_> fwereade: hiya. TheMue reviewed my state changes for environment Life, but I thought I'd better wait for you since you reviewed the parent branch
<axw_> when you have some moments: https://codereview.appspot.com/28880043/
<dimitern> morning all
<TheMue> axw_: using the uuid check for the id looks better now, thanks
<axw_> TheMue: cool, thanks for the review
<axw_> morning dimitern
<TheMue> morning
<rogpeppe> mornin' all
<axw_> morning rogpeppe
<jam> morning
<jam> well, afternoon :)
<mgz> mornin'
<jam> morning mgz
<jam> mgz: did you see the recent discussion about maintaining compat?
<mgz> the API thread on the list?
<jam> mgz: yeah, abentley reasonably pointed out that Status is something we probably want multi-version compatible
<jam> so don't be too hasty to tear out the client side code yet
<mgz> I didn't fully understand his point
<jam> mgz: for CLI API changes that require us to add a new API, we'd like to keep the old code around in the 1.18 client in case it connects to a 1.16 server that doesn't have the new API
<mgz> but, I guess that goes for one upgrade step only? we need to remove the mongo access in two stages
<jam> mgz: right. I'm not 100% sure if we want a 1.16 client to be able to do status on a 1.18 but maybe
<fwereade> jam, mgz: I really don't think we can avoid it
<fwereade> jam, mgz: 2-way compatibility for minor+2 was always the plan
<fwereade> jam, mgz: it's just something that we seem to repeatedly fuck up
<fwereade> jam, mgz: and ofc once we hit 2.0 we need compatibilty all the way back to 2.0 until 3.0 (and even that needs compat back to the final 2.x, I think)
<jam> fwereade: so I know that we didn't do it for several commands so far (I don't know them offhand, but juju destroy-machine --force comes to mind :)
<fwereade> jam, indeed so, I definitely fucked that up for 1.16.4 -- but it actually just turned out to be early warning of the same fuckup for 1.18
<fwereade> jam, casual glance indicates that we've just been doing straight replacement with no fallbacks across the board
<jam> fwereade: that has definitely been the pattern. I did bring it up to you before
<jam> it was fine for all the ones that didn't need a new API
<jam> but the others are all incompatible
<fwereade> jam, well, fuck, I'm sorry -- I don't recall that, and if I told you to do something stupid then that's all on me
<jam> fwereade: weekly standup, btw
<jam> TheMue: are you coming to the standup?
<TheMue> jam: oh, yep, forgot that it is now, sorry
<jam> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.09gvki7lhmlucq76s2d0lns804
<jam> TheMue: ^^
<jamespage> can anyone help me with the impact and test case for https://bugs.launchpad.net/juju-core/+bug/1239508
<_mup_> Bug #1239508: Empty constraint value lost during some cloud-init step <cloud-init> <juju-core:Fix Committed by thumper> <juju-core 1.16:Fix Released by thumper> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):New> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1239508>
<jamespage> (working the SRU for saucy/1.16.3)
<thumper> committed by me?
 * thumper looks
<thumper> jamespage: look at my comment, I marked it as invalid
<thumper> jamespage: the bug is erroneous
<thumper> I filed it, but the bug itself is wrong
<thumper> the fundamental problem was the local provider wasn't starting
<thumper> and I thought that this was the problem
<thumper> but it wasn't
<jamespage> thumper, ah - ok
<thumper> the problem was that the startup process was changed
<jamespage> thumper, I thought that was the case but I was not sure
<jamespage> thanks
<thumper> meaning that the local provider needed to set up the storage earlier
<thumper> hence the branch connected to that bug just has a "setup bootstrap storage" method
<thumper> np
<jamespage> OK - uploaded for SRU team review - lets see how this goes
<jamespage> MRE soonish if this goes all OK
<jamespage> ehw, ^^
<ehw> jamespage: \o/
<jamespage> fwereade, who's a good person to talk to about what juju-core is doing CI wise?
<jamespage> I need to evidence sufficient upstream testing as part of the Minor Release Exception we need for Ubuntu
<jam> jamespage: sinzui and abentley seem to be driving that
<jam> jamespage: I'm the one that set up the trunk robot for passing the test suite before landing to truk
<jam> trunk
<jamespage> jam: unit testing right? or does that exercise with each provider directly?
<jam> jamespage: it tests each provider against its double, but not against a live service
<jam> (eg, not against Amazon)
<jam> testing against Amazon is on Curtis's team
<jamespage> jam: does the robot cover unit testing pre-landing for stable branches as well?
<jam> jamespage: currently es
<jam> yes
<sinzui> Ci tests the candidate works on LXC, AWS, HP, Azure, and Canonistack. It also nominally tests  stable to next are compatible
<jam> so 1.16 passes the test suite before accepting patches, etc
<jamespage> thumper, sinzui: I marked bug 1239508 as invalid all round - I got confused so figured others would as well
<_mup_> Bug #1239508: Empty constraint value lost during some cloud-init step <cloud-init> <juju-core:Invalid by thumper> <juju-core 1.16:Invalid by thumper> <juju-core (Ubuntu):Invalid> <juju-core (Ubuntu Saucy):Invalid> <juju-core (Ubuntu Trusty):Invalid> <https://launchpad.net/bugs/1239508>
<sinzui> jamespage, Ci also verifies the tarball works with Ubuntu packaging. We are verifying the package upgrade (and downgrade)
<jamespage> sinzui, is this publically visible somewhere
<jamespage> useful for my email to the tech board
<sinzui> visible, but the results are not very intelligible at http://162.213.34.53:8080/
<sinzui> jamespage, I just drafted this as a the kind of report we want managers and engineers to see https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoY1kjOB7rrcdEl3dWl0NUM3RzE2dXFxcGxwbVZtUFE#gid=0
<dimitern> g+ kicked me out for some reason and I can't reconnect
<fwereade> dimitern, not to worry, we'renearly deon
 * fwereade can has typing? apparently not
<dimitern> fwereade, sticky keyboard? :)
<natefinch> TheMue: forgot to mention. your package shipped, Monday, I believe, so it should be there sometime in the next 3-30 days :)
<TheMue> natefinch: fantastic, have to thank you
<natefinch> TheMue: it's no problem :)
<TheMue> natefinch: will be paid at least with one (or some more) beer
<natefinch> TheMue: bring some coffee, I'm not a big beer guy :)
<TheMue> natefinch: yeah, already thought so. will do ;)
<arosales> thumper, http://newraycom.com/how-to-set-up-google-hangout-lower-third/
<thumper> arosales: cheers
 * thumper goes to bed
<jam> sinzui: I set up a 1.17.1 milestone, for things that I know we need before we can do a 1.18.0 final release.
<jam> sinzui: is that a reasonable way to do it ?
<sinzui> +1
<jam> axw_: poke if you're still around
<jam> I think the summary for https://bugs.launchpad.net/juju-core/+bug/1246905 needs to be updated
<_mup_> Bug #1246905: status for manual provider hangs <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1246905>
<axw_> jam: yo, just making dinner - what's up?
<axw_> ok
 * axw_ looks
<jam> reading the text, it looks like it should be something about "juju should use netwokr address from ?"
<axw_> jam: yes, agreed - I'll update it in a bit
<jam> axw_: thanks, I was a bit confused reading the summary and looking at our trajectory. I think we can unschedule it from "stuff we are working on right now" unless you're looking closer at it
<jam> (so unset the milestone)
<jam> natefinch: are you still looking at bug #1218616 ?
<_mup_> Bug #1218616: all-machines.log is oversized on juju node <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1218616>
<jam> I thought I remembered a ping on your logrotate branch
<jam> but I don't know where that's at
<axw_> jam: yeah, sorry, it should be unset
<jam> axw_: yeah no problem, I was just going through the list and figured I'd check it with you
<natefinch> jam: I should pick it back up.... all it really needs is a signal to juju to have it reopen the log file so it starts writing to a new one, rather than the old one.  Not exactly sure how hard that'll be to implement, since I don't know the core logging code that well
<jam> natefinch: I'm assigning https://bugs.launchpad.net/juju-core/+bug/1248329 to you. Is that ok ?
<_mup_> Bug #1248329: juju destroy-environment does not accept -e <ci> <destroy-environment> <regression> <ui> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1248329>
<jam> it sounded like you were going to pick it up at the meeting today
<natefinch> jam: yep
<natefinch> jam: so we'll support -e but not JUJU_ENV ?
<jam> natefinch: and not ~/.juju/environments
<jam> at least, that is what I'm going with
<jam> as that will be "you can run juju destroy-environment -e YYYY" on 1.16 and 1.18
<jam> natefinch: so you *have* a transition step. Also specifying "-e env" still gets us "you had to type it manually"
<jam> which is what the old bug was about
<jam> I can respect the "required arguments should be positional" but we still hold to the letter of the original request
<jam> (don't make it so easy to destroy the production env)
<natefinch> jam: right.  Are we going to remove -e in 1.20 then, or keep it?
<jam> natefinch: *shrug*
<jam> If someone feels super strong that we must not have a required but flagged argument then we can remove it in 1.20
<jam> natefinch: you can write a bug about it and target 1.19 if you like
<natefinch> jam: yeah, it does bug me to have required flags :)
<jam> natefinch: I think of them a bit like named arguments
<jam> I actually like them sometimes
<jam> especially vs a "cmd dosomething true"
<jam> cmd dosomething -tox=true
<jam> fwereade: do you feel bug #1233936 is very important for 1.18 ?
<_mup_> Bug #1233936: worker/uniter: uniter restarts when relation removed <tech-debt> <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1233936>
<natefinch> jam: there are cases where it makes more sense, like if you have several arguments, or the value of the argument is something non-obvious, like a boolean or a number
<jam> (iow, target 1.17.1 or leave it at 1.19?)
<fwereade> jam, 1.17.1
<jam> done
<fwereade> jam, it's not even hard -- find everywhere in worker/ and cmd/jujud/ that checks for NotFound, and cause it to also check for Unauthorized
<fwereade> jam, (ok that's more than the bug, but that bug is just a symptom of the broader problem)
<jam> fwereade: sure, but doing that work as part of the bug is fine
<jam> you could even land that today *wink* :)
<fwereade> jam, but actually coding doesn't seem to be something I can get away with doing at the moment
<jam> :)
<jam> I understand the feeling
<jam> fwereade: it does feel like something that is really missing test coverage
<jam> somehow
<jam> fwereade: I suppose our test suite doesn't assert that services don't bounce ?
<fwereade> jam, it was something we agreed and planned but missed in the actual hurly-burly of developing stuff
<fwereade> jam, well, I spotted an unchecked error return in the uniter.filter test suite that would have caught it
<fwereade> jam, but yeah, I don't think we have adequate coverage of such situations
<fwereade> jam, otherwise I don't think there'd be any bare NotFound checks
<jam> dimitern: ping
<jam> sinzui: bug #1253628 *might* be a blocker for juju 1.17.0, we could sort of go either way here
<_mup_> Bug #1253628: juju upgrade-juju incompatible with 1.16 <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1253628>
<jam> but not being able to upgrade 1.16 to 1.17 is a bit bad
<sinzui> yeah
<jam> sinzui: I *think* we don't have to block. because people can still test if 1.17 works for new workloads, and we advocate that people *never* upgrade a production env to a dev release
<jam> so not being able to, hey we just helped you out, right ? :)
<sinzui> jam, they cannot upgrade without the --dev flag
<sinzui> though...
<jam> sinzui: right, but they *can't do it at all* with a 1.17 that we release today :)
<sinzui> yesterday I upgraded the charmworld staging site from 1.13.3 and was surprised to see 1.15.0 selected. That was the aborted release. I then specified the upgrade to choose 1.14.1 then 1.16.3 to upgrade along a path I know worked
<jam> sinzui: right, we've explicitly stated that we will support stable => stable, but we don't guarantee from/to dev releases.
<jam> sinzui: I' believe Dimiter was specifically doing upgrade work so that it wouldn't default dev => dev anymore
<sinzui> fab
<jam> (so 1.17 won't try to upgrade to anything but 1.17+ by default, not 1.19)
<jam> dimitern: I'd like you to pick up bug #1253628 if you can
<_mup_> Bug #1253628: juju upgrade-juju incompatible with 1.16 <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1253628>
<dimitern> jam, will take a look
<dimitern> jam, is it more important than the CLI stuff?
<jam> dimitern: it is the compatibility for the CLI stuff.
<jam> and yes
<jam> dimitern: essentially because you use Client.EnvironmentGet
<jam> you *can't* actually upgrade 1.16 to trunk
<jam> because that API doesn't *exist* in 1.16
<axw_> fwereade: not sure if you saw this earlier, because you got cut off shortly after I sent it:
<axw_> <axw_> fwereade: hiya. TheMue reviewed my state changes for environment Life, but I thought I'd better wait for you since you reviewed the parent branch
<axw_> <axw_> when you have some moments: https://codereview.appspot.com/28880043/
<dimitern> jam, ok, will switch to it then
<fwereade> axw_, I did, and I started to make comments, and then meetings swept me away
<axw_> no worries
<fwereade> axw_, sent
<axw_> fwereade: thanks
<jam> sinzui: I'm upgrading bug #1250154
<_mup_> Bug #1250154: updateSecrets in juju-1.18 uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1250154>
<jam> sinzui: it turns out that axw_'s patch to try to pass secrets on demand
<jam> broke *every* cli command against 1.16
<axw_> :o
<sinzui> Yay! I like the kinds of changes that are 100% something. Thats how I roll.
<jam> sinzui: no half-assed measures
<jam> we're gonna break it
<jam> and we're gonna do it right!
<jam> axw_: not particularly your fault, as we weren't being cautious and labeling what the new APIs were
<jam> axw_: can I assign it to you ?
<axw_> jam: certainly
<sinzui> nope. Not one promulgated charm branch worked yesterday thanks to me
<jam> axw_: I *think* we can just fall back to finishing api.Open in that case
<jam> axw_: because we don't *have* to pass secrets.
<jam> (most of the time)
<axw_> jam: ah, because it's existing
<axw_> yep
<jam> axw_: so there is still the potential for someone bootstrapping with 1.16 and then we try to use 1.18 for everything else
<axw_> I assume we don't have to cater for installed 1.16 without having ever connected to it? :)
<jam> but I think that window is small enough we can document it and WontFix
<axw_> +1
<axw_> "delete and rebootstrap with 1.18"
<jam> axw_: worst case, yeah
<jam> as long as destroy-environment still works :)
<axw_> hehe
<jam> axw_: that particular bug makes it hard for me to test what other commands we broke, becaues... they're all broken :)
<axw_> jam: all the SSH-based ones, IIRC, use a new API
<axw_> yep - I added the PublicAddress API
<axw_> sigh
<jam> axw_: yeah, I'm just going throug hthe "bzr diff -r juju-1.16.3..trunk"
<jam> so I'll get there eventually
<axw_> jam: so that's ssh, scp, debug-hooks, debug-log
<jam> fwereade: compatibility is turning into quite a bit of work
<axw_> can we just unbreak upgrade-juju and leave the rest? ;)
<jam> axw_: well updateSecrets is a definite fix, and upgrade-juju is
<jam> status hasn't been done yet
<jam> axw_: for the rest... I wanted to scope the work and then decide
<jam> but it is looking pretty big
<axw_> ok
<fwereade> jam, isn't the secrets-pushing just one piece of work? ie if the api isn't there, fall back to a state connection to push them using the previous mechanism?
<jam> fwereade: so *that* is one of the "we must do" bits
<jam> fwereade: well, I don't think we *have* to fallback, but we could
<jam> fwereade: the big scope of the work is falling out from my auditing
<jam> I'm up to about 10 commands and counting
<fwereade> jam, that just didn't have APIs at all in 1.16!?
<fwereade> jam, how did the gui get anything done?
<jam> fwereade: well they were missing a key api.
<jam> fwereade: like "juju set-constraints" didn't support EnvironmentConstraints
<jam> fwereade: so the GUI could change a service but not the global
<jam> but they didn't need to
<jam> I guess
<jam> add-machine wasn't done by the guy
<jam> debug-hooks, ssh, scp weren't done by the gui
<jam> fwereade: service-set and unset needed new APIs to handle the empty string vs null appropriately
<jam> destroy-machines,
<jam> environment-get/set
<jam> so basically, the GUI didn't do machines or environment level things
<jam> dimitern: just to keep you in the loop, bug #1250154 is blocking *all* of trunk talking to 1.16 so if you go testing manually that needs to be fixed first. axw will pick it up, but you can do a quick hack if you want to test it.
<_mup_> Bug #1250154: updateSecrets in juju trunk uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1250154>
<dimitern> jam, ok, so what's the fix we're looking for?
<dimitern> jam, migrate my set-/get-environment changes into 1.16?
<jam> dimitern: updateSecrets (in a first pass) should just keep going if it can't get EnvironmentGet
<jam> dimitern: because the 99% case is that we don't actually need to pass the secrets
<jam> (it is only needed if they bootstrapped with 1.16 and then never did anything but upgraded to 1.18)
<dimitern> i'm not sure I get you
<dimitern> in trunk we need to implement a workaround for using state.EnvironConfig if client.EnvironmentGet fails?
<jam> dimitern: no. The particular bug is that when doing NewAPIConnFromName we check if we need to pass secrets by calling Client.EnvironmentGet
<jam> but that API didn't exist in 1.16
<jam> however, we *also* don't normally need to set secrets
<jam> so a quick fix
<jam> is that if we try to EnvironmentGet in updateSecrets, and it fails, just keep going.
<dimitern> jam, ah, so just skip it and ignore the error?
<axw_> jam: did you mean to set the overall compat bug to me, or the upgradeSecrets one?
<axw_> (you assigned the former)
<jam> axw_: just the upgradeSecrets one
<jam> I'll fix it
<axw_> ok
<axw_> ta
<jam> axw_: I'm making you responsible for all that is wrong in the world. Are you ok with that? y/Y ?
<axw_> ;)
<jam> yay, DestroyRelation should be ok. Finally something that may not have broken (aside from the breaking of everything :)
<dimitern> jam, so I shouldn't look at bug 1250154, but at bug 1253628 only?
<_mup_> Bug #1250154: updateSecrets in juju trunk uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1250154>
<_mup_> Bug #1253628: juju upgrade-juju incompatible with 1.16 <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1253628>
<jam> dimitern: well, I think axw_ is officially done working for today. So if you want to pick up 1250154 before he gets to it. It is the more important one. But both are important and you have more context for upgrade-juju
<dimitern> I'm confused now :/
<dimitern> what's the workaround for SetEnvironAgentVersion ?
<jam> dimitern: just focus on fixing juju upgrade-juju when running against 1.16
<jam> dimitern: essentially juju upgrade-juju needs to fall back to poking the DB directly if it can't client.EnvironmentGet
<dimitern> 1.16 in the cloud when using cli from trunk?
<jam> since if it can't EnvironmentGet then it can't SetEnvironAgentVersion
<jam> dimitern: "juju-1.16 bootstrap; juju-1.16 deploy; juju-trunk upgrade-juju --dev" is broken
<axw_> I've gotta go, I'll look at 1250154 first thing in the morning if it's still broken
<jam> axw_: have a good night
<dimitern> jam, upgrade-juju --dev is no longer present in trunk
<axw_> cheers, good night jam, all
<jam> dimitern: "juju upgrade-juju" is just broken
<dimitern> axw_, g'night
<axw_> later dimitern
<jam> dimitern: we *can't* upgrade a 1.16 installation to anything
<jam> because it doesn't have the API we added to do so
<jam> regardless --dev or whatever
<sinzui> I am uncertain about bug #1253576. I expect a relation error to eventually be shown in status if the hook didn't complete.
<_mup_> Bug #1253576: Juju does not show relation status <add-relation> <juju-core:New> <https://launchpad.net/bugs/1253576>
<dimitern> jam, so the fix should be "try EnvironmentGet, if it fails, access the state directly?"
<jam> dimitern: right
<dimitern> jam, if it fails in a certain way that is - when it's missing
<jam> dimitern: well, we can just fallback and then worry about other reasons why it fails
<dimitern> jam, so we'll have 2 commands in 2 old upgrade-juju and the new one
<jam> dimitern: 2 commands?
<dimitern> jam, s/in 2/in 1/
<jam> 2 code paths ?
<dimitern> yeah
<jam> dimitern: yes
<dimitern> ugh, how ugly... but well
<jam> dimitern: keep what you've done, we'll want it for upgrading a 1.18 to something newer, but we also need to support upgrading from 1.16 to 1.18
<jam> dimitern: the "ugliness" is just beginning: https://bugs.launchpad.net/juju-core/+bug/1253619
<_mup_> Bug #1253619: juju 1.18 needs to support all CLI against a 1.16 server <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1253619>
<jam> I'm up to 10 commands
<jam> that are broken against 1.16
<dimitern> so due to compatibility the mess is getting worse for each minor version from now on forever
<jam> dimitern: no, we don't claim to support 1.16 in 1.20
<dimitern> we'll have duplicated code that both has and hasn't direct db access
<jam> so for things that we have compatibility to 1.16
<jam> we can delete it in 1.120
<jam> 1.20
<jam> things will be worse in the 2.0 series
<jam> where we *will* go for 2.X is compatible with 2.Y
<jam> but hopefully we've gotten our shit sorted a bit better by then
<fwereade> jam, that "10" number hasn't got worse in the last 20 minutes at least :/
<dimitern> can we claim that upgrade-juju truly uses the api, if it has this workaround? it seems like a regression/security leak
<jam> dimitern: it is possible that we'll decide instead "juju upgrade-juju and juju status" are all that need to maintain compat
<jam> and the rest will just have new ocde
<jam> fwereade: too much talking on IRC :)
<jam> fwereade: but actually I've gotten to a few commands that were in the API
 * fwereade cheers
<fwereade> dimitern, jam: and it's 2 steps -- *can* use the api in 1.18, followed by *must* in 1.20
<fwereade> dimitern, jam: so we can drop the db access code starting in 1.19
<dimitern> fwereade, ok, that's a small consolation at least
<fwereade> dimitern, take 'em where you can find 'em ;)
<dimitern> :)
<fwereade> jam, do you have a note somewhere for cutting off client mongo access for new deployments in 1.18 and for all in 1.20? as for agents in 14/16?
<jam> fwereade: 12 total
<jam> audit is done
<jam> fwereade: arguably the 1.18 thing is https://bugs.launchpad.net/juju/+bug/804284
<_mup_> Bug #804284: API for managing juju environments, aka expose cli as daemon <pyjuju:Triaged> <juju-core:In Progress by jameinel> <https://launchpad.net/bugs/804284>
<jam> but we need another for 1.20
<jam> fwereade: is it 14/16 or is it 16/18 ?
<jam> fwereade: I *think* we actually need to cut off all access in the 1.18 code for all agents
<fwereade> jam, hmm, you may be right in fact
<fwereade> jam, ok, we need to do that too then :)
<jam> fwereade: yeah, filing the bug now
<fwereade> jam, cheers
<jam> fwereade: so, an issue of 1.16 to 1.18 to 1.20 compat for direct DB access
<jam> for clients specifically
<jam> if we want "juju-1.18 bootstrap; juju-1.16 status" to work
<jam> then we can't remove DB access yet
<jam> but we can remove access in 1.20
<jam> (by default)
<fwereade> ha, good point
<jam> fwereade: but I think we can just do it forcibly
<jam> as in, upgrading 1.18 to 1.20 will remove access
<jam> which we *couldn't* do for agents
<jam> mostly because of the set of "people who might access this" is unknown
<jam> while for agents we knew who might
<jam> and could leave rights just for that set
<jam> fwereade: ok. so I've done the audit for bug #1253619
<_mup_> Bug #1253619: juju 1.18 needs to support all CLI against a 1.16 server <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1253619>
<jam> fwereade: we have 12 commands that need compatibility
<jam> fwereade: they break down into "things that touch machine", "things that touch environment", "things that directly access a node", and "ServiceSet" allowed the empty string to indicate reverting a field to default, while we added Unset for that
<jam> and then we'll get upgrade-juju for SetAgentAPIVersion, "juju status" which the GUI did via the AllWatcher, and "juju deploy" because of the PutCharm stuff.
<abentley> sinzui: I think the EnvironmentGet thing is interfering with Azure uploads, but I thought that Azure uploads didn't use juju.  http://162.213.34.53:8080/job/upgrade-and-deploy-specific/174/consoleFull#-19356225433c12a2ef-3702-44a9-9d42-48ac051c3e02
<jam> abentley: You used to use gwacl directly there
<jam> so it couldn't be EnvironmentGet, but if you changed that maybe
<abentley> jam: we don't anymore.
<abentley> jam: Now we use azure_publish_tools.py from ci-cd-scripts2.
<dimitern> jam, fwereade: fix for bug 1253628 https://codereview.appspot.com/30300043/
<_mup_> Bug #1253628: juju upgrade-juju incompatible with 1.16 <compatibility> <regression> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1253628>
<jam> abentley: that is a pretty big log, any help to narrow down where you think the failure due to EnvironmentGet is?
<jam> abentley: I don't see azure_publish_tools in that file
<abentley> jam: The bit in red.
<abentley> jam: The link should have taken you to to bit in red.
<jam> abentley: I probably scrolled shortly after. So I can't tell what command is being run, but if it is "juju scp" yes, that would be broken
<abentley> jam: I don't think it is, but sinzui will know better, because he wrote the script being run.
<jam> abentley: unfortunately that log seems to hold the output of commands run, but not the commands themselves
<jam> abentley: anyway, bug #1250154 means that *any* command you run with a 1.17 client against a 1.16 environment will fail
<_mup_> Bug #1250154: updateSecrets in juju trunk uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1250154>
<abentley> jam: Yes.  That's because some of these scripts source credentials and I was being cautious to about having credentials appear in the log.
<sinzui> abentley, jam: we use the official MS python azure library to upload the stream meta and tools
<abentley> sinzui: Okay, maybe the azure upload completes, and it's my wait_for_agent_update script that dies.
<abentley> sinzui: No, can't be that, that happens after we upgrade juju.
<sinzui> abentley, The log doesn't show --upload so there is no evidence that juju wanted to move things.
<abentley> sinzui: I'm going to change the script to output commands, since we now exect publish-public-tools, instead of sourcing it.
<abentley> sinzui: I think it might be upgrade-juju itself that's failing.
<sinzui> abentley, looking at the log and the error line, I see that upload to azure completed a few lines before. We can update the script to state is is done with everything
<sinzui> abentley, in juju-dev, jam predicted that upgrade-juju is dead because of a recent landing
<jam> dimitern: reviewed
<abentley> sinzui: That would explain it, then.
<jam> ideally we'd have you test with deploying with 1.16 but bug #1250154 will break for you
<_mup_> Bug #1250154: updateSecrets in juju trunk uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1250154>
<jam> dimitern: if you want to pick that one up then we'll have both fixed which would be great
<jam> I need to head off to dinner now.
<sinzui> thanks jam, I stumbled because I wasn't sure how it was renamed
<dimitern> jam, I'm on it already
<dimitern> jam, added a single line to call IsNoSuchRequest in the only sensible test I can find, which tests for "no such request" - rpc/reflect_test.go, should be sufficient
<dimitern> jam, proposing now
<dimitern> jam, I don't want to complicate things too much for this - it's not easy to test it in params, because there are no api tests there, and in order to test it I need to implement some generic client call that accepts a method name and calls whatever you give it, or something
<dimitern> jam, fwereade: and this https://codereview.appspot.com/30330043 fjxes bug 1250154
<_mup_> Bug #1250154: updateSecrets in juju trunk uses Client.EnvironmentGet which is not in 1.16 <ci> <intermittent-failure> <precise> <regression> <test-failure> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1250154>
<rogpeppe> dimitern: isn't there already such a client call?
<rogpeppe> dimitern: api.State.Call
<dimitern> rogpeppe, well, not directly accessible from tests I think
<rogpeppe> dimitern: isn't it?
<rogpeppe> dimitern: what about in the state/api tests?
<dimitern> rogpeppe, there are no tests that use Call directly
<rogpeppe> dimitern: i should look at the CL itself to see what jam is suggesting :-)
<dimitern> rogpeppe, yeah, do that please :)
<dimitern> jam, ping
<rogpeppe> dimitern: i think HasPrefix would be better than using regexp
<rogpeppe> dimitern: strings.HasPrefix, that is
<dimitern> rogpeppe, ah, yes, I forgot about that
<rogpeppe> dimitern: also the Is* functions should work correctly when passed a nil error
<dimitern> rogpeppe, not in this case - i'm not using ErrCode(err)
<rogpeppe> dimitern: all the Is* functions should work ok when passed a nil error
<rogpeppe> dimitern: that's a current invariant, and a useful one
<dimitern> rogpeppe, IsCode*, but this is not like the others
<rogpeppe> dimitern: it doesn't matter
<rogpeppe> dimitern: it's like os.IsNotExist and many others
<dimitern> rogpeppe, ok, I see your point
<natefinch> sigh.... mgo doesn't like connecting to a mongod that has been started with --replSet.  Trying to figure out why.
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, thanks, take a look at the follow-up as well please https://codereview.appspot.com/30330043
<rogpeppe>  dimitern: i'm not entirely convinced by that
<rogpeppe> dimitern: are we sure that noone is going to bootstrap a 1.16 environment any more?
<rogpeppe> dimitern: and then talk to it with 1.18 tools
<rogpeppe> dimitern: if we can rule that out, then it seems ok
<rogpeppe> dimitern: but i'm not sure
<dimitern> rogpeppe, what do you suggest?
<rogpeppe> dimitern: well, the proper fix would be to push secrets as we did before
<dimitern> rogpeppe, expand please
<rogpeppe> dimitern: well, say someone bootstraps a 1.16 environment
<rogpeppe> dimitern: then they run a 1.18 juju command to try and get the status
<rogpeppe> dimitern: actually, that's a bad example maybe
<fwereade> rogpeppe, dimitern: I think we want +2 compatibility to work both ways
<fwereade> rogpeppe, dimitern: and I think that is a good example
<dimitern> fwereade, both ways?
<rogpeppe> fwereade: i think it should work both ways in that specific instance actualy
<rogpeppe> lly
<fwereade> rogpeppe, dimitern: yeah -- 1.18 client, 1.16 server; and 1.16 client, 1.18 server, are both important
<rogpeppe> fwereade: won't it work with the above CL?
<fwereade> rogpeppe, I don't know, I haven't looked -- been in a meeting
<rogpeppe> fwereade: the old client will push the secrets correctly because it talks to mongo directly
<natefinch> niemeyer: you around?
<rogpeppe> fwereade: the new client will push the secrets correctly because it should fall back to talking to mongo directly when the relevant API call isn't implemented
<fwereade> rogpeppe, yeah, that sounds just fine
<rogpeppe> fwereade: the only thing that falls through the cracks are calls that use the API in 1.16
<rogpeppe> fwereade: but that's a problem in 1.16 anyway
<rogpeppe> fwereade: so i don't think there's a regression there
<fwereade> rogpeppe, 1.16 calls that use the api should be ok, shouldn't they? what's wrong there?
<rogpeppe> dimitern: i've convinced myself it's all fine :-)
<rogpeppe> fwereade: they don't push secrets
<dimitern> rogpeppe, ok, so it's good as is then
<rogpeppe> fwereade: so if it's the first call that's made after bootstrapping, they won't work
<fwereade> rogpeppe, I *think* that we specifically avoided calls that made sense as first ones there
<rogpeppe> fwereade: even better
<fwereade> rogpeppe, eg juju get -- meaningless without a service :)
<jam> rogpeppe: yeah, "juju get" and "juju add-unit" both don't work unless you've deployed
<jam> fwereade: so there is likely to be a gap that if you "juju-1.16 bootstrap" and immediately "juju-1.18 status" the env won't have the secrets
<jam> *but* you have no services
<jam> so either you "juju-1.16 status"
<jam> or you "juju-1.18 destroy-environment; juju-1.18 bootstrap"
<jam> and things will work ok
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, thanks
<jam> dimitern: It matches what I thought we would need to do. I wonder if we could mock test it. Or possibly just test it live and I'll be happy enough
<rogpeppe> dimitern, fwereade: BTW if you're ever stuck debugging Eaborted with a large set of transaction operations, you might find this code useful for finding out which assertion actually failed: http://paste.ubuntu.com/6453685/
<rogpeppe> dimitern, fwereade: i just found it very useful
<dimitern> rogpeppe, cheers, good to know
<fwereade> rogpeppe, nice
<rogpeppe> dimitern: in case it's not obvious, it returns the index of the operation with the first failed assertion
<dimitern> rogpeppe, this can probably live in some of the testing packages
<rogpeppe> dimitern: it's not actually that useful in a testing package because the operations rarely escape to the tests
<rogpeppe> dimitern: it might be useful in its own testing package i suppose, to be imported temporarily when debugging
<rogpeppe> dimitern: but in that case it might as well live somewhere external
<dimitern> rogpeppe, my point was, it's better to be somewhere in the code, so it can be reused if needed + some comments
<rogpeppe> dimitern: i agree it needs comments - i just hacked it up for my own use :-)
<rogpeppe> dimitern: just found that the 9th op out of 11 was the one that failed its assert
<dimitern> rogpeppe, sweet!
<rogpeppe> fwereade: i think you might be pleased to know i've just refactored all the addmachine logic. i can actually understand it now. hopefully others will be able to too.
<fwereade> rogpeppe, you rock, thank you
<rogpeppe> fwereade: it was some of the twistiest stuff i've had to deal with in a while
<jam> dimitern: so if you land those two patches, target the bugs to 1.17.0 since sinzui hasn't released it yet
<sinzui> thank you jam and dimitern
<dimitern> jam, ok, will change the milestone to 1.17.0
<dimitern> sinzui, np, they were easy to fix at least
<niemeyer> natefinch: Yep
<natefinch> niemeyer: I am having trouble dialing into a mongod that has been started with --replSet, but that hasn't had replSetInitiate called yet.  mgo connects, but then repeatedly tries <something> and eventually fails with " no reachable servers"
<niemeyer> natefinch: That's the right behavior.. it's not finding the master
<niemeyer> natefinch: If you want to force a connection to a slave, you can use the direct mode
<natefinch> niemeyer: but I need to be able to connect to call replSetInitiate so it can determine the master :/
<natefinch> niemeyer: ahh, ok
<rogpeppe> fwereade: i'm looking at Unit.findCleanMachineQuery
<rogpeppe> fwereade: it first finds all machines with non-empty containers, then finds all machines which weren't found earlier
<rogpeppe> fwereade: do you know of anything that's stopping something jumping in and adding a container between those two steps?
<rogpeppe> dimitern, jam: ^
<fwereade> rogpeppe, dimitern: if the eventual assignment doesn't or can't assert on the lack of a container, then no
<dimitern> rogpeppe, fwereade, yeah, that sounds right
<rogpeppe> fwereade: if the query can't, i'm not sure how the eventual assignment can
<rogpeppe> fwereade, dimitern: i think it's fundamentally racy unless there's some indication of "has a container" in machineDoc
<fwereade> rogpeppe, the eventual assignment surely can, because it can assert on the containerrefs document
<rogpeppe> fwereade: ah
<fwereade> rogpeppe, whether it actually does so is another question
<rogpeppe> fwereade: yeah, i can't see that it does, but good point.
<rogpeppe> fwereade: i think it should probably be another txn assert inside Unit.assignToMachine
<fwereade> rogpeppe, sgtm
<rogpeppe> fwereade, dimitern: https://bugs.launchpad.net/juju-core/+bug/1253704
<_mup_> Bug #1253704: state: unit assignment emptiness check is not transactional <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1253704>
<fwereade> rogpeppe, triage it please :)
<dimitern> rogpeppe, thanks
<rogpeppe> fwereade: what importance would you give it?
<fwereade> rogpeppe, I'd call it medium because I can't decide between high and low
<rogpeppe> fwereade: :-)
<fwereade> rogpeppe, which is what medium means
<rogpeppe> fwereade: confirmed at medium
<jam> fwereade: rogpeppe: High is we should do it now, Low is we should do it, medium doesn't mean anything
<rogpeppe> jam: i hold no opinion in this matter :-)
<rogpeppe> jam: i will mark it however people think
<jam> rogpeppe: sinzui put up a good listing of what the different priorities mean
<fwereade> jam, then almost everything is low ;)
<jam> fwereade: exactly
<jam> saying "this is slightly higher than this other thing" doesn't mean much
<jam> it is either "stuff we're working on for the next releases" == High
<jam> or it is Low
<jam> fwereade: or it is "OMG we have to fix this now" = Critical
<rogpeppe> jam: personally i think that "low" should be reserved for things that won't break anything if they're not fixed
<jam> rogpeppe: Either it is High and we'll actually schedule it to be done, or we won't actually and then it doesn't matter
<jam> whether you call that "Low" or "Medium" they are effectively the same
<jam> because you're not getting to them in a reasonable amount of time
<rogpeppe> jam: hmm, perhaps it should be High then
<sinzui> High mean we commit to fixing it in our plans for the cycle. It is easy to say the cycle is 6 months, but I think 3 months is more realistic for the purposes of planning. I cannot image more than two milestones personally. I think this, that, and them
<sinzui> Also, I don't believe 100 of our High bugs are really High. We just don't have a enough of them in our heads to see which ones we wont fix
<hazmat> fwiw, there seem to be quite a few issues at the http client layer for go trunk and juju-core trunk wrt to ec2 bootstrapping and s3 interactions
<mgz> interesting as in terrifying?
<hazmat> sinzui, re ui here.. is there any way to sort the latest release at the top, people are just downloading the top link for 1.15 even though 1.16.3 is the latest there (at the bottom) https://launchpad.net/juju-core/+download
<sinzui> no
<sinzui> I keep bring this up. Lp doesn't support what we do and our stable releases will fall off +downloads, breaking debwatch
<natefinch> sinzui: how are they sorted?
<sinzui> hazmat, to be blut, Lp doesn't do the right thing for any project in this matter.
<sinzui> natefinch, according to the minds of salgado-grubbs-pool-albistte...
<natefinch> hazmat, sinzui:  wow, that is, umm... like completely unacceptable.
<sinzui> natefinch, I believe we are seeing the project's focus-of-development series listed first, then ordered in z-a, then all other series in a-z with releases as z-a
<sinzui> natefinch, hazmat I get angry every time this comes up. I didn't have the power and time to prevent it
<natefinch> sinzui: I have no idea what that means.  Is there a way we can hack out outputs so they sort the way we want.
<sinzui> hazmat, natefinch I /think/ we want the page listed by deb-version descending and offer an alternate page by date
<sinzui> the latestest portlet would show  highest deb-version for the series or all series
<sinzui> natefinch, the +downloads page was originally simple and practical. Then changes were made without checking use cases. I wept
<natefinch> sinzui, hazmat:  in my experience, when stuff like this comes up, the best way to get people to listen is to do something incredibly drastic, so everyone has to go "why the hell would you do that?"  And that gets the conversation going about how to fix things.
<sinzui> I don't know the use cases myself, but I think packagers are the first users that need to find what they need to get into distros
<sinzui> +downloads is broken by design. I haven't found a single project that it works for
<natefinch> sinzui: here's my suggestion - we delete all the downloads off that page and move them somewhere outside LP where we have control over sorting.  Then email the juju list about the change.... and way to see how long it takes someone to throw a hissy fit.
<sinzui> natefinch, the page exists to two of our users. Ubuntu and homebrew. Both pickup packages from that page. removing them will break ubuntu temporarily and home brew for ever
<natefinch> sinzui: well then, it would definitely get some attention ;)   Sigh, yes, I guess we can't do that, then.
<sinzui> I have a 4 day weekend coming up. I can make a grand simplification to the page that stevenk and wgrant might except. They are sympathetic to the needs of packagers.
 * sinzui see that we are 2 unstable releases aways from pushing stable releases to the scond page
<hazmat> natefinch, drastric would be have release downloads on juju.ubuntu.com only and trash the lp download page.
<hazmat> sinzui, ^
<hazmat> natefinch, oh.. yeah.. same thing you were suggesting
<hazmat> sinzui, we can fix homebrew
<hazmat> its an mp away.
<hazmat> er. pr
<sinzui> hazmat, yes we can do that.
<rogpeppe> fwereade: finally https://codereview.appspot.com/30390043
<rogpeppe> and that's me for the night
<rogpeppe> g'night al
<rogpeppe> l
<natefinch> hazmat. sinzui: took me over 3 months, but I finally realized that when canonical says series, what they mean is "branch", at least from a code perspective.
<sinzui> not the same
<natefinch> sinzui: branch + sub-branches
<sinzui> natefinch, a series is metadata about intent. I have argued that Lp should let me state a branch is a fix, a feature, a series that I make releases from
<sinzui> natefinch, I would like to think a series is a superset of data about a branch, but distros have series and there are no branches. A series is planning device that branches are arbitrarily associated with. I say "arbitrary" because Lp puts projects before branches, and treats secondary communities as having equal power the the primary developers. equal power with out any responsability
<sinzui> natefinch, I know why Lp does its non-sense. I was a collaborator. The developers spent too much time creating incomplete features without journey to guide design
<natefinch> sinzui: I get it.  And yeah, I can see there's a lot started on LP that didn't get the spit and polish.
<natefinch> morning thumper
<natefinch> niemeyer: still around?  I still can't get this working.  replSetInitiate.  mgo is returning "no reachable servers" which I know is not true, since it is correctly dialing.  when I do rs.initiate() from the shell, I get "can't find self in the replset config"
<niemeyer> natefinch: How are you dialing?
<natefinch> niemeyer: here's the mongod command line and the code I'm running: http://pastebin.ubuntu.com/6454825/
<niemeyer> natefinch: What's the output?
<natefinch> niemeyer: actually, I guess it is failing on the dial, I had thought I'd seen it made it past that, but I guess not.  I'm getting "Error from dial: no reachable servers"  (first half is my message)
<niemeyer> natefinch: In that case you have a sever that is actually in a bad state
<niemeyer> natefinch: Oh, wait
<niemeyer> natefinch: You need to use a Monotonic session
<thumper> o/
<niemeyer> natefinch: With a strong session, it won't allow anything but a master
<natefinch> niemeyer: how do I do that?  I only see SetMode on the session, which I can only get with Dial, which is what is failing
<niemeyer> natefinch: Well, if you cannot even dial the server is likely in a bad state
<niemeyer> natefinch: Reset your server and try this command again
<natefinch> niemeyer: ok
<natefinch> niemeyer: ok, yeah, now I'm getting "couldn't initiate : can't find self in the replset config my port: 28000"
<thumper> mramm2: around somewhere?
<mramm2> thumper: yea
<niemeyer> natefinch: Cool
<natefinch> niemeyer: well, except for the error.
<niemeyer> natefinch: This means you're not configuring the replica set correctly
<niemeyer> natefinch: It's simply telling you the server isn't part of the configuration, so the config can't be valid
<natefinch> niemeyer: ok, I thought since I could do rs.initiate() that I could do a bare replSetInitiate and it would do the right thing, but I can give it a valid config too
<niemeyer> natefinch: Yeah, it likes valid configs :)
<natefinch> niemeyer: details details :)
<jam> sinzui: we could always make "stable" releases from the trunk series ...
<sinzui> jam we could
<jam> sinzui: or maybe the .0 from there?
<sinzui> I could also move the releases to trunk now...
<jam> it at least gets people 1.16 instead of 1.15
<sinzui> jam ...but I sent an email to wgrant and stevenk proposing an fix that is easy for me to do and would make the page timeout less often
<jam> sinzui: if you can fix it, I'd rather not work around it :)
<sinzui> jam, the fix has always been political. I appealed to their love of speed and deb/ubuntu packaging
<natefinch> ahh, of course, I had to set direct=true and mode=monotonic, why didn't I think of that?  #mongodb :/
<thumper> abentley: still around?
<abentley> thumper: Hi.
<thumper> abentley: hey
<thumper> abentley: looking at this 'local provider not starting' bug
<thumper> abentley: do you have a machine it happens on reliably that I can get you to test a fix on?
<abentley> Yes, I was excited to see you think you have a solution.  I am not sure how reliably it happens on my machine.
<abentley> thumper: It worked yesterday, but before that, it had been failing a lot.
<thumper> abentley: is the machine in question able to compile easily from source?
<thumper> abentley: I think it is a race condition
<thumper> so could well be impacted by other work the machine is doing at the time
<abentley> thumper: just failed.
<thumper> abentley: let me whip you up a branch
<abentley> thumper: Yes, I should be able to compile from source here.
<thumper> kk
<thumper> give me a few minutes
<thumper> wallyworld_: hi
<thumper> wallyworld_: enjoy the cricket?
<wallyworld_> thumper: no :-(
<wallyworld_> bloody poms are winning
<thumper> abentley: can I get you to hammer this a few times? lp:~thumper/juju-core/fix-upstart-start-race
<wallyworld_> thumper: if you get a chance today, here's a branch which reworks the provisioner. the container stuff is moved out, only one switch statement now. https://codereview.appspot.com/29450043/
<thumper> wallyworld_: cool, got time to hangout?
<wallyworld_> ok
 * thumper starts one
<thumper> wallyworld_: https://plus.google.com/hangouts/_/72cpjtpfsf6lleb295gbg9iff0?hl=en
<abentley> thumper: Okay, I got it, but I don't know how to build it; make complains that various packages are missing.
<thumper> abentley: ah bugger
<thumper> I've forgotten how to grab all that
<abentley> https://pastebin.canonical.com/100868/
<thumper> abentley: try 'go get launchpad.net/juju-core
<thumper> abentley: have you compiled from source before?
<abentley> thumper: Not sure.  I grabbed the source long ago to make a small change.
<abentley> thumper: "no Go source files in /home/abentley/hacking/go/src/launchpad.net/juju-core"
<thumper> ugh...
<thumper> natefinch: do you member the command?
<thumper> abentley: perhaps add /... to the end of the go get juju-core command
<natefinch> thumper, abentley: that error is actually right... we structure our code in a non-idiomatic way, so there actually is no go code in the root directory, and that's ok
<natefinch> thumper, abentley: you can pass go get the -d flag and it'll just download (by default it downloads and tries to build)
<abentley> natefinch: I passed -d and it completed immediately.
<natefinch> abentley: so, you have juju-core, but it doesn't automatically go get the dependencies
<abentley> natefinch: That's what we're trying to accomplish with go get.
<hatch> hey can someone confirm if juju support retry & remove on 'pending' units?
<natefinch> abentley: go get launchpad.net/godep
<natefinch> abentley: then go to launchpad.net/juju-core/ and run godep -u dependencies.tsv
<abentley> natefinch: godeps with an s?
<natefinch> abentley: oops, yeah, godeps
<natefinch> abentley: there's like three different tools named godep / godeps
<abentley> natefinch: "No command 'godep' found, did you mean:..."
<natefinch> godeps :)
<abentley> natefinch: "godeps: command not found"
<natefinch> abentley: is your $GOPATH/bin folder in your path?
<abentley> natefinch: No.
<natefinch> abentley: you should fix that :)
<natefinch> abentley: that's where go puts the binaries that it builds
<natefinch> (go get both downloads and builds)
<abentley> https://pastebin.canonical.com/100869/
<abentley> natefinch: ^^
<natefinch> abentley: arg, sounds like it will only update, not actually go get the thing in the first place.  sigh
<natefinch> abentley: the hard way is to first simply do go get <path> where path is the first string in dependencies.tsv
<natefinch> (for each line in dependencies.tsv)
<abentley> natefinch: https://pastebin.canonical.com/100870/
<fwereade> hatch, retry no; remove yes
<hatch> fwereade: thanks for confirming
<hatch> fwereade: so when a charm gets 'stuck' what is a user to do?
<hatch> just remove it and try again?
<natefinch> abentley: that's probably ok... that's just the same thing as juju-core had
<fwereade> hatch, soon, they will be able to destroy-machine --force to take the whole thing down; in the meantime, assuming the agent is running, they can destroy the unit and repeatedly resolve hook errors (as opposed to retry) until it finally goes away
<natefinch> abentley: I have to go in a few minutes, FYI
<abentley> natefinch: That's alright.  It's past EOD for me.
<fwereade> hatch, --force has landed, and will be in 1.17, but most people won't see it until 1.18, which we can't do until we've got some fairly significant api compatibility work done
<hatch> fwereade: ok so from the GUI if I were to give the user a 'remove' button for units in pending status that would suffice to match the functioning features?
<natefinch> good night all
<fwereade> hatch, yeah, I think so -- we favour the "destroy" terminology, but if you're calling it "remove" elsewhere it's probably best to stay consistent
<hatch> well from the gui it can't 'destroy' it can only remove the unit
<hatch> which will leave the machine
<hatch> at least for the time being
<hatch> at least I think that's the though process behind it
<hatch> thought*
<abentley> thumper: Got it to a state where make finishes with no output, but GOPATH/bin doesn't have an updated juju.  The one there is from March 8.
<thumper> abentley: make, or make install?
<thumper> make just builds
<abentley> thumper: make install put it there.  I'm used to make install putting it in /usr/bin, not a home directory.
<abentley> thumper: failed: ERROR failed to initialize state: no reachable servers
 * thumper shrugs, and looks at jtv
<thumper> abentley: again?
<abentley> thumper: You want me to try again?
<thumper> as in, you are still getting it?
<abentley> thumper: I'm saying I just tried it and it just failed.
<thumper> ah, can you show me your command line?
<thumper> the sudo line
<abentley> thumper: "$ sudo $GOBIN/juju bootstrap -e local"
<thumper> I tend to use $ sudo $(which juju) bootstrap
<thumper> but I gess that works
<thumper> can you see if the local mongo service is running?
<abentley> thumper: Since GOPATH isn't in my PATH, that wouldn't work.
<thumper> inside /etc/init there is a juju-something-db.conf
<thumper> go 'sudo status juju-...-db'
<thumper> to see if it is up
<thumper> I think it probably isn't
<thumper> but now I'm more confused
<thumper> I thought that this would fix it
<abentley> thumper: https://pastebin.canonical.com/100872/
<thumper> no, not monodb
<thumper> like I have juju-db-tim-local-kvm.conf
<thumper> where 'local-kvm' is my environment
<thumper> so I'd type 'sudo status juju-db-tim-local-kvm'
<thumper> yours is probably juju-db-abently-local
<thumper> assuming your userid is abently
 * thumper forgot last e
<thumper> sorry
<abentley> thumper: nw.
<abentley> thumper: https://pastebin.canonical.com/100874/
 * thumper frowns
<thumper> wtf
<thumper> ok, not sure, will have to come back to this
<abentley> thumper: okay.  ttyl.
<thumper> kk
#juju-dev 2013-11-22
 * thumper is losing the will to finish this bit of work
 * thumper takes a look at that critical bug that fwereade suggested
<thumper> time to step back and look at the pending reviews...
<axw> wallyworld_, thumper: what are your thoughts on doing `strings.HasSuffix(os.Args[0], ".test")` for changing default behaviour when running tests?
<thumper> ?!
<axw> my gut feeling is that it's bad, because it's adding test logic into non-test code
<thumper> horrible
<wallyworld_> context?
 * thumper school run
<axw> wallyworld_: disabling the finish-bootstrap stuff
<axw> I was thinking we could just disable it always when running tests by doing something hackish like that
<wallyworld_> yeah, go to agree with thumper on that one. i hate adding TestFoo() stuff but Go sucks in that it doesn't allow a better way to do it
<wallyworld_> TestingFoo() even
<axw> wallyworld_: how would you do it with, say, Python?
<axw> I guess you'd just monkey patch
<wallyworld_> yeah
<axw> but that's what I'm doing here...
<wallyworld_> but the test code has to be in the production code
<axw> well, we could expose the finishBootstrap var
<axw> the TestingX thing isn't strictly necessary
<wallyworld_> we could, and that has been done elsewhere eg var FinishBootstrap = finishBootstrap
<wallyworld_> i'd prefer the above
<axw> which above?
<axw> :)
<wallyworld_> with a suitable comment, saying "exposed for testing"
<wallyworld_>  var FinishBootstrap = finishBootstrap
<axw> hmmkay. I didn't do that to cut down on duplication
<wallyworld_> what duplication?
<axw> defining a replacement function. I guess I could just put that in another package tho
<wallyworld_> maybe i'm missing something
<wallyworld_> i'm just suggesting introducing anj exported var
<wallyworld_> so the testing stuff can live inside the _test file
<axw> wallyworld_: and then remove the Testing functions, right?
<wallyworld_> yes
<axw> wallyworld_: so the contents of those are either duplicated, or moved
<axw> no big deal I suppose
<wallyworld_> there's also a pattern where a testing package is introduced
<axw> yeah, I'll probably go with that
<wallyworld_> and all the callers over various other packages call the stuff in the testing package
<axw> provider/common/testing or so
<wallyworld_> yeah
<wallyworld_> still messy compated with python etc al
<thumper> not entirely surprising that
<thumper> given that go is compiled and strictly typed
<wallyworld_> and it doesn't have friends like C++ or access to "private" methods like python
<axw> I never liked friends in C++
<thumper> I didn't like friends in C++ either
<thumper> friendship isn't really that useful
<thumper> because you have to give it
<thumper> and it tightly couples things together
<thumper> it would be nice though if you had the ability to say "i know what I'm doing" in go
<thumper> anyway...
<abentley> axw: For a minute I thought you were using "like" and "friends" in the Facebook sense.  My mind may be permanently warped.
<axw> abentley: :) I don't Like my facebook Friends either
<axw> thumper: you added a whole lot of stuff to the CL you just updated
<axw> the local provider rsyslog one
<thumper> really?
 * thumper grunts
<thumper> I merged trunk
<thumper> and lbox shits itself
<axw> ah
<axw> because of the prereq maybe?
<thumper> in all honesty there is nothing interesting in that diff, just questions around the interface...
<thumper> maybe
<axw> thumper: I mean the other one - but anyway, LGTM
<axw> I didn't realise rsyslog was "Important"
<thumper> :)
<axw> should've checked
<thumper> even on my vanilla precise box we have /etc/rsyslog.d
<thumper> I was trying to do a reverse depends on rsyslog
<thumper> but not sure how to drive dpkg
<axw> not sure, but the Priority=Important, so it's in the base system
<thumper> axw: ok, so ubuntu-minimal depends on rsyslog
<axw> okey dokey
<thumper> although
<thumper> technically, we should add it as a depends to juju-local
<thumper> apt-cache rdepends pkg-name FWIW
<axw> thumper: thanks for the comment on tagOffset, the 1-indexing was the bit that confused me
<thumper> :)
<thumper> yeah, who indexes from 1?
<axw> not sure, maybe the same people who say Monday is the first day of the week
<axw> anyway... /me gets back to synchronous bootstrap
<axw_> wallyworld_: I've updated the synchronous bootstrap CL. There's now no upper limit on DNS/SSH wait, and it can be cancelled with SIGINT. Also added the output as you suggested, and better progress reporting
<axw_> haven't tested against the other providers yet
<wallyworld_> axw_: ok, looking, thanks
<wallyworld_> axw_: you were going to introduce a testing package for those test helpers?
<axw_> doh
<axw_> I was
<axw_> wallyworld_: I'll update again later with that
<wallyworld_> yeah, i'm not going ti blokc on that
 * wallyworld_ -> walk the dog
<rogpeppe> axw__, wallyworld_, TheMue: mornin' all
<axw__> morning rogpeppe
<rogpeppe> wallyworld_: thanks for the review
<wallyworld_> rogpeppe: np. nice to see that add machine stuff get some lovin'
<rogpeppe> wallyworld_: glad you're ok with it
<wallyworld_> why wouldn't i be? :-)
<rogpeppe> wallyworld_: it took me a full day to understand the old code :-)
<wallyworld_> i have had a had in it but a lot of the code predated my time :-)
<wallyworld_> /had/hand
<rogpeppe> wallyworld_: i ended up manually simulating each path through it and writing down the trace
<wallyworld_> i sorta just added to it, without refactoring
<wallyworld_> i like it that the top level methods reflect each business case
<rogpeppe> wallyworld_: you're right about the machine doc duplication BTW - i'm just adding a machineDocForTemplate function
<wallyworld_> \o/ thanks :-)
<rogpeppe> wallyworld_: i plan on losing AddMachineParams entirely BTW and exporting machineTemplate
<wallyworld_> any code that takes a day to understand needs refactoring :-)
<rogpeppe> wallyworld_: well, perhaps it was just my small brain...
<wallyworld_> that would be good cause that but of duplication will disappear with it
<wallyworld_> bit
<wallyworld_> i have a small brain too, smaller than most :-)
<rogpeppe> wallyworld_: yeah. and the code that digs around in it to work out what the caller is actually trying to do.
<wallyworld_> i think the final outcome will be good
<rogpeppe> wallyworld_: i hope so. i feel that it should be straightforward to do the next modifications that i need to do.
<wallyworld_> i'm always up for a good refactoring :-)
<rogpeppe> wallyworld_: BTW the logger.Info lines about transaction hooks will only ever happen in tests - transaction hooks are explicitly only there for testing
<wallyworld_> ah ok
<wallyworld_> maybe a comment in the code so the reader knowns the hooks are only run in tests?
<wallyworld_> just as an fyi?
<rogpeppe> wallyworld_: will do
<wallyworld_> thanks :-)
<rogpeppe> fwereade, axw__: your reviews of https://codereview.appspot.com/30390043/ would be appreciated too, as it's a significant change
<axw__> rogpeppe: ok, will take a look
<rogpeppe> axw__: thans
<rogpeppe> ks
<fwereade> rogpeppe, looking
<fwereade> axw__, I haven't followed up on your CL -- did what I said yesterday make sense?
<axw__> fwereade: are you talking about the state changes?
<fwereade> axw__, yeah, the environment life stuff
<axw__> fwereade: yup, makes sense - I checked with frankban about the tag usage
<axw__> I sent you an email about it. but yes, they do use it
<fwereade> axw__, great, thanks
<axw__> so I guess we'll have to not validate them for now
 * fwereade tries to keep up to date with mail :/
<axw__> fwereade, rogpeppe: if you're interested, I've got a synchronous bootstrap CL up for review here: https://codereview.appspot.com/30190043/
<rogpeppe> axw__: looking
<axw__> wallyworld_ has given it a once over, but this is a non-trivial change, so more eyes the better
<axw__> well, a thrice over I think
<axw__> :)
<axw__> fwereade: with the environment life CL, I still have a question about how we signal state servers to kill themselves
<axw__> fwereade: that was the reason for Remove (and EnsureDead before it)
<fwereade> axw__, off the top of my head: would it make sense to have a path that ties it into the Remove of a manually provisioned machine? current schema might not accommodate that, though
<fwereade> axw__, might require per-provider provisioned-machine refcounts
<fwereade> axw__, so forget that for now :(
<axw__> fwereade: refcounts for what sorry?
<fwereade> axw__, the number of manually provisioned machines in existence
<axw__> I don't understand how that'd be used here
<fwereade> axw__, possibly broken down by role -- we can kill the environment (or the manual state servers) once all the manual normal nodes have been killed
<axw__> fwereade: ok. I think we're thiinking the same thing, but you want transactional guarantees on mongo?
<fwereade> axw__, yes
<fwereade> axw__, they're tedious to work with but they're a lot better than nothing
<axw__> fwereade: sure. I was going to put all the logic inside apiserver/client, but you probably gathered that already
<axw__> (hence the env Dying -> prevents machine addition)
<fwereade> axw__, I feel that an env being set to Dying should set things in motion in itself
<fwereade> axw__, the dying preventing machine addition is necessary regardless, isn't it?
<fwereade> axw__, assume multiple clients
<fwereade> axw__, it's a little bit thin, but have you read doc/hacking-state.txt? and the various other lifecycle related docs?
<axw__> fwereade: no, but I will now :)
<fwereade> axw__, I'm afraid the lifecycle stuff has not entirely kept up with reality (I might get around to fixing them in my Copious Free Time) but things haven't diverged that much -- most of them should still be actually true
<rogpeppe> fwereade: how strongly do you feel about Machine.doc.TxnRevno, and in particular how important is it that AddMachine do a refresh immediately after creation to pick up an accurate txn-revno?
<rogpeppe> fwereade: i've just realised that it's racy, and it seems unnecessary.
<fwereade> rogpeppe, IIRC it's necessary for the watcher -- but I think I'd be fine with Machine.Watch grabbing a fresh TxnRevno before we start watching
<fwereade> rogpeppe, Ican't think of any cases where the API server calls Watchon a freshly-added machine
<rogpeppe> fwereade: it's not really necessary for the watcher tbh
<fwereade> rogpeppe, fwiw the point is not that it be accurate, specifically, but that it have a value that corresponds with reality
<rogpeppe> fwereade: you'll get an extra event if txn-revno is too low, but otherwise the watchers work fine
<rogpeppe> fwereade: and that extra event might happen anyway, if someone's made a change since you last refreshed
<fwereade> rogpeppe, I recall niemeyer got really irritated when I tried to write watchers that just treated the last-known-revno as -1, so I internalised it as something necessary, but I don't recall the details-- yeah, that had been my initial supposition
<rogpeppe> fwereade: i'm thinking that just leaving it as zero when adding a machine should be fine
<fwereade> rogpeppe, ha!
<fwereade> rogpeppe, I factored that stuff out anyway
<fwereade> rogpeppe, have a look around, see if *anyone* uses that field
<fwereade> rogpeppe, I'd love it if we just dropped it
<rogpeppe> fwereade: the machineUnits watcher does
<rogpeppe> fwereade: but tbh i don't think it needs to
<rogpeppe> fwereade: the only problem is the test that specifically tests that txnrevno is correct after AddMachine (TestAddAndGetEquivalence)
<fwereade> rogpeppe, I think that really I'd prefer not to have watchers that potentially start with double-events signifying no change
<rogpeppe> fwereade: i don't think any extra event will be emitted, but... let me check
<fwereade> rogpeppe, but equally that txn-revno lookups should probably be secreted away inside the watcher code
<fwereade> rogpeppe, the TxnRevno fields then become useful only when doing ultra-pedantic txn assertions and can in generalbe dropped
<rogpeppe> fwereade: i finally gave in and did it. what do you think of this? https://codereview.appspot.com/30770043
<fwereade> rogpeppe, if it's what we were talking about above, I love it already, but I've got to go to laura's school right now :(
<fwereade> (not emergency but appointment)
<rogpeppe> fwereade: it's not quite
<rogpeppe> fwereade: but it was prompted by it
<rogpeppe> fwereade: it's a  DeepEquals checker that treats empty slices == nil slices
<rogpeppe> axw_, dimitern, wallyworld_: would appreciate your thoughts too
<dimitern> rogpeppe, looking
 * wallyworld_ has had several drinks, being friday evening and all
<wallyworld_> but in general i don't agree empty == nil
<wallyworld_> well, maybe go likes to think they are equal, but that i disagree with
<wallyworld_> since nil should be a distinct value with a different semantic meaning to empty
<wallyworld_> at least that's the case in all other languages i have used
<wallyworld_> and it allows you to distinguish between "i don't know" and "empty"
<mattyw> fwereade, rogpeppe who would be best to talk to about the juju deploy command - how it works currently and how it might work in the future (I know there are some changes coming at some point)
<rogpeppe> wallyworld_: go doesn't think they're equal, but in many cases we do treat them as the same
<dimitern> rogpeppe, reviewed
<rogpeppe> dimitern: thanks
<wallyworld_> rogpeppe: that i find an issue with
<wallyworld_> since nil is semantically different to empty
<rogpeppe> wallyworld_: it's actually only an issue for DeepEquals
<rogpeppe> wallyworld_: because otherwise you can't compare slices
<rogpeppe> wallyworld_: (except against nil, which we almost never do)
<wallyworld_> i think is an unfortunate Go idiom or some such
<wallyworld_> usually, nil = "i don't have a value for this thing"
<rogpeppe> mattyw: i'm happy to chat about it; fwereade probably has the best bird's eye view of where things might be going
<rogpeppe> wallyworld_: luckily in go we don't need to use in-band signalling so much
<mattyw> rogpeppe, ok - so the way it works now - it actually does a bzr branch locally (more or less)
<rogpeppe> wallyworld_: lots of things *can't* be nil (ints, strings, etc)
<wallyworld_> rogpeppe: yeah, i'm not sure if that's a cause or a consequence
<wallyworld_> in a true oo world everything can be nil
<wallyworld_> which sadly go is not
<rogpeppe> wallyworld_: i'm glad that we don't have nil everyewhere
<rogpeppe> wallyworld_: value types are ace
<rogpeppe> mattyw: go on
 * TheMue thinks back of his smalltalk time *sigh*
<mattyw> rogpeppe, that's right is it - more or less a bzr branch happens on the machine you run juju deploy on?
<rogpeppe> mattyw: i'm not sure it does; let me check
<rogpeppe> mattyw: no i don't think it does
<rogpeppe> mattyw: it pulls a charm bundle from the charm store (if the charm's not local)
<rogpeppe> mattyw: the charm bundle is a tgz file
<mattyw> rogpeppe, ok - and I believe that might be changing so that it happens on the state server instead of locally?
<rogpeppe> mattyw: if you do a deploy through the api, that already implements that logic, so nothing is created locally
<rogpeppe> mattyw: yes. except for local charms, which must be pushed up to the server
<mattyw> rogpeppe, ok - that's probably all I need for know - thanks very much - don't leave the country though
 * rogpeppe puts his passport down
<natefinch> fwereade: standup?
<mattyw> rogpeppe, when would you have a spare few minutes for a quick hangout?
<natefinch> mattyw: we're in a hangout right now, but should be done soon
<mattyw> natefinch, no problem I thought that was the case - just getting my booking in early ;)
<rogpeppe> mattyw: i'll just look at a review, have a bowl of cereal and then we'll do that
<mattyw> rogpeppe, ok - no particular hurry
<jamespage> anyone around with an azure account who could confirm https://bugs.launchpad.net/juju-core/+bug/1246320 with the juju-core package that's in saucy proposed? (details on how in the bug report)
<_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified <azure> <bootstrap> <verification-needed> <Go Windows Azure Client Library:Fix Committed by wallyworld> <juju-core:Fix Committed by wallyworld> <juju-core 1.16:Fix Released by wallyworld> <juju-core trunk:Fix Committed by wallyworld> <juju-core (Ubuntu):Fix Released> <juju-core (Ubuntu Saucy):Fix Committed> <juju-core (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/12
<rogpeppe> mattyw: you got a hangout location?
<natefinch> jamespage: I have an azure account, but limited time.  I could share my azure creds with you if that's helpful
<jamespage> natefinch, please
<jamespage> (its the last bug needing verficiation)
<natefinch> jamespage: sent
<rogpeppe> dimitern: responded to your review.
<dimitern> rogpeppe, i'm not entirely convinced
<dimitern> rogpeppe, if we're going to copy/paste stuff from the go source into our codebase, it should be consistent in formatting
<rogpeppe> dimitern: if we're copy/pasting something, it should be as identical as possible with the original so that when the original changes there are as few conflicts as possible
<dimitern> rogpeppe, if otoh we're going to follow possible go source changes and use/patch as needed when it changes, it doesn't belong in juju-core, but in an external package
<rogpeppe> dimitern: we've already got one precedent, in thirdparty/pbkdf2
<rogpeppe> dimitern: i don't want to add an external dependency for this
<dimitern> rogpeppe, which was done before we decided on the current rules of consistency
<rogpeppe> dimitern: i don't think that vendored code should be subject to the same rules
<dimitern> rogpeppe, I don't believe making our code messier is helpful for long-term maintenance
<dimitern> ;)
<rogpeppe> dimitern: it's not really our code
<rogpeppe> dimitern: it's their code + minimal patches to make it do what we need
<dimitern> rogpeppe, then what's wrong with an external dependency?
<rogpeppe> dimitern: it seems overkill to make a whole new project just for this. and i don't think it solves anything.
<dimitern> rogpeppe, call it code.google.com/rog/deepequals or something
<rogpeppe> dimitern: i don't see what issue it solves
<dimitern> rogpeppe, use an existing project then
<dimitern> rogpeppe, consistency
<dimitern> rogpeppe, that's what it solves
<rogpeppe> dimitern: i don't believe that consistency is an iron rule, particular in this kind of case
<natefinch> rogpeppe: I agree with dimitern... I think we put way too much under juju-core that should be independent projects
<dimitern> natefinch, +1
<dimitern> rogpeppe, we should be going leaner and more consistent, not the other way around
<natefinch> rogpeppe: this has nothing to do with juju specifically. It just happens to be useful for us.
<rogpeppe> dimitern: i'd prefer us to have less dependencies not more
<rogpeppe> natefinch: true, but i don't think that's a bad thing
<dimitern> rogpeppe, complex projects like juju are composed of many dependencies
<dimitern> rogpeppe, nothing wrong with that, it's a better design, cleaner
<natefinch> rogpeppe: dependencies shouldn't be a problem.  If they are, we should address that, but I don't think they are.
<rogpeppe> dimitern: the less dependencies, the less fragile IMO
<dimitern> rogpeppe, i disagree
<natefinch> rogpeppe: true for dependencies not controlled by us.  But we do control this one.
<rogpeppe> dimitern: it's a fundamental truth
<rogpeppe> dimitern: even if we do control the dependency, it's one more entity to manage
<dimitern> rogpeppe, smaller, better organized chunks that are internally consistent and do best one or a few things is better than a monolithic whole
<dimitern> rogpeppe, what's wrong with managing more?
<rogpeppe> dimitern: it's not monolithic - we're organised into independent package within juju-core. i really don't see the problem here.
<rogpeppe> dimitern: more work to do
<jamespage> natefinch, thanks
<dimitern> rogpeppe, we're coming the the old discussion of "why having a huge package like state with no internal substructure is worse than smaller, well-defined packages"
<dimitern> rogpeppe, less is more in this case
<rogpeppe> dimitern: i think that's a different issue actually
<natefinch> rogpeppe: for this particular case in question... it's a very well-defined project that does one thing and does it well and is unlikely to see a lot of churn.  in this case, the overhead of creating and maintaining a project should be minimal.
<dimitern> rogpeppe, it's true we were not always following the principle of "what's in juju-core is juju related", but we can improve on that by not making it worse
<rogpeppe> natefinch: that's an argument for moving all of testing/checkers into an external package
<rogpeppe> natefinch: which might be a reasonable thing to do
<natefinch> rogpeppe: I was actually just thinking that
<dimitern> rogpeppe, i'm not arguing just for the sake of it - this specific case is a trivial example, but shows a fundamental design issue with many parts of the codebase, which have not place in the main code base
<dimitern> rogpeppe, i agree to moving checkers outside
<rogpeppe> dimitern: for me, it depends if some other project might want to use those parts
<dimitern> rogpeppe, it doesn't really matter
<dimitern> rogpeppe, what matters is to make our life easier by removing reusable chunks like that, not specific to juju, even if noone else uses them
<rogpeppe> dimitern: there *is* overhead in maintaining an external project dependency
<rogpeppe> dimitern: i don't see how it makes *anything* easier
<dimitern> rogpeppe, and doing so will make them more likely to be reused, than if there are in juju
<rogpeppe> dimitern: perhaps we don't want them to be reused
<dimitern> rogpeppe, what's the overhead of maintaining a set of reusable, well-defined helpers, like the checkers, which certainly do not change often
<rogpeppe> dimitern: because if something is reused by external code, then we're not nearly as free to change if if our requirements change
<rogpeppe> dimitern: non-zero
<dimitern> rogpeppe, we can't stop them from being reused, even now, but it's not obvious
<dimitern> rogpeppe, not true - we still control the external project
<rogpeppe> dimitern: that's true
<natefinch> rogpeppe: that is an interesting point, about having to worry about external use.... keeping stuff in juju-core means we can hack at it any way we like, since no one in their right mind would link against anything under juju-core
<dimitern> rogpeppe, by your logic goose should've been part of juju-core
<rogpeppe> natefinch: well, i kinda hope that people will in time, but that's a different issue
<dimitern> rogpeppe, or the gomaasapi - who else uses them?
<rogpeppe> dimitern: goose should be useful by other people wanting to use openstack, just like goamz is useful by other people wanting to use aws
<rogpeppe> dimitern: same there
<natefinch> rogpeppe: only for juju-specific stuff.  Anything else could break at any time, since it's so deep in our codebase
<dimitern> rogpeppe, right, and a set of comprehensive checkers, that have nothing to do with juju in particular, also
<natefinch> rogpeppe: I think this and the checkers are a good example of prime subjects for extraction.... because they're well defined and no going to have their interfaces change
<rogpeppe> dimitern: except i don't want us to depend on 100 external projects, each created just because it was possible to factor them out
<dimitern> rogpeppe, why?
<dimitern> rogpeppe, that's the main issue of argument
<rogpeppe> dimitern: because i don't think it helps anything
<dimitern> rogpeppe, i don't think we're getting anywhere here
<dimitern> rogpeppe, ;)
<rogpeppe> dimitern: yeah, i guess
<natefinch> dimitern: I think it's valid to say that there is an expectation of API compatibility in independent projects that we don't have under juju-core.  Stuff under juju-core is sort of assumed to be part of a larger project and not intended for independent consumption
<rogpeppe> natefinch: +1
<rogpeppe> natefinch: *particularly* for stuff under testing...
<dimitern> rogpeppe, you're generalizing a specific case where using an external dep is a good thing
<natefinch> rogpeppe: but that being the case, the checkers and your lax deepequals are still things that probably are fine and good to have as independent packages
<dimitern> rogpeppe, i'm not saying "let's have 100 deps", i'm saying let's apply some common sense
<rogpeppe> dimitern: i haven't seen a single argument as to *why* using more external deps is a Good Thing
<dimitern> natefinch, exactly
<natefinch> rogpeppe: it makes us better open source citizens and helps out fellow go programmers, including people from Canonical
<dimitern> rogpeppe, code describes linked concepts and abstractions, all related
<rogpeppe> natefinch: ok, that's a good argument
<rogpeppe> dimitern: that's too abstract for me
<dimitern> rogpeppe, if they're not related, they shouldn't be coupled together
<rogpeppe> dimitern: that sounds like a statement of belief, not an actual practical reason
<dimitern> rogpeppe, would you put a wordprocessor and a database in the same codebase, if they just happen to connect sometimes, but can operate totally independently?
<natefinch> rogpeppe: definitely we have to be pragmatic. We can't sacrifice our own flexibility... but we're not saying that... just saying, if it's not going to cause much pain and someone else might want to use it, then make it an external project
<rogpeppe> dimitern: quite possibly
<dimitern> rogpeppe, ok, no point to argue further
<dimitern> rogpeppe, you simply refuse to see my point :)
<rogpeppe> dimitern: i see that you strongly believe in that principle
<rogpeppe> dimitern: but i believe in pragmatism, not principles
<dimitern> rogpeppe, yes, i do, because of experience (bad usually) - what happens with large projects with fuzzy boundaries, things that shouldn't be together but historically are kept like that and coupled even further, which makes refactoring difficult
<rogpeppe> natefinch: i definitely buy that argument. by that argument, we could easily factor out the checkers, cloudinit, maybe the rpc package and some others too
<rogpeppe> dimitern: i'm not sure those historical arguments apply here, as the go package system is strongly boundaried and non-circular
<natefinch> rogpeppe: seems like the good open source thing to do
<dimitern> rogpeppe, putting independent things together, just for the sake of convenience, in my experience ever so slightly tends to couple them more and make them less independent
<rogpeppe> dimitern: there's nothing about having something in an external project that means that things are easier to refactor
<rogpeppe> dimitern: decoupling is good, no question
<rogpeppe> dimitern: but whether two packages are in the same project is orthogonal to how coupled they are
<dimitern> rogpeppe, no it's not - because they can change together and that's a temptation too big to resist to couple them over time
<dimitern> rogpeppe, anyway, we veered of way off track
<rogpeppe> dimitern: goose is way too strongly coupled with the openstack provider
<rogpeppe> dimitern: the fact that they're in separate projects doesn't really help in that refard
<rogpeppe> regard
<rogpeppe> dimitern: conversely the rpc package isn't strongly coupled with any other package outside rpc. we can maintain dependency hygiene inside juju-core too, and we really should.
<dimitern> rogpeppe, lgtm, just to have it landed, even with these minor inconsistencies
<rogpeppe> dimitern: thanks
 * TheMue => lunch
<rogpeppe> dimitern: i hope you can see where i'm coming from, even if you might not agree :-)
<dimitern> rogpeppe, I see, I hope you can see my point as well
 * dimitern gets hungry when arguing like that :)
 * dimitern -> lunch as well
<rogpeppe> dimitern: i hear it, but i can't *feel* it in the same way as you...
<rogpeppe> dimitern: enjoy!
<dimitern> rogpeppe, thanks :)
<rogpeppe> hmm, this has some test failures i've never seen before: https://code.launchpad.net/~rogpeppe/juju-core/467-checkers-deepequals/+merge/196247
<rogpeppe> ... Panic: Couldn't create temporary directory: mkdir /tmp/gocheck-5074209722772702441: file exists (PC=0x413D01)
<rogpeppe> how could that happen?!
<jam> rogpeppe: gocheck is broken
<rogpeppe> jam: oh, that's not good
<jam> rogpeppe: it doesn't seed its random number generator
<jam> so after 100 temp directories get created, it "runs out"
<rogpeppe> jam: ha ha
<jam> rogpeppe: I'll clean it up, I would say gocheck should be fixed, but it keeps us from leaking *too* many
<rogpeppe> jam: is that actually a problem with ioutil.MkTempDir() ?
<jam> rogpeppe: so MkTempDir wouldn't run out after 100 tries like gocheck's internals
<jam> but we would still be leaking dirs (I think)
<jam> rogpeppe: and filling up /tmp with dirs is a good way to slowly kill your machine
<jam> so I haven't "fixed" gocheck
<rogpeppe> jam: ioutil.TempDir does seed properly anyway
<rogpeppe> jam: could you clean up those tempories please then, before my branch dies again? (perhaps you have, in which case thanks!)
<jam> rogpeppe: i did
<rogpeppe> jam: cool
<jam> rogpeppe: ideally we'd figure out why we're leaking dirs, fix that, end then fix gocheck to use ioutil.TempDir
<rogpeppe> jam: that would indeed be good
<rogpeppe> jam, dimitern, fwereade, TheMue, wallyworld_, mattyw: FYI i'm going to be travelling this afternoon. i'll be working on the train, but probably with only partial internet connectivity
<fwereade> rogpeppe, cool, enjoy your travels
<rogpeppe> i leave in about 2 hours
<TheMue> rogpeppe: ok, enjoy
<rogpeppe> fwereade: did you manage to take a look at https://codereview.appspot.com/30390043/ BTW?
<rogpeppe> fwereade: i've also got https://codereview.appspot.com/30900043 which does the txn-revno changes we discussed
<fwereade> rogpeppe, not enough of it yet
<rogpeppe> fwereade: (please ignore the testing/checkers changes in that branch - i don't know why they're there, as i included the other branch as a prereq)
<rogpeppe> fwereade: ok, np
<fwereade> rogpeppe, no worries
<mattyw> rogpeppe, going anywhere nice?
<rogpeppe> mattyw: up to edinburhg
<rogpeppe> gh
<mattyw> rogpeppe, that is nice - enjoy
<rogpeppe> mattyw: there's a fiddle festival on. lots and lots of trad tunes!
<mattyw> rogpeppe, excellent! going for the weekend?
<rogpeppe> mattyw: aye
<mattyw> rogpeppe, scotsfiddlefestival.com?
<rogpeppe> mattyw: that'll be the one
<mattyw> rogpeppe, who are you looking forward to seeing most (which ones should listen to)
<rogpeppe> mattyw: Frigg are excellent, though I've seen 'em before
<rogpeppe> mattyw: mostly i'm going for the crack
<rogpeppe> mattyw: lots of sessions and late nights
 * rogpeppe goes to lunch
<rick_h_> morning sinzui, can I get a few min hangout time today at your leisure?
<sinzui> sure
<sinzui> I am free at the top of the hour rick_h_
<rick_h_> sinzui: sounds good, thanks
<jcastro> sinzui, for your consideration sir! https://bugs.launchpad.net/juju-core/+bug/1254061
<_mup_> Bug #1254061: Add bash completion for OSX  <juju-core:New> <https://launchpad.net/bugs/1254061>
<sinzui> oh, I might be able to to that mysel
<sinzui> f
<natefinch> niemeyer: just wanted to mention I got that code working yesterday.  Thanks for the help.
<rick_h_> sinzui: hit me up with an invite when you're free. Thanks.
<sinzui> rick_h_, https://plus.google.com/hangouts/_/7ecpigc90pv2nkor675dm9p9oo?hl=en
<natefinch> hey rogpeppe, I don't think I can go through with making the public struct for replica set members and a private one for marshaling.  It just complicates the code too much, plus we lose information in the translation about what values are actually set in the database versus which are being defaulted.  The code is so much cleaner and easier to understand just using pointers to the optional values.
<rogpeppe> natefinch: i actually think that not providing that information could be considered a positive thing
<rogpeppe> natefinch: it means that the user doesn't have to know what a missing value means
<rogpeppe> natefinch: but i do appreciate what you're saying.
<rogpeppe> natefinch: i can't decide which comes first: a package that's easy and intuitive to use, or one that's simpler maps closely to the underlying transport
<natefinch> rogpeppe: I actually think that the pointers are simpler to use. You don't have to use some default value struct to create new members
<rogpeppe> natefinch: but you do have to create variables for all your fields so you can make pointers to them...
<natefinch> rogpeppe: yes, but most of the optional fields aren't going to be used often, and it's not really that hard to make a f := false and use &f for the value
<rogpeppe> natefinch: is it really that awkward to have a couple of functions for each type, doing the translation in each direction?
<rogpeppe> natefinch: but if you really feel strongly, as it seems you do, then do it the way you feel like
<natefinch> rogpeppe: it's not the translation that is awkward, it's the fact that we lose whether or not a value was intentionally set.... also the zero value of Member is then a generally broken value, so we need AddressToMembers and DefaultMember.  All that can go away if we just make people deal with the fact that there are some optional values on Member
<rogpeppe> natefinch: but the other side of the coin is that when reading a value, the package needs to know that a nil vote count actually means 1, for example
<rogpeppe> natefinch: and it won't print out very nicely, because it'll just print pointer values for all the fields
<natefinch> rogpeppe: we could make accessor methods that do the translation internally.  I know it's not ideal.
<rogpeppe> natefinch: and people will need to be careful with pointer aliasing
<rogpeppe> natefinch: gotta go right now, back in 5 when i'm on the train
<natefinch> rogpeppe: ok
<rogpeppe1> natefinch: sorry, intermittent connection here
<rogpeppe1> natefinch: last thing i saw was:
<rogpeppe1> [15:45:56] <natefinch> rogpeppe: it's not the translation that is awkward, it's the fact that we lose whether or not a value was intentionally set.... also the zero value of Member is then a generally broken value, so we need AddressToMembers and DefaultMember.  All that can go away if we just make people deal with the fact that there are some optional values on Member
<niemeyer> natefinch: Sweet
<natefinch> rogpeppe1: no problem.  That was pretty much it... we could make accessor methods that return the right defaults, but you're right about printing it out
<natefinch> rogpeppe2:  (retype of my last message) no problem.  That was pretty much it... we could make accessor methods that return the right defaults, but you're right about printing it out.  Seems like there's no real great way to do it while maintaining information about values that are unset.
 * rogpeppe3 has reached end of journey.
<rogpeppe3> i can say definitively that east coast wi-fi is terrible...
<rogpeppe3> happy weekends all
<hazmat> ? -> Copyright 2013 Joyent Inc.
<natefinch> hazmat: ?
<hazmat> natefinch, joyent provider has that, pretty sure that's not the intent for cla
<hazmat> contributor license agreement
<natefinch> hazmat: hah, I see.  Yeah, probably just old habit for them
#juju-dev 2013-11-24
<thumper> fwereade: if you come back, I'd love to chat
<hazmat> does manual provider on trunk work? bootstrap is fine, but subsequent connections stall out trying to resolve state instances in provider/common/state.go.. looking over the state content, it looks like manual provider is missing recording ips into state.
<thumper> hazmat: I thought it did, but I've not tried it
#juju-dev 2014-11-17
<davecheney> thumper: menn0 waigani i've been working on some visualisation tools to help me
<davecheney> https://twitter.com/davecheney/status/534135954420678656
<davecheney> here is an example
<davecheney> dealing with something the size of juju/state is still daunting
<waigani> nice!
<davecheney> that is cmd/juju
<davecheney> sorery
<davecheney> cmd/go
 * menn0 is still waiting for twitter to load the image
<waigani> davecheney: is that d3?
<menn0> wow that's awesome
<menn0> what are you using to do the rendering?
<davecheney> waigani: d3js.org
<waigani> thought so
<davecheney> http://imgur.com/t57nMob
<davecheney> ^ juju/state
<waigani> menn0: can I talk over the allwatcher store with you? I can see two ways to go
<davecheney> http://imgur.com/3oErTdQ
<davecheney> juju state, from the perspective of mgo/v2
<waigani> davecheney: omg...
<menn0> waigani: i was about to go for lunch...
<menn0> waigani: did you want to hangout/
<waigani> menn0: should be a quick question
<waigani> menn0: standup hangout?
<menn0> waigani: ok
<davecheney> http://i.imgur.com/ioxieyg.png
<davecheney> something to consider with the juju/version pacakge
<davecheney> http://imgur.com/d9xNtae
<davecheney> who's using loggo, and who isnt ...
<thumper> davecheney: so the picture is showing what?
<thumper> what are the lines?
<thumper> and how do you know?
<thumper> is there meaning to the relative thickness?
<davecheney> thumper: it's a bit hard to tell
<thumper> davecheney: it is almost like you need two graphs rather than one
<davecheney> i stole most of the code from an example comparing people who like different hair color
<davecheney> i'll keep working on it tonight
<thumper> kinda cool picture though
<davecheney> at leats it tells me who is relaed to what
 * thumper nods
<davecheney> like juju/version imports bson ...
<davecheney> http://imgur.com/UKYv5j3
<davecheney> this is all the things that importing juju/version brings in
<davecheney> which seems excessive
<davecheney> like why does juju/version depend on sync ...
<davecheney> http://imgur.com/nmfRE4r
<anastasiamac> davecheney: these look pretty!
<anastasiamac> davecheney: are they available on the fly?
<anastasiamac> davecheney: kinf of like "graph usage of blah"?
<anastasiamac> s/kinf/kind
<davecheney> anastasiamac: go get github.com/davecheney/junk/glyph
<davecheney> $GOPATH/bin/glyph
<davecheney> then go to localhost:8080/chord/cmd/go
<davecheney> it works just like godoc, the first url is the visualisation, the rest is a package path to start from
<davecheney> be warned
<davecheney> it is very very slow
<davecheney> took two minutes to generate the first image
<anastasiamac> davecheney: it's monday... i feel slow too :-)
<davecheney> i'm doing to much processing in the browser
<davecheney> i need to offload that to the backend
<anastasiamac> davecheney: thnx :-) visually seeing dependencies is enormously helpful!
<davecheney> that's why i built this
<davecheney> i need it to help me
<thumper> davecheney: juju/version brings in io (to read the file), io brings in sync
<thumper> davecheney: easy to pull in heaps
<davecheney> versino is also bringing in sync directly
<davecheney> which is odd
<davecheney> hmm
<davecheney> no it isnt
<davecheney> ok
<davecheney> i screwed up
<davecheney> doesn't surprise me
<thumper> davecheney: just checking that we both aren't sitting in a different hangout with the same name
<thumper> google gets things wrong occasionally
<davecheney> thumper: nope, my bad
<davecheney> i ingored the reminder
<davecheney> be there in a sec
<davecheney> thumper: http://godoc.org/github.com/juju/juju/state?import-graph
<davecheney> thumper: http://imgur.com/TT3xgeD
<davecheney> thumper: http://imgur.com/2iKJC2O
<thumper> davecheney: https://github.com/juju/errors/pull/13
 * thumper takes broken kid to physio
<menn0> waigani: http://reviews.vapour.ws/r/471/ reviewed
<axw> wallyworld_: when you have a minute, can you PTAL at http://reviews.vapour.ws/r/442/
<wallyworld_> sure
<axw> wallyworld_: I've parameterised the function to list block devices in worker/diskmanager.NewWorker
<axw> with a default
<axw> jujud tests now override that default
<wallyworld_> axw: looks good, now tests will pass in a container
<axw> yep
<axw> thanks
<waigani> menn0: thanks for the review. testing the constraints upgrade, I've expected three records because there is a preexisting environment constraints doc
<waigani> menn0: i.e. it has a local i.d. of "e" - the global env key
<thumper> wallyworld_: hey, can I get you to look at this for me? https://github.com/juju/loggo/pull/7/files
<wallyworld_> sure
<wallyworld_> thumper: the location stuff is just for tests to avoid hard coding line numbers?
<thumper> wallyworld_: exactly
<thumper> stolen from the errors tests, which I got from rog
<wallyworld_> can you add a doc comment then so the next person doesn't need to fiure it out?
<thumper> sure
<wallyworld_> also, i think then the test commnt is wrong
<wallyworld_> as it still mentions line number fragility
<thumper> ah... will fix
<thumper> wallyworld_: changes pushed
<wallyworld_> +1
<thumper> cheers
<menn0> waigani: of course... I didn't think of that
<waigani> menn0: cool, so good to ship?
<menn0> I think so
<menn0> just wondering if the test should check that the "e" key is still in good shape post migration
<menn0> waigani: ^
<waigani> menn0: shesh, just caught me - mouse was over the 'commit' button
<thumper> wallyworld_: and a useful one: https://github.com/juju/loggo/pull/6/files
<menn0> waigani: it's probably ok
<waigani> menn0: I do check that in TestAddEnvUUIDToConstraintsIdempotent
<waigani> menn0: so it is covered. good enough?
<menn0> waigani: so you do. that's great then. can you just add a comment with the assertion that check for a length of 3 to avoid confusion
<menn0> waigani: then merge away
<waigani> menn0: will do
<menn0> thumper: so State.NewEnvironment doesn't give you an environment you can do anything with
<thumper> no
<thumper> menn0: it just adds an environment into the collection
<thumper> menn0: happy if you want to change that
<thumper> menn0: it probably isn't used in many places
<wallyworld_> thumper: so how to developers decide to use the Stack vs non Stack variants of the various log methods
<wallyworld_> shouldn't they just use Warningf() and a log setting decides
<thumper> wallyworld_: if you are logging a message, you go `logger.Infof("some garbage")`
<menn0> thumper: it isn't used anywhere, except tests
<thumper> wallyworld_: the InfoStackf takes an error as the first param
<thumper> wallyworld_: magical introspection of the args... params would be a bit too magic
<menn0> thumper: so basically we need Initialize (in open.go) to happen afterwards right?
<thumper> wallyworld_: if you want the error stack logged, call the stack message
<thumper> menn0: if you want to use it, yes
<wallyworld_> ok
<wallyworld_> i'm not sure then we need all the variants
<thumper> wallyworld_: there are many many occurrances of logging where we go `logger.Warningf("something horrible: %v", err)`
<wallyworld_> would we really want to see a stack trace for an Info message
<thumper> I'm thinking that it would be `logger.WarningStackf(err, "something horrible")`
<thumper> wallyworld_: I don't want to make that call
<thumper> wallyworld_: someone may want a stack at a different level
<wallyworld_> if they need stack trace with an info there's something wrong
<wallyworld_> but ok
<wallyworld_> i think this will be absed
<thumper> abused?
<wallyworld_> yeah
<thumper> I'm not sure.. I guess time will tell
<menn0> thumper: Initialize doesn't quite work as it dials it's own mongo connection and create its own uuid etc
<wallyworld_> our log output will become oven more of a firehose
<thumper> I have a better one coming
<menn0> thumper: I will do some refactoring
<thumper> menn0: ack
<wallyworld_> thumper: what do we do when our log files are full of stack traces and even harder to read than they are now
<thumper> wallyworld_: I think this becomes one of those pragmatic things, don't record a stack for an expected error
<wallyworld_> i think we need x-team collaboration or a policy that reviewers are aware of so that this will not be misused
<wallyworld_> clear guidelines on what an "expected" error is
<wallyworld_> what's the driver for this?
<wallyworld_> is there an issue that is being solved?
<thumper> one of the issues was our logging, and that I was looking for occurrances of ": %v" in the codebase
<thumper> I saw that many were to log errors
<thumper> we now catch error stack info which is important for debugging
<thumper> that was the rationale
<thumper> wallyworld_: along with this one: https://github.com/juju/testing/pull/38/files
<wallyworld_> i content you don't need the error stack 99% of the time
<wallyworld_> and if you do, it is for debugging, and not warning or error or info output
<wallyworld_> i have very rarely if ever wished to have the stack trace when debugging a juju issue
<thumper> hmm...
<wallyworld_> sorry for being -1 on this, i just see a whole lot of extra logging for little benefit
<wallyworld_> but that's just IMHO
<thumper> I'm happy to hold off landing that one until we talk as a team through it more
<thumper> I can take it to the list
<wallyworld_> i'd personally be happier if this were a trace level thing that could be turned on when needed
<thumper> but probably tomorrow
<thumper> wallyworld_: or just a separate method:
<thumper> logger.StackTrace(err)
<thumper> although...
<wallyworld_> so long as it can be turned on/off
<thumper> I had thought of having other helper methods:
<thumper> one to get a limited stack trace of where you are
<thumper> the other to get the stack trace of the error you have
<wallyworld_> this could be useful when developing (not foe me, but others might like it)
<wallyworld_> but it should not get into our std log output by default
<wallyworld_> happy to concede if the majority want it
<thumper> I'll take this one to the list
<wallyworld_> ta
<thumper> the other is `jc.IsNil`
<wallyworld_> ok
<thumper> which does " if not nil, and it is an error, and it has a StackTrace method, show the stack trace in the test fail message"
<wallyworld_> now, that is useful
<thumper> which I have wanted for a while
 * thumper goes to make dinner for the little beings that live at his house
<wwitzel3> axw: can you take a look at https://github.com/juju/juju/pull/1157
<axw> looking
<axw> wwitzel3: I can't spot the problem that was fixed - can you please describe?
<wwitzel3> axw: well this was actually done before you merge landed adding in the break.
<waigani> wtf?
<axw> wwitzel3: so is this really necessary then? there are tests for zone selection already, TestStartInstanceDistribution.*
<waigani> I just merged trunk and pushed my diff up to RB. What should be a four line diff has turned into a 400 line diff.
<axw> also, the "continue" in the refactored function should still do an index check, otherwise the message is wrong on the last iteration
<waigani> http://reviews.vapour.ws/r/473/diff/
<wwitzel3> axw: well I think the refactor is better, since it extracts the concern out of a big monolithic method and helps to isolate the testing :)
<waigani> other than the megawatcher changes, none of those changes are mine.
<axw> wwitzel3: yes, that is a fair point
<waigani> from this branch at least
<wwitzel3> axw: yeah, I think that got clipped out in a merge, I just noticed that
<wwitzel3> axw: I wanted you to give me a review on it since you did the code, but I'd stil like to land it
<axw> wwitzel3: sure. LGTM with the continue condition readded
<davecheney> http://imgur.com/94R6MwG
<davecheney> the agent package is a bit of a beast
<wwitzel3> axw: on the condition, is can I use <= instead of i+1 < ?
<axw> wwitzel3: that's fine with me
<wwitzel3> axw: k, yeah, that is what I changed, but I think I foobar'd a merge and ended up squashing the entire if block :/
<axw> davecheney: looks like a DHT; it's got some extra deps in case someone removes one ;)
<wwitzel3> axw: thanks, addressed both of those
<axw> wwitzel3: thanks for making it better :)
<axw> wwitzel3: did you figure out that latest MAAS provider bug btw? last I looked you couldn't repro
<waigani> menn0: something between git, github and RB crapped itself along the way, so new PR: http://reviews.vapour.ws/r/474/
<wwitzel3> axw: yeah, the bug was their code didn't have the back port of the "break" yet.
<wwitzel3> axw: so instead of stopping after finding the right zone, it just kept running until the last zone.
<wwitzel3> axw: and it just happened their last zone was full
<wwitzel3> axw: I couldn't repo at first because my last zone had a free slot.
<axw> wwitzel3: ahh I see, thanks
<wwitzel3> axw: now I just have to figure out why my test fails on the bot , but works locally :( .. sad day, guess I will save that for tomorrow
<axw> wwitzel3: nothing jumps out
<anastasiamac> axw: could u plz clarify juju convention when creating pair of corresponding commands?
<anastasiamac> axw: do they sit in one file like in environment.go - set/unset
<anastasiamac> axw: do they sit in different files like addmachine.go and removemachine.go?
<axw> anastasiamac: I think most people prefer one command per file
<anastasiamac> axw: sorry ;-(
<anastasiamac>  set/get for environment
<anastasiamac> axw: k.. one file  is gr8 ;-)
<anastasiamac> axw: thnx
<axw> anastasiamac: nps
<anastasiamac> axw: so where would u put shared functionality?
<anastasiamac> axw: i'd like to avoid duplicate code
<axw> anastasiamac: I'd just stick all common functionality in one or the other, doesn't matter which... just as long as it's together
<anastasiamac> axw: k. sure :-) thnx
<wallyworld_> jam: you ok for the juju status meeting later?
<jam> wallyworld_: I should be able to be around
<wallyworld_> great, we need to get the spec approved, and there's a fair bit of disagreement
<axw> dimitern: why does goamz use a different API version for RunInstances when specifying VPC attributes? were you being paranoid, or is there actually different behaviour?
<dimitern> axw, because the VPC API is a newer version than the classic api it otherwise uses
<dimitern> axw, and yes, I was being a bit paranoid :)
<axw> dimitern: I realise.. I meant, why not use the newer version on all
<axw> ok
<axw> dimitern: I'm just asking because I'm going to have to bump the version we use to support allocating additional EBS volumes
<dimitern> axw, sure, if you need to, but please sync up with niemeyer
<axw> dimitern: will do
<jam> wallyworld_: any news about the remaining critical bugs ? Do you need some extra manpower to work on them ?
<jam> like https://bugs.launchpad.net/juju-core/+bug/1392544 isn't assigned yet
<mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
<wallyworld_> jam: i poked tim about bug 1392745 as i suspect he'll be across it, but he deferred till tomorrow
<mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
<wallyworld_> the local provider one i'm going to start looking at
<wallyworld_> the default value one is not assigned yet, if you had someone who could look that would be good
<wallyworld_> otherwise i'll do tomorrow
<jam> wallyworld_: k, if you want someone on my team, I'm perfectly happy having us polishing a release branch
<wallyworld_> ok, thanks, maybe the default value one then
<mattyw> morning all
<jam> wallyworld_: k, I'm not sure if they'll get up to speed before someone like Tim could fix it, but I can get them started.
<wallyworld_> jam: tim will do the 1.20.11 juju run one
<wallyworld_> i haven't look in default at the default value one
<wallyworld_> in detail
<jam> ah, ok
<wallyworld_> bug 1392544 should just be some generic snafu maybe
<mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
<jam> wallyworld_: yeah. It looks like something is casting everything to a generic boolean type
<jam> wallyworld_: I've tasked dimitern with it
<wallyworld_> the other one - the local provider log issue - is likely tim's aread also, but i'll did into it
<wallyworld_> ty
<wallyworld_> and the maas one is well in hand
 * fwereade_ was up late last night, is going for a bit of a walk before he starts properly
<axw> fwereade_: when you have started, if you have some time would you please take a glance over https://github.com/juju/charm/pull/77? doesn't need to be a full review, but I'd like to know if you have had differing thoughts on how the storage metadata should look
<dimitern> fwereade_, ping
<fwereade_> dimitern, pong
<dimitern> fwereade_, re https://bugs.launchpad.net/juju-core/+bug/1392544 - what's the purpose of the "default: true|false" field in juju get svcname output?
<mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged by dimitern> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
<fwereade_> dimitern, it tells you whether it's that value because [nothing was set, and it will therefore change if there's a charm upgrade that changes the default] or [that's the actual value that was explicitly set, even if it happens to match the default, and will persist so long as there's a matching config entry]
<jam> TheMue: voidspace: standup ?
<dimitern> fwereade_, so if "default: true" it means yeah the respective config setting is not set (i.e. uses the default value) ?
<fwereade_> dimitern, yeah
<fwereade_> dimitern, looking at that bug I suspect it's a documentation issue more than anything
<dimitern> fwereade_, it seems to me as well, but I'll do a quick test to make sure we don't set default: true for non-default values
<fwereade_> dimitern, thanks
<fwereade_> dimitern, don't close the bug without fixing the docs, though, please :)
<voidspace> jam: oops
<voidspace> jam: omw
<dimitern> fwereade_, sure
<fwereade_> dimitern, <3
<jam> fwereade_: so for compat reasons, can we ever change that to "is-default" rather than "default" confusing people ?
<fwereade_> jam, yes and no. no for `juju get`; yes for `juju service get`, which I'll need to sync up with thumper on
<fwereade_> jam, however, for `juju service get` we really want the default output to be something we can pass back into `juju service set`
<fwereade_> jam, so a sane implementation would probably just skip the ones with default values
<fwereade_> jam, and a --schema flag or something could tell you what the defaults were
<jam> fwereade_: we *could* have that as "--as-set" or some other flag that indicates the output you want. I think you *do* sometimes want to see what the value is, even if you haven't set it
<fwereade_> jam, that is not perfect for sure
<jam> I've used it often to figure out what I *could* set
<fwereade_> jam, I agree we do
<jam> fwereade_: you'd prefer the minimal form as the default output ?
<fwereade_> jam, but the asymetry between get and set is really kinda nasty
<fwereade_> jam, I *think* so, yeah -- in my mind the main tension is in what happens if you get, upgrade, set
<fwereade_> jam, and whether that final set shoudl change values or not
<fwereade_> jam, (assuming it's not rendered irrelevant by the original get having values that are invalid/unknown post-upgrade
<fwereade_> )
<fwereade_> jam, not saying it should be *hard* to see the possibilities, but I don't think it's the *most* important thing
<jam> fwereade_: well, I do think it is the primary use case of get, isn't it ? (what are all the current settintgs)
<jam> fwereade_: or do you feel it is more the way you transfer settings to some other place
<fwereade_> jam, `get --all` feels appropriate for "and include the defaults please" -- it's more consistent with charm-side config-get apart from anything else
<fwereade_> jam, and `get --schema` feels appropriate for "tell me what the possible keys and their meanings are"
<fwereade_> jam, and I'm not automatically opposed to some nice human-readable combination of the two
<fwereade_> jam, but it feels like a lot of disparate info to cleanly fit into the default output
<fwereade_> jam, that's what we signally failed to do with the current implementation ;)
<perrito666> morning
<dimitern> fwereade_, so it does work - setting a service config setting to a non-default value causes juju get svcname to *not* include "default: true" for that setting
<fwereade_> dimitern, that's good anyway
<fwereade_> dimitern, not really much less confusing
<fwereade_> dimitern, but at least working as intended
<dimitern> fwereade_, so what do you suggest to add to juju help get to clarify the behavior?
 * fwereade_ looks at documentation for `juju get`
<fwereade_> dimitern, um, some documentation ;p
<dimitern> fwereade_, because this is what I think the "fix" for that bug
<fwereade_> dimitern, concur
<dimitern> fwereade_, barely :)
<fwereade_> dimitern, seriously, all it has is a "purpose"
<fwereade_> dimitern, give it a Doc as well
<dimitern> fwereade_, yeah, a lot of commands (simpler ones) are like that
<fwereade_> dimitern, indeed
<fwereade_> dimitern, this is not actually a good thing ;)
<dimitern> fwereade_, ok, I'll describe the output in the Doc of get
<fwereade_> dimitern, cool, thanks
<dimitern> fwereade_, trivial review (mostly proof-reading I guess) ? https://reviews.vapour.ws/r/477/diff/
<fwereade_> dimitern, ship it
<dimitern> fwereade_, cheers!
<fwereade_> dimitern, hey, btw, apparently malta played football against bulgaria and didn't lose, I feel quite unwarrantedly smug on behalf of my place of residence
<dimitern> fwereade_, :) yeah, I've heard of that
<dimitern> fwereade_, and also BG won 2nd place in the kids eurovision in malta
<fwereade_> dimitern, cool, I didn't know that until today either :)
<dimitern> fwereade_, btw can you actually click on Ship it! ? :)
<dimitern> fwereade_, ah, sorry - I've just seen it, it must've been lagging behind
<dimitern> niedbalski, ping
<dimitern> voidspace, jam, can any of you please approve https://reviews.vapour.ws/r/478/ ? it's the same fix for bug 1392544, this time for master
<mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1392544>
<voidspace> dimitern: looking
<dimitern> voidspace, ta
<voidspace> dimitern: lgtm
<dimitern> voidspace, thanks
<dimitern> voidspace, did you click "Ship It!" btw?
<voidspace> dimitern: yes
<voidspace> dimitern: I really did
<voidspace> dimitern: I've done it twice, but it doesn't seem to be showing up
<dimitern> voidspace, yeah, weird...
<voidspace> dimitern: I got an "untrusted connection" warning when I went to RB too
<dimitern> voidspace, anyway, ta, I'll ping eric later about this
<voidspace> dimitern: if I use http it works
<voidspace> dimitern: https fails
<voidspace> odd
<voidspace> dimitern: Ship It! now visible anyway
<dimitern> voidspace, ha! I've seen this as well - using https I had to add an exception because the cert was self-signed most likely
<voidspace> dimitern: yeah, I added the exception ok
<voidspace> dimitern: but if I use https then ship it doesn't work
<dimitern> voidspace, really odd
<voidspace> rogpeppe3: ping
<voidspace> rogpeppe2: ping
<voidspace> rogpeppe1: ping
<rogpeppe3> voidspace: pong
<voidspace> rogpeppe3: hello Roger
<rogpeppe> voidspace: hiya
<voidspace> rogpeppe: morning
<rogpeppe> voidspace: how's it going?
<voidspace> rogpeppe: is there a tool for applying changes  to go code that works by ast rewriting
<voidspace> rogpeppe: like "go fix" but a general tool
<rogpeppe> voidspace: gofmt :)
<voidspace> rogpeppe: ah!
<voidspace> rogpeppe: cool, thanks
<rogpeppe> voidspace: check out gofmt -r
<voidspace> rogpeppe: all is good, how's you?
<rogpeppe> voidspace: but it depends what you want to do
<voidspace> rogpeppe: do I need "gofmt" rather than "go fmt"
<rogpeppe> voidspace: excellent, thanks
<rogpeppe> voidspace: go fmt invokes gofmt
<voidspace> rogpeppe: I want to rename an Interface method and all uses
<voidspace> rogpeppe: ah, ok - I understood there were some historical differences
<rogpeppe> voidspace: you possibly want to (brand new) gorename tool actually
<rogpeppe> voidspace: the interface to go fmt is in terms of packages; the interface to gofmt is stdin/stdout and files
<voidspace> rogpeppe: ok
<rogpeppe> voidspace: i haven't succeeded in using it on a large code base yet though
<voidspace> rogpeppe: ah :-)
<rogpeppe> voidspace:  but take a look at https://groups.google.com/forum/#!topic/golang-nuts/96hGPXYfqsM
<voidspace> rogpeppe: I'm there already
<rogpeppe> voidspace: if the method name is distinctive, then gofmt -r will probably do your job ok
<voidspace> hmmm... gorename can't find the environs package it seems
<voidspace> I'll try go fmt
<wallyworld> jam: meeting?
<jam> wallyworld: omw
<jam> wallyworld: .... firefox just froze, be there in a sec
<wallyworld> np
<voidspace> dimitern: when you get a chance http://reviews.vapour.ws/r/479/
<voidspace> dimitern: it builds fine (so is probably correct), just running all tests
<voidspace> dimitern:  I used gofmt, but ended up having to use sed to fix comments (and then manually unfix some of things sed did)
<voidspace> dimitern: so I might as well just have started with sed...
<dimitern> voidspace, :) ok, looking
<voidspace> dimitern: ooh
<voidspace> dimitern: "Subnets returns basic information about all networks known"
<voidspace> dimitern: should probably be
<voidspace> dimitern: Subnets returns basic information about all subnets known
<voidspace> dimitern: I'll make that change
<dimitern> voidspace, yeah, I've just added a comment for this
<voidspace> dimitern: pushed
<voidspace> dimitern: I don't think you've published that comment yet anyway
<dimitern> voidspace, LGTM, just sent my comment
<voidspace> dimitern: cool, thanks
<dimitern> voidspace, a bit of a problem
<dimitern> voidspace, did you remember to rename ListNetworks to Subnets in environs/interface.go ?
<dimitern> voidspace, because I see lots of build errors like *joyentEnviron does not implement environs.Environ (missing ListNetworks method)
<dimitern> voidspace, I can't even say how this managed to land, because it does not build :)
<dimitern> voidspace, ah, sorry - something was messed up with my local git repo - now it seems to work and there are no failures
<sinzui> wwitzel3, is bug 1392390 not fix committed in master?
<mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Fix Committed by wwitzel3> <juju-core 1.21:In Progress by wwitzel3> <https://launchpad.net/bugs/1392390>
<rogpeppe> fwereade_: do we check anywhere that a charm must have an install and/or a start hook?
<fwereade_> rogpeppe, nope
<rogpeppe> fwereade_: ok, cool
<rogpeppe> fwereade_: i could've sworn it did, but couldn't find the code
<wallyworld> wwitzel3: is nate around?
<jw4> mgz, wallyworld out of disk space on CI build server?
<wallyworld> jw4: just retry
<jw4> kk
<jw4> tx wallyworld
<wallyworld> happens sometimes :-(
<jw4> :)
<wallyworld> perrito666: when wwitzel3 or nate are around, could you mention bug 1392602 - i cannot find wtf is happening. it could be related to recent logging work, but i'm not sure. maybe they will have an idea
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<mgz> jw4: it's still not clear what triggers that failure... but just retrying works
<jw4> mgz: yeah weird.  I've $$retried$$ and so far it's looking good
<jw4> mgz: tx
<jw4> mgz: derp... now I get "failed to find "mongod"
<mgz> >_<
<voidspace> fun
<mgz> jw4: I'll investigate, also seems like an 'ec2 is ill' type of issue
<jw4> bummer
<jw4> thx mgz
<jw4> mgz: shall I $$retry$$ or wait?
<mgz> jw4: this one is just "no reachable servers" no? an intermittent test failure.
<jw4> mgz: yeah
<mgz> though... I agree I've not seen MongoSuite.TestAddRemoveSet fail quite like that before
<jw4> mgz: lol it was because the build number was '1337'
<jw4> ;)
<mgz> http://paste.ubuntu.com/9057111/
<mgz> jw4: send it through again
<jw4> k
<wwitzel3> sinzui: it is fix commited in master, I am getting the patch up for 1.21 now, not sure how it go reverted in lp, probably my fault :)
<sinzui> wwitzel3, thank you for following up
<perrito666> wwitzel3: natefinch ericsnow Ill be a couple of mins later, I am hogging my bw with a deploy
<natefinch> k
<natefinch> wwitzel3: ping?
<wwitzel3> natefinch: yep, sorry
<sinzui> natefinch, I think bug 1392745 needs to attention, can you find someone to look into it? I amd jjo can gather information as needed
<mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
<sinzui> natefinch, and I can offer access the the juju-ci3 env if someone needs to be on an affected env
<mgz> jw4: you're a lucky one today
<mgz> latest run, not seen a failure on this test before...
<mgz> FAIL: metricmanager_test.go:20: MetricManagerSuite.TestRunner
<mgz> looks like it's timing dependent though
<mgz> jw4: test you added, so probably needs fixing?
<mgz> wait... is that run not yours? I am confused
<mgz> mattyw: ^
<mattyw> mgz, ah shit - I'll take a look, didn't realise that test had landed yet - probably only landed 10 minutes ago
<jw4> hmm; I'll investigate... I don't think it was mine
<mattyw> mgz, jw4 it's all good
<mattyw> mgz, jw4 it's failed trying to land the branch that test was added in - so the tests are doing their job
<jw4> mattyw: cool, tx!
<jw4> I'll try mine again for the fourth time
<mattyw> jw4, I don't think you'd have seen that error? looks like my branch hasn't landed
<jw4> mattyw: right - my integration builds were failing due to space issues on the ci server
<mgz> yeah, I'd just assumed the in-progress landing was jw4's again, but it was mattyw's, hence the confusion, sorry :)
<jw4> mgz: no worries - nice chat :)
 * perrito666 is told that amazon will actually ship ram to his country without the 1 month wait in customs and he grins
<mgz> perrito666: real live rams?
<perrito666> mgz: well, they will be alive when shipped
<perrito666> rick_h_: btw, I loved the composition on rog/uros pic on your post
<rick_h_> perrito666: ty :) was playing with my fancy lens during the sprint a lot
<voidspace> anyone here familiar at all with gomaasapi ?
<perrito666> voidspace: I have been around there but most likely dont hve enough info to help youi
<voidspace> perrito666: :-)
<voidspace> perrito666: I need to call the api to claim a static ip address
<perrito666> voidspace: just ask the question and we can see
<voidspace> I am doing...
<voidspace> perrito666: I believe it looks like the following
<voidspace> ipaddresses := environ.getMAASClient().GetSubObject("ipaddresses")
<voidspace> _, err = ipaddresses.CallPost("", params)
<voidspace> (response is not useful - either it succeeds or we get an error)
<voidspace> perrito666: it's that empty string as the first argument to CallPost that bothers me
<voidspace> perrito666: that's the "operation" parameter
<voidspace> perrito666: but there's no operation here
<perrito666> voidspace: ah I have dealt with it
<voidspace> it's a post to the ipaddresses api end point
<voidspace> perrito666: right - have you called any endpoints without operations?
<perrito666> voidspace: you are dealing with a restful api there you not always have an op
<voidspace> it looks odd
<voidspace> perrito666: right
<voidspace> I guess I have to try it :-)
<voidspace> perrito666: I have a working maas server - I'll whip up some code to check it
<voidspace> perrito666: thanks anyway
<perrito666> voidspace: so iirc that translates to /path/to/node?operation
<voidspace> perrito666: this particularcall is directly paddresses/
<voidspace> no operation and no node id
<perrito666> voidspace: ahh addresses yes, that one is specially ugly
<perrito666> hold a sec, I was around there not long ago
<voidspace> perrito666: ooh, I might be wrong
<voidspace> perrito666: the GET is without an operation
<voidspace> perrito666: looks like it's "reserve"
<voidspace> POST /api/1.0/ipaddresses/ op=reserve
<voidspace> my mistake then :-)
<perrito666> voidspace: you did look at http://maas.ubuntu.com/docs/api.html#ip-addresses right?
<voidspace> perrito666: I did...
<voidspace> perrito666: I think I looked at the GET by mistake :-D
<voidspace> just looked now and seen "reserve" is the op...
<voidspace> perrito666: thanks
<perrito666> voidspace: heh yes, happened to me too :p also there are a few with similar names so beware of not getting the wrong endpoint :p
<katco> hey, go question: with a map, do you think it would be better to delete keys, or nil out their values? i would think that if the key had a good chance of being re-inserted, you'd want to nil out the value so the hash wouldn't continually be recomputed. thoughts?
<mgz> katco: if it's not a giant map, I wouldn't worry about resizing
<mgz> so, likely deleting makes better logical sense and is less likely to result in surprising bugs
<katco> mgz: kind of thinking that as well
<katco> mgz: b/c i would expect for people to be checking for "ok", not != nil
<mgz> yup
<katco> cool, ty sir!
<katco> mgz: you've given me the confirmation bias that upholds my world-view! ;)
<mgz> :)
<natefinch> katco: definitely delete.  Don't prematurely optimize... just do the most simple and straightforward thing .
<katco> natefinch: i recognize and applaud your agreement with me.
<katco> natefinch: seriously, thanks for chiming in ;)
 * natefinch is the king of chiming in. ;)
<katco> haha
<voidspace> g'night all
<bodie_> if I find that I keep needing to repeat myself with methods like map recursion, or a conformer for map keys, I would normally extract these into a library and import it.  but, I don't know how I would handle this with juju
<bodie_> I expect importing a personal library would be unkosher
<bodie_> who could tell me where to put such things?  e.g. a method for coercing map[interface{}]interface{} to map[string]interface{}
<bodie_> I'm kinda tempted just to open a PR with a personal import and see if it flies :S
<bodie_> it looks like charm master breaks its own tests
<bodie_> rogpeppe, config_test line 408: YAML error: reflect: reflect.Value.Set using unaddressable value
<bodie_> maybe it's an issue with my deps
<bodie_> doesn't seem to be
<bodie_> https://github.com/juju/charm/pull/80 rogpeppe
<bodie_> one-line fix
<bodie_> not sure if this is how it *should* work, but it patches the breakage
<bodie_> ah
<bodie_> I see
<bodie_> my charm master is out of sync with upstream because my upstream is gopkg.in/juju/charm.v4
<rogpeppe> bodie_: oops. looks like juju-core needs latest version of yaml package
<rogpeppe> bodie_: i think it should anyway - if you could do that, i'd be happy :)
<rogpeppe> bodie_: i'm not here BTW :)
<bodie_> rogpeppe, ack, so tweak the charm or the deps?
<bodie_> er, rogpeppe's IRC away bot
<mgz> heads up for juju-core... talking about server moving to systemd, which means our dynamically upstart jobs will need adapting for vivid
<ericsnow> thumper: ping
<thumper> ericsnow: hey
<ericsnow> thumper: I've addressed just about everything on http://reviews.vapour.ws/r/346/
<thumper> ericsnow: ok, will look again
<ericsnow> thumper: left one open issue
<ericsnow> thumper: thanks
<thumper> ericsnow: was trying to look at the differences, and all I get is empty files and errors: http://reviews.vapour.ws/r/346/diff/16-17/?page=2
<thumper> ericsnow: I'm assuming rb shouldn't do this?
<ericsnow> thumper: it's because the branch depended on another branch
<thumper> ah
<thumper> ericsnow: ship it!
<ericsnow> thumper: try diff'ing between 14 (where you last reviewed) and the latest
<ericsnow> thumper: okay!
<katco> well. i now know that my machine does not like spawning 100,000 instances of this test.
<bodie_> heh
<bodie_> my machine doesn't like running the juju core tests at all :/ I'm still trying to determine why I keep getting a reversed port number in the firewaller test
<katco> i didn't expect it to become completely unresponsive... i thought the kernel scheduler was better than that
<katco> 608s before it started giving me back control lol
<katco> kind of. ugh.
<katco> or gosh... maybe it's the window manager...
<katco> ssh is working fine
<katco> cpu and mem aren't under load...
 * thumper goes to lie down for a bit
<waigani> thumper/menn0: after I take out the machineID and NetworkName from the openPorts doc, what should the localID of the doc look like?
<waigani> right now it is: "m#<machineid>#n#<networkname>
<waigani> if we update the quires to use the fields, should we let the localID just be generated by mongo?
<cmars> bodie_, i've seen that firewaller bug as well, intermittently
<cmars> bodie_, is it fairly repeatable for you?
<cmars> bodie_, what version go compiler are you using
<bodie_> cmars, I wouldn't call it repeatable, but I've seen it I think three times now
<bodie_> cmars, 1.3.3
<cmars> bodie_, i'm using 1.3, and mgz just mentioned this could be a map ordering issue
<waigani> thumper/menn0: just looking at how portsGlobalKey is used ...
<bodie_> cmars, that might make sense.  should be a SameContents, perhaps
<mgz> would explain why bot and others havenb't seen it, small maps are deterministically ordered on 1.2
<mgz> one of you needs to file a bug :P
<cmars> bodie_, firewallerSuite.TestGetMachinePorts ?
<bodie_> cmars, aye
<cmars> bodie_, i'll open it
<bodie_> much appreciated cmars, I'm already way over EOD trying to get something else landed
<ericsnow> thumper: when would be a good time to talk about MESS and backups?
<waigani> thumper/menn0: machineid and networkname need to be in the id for the watcher
<menn0> waigani: sorry, I don't actually know what you're doing
<thumper> waigani: I didn't say to take them out of the id
<thumper> waigani: just make sure they are also available outside the id
<menn0> waigani: why did you want to remove machineID and NetworkName from the openPorts doc?
<waigani> thumper: right
<thumper> like the envuuid
<waigani> menn0: I misunderstood
<menn0> ok
<rogpeppe> bodie_: tweak juju-core deps
<katco> wallyworld: "This webpage has a redirect loop"
<katco> not sure what's going on
<wallyworld> :-(
<wallyworld> i'l try opening hangout again
<katco> wallyworld: i bet this is that stupid cookies issue i was having
<mgz> don't eat the stupid cookies!
<wallyworld> chocolate chip?
<ericsnow> perrito666: FYI, all four of those patches have now landed
<perrito666> ericsnow: niiice, Ill start integration right away
<menn0> thumper: how do you feel about NewEnvironment's signature changing from this:
<menn0> NewEnvironment(env, server names.EnvironTag, owner names.UserTag, name string) (*Environment, error)
<menn0> to this:
<menn0> NewEnvironment(cfg *config.Config, server names.EnvironTag, owner names.UserTag, ownerPassword string) (*Environment, error)
<thumper> so it creates an environment uuid?
<thumper> why have ownerpassword?
<thumper> and why remove the name?
<menn0> the name comes from the config
<menn0> ownerpassword is needed to set up the owner user
<menn0> the uuid also comes from the config
<menn0> thumper: ^
<thumper> the owner must already exist
<menn0> you're right
<menn0> createInitialUserOp should only be done by Initialize and not by NewEnvironment
<menn0> i'll fix that
<thumper> perhaps, remove the server, and just add a comment that the environment will have the same server as the initial environment
<thumper> the server uuid was added to enable us to store records to remote environments
<thumper> which we have no use case for right now
<thumper> maybe soon with cross environment relations
<thumper> which will need other commands anyway
<thumper> so...
<menn0> that makes sense
<thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, error)
<thumper> or
<thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, *State, error)
<menn0> I was wondering about returning the new state
<thumper> so it returns a *State that would operate in that env?
<menn0> but it's easy to get with State.ForEnviron
<thumper> sure
<menn0> and NewEnvironment doesn't need to create it itself
<menn0> so it's probably outside its responsibility to return it
<menn0> thumper: thanks I'll run with this
<thumper> ok
<thumper> cool
<thumper> alexisb: are we meeting today?
<alexisb> yes
<thumper> k, be there in a sec
<wallyworld> thumper: when you finished your meeting, i need to talk about bug 1392745
<mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
<thumper> :-(
<wallyworld> anastasiamac: review done, let me know if you have questions
#juju-dev 2014-11-18
<wallyworld> thumper: can i pick your brain? let me know if you have time for a hangout
<thumper> how about in 15 min?
 * thumper is just eating
<wallyworld> sure
 * wallyworld reboots
<thumper> wallyworld_: https://plus.google.com/hangouts/_/gyff6xf73v7pnxrzkv4lm3t7fqa?hl=en
<LinStatSDR> Party is over ;(
<thumper> do we have a good tool for navigating the history of the git branch?
<thumper> wallyworld_: here is a suspect comment: // Write non-empty contents to the file, otherwise delete it
<thumper> so the question becomes, why is the info value empty
<wallyworld_> thumper: almost finished standup, will look soon
<thumper> hmm... it seems like it should be in the agent config
<wallyworld_> sinzui: you around?
<sinzui> I am
<wallyworld_> sinzui: thumper has questions about bug 1392745
<mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
<wallyworld_> we know 1.19 was broken
<thumper> sinzui: oh hai
<wallyworld_> so comment #1 we can put don to that
<thumper> also...
<thumper> the bug targets 1.22 and 1.21-beta3 but the bug talks about 1.20.11
<sinzui> yep, CI was 1.18 and 1.20
<thumper> sinzui: first question, what is machine 6?
<thumper> sinzui: is it a state server or not?
<thumper> sinzui: are you running in HA or not?
<sinzui> thumper, CI itself... http://juju-ci.vapour.ws:8080
<sinzui> thumper, no HA
<thumper> sinzui: is machine 6 a state server?
<thumper> or is it just a normal machine?
<thumper> how many machines are in the environment?
<thumper> sinzui: can I get access to the state server machine?
<sinzui> thumper, no, not a state-server, that is 0, 6 really is juju-ci's jenkins master.
<sinzui> sure
<thumper> sinzui: isn't there some magic script to import someones launchpad ssh keys to a machine?
<sinzui> thumper, https://drive.google.com/a/canonical.com/?ddrp=1#search/juju-ci3.jenv will show the jenv
<sinzui> thumper, sure I can do that if you just want access to the machine, the staging key in cloud-city also gives you that power
 * sinzui places keys
<thumper> sinzui: I could just use the juju command to add my ssh key
<axw> sinzui: has there been any change to the github-merge-juju job in the last day? it just failed three times in a row with intermittent test errors... at least two mongo related
<sinzui> axw, I don't thinks so. mgz, didn't mention he made changes
<axw> okey dokey
<thumper> wallyworld_: when adding an ssh key, do I specify the path or the actual key?
<thumper> wallyworld_: help isn't clear
<wallyworld_> um
<wallyworld_> let me look to refresh memory
<wallyworld_> the key itself
<wallyworld_> or you can import from lp
<wallyworld_> juju authorised-keys import lp:thumper
<thumper> nm, there already
<thumper> haha
<thumper> ha
<thumper> oops
 * thumper does some digging
<thumper> this could be 'orrible
<sinzui> thumper, I think I put your keys on manually because the above command exited with error 1
<thumper> sinzui: I also put them in through the environment
<thumper> :)
 * thumper facepalms
<thumper> sinzui: well, I can fix the problem but it doesn't make it clear why it happened in the first place...
<thumper> although I do have some ideas
 * thumper continues digging
<thumper> sinzui: do you want me to fix the environment?
<sinzui> thumper, just helping us fix is will let us get on with our lives
<thumper> kk
<thumper> sinzui: my attempted fix didn't work :-(
<sinzui> :(
 * thumper tries something else
<ericsnow> davecheney: thanks for taking a look at http://reviews.vapour.ws/r/485/
<ericsnow> davecheney: if you like I can roll the rest of removing-backups-dependency-in-state into the patch
<thumper> wallyworld__: managed to get into the inside of the mongo database, it says "system-identity" is ""
<wallyworld__> \o/
<wallyworld__> that that explains why the file is being removed
<wallyworld__> but not why system identity in db is ""
<thumper> right
<thumper> wallyworld__: did you want to talk this through?
 * thumper needs a teddybear
<wallyworld__> thumper: i'm just about to get a pie out of the oven, give me 5 mins to eat it
<thumper> kk
<wallyworld__> then i'll spoon you
<jw4> wallyworld__, thumper I'm guessing that means something different in that hemisphere?
 * jw4 is from South Africa though and spooning meant the same there
<thumper> jw4: no... I think he just used the wrong word
 * thumper hopes
<jw4> lol
<wallyworld__> thumper: am in our 1:1 waiting for a cuddle
<thumper> jw4: he meens "huddle"
 * jw4 blushes and tiptoes away
<menn0> LOL
<menn0> i just looked at the channel after having not looked for a while and oh dear...
<jw4> menn0: I feel safer now that theres someone else here
<menn0> :)
<wallyworld__> menn0: well, he is very cuddly, you should try it sometime
<anastasiamac> wallyworld__,thumper: "huddly"?..
<jw4> anastasiamac: :-D
<anastasiamac> jw4: m relieved this channel is PG-rated ;-)
<jw4> anastasiamac: hehe - I'm sure thumper is squirming right now
<thumper> nah
<thumper> calm but annoyed by minions running around the house
<jw4> hehe
<jw4> for some reason my minions have been CRAZY the last few days
<anastasiamac> thumper: u'll need to teach me someday how u manage to "be calm but annoyed" :-)
<thumper> anastasiamac: outer calm
<thumper> inner rage
<thumper> deep breathing
<thumper> wallyworld__: so... about this system identity problem...
<thumper> wallyworld__: are you looking after it?
<wallyworld__> no, i was hoping you would :-)
<wallyworld__> i was delegating :-D
<wallyworld__> as i'm stuck on the other one
<wallyworld__> sharing the love, john and nate's teams have already fixed stuff for beta3
<anastasiamac> thumper: yep, I know the feeling. JUst got off the phone with the school re: discipline ;-(
<thumper> :-(
<anastasiamac> thumper: it's less than 2 weeks left!
<anastasiamac> :-(
<thumper> wallyworld__: ok, I'll take it, and look in the morning
<wallyworld__> \o/ ty
<thumper> wallyworld__: I expect it will be an upgrade step specifically for 1.20.12
<thumper> wallyworld__: and put back in for 1.21 too
<wallyworld__> yeah, cause 1.21 and on run all the other steps
<thumper> also, was only going to put the upgrade step in the 1.20 branch for 1.20.12
<thumper> and in the normal 1.21 steps for the 1.21 branch and trunk
<thumper> wallyworld__: sound reasonable?
<wallyworld__> yep, do it as a 120 step, right
<thumper> um... no
<thumper> well
<wallyworld__> if done as a 120 step, 1.21 and later will run it
<thumper> no it won't
<thumper> not if on 1.20 already
<thumper> you may have upgraded, and just be broken
<wallyworld__> so to unbreak, the step needs to reinsert the file into the db
<wallyworld__> shit, i guess it becomes an agent startup step
<wallyworld__> like ensureMong()
<thumper> it needs to create a new system identity file and put it in the authorized keys and update the db
<thumper> wallyworld__: no, just an upgrade step
<wallyworld__> maybe i'm missing something - if the install is 1.20.11 and broken, having new 1.20.12 won't rerun the 1.20 upgrade stes wil it?
<thumper> no, but I can make an upgrade step for 1.20.12
<wallyworld__> oh, i thought we only did 1.20
<wallyworld__> not 1.20.x
<thumper> so far we haveâ¦
<wallyworld__> cool
<thumper> but that doesn't mean we are limited to it
<wallyworld__> rightio
<menn0> waigani: here's the NewEnvironment change
<menn0> http://reviews.vapour.ws/r/489/diff/
<menn0> waigani: this is what's required to easily allow multiple test environments to be set up
<dimitern> morning all
<jw4> morning dimitern :)
<dimitern> hey jw4 :)
<TheMue> morning
<TheMue> jw4: still awake?
<dimitern> morning TheMue
<jw4> Yeah, but off to bed in minutes
<jw4> TheMue: :)
<TheMue> jw4: good, already wondered
<TheMue> dimitern: o/
<mattyw> morning all
<jam> wallyworld__: any more bugs to tackle today ?
<wallyworld__> jam: just eating, be with you soon
<jam> wallyworld__: np, I looked at the milestones and everything at least looks assigned
<wallyworld__> jam: so bug 1392745, the system identity was moved into the state database from the file system, presumably for HA, but there was no upgrade step written. tim is onto that one.
<mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged by thumper> <juju-core 1.21:Triaged by thumper> <https://launchpad.net/bugs/1392745>
<wallyworld__> and then there's bug 1392602
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<wallyworld__> i can't see what the root cause is
<wallyworld__> i can reproduce it, but not find the cause to fix it
<wallyworld__> i have manually stopped the juju agents, and rsyslog, removed the update conf files, everything is good
<wallyworld__> ie the log dir is still there
<wallyworld__> then a reboot results in the whole log dir being deleted
<wallyworld__> with juju seemingly not involved because it had been stopped and the conf files moved away to avoid upstart stating the agents
<wallyworld__> a manual stop and start of the agents (but no reboot) does not reproduce the issue
<wallyworld__> it's only a reboot
<wallyworld__> i have nfi right now
<wallyworld__> is there some diagnostic process that can be run to see what process is removing adir?
<davecheney> wallyworld: fuser
<wallyworld> i'm trying auditd but can't get the rules to stic
<wallyworld> k
<wallyworld> fuser shows nothing is referencing the file after bootstrap
<voidspace> dimitern: should ReleaseIPAddress take instance id and net id - or just net id (plus address of course)?
<voidspace> dimitern: I think only net id is sufficient
<dimitern> voidspace, you mean Environ.ReleaseAddress?
<dimitern> voidspace, I think, for consistency, it can take the same args as AllocateAddress (in maas we won't use instId and netId, but for ec2 we will right?)
<voidspace> dimitern: for maas we'll use netid I think
<voidspace> dimitern: for ec2 we might *need* instance id
<voidspace> dimitern: so yeah, probably taking the same is best
<voidspace> dimitern: ah no, for maas we just need ip address
<dimitern> voidspace, +1
<voidspace> cool
<bodie_> morning folks :)
<perrito666> hey, anyone knows what the Total attribute of utils.AttemptStrategy is for?
<bodie_> Total Warfare
<bodie_> sorry....  hehe
<perrito666> oh I get how it works.. mm
<rogpeppe> perrito666: it bounds the total length of time of all attempts
<rogpeppe> anyone know how local charm revisions are meant to work?
<rogpeppe> dimitern: ^
<perrito666> rogpeppe: yes, I read the code because it was not all that clear, It is odd that there is no clear way to ask for a given number of attempts instead, the only way seems to be to set any short time and min retries
<rogpeppe> perrito666: just specify min retries, but don't specify Total
<dimitern> rogpeppe, yes, so the revision in the revision file is respected only if there's no duplicate charm with the same revision in state (it's bumped then until unique)
<bodie_> am I the only one getting breakage on master again?
<bodie_> I rolled back to go1.2.2 thinking it would make things work better, cleaned my $GOPATH/pkg, ran godeps, and now everything is broken. lol
<bodie_> throw in a few go get -u -v ./... for good measure
<bodie_> ... with godeps at the end, of course
<rogpeppe> dimitern: so if there's a local charm with no revision file and there's an existing charm in the environment, but no existing charm with revision 0, what should happen?
<rogpeppe> bodie_: what breakage are you seeing?
<rogpeppe> dimitern: i'm seeing what i think is broken behaviour, but perhaps it's deliberate
<bodie_> rogpeppe, looks like the same newline breakage we were getting last night when we updated the yaml.v1 version
<dimitern> rogpeppe, if there's no rev file and no local charm with the same url, revision is set to 1
<bodie_> jw4 and I went over that, but it looks like the update changed some of the behaviors expected by many tests in master
<bodie_> rogpeppe, so, I wasn't able to get the new dep in, perhaps somebody poked it into the deps without checking the tests, or possibly I'm just doing something silly :P
<rogpeppe> dimitern: ok, so that will upload to revision 1 in the environment? so won't actually upgrade the charm?
<rogpeppe> bodie_: remind me what the issue was again?
<dimitern> rogpeppe, hmm.. wait a sec - how can you upgrade a charm not yet deployed (i.e. missing from the env and state)?
<bodie_> rogpeppe, we needed to update yaml.v1 version in order for the new charm content to pass tests
<rogpeppe> dimitern: it's already deployed
<bodie_> rogpeppe, but when updating yaml.v1, many tests in master broke with slight changes to newline behavior
<rogpeppe> dimitern: but the local charm doesn't have a revision file
<bodie_> rogpeppe, so we didn't push the change since it was already past EOD for us
<rogpeppe> bodie_: example test output?
<dimitern> rogpeppe, iirc, the revision file is only used if present, and only if the revision is unique in state; if it's missing it's assumed rev 1 (and if rev 1 exists, rev 2 and so on)
<bodie_> rogpeppe, can't promise that's what I'm seeing right now, jw4 was the one who was seeing the test breakage, as I wasn't able to roll back to 1.2.2 due to some network issues and was seeing different breakage
<bodie_> but, it looks like this, as far as I can tell --
<rogpeppe> dimitern: the behaviour i'm seeing is that i run "juju upgrade-charm myservice" and it says "Added charm "local:trusty/myservice-41" to the environment." (that's later than any other revision) but the service isn't actually seeing an upgrade
<bodie_> rogpeppe, http://paste.ubuntu.com/9072227/
<rogpeppe> bodie_: ok. so those are actually broken tests, i'd say
<dimitern> rogpeppe, you mean looking at the uniter logs you don't see the upgrade happening?
<rogpeppe> dimitern: yup, and the charm source didn't change
<rogpeppe> dimitern: (when i looked in /var/lib/juju/agents/unit-myservice-0/charm)
<dimitern> rogpeppe, weird
<bodie_> rogpeppe, this is my master with latest godeps, so I'm hoping it's an issue with my rolling back to 1.2.2, but yes
<dimitern> rogpeppe, sounds like a bug to me
<rogpeppe> bodie_: so if we don't change those tests, we won't be able to use the latest version of goyaml
<rogpeppe> dimitern: me too :)
<rogpeppe> bodie_: but the plus side is that it should be relatively easy to fix them
<bodie_> yes, rogpeppe, this is on my master with current godeps, however
<bodie_> unless we ugpraded the yaml version in master already
<rogpeppe> bodie_: i'll see if i can replicate
<bodie_> hoping it's just a failure with my packages
<rogpeppe> bodie_: this is such awesome test output http://paste.ubuntu.com/9072392/
<rogpeppe> bodie_: now where's the difference again? :)
<bodie_> rogpeppe: what, isn't it obvious to you?
<bodie_> hmmm...
<rogpeppe> bodie_: if i update yaml deps to current juju-core version, all tests in that package pass for me
<bodie_> hmm... okay, good to know
<rogpeppe> bodie_: ok, here's the diff: http://paste.ubuntu.com/9072508/
<bodie_> rogpeppe, for?  deps.tsv?
<bodie_> I don't know if I'm supposed to know what I'm looking at here, heh
<rogpeppe> bodie_: the odd thing is why the obtained value doesn't seem to be formatted with the same goyaml
<rogpeppe> bodie_: that's the diff between expected and obtained output from that test output i pasted above
<rogpeppe> bodie_: ah! i have a suspicion
<rogpeppe> bodie_: hmm, unfounded
<rogpeppe> bodie_: ah, i've found the problem, and i'm not sure of the best way of fixing it
<rogpeppe> bodie_: in windows_userdata_test.go, it has an expected literal agent configuration
<rogpeppe> bodie_: that seems bogus to me
<rogpeppe> bodie_: i think that test should be using assertScriptMatch
<rogpeppe> bodie_: then it could just leave out the problematic places, i think
<bodie_> rogpeppe, I apologize, family woke
<rogpeppe> bodie_: np
<rogpeppe> bodie_: ok, i've got that package passing its tests
<bodie_> rogpeppe, excellent
<rogpeppe> bodie_: i've pushed the branch to github.com/rogpeppe/juju under the 019-fix-environs-cloudinit-for-new-yaml  branch
<rogpeppe> bodie_: if you could move forward with that, that would be great, as i've already spent too much time on it
<rogpeppe> bodie_: ideally that enormous string in windows_userdata_test.go would be honed down to stuff we actually care about.
<bodie_> rogpeppe, sure thing.  I need the charm working to push forward on my work anyway, so this will have to come first either way :)
<bodie_> but, we are pretty slammed with trying to push actions forward
<bodie_> I don't imagine this will be a big timesink though
<perrito666> natefinch: wwitzel3 ericsnow brt, restarting a few things to see if hangouts works better
<rogpeppe> bodie_: sorry about that. it is paying off tech debt, at least, though
<perrito666> natefinch: ericsnow wwitzel3 could you hear any of that?
<natefinch> perrito666: when are you going to upgrade to that 5800 baud modem? :)
<natefinch> perrito666: nope
<perrito666> natefinch: I am saving to buy the serial cable
<natefinch> lol
<perrito666> well, apparently chrome decided to take my 4 cores
<perrito666> in the good side, almost no ram
<perrito666> except for the 84G virt memory
<perrito666> that is
<perrito666> I have no clue what is going on there but I fear I will have to switch to firefox if this keeps going on
<perrito666> natefinch: btw, I did not see your rant
<natefinch> perrito666: I'm still writing it.  Almost done.
<perrito666> natefinch: rant early, rant often
<perrito666> well that explains it... its is a freaking virtual machine https://en.wikipedia.org/wiki/Google_Native_Client
<voidspace> dimitern: ping
<voidspace> dimitern: why do some providers use errors.NotSupportedf for not implemented methods
<voidspace> dimitern: whereas others use NotImplementedf
<dimitern> voidspace, well supposedly because some *can* support something (once implemented) while others don't even support that feature
<voidspace> dimitern: ok
<voidspace> dimitern: makes sense
<voidspace> if true in actual usage patterns...
<dimitern> voidspace, it's not a strictly followed policy :)
<natefinch> perrito666: rant sent
<voidspace> dimitern: looks like they're used in local and manual
<mgz> anyone remember how I turn off the 10m timelimit for tests?
<voidspace> dimitern: is it true that local and manual will not support AllocateAddress and ReleaseAddress?
<natefinch> mgz: -timeout
<natefinch> mgz: also go help testflag
<dimitern> voidspace, possibly not, at least not in the near future I think
<mgz> natefinch: ta
<voidspace> dimitern: cool
<voidspace> dimitern: for the dummy environ, do I just write an "OpReleaseAddress" to the estate.ops ?
<voidspace> dimitern: or do we need to mimic the behaviour of the real release and undo the previous allocate?
<voidspace> natefinch: I had to do that very thing (report a bug) and had exactly the same problem as you...
<voidspace> natefinch: I just picked "unity" as the package name in the end
<dimitern> voidspace, let's have a OpReleaseAddress - that way we can test it gets called
<natefinch> voidspace: heh... on my second try, I picked "X.org", just because it was a UI related thing, but then it went to a screen asking what particular thing crashed or whatever, and none of that was right either, so I finally said screw it and wrote that rant instead.
<voidspace> dimitern: sure
<voidspace> natefinch: hah
<dimitern> voidspace, and the implementation should allow us to test it, without expecting too smart behavior of the dummy provider :)
<perrito666> natefinch: I think its lightdm
<perrito666> although I have no clue what the package for it its called
<voidspace> natefinch: mine was a bluetooth/touchpad/multi-touch gesture issue
<voidspace> fuck-knows where the actual bug is with that
<natefinch> <shouting>I shouldn't need to know what the f'ing package name is to report a bug!!</shouting>
<voidspace> a three-fingered (or four fingered) gesture causes an event storm and the magic trackpad stops responding
<perrito666> natefinch: really all it took is a few years of fighting with dms and dpkg -l | grep -i light
<perrito666> :p
<cmars> hi natefinch, could I trouble you to look at a small PR I've got, http://reviews.vapour.ws/r/488/. fixes a go 1.3 map ordering issue bodie_ and I ran into yesterday
<mgz> cmars: interestingly, I couldn't make it fail of gccgo
<cmars> mgz, that is interesting... does gccgo implement the same nondeterministic map ordering?
<mgz> it's different non-determinism
<natefinch> cmars: why do we care what order the port ranges are returned in?
<bodie_> "non-deterministic"
<cmars> natefinch, so that we can more easily test them
<bodie_> natefinch, go 1.3 breaks map ordering on purpose I think, so that people won't rely on map ordering in tests for example (like us)
<bodie_> there is no doubt also another good reason
<mgz> natefinch: in my opinion, api returns should be deterministic
<sinzui> natefinch, I would like your thoughts on this bug. I hope to defer it to another milestone or show that is it a local setup issue. https://bugs.launchpad.net/juju-core/+bug/1392602
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<mgz> if we're providing a public method to retrieve some stuff, it's better if you get the same stuff back when nothing has changed, rather than a random shuffle
<bodie_> rogpeppe, I love your branch naming! lol
<cmars> natefinch, that apiserver/firewaller test fails intermittently on go 1.3. easy to reproduce if you repeat it in a loop. the test deep-equals a slice, whose order was coming from map iteration.
<bodie_> rogpeppe, I am constantly trying to convince people to use expressive branch names :/
<rogpeppe> bodie_: :)
<rogpeppe> bodie_: in the old juju-core, my branch numbers had reached 562
<hallyn> anyone have time for a go question?
<hallyn> (^ wording Kapil suggested :)
<bodie_> ask away, #go-nuts is also a great place if people are too busy here :)
<hallyn> I've got a https client in go, talking to an https server in go.  On first connect, I'd like the client to grab the server's certificate from the connectio nand present the fingerprint to the user for verification.  In the server code I can grab the certificate from the http.Request.TLS.  but that .TLS doesn't exist on the client end.
<hallyn> I guess I should probably join there
<hallyn> But so I'm wondering how I can grab the cert.  I.e maybe override the Dial command to intercept it, but I still don't have access to my own structs then to store the result
<hallyn> ooh, can i get it fro mtr.clientsessionstate?
<hallyn> from config.ClientSessionCache that is
<natefinch> mgz, cmars: I guess it makes sense to return the same data each time, but I kinda hate guaranteeing an order, because then people will depend on it, and if we change the sorting mechanism, it'll break people.
<mgz> natefinch: I think when we're returning a slice of stuff, having it in a random platform/compiler dependent order is perverse
<voidspace> dimitern: ping
<voidspace> dimitern: http://reviews.vapour.ws/r/491/
<voidspace> dimitern: I'm pinging you specifically because I'm not happy that the test for the dummy provider implementation of ReleaseAddress is basically a duplicate of the one for AllocateAddress
<voidspace> dimitern: all that changes is the op type, and in the absence of generics (or reusing the OpAllocateAddress which would be bad) I can't see an obvious way round it
<voidspace> dimitern: suggestions welcomed!
<natefinch> mgz: I don't ever assume lists are sorted unless it is very specifically called out as such.  That being said, if we decide we want this to be a sorted list, that's fine.... but we need tests around it so we don't break it later.
<mgz> xwwt: https://launchpad.net/juju-core/+milestone/1.21-beta3
<sinzui> natefinch, I really do need an opinion on bug https://bugs.launchpad.net/juju-core/+bug/1392602 it block the release
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<natefinch> mgz, cmars:  I'd like to bring this up on the mailing list, because we should probably be consistent with any API that returns a list of things - either explicitly sorted or not-sorted.,
<voidspace> natefinch: if you fancy a review
<voidspace> natefinch: http://reviews.vapour.ws/r/491/
<voidspace> natefinch: note what I said to dimitern above
<voidspace> natefinch:  I'm not happy that the test for the dummy provider implementation of ReleaseAddress is basically a duplicate of the one for AllocateAddress
<voidspace> natefinch:  all that changes is the op type, and in the absence of generics (or reusing the OpAllocateAddress which would be bad) I can't see an obvious way round it
<voidspace> natefinch: so suggestions welcomed...
<voidspace> In other news, it seems Nokia is still a thing...
<dimitern> voidspace, sorry, was afk for a while, will have a look now
<voidspace> dimitern: np, thanks
<natefinch> voidspace: nearly duplicate tests do not bother me
<voidspace> natefinch: heh, fair enough
<natefinch> voidspace: merging two tests that just happen to be very similar *does* bother me
<voidspace> natefinch: it just seems like there ought to be an elegant solution
<voidspace> natefinch: they're *identical* other than type
<natefinch> voidspace: it's really just a coincidence.  There's nothing inherently "the same" about allocation or deallocation.  They happen to be the same here, but that's not a contractual thing we want to ensure.
<voidspace> natefinch: in terms of implementation in the dummy provider it's more than coincidence
<voidspace> natefinch: for both of them it's "write a typed op into the log"
<voidspace> natefinch: it's not even a coincidence that they have exactly the same parameters...
<voidspace> natefinch: it's very deliberate
<voidspace> natefinch: I'm not fighting you on saying it's alright for the tests to be duplicates though
<voidspace> natefinch: and agreed we may not want to bake in the fact that the parameters are the same
<voidspace> natefinch: although that would be trivially easy to change of course
<natefinch> the fact that we have to test the dummy provider at all is appalling to me.
<natefinch> we're testing our mock... awesome
<voidspace> natefinch: there's code there
<voidspace> it needs to be tested
<natefinch> that's the problem
<voidspace> you should certainly test your test infrastructure
<natefinch> anyway
<voidspace> not your tests themselves of course
<voidspace> natefinch: I would hope the mock servers in gomaasapi and goamz are tested
<voidspace> natefinch: but they're "merely mocks"...
<natefinch> I would hope you could test the code without a mock server :)
<natefinch> but, yes, for exporting a mock server for others to test again, that's valid, I suppose
<voidspace> and dummy provider is essentially that, no?
<natefinch> I wouldn't wish testing against the dummy provider on my worst enemy, however
<voidspace> although "others" is us...
<voidspace> hah
<voidspace> ok
<natefinch> sinzui: thanks for pinging me, I'll get someone on it
<dimitern> voidspace, LGTM
<voidspace> dimitern: cool, thanks
<voidspace> dimitern: maas implementation done - just testing it
<voidspace> not really an achievement - it's about ten lines of code or so...
<dimitern> voidspace, sweet! :)
<mgz> can someone on utopic either confirm bug 1392602 exists or doesn't?
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<mgz> we need that to see if we have to block beta3 on it
<mgz> dimitern: what version of ubuntu are you on atm?
<dimitern> mgz, trusty
<dimitern> 14.04.1
<voidspace> mgz: I thought wallyworld_ confirmed that this morning
<voidspace> mgz: he said he could reproduce and was working on it IIRC
<voidspace> mgz: he just had no idea why the log dir would disappear last I heard
<voidspace> mgz: it happened even with jujud stopped and the upstart config blown away to prevent it restarting
<voidspace> mgz: so it didn't look like it was *juju* that was deleting the log dir...
<dimitern> cmars, anastasiamac, hey, thanks for taking care of that port ranges bug with http://reviews.vapour.ws/r/488/ - sorting LGTM
<voidspace> mgz: ah, you're asking about utopic specifically
<voidspace> mgz: I missed that, sorry :-)
<mgz> voidspace: he can, but sinzui cannot - we want a third opinion :)
<voidspace> mgz: hah :-)
<mgz> basically, to see if the bug should be bumped or not
<voidspace> is gc.ErrorMatches *really* a regex match?
<voidspace> hmmm... it really is
<natefinch> voidspace: yes....
<voidspace> but .* doesn't seem to be doing its job
<dimitern> voidspace, but with some added nastiness
<voidspace> http://pastebin.ubuntu.com/9074743/
<natefinch> it's a substring match
<voidspace> is it
<natefinch> yep, you can just do "failed to release ip address 192.168.2.1"
<voidspace> it puts ^ and $ around the regext
<voidspace> natefinch: nope, that failed
<voidspace> which is why I added .*
<natefinch> really? dang, sorry, I think it did
<dimitern> voidspace, if it's a multiline string you're trying to match, add (.|\n)* at the beginning and at the end of the regexp
<voidspace> dimitern: yuck
<voidspace> dimitern: probably - it's an annotated error I'm trying to check
<dimitern> voidspace, yeah, that's one of the ways to get around the auto-appending/prepending of ^ and $
<voidspace> dimitern: that worked...
<voidspace> dimitern: thanks
<voidspace> dimitern: see what you think of the test here
<voidspace> http://reviews.vapour.ws/r/492/
<voidspace> dimitern: hmm... I could get rid of the mocking indirection, as the test server is sufficient for testing this
<dimitern> voidspace, there are a few places in the codebase this is used
<dimitern> voidspace, ok, looking
<dimitern> voidspace, reviewed
<voidspace> dimitern: thanks
<dimitern> voidspace, np
 * dimitern needs to stop now 
<voidspace> dimitern: see you tomorrow
<ericsnow> natefinch: would you mind taking a look at http://reviews.vapour.ws/r/484
<ericsnow> natefinch: it should be a quick review
<natefinch> ericsnow: done
<ericsnow> natefinch: thanks
<ericsnow> fwereade: does it make sense to worry about bulk calls for the backups API?
<natefinch> wwitzel3: did you look at this bug at all?  Can't remember if you were looking at it or not: https://bugs.launchpad.net/juju-core/+bug/1392602
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<fwereade> ericsnow, I would say that in general yes it does, I can absolutely see myself wanting to create backups of all my envs in one shot
<ericsnow> fwereade: ah, got it
<sinzui> natefinch, wwitzel3 voidspace : I really want to know if this issue affects utopic users. I don't see this affecting trusty users and I don't think this is a juju-core bug https://bugs.launchpad.net/juju-core/+bug/1392602
<mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
<sinzui> natefinch, wwitzel3 voidspace : If we can prove the bug is not in juju-core, I want to release beta3 today
<voidspace> I don't have utopic I'm afraid
<voidspace> :-(
<natefinch> gah, guess I can upgrade
<natefinch> 8////
<voidspace> g'night all
<voidspace> natefinch: good luck!
<natefinch> thanks
<ericsnow> natefinch: when you have a minute, could you take a look at http://reviews.vapour.ws/r/493/?
<ericsnow> natefinch: effectively I take state/backups.go and move it to state/backups/storage.go (plus deal with various consequences)
<natefinch> ericsnow: sorry, gotta try to work on the release blocker...
<natefinch> ericsnow: unless you want to upgrade to utopic while I look at your review... ;)
<ericsnow> natefinch: no worries
<sinzui> natefinch, I am not asking anyone to update to utopic. I don't want to ruin someone's desktop. I am hoping someone on the engineering team is on utopic
<natefinch> sinzui: too late, I've pulled the trigger...
<sinzui> natefinch, ouch
<natefinch> if I don't come back, tell my family I love them
<sinzui> natefinch, I am staying on trusty since it is where juju really needs to run
<ericsnow> perrito666: sorry, I'm going to call it a day
<perrito666> ericsnow: no worries
<perrito666> are you ok?
<ericsnow> perrito666: I've got a sudden head cold that's kicking my but
<perrito666> well go rest then
<natefinch>   
<perrito666> natefinch: wise words
<natefinch> well, couple notifications about chrome crash-
<natefinch> sorry 1 year old on my la
<natefinch> lap
<natefinch> anyway, ubuntu thinks chrome crashed a couple times, but my browser windows look ok
<natefinch> otherwise, no problems so far in the first 2 minutes
<natefinch> 5
<perrito666> natefinch: same happens to me
<perrito666> I would guess auxiliary chrome apps
<perrito666> if you ps you will find chrome runs a load of processes
<natefinch> 3andthis i why I like having an off switch on my keyboard
<perrito666> one of them a virtual machine
<natefinch> yeah
<perrito666> I had to go to firefox even tough I dont like it at all
<perrito666> I feel kind of dirty runing xul apps
<natefinch> reminds me of this: https://www.youtube.com/watch?v=lg7MAacSPNM&t=15
<perrito666> lool
<perrito666> havent seen that one in a while
<natefinch> me either
<perrito666> (a while <1 year)
<natefinch> gah, dependencies.tsv is wrong on the 1.21 branch
<mgz> where's our logging bot gone for this channel?
<natefinch> actually, wait, now
<natefinch> no
<perrito666> mgz: dunno, where is chanserv?
<mgz> nvm, maybe it is here after all...
<natefinch> sinzui: couldn't repro that bug on my machine using 1.21 on utopic
<sinzui> natefinch, thank you very much. I am going to defer that bug and release beta3
<thumper> morning
<rick_h_> party thumper
<thumper> sinzui: hey, looked more into the juju-run issue yesterday
<thumper> sinzui: we *think* we know what the problem is
<thumper> sinzui: but not a quick fix, needs a patch, backport and new version
<thumper> hi rick_h_
<sinzui> thumper, thank you! I removed the bug from the beta3 milestone since we are certain the regression is older
<thumper> sinzui: yeah, I think it came about from 1.18 -> 1.20 upgrade
<thumper> I'll write an update in the bug and I agreed with wallyworld_ to take it
 * thumper checks sprint agenda for more surprise hangouts
<rick_h_> thumper: but why ruin the surprise?
<thumper> rick_h_: I was trying to rest lying in bed when the hangout request came through from mramm2
<thumper> rick_h_: when I answered and heard sabdfl in the background, I was like "oh bugger, better get up"
<rick_h_> thumper: yea, I got home from bringing the boy home from school and saw an email "we're in this hangout"
<rick_h_> "hmm, wonder what hangout that is...click link...guess I'll see if anyone's still there. Oh crap, that's the boss in front of a whiteboard!"
<thumper> heh... yeah
<sinzui> natefinch, mgz, do you have a minute to review https://github.com/juju/juju/pull/1183
<mgz> on it
<katco> fwereade: are you around by any chance?
<katco> wallyworld_: what about you?
<menn0> thumper: when you're free can you have a look at http://reviews.vapour.ws/r/489/ pls?
<thumper> sure
<waigani> menn0: I'm looking now too
<menn0> waigani: thanks. that'll make 4 reviewers :)
<waigani> menn0: so this is moving business logic out of initialize into NewEnvironment and then calling NewEnvironment from Initialize
<menn0> waigani: that was the original plan but it didn't quite work out that way.
<menn0> waigani: Initialize and NewEnvironment do share the code to create and initialize an environment though
<waigani> so you've got envSetupOps now
<waigani> menn0: ^ why couldn't that go in NewEnvironment ?
<wallyworld_> katco: hiya
<menn0> because Initialize needs to take those ops and add more
<katco> wallyworld_: did you see my pms?
<menn0> they should happen in one trxn
<menn0> txn
<menn0> waigani: ^
<menn0> waigani: when the state server env is created, the initial user needs to be created and various docs about the state servers need to be created
<menn0> waigani: these ops aren't required when setting up further envs
<waigani> right
<mgz> can I bother someone about an lxc container start issue/local provider file storage? see bug 1393932
<mup> Bug #1393932: 'container failed to start' with local provider <juju-core:New> <https://launchpad.net/bugs/1393932>
<natefinch> anyone know why I might have to source my .profile every time I start a terminal to get my prompt stuff set up?
<perrito666> natefinch: you broke your conf most likely :p
<natefinch> can't tell you how much I hate the linux profile configuration stuff
<wallyworld_> mgz: it could be that an old container template is being used as tools are no longer in provider storage and the template has the bind mount entry for that still
<wallyworld_> i'd delete the lxc template container
<mgz> wallyworld_: as in, the template in /var/lib/juju/containers ? we tried deleting the contents of that dir
<mgz> or should we try wiping anything else?
<wallyworld_> mgz: no, /var/lib/lx c/juju-trusty-template or something like that
<mgz> is this something we expect to break for users who do an apt-get upgrade and get a new version of juju?
<wallyworld_> it could do
<mgz> yeay.
<wallyworld_> this is the problem of template containers being stale
<wallyworld_> we should do something about this issue though
<mgz> we were talking yesterday about whether a big-bang client upgrade from 1.18 to 1.21 would work the other day, if we want to sru back a modern juju
<wallyworld_> if i'm correct, if there's containers already running, that will work, but if you destroy env and recreate, it will break
<wallyworld_> but
<wallyworld_> it needs more investigation
<wallyworld_> what i say above is an educated guess about the root cause
<waigani> ericsnow: http://reviews.vapour.ws/r/493/diff/ "There was an error displaying this diff"
<jw4> is there a consensus on leaving liberal loggo Debugf statements in the code?
<wallyworld_> sinzui: not sure what you want to do with bug 1393932 - a lxc template created in 1.20 has invalid config when using 1.21
<mup> Bug #1393932: 'container failed to start' with local provider <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1393932>
<natefinch> jw4: if you're going to be really liberal, trace is better.... debug still gets turns on with --debug, but if you want super verbose, one can manually turn on trace
<jw4> natefinch: yeah; I went back and converted my most chatty ones to Tracef
<jw4> natefinch: thanks
<sinzui> wallyworld_, I have seen that report
<wallyworld_> sinzui: i just sorta confirmed the root cause
<sinzui> wallyworld_, beta3 is in the cpcs and will be on streams.canonical.com in 30 minutes.
<wallyworld_> there's a now obsolete bind mount entry in the template config
<wallyworld_> deleting the template container fixes
<wallyworld_> cause juju will recrete it
<wallyworld_> maybe that's a workaround we add to the release notes
<wallyworld_> maybe juju should put a version in the template config file
<wallyworld_> and if a newer juju is incompatible, advise the user to delete the template
<wallyworld_> or something
<sinzui> wallyworld_, to rephrase users should lxc- destroy their juju-*-lxc-templates after upgrading?
<mgz> a comment in release notes sounds good to me
<sinzui> wallyworld_, is this just local, or are lxc containers on other substrates affected?
<wallyworld_> sinzui: that's a big hammer approach, but yeah. the image tarball will be cached still in /var/cache/lxc so it's not too bad
<wallyworld_> just local i think
<sinzui> wallyworld_, I disagree. the templates are stale within days of creating them. I purge /var/cache/lxc and juju templates when I start each development effort to be sure my charms run with new images
<sinzui> wallyworld_, weekly purges with apt update and upgrade off are fastest
<wallyworld_> fair enough
<sinzui> wallyworld_, we already have a section about new local defaults in the 1.20.0 release notes. I will update it with some advice about best practice.
<sinzui> wallyworld_, so you you like to declare that bug as documentation, not a defect?
<wallyworld_> sinzui: it's only in 1.21 that this particular issue occurs
<sinzui> wallyworld_, I might release 1.21.0 on Friday :)
<wallyworld_> it's because we no longer use provider storage for tools
<wallyworld_> sinzui: i personally am +1 with doco, bu that's IMHO
<sinzui> wallyworld_, could you review https://github.com/juju/juju/pull/1183
<wallyworld_> there's an argument we could add an upgrade step
<wallyworld_> done
<wallyworld_> i hope we can release on friday too
<sinzui> wallyworld_, since the 1.21.x user is not getting upgrades, the template needs to be recreated regularly, or we explain how to upgrade a template.
<sinzui> wallyworld_, deletion is fastest.
<sinzui> wallyworld_, in fact, my own preference for an upgrade step is to remove stale templates
<wallyworld_> how do we define stale?
<thumper> menn0: I think I see a problem with the new env branch
<thumper> menn0: plz don't land it yet
<thumper> menn0: just about to talk to fwereade
<thumper> menn0: I'll chat with you after
<menn0> thumper: no problems. i wasn't going to land it without you having a look.
<sinzui> wallyworld_, the packages are more than a fortnight stale update settings set 2 weeks as the longest interval.
<thumper> menn0: ah...no actually, I think it may be ok, still reading...
<sinzui> wallyworld_, sorry, that makes no sense
<menn0> thumper: ok good :)
<sinzui> wallyworld_, We have dealt with ppc64el bugs caused by users who went out of their way to disable updates. juju requires current images, and now that updates and upgrades are off by default for local-provider, users need to learn to manage their images
<wallyworld_> sinzui: updates should no longer be off by default
<wallyworld_> only upgrades
<sinzui> wallyworld_, maybe you want to review and revise https://docs.google.com/a/canonical.com/document/d/1SDhb5UKpsPL4jwnOhgHMJyNZb0Vj01LHY0mDgWMNU1w/edit
<sinzui> the docs based on previous release notes says they are off by default
<wallyworld_> sinzui: they were off by default at one point, but kapil asked for that be be changed so updates were on, i'll check the state of it  all
<wallyworld_> sinzui: i also have a plan brewing to hopefully better manage the template staleness issue moving forward
<mgz> those notes are 16 pages...
<sinzui> wallyworld_, a cunning plan?
<wallyworld_> sinzui: yes, my lord
<sinzui> mgz, the release was due 7 weeks ago...
<sinzui> features kept landing
<wallyworld_> sinzui: is is as cunning as a fox what used to be Professor of Cunning at Oxford University but has moved on and is now working for the U.N. at the High Commission of International Cunning Planning
<sinzui> :))
<sinzui> wallyworld_, I am sure your plan cannot possibly fail.
<wallyworld_> sinzui: of course not, it is so cunning
<menn0> thumper: re your comment about using StateServerEnvironment intead of StateServerInfo
<menn0> thumper: I originally did it that way, but all I wanted was the UUID
<menn0> thumper: so using StateServerInfo seemed like a more direct way to get it
<menn0> thumper: StateServerEnvironment does a bunch of things I don't need at that point
<menn0> thumper: what do you think? I don't mind changing it if you think it's better.
<wallyworld_> sinzui: it involves a combination of changing the current EnsureCloneTemplate() method, storing lxc images in state blobstore, and redirecting lxc to download images via state server so we get to determine if we should continue to use a cached image or reach out and download a new one
<wallyworld_> so we continue to cache for performance, bt can make a decision to update images when needed
<sinzui> wallyworld_, my that is cunning
<wallyworld_> i hope it works, it should do
<wallyworld_> i have a prototype
<wallyworld_> where the redirection happens, but minus logic to look at staleness
<thumper> menn0: I thought about that, and I think that it just makes it a little more easy to understand
<thumper> menn0: comments could also help
<thumper> menn0: alternatively make a function that returns just that
<thumper> and use the new function
<menn0> thumper: ok... i'll make this clearer one way or another
<davecheney> menn0: if you can kill stateserverinfo, that would be great
<menn0> davecheney: i'm not going to kill it in this PR, but I will probably avoid adding another use of it
<thumper> menn0: can we have a chat about upgrade order
<menn0> thumper: sure
<thumper> menn0: just jump in the standup hangout
<thumper> sinzui: are we merging the 1.21 branch into master periodically?
<thumper> sinzui: and also want to confirm that we aren't merging the 1.20 branch into anything any more
<thumper> this fix is horrible
<thumper> but I know what to do now
<mgz> thumper: not as a matter of course, we've been backporting changes from 1.22 to 1.21
<mgz> we're not upmerging 1.20
<thumper> mgz: ok, I gan go with the back port option
<thumper> will land on trunk first, them push into 1.21
<mgz> I have proposed <https://github.com/juju/juju/pull/1184> for an edge case failure, it's possible a reviewboard thing will show up for it
<sinzui> thumper, I don't think we are. jam has done it on occasion.
<sinzui> thumper, I am sure we are not merging 1.20 branch into master. we are hoping to never commit to it again
<thumper> sinzui: to fix juju-run we'll need 1.20.12
<sinzui> thumper, really? we cannot count on everyone to upgrade to the latest. in each minor. If 1.21.1 gets the fix, can't I upgrade my 1.20.11 to 1.21.1?
<sinzui> thumper, many envs went from 1.18.1 to 1.20.5
<thumper> sinzui: ok, what I mean is that if we want the 1.20 release to have a fixed juju-run, we'll need 1.20.12
<thumper> sinzui: if we are fine with it just being fixed in 1.21, then that makes my job easier
<thumper> sinzui: AFAICT, juju-run was broken for everyone with the 1.20 branch
<thumper> sinzui: for everyone that upgraded to it
<thumper> rather than bootstrapped it
<sinzui> thumper, okay, yes, I agree. juju-ci will support 1.20.x for a while. we want to remove the dual support for old streams soon
<thumper> sinzui: so... fix in 1.20 series or not?
<sinzui> thumper, if it isn't patch hell, yes please.
<thumper> ok
<thumper> so what I need now is a 1.18 binary so I can bootstrap and test upgrades
 * thumper pokes around
<thumper> bugger
<thumper> /usr/bin/juju is 1.20.11
 * thumper goes to get files out of the package by hand
 * thumper goes to make lunch first
<sinzui> thumper, ci has a cache of what was published in trusty
 * sinzui looks
<thumper> sinzui: can we find the amd64 version for 1.18.x where x is the latest?
<sinzui> yep, Lp will have it too
 * sinzui looks
<sinzui> thumper,  expand 1.18.4 and download the juju-core and juju-local package https://launchpad.net/ubuntu/+source/juju-core
#juju-dev 2014-11-19
<mgz> exit eod
<perrito666> anyone savvy on FacadeCall?
<thumper> anyone know how to extract files from a .deb without installing it?
<perrito666> dpkg -x
<perrito666> thumper: ^
<thumper> perrito666: ta
<perrito666> np
<thumper> colour me confused...
<thumper> menn0: you have done lots of upgrades recently
<thumper> I have bootstrapped a 1.18.4 local environment
<thumper> /usr/bin/juju is 1.20.11
<thumper> but if I go `/usr/bin/juju upgrade-juju` it says: no upgrades available
<thumper> WTF?
<perrito666> thumper: colour? have you just tried to use irc colors?
<perrito666> thumper: specifying --version does not help either?
<thumper> do I need to go --upload?
<menn0> thumper: to be honest i've never tried upgrading to the official releases
<thumper> menn0: how do you do it?
<menn0> thumper: with --upload-toools
<menn0> tools even
<thumper> hmm...
<thumper> ok
<menn0> but i'm pretty sure what you've just tried is supposed to work
<menn0> could be a bug
<thumper> ok that upgraded
<thumper> ok, confirmed that 1.18 local provider upgrading to 1.20.11 breaks juju-run as expected
<thumper> not to fix it
<thumper> I did just want to confirm that it was doing what I thought it was doing
<menn0> thumper: it might be a local provider thing
<menn0> thumper: according to the upgrade-juju help output the tools selection behaviour is somewhat provider dependent (e.g. for maas you need to install the tools yourself)
<thumper> ah
<davecheney> SHIT
<davecheney> why does params.ProvisioningInfo.Jobs take a []state.MachineJob
<davecheney> ie, and int
<davecheney> can I change it ?
<menn0> thumper: can you have another look at http://reviews.vapour.ws/r/489/ pls?
<menn0> thumper: i've created issues for the 2 bits i'd like you to look at
<thumper> kk
<menn0> thumper: the handling of panics in that defer wasn't quite right IMO. it was swallowing the panic when it should re-panic after cleaning up.
<thumper> menn0: to be honest, we don't have any other panic handling like that
<thumper> menn0: probably worth asking davecheney if it is worth it
<menn0> thumper: the reason it's there is because I did have a panic happening during tests but that was hidden because the state wasn't being closed so instead i got the "dirty sockets" errors
<thumper> ah
<menn0> davecheney: can you have a look at one of the issues i've marked for  http://reviews.vapour.ws/r/489/
<menn0> davecheney: the recover, close, re-panic bit
<menn0> davecheney: am i being silly?
<davecheney> ywah, don't do that
<davecheney> it'll end up looking like gocheck
<davecheney> the way it eats the panic
 * thumper wants to stab the person that added the second of "StateServerInfo" and "StateServingInfo"
<davecheney> thumper: i know
<davecheney> i think that was me
<davecheney> i want to get rid of both of them
<menn0> davecheney: so what would you recommend? state needs to get closed if something goes wrong
<davecheney> i have several responses
<davecheney> none you'll like
<davecheney> so i'll not suggest them
<wwitzel3> ok, so I've been attempting to run an apiclient call from inside the debughooks cmd, specifically a call to Resolved(), exposed by using a --retry flag on the debug-hooks command.
<wwitzel3> is there a way to issue the call from the debughooks session? would it make sense to extend the runserver (juju-run) to accept a resolved retry command?
<wwitzel3> because internal to the debughooks / SSH cmd stuff, it does a c.Wait and that makes issuing the client.Resolved call a bit tricky, I can use go routines and select, but then control is returned instead of Waiting since the execution is happening in the go routine.
<wallyworld_> axw: standup?
<axw> wallyworld_: can you send me hte link? calendar decided it needed to upgrade
<davecheney> menn0: can you just let the panic happen ?
<wallyworld_> axw: https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
 * axw taps fingers in google's direction
<axw> ta
<davecheney> state will be closed anyway when the process dies
<menn0> davecheney: I guess so. the reason that panics are being handled was because not closing state there was hiding the real cause of a failure in the tests while I was working on this change
<menn0> davecheney: our test cleanup stuff checks if any mgo connections are still open and reports that if they are
<menn0> davecheney: and hides the original panic in the process
<menn0> davecheney: i might just remove that
<menn0> davecheney: regarding your comment about err needing to be passed into the defer func
<menn0> davecheney: that doesn't quite work because if err is set after the defer line the defer func doesn't see the error
<menn0> davecheney: or perhaps I'm missing something
<menn0> davecheney: for example: http://play.golang.org/p/1zKj4v9pQP
<menn0> davecheney: but what I want is: http://play.golang.org/p/b-zvXikd-Y
<menn0> davecheney: or do you actually want: http://play.golang.org/p/wP2pfIGd4c ?
<thumper> ah fuck fuck fuckity fuck
 * thumper glares at the code
<davecheney> menn0: declare err in the scope of the function by making it a named return value
<davecheney> menn0: http://play.golang.org/p/NXg0tPrqHq
<katco> axw: thanks again for the suggestion; that was really insightful. "time is an external resource". axw: the philosopher engineer.
<katco> axw: http://foomandoonian.files.wordpress.com/2011/11/philosoraptor-time-freeze.png?w=500
<thumper> menn0: sanity check plz? http://paste.ubuntu.com/9083907/
<thumper> menn0: and now for the 'orrible unit tests...
<thumper> wallyworld_: see paste above for juju-run fix (in 1.20 branch)
<axw> katco: lol :)
<axw> no worries
<axw> katco: sorry if I lead you astray back in Boston
<katco> axw: oh no not at all. i actually meant that i remembered us addressing this same kind of problem -- you helped
<katco> (again)
<katco> so thank you :)
<axw> cool. I'm wondering whether we should define a time interface somewhere, with an implementation based on the standard time package
<katco> axw: i really don't know. i feel like i need to immerse myself more in that test to form an opinion. but i still don't feel right masking perfectly fine go std libs
<katco> (at the moment)
<axw> katco: yup, fair enough, I struggle with that a bit
<axw> (hence the regular flip flopping)
<katco> hehe
<thumper> ah stabby stabby
<thumper> (â¯Â°â¡Â°)â¯ï¸µ â»ââ»
 * thumper goes to clean the kitchen for a few minutes
<katco> haha
<katco> i'm so glad i met thumper... i can picture this so much better
<waigani> katco: if you knew the half of it....
 * katco laughs
<waigani> davecheney: that's very tricky :)
<thumper> oh ffs
<thumper> I think I have hit another typed nil bullshit error
<thumper> davecheney: help
<davecheney> waigani: it's not my pattern, william and frank came up with that one
<davecheney> i'm +/- on it
<davecheney> i think it's too clever for it's own good most of the time
 * davecheney reaches for curmudgeon hat
<thumper> fuckity fuck fuck
<thumper> davecheney: http://paste.ubuntu.com/9084574/ line 123
<thumper> [LOG] 0:01.337 INFO juju.upgrade err: <nil> <nil>, apiErr: *params.Error <nil>
<thumper> [LOG] 0:01.337 INFO juju.upgrade true
<thumper> oh... now I know why the expression was there before...
<thumper> stabby
<davecheney> typed nil strikes again
<thumper> god that's horrible
<thumper> had to replace the test wth: if err != nil || errResults[0].Error != nil {
<thumper> which is what it had before, but I thought I was being clever
<thumper> too clever apparently
<thumper> damn
 * thumper heads to physio again
<davecheney> typed nils are bad
<davecheney> there is only one use of them in the std lib
<davecheney> in the guts of the net package
<davecheney> and it's only because not doing it that way would be much worse
<menn0> davecheney: right. so the sample you sent me is almost identical the last one I sent you.
<menn0> davecheney: is there any technical reason why that's better than http://play.golang.org/p/b-zvXikd-Y ?
<menn0> davecheney: i.e. is it just a style thing
<davecheney> menn0: i guess so
<davecheney> i don't think this cleverness pays off in general
<davecheney> i use named return arguments as a clue that the method is doing something clever
<davecheney> if it's not actualloy doing something clever, then I recommend they are removed
<menn0> davecheney: ok. i just wanted to understand if i'm missing some technical aspect.
<menn0> davecheney: named return values are a little annoying in this case because there's 2 other return values and if you want to name one of them you have to name all of them.
<menn0> davecheney: it uglies up the function a bit
<davecheney> menn0: use _
<davecheney> it should be ugly
<davecheney> it's a sign that it's complicated
<menn0> davecheney: kk you win. I will change it :)
<menn0> davecheney: i've already removed the panic handling btw
<davecheney> cool
<wallyworld_> thumper: looking
<wallyworld_> thumper: i think line 90 is wrong
<wallyworld_> thumper: i think line 90 is wrong
<wallyworld_> if stateInfo.SystemIdentity != "" {
<wallyworld_> should be ==
<davecheney> thumper: menn0 today i'm workgin on teasing apart the uses of MachineJobs
<davecheney> and trying to unpick state.MachineJob.ToParams
<davecheney> i think that method on that type needs to move somewhere else
<menn0> davecheney: sounds good
<davecheney> it wont' be done today
<menn0> waigani: the NewEnvironment tests have landed now so it's a bit easier to set up alternative environments with stuff in them for testing with
<menn0> thumper: forgot to say, i looked at your change ages ago but forgot to say that it looks ok
<waigani> menn0: whoop whoop
 * LinStatSDR giggles
<menn0> thumper: one thing: did you check whether the "systemidentity" is empty or missing?
<menn0> thumper: the assert obviously needs to match whatever happened when that change was made
<menn0> thumper: just saw another thing: in the "if stateInfo.SystemIdentity != "" {" shouldn't that be "==" not "!=" ?
<wallyworld_> menn0: that's what i said too :-)
<menn0> wallyworld_: good :)
<menn0> thumper: I have a simple "canary" environment being set up from ConnSuite.SetupTest
<menn0> thumper: breaks everything :)
<menn0> thumper: which is expected and useful
<menn0> thumper: most of the setups for suites in state die because things get confused when trying to create units when there's data for another environment present
<thumper> menn0: why do they get confused making units?
<menn0> thumper: still figuring it out but one of the asserts is getting tripped up by the data for the canary env
<thumper> hmm...
<thumper> ok
<menn0> thumper: it's the insert into the meterStatus collection
<menn0> here's the txn op ids and asserts:
<menn0> C:units Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:mysql/0 Assert:d-
<menn0> C:statuses Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:u#mysql/0 Assert:d-
<menn0> C:meterStatus Id:u#mysql/0 Assert:d-
<menn0> C:services Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:mysql Assert:[{Name:life Value:alive}]
<menn0> C:constraints Id:d48e84dd-0e78-4e05-87ad-8a0a5acf99e8:u#mysql/0 Assert:d-
<menn0> thumper: the canary env also has a mysql/0 so they're colliding
<menn0> thumper: not sure if that collection is supposed to have been done yet
<thumper> menn0: the meterStatus collection doesn't need it, but it's asserts propably need checking
<menn0> thumper: what do you mean it doesn't need "it"
<thumper> menn0: the collection's _id field is a uuid already
 * thumper thinks
<thumper> I think they are storing the envuuid already
<menn0> thumper: doesn't look like that works been done properly
<thumper> but the asserts that it uses to check docs probaly need checking
<menn0> there's more problems
<menn0> see state/meterstatus.go:70
<menn0> thumper: i don't see anything in meterstatus.go that indicates it's using env uuid prefixes
<thumper> no, it isn't using env uuid prefixes
<thumper> but I was told it didn't need it...
<thumper> menn0: can you fix it?
<menn0> thumper: sure, I was about to suggest that
<menn0> thumper: who told you it wouldn't need it? it might be good to find out why someone thought that in case we're missing something.
<thumper> menn0: me
<thumper> when I was looking through things
<thumper> I have been known to be wrong before :-)
<menn0> thumper: really? :-p
<menn0> updating the doc and LK then I'm EOD
<thumper> fuck fuck fuck fuck
<thumper> fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck
 * thumper head desks
<wwitzel3> sooooo how's it going?
<thumper> pretty sure my upgrade step is writing the new system identity to disk
<thumper> and then the machine agent deletes it
<thumper> this is horrible
 * axw joins in the head desking
<axw> single collection transactions makes me :(
 * thumper is doing a single collection transaction for the assertion
 * axw is referring to his own problems
<thumper> how do we refer to a work in progress in github?
<axw> some people have been putting WIP: in the title
<thumper> wallyworld_: https://github.com/juju/juju/pull/1185 for the fix, missing real tests
<thumper> wallyworld_: and this is just the 1.20 branch
<wallyworld_> looking
<thumper> wallyworld_: although the upgrade step will be almost identical for 1.21
<thumper> wallyworld_: there is a race in 1.20 as all the workers start at once
<wallyworld_> oh joy
<thumper> wallyworld_: so one worker is deleting the system identity that the upgrade step writes
<thumper> so I've commented that bit out for 1.20.12
<thumper> it'll be fine
<thumper> we can make sure it is still there for 1.21 as the race isn't there
<thumper> due to the upgrade synchronisation stuff menn0 did
<thumper> but tests will have to wait until tomorrow
<thumper> I have tested manually
<thumper> going from 1.18.4 -> 1.20.11 -> 1.20.12
<thumper> and juju run works again after failing in the middle
<thumper> should also test 1.18.4 -> 1.20.12
<thumper> but not done that yet
 * thumper is done for the day, 
<thumper> dinner is calling
<thumper> and so is the wine
<thumper> later folks
<urulama> wallyworld_: you're frozen in hangouts
<rick_h_> urulama: up early?
<jw4> davecheney: I can't reproduce bug 1394066 on master... are you seeing it consistently
<mup> Bug #1394066: FAIL: action_test.go:254: ActionSuite.TestActionsWatcherEmitsInitialChanges <juju-core:New> <https://launchpad.net/bugs/1394066>
<wallyworld_> jamespage: are you ok for a chat in about an hour's time about charm status changes?
<wallyworld_> jam: fwereade_: i had scheduled a juju status meeting to talk with jamespage from a charmer's perspective, but looks like he's not around
<fwereade_> wallyworld_, bother
<wallyworld_> fwereade_: you were also not around yesterday for our 1:1 :-)
<wallyworld_> i'll try and reschedule
<fwereade_> wallyworld_, sorry, yes, I was up stupidly late and then slept much of the day :(
<wallyworld_> np :-)
<wallyworld_> fwereade_: jam: was there anything major in the email I sent that was off the mark? if not, i'll update the doc
<jam> wallyworld_: it all looked pretty good to me
<wallyworld_> ok, ta will run with that
<wallyworld_> fwereade_: it would be great if you could add your 1 penny's worth to the juju-dev thread talking about goal state, unit count, quorums etc
<fwereade_> wallyworld_, bother, one thing I never mentioned, I'm not sure about the agent setting allocating/installing/error in *unit* state?
<fwereade_> wallyworld_, aren't those still agent states?
<jam> fwereade_: I believe they are both, because the unit agent can't set allocating/installing
<wallyworld_> fwereade_: i had thought allocating can be considered unit state, but i can also see it does relate to the agent
<wallyworld_> i'd like to keep as both
<fwereade_> wallyworld_, auto-setting busy/running if set-status hasn't been used is fine
<wallyworld_> that way people can mosylu look just at unit state and get all they need
<fwereade_> wallyworld_, allocating in unit state is fine, I think, because no overlaps
<fwereade_> wallyworld_, in responsibility
<wallyworld_> yeah
<fwereade_> wallyworld_, installing feels like a different way of spelling busy that only happens sometimes
<fwereade_> wallyworld_, and I think that error is a can of worms
<fwereade_> wallyworld_, because (1) it's usually a filthy lie
<wallyworld_> error on unit state means the hook failed
<fwereade_> wallyworld_, right
<wallyworld_> error on agent state means something fucked up in the agent
<fwereade_> wallyworld_, that's not what it means at the moment
<wallyworld_> true, but that's what we can make it mean, i think without upsetting people?
<wallyworld_> i was hoping to ask james etc
<fwereade_> wallyworld_, that throws away any ability to convey the difference between management failures and software failures
<fwereade_> wallyworld_, a failing hook does not automatically imply non-functioning software
<fwereade_> wallyworld_, in fact it's pretty rare that a hook failure will have *anything* to do with what the software is up to
<wallyworld_> depends doesn't it?
<wallyworld_> if install hook fails, itsn't it likely the software won't run?
<fwereade_> wallyworld_, won't unit-state already be "busy" then?
<fwereade_> wallyworld_, it's not *meant* to be running after the install hok
<wallyworld_> it will be installing
<wallyworld_> unless the charm sets it to busy
<wallyworld_> unit agent sets unit state to installing just prior to running install hook
<fwereade_> wallyworld_, do you not think that having overlap in values for unit-state and agent-state, that don't even mean the same thing, is asking for trouble?
<wallyworld_> it's not meant to be running after install hook, true, but my point is, if install hook fails, then it likely won't ever run
<fwereade_> wallyworld_, right
<fwereade_> wallyworld_, however we spell it, the unit state should *already* reflect that it's not running
<wallyworld_> i'm not sure overlap in values is bad or not, i'd like another opinion
<fwereade_> wallyworld_, the thing that's actually *wrong* is that the agent has stopped reacting to changes
<fwereade_> wallyworld_, that is the only thing we know
<wallyworld_> sorry, what's the context of "the only thing that is actuall wrong"?
<fwereade_> wallyworld_, in the absence of specific information from status-set, we don't know about the state of hte software
<wallyworld_> true
<fwereade_> wallyworld_, what we do know, given an error state, is that the agent has become upset by something the charm did and wants a human to help it out
<wallyworld_> the agent guesses though if the unit doesn;t tell it othereise
 * fwereade_ gets to use the zen of python again :)
<fwereade_> wallyworld_, in the face of ambiguity, resist the temptation to guess
<wallyworld_> we do now
<wallyworld_> if started hook runs, then assume software is functional
<fwereade_> wallyworld_, no argument there, but are you suggesting that's a *good* thing?
<wallyworld_> and for old charms, we need to maintain that assumption
<wallyworld_> no
<wallyworld_> just that we need to continue to do it if the charm doesn't tell us
<fwereade_> wallyworld_, how do old charms come into this? we won't set "running" because we won't progress past the start hook
<TheMue> morning
<fwereade_> wallyworld_, so, surely, orthogonal?
<wallyworld_> we set running for old charms if they don't use status-set during start hook
<fwereade_> wallyworld_, I would add "and the start hook doesn't error"?
<wallyworld_> yes, of course :-)
<fwereade_> wallyworld_, so... I still think this is orthogonal to discussions about whether we overwrite unit-state?
<fwereade_> wallyworld_, oh hell
<wallyworld_> maybe we take this to a hangout?
<fwereade_> wallyworld_, use of status-set will really not play nicely with charm upgrades, will it
<fwereade_> wallyworld_, yeah, let me grab another coffee, with you in a mo
<mattyw> morning everyone
<wallyworld_> ok
 * wallyworld_ gets a wine
 * TheMue would like to join, but 10am is a bit early :D
 * fwereade_ has a mildly jealous
<wallyworld_> well it's after 19:00 here :-)
<wallyworld_> fwereade_: https://plus.google.com/hangouts/_/canonical.com/juju-status
 * TheMue will compensate his abstinence now with a fine single malt this evening
<jam> TheMue: dimitern: voidspace: I'll be there in about 2 min
<dimitern> voidspace, standup?
<voidspace> dimitern: om2w
<voidspace> *omw
<perrito666> morning
<voidspace> perrito666: morning
<voidspace> jam: dimitern: yep, if we use ec2.EC2.NetworkInterfaces then the new IP address shows up
<voidspace> jam: dimitern: so I'll go mark that bug against goamz as invalid
<dimitern> voidspace, but how about the Instances() output? does it have the IPs?
<voidspace> dimitern: no, it's Instances that doesn't
<voidspace> dimitern: you have to get the interface id and fetch it from that
<dimitern> voidspace, that will work, but I'd rather use the pre-existing Instances() if possible
<voidspace> dimitern: it is not in the ec2 response
<voidspace> dimitern: it's not a goamz issue
<dimitern> voidspace, I mean, if it's a goamz bug due to parsing the output
<dimitern> voidspace, how did you verify that? what aws api version?
<voidspace> dimitern: I'll double check, but it's not in the xml response dumped out with debug on
<dimitern> voidspace, because I think it's due to not using the vpc-aware version or DescribeInstances
<voidspace> dimitern: I'm using the default version used by goamz - would I need to change that?
<voidspace> dimitern: and the ec2.Instances call *is* a call to DescribeInstances I believe?
<dimitern> voidspace, because the ec2 response you're getting will match the response expected by the aws api client using the version specified in the request
<dimitern> voidspace, e.g. trying to run RunInstances specifying SubnetID and older (non-vpc-aware) version will return an error like "invalid field subnetid"
<voidspace> note that the Instances call is *definitely* a call to DescribeInstances - the response xml is a <DescribeInstancesResponse>
<voidspace> just trying to see if I can see the request header for the version
<voidspace> no, it doesn't dump the requests - just the responses
<voidspace> dimitern: we have a vpcId in the response - so I doubt it's a non-vpc-aware version of the api
<voidspace> not definitive though
<dimitern> voidspace, hmm... then it is an ec2 api bug then
<voidspace> dimitern: looks like it
<voidspace> dimitern: shall I work on ReleaseAddress for ec2?
<dimitern> voidspace, yes, please
<anastasiamac> i've synced upstream and now build fails due to issues in backups primarily (altho there r others)...
<anastasiamac> anyone else seeing this behaviour?..
<perrito666> anastasiamac: I cant say I havent
<perrito666> anastasiamac: could you pastebin the errors?
<anastasiamac> perrito666: thnx.. my bad - outdated utils ;-)
<perrito666> anastasiamac: lol
<perrito666> happens a lot to me
<perrito666> like once every pull :p
<anastasiamac> perrito666: :-)
<voidspace> dimitern: ping
<voidspace> dimitern: actually, you were correct
<voidspace> dimitern: goamz uses two different aws api versions - a "legacy version" for most things and a "vpc aware" version only for vpc related calls
<voidspace> ah, dammit
<voidspace> no -I'm still looking at DescribeNetworkInterfaces
<dimitern> voidspace, yes, that's why I was asking which one you use :)
<voidspace> let me check DescribeInstances
<dimitern> voidspace, I thought you're testing with the ec2 cli
<voidspace> dimitern: yes, confirmed
<voidspace> dimitern: nope
<dimitern> voidspace, right :)
<voidspace> dimitern: I did a bit - I still find goamz easier
<voidspace> dimitern: so DescribeInstances *does* show the private ip address when you use the vpc aware api version
<voidspace> dimitern: http://pastebin.ubuntu.com/9094670/
<voidspace> dimitern: that last faragment
<dimitern> voidspace, sweet!
<voidspace> The privateIpAddressesSet
<voidspace> dimitern: well, except we have to work out how to get goamz to use the vpc version of the api for describe instances
<voidspace> dimitern: is it configurable that you know of?
<dimitern> voidspace, so we probably should use the vpc-aware version (which is not the very latest btw) for all goamz calls
<dimitern> voidspace, nope, not globally
<dimitern> voidspace, when I did those vpc changes to goamz I didn't want to switch *all* calls to use the new version, it seemed risky
<voidspace> dimitern: vpcAPIVersion = "2013-10-15"
<voidspace> dimitern: ah, you did those changes
<dimitern> voidspace, yeah
<voidspace> dimitern: so you're fairly familiar with the mechanism then...
<dimitern> voidspace, I was at least :) it's been a while
<voidspace> dimitern: do you want me to do anything about it right now?
<voidspace> dimitern: I guess we file the knowledge away for "shortly" when we need it
<dimitern> voidspace, I think we should file a bug against goamz for DescribeInstances to use the vpc-aware api version
<voidspace> dimitern: ok, I'll do that
<dimitern> voidspace, cheers
<voidspace> dimitern: https://bugs.launchpad.net/goamz/+bug/1394186
<mup> Bug #1394186: vpc aware aws api should be used for DescribeInstances <goamz:New> <https://launchpad.net/bugs/1394186>
<dimitern> voidspace, ta
<dimitern> voidspace, I'll pick that up and propose a fix for it later today
<voidspace> dimitern: cool, thanks
<mattyw> dimitern, wwitzel3 I've added you both as mods to /r/juju
<perrito666> ericsnow: you are not around by any chance are you?
<dimitern> mattyw, thank you
<bac> Hi marcoceppi, do you plan to release a new amulet to the PPA any time soon? We need some recent changes and getting them via the PPA is the easiest for our charms.
<marcoceppi> bac: I was going to do a release on Friday, need something sooner?
<bac> marcoceppi: friday is probably ok, but if you have time and are feeling charitable sooner is better.  i'm happy either way.
<marcoceppi> bac: ack
<wwitzel3> fwereade_: ping?
<perrito666> natefinch: you need a font with broad unicode support
<perrito666> I had to install quivira font to see it
<natefinch> perrito666: ain't nobody got time for that
<wwitzel3> lol
<natefinch> well... except you, evidently :)
<perrito666> natefinch: installing a font takes a couple of secconds gnome-font-viewer yourfont
<perrito666> then click install
<perrito666> it helped that I knew what the font was
<perrito666> s/font/char
<perrito666> so I just googled for the first font with support for it
<perrito666> I do wonder if it ever finishes loading
<perrito666> otherwise seems like a stream of U0001f4a9
<mgz> jog: I see bug 1250104 but no general destroy-machine --force failing bug
<mup> Bug #1250104: destroy-machine --force may require multiple invocations <juju-core:Triaged> <https://launchpad.net/bugs/1250104>
<fwereade_> wwitzel3, sorry, pong
<mgz> can someone review https://github.com/juju/juju/pull/1184 before I possibly accidentally land it?
<mgz> (github doesn't think I'm human atm so it's not up on reviewboard)
<wwitzel3> fwereade_: no worries need some help trying to solve an issue I'm running in to, quick hangout?
<perrito666> ericsnow: natefinch wwitzel3 standup?
<natefinch> perrito666: yeah, one minute, sorry
<perrito666> you dont need to apologize for standups they are not your fault
<natefinch> wwitzel3, ericsnow: standup?
<wwitzel3> natefinch: chatting with fwereade brt
<natefinch> wwitzel3: sure no prob
<natefinch> hmmm... chrome has started to have tabs randomly crash
<ericsnow> perrito666: I'm here
<perrito666> ericsnow: hey, how are you feeling?
<ericsnow> perrito666: well enough
<perrito666> doesnt sound really inspiring
<perrito666> :p
<ericsnow> perrito666: I've been worse (last night for instance)
<perrito666> well loved your changes and I integrated most of them yet I do need http://reviews.vapour.ws/r/493/ landed or I cannot compile :)
<ericsnow> perrito666: yep, and again it got hijacked
<perrito666> ericsnow: tell me more :)
<ericsnow> perrito666: I'm going to push for landing the change as-is and then addressing concerns afterward
<ericsnow> perrito666: well, there are 33 issues opened on code that I'm just moving from point A to point B
<ericsnow> perrito666: basically none of it is new code
<ericsnow> perrito666: while I appreciate the insight and agree it's worth addressing most of it, it shouldn't hold up restore
<perrito666> I would agree that it needs to be merged and adressed after restore is merged so we are not doing all work twice
<ericsnow> perrito666: if no one feels comfortable making that decision beforehand, I'll bring it up with davecheney when he gets in
<perrito666> ericsnow: I feel comfortable if those are addressed after (that technical debt is already there)
<perrito666> but my +1 is kind of worthless
<LinStatSDR> Hello
<voidspace> goodnight all
<natefinch> perrito666, ericsnow:  eric - you have a shipit.  I'll take full responsibility if anyone complains later.
<perrito666> uh, blank check, sweet
<natefinch> haha
<perrito666> ericsnow: lemme know if you merge that please
<ericsnow> perrito666: k
<perrito666> ericsnow: your build failed with some odd error
 * perrito666 crosses fingers
<perrito666> ericsnow: I really hope that is not the build broken
<mwhudson> davecheney: for your amusement
<mwhudson> davecheney: the a.p != nil line here: https://code.google.com/p/go/source/browse/src/cmd/go/build.go#1925
<mwhudson> is a bit pointless given the line above :)
<waigani> mjs0: not sure if last message got through, my connecting dropped. Can we talk through the openPort upgrade when you have a moment?
<mjs0> waigani: sure. my internet has been dropping out a lot this morning
<menn0> waigani: I think my link just dropped too (it's been flaky this morning)
<menn0> waigani: but yes, let's talk about that problem.
<waigani> menn0: you seem to be going through an identity crisis also...
<waigani> menn0: okay, stand up chan?
<menn0> waigani: going to standup channel now
<ericsnow> perrito666: landed (and I'm signing off)
<perrito666> ericsnow: cheers tx
<waigani> menn0: lost you
<thumper> I thought it was a bit too quiet
<thumper> http://reviews.vapour.ws/r/495/diff/# updated for review
<menn0_> thumper: waigani and I were wondering where you were :)
<menn0_> thumper: we might need to chat about something later on today regarding old migration steps
<waigani> davecheney, thumper, menn0: http://reviews.vapour.ws/r/496/diff/#
<waigani> just doing manual testing now
<mgz> ericsnow: any idea what I'm missing for reports love on pr 1184?
<mgz> *reviewboard
<waigani> mgz: do you have the rbtool? If so `rbt post` should push your diff up to RB
<thumper> menn0: got a minute?
<menn0> thumper: yep
<thumper> menn0: standup hangout?
<menn0> thumper: yep
<mgz> waigani: I thought it got picked up anyway now...
<waigani> mgz: it *should*
<waigani> thumper, davecheney, menn0: in case your looking at my branch - just realised I forgot to hook the upgrade step up, facepalm
<menn0> waigani: whoops
<waigani> menn0: manual testing is a good thing!
<menn0> waigani: so I was talking to thumper about something else and brought up the issue with the ports migration step
<menn0> waigani: he thinks we should aim to allow multi-version upgrade hops
<menn0> waigani: which means the test still needs to work
<waigani> sigh
<menn0> waigani: so using a manual DB query in the test is probably the way to go(i.e. not using state objects)
<waigani> okay
<davecheney> ericsnow: is this one ready for review ? http://reviews.vapour.ws/r/493/
<davecheney> aisrael: please make this review as submitted, http://reviews.vapour.ws/r/262/diff/#
<davecheney> waigani: http://reviews.vapour.ws/r/496/ please make the change and repropose this when it's ready
<waigani> davecheney: thanks
<aisrael> davecheney: Sorry, I'm not sure what you need me to do.
<davecheney> aisrael: because of the unique power of reviewboard, you have to make the review as submitted when you merge it on github
<davecheney> otherwise it stays around in the list of things to be reviewed
<aisrael> davecheney: ok, I'll see if I can figure that out. I've never used reviewboard before.
<perrito666> davecheney: mmm that used to be automatic
<waigani> davecheney: what did you think of the refactoring of state/upgrades.go? I used your option funcs pattern.
<menn0> waigani: I see a spot where env-uuid isn't being set on a status doc
<menn0> state/service.go: addUnitOps
<waigani> menn0: sit
<waigani> shit even
<menn0> waigani: statusDoc is being created without it being set
<menn0> I think createStatusOp should probably add it
<aisrael> davecheney: Is this something I need to do in reviewboard, or github?
<menn0> waigani: yeah, same problem in insertNewMachineOps
<waigani> aisrael: in reviewboard, go to your review request page, there will be a "Close" tab
<davecheney> aisrael: reviewboard
<davecheney> sadly only the author can close reviews
<aisrael> davecheney: I'm not the original author, though. That'd be jrwren. He gave me commit access to his fork so I could fix the tests.
<davecheney> shit
#juju-dev 2014-11-20
<thumper> screw git...
<thumper> how to I reset hard?
<thumper> ...
<jw4> git reset --hard
<thumper> leaves me with lots of untraced files
<thumper> jw4: did that
<jw4> hmm; were they added files?
<thumper> how do I get rid of the untracked files?
<thumper> from a screwed up pull
<jw4> well if you don't have any changes you want to keep:
<jw4> git rm -r --cached .
<thumper> what does that do?
<jw4> step 1
<thumper> I want the equivalent of "bzr clean-tree"
<jw4> yep
<jw4> wait
<jw4> even easier
<jw4> git ls-files -o --exclude-standard
<jw4> | rm
<jw4> *should* remove all the untracked files
<jw4> the git rm -r --cached . removes all the files from the stage
<jw4> but you just need "git ls-files -o --exclude standard | rm"
<jw4> if you did do the rm --cached command you follow it with "git reset --hard " again to get your working copy back
<menn0> jcw, thumper: does the "git clean" command not help?
<jw4> menn0: ;-p
<jw4> thumper: just do git clean
<jw4> menn0: I've just spent hours figting line ending conflicts so my head was in the "cleanup stage" mode
<jw4> thumper: did 'git clean -fdx' work?
<waigani> thumper: http://pastebin.ubuntu.com/9108069/ save that as git-clean-tree (no .sh) in your path
<waigani> thumper: you can the go `git clean-tree`
<thumper> waigani: I'd prefer not to have a bunch of special aliases
<thumper> it makes it hard to work with others
<waigani> thumper: okay, it's just two commands
<thumper> git clean -df worked
<waigani> 1. `git clean -df` removes any [d]irectories and [f]iles not added
<waigani> 2. git checkout . discards any uncommited changes
<waigani> davecheney, menn0: I've hit a bug in manual testing that I can't reproduce (yet) in the unit tests on this openPorts, so I might not get to the other tasks for a bit
<waigani> "on this openPorts branch" I mean
<davecheney> kk
<waigani> ah, menn0 it wasn't just the tests. st.Ports is used in the actual (1.21) upgrade step to get all the ports to upgrade. That explains the bug I'm hitting in manual testing.
<thumper> menn0: http://reviews.vapour.ws/r/497/
<thumper> menn0: if you want to look at it since you looked at the 1.20 one
<thumper> menn0: actually, I'll propose it for trunk first
<thumper> menn0: that is the 1.21 branch
<thumper> menn0: this is the trunk comit - http://reviews.vapour.ws/r/498/
<menn0> thumper: looking
<thumper> ta
 * thumper is running all the tests...
<thumper> again
<thumper> had a missing import statement
<menn0> thumper: review done
 * thumper is wondering why the tests aren't seeming to progress...
<thumper> normally they are done by now...
<davecheney> thumper: mongo pooped itself, then you have to wait for the timeout ?
<menn0> thumper: and other review done
 * thumper grunts
<thumper> ffs
<thumper> why are we testing this shit in two places
<davecheney> thumper: my favorite is the way that api/* and apiserver/* have the same set of tests
<waigani> this is ugly ugly ugly
<thumper> WT actual F
<thumper> I have a test failure where it says it writes the file, but then says it doesn't exist...
<thumper> I don't see anywhere where it removes it it between
<thumper> and this time it panics
<thumper> panic: API not available from this context
<thumper> how can that work sometimes and not others?
<thumper> fucking weird... the real upgrades work, but the tests for jujud fail
<menn0> hmmmm
<menn0> you can't destroy a 1.22 env with a 1.20 client
<menn0> $ /usr/bin/juju destroy-environment --force --yes local
<menn0> WARNING unknown config field "block-destroy-environment"
<menn0> WARNING unknown config field "agent-metadata-url"
<menn0> WARNING unknown config field "uuid"
<menn0> WARNING unknown config field "prefer-ipv6"
<menn0> WARNING unknown config field "set-numa-control-policy"
<menn0> WARNING unknown config field "block-destroy-environment"
<menn0> WARNING unknown config field "uuid"
<menn0> WARNING unknown config field "agent-metadata-url"
<menn0> WARNING unknown config field "set-numa-control-policy"
<menn0> WARNING unknown config field "prefer-ipv6"
<menn0> WARNING unknown config field "prefer-ipv6"
<menn0> WARNING unknown config field "block-destroy-environment"
<menn0> WARNING unknown config field "agent-metadata-url"
<menn0> WARNING unknown config field "uuid"
<menn0> WARNING unknown config field "set-numa-control-policy"
<menn0> ERROR cannot find network interface "": net: invalid interface name
<menn0> ERROR failure setting config: cannot find address of network-bridge: "": net: invalid interface name
<menn0> 1.22 client works
<axw> wallyworld_: that MAAS API meeting is going to be difficult for me to attend, I have to take my daughter to school then
<wallyworld_> ah
<thumper> ah...
 * thumper pokes the mock
<wallyworld_> axw: would 30 minutes later work?
<axw> wallyworld_: worse :)  2 hours earlier would be good...
<axw> 1 hour earlier at a stretch
<wallyworld_> that clashes with the sprint schedule i think, i'll check
<wallyworld_> yeah, sprint sessions are earlier
<axw> wallyworld_: I could go an hour later too
<wallyworld_> maybe an hour later? that would be 7pm for them
 * thumper stabs this tangled mess repeatedly
<wallyworld_> they can delay their dinner maybe, or eat earlier
<wallyworld_> i'll check with alexis
<thumper> menn0: ok, need some help here
<menn0> thumper: ok
<menn0> thumper: standup channel?
<thumper> yep
<menn0> thumper, davecheney: here's the env UUID upgrade for the meterStatus collection
<menn0> http://reviews.vapour.ws/r/499/diff/
<menn0> waigani: here's the meterstatus env uuid work http://reviews.vapour.ws/r/499/diff/
 * menn0 is off to run some errands
<waigani> menn0: done
<thumper> menn0: http://reviews.vapour.ws/r/497/diff/# has been updated to unblock 1.21 release
<thumper> menn0: I'll fix for 1.22 with different patch that splits out the work
<menn0> thumper: looking
<menn0> thumper: i see you've already submitted so all good.
<menn0> thumper: good idea to get this in and then do the split.
<menn0> wallyworld_: ping
<wallyworld_> hi, otp, one sec
<menn0> wallyworld_: np
<wallyworld_> menn0: hiya
<menn0> wallyworld_: so I discovered earlier that a 1.20 client can't destroy a 1.22 env
<menn0> wallyworld_: would you call that a bug?
<wallyworld_> i think so
<wallyworld_> yes
<wallyworld_> sigh
<wallyworld_> raise a bug and we'll fix it for 1.22
<menn0> there emitted error is:
<menn0> ERROR cannot find network interface "": net: invalid interface name
<menn0> ERROR failure setting config: cannot find address of network-bridge: "": net: invalid interface name
<menn0> writing up a bug now
<wallyworld_> ok, so some new config was introduced in 1.22
<wallyworld_> ta
<wallyworld_> 1.22 needs to be more robust to such situation
<menn0> wallyworld_: here tis: bug 1394450
<mup> Bug #1394450: 1.20 client can't destroy a 1.22 environment <juju-core:New> <https://launchpad.net/bugs/1394450>
<wallyworld_> ta
<anastasiamac> menn0:curiosity kills me - would this happen often that a client is of older version than environment?
<anastasiamac> menn0: i would have assumed that more often u'd encounter 1.20 env and 1.22 client, for eg...
<anastasiamac> menn0: apart from devs?..
<wallyworld_> this also affect 1.21
<menn0> anastasiamac: good question. I guess it's not that common. I just noticed it by accident after I made a mistake while testing upgrades.
<menn0> anastasiamac: still worth fixing if we can I think.
<menn0> wallyworld_: i haven't tested with 1.21 but you're probably correct.
<menn0> wallyworld_: let me check
<anastasiamac> menn0: of course ;-) whether fix is needed or not is not even a question :-)
<wallyworld_> this fix would be to make the network-bridge attribute have a default of lxcbr0 instead of "" i think
<wallyworld_> although it appears the code does use lxcbr0 if network bridge is ""
<wallyworld_> so i'm not sure off hand how this occurs
<menn0> wallyworld_, anastasiamac : i've tried destroying with a 1.21 client and that works fine
<menn0> so it looks like it's just the 1.20 client that has a problem
<wallyworld_> menn0: ah, i meant destroying a 1.21 env ith a 1.20 client
<menn0> ok right
<menn0> wallyworld_: i'll try that then :)
<anastasiamac> wallyworld_: it's coming from utils.network.go ;-(
<wallyworld_> not sure if the issue needs fixing in both 1.21 and 1.22
<wallyworld_> network.go won't work though if we pass in "" for networkName
<anastasiamac> wallyworld_: we find network interface fine (i dont think we r passing "")
<anastasiamac> wallyworld_: we cannot find addrs for the network interface...
<wallyworld_> the bug seems to indicate otherwise
<wallyworld_> but i could be wrong
<wallyworld_> ERROR failure setting config: cannot find address of network-bridge: ""
<wallyworld_> seems to indicate that networkBridge := config.networkBridge() returned ""
<menn0> wallyworld_, anastasiamac: as suspected, a 1.20 client can't delete a 1.21 env either
<menn0> wallyworld_, anastasiamac: ticket updated
<wallyworld_> thanks menn0
<wallyworld_> we'll need to fix this for the 1.21 release
<anastasiamac> wallyworld_: yep ;(
<anastasiamac> wallyworld_: and yes ;(
<anastasiamac> wallyworld_: as u suggested, config var "network-bridge" should probably b defaulted to something other than ""
<wallyworld_> yeah, do it at the schema level instead of in the getter
<wallyworld_> but, i'm not 100% sure why the current code doesn't work
<anastasiamac> wallyworld_: well, wher r we assuming that network bridge is lxcbr0 if we get ""?
<anastasiamac> wallyworld_: from what m seeing we r relying that network bridge is provided
<wallyworld_> before calling getAddressForInterface(), the network bridge value is gotten like so: networkBridge := config.networkBridge()
<wallyworld_> that should have resulted in a non "" being returned
<wallyworld_> so more digging is needed to find out why it is failing
<anastasiamac> wallyworld_: that's easy. network-bridge in config defaults to ""
<wallyworld_> yes, but the getter turns it into a value
<wallyworld_> the getter has code:
<wallyworld_> 		if name == "" {
<wallyworld_> 			return lxc.DefaultLxcBridge
<anastasiamac> wallyworld_:  assuming instance.LXC
<anastasiamac> wallyworld_: can c.container b something other than LXC or KVM
<wallyworld_> no
<jw4> Actions refactor PR - large, but much of it is mechanical. PTAL http://reviews.vapour.ws/r/502/
<jw4> fwereade_, TheMue ptal too ^^^
<jw4> but I welcome anyone's feedback :)
<mattyw> morning all
<TheMue> morning
<TheMue> jw4: will take a look (in case you're still awake *g*)
<dimitern> morning TheMue , mattyw
<TheMue> dimitern: o/
<mattyw> dimitern, TheMue good morning!
<dimitern> does anyone know off hand how to file bugs for subrepos? I found an issue with juju/utils.. maybe I'll just file it against juju-core
<davecheney> dimitern: depends
<davecheney> i've logged them against the repo on GH
<davecheney> ... when it's thumpers stuff :)
<dimitern> davecheney, right ;) so I'll file an issue in GH and a link to a bug in LP then
<davecheney> dimitern: sgtm
<TheMue> davecheney: thanks for editing right for the diary doc
<davecheney> TheMue: no worries
<davecheney> i was surprised that @canonical didn't ahve edit already
<davecheney> ÃÂ¯\_(Ã£ÂÂ)_/ÃÂ¯
<davecheney> urgh
<TheMue> davecheney: yes, I wondered too
<davecheney> y are none of you in the hangout ?
<davecheney> Y U NO JOIN HANGOUT
<TheMue> oh, now? sh**
<TheMue> joining
<voidspace> omw
<jam> fwereade_: team call ?
<voidspace> dimitern: when you get a chance
<voidspace> dimitern: http://reviews.vapour.ws/r/504/
<dimitern> voidspace, will look in a bit
<voidspace> dimitern: and then I need to talk to you about "what next"
<voidspace> dimitern: there are several tasks that look achievable for me, but all with some "hand holding" :-)
<jam> axw: ping for team call ?
<axw> doh
<axw> jam: thanks
<jam> wwitzel3: perrito666: are you coming to the team meeting ?
<dimitern> mattyw, team call?
<voidspace> cold in my room - time to run the whole juju test suite and warm up the computer a bit
<tasdomas> dimitern, mattyw has taken an early lunch
<voidspace> davecheney: thanks for the review
<perrito666> jam: sorry had to solve a couple of last minute issues did not make it
<perrito666> the public transport went on strike the same day the city is flooding with rain.. have to love these people
<davecheney> voidspace: no wuks
<natefinch> ahh crap, I guess the core team meeting moved an 3
<natefinch> hour earlier?
<natefinch> stupid daylight savings
<natefinch> dammit, utopic broke fullscreen.... any app that goes fullscreen now lags like hell
<perrito666> natefinch: from my viewpoint it has not  moved
<natefinch> perrito666: likely because your country does do stupid daylight savings crap
<perrito666> but 3 hs is a bit much
<davecheney> has anyone tried ubuntu.next ?
<natefinch> davecheney: like post utopic?
<natefinch> dammit now my mouse is invisible
<davecheney> yup
<davecheney> the one that jane talked about in the canonical newsletter
<natefinch> tried switching video drivers to see if that would help the fullscreen problem
<davecheney> unity 8 is the default
<natefinch> maybe you should ask first if anyone has read the newsletter ;)
<natefinch> I haven't heard of anyone using ijt.
<perrito666> natefinch: just pat down your desk, must be around
<natefinch> lol
<voidspace> :-)
<natefinch> brb gonna reboot
<perrito666> davecheney: I am curious about unity yet I do need some stability on the rest of my system
<natefinch> I'm willing, I'm a glutton for punishment ;)
<davecheney> perrito666: natefinch don't be a stooge, install it in a vm
<davecheney> you'll know what I mean
<nate-tablet> well this is going well
<nate-tablet> can't log in to Ubuntu because it errors when trying to switch monitor config and dumpsme back at login
<nate-tablet> nice error handling there
<nate-tablet> is there a trick to login without the log in screen?
<davecheney> gotta enable auto login ?
<davecheney> that is part of gdm
<nate-tablet> or is there a way to with from the guest session? that log in works fine
<nate-tablet> s/with/with/
<nate-tablet> auth
<nate-tablet> stupid tablet
 * nate-tablet goes to google "switch display driver from terminal"
<voidspace> nate-tablet: so, the utopic upgrade went well then...
<nate-tablet> it might be mostly a driver issue and one egregious
<nate-tablet> ly
<nate-tablet> bad error handling
<voidspace> right
<voidspace> I hope you get it sorted
<voidspace> sounds like the opposite of fun
<davecheney> i don't mean to swear in church
<davecheney> but ubuntu only really works on thinkpads
<voidspace> it works great on my desktop
<davecheney> intel graphics ?
<voidspace> but then I picked all the components for compatibility and built myself
<voidspace> nope, amd I think
<voidspace> maybe I've just been lucky
<voidspace> driving four monitors from one card though
<perrito666> nate-tablet: enter a session in your shell
<perrito666> then DISPLAY=:1 startx&
<perrito666> then DISPLAY=:1 whateverthewmiscalledthesedays
<perrito666> davecheney: to be honest it sometimes fails on mine, but yes, I have a preference for thinkpads when using linux, just in case
<nate-tablet> davecheney - this is the first major problem I've had
<nate-tablet> (that wasn't caused by juju)
<nate-tablet> besides, I figured it's pretty safe using the same model laptop as Mark S ;)
<perrito666> nate-tablet: well, you seem to have a bit different one
<perrito666> nate-tablet: the right trick, is to have the same laptop linus torvalds has, so when everything else fails, at least the kernel still works
<nate-tablet> maybe he's not running two external monitors
<perrito666> nate-tablet: maybe, I can only run one and it works well enough
<perrito666> to solve that I am tempted to get a desktop machine, but I am to picky about hardware
<davecheney> nate-tablet: i like that qualification
<davecheney> ther is a reason i have a 8gb /tmp partition
<davecheney> in ram
<davecheney> (stupud test runner bug)
<nate-tablet> my two biggest problems with Ubuntu have been back error handling
<nate-tablet> bad
<nate-tablet> no etc/networks? no network!  ....what ever happened to sane defaults?
<davecheney> nate-tablet: yeah, no desktop
<davecheney> no network manager
<davecheney> no network
<davecheney> catch 22
<dimitern> any reviewers willing to take a look at a trivial fix for bug 1394524? https://github.com/juju/utils/pull/91
<mup> Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1394524>
<TheMue> dimitern: will do
<dimitern> TheMue, cheers
<dimitern> jw4, bodie_, hey guys, if you can have a look perhaps ^^ as the fix might have some implications for windows?
<TheMue> dimitern: done
<dimitern> TheMue, thanks
<dimitern> rogpeppe, ping
<TheMue> yw
<rogpeppe> dimitern: pong
<dimitern> rogpeppe, hey, do you know if juju/utils is running under the landing bot? How to land a patch on that subrepo?
<rogpeppe> dimitern: i don't think so
<rogpeppe> dimitern: i can land patches there
<rogpeppe> dimitern: isn't the landing bot intended for repos that actually build binaries?
<rogpeppe> dimitern: (rather than just packages)
<rogpeppe> dimitern: i think the landing bot for juju-core should actually run go test github.com/juju/...
<rogpeppe> dimitern: or at any rate for the packages juju-core depends on
<dimitern> rogpeppe, yeah it does
<rogpeppe> dimitern: ah, cool
<dimitern> rogpeppe, ok, so how will you land it?
<rogpeppe> dimitern: i push the big green button :)
<dimitern> rogpeppe, ha :) ok, I'll try, thanks!
<dimitern> but first let's try a $$merge$$ comment to see if the bot will pick it up
<mattyw> folks - sorry I missed the core hangout - I have my reasons - but there is no excuse
<jam> mattyw: there is *no* excuse, you let us all down. In fact, we could barely even have the meeting at all without you.
<jam> :)
<perrito666> mattyw: happens, I did too, anyway I think there is no room for all of us
<dimitern> TheMue, another related trivial - http://reviews.vapour.ws/r/506/ ?
<mattyw> jam, most of all I let myself down
<TheMue> dimitern: ok, if it's trivial I can jump in. ;)
<dimitern> TheMue, :) it's just updating dependencies.tsv
<TheMue> dimitern: ic, and where is the unit test for it? *lol*
<dimitern> TheMue, :D I wish we had some
<TheMue> dimitern: also all those leading spaces/tabs
<TheMue> dimitern: somehow 6bfed5692f0d524bab3be5976f26d24bd4d3f677 is very self-documenting
<dimitern> TheMue, yeah, indeed
<TheMue> dimitern: so, done
<dimitern> TheMue, thanks!
<TheMue> dimitern: always a pleasure
 * TheMue currently does another, larger review, so has been in the right mode
<jw4> TheMue: I trust your other larger review is mine :)
<TheMue> jw4: eh, ehm, why do you think so? *grin*
<jw4> TheMue: :)
<TheMue> jw4: you already work on daves feedback?
<jw4> TheMue: I'm starting to go through it...
<TheMue> jw4: fine, it's catching most of the points
<jw4> TheMue: a lot of his feedback is about things that are bigger than my change
<jw4> TheMue: but I'll respond to each one in the PR
<TheMue> jw4: yep, so for some of the we may need to create a follow-up
<jw4> kk
<rogpeppe> hmm, so i've just discovered that juju deploy local:trusty/foo can totally ignore the directory $JUJU_REPOSITORY/trusty/foo if there's another charm in there with Meta().Name == "foo"
<rogpeppe> fwereade_: does that seem right to you? it certainly surprised me
<fwereade_> rogpeppe, it's insane but As Designed :/
<rogpeppe> fwereade_: can we just change it please? :)
<rogpeppe> fwereade_: can you think of something it might break?
<fwereade_> rogpeppe, well, it opens the issue of meta name not matching the url we use
<rogpeppe> fwereade_: we could make it complain if the meta name didn't match the dir name
<fwereade_> rogpeppe, it's never been *quite* annoying enough to reach the top of the list; in principle I'd be glad to see it improved; in practice I think we'd need to talk to the people who actually use local repos
<rogpeppe> fwereade_: i think that having meta name in there is silly anyway, but at least then we wouldn't be in such a ridiculous situation (i created the directory, deployed the charm, then wondered wtf was going on)
<fwereade_> rogpeppe, the other reason not to do it is the hope that we'll be able to transition to just publishing directories directly, and forget the whole local repo thing entirely
<rogpeppe> fwereade_: i'm guessing we'll still want a local repo
<rogpeppe> fwereade_: i guess it depends how important the naming-after-series thing is
<fwereade_> rogpeppe, don't we end up needing series in the metadata in the general case though?
<rogpeppe> fwereade_: that is, as we know, a controversial topic :)
<rogpeppe> fwereade_: FWIW I'm +1
<fwereade_> rogpeppe, well, it's only lp-based charms where we get the magic series-from-name thing -- where else is it going to come from?
<fwereade_> rogpeppe, I'm probably just blanking, but I don't recall the controversy
<fwereade_> rogpeppe, multiple-series charms are controversial for usre
<fwereade_> rogpeppe, (lp-based and local-based, I suppose, but local is just aping lp, I think)
<rogpeppe> fwereade_: except... all the official charms are multiple series AFAIK.
<fwereade_> rogpeppe, IMO the only ones where that's really defensible are the subordinates
<rogpeppe> fwereade_: i'd like to robustly defend the ability to create portable software :)
<rogpeppe> fwereade_: and we're not even talking portability across different unix flavours here
<fwereade_> rogpeppe, I'd like to dismissively pooh-pooh the notion that anyone cares what OS they use, so long as their workloads function properly
<fwereade_> ;)
<fwereade_> rogpeppe, subordinates come crashing hard against that statement though
<rogpeppe> fwereade_: i care that i understand something about the OS so i can debug it. i.e. not windows..
<rogpeppe> fwereade_: yeah, subordinates imply we want a single service that can be deployed to multiple series
<fwereade_> rogpeppe, and if we can fix it for subordinates, we can fix it for everything
<fwereade_> rogpeppe, it's just not looming particularly large in my mind atm
<fwereade_> rogpeppe, because, well, subordinates potentially need to be *really* cross-platform
<rogpeppe> fwereade_: it's something that's looming large in my mind, with some possibly significant changes in the charm store needed
<rogpeppe> fwereade_: well, yes
<rogpeppe> fwereade_: i'd like to take the series out of the charm name entirely. that would help quite a lot of things.
<fwereade_> rogpeppe, series feels like a pretty useful part of a charm url tbh
<fwereade_> rogpeppe, but I'm looking at it from a different perspective, I suspect, keen to hear more
<rogpeppe> [14:04:13] <fwereade_> rogpeppe, I'd like to dismissively pooh-pooh the notion that anyone cares what OS they use, so long as their workloads function properly
<rogpeppe> :)
<rogpeppe> fwereade_: it assumes that the OS is just as important as the workload
<fwereade_> rogpeppe, "juju deploy whatever"
<rogpeppe> fwereade_: yup
<fwereade_> rogpeppe, *we* have to care about the charm url, so that our users don't ;)
<fwereade_> rogpeppe, the series, I mean
<fwereade_> rogpeppe, and having the series part of the url is convenient for us, at least
<rogpeppe> fwereade_: yup. that, for me, means that the URL (*the* user-visible part of a charm) shouldn't contain the series
<rogpeppe> fwereade_: it's *kinda* convenient for us, but i don't think we gain that much from it
<fwereade_> rogpeppe, well, we want some way to distinguish between charms for the same workload with different targets, don't we?
<fwereade_> rogpeppe, series does that
<rogpeppe> fwereade_: isn't that what constraints do?
<fwereade_> rogpeppe, and it's easier to read than a hash or something
<rogpeppe> fwereade_: i see series as just one aspect of the "aspects of the target that i care about" continuum
<fwereade_> rogpeppe, the centos, windows, and ubuntu apache charms will actively differ in a number of respects, though, right?
<rogpeppe> fwereade_: oh yes. but that's our problem - the user should be oblivious to their differences, i think.
<fwereade_> rogpeppe, distinguishing by version number is terrifyingly opaque
<fwereade_> rogpeppe, and jamming the target into the name feels strictly inferior to making it a separate component
<fwereade_> rogpeppe, I can't really see other options
<rogpeppe> fwereade_: i think i'd provide a way to publish several charms (with different series) under the same name, and let juju select the appropriate one.
<rogpeppe> fwereade_: that's *kinda* what happens already
<fwereade_> rogpeppe, right, but if you happen to deploy the same workload on different OSs, you want to be aware that they're running different charms
<rogpeppe> fwereade_: i'm not sure
<rogpeppe> fwereade_: only when things go wrong
<rogpeppe> fwereade_: but there are all sorts of things you want to know in that case
<fwereade_> rogpeppe, well, they *are* different charms... if every charm "url" really points to an opaquely context-sensitive redirect (to something without a url?), I think it will be... confusing
<rogpeppe> fwereade_: i guess it depends how much you care about the workload vs how it's implemented
<fwereade_> rogpeppe, for me it's more about a charm url being unambiguous
<fwereade_> rogpeppe, I *don't* actually care about the series, any more than I care about the revision
<fwereade_> rogpeppe, but both those components disambiguate usefully
<rogpeppe> fwereade_: in the end, what the charm *does* can be arbitrarily different depending on platform anyway, regardless of what the contents of the charm are
<sinzui> dimitern, does bug 1394524 need to merged into the 1.21 branch?
<mup> Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1394524>
<fwereade_> rogpeppe, as it can be depending on revision too, right?
<rogpeppe> fwereade_: yeah.
<anastasiamac> sinzui: ping
<sinzui> hi anastasiamac
<anastasiamac> sinzui: about bug 1394450
<mup> Bug #1394450: 1.20 client can't destroy a 1.21 or 1.22 environment <destroy-environment> <regression> <juju-core:Triaged by anastasia-macmood> <juju-core 1.21:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1394450>
<anastasiamac> sinzui: m not convinced it needs backporting
<sinzui> :)
<anastasiamac> sinzui: different version had different defaults for network bridge names
<anastasiamac> sinzui: this ione is specifically about default in 1.22 changing to ""
<anastasiamac> sinzui:1.22 works fine because we specify container specific defaults in the getter
<sinzui> anastasiamac, so 1.22 needs to change to allow any older juju to destroy it?
<anastasiamac> sinzui: however, older clients don't use getter but rather schema default and hence get ""
<jw4> TheMue: responded to davecheney 's feedback - any further feedback on this PR? http://reviews.vapour.ws/r/502/
<anastasiamac> sinzui: kind of - 1.22 needs to set container specific defaults when it sets up env config
<jw4> fwereade_: I'd appreciate your review of ^^ too
<anastasiamac> sinzui: so I am hoping that it's just the change on 1.22 ;-)
<sinzui> me too. thank you anastasiamac
<anastasiamac> sinzui: gr8 :) thnx!
<TheMue> jw4: so far mostly more simple comments, dave already found most
<jw4> tx TheMue
<TheMue> jw4: will submit in a few minutes
<jw4> kk
<TheMue> sometimes diffs are really strange, when new functions are shown as placed inside an existing function and only two lines of the old code are shown afterwards
<jw4> TheMue: I know, I've noticed that too :(
<TheMue> jw4: so, published my comments and now go through your answers to daves comments
<jw4> TheMue: perfect
<fwereade_> jw4, sent a few thoughts/questions
<jw4> fwereade_: excellent, thanks
<rogpeppe> fwereade_: if i do a juju upgrade-charm --force when a unit is an error state, should i expect to get an upgrade-charm hook called at some point in the future?
<fwereade_> rogpeppe, no
<fwereade_> rogpeppe, if upgrade-charm is important you basically have to prefix all your hooks with an effective maybe-upgrade-hook :/
<rogpeppe> fwereade_: how do you know if the charm has been upgraded?
<fwereade_> rogpeppe, heh.
<fwereade_> rogpeppe, copy the charm url file somewhere in the upgrade-charm hook?
<fwereade_> rogpeppe, not that, as a charm author, you're really meant to know about or depend upon that file
<rogpeppe> fwereade_: yeah, i didn't know that existed
<rogpeppe> fwereade_: i guess i could hash the contents of the charm directory
<rogpeppe> fwereade_: or look at the mtime of the metadata.yaml file
<fwereade_> rogpeppe, or, hmm, copy the revision file somewhere?
<fwereade_> rogpeppe, although that *could* fail if you --switch
<rogpeppe> fwereade_: is there guaranteed to be a revision file? maybe, i guess
<fwereade_> rogpeppe, in a deployed charm, yes, I think so
<rogpeppe> fwereade_: yeah, doesn't seem too reliable given switch
<rogpeppe> fwereade_: perhaps this is worth fixing. i think it may be woth guaranteeing that upgrade-charm will be called when the charm is upgraded
<rogpeppe> fwereade_: the problem is there's no decent way around it. if a charm dies in a relation hook and the only way to fix it is to upgrade the charm, there's no way of triggering the upgrade-charm hook *and* retrying the relation hook AFAICS
<perrito666> nate-tablet: did you fix your computer?
<nate-tablet> I'm still on my ta let
<nate-tablet> tablet
<nate-tablet> support is trying to help
<fwereade_> rogpeppe, just a mo, sorry, laura just got home
<rogpeppe> fwereade_: np
<jw4> fwereade_: at your convenience, after reading my responses to your review, we can chat about your issues raised?
<fwereade_> rogpeppe, so, yes, that was essentially the issue
<fwereade_> rogpeppe, we don't really want to run upgrade-charm in the middle of an incomplete, errored hook
<rogpeppe> fwereade_: my expectation was that you'd upgrade the charm, retry the hook, and then upgrade-charm would be run
<fwereade_> rogpeppe, really, honestly, there are only two answers -- either don't depend on upgrade-charm, or make your charm bulletproof enough that no user will have to force-upgrade it :/
<fwereade_> rogpeppe, yay preserving compatibility
<fwereade_> rogpeppe, fwiw that *is* documented, I'm pretty sure
<fwereade_> rogpeppe, not saying it's *good* though
<fwereade_> rogpeppe, ok, that is not an unreasonable expectation, but let's dig in
<fwereade_> rogpeppe, if we do that
<fwereade_> rogpeppe, we're implicitly denying the need for an upgrade-charm to ever happen, aren't we?
<rogpeppe> fwereade_: i wouldn't mind your "treat every hook as if it might be run after an upgrade" solution *if* there was a way of finding out whether a charm's been upgraded
<fwereade_> rogpeppe, because we're assuming that any hook can be rerun safely after an upgrade *without* an upgrade-charm
<rogpeppe> fwereade_: yeah
<rogpeppe> fwereade_: i'd realised that
<fwereade_> rogpeppe, it would really feel *safer*, I think, to require that upgrade-charm be able to handle running in any state...
<rogpeppe> fwereade_: yes, and then just run it and leave the current error state unaffected
<fwereade_> rogpeppe, but then we guarantee that config-changed will run after upgrade-charm, so we can either relax *that* restriction or raise the spectre of a double-nested error state with a queued config-changed lurkingin there somewhere too
<rogpeppe> fwereade_: ha
<fwereade_> rogpeppe, happy fun times, eh?
<rogpeppe> fwereade_: happy fun times indeed
<rogpeppe> fwereade_: when we have charm status, i'm going to write charms such that their hooks never fail
<fwereade_> rogpeppe, +100 to that
<ericsnow> nate-tablet: FYI, I'll be here sporadically again today (feeling a bit better)
<nate-tablet> ericsnow: ok
<nate-tablet> now I have managed to install lubuntu (which didn't help) and can't get it to go away
 * nate-tablet is a special flower
<wwitzel3> my upgrade went about the same as nate's
<wwitzel3> looked ok, then just progressively degraded everytime i used my laptop, until I had to reinstall
<nate-tablet> luckily I just backed everything up to a USB drive
<nate-tablet> so if worse comes to worse.....
<katco> nate-tablet: borked upgrade from 10.04 .10?
<fwereade_> jw4, yeah, I think all those things are fine for followups
<jw4> fwereade_: okay; I'll add issues to our leankit board and drop the issues here
<fwereade_> jw4, a thought about the notifications, though -- would it be sane to encode the statuses in the notification _ids, and to add unconditional remove-other-possible-notification-kind ops to the transactions that notify?
<jw4> fwereade_: interesting
<fwereade_> jw4, that might be insane or it might be brilliant or it might just be meh, I just want us to think about the possibility space a bit here
<TheMue> rogpeppe: ping
<jw4> fwereade_: yeah I like it.  Requires a little more bookkeeping but seems worth it
<fwereade_> jw4, and saves us the expensive-style watcher
<jw4> fwereade_: and the beauty is there is a logic hole in the expensive watcher that would be addressed by this approach
<TheMue> rogpeppe: could you tell me a bit more about the yaml change so that I change the test?
<rogpeppe> TheMue: pong
 * fwereade_ cheers
<rogpeppe> TheMue: you need to change the tests so that they don't depend on the specific marshaling details of YAML
<rogpeppe> TheMue: have you run the tests yet, with the latest version of yaml.v1 ?
<TheMue> rogpeppe: no, want to start now
<TheMue> rogpeppe: afaik today the tests are based on yaml strings. so it would be better to let them base on types that are marshalled and unmarshalled?
<rogpeppe> TheMue: no, you don't need to do that in general
<rogpeppe> TheMue: i pointed you to a possible solution yesterday
<TheMue> rogpeppe: have to see if I have a log
<fwereade_> jw4, actually, though
<fwereade_> jw4, I am wondering about the nolongeravailable thing
<jw4> fwereade_: as in what kind of error it should be?
<fwereade_> jw4, it feels kinda overspecific -- should we maybe be using NotFound directly there?
<TheMue> rogpeppe: ah, the YAMLEquals checker, found the log ;)
<rogpeppe> TheMue: yeah
<jw4> fwereade_: that sounds plausible
<fwereade_> jw4, it will be all the clearer, I think, when we call it PendingActions
<fwereade_> jw4, agree?
<jw4> fwereade_: +1
<dimitern> sinzui, hey
<dimitern> sinzui, I'll backport the fix for bug 1394524 into 1.21 as well
<mup> Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1394524>
<sinzui> Thank you dimitern
<dimitern> sinzui, hmm looking at how much 1.21 has changed from 1.22 wrt juju/utils/ it might be safer not to backport perhaps?
<sinzui> dimitern, I respect your decision, and I am happy to remove the issue from the milestone if you think it is best
<dimitern> sinzui, juju/utils for 1.21 is more than 10 commits behind master and some interface changes were introduced during some of these
<dimitern> sinzui, yeah, thanks - I think it's safer
<sinzui> okay
<voidspace> dimitern: ping
<voidspace> dimitern: you still around?
<dimitern> voidspace, yep
<natefinch> huzzah
<natefinch> and the answer is... fucked up .profile
<natefinch> no idea why that caused the whole "could not switch monitor configuration" error... but there was a little .xsession-errors file in my home directory that said "your .profile is fubared"
<natefinch> /usr/sbin/lightdm-session: 30: /home/nate/.profile: source: not found
<natefinch> /usr/sbin/lightdm-session: 32: /home/nate/.profile: function: not found
<natefinch> /usr/sbin/lightdm-session: 35: /home/nate/.profile: __git_ps1: not found
<natefinch> /usr/sbin/lightdm-session: 36: /home/nate/.profile: Syntax error: "}" unexpected
<natefinch> this is what I get for copying a shell script into my .profile
<wwitzel3> natefinch: wb :)
<natefinch> ironcically, while this all happened, my mother called me to ask for help getting malware off her laptop
<natefinch> one of those "malware masquerading as anti-malware" things
<jw4> fwereade_, TheMue LGTM on review 502?
<TheMue> fwereade_: just seen your all-watchers-in-one-file-statement in jw4's proposal, laughed loud
<TheMue> jw4: from my side it's ok now as the cards for the missing parts are created. but would like to wait for fwereade_ to check your answers on his review
<fwereade_> jw4, if you've done what I suggested and it LGT TheMue I'm happy
<jw4> fwereade_ TheMue cool tx
<jw4> (yes, I've addressed all comments and issues)
<mattyw> night all
<mgz> cmars: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1368/ plus 1369 plus 1370
 * perrito666 is back to the land of the bad but bearable internet
<voidspace> g'night all
<lazyPower> does anyone have a minute to help debug proxy issues with a users juju env?
<natefinch> lazyPower: you're on the wrong time of day to find people that know about proxies and juju, unfortunately
<lazyPower> i figured as much - but i think its a config issue fortunately
<lazyPower> not something juju isn't respecting
<lazyPower> thanks for the reply natefinch
<natefinch> lazyPower: wish I had a better reply.
<perrito666> wiii, I have an upgrade resistent restore, I am a happy man
<perrito666> :D
<natefinch> yay
<jw4> fwereade_: don't know if the new name I picked is the best, but it's clearer : http://reviews.vapour.ws/r/508/
<perrito666> go fmt not taking a list of paths as parameter makes me sad
<natefinch> you can do go fmt ./...
<natefinch> (or other package wildcards)
<perrito666> natefinch: that I did not know
<natefinch> note, that's go fmt not gofmt
<perrito666> natefinch: http://reviews.vapour.ws/r/298/
<natefinch> perrito666: also, you can give multiple paths to gofmt   gofmt *.go  foo/*.go  seems to work, for example
<natefinch> (note that one is gofmt, not go fmt
<perrito666> natefinch: go fmt, which I prefer does not like multiple paths
<perrito666> well, being blessed as I am with having no power and using internet from a cellphone tethering I think I might call a stop here and return later
<perrito666> wow, reviewboard sucks badly in bad internet situations
<natefinch> not sure if waigani is trolling or actually means it
<perrito666> natefinch: cmon it wont affect you unless you decide to code in an old english typeset
<perrito666> :p
<waigani> natefinch: I put it to the vote, and this was the result. It's a stupid minor point and the best way to avoid ongoing time loss on the issue is to reach a decision and get on with coding.
<natefinch> waigani: isn't the best way to avoid wasting time on it.... to not waste time on it?
<waigani> natefinch: isn't that what we are doing now?
<jw4> natefinch: or to make a decision and not revisit it?
<waigani> +1
<natefinch> waigani: my point is, we're adding something else we have to check for in a code review that offers ZERO benefit to the quality of the code.
<natefinch> or to the quality of the comments
<jw4> natefinch: except that new folks not party to this debate may raise it again unless it's spelled out
<katco> is this about the one-space after periods?
<jw4> katco: yep
<katco> why is this something we're even discussing?
<natefinch> I have never (previously) in my 15 years of development experience had anyone ask about number of spaces after a period.
<waigani> natefinch: sigh. The reason I put it to the vote is because there were debates about it, that were distracting. The solution to such debates is to make a decision and not revisit it (without good reason)
<waigani> that is the role of the style guide I think
<katco> i'm with nate on this... my solution would be to tell the person bringing this up that there are more important things to discuss
<katco> why are we reviewing the # spaces in a comment?
<mgz> katco: because it's fun!
<jw4> katco: except you'd have to say it again everytime someone who didn't know asked
<waigani> OMG
<perrito666> yay bikeshedding
<katco> jw4: i don't know... i've never seen this ever come up either
<natefinch> if we want to end the discussion, state in the style guide that we don't care
<waigani> the intention was to put the issue to bed and move on - that is what I'm doing now. If it does not get a ship it does not land. I'm not fussed.
<jw4> katco: I know, but Go is the first language I've used that has one-true-way of formatting code too
<jw4> katco: for this exact reason I believe
<katco> jw4: yeah, but that's to handle major stylistic differences in actual code
<katco> jw4: this is... a space... b/t sentences
<perrito666> jw4: all languages have one true way of formating code... mine
<katco> jw4: writers can't even agree on this lol
<jw4> katco: :)
<jw4> I for one favour one sentence per line
<katco> natefinch: i really like that stance. "we don't care"
<katco> natefinch: removes the additional review point, and puts the issue to bed as well
<natefinch> we don't even have style guides for things that actually kinda sorta matter, like formatting long lines of function declarations
<jw4> natefinch: I missed that - I'm okay with that stance too
<davecheney> "implementation defined"
<katco> natefinch: +1 +1 +1
<natefinch> we just said "as long as it passes gofmt, it's ok"
<katco> waigani: i'm sorry if i'm causing you some pain. this isn't directed at you at all
<katco> waigani: i was just very surprised to see this
<jw4> katco, natefinch my main support of this is to address it so that newcomers know what the stance  is.  "We don't care" is great if it's in the docs. (IMVHO)
<natefinch> let's make it a tab after a space, that way the spacing is customizable to everyone's own tastes ;)
<natefinch> sorry, tab after a period
<jw4> natefinch: oh no you didn't
<jw4> :)
<natefinch> lol
<perrito666> I have never seen someone dont care so strongly about something
<jw4> perrito666: :)
<katco> tabs are better than spaces, but only if you're using the best editor: emacs
<katco> ^ the most contentious sentence ever written
<jw4> katco: oh no you didn't
<perrito666> even more this seems to be the longest not argument about something I have ever been
<katco> perrito666: i respectfully hear your viewpoint!
<natefinch> for the record, if we have to pick one, I do prefer 2 spaces after a period.  But I'd much rather just let everyone do whatever they want.
<perrito666> oh, no, I feel offended, I demand that you ignore me in the spirit of this conversation amd I will definitely not say that using vim I dont care because I can easily turn one into the other
<jw4> natefinch: I think the ship sailed
<katco> natefinch: i believe in the annals of typography, one space is actually correct
<perrito666> natefinch: 2 spaces? who are you, guttemberg=
<perrito666> ?
<katco> but i guarantee you i'm not going to check for this lol
<perrito666> katco: lets ignore typography in favor of proper language and just read thoroughly the comment as we should
<perrito666> said by the guy that sucks at english <--
<katco> haha
<katco> i've found your english to be quite good perrito666
<katco> better than some americans
<perrito666> katco: heh, most of the reviews I get are people correcting my grammar
<perrito666> also my english is like a health bar in videogames, certain things can make me loose it
<katco> well, you know... go is a unicode language. write in Portuguese :)
<jw4> perrito666: "most of the reviews I get are *from* people correcting my grammar"
<perrito666> katco: my kb lacks a few chars for it I believe
<katco> perrito666: i'm actually afraid of that happening. right now code is wonderfully unified with latin characters
<katco> i read code this japanese guy wrote all the time. in the future, maybe it's written in hirigana
<katco> and that avenue will be closed to me
<perrito666> katco: here, code in spanish is is usually considered bad
<katco> i mean i know it's a bit ethnocentric, but it is nice that anyone anywhere can read any code
<perrito666> katco: no offense intended, we consider English to be a simple, undecorated and sufficiently small language to be practical in technical things
<natefinch> I think it's pretty great that people in other languages can write code that uses their own alphabet.
<natefinch> I do find it quite amusing that the standard time format in Go is in US month/day/year order, though
<katco> perrito666: none taken... wow is that really true?
<katco> perrito666: funny, some people say that same thing about Go :)
<perrito666> katco: well spanish has accents and this -> Ã± and Âº for degrees and many things like the fact that words have gender
<perrito666> which makes a pain to code and comment in it
<katco> i see
<perrito666> and also, you most likely never thought of this because you speak english but programming languages are also in english :p
<katco> natefinch: that is odd
<perrito666> which makes constructions in prog lang+my lang very ugly
<katco> it will be interesting to see what happens as time goes on
<natefinch> katco: rob pike apologized for it, he just wasn't thinking.  The canonical date is 01/02 3:45pm 2006  tz +7
<perrito666> I spent some time reading code in spanish, and the SQL sentences where hilarious
<natefinch> (that's jan 2)
<katco> natefinch: i kind of like how they implemented the parsing stuff, but i wish they would have picked a date that is easier to remember
<katco> natefinch: oh god
<perrito666> Is there any rationale why you ppl use mm/dd/yy?
<katco> natefinch: and as i say that i just now realize it's 1-8
<katco> ^7
<natefinch> yep
<katco> yuk yuk
<katco> good job katherine
<katco> perrito666: i don't know that there is... it's just what i grew up with
<natefinch> I like the idea, but the actual date is hard to remember unless you know the order in which the timestamp parts are put in the canonical string
<katco> i prefer coarse to fine, e.g.: yyyy-mm-dd
<natefinch> katco: absolutely
<jw4> katco: +1
<katco> it's just like numbers... i don't know why we don't do that
<katco> i think that is the ISO standard though isn't it?
<natefinch> there's a lot of ISO standards for time :)
<jw4> katco: I belive so.  I try to always use that format : writing cheques, notes, etc.
<natefinch> a better time format might be 9999 08 07 06:54pm tz +3
<katco> jw4: i admit i use what i grew up with, unless i'm producing documents for the interwebs
<natefinch> for august 7th, 9999
<jw4> katco: I grew up with dd/mm/yyyy and I still have to make a concious choice every time I write a date
<natefinch> I just noticed I can (possibly?) delete waigani's review request on reviewboard.  I guess there's no permissions for that kind of thing?
<jw4> natefinch: what about 9988 07 06 etc.
<natefinch> jw4: don't need it, you only use the amount of resolution in the year as you get, so 99 would be a 2 year date
<katco> natefinch: review by fiat?
<perrito666> ericsnow: ping? alive?
<katco> natefinch: "i DIS-AGREE!" (delete)
<natefinch> katco: I wouldn't, I just thought it was amusing that it was possible :)
<jw4> natefinch: interesting
<natefinch> haha, I AM willing to change the title of the review, though
<alexisb> thumper, ping
<thumper> alexisb: hey
<alexisb> hey there thumper I have a couple of things I need to discuss with you
<alexisb> can you spare me a few minutes
<alexisb> ?
<thumper> yep
<alexisb> ok, let me find a corner
<alexisb> ok thumper our 1x1 hangout
<thumper> ok
<natefinch> sinzui: slight typo in that email subject ;)
<sinzui> yeah, we well need a few years to get to that number :)
<jw4> davecheney: do you have any more details on how you're reproducing bug 1394066 ?
<mup> Bug #1394066: FAIL: action_test.go:254: ActionSuite.TestActionsWatcherEmitsInitialChanges <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1394066>
<katco> if api/* is finding my facade, but not my method in apiserver/*, what have i most likely overlooked?
<wallyworld> thumper: can we delay by 1 hr today? I have a meeting clash
<thumper> wallyworld: sure
<wallyworld> \o/
<thumper> oh fuck...
<thumper> fuckity fuck fuck
 * thumper head desks
<jw4> mooommm; thumper is doing it again
<thumper> ah, no, panic over
<jw4> haha
<thumper> i think we're still good
 * thumper goes back to the 1.22 upgrade malarky
 * fwereade_ driveby: any less than 7 spaces after a period is unacceptable
<jw4> fwereade_: smart alec
<menn0> fwereade_: but surely it's 8.5 if you're using a comic sans font? ;-p
<benji> fwereade_: you mean "fewer"; spaces are countable
<fwereade_> menn0, comic sans users have to use at least 37 as a penance
<menn0> thumper: are all the docstrings in factory.go wrong? they all say, "If more than one params struct is passed to the function, it panics."
 * fwereade_ fails at pedantry forever, tips hat to benji
<benji> :)
<thumper> menn0: yeah
<thumper> menn0: obviously the person that changed the factory failed to update the doc strings
<menn0> thumper: but there's no way to pass in more param structs
<menn0> thumper: is that left over from a previous implementation?
<thumper> yep
<menn0> thumper: k, i'll fix. i'm in there anyway
<thumper> oh god...
 * thumper just had a horrible thought
 * thumper tries to work out if he cares
<thumper> shit shit shit
<thumper> bugger
<thumper> balls
 * thumper pretends the problem doesn't exist
 * jw4 can't help but be intrigued when thumper goes off
<menn0> thumper: that works... sometimes
<jw4> it's like a shiny object or a squirrel to me
<katco> asking again in the hopes someone can help me out: if api/* is finding my facade, but not my method in apiserver/*, what have i most likely overlooked?
<katco> fwereade_: ^ ?
<thumper> katco: is it a new end point?
<katco> thumper: it is
<thumper> then you have probably forgotten to hook up the end point with the root
<katco> thumper: i've been using the usermanager as a guide... can you point me to a line of code maybe?
 * thumper goes to look
<katco> thumper: ty sir. hopefully i am providing a distraction from what sounds like fun problems :)
<menn0> thumper, waigani: here's Factory.MakeEnvironment()  https://github.com/juju/juju/pull/1201
<fwereade_> katco, thumper: if you're seeing the facade but not the method, failing to register seems unlikely, and I don't immediately have good ideas... mm, versioning maybe?
<katco> fwereade_: i registered as 0
 * thumper goes back to his horrible problem
<katco> thumper: haha i'm sorry. ty so much for responding
<katco> fwereade_: 	common.RegisterStandardFacade(
<katco> 		FacadeName,
<katco> 		0,
<katco> 		NewLeadershipServiceFn(leaderMgr),
<katco> 	)
<katco> where FacadeName is "LeadershipService"
<ericsnow> perrito666: you still looking for me?
<katco> fwereade_: the only thing i could think of is i am returning an interface, so maybe the reflection is failing
<katco> fwereade_: so i returned a pointer to the actual type, and that didn't work
<katco> fwereade_: but the type is not exposed
<katco> fwereade_: not sure if that matters
<fwereade_> katco, I don't *think* the type matters so long as the methods are exposed
<katco> fwereade_: they're there on the interface alright
<perrito666> ericsnow: nope, solved it
<perrito666> :D
<katco> fwereade_: i should have mentioned this; i tracked the failure to rpc/rpcreflect/type.go Method(...)
<ericsnow> \o/
<katco> fwereade_: line 180
<waigani> menn0: done
 * fwereade_ scratches head expressively at katco
<fwereade_> katco, hold on a moment
<menn0> waigani: thanks
<fwereade_> katco, I'm unconvinced that we need a new facade for what you're doing -- but then I don't *actually* know *exactly* what you're doing
<fwereade_> katco, oh wait scratch that
<fwereade_> katco, we agreed leadership could & shoudl be handled by a worker that's not the uniter, hence a separate facade
<fwereade_> katco, ignore me
 * katco always prefers to have hard conversations when it's late where fwereade_ is
<katco> ;)
<fwereade_> in vino veritas, or sometimes just nonsense
<thumper> ah ffs
<katco> haha
<thumper> fwereade_: is the translation of that "in wine we find the truth?"
<fwereade_> thumper, yeah :)
<thumper> I agree
<thumper> bit early for wine here
<thumper> being just after noon
<thumper> but I'm tempted
<wallyworld> thumper: if you get a moment, you you please look at https://code.launchpad.net/~wallyworld/golxc/support-cmd-env/+merge/242438
<thumper> wallyworld: kinda deep in it right now
<wallyworld> np
<katco> fwereade_: ahoy... all the functions live in the "discarded" array
<fwereade_> katco, ahhh
<katco> fwereade_: they feel so abandoned :(
<fwereade_> katco, you will have failed to have "appropriate" signatures
<katco> fwereade_: yeah well the troublemakers are always the interesting ones
<katco> fwereade_: how do i know what's appropriate?
<fwereade_> katco, I feel somewhat justified in my ages-ago belief that this would cause someone trouble sometime
<fwereade_> katco, looking, oping I can remember
<katco> fwereade_: i think in rpc/rpcreflect/type.go newMethod(...) there lies a truth
<fwereade_> katco, look at newMethod in rpcreflect/type.go I thinl?
<katco> first!
<fwereade_> katco, jinx
<katco> first again!
 * fwereade_ is evidently outclassed
<katco> ahaha
<katco> fwereade_: i will pursue this. thank you, as always, for your support :)
<fwereade_> katco, cheers :)
<katco> fwereade_: do you mind if when i find out what is wrong i add some helpful error message?
<fwereade_> katco, go for it
<katco> fwereade_: it would appear i do not fit the template for # of return values or some such thing
 * fwereade_ looks at the code he was writing before he started the evening, remembers he decided to change the signature of an abundantly-used method, grumbles quietly to himself
<fwereade_> katco, it's either (result, err) or (err) IIRC
<fwereade_> katco, I think it would have been nicer if it'd been (err) only tbh, at least that would have matched the golang rpc package
 * fwereade_ shrugs, resolves not to whine further
<waigani> menn0: ship it
<katco> fwereade_: gosh... is it because i'm using *params.Error, and not *error?
<fwereade_> katco, ha
<fwereade_> katco, most likley
<katco> fwereade_: so now i am thoroughly confused. i thought i was supposed to use params.Error b/c that's our over-the-wire protocol?
<fwereade_> katco, the params.Errors should probably be in a slice in the result somewhere
<katco> fwereade_: aha
<fwereade_> katco, errors out of the actual methods are OMG-EVERYTHING-IS-BROKEN errors
<katco> fwereade_: right
<katco> fwereade_: thought we were still supposed to use params.Error for some reason
<fwereade_> katco, I *think* that's handled elsewhere -- it's the distinction between a this-element-is-problematic (where we expect you to have created a sane result) and this-whole-call-is-broken where the transport does something about it
 * fwereade_ waves hands vaguely, tries to look wise
<katco> fwereade_: mmm yes, i see, i see. i do not comprehend your brilliance of course, but i think i can fix this.
<thumper> menn0: FWIW the jujud upgrade test starts with a version of 1.16.something and upgrades to current
<thumper> menn0: and makes sure everything passes
<thumper> menn0: so it is testing full upgrades
<thumper> and jumping versions
<menn0> thumper: that sounds good
<menn0> thumper: given that Factory is your baby, can you PTAL at http://reviews.vapour.ws/r/511/? waigani has already given it the ok.
<perrito666> ericsnow: if you have some time, many of your changes just pushed to http://reviews.vapour.ws/r/298
<thumper> menn0: ok
<perrito666> ericsnow: make notes for all you feel needs moving so we do it after this lands
 * thumper bangs and the desk and leaves the office for a bit
<menn0> thumper: before you go
<mgz> bangs hard enough that the desk leaves the office?
<mgz> that's some serious table flip
<menn0> thumper: never mind
#juju-dev 2014-11-21
<thumper> oh FFS...
 * thumper takes the dog for a walk
<davecheney> thumper: i'm coming around to your way of thinking that we should have unit tests in place
<davecheney> to assert if we add extra transitive dependencies
<thumper> :-)
<davecheney> ericsnow: ping, https://github.com/juju/juju/pull/1202
<davecheney> its pretty easy to screw it up
<davecheney> thumper: you said we had some tests in another package I could appropriate ?
<thumper> davecheney: juju/osenv/package_test.go
<davecheney> lucky(~/src/github.com/juju/juju/juju/osenv) %
<davecheney> worst package name, ever
<thumper> heh
<davecheney> who wants to review this cheeky one ? https://github.com/juju/juju/pull/1202
<davecheney> why does jc.Contains not work in a sane way
<davecheney> c.Assert([]string{"a","b","c"}, jc.Contains, "c")
<davecheney> doesn't work
<menn0> davecheney: did you ever figure out the issue with tests leaving behind lots of stuff in tmp?
<menn0> davecheney: my merge run just broke because the disk was full
<davecheney> menn0: yes
<davecheney> i logged the issue
<davecheney> it's very hard to fix
<davecheney> short version
<davecheney> the mongo suite thing that caches mongos between suites
<davecheney> lacks a signal to say "tehre are no more suites, shut yourself down"
<davecheney> so the last suite will finish
<davecheney> the test process will exit
<davecheney> and mongo will die because it's parent died
<axw> davecheney: can we not just run the tests within a script with $TMPDIR set to something temporary, then rm -f $TMPDIR after the test run?
<davecheney> but the merge failing on the bot is a differnt issue
<davecheney> axw: maybe
<davecheney> i haven't looked into fixing the issue
<davecheney> i just cron up
<axw> I think we used to do that with tarmac
<davecheney> rm -rf /tmp/test-mgo*
<axw> fair enough
<davecheney> but that bot is made afresh on each test
<davecheney> it shouldn't fill up
<davecheney> because it is a new machine every time
<axw> ah yeah
<davecheney> the leak is ~43mb per pacakge
<axw> nice
<davecheney> i think it's possible to fix the leak
<davecheney> but we'd have to push gc.Mkdir() right down intot he mongo testing suite
<davecheney> but seriously, why is jc.Contains useless ?
<davecheney> params_test.go:265: c.Assert(imports, gc.Not(jc.Contains), "state")
<davecheney> ... obtained []string = []string{"cert", "constraints", "instance", "juju/arch", "mongo", "network", "replicaset", "rpc", "rpc/rpcreflect", "service/common", "service/upstart", "state/backups", "state/multiwatcher", "storage", "tools", "utils", "utils/ssh", "version"}
<davecheney> ... expected string = "state"
<davecheney> ... Obtained value is not a string and has no .String()
<menn0> davecheney: this could help with mongo suite issue: https://code.google.com/p/go/issues/detail?id=8202
<menn0> letting us run something at the end of the test run
<davecheney> yes, it will be very useful
<davecheney> menn0: but it means 1.4 everywhere
<davecheney> which is basically impossible
<menn0> davecheney: ok. I didn't look into which Go version this was part of.
<jw4> names package update to reflect simpler UUID based Action ID's : PTAL https://github.com/juju/names/pull/32
 * jw4 thought we'd rolled reviewboard out to the names package recently?
<davecheney> menn0: the magic is baked into the test runner that the go tool generates during the build
<davecheney> jw4: is rb watching that repo ?
<davecheney> JYNX!
<jw4> davecheney: I thought I saw ericsnow say something about that
<menn0> davecheney: yep I realise that. just didn't know what version the feature had been added.
<menn0> thumper: this canary environment stuff is working out pretty well. 100's of genuine test failures.
<thumper> I guess that's good
<menn0> thumper: i suspect the number of fixes required will actually be a lot smaller
<davecheney> jw4: change looks ok
<davecheney> i can't lgtm it
<jw4> thanks davecheney
<davecheney> i'm too scared of compatibility issues
<jw4> davecheney: yeah, we're still skating on "no-one is using actions yet"
<davecheney> menn0: canary environment ?
<davecheney> jw4: someone else will have to make that call
<jw4> davecheney: kk
<jw4> fwereade_: ? ^^
<menn0> davecheney: as discussed in standups, it's a fully-featured environment that gets created in ConnSuite.SetupTest designed to screw things up when we forget to filter by env UUID. The data for the canary env gets returned unexpectedly breaking tests.
<menn0> davecheney: undecided if it will just stay there
<menn0> davecheney: but it's useful for finding issues right now.
<davecheney> ok
<davecheney> +1 to destructive testing
<menn0> davecheney, thumper: I'm just checking the performance hit that the canary environment incurs... not good
<menn0> 40-50% on my machine
<menn0> so it might not stay there
<menn0> a more targetted approach might be required
 * thumper nods
 * thumper glares at wallyworld
<wallyworld> wot
<thumper> I shouldn't have been talked into fixing this damn bug
<wallyworld> \o/
<thumper> stabby stabby
<thumper> well, the tests are doing the right thing
<thumper> ...
<thumper> finding bugs in my code
<thumper> ok... I think I have this done now
<thumper> gah...
 * thumper enfixorates some more
<thumper> davecheney: jc.Contains is for string in string
<thumper> davecheney: not item in slice
<thumper> davecheney: which I dearly would have liked to use earlier too
<thumper> davecheney: I think it is poorly named
<thumper> davecheney: you can blame me for that
<davecheney> s'ok
<davecheney> i found an example
<davecheney> test is proposed
<thumper> wallyworld, menn0: http://reviews.vapour.ws/r/498/diff/
<thumper> menno because you looked at it before
<wallyworld> about time
<thumper> wallyworld: because you made me do it
<davecheney> just saw this fail, FAIL: upgrade_test.go:437: UpgradeSuite.TestLoginsDuringUpgrade
 * thumper takes kids into town to get sushi
<menn0> davecheney: can you get the details of the failure to me?
<menn0> thumper-sushirun: looking
<davecheney> menn0: sorry, closed the window
<menn0> davecheney: np. was it on your machine?
<davecheney> yeah
<menn0> davecheney: there's another one in that suite that occasionally fails. I have a ticket for that.
<davecheney> anyone ? http://reviews.vapour.ws/r/512/
<davecheney> i'd like to have the argument about names today
<davecheney> rather than monday
<davecheney> make that monday week
<jw4> davecheney: which names argument?  DB interface?
<axw> wallyworld: I answered my own question about Xen; it's a general thing, not EC2-specific
<axw> so name is stable
<davecheney> yup
<davecheney> of course
<wallyworld> ok
<davecheney> if nobody cares about the name
<davecheney> or nobody has the will to argue
<davecheney> that is also fine
<davecheney> but it is spelt DB with two spaces after it :)
<jw4> davecheney: you had me til the two spaces
<jw4> davecheney: now I'm feeling argumentative
 * davecheney cracks knucles
<jw4> ah; hate to dissapoint you - I was just joking - I like DB
<jw4> ;)
<davecheney> all the good names are taken, several times over
<davecheney> environ, env, db, state
<davecheney> one in every package
<davecheney> at least
<jw4> I know, just like John
<davecheney> jw4: i'd be happy to name the interface John
<jw4> (and Dave for that matter)
<jw4> haha
 * thumper finally submits the branch for master
<menn0> anastasiamac: nice job on sorting out that bug
<anastasiamac> menn0: thnx for finding it :-) it was gr8 fun to fix
 * anastasiamac is kind of a fan of strict accessor/mutator separation.. :-p
<wallyworld> axw: can i offer you a small one? http://reviews.vapour.ws/r/516/
<axw> looking
<axw> wallyworld: lgtm
<wallyworld> tyvm
<mattyw> morning all
<TheMue> morning
<voidspace> morning all
<TheMue> voidspace: o/
<dimitern> morning mattyw, TheMue, voidspace
<TheMue> dimitern: morning
<mattyw> dimitern, TheMue voidspace morning
<TheMue> mattyw: o/
<voidspace> mattyw: o/
<voidspace> dimitern: o/
<mattyw> lots of people waving with their left hands - that's what I like to see
<TheMue> mattyw: \o/
<TheMue> mattyw: also there's no face, so maybe you see them from behind? âºï¸/
<mattyw> TheMue, these are all good points
<TheMue> mattyw: but best and most simple is to interpret it your way ;)
<perrito666> morning
<fwereade_> axw, ping
<fwereade_> axw, I am looking at the charm storage changes
<fwereade_> axw, it seems there is no way to ask where to download a charm from any more
<fwereade_> axw, and so ISTM we have to depend on some funky magic whereby archive urls are always transformed versions of the charm urls in question
<axw> fwereade_: who has no way to ask where to download from?
<axw> the unit agent?
<fwereade_> axw, yeah
 * axw rolls back memory
<fwereade_> axw, shouldn't the state server know where they can be downloaded from, and be able to tell the unit agent, rather than the unit agent inferring same?
<axw> fwereade_: the problem I had with that was that the facades don't know anything about how they should be queried
<fwereade_> axw, sorry, not quite following
<axw> fwereade_: the API server is hosting the charm storage, right? how does it figure out the URL to send to the client?
<fwereade_> axw, how does it figure out the URL to send to the client when new state servers are added? ;p
<axw> fwereade_: the facade doesn't even know which address it should be contacted on - that's all at a higher level
<axw> and the client knows what address it has connected to already
<axw> we could do relative locations?
<fwereade_> axw, I don't see why the facade needs to concern itself with that?
<fwereade_> axw, IIRC what we used to do was ask the state server for the charm's archive URL
<fwereade_> axw, we used to get that from state
<fwereade_> axw, we also get things like lists of state server addresses over the api
<axw> fwereade_: we could get a list of URLs (one for each API server), if that's what you're getting at?
<axw> it seems a little counterproductive, since the API server is clearly up and available if it's responding to a request for URL... :)
<fwereade_> axw, right, but it creates a distributed assumption about exactly where the charm server lives
<fwereade_> axw, it's already moved once
<axw> fair enough
<fwereade_> axw, what long-term guarantees do we have that all state servers will always be charm servers, and will always use serve them on that path?
<axw> fwereade_: it was my understanding that we'd always proxy through the API server
<axw> I see your point though, it would be safer to tell the client
<axw> also means other clients don't need that intelligence/stupidity recoded
<fwereade_> axw, yeah
<axw> I'll log a bug
<fwereade_> axw, cheers -- do you reckon there's half a chance of getting it scheduled soonish?
<axw> fwereade_: I'm happy to take a look early next week, could do with a rest from thinking about block devices
<fwereade_> axw, awesome
<axw> fwereade_: https://bugs.launchpad.net/juju-core/+bug/1394976
<mup> Bug #1394976: api/uniter: Charm.ArchiveURL should query API server <juju-core:Triaged> <https://launchpad.net/bugs/1394976>
<axw> fwereade_: (just out of curiosity) is there really any rush? because it's just the uniter, there's not backwards compatibility issue? I mean, even if we changed the path at which we served the archives, it wouldn't be the end of the world if the uniter threw a few errors before upgrading
<axw> is there another reason I'm missing?
<fwereade_> axw, ehh, I wanted to patch out the api so I could do some proper testing in the uniter and got all angried up when I couldn't find an api call to patch
<axw> fwereade_: fair enough :)
<perrito666> katco: https://twitter.com/ShiroSirius/status/535515056528969728/photo/1
<axw> fwereade_: in the two new workers I just landed for storage, they accept interfaces rather than an api/*.State struct
<fwereade_> axw, there might not be that much rush though, I am strongly tempted to just write the api call I need anyway, definitely ping me before you start work on it ;)
<axw> so I managed to write a worker without any API at all...
<fwereade_> axw, that is awesome
<axw> sure
<fwereade_> axw, the uniter api is sadly a bit more involved and a bit harder to patch out -- *unless* I just write that method, because there are actually only 2 methods I need on it at the moment, and it's only the charm one that's awkward
<perrito666> hey, can I, from juju client, know which of the state servers of an HA setup is the master?
<fwereade_> perrito666, that's awesome
<fwereade_> perrito666, http://imgur.com/uVWFN92
<perrito666> heh seems to be a trend these days the coder barbie thing I just saw the one of emacs vs vim and cracked
<fwereade_> perrito666, yeah, it's *awesome*, I've just spent 10 minutes looking at examples and laughing like a drain
<perrito666> natefinch: ping?
<natefinch> perrito666: sorry, gotta run a quick errand for my wife, mind if we move it later?
<perrito666> np
<perrito666> natefinch: actually I suddenly have to rush run an urgent one too
<wwitzel3> ericsnow, perrito666, natefinch
<natefinch> stupid friggin' chrome on utopic
<natefinch> ahh crud, school thanksgiving party thing.. gotta leave in a few minutes.
<natefinch> ericsnow: if you run out of things to do, look at output variables.  Should be pretty well spec'ed out
<natefinch> ericsnow: I'll try to figure out how to split up GCE work, but not going to have time to do it now
<ericsnow> natefinch: no worries
<perrito666> fwereade_: voidspace I am reviewer next tue but Ill be on holiday, back on fri when you two are reviewers does any of you want to swap with me so we dont have a day with only one rev and I get to do some reviewing?
<voidspace> perrito666: fine with me
<perrito666> deal then :D
<voidspace> perrito666: can you swap them in the calendar
<perrito666> yup, on it
<perrito666> voidspace: I created new events
<perrito666> bc if I change those i seem to change the whole series
<perrito666> which is not good
<voidspace> perrito666: ah, right - thanks
<ericsnow> perrito666: what where those two issues you brought up during standup? (something about filenames and archives)
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: you said to look at the address collection
<dimitern> voidspace, yeah?
<voidspace> dimitern: I've been looking in the state package at the address stuff - that's mostly api server addesses
<voidspace> dimitern: and in machine.go
<voidspace> dimitern: the machine doc stores address info - is that what you meant?
<dimitern> voidspace, it does but it shouldn't :)
<voidspace> dimitern: I've also re-read the container addressability doc - and updated it a bit
<voidspace> dimitern: heh
<voidspace> dimitern: where is the address collection?
<dimitern> voidspace, the idea is to have a separate addresses collection
<voidspace> dimitern: I've tried grepping but failed
<voidspace> dimitern: ah...
<voidspace> dimitern: and have machine doc reference that
<wwitzel3> fwereade_: *poke* need some of your time for the juju-run stuff I addresses
<wwitzel3> addressed
<dimitern> voidspace, which will contain "proofed", verified addresses linked properly to machines, subnets, etc.
<voidspace> dimitern: right
<dimitern> voidspace, ideally we'll drop the addresses from the machine doc at some point
<fwereade_> wwitzel3, oh *hell* sorry
<dimitern> voidspace, even now the addresses there are considered incomplete, plain wrong or unusable
<wwitzel3> fwereade_: no trouble, you told me you'd forget and I would have to poke you today :)
<voidspace> dimitern: hah, wonderful
<dimitern> voidspace, :)
<dimitern> voidspace, we'll fix that as we go
<voidspace> dimitern: will the new address collection just be used for where we're managing addresses (ec2 with default vpc and maas)?
<voidspace> so just for the new stuff
<dimitern> voidspace, if you have a look at the older network model doc (the one with more details like the state docs and fields) there are some pointers what we need
<voidspace> dimitern: cool, thanks
<voidspace> I have that starr3ed
<voidspace> *starred even
<dimitern> voidspace, yeah - it should contain only addresses we know and can match (or manage)
<voidspace> dimitern: "Juju networking model specification"
<dimitern> voidspace, but please keep in mind that doc is a bit obsolete now by the "phase 1" model (i.e. compare the statements/assumptions in the old doc with the similar ones in the new model)
<voidspace> dimitern: sure, I've just read that so its fresh
<dimitern> voidspace, that's the one I think - it should say it's a low level tech spec
<voidspace> dimitern: actually this one says "This document presents a high-level draft specification for discussion and approval."
<dimitern> voidspace, hmm, so not this one, just a sec..
<voidspace> dimitern: https://docs.google.com/a/canonical.com/document/d/1UzJosV7M3hjRaro3ot7iPXFF9jGe2Rym4lJkeO90-Uo/edit#heading=h.a92u8jdqcrto
<voidspace> oops
<voidspace> not that one
<voidspace> https://docs.google.com/a/canonical.com/document/d/11KbAnVWf8GBJYznOEpzqSRxY7Os7FQSL9huIt1hq1Ao/edit#
<voidspace> This one
<dimitern> yeah
<dimitern> no
<dimitern> :)
<voidspace>  so, uhm... which one?
<dimitern> I've sent you a link in a pm
<voidspace> ah!
<fwereade_> wwitzel3, that's only a hair away from a ship-it-with-trivials, just explain why my suggestion for keeping the old form of newRelationIdValue is dumb
<wwitzel3> fwereade_: yeah, so the way f.Var works internally, you must assign the value to the exact same pointer, if you want the flags to stack in the help output, e.g. -r, --relation
<jw4> fwereade_: params.Entites use string for the Tag type instead of names.Tag
<sinzui> Anyone, everyone there is an issue with 1.20.12 :( https://bugs.launchpad.net/juju-core/+bug/1395081 relates to a change in https://launchpad.net/juju-core/+milestone/1.20.12 that we need to identify quickly
<mup> Bug #1395081: 1.20.12 breaks neutron-gateway, since all interfaces are brought up <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1395081>
<jw4> fwereade_: can I make a params.Tags struct that is strongly typed?
<jw4> fwereade_: fwiw, we already have a params.Tags type which we're using elsewhere
<voidspace> happy weekend everyone
<voidspace> g'night all
<dimitern> wwitzel3, natefinch, perrito666, guys, urgent bug fix review - who can have a look? http://reviews.vapour.ws/r/518/
<dimitern> the bug is https://bugs.launchpad.net/juju-core/+bug/1395081
<mup> Bug #1395081: 1.20.12 breaks neutron-gateway, since all interfaces are brought up <cloud-installer> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1395081>
<natefinch> looking
<natefinch> are there side effects to us *not* bringing these up?
<dimitern> natefinch, not really - if anything it was messing up maas environments for is
<perrito666> dimitern: looks a lot like you are reverting or partially reverting a patch, could you add a reference to it in the commit?
<dimitern> natefinch, and it's really *my bad*, because I backported that from trunk, but accidentally changed the behavior between 1.20.11 and 1.20.12
<dimitern> perrito666, it's not a complete revert, it's just dropping some code which was the source of the issue - this code is already gone in more recent versions
<dimitern> perrito666, updated the PR to include a link to the PR that changed that part of the code most recently
<natefinch> cool
<natefinch> dimitern: LGTM'd
<dimitern> natefinch, thanks! and I've just confirmed it with the live test
<bac> marcoceppi: you still going to do an amulet release today?
<marcoceppi> bac: yes
<bac> yay
<fwereade_> jw4, don't tags get sent over the wire as strings anyway?
<fwereade_> jw4, and don't we have to do manual stuff at the other end to turn them back into the right sort of tags anyway?
<mgz> how do I set the log level of root to be debug rather than having that override up to warning that happens now?
<mgz> I am failing to find this documented anywhere
<natefinch> I think thumper is the only one who understands loggo
<mgz> ...someone must have needed to debug juju at some point though,,,
<mgz> I've not done it since that change, and I am currently going insane
<perrito666> how considerate, x crashed
<natefinch> mgz: I think juju set-environment logging-config "root=DEBUG"
<natefinch> mgz: unless someone invalidated juju help logging
<natefinch> which is entirely possible given our history of keeping the help up to date
<mgz> natefinch: ta, seems we also have a logging-config thing to go in environments.yaml as well now?
<natefinch> mgz: I think anything you can set with set-environment can be set in environments.yaml ... not that we actually have either documented anywhere
<katco> if anyone wants to know more about the new leadership/lease services: http://reviews.vapour.ws/r/519/
<natefinch> finally uploaded all my music to google music... I'd forgotten how much I like listening to music while I hack
<jw4> fwereade_: we can discuss - but the short answer is no, it doesn't have to be that way
<fwereade_> jw4, ahh, a TagSlice with a SetJSON or something? nice
<fwereade_> jw4, I guess we'd need an InvalidTag type or something though?
<jw4> fwereade_: what I found with the ActionTags (before I knew we were 'supposed' to convert to string before using) is that the reason they had trouble serializing was because the fields were private
<fwereade_> jw4, ah yes
<jw4> fwereade_: if we accept public fields then they serialize just fine
<fwereade_> jw4, right, but we want them to be actual strings
<fwereade_> jw4, over the wire
<jw4> fwereade_: how come? (They all implement String() fwiw)
<fwereade_> jw4, I have no interest in forcing that sort of structure on every client
<jw4> fwereade_: I see
<fwereade_> jw4, and I want people to be able to do things like use them as map keys
<jw4> fwereade_: you mean in other client languages, or does Go not allow that either?
 * jw4 goes to check
<fwereade_> jw4, in general, but specifically in python I guess
<fwereade_> jw4, seriously, a tag over the API is a string
<fwereade_> jw4, smarter representations in go? awesome
<fwereade_> jw4, subverting the deliberately trivial wire-format representation of an entity? not so much ;)
<jw4> fwereade_: lol
<jw4> fwereade_: okay - so in the params types should we not be using names.Tag or names.*Tag ?
<fwereade_> jw4, yeah
<fwereade_> jw4, and, hmm, you shouldn't be using charm.Actions either, I think
<fwereade_> jw4, params has the same forces in play as internal state stuff does
<fwereade_> jw4, if we use types from other packages, we allow changes to those other packages to magically change our wire format/db format
<jw4> fwereade_: yeah - I remember that discussion
<jw4> fwereade_: good point
 * fwereade_ looks at the rest of apiserver/params and starts swearing
<natefinch> dude, seriously?:  Bootstrap(ctx BootstrapContext, params BootstrapParams) (arch, series string, _ BootstrapFinalizer, _ error)
<jw4> natefinch: what; four return values too much for you?
<natefinch> jw4: you get TWO.  No more.
<jw4> hehe
<jw4> unless it's after a full stop?
<natefinch>  (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»)
<jw4> haha
<jw4> katco: your code is delightful to read
<natefinch> katco: I think he wants something ;)
<katco> haha
<jw4> haha
<katco> jw4: thank you so much... that's probably the highest compliment someone could give me
<jw4> I just appreciate clean well laid out, well named, elegantly flowing code
 * katco beams
<jw4> now, do you think you could help me out with something katco ?
 * jw4 is kidding
<katco> rofl
<jw4> about the last line not the prior two
<katco> i got it ;)
<natefinch> wow... environs.Environ is an interface with 18(!) methods on it.  Sad gopher is sad.
<natefinch> happy weekend all
<jw4> katco: do you want to write the Actions spec?
<katco> jw4: i don't know, i think there are other plans for me
<jw4> katco: I don't know what the emoticon is for tongue-in-cheek, but I couldn't help contrasting Leadership Spec with the Actions Spec
<katco> oh lol
<katco> fwiw i use ":p"
<jw4> katco: that makes sense - I think of that as tongue sticking out, but that's probably more like it
<katco> oh no you're right
<katco> but that's for when i'm feeling cheeky :)
<jw4> hehe
<jw4> :-J
<katco> lol there you go
#juju-dev 2014-11-22
<perrito666> ericsnow: those are pretty good questions, quick answer on client thing, client closes connection after a call and it is not as smart a type as one would hope so I can not just ask for a reconnectoin
<ericsnow> perrito666: yuck then
<perrito666> and quick answer on the issue of the typecasting of client
<perrito666> which is very interesting
<perrito666> I originally did not typecast that
<perrito666> but then I had problems because APIClient is an interface from another package and even though the actual object returned was a Client I was not able to call c.facade.FacadeCall
<perrito666> bc facade is not public
<ericsnow> perrito666: FWIW, I covered the entire patch in a single review this time! ;)
<perrito666> I am adding those as comments because these are very interesting questions you posed
<ericsnow> ah, the facade field (yuck)
<ericsnow> hopefully we can find a way to address both but I'm okay with tabling those as long as you put TODO comments (and you agree they should be fixed, of course)
<perrito666> ericsnow: well if we where to nuke the interface all would be fixed :p
<ericsnow> having a user of the API client pass in a function that outputs a new API client doesn't smell right
<ericsnow> perrito666: we need the interface for testing
<perrito666> ericsnow: we can have the interface be part of the other backups
<perrito666> I dont feel right having a public facade of sorts
<ericsnow> perrito666: I gotta run but I'll probably check back in a little while in case you have more clarifications you want on my review
<perrito666> ericsnow: I am dropping issues but the explanation is in the comment below wihch I did not yet commit
<perrito666> bear with me plz :) I am cooking
<perrito666> ericsnow: lol, review mails get cutted by gmail
<ericsnow> :)
<perrito666> ericsnow: btw, I am explicitly not doing anything at all to help restore work  in local provider, it is a broken provider and we should not be doing things for it to work there, instead, we should fix local provider
<perrito666> there is no practical reason for restore to work on local
<ericsnow> unit tests
<perrito666> and no, the juju script actually stops the db
<perrito666> ericsnow: I can add unit tsts and make things work on those, but I am purposedly not changing things to work in local
<perrito666> to be honest it is VERY dangerous for restore to run on local
<perrito666> ericsnow: btw, I need a bit of your help
<ericsnow> very true
<perrito666> I want to answer one of your comments but I need to rubber duck the answer with you before
<ericsnow> so you know I'm trying to be helpful with the reviews, in case it seems like anything else :)
<perrito666> so, regarding the order of prepare, upload, restore, finish
<ericsnow> yep
<perrito666> sure, that is why I try to answer in a way that the review can be used as a doc later
<perrito666> so, the reason is
<perrito666> lets assume a succesful run
<perrito666> you call prepare, which can be likened to a sqldb begin transaction
<perrito666> then, you upload
<perrito666> then you restore from the uploaded file
<perrito666> so far good?
<perrito666> so, if anyone, after I decided to restore, did juju deploy blah. blah will be lost
<perrito666> so I accept it can fail in the upload
<perrito666> but there is a strong intention to actually destroy that state server
<ericsnow> right
<perrito666> so, given the nature of this process, it is an aceptable trade off to actually freeze any possible action from other users
<perrito666> I prefer to have the user be mad because it gets postponed
<perrito666> to the user be mad because I just deleted his deployed workload
<ericsnow> that's partly why I'm suggesting that Upload not be called within Restore() at all (only in the command)
<perrito666> ericsnow: we are not syncing here
<perrito666> if upload takes 2 hs
<perrito666> and it does not fail
<ericsnow> ah, I think I see what you mean
<perrito666> anything done in those 2 hs will be lost
<perrito666> I do agree it is one of the strangest concepts of restore
<perrito666> It took a lot of discussion with william loking for possible failure points in restore to realize that this could happen
<ericsnow> but if they run restore, why would they expect anything other than what they backed up at some other time  to be restored?
<ericsnow> there's no backup getting created when restore runs
<perrito666> ericsnow: think multi user
<perrito666> A begins a restore, B wants to deploy
<perrito666> A and B do not comunicate well
<perrito666> :p
<ericsnow> I see what you mean, but I'm still not convinced prepare-before-upload is the right choice
<ericsnow> I gotta go pretty soon, but we can pick this up on Monday
<perrito666> ericsnow: Ill be back here on friday
<ericsnow> it may help to get a fresh perspective from someone else too
<ericsnow> dang it
<ericsnow> I'm still mostly sick and now my family is really sick :(
<perrito666> ouch
<jw4> fwereade_: per our discussion earlier -- http://reviews.vapour.ws/r/521/
#juju-dev 2014-11-23
<wallyworld_> thumper: i think we briefly discussed this last week - there seems to be a universal pushback from some reviewers to insist all err returns use Trace(). There's been no clear guidelines as such as far as I recall. I can't see the point  myself in it being mandated, but if that's what we decide, so be it. Did I miss an email where this was communicated?
<thumper> no, not really
<thumper> i don't think it should be compulsory
<thumper> suggested but not mandated
<wallyworld_> me either, it's just some some reviewers are asking for it
<thumper> it doesn't always make sense
<wallyworld_> yep
<wallyworld_> maybe we need guidelines on when it makes sense
<thumper> hmm...
 * thumper is eating
<wallyworld_> leave you to it
#juju-dev 2015-11-16
<axw> thumper: http://reviews.vapour.ws/r/3149/ -- FYI
<axw> thumper: I'd be keen to know if you still get errors with this applied, since I had to really work hard to get the peergrouper to reliably fail
<menn0> thumper: and another easy one: http://reviews.vapour.ws/r/3150/
<thumper> axw: I'll grab it down and try
<thumper> axw: yay, that looks like it fixed it, for me at least
<axw> thumper: sweet
<axw> menn0 thumper: can I retarget https://bugs.launchpad.net/juju-core/+bug/1516144 to a different series? it's blocking master but it's not on the master branch...
<mup> Bug #1516144: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Fix Committed by menno.smits> <https://launchpad.net/bugs/1516144>
<thumper> axw: yeah, it is
<axw> thumper: oh. job says functional-jes
<thumper> axw: menn0 is currently looking at it
<axw> ok then
<thumper> yes it is the master branch, but the JES test
<axw> righto
<axw> sorry
<thumper> menn0 has fixed one of the problems, but CI failed again with an IP address error
<thumper> so... weird
<menn0> thumper: if I repeat what the CI test does with the local provider it all works
<menn0> thumper: trying with joyent now
<thumper> menn0: any joy with joyent?
<menn0> thumper: everything works fine when I do it manually
<menn0> with local provider and joyent
<thumper> FFS
<menn0> i'm going to look over the logs from the test failure again in more detail
<thumper> I'd reply to the curse email, and make sure it is addressed to Curtis and Aaron, cc juju-dev
<thumper> let them know
<menn0> the test is seeing the dummy-source/0 unit in the first hosted environment is in an error state
<menn0> no idea why or how
<thumper> hmm
<menn0> thumper: the test is passing a config.yaml to create-environment
<menn0> I wonder if that is broken somehow
<menn0> I kinda guessed with that
<thumper> hmm..
<thumper> menn0: there is a cursed email to reply to now
<menn0> thumper: thanks, I will
<menn0> thumper: I'm using the actual CI test script now
<mup> Bug #1331151 changed: 'juju destroy-environment' sometimes errors <destroy-environment> <juju-core:Expired> <https://launchpad.net/bugs/1331151>
<davecheney> axw: ping ?
<axw> davecheney: pong
<davecheney> axw: you mentioned you had some fixes for the peergrouper ?
<davecheney> did they land ?
<davecheney> ?
<axw> davecheney: no, master is blocked
<axw> davecheney: fixes here: http://reviews.vapour.ws/r/3149/
<davecheney> axw: crap
<mgz> menn0: is there some trick to getting hosted env... oh, oh dear
<mgz> # TODO(gz): May want to gather logs from hosted env here.
<davecheney> thumper: https://bugs.launchpad.net/juju-core/+bug/1516498
<mup> Bug #1516498: api/unitassigner: data race <juju-core:New> <https://launchpad.net/bugs/1516498>
<mup> Bug #1516498 opened: api/unitassigner: data race <juju-core:New> <https://launchpad.net/bugs/1516498>
<jam> dimitern: ping
<dimitern> jam, hey, sorry I missed our 1:1 :/
<jam> dimitern: np, maybe we can chat after the standup if you have anything you want to go over
<dimitern> jam, sure, ok
<rogpeppe> this PR updates juju-core to the latest charm package version: http://reviews.vapour.ws/r/3152/)
<rogpeppe> reviews appreciated :)
<mup> Bug #1516541 opened: payload/api/private: tests do not pass <juju-core:New> <https://launchpad.net/bugs/1516541>
<mup> Bug #1516541 changed: payload/api/private: tests do not pass <juju-core:New> <https://launchpad.net/bugs/1516541>
<mup> Bug #1516541 opened: payload/api/private: tests do not pass <juju-core:New> <https://launchpad.net/bugs/1516541>
<dimitern> jam, frobware, standup?
<dimitern> frobware, dooferlad, voidspace, please take a look when you have a moment - http://reviews.vapour.ws/r/3153/ - almost straight cherry pick from the 1.25 fix for bug 1483879
<mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider> <sts> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1483879>
<frobware> voidspace, ok to start?
<voidspace> frobware: yep, omw
<dimitern> frankban, hey, do you have any idea when the guibundles branch will land on master?
<frankban> dimitern: it is already landed on master
<frankban> dimitern: because it was merged on the chicago-cubs one
<dimitern> frankban, awesome! so juju deploy bundle.yaml is usable?
<frankban> dimitern: yes
<dimitern> frankban, nice! I'll give it a try now :) it's pity it's not mentioned in juju deploy help
<frankban> dimitern: it should be mentioned actually
<dimitern> frankban, oh, sorry - I missed it - it's there
<frankban> dimitern: cool
<dimitern> sweet! juju deploy bundle.yaml works just fine with spaces constraints
<frankban> dimitern: \o/
 * frankban lunches
<dimitern> frobware, dooferlad, voidspace, I have another review for you to look at when you can - http://reviews.vapour.ws/r/3155/ - fixes spaces-based deployments on ec2 and brings feature parity between master and 1.25
<voidspace> dimitern: is that a straight forward port?
<dimitern> voidspace, yes, no changes needed
<voidspace> dimitern: you don't need a review then if it's already been reviewed
<voidspace> dimitern: but LGTM :-)
<dimitern> voidspace, it still needs a review :) thanks!
<voidspace> dimitern: I don't think we're re-reviewing stuff that is a straight port between branches
<voidspace> dimitern: at least I and other people haven't been :-)
<voidspace> dimitern: and it doesn't seem like a good use of time
<dimitern> voidspace, it still needs a ship it stamp
<voidspace> dimitern: that isn't what we've been doing
<dimitern> voidspace, isn't it?
<voidspace> dimitern: no
<frobware> dooferlad, would dimitern's change have any impact to your CI tests? ^^
<voidspace> dimitern: and people shouldn't "Ship It" *without* reviewing it
<dimitern> voidspace, I agree
<voidspace> dimitern: and re-reviewing it is a waste of everyone's time
<dimitern> voidspace, not if you reviewed it the first time I guess
<voidspace> dimitern: heh, well possibly
<frobware> dimitern, voidspace: cherry-pick backports that have already been reviewed shouldn't need re-reviewing, IMO.
<dimitern> frobware, ok, I don't mind at all to just land it then :)
<voidspace> if they need substantive changes then a re-review is reasonable
<dooferlad> frobware: it shouldn't have any impact on tests.
<frobware> dimitern, my only observation is for the CI tests
<voidspace> dooferlad: how far off getting to the maas test server are you?
<voidspace> dooferlad: I'm going to need it "soon-ish"
<dooferlad> voidspace: I just ran into a KVM not appearing for one of my tests, which may be due to mhy MAAS or may be just flake.
<dooferlad> voidspace: once I have that sorted I will have got the review answered I was looking at and can get on with the test server
<dooferlad> voidspace: so, this afternoon.
<voidspace> dooferlad: ok
<dimitern> frobware, voidspace, thanks for the Ship It! anyway guys :)
<dimitern> frobware, dooferlad, voidspace, yet another for you to review - a really small one this time - http://reviews.vapour.ws/r/3156/ fixes bug 1499426
<mup> Bug #1499426: deploying a service to a space which has no subnets causes the agent to panic <network> <juju-core:In Progress by dimitern> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1499426>
<dimitern> frobware, thanks for the review - I've replied and updated the PR
<mattyw> fwereade, ping?
<fwereade> mattyw, pong
<frobware> dimitern, are you waiting for a review on http://reviews.vapour.ws/r/3153/  I ask because I saw that it was being merged.
<alexisb> thank you wwitzel3 and katco !
<katco> alexisb: yep, we'll get it figured out
<wwitzel3> alexisb: np
<dimitern> frobware, nope that one is for master and it's still blocked
<dimitern> frobware, and since we're not reviewing forward ports, I'll just merge it when possible, if that's ok
<katco> natefinch: standup
<katco> frobware: hey, how close are you to getting a fix for bug 1512371 for 1.25?
<mup> Bug #1512371: Using MAAS 1.9 as provider using DHCP  NIC will prevent juju bootstrap <bug-squad> <maas-provider> <network> <juju-core:In Progress> <juju-core 1.25:In Progress by frobware> <https://launchpad.net/bugs/1512371>
 * dimitern steps out to the store; bbl
<frobware> katco, probably tomorrow
<katco> frobware: kk
<frobware> katco, actively working on it now
<frobware> katco, blocking you?
<katco> frobware: cool, just trying to figure out how much wiggle room we have on another bug :)
<katco> frobware: nope not blocked.
<frobware> katco, in terms of a making a 1.25.x release?
<katco> frobware: yeah
<katco> frobware: e.g. is everyone waiting on us
<katco> rather, i.e.
<frobware> cherylj, you mentioned you had the replica set problem again - still holding true?
<cherylj> frobware: that maas set up was hosed.  I ended up tearing it down and rebuilding it.  Haven't seen the problem since.
<cherylj> frobware: I can't say for sure there wasn't something else going on
<katco> cherylj: hey, can you read my comment at the bottom of bug 1382556 and give guidance?
<mup> Bug #1382556:  "cannot allocate memory" when running "juju run" <cpe-critsit> <run> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.25:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1382556>
<cherylj> katco: sure, taking a look....
<katco> cherylj: ty
<katco> cherylj: this is one of the last blockers for 1.25.1
<cherylj> katco: yeah.  Are you guys in your stand up?  Could I come chat with you guys if you are?
<katco> cherylj: of course: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<lazypower> wwitzel3 katco - ping
<wwitzel3> lazypower: pong
<lazypower> I'm riffing with mbruzek in a hangout, and it appears juju list-payloads isn't available on 1.26-alpha1, is this known/expected behavior?
<katco> lazypower: pong
<katco> lazypower: it is not yet in master
<lazypower> i'm confused as to how its in 1.25 and not 1.26 :P
<mbruzek> How did it get into 1.25 if it is not in master?
<mbruzek> is it hidden by feature flag?
<mbruzek> You gave us a feature then took it away!
<lazypower> ^ yeah, wat
<katco> lazypower: mbruzek: sorry in meeting. we started the feature based on 1.25, 1.26 was blocked by lack of a >= Go 1.3 process
<lazypower> hmm, hokay
<katco> lazypower: it's on the radar. we'll get it landed asap
<mbruzek> OK, sorry to interrupt meeting.
<lazypower> Thanks for the follow up o/
<katco> (we're also on bug squad this iteration)
<mup> Bug #1516668 opened: Switch juju-run to an API model (like actions) rather than SSH. <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1516668>
<mup> Bug #1516669 opened: Memory/goroutine leaks. <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1516669>
<mgz> I replied to menn0's mail about the blocker again, can natefinch or someone take a look?
<mup> Bug #1516676 opened: Use of os/exec in juju is problematic in resource limited environments. <tech-debt> <juju-core:New> <https://launchpad.net/bugs/1516676>
<natefinch> mgz: reading
<natefinch> katco: seems like the jes CI tests are still blocked by code introduced by the unitassigner.  Should I work on that or the juju run bug?  (I presume the blocker, but wanted to confirm)
<katco> natefinch: hm
<katco> natefinch: my inclination is to say the juju run bug since it's blocking the impending 1.25.1 release
<katco> natefinch: we still have some runway on master
<katco> natefinch: plus it looks like menno did a fix-committed?
<natefinch> katco:  menno responded to the CI test failure with some comments, thread title is "Cursed (final): #3310 gitbranch:master:github.com/juju/juju 0bf7c382 (functional-jes)"
<natefinch> katco: basically... he thought it should have been fixed, but the CI test was still having problems
<katco> natefinch: i see. well, i think you should still focus on the 1.25.1 blocker
<katco> natefinch: that's coming out first
<natefinch> katco: yep, that's fine.  That's why I asked :)
<katco> natefinch: yep, ty
<mbruzek> axw: ping?
<voidspace> frobware: change to picking address algorithm landed on 1.25
<voidspace> frobware: change discussed in standup fixed that failing test
<voidspace> frobware: porting to master now
<voidspace> frobware: also I think that the new Subnets implementation is done - but needs tests, which means I need a test harness
<voidspace> frobware: I can switch to ListSpaces whilst I wait for that
<mup> Bug #1516698 opened: Juju never stops trying to contact charm store <juju-core:Triaged> <https://launchpad.net/bugs/1516698>
<natefinch> one wonders if no one thought about what might happen if this was run on an environment of 5000 machines: https://github.com/juju/juju/blob/master/apiserver/client/run.go#L164
<dooferlad> voidspace: *sigh*, that CI stuff took ages. I am not going to get far with gomaasapi before I need to stop (now-ish). Will see if I can take a look after dinner.
<frobware> voidspace, all sounds good
<natefinch> sometimes I think people just randomly decide whether or not to pass around pointers versus values :/
<voidspace> dooferlad: thanks
<voidspace> natefinch: what's your problem with that function using a pointer?
<natefinch> voidspace: it shouldn't be modifying the value, and the value is small enough to be copied easily.
<natefinch> voidspace: making it a pointer makes me wonder if it's going to be modified somewhere.
<voidspace> natefinch: if it's called 5000 times surely using a pointer is *more* efficient
<voidspace> natefinch: and if that's not the issue why does it matter if it's called for 5000 machines as you called out
<voidspace> natefinch: or is that a separate issue?
<cherylj> katco, does the lxd provider use the container/lxc code to still do container provisioning?
<natefinch> voidspace: separate issue... the problem is spawning 5000 goroutines that all do stuff at te same time
<voidspace> natefinch: right, instead of queuing
<voidspace> yeah, that would be much better...
<katco> cherylj: i don't think so. container/lxd
<natefinch> voidspace: and pointer dereference versus some small amount of memory copying is not always an obvious win
<natefinch> voidspace: queueing is what I'm writing right now, since this code is causing OOM issues
<voidspace> not always, just usually
<voidspace> natefinch: right, cool
<natefinch> voidspace: the pointer thing isn't really a problem, just a pet peeve
<voidspace> heh
<voidspace> natefinch: thanks for expanding, interesting stuff
<natefinch> man I love channels and goroutines
<natefinch> bbiab
<katco> natefinch-afk: hey did you get that tech-debt card created?
<natefinch> katco: oops, nope, will do now
<natefinch> katco: done
<katco> natefinch: ty
<thumper> sinzui: what's the status with the CI blocker
<thumper> ?
<thumper> sinzui: menno ran the tests locally yesterday and could not reproduce
<thumper> both with local, joyent, and the CI scripts
<sinzui> mgz: ^ I think you are versed in this topic
<mgz> thumper: I replied to menno's message
 * thumper hasn't got to it yet, still reading
<thumper> go there
<thumper> s/go/got
<mgz> thumper: short version, somehow with trunk the units in the hosted environment are going *through* error, when the machines are not up, rather than pending, but once the machines are up are fine
<thumper> wha?
<thumper> oh...
<thumper> ha
<thumper> I bet this is the unit assignment worker
<thumper> trying to assign them too early
<thumper> and somehow marking them
<mgz> there is some layering thing screwed up
<thumper> natefinch ^^?
<mgz> it thinks they are units for the hosting env... till it gets machines, then it works it out
<natefinch> thumper: reading backlog
<thumper> natefinch: I was just about to look at the unit assignment worker
<thumper> it seems that it is trying to assign the unit twice
<thumper> because the machine isn't up yet
<thumper> http://juju-ci.vapour.ws/job/functional-jes/276/console
<thumper> natefinch: see the status output in there
<thumper> natefinch: after two minutes, the status is taken again, and it looks ok
<thumper> so it obviously settles itself down
<thumper> but putting the unit into an error state is confusing the tests (and users)
<natefinch> thumper: I've seen it error and then settle, but I thought I'd fixed that when I told it only to run the worker on the master state machine
<natefinch> thumper: already assigned does not sound like the error you'd get if you tried to assign it and there was no machine yet
<thumper> no, it sounds like it was assigned, and then attempted to assign it again
<natefinch> right, which would imply some sort of race condition - either multiple people getting notified and trying to assign (like I originally fixed) or maybe two notifications firing off in succession and thus causing two unit assignments to run concurrently.... the latter seems possible
<mgz> natefinch: the other thing with this is this doesn't appear in a state server log anywhere
<mgz> despite being an error that appears in status. this seems very wrong.
<thumper> maor logging plz
<thumper> :)
<natefinch> hmmm... wonder if I went too crazy in removing my debugging logging
<thumper> this might be strange, but does the collection watcher fire when docs are removed?
<thumper> natefinch: I have a feeling it might, but just a stab in the dark at the moment
<thumper> I thought any change to the doc would fire the watcher
<thumper> not just insertions
<thumper> it appears that the assign units collection just has insertions and deletions and no updates
<thumper> is that right?
<natefinch> corret
<natefinch> correct
<thumper> natefinch: how about logging the unit ids that are being assigned
<thumper> I wonder if we'll find a dupe
<natefinch> thumper: yeah.... I swear I was, but again, maybe I just took out too much logging
<mgz> I can rerun with logging turned up more if that would maybe make things clearer
<natefinch> the worker has some tracef calls that you could turn on, but it definitely looks like I took out too many log statements
<natefinch> that'll at least tell you wht unit ids the worker is seeing firing from the watcher, and log the results of the unit assignment attempt
<mgz> natefinch: what do I want... "<main>=DEBUG ?=TRACE"
<natefinch> juju.worker.unitassigner
<mgz> ta
<mgz> natefinch: http://juju-ci.vapour.ws/job/functional-jes/279/console
<perrito666> anyone knows how to ask peergrouper which of the machines is the leader?
<mgz> you'll want the gathered logs when the job completes
<natefinch> mgz: thanks
<natefinch> wow, juju status --format=tabular doesn't show containers?
<mgz> 2015-11-16 21:52:19 TRACE juju.worker.unitassigner unitassigner.go:56 Unit assignment results: ["cannot assign unit \"dummy-source/0\" to machine: cannot assign unit \"dummy-source/0\" to new machine or container: cannot assign unit \"dummy-source/0\" to new machine: unit is already assigned to a machine" <nil>]
<natefinch> lol, this OOM error frmo juju run is a lot harder to repro when we moved to m3.mediums.
<natefinch> mgz: not really useful, given that we already knew that.  I'm working on another bug for bug squad right now, that's blocking 1.25, but I'll try to look at that one once I get this one finished up
<natefinch> mgz: I'll take a look at the logs from the run later tonight and see if anything obvious pops up
<natefinch> gotta run and make dinner for the family
<perrito666> diner, honestly? at 6PM...
<thumper> I'm sorry, but seriously?
<thumper> a critical blocker stopping the entire team has less priority?
<axw> wallyworld: I'm rebasing the azure-arm-provider branch because it's missing fixes from master
<axw> wallyworld: assuming no need to review
<wallyworld> axw: once, just finishing meeting
<wallyworld> axw: sorry, done now, in standup
<axw> oops, is that the time
<thumper> axw: I have never suggested or required a review of merging master into a feature branch
 * thumper off to walk the dog
#juju-dev 2015-11-17
<axw> abentley: don't suppose you're working? CI seems to have died... merge job has been running for 2 hours
<axw> I'll just kill it and hope for the best
 * thumper heading out for a bit, taking daughter to BJJ
<natefinch> google: ps human readable memory
<natefinch> response: <hugeass command>
<natefinch> nobody's put a -h on ps, huh?
<natefinch> nobody's put a -h on ps, huh?
<natefinch> oops wrong window
<natefinch> oops wrong window
<mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
<frobware> dimitern, ping 1:1?
<dimitern> frobware, sorry, omw
<axw> wallyworld: http://reports.vapour.ws/releases/3318  -- azure-arm-provider is blessed. what's the process to merge into master?
<wallyworld> axw: yay. when master unblocked, just create a branch, merge in tip of feature branch, and propose
<axw> wallyworld: cool. no need for review on that I take it?
<wallyworld> axw: judgement call, usually no
<wallyworld> IMHO
<dimitern> voidspace, frobware, jam, fwereade, standup?
<voidspace> dimitern: bugger, bugger, bugger
<voidspace> got distracted by work
<voidspace> sorry
<voidspace> dimitern: frobware: dooferlad:  I guess you've finished
<dooferlad> voidspace: yep
<voidspace> dimitern: frobware: dooferlad: my standup then - I made the changes to add a machine.Principals method for my "address picking algorithm change"
<dimitern> voidspace, :) hey, you didn't miss much
<voidspace> dimitern: frobware: dooferlad: that made tests pass on CI - it's landed on 1.25 but master is still blocked
<dimitern> voidspace, nice! yeah - too bad for master :/ I have 3 PRs blocked as well
<voidspace> I thought I'd finished the implementation of Subnets using the new MAAS API and am waiting on the test harness - will need to sync up with dooferlad for that
<voidspace> so I'd started on the ListSpaces implementation
<dimitern> voidspace, please, call it Spaces()
<voidspace> in the process of that this morning I discovered a flaw in the new Subnets code (wasn't filtering by subnet ID)
<voidspace> dimitern: ok - I thought ListSpaces was your idea
<voidspace> but fine
<dimitern> voidspace, it was an early idea, but since we have Subnets() now, let's keep the consistency in names
<voidspace> and it was fixing the subnet ID filtering that distracted me
<voidspace> done now
<voidspace> dooferlad: have you made a start on the maas test server update?
<dooferlad> voidspace: yes
<dimitern> voidspace, cheers
<dooferlad> voidspace: working on it now. Will ping you when I have something worth sharing
<voidspace> dooferlad: cool, let me know if you have any questions
<voidspace> dooferlad: great!
<voidspace> dooferlad: I'll carry on with Spaces then - can land it as a single branch
<voidspace> dimitern: environ.Spaces() can just return a map of string -> []SubnetInfo - right?
<voidspace> dimitern: and should we do anything with the maas "Default Space" (named like that)
<voidspace> dimitern: we want to make sure our default space is the same as the maas default space
<voidspace> otherwise nothing works
<dimitern> voidspace, I think Spaces() needs to return []network.SpaceInfo
<voidspace> dimitern: ok
<voidspace> dimitern: all SpaceInfo will have is a name and a []SubnetInfo
<dimitern> voidspace, and that in turn should have a Name, ProviderId, Subnets []network.Id
<voidspace> there's no provider id beyond name
<voidspace> dimitern: you want network.Id for subnets rather than SubnetInfo ?
<dimitern> voidspace, I don't think we should care about the "Default space"
<voidspace> dimitern: what do you mean by "not care" - not include it?
<dimitern> voidspace, well, if we require Spaces() to return the full subnets info, wouldn't that be too restrictive on providers?
<dimitern> voidspace, no, include it - we just won't use it for openstack
<voidspace> the only provider we have that can list spaces is maas
<dimitern> voidspace, for now
<voidspace> and I suspect that for any provider we implement spaces for, the only way we'll get a slice of subnet IDs is by getting full subnet info anyway
<dimitern> voidspace, will it be easier to do []SubnetInfo instead?
<dimitern> voidspace, I mean, SpaceInfo with Subnets []SubnetInfo
<voidspace> it would mean throwing away less information away
<voidspace> so marginally less work
<dimitern> voidspace, ok, let's do it so Spaces() return the full subnets info
<voidspace> and include default space
<voidspace> we need to be careful when we populate the model that we don't end up with a "juju default space" and a "maas default space" that are actually the same thing but we treat them differently
<dimitern> voidspace, well, since a juju space name cannot contain a space, "Default space" will be the ProviderId, the juju name will need to be something like "default-space" I guess
<voidspace> dimitern: so I need to transform all maas names into juju compatible ones
<voidspace> dimitern: so ironically the "Provider Id" will be much more human readable than the "Space Name"
<voidspace> dimitern: why do we have that restriction?
<dimitern> voidspace, because of constraints and bindings
<voidspace> ah
<voidspace> fair enough
<dimitern> voidspace, the transformation should be just lowercase it and replace spaces with -
<voidspace> dimitern: sooo... when I fetch the space name from the maas subnet result I need to transform there too
<voidspace> SubnetInfo.SpaceName has to be the juju space name
<dimitern> voidspace, yeah I think so
<voidspace> cool
<voidspace> dimitern: thanks
<voidspace> dimitern: hmmm... that's a one way transform though
<voidspace> dimitern: (i.e. you won't be able to deterministacally go from the SpaceName on a Subnet to the MAAS space)
<voidspace> dimitern: you can list spaces to see that though
<voidspace> which will have both
<voidspace> probably doesn't matter
<dimitern> voidspace, when talking to maas we always need to use the provider id - we should have it once the space is imported
<voidspace> dimitern: sure
<voidspace> dimitern: but if someone sees a SubnetInfo (i.e. output from subnets list) the space name shown there is *not* the maas space name
<dimitern> voidspace, but I don't think we'll need to do juju space name -> maas space provider id anywhere
<voidspace> I'm talking about the user - not us
<dimitern> voidspace, ah, sure - we need to have ProviderSpaceId on SubnetInfo
<dimitern> voidspace, in addition to SpaceName
<voidspace> that means a new facade
<voidspace> as it's a change to the api output
<voidspace> are you *sure* we need that as it's a lot of extra work
<voidspace> (well - a moderate amount)
<dimitern> voidspace, ProviderSpaceId is optional
<voidspace> I say we should be aware of it but not do it for now
<dimitern> voidspace, but good point about the versioning
<voidspace> dimitern: still need a new facade, if someone writes any code depending on that value being present then they need to know which api version to require
<dimitern> voidspace, that's the client subnets facade you're talking about?
<voidspace> dimitern: yep
<voidspace> as it's in 1.25
<dimitern> voidspace, yeah, I think before the release we should bump the version for sure
<voidspace> dimitern: I say we don't need SpaceProviderId on SubnetInfo yet
<dimitern> voidspace, but for the time being let's just keep it in mind (probably add a card for it though, once your change lands)
<voidspace> cool
<voidspace> nobody may actually care in practise, but if they do we can add it
<dimitern> voidspace, we should be serious about api backwards compatibility
<dimitern> voidspace, but given the time frame, it can wait for a while
<voidspace> dimitern: so I think I do need to add SpaceProviderId to SubnetInfo - as it's needed for Spaces
<voidspace> dimitern: however I don't need to add it to the apiserver SubnetResults
<dimitern> voidspace, not yet, yep
<dimitern> voidspace, it can stay within the provider code
<dimitern> voidspace, and for importing at bootstrap we don't need to modify the api facades at all, since we have access to state at that point
<voidspace> dimitern: and access to the provider
<voidspace> dimitern: but we do need the proper provider id, so it will need to be on SubnetInfo (which is what we build the state model from)
<dimitern> voidspace, we do have access to the provider when we have the environ config
<dimitern> voidspace, network.SubnetInfo != params.SubnetInfo btw exactly for that reason
<voidspace> yep, understood
<mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
<mup> Bug #1516975 changed: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
<mup> Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
<mup> Bug #1516977 changed: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
<mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
<mup> Bug #1516975 changed: Incompatible version formats <juju-core:Invalid> <https://launchpad.net/bugs/1516975>
<mup> Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
<mup> Bug #1516989 opened: juju status <service_name> broken <juju-core:New> <https://launchpad.net/bugs/1516989>
<fwereade> straw poll: `type NotifyChan <-chan struct{}`, or `type NotifyChannel <-chan struct{}`
<fwereade> jam, dimitern, frobware, anyone? ^^
<dimitern> frobware, I'd vote for the first one
<dimitern> sorry :) I meant fwereade  ^^
<fwereade> dimitern, cheers
<frobware> dimitern,  fwereade: for me the latter. :)
<frobware> fwereade, speaking it out loud (in my head) I'm talking about a "channel"
<dimitern> frobware, yeah, but the type name is "chan" and it's more common in the go code base to use Chan vs Channel
<fwereade> dammit, now it's even again, if someone wants to tie-break?
<fwereade> I do favour Chan myself but can't really muster up very strong arguments either way
<perrito666> I would vote for the seccond, there is no sense in adding the type to the name of something in a typed language
<dimitern> fwereade, frankly, I don't care that much :) you can count me towards Channel if it helps
<fwereade> Channel it is then, thanks all
<fwereade> and: dimitern, frobware, perrito666: can I trouble any of you for reviews of http://reviews.vapour.ws/r/3143/ and http://reviews.vapour.ws/r/3146/ please?
<fwereade> if I can get LGTMs there I can apply the various fixes for the pipeline to http://reviews.vapour.ws/r/3147/ and land in one fell swoop
<dimitern> fwereade, I'll have a look shortly
<fwereade> 3143 has already been looked at and I *think* just needs an LGTM and/or second opinion on the open issue
<fwereade> 3146 is just a copy-code-and-fix-imports
<fwereade> dimitern, tyvm
<fwereade> frobware, opinion on thumper's comment at http://reviews.vapour.ws/r/3143/diff/3/?file=159341#file159341line96 ?
<fwereade> frobware, am inclined to drop the issue but if anyone can tell me *why* it's bad I will change it
<frobware> fwereade, looking
<frobware> fwereade, plan.Init is actively populated with workers at this stage?
<fwereade> frobware, yeah
<fwereade> frobware, ha! some asshole could change Init once the func's returned
<fwereade> frobware, thanks
<dooferlad> dimitern, frobware, voidspace: https://plus.google.com/hangouts/_/canonical.com/maas-juju-net
<dimitern> dooferlad, omw 2m
<mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
<voidspace> dooferlad: sooo...
<dooferlad> voidspace: yep?
<voidspace> dooferlad: I'll be changing my implementation to call the /node/{id}/ endpoint which now includes subnet information in the output
<voidspace> dooferlad: which the test server may or may not already support - probably not
<dooferlad> no, not yet
<voidspace> dooferlad: so if you could include that in your test server work that would be wonderful :-)
<dooferlad> voidspace: sure
<voidspace> thanks
<natefinch> rofl.... the output for juju run is sorted by machineID... alphabetically... i.e. 1, 10, 11, 12, 2, 3, 4
<mattyw> katco, not merging lxd in master? I'm excited for it to happen though
<mup> Bug #1517076 opened: juju run output is sorted by machine id alphabetically not numerically <juju-core:New> <https://launchpad.net/bugs/1517076>
<dooferlad> voidspace: this is more involved than just subnets because they depend on fabrics and VLANs. Fun :-|
<voidspace> dooferlad: we're not initially going to be using fabrics and vlans though
<voidspace> dooferlad: so even if they *should* appear in json output you can restrict the test server to just stuff that we're using
<voidspace> when we need fabrics and vlans we can add them
<dooferlad> voidspace: hmm, OK
<voidspace> test server support doesn't need to be complete
<dooferlad> voidspace: I will just dump out some sensible defaults
<voidspace> cool
<voidspace> it doesn't look like I'll need to query a subnet's ip addresses by the way
<voidspace> if you haven't done that yet
<voidspace> if you have there's no harm in keeping it
<dooferlad> voidspace: Oh, I haven't got the basics down yet, but ignoring VLANs removes quite a chunk of work.
<voidspace> yay \o/
<dimitern> fwereade, sorry, I just finished a call now and managed to push first of your reviews
<fwereade> dimitern, np, I've been tussling with worker/environ again
<katco> mattyw: we're merging lxd into master. waiting for bless from ci
<fwereade> dimitern, and, thanks for the detailed review: I'm not sure I'll be making any code changes there, but there's no harm in making the comments less stupid
<dimitern> fwereade, and the other one is done - I hope the reviews are useful  :)
<dimitern> fwereade, yep +1
<dimitern> katco, hey, any idea about that blocker bug? didn't we decide to rollback issues like that..
<katco> dimitern: we're going to try and get a fix in before EOD today, if not we'll revert
<mattyw> katco, much excite ;)
<katco> mattyw: :)
<dimitern> katco, ok, thumbs up then :)
<mup> Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
<mup> Bug #1517092 changed: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
<mup> Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
<voidspace> dimitern: frobware: dooferlad: openstack hangout?
<dooferlad> voidspace: we are skipping today I think
<voidspace> dooferlad: no0pe
<voidspace> *nope
<voidspace> dooferlad: we skipped the second one last week
<dooferlad> voidspace: and at this mornings hangout we discussed canceling this one
<dooferlad> voidspace: which I realise you weren't at
<dooferlad> voidspace: so, we should have mentioned that! I guess it should have been canceled in our calendars as well. frobware, dimitern?
<voidspace> dooferlad: dimitern and the open stack guys are here
<voidspace> but it's a low key discussion
<voidspace> dooferlad: probably no harm in you skipping
<natefinch> if we juju add-machine and then juju deploy, shouldn't the deployed unit get placed on the existing clean machine?
<natefinch> i.e. instead of having deploy add another machine
<natefinch> fwereade: ^
<dooferlad> voidspace: https://code.launchpad.net/~dooferlad/gomaasapi/subnets
<dooferlad> voidspace: I can remove most of the VLAN code (untested) and propose a merge now, or you can just use what is there until I have finished up vlans, spaces and subnets. Shouldn't take long now.
<voidspace> dooferlad: I can start using what you've got
<voidspace> dooferlad: I'm "retooling" to use the node api instead of subnets plus addresses for when we're filtering by node id
<voidspace> dooferlad: that's almost done and I have the start of maasEnviron.Spaces() too
<voidspace> dooferlad: so plenty to be getting on with, but I'll need this code "real-soon-now"
<voidspace> dooferlad: if I need it before you're done I'll use your branch until it lands
<dooferlad> voidspace: sounds good. So far I just have basic get/post/put/delete support for subnets. I need to integrate subnets into nodes, add op=?? (if you need that) etc.
<voidspace> I don't need ip_addresses now
<voidspace> I still need unreserved_ranges
<cherylj> sinzui: for the 1.26-alpha2 release notes, should they just be appended to the 1.26.0 release notes doc?
<sinzui> cherylj: yes please
<cherylj> sinzui: thanks!
<fwereade> natefinch, assuming constraints match hardware characteristics, yes
<natefinch> fwereade: was not seeing that happen last night on 1.25
<fwereade> natefinch, I don't think I have the mental bandwidth to do more than say "that sounds like a bug then"
<natefinch> fwereade: no problem, just wanted to confirm that it really should be putting the unit on the existing machine, assuming the machine would otherwise be ok.
<natefinch> (clean, matches constraints, etc)
<marcoceppi> cherylj: we're back to power8
<marcoceppi> it's no longer a proxy issue
<marcoceppi> we're getting a machine-0 log in the next 30 mins
<katco> natefinch: how's bug fix coming?
<natefinch> katco: having some trouble reproing... running CI test s manually now to see if I can see it happen
<katco> natefinch: k, lmk what happens. maybe menn0 did fix it :)
<natefinch> that would be cool :)
<natefinch> mgz: you around?
<natefinch> or abentley?
<abentley> natefinch: Hi.
<natefinch> I'm looking at the jes CI failure on master... but when I try to run it I get provider validation failed: invalid EC2 provider config: environment has no access-key or secret-key
<natefinch> this is when it's trying to do create-environment on top of the controller environment
<natefinch> ...obviously the controller environment was created fine with an access key and secret key
<abentley> natefinch: I could be wrong, but I don't think the controller environment provider config is used to create the hosted environments.
<natefinch> thumper, menn0: is there a trick to getting the jes CI test to run?  It seems to be failing when it tries to create-environment on top of the controller environment, saying it can't find EC2 keys
<thumper> natefinch: you need to give it config for the environment, which includes cloud credentials
<abentley> natefinch: Which jes test do you mean?
<natefinch> thumper: I did... it bootstraps the controller environment just fine, then fails to create the child environment (or whatever we're calling them)
<natefinch> abentley: assess_jes_deploy
<thumper> did you pass the config through to the create environment call?
<natefinch> thumper: I don't know?  I gave the script the CLI args it asked for, and it didn't say I was missing any
<thumper> hosted environments are what we are calling them
<abentley> natefinch: Does environments.yaml contain  access-key and secret-key for the "env" you specified?
<natefinch> abentley: yes. Like I said, it was able to bootstrap the controller environment, so obviously those exist and are correct (also I can bootstrap that environment manually).
<menn0> natefinch: assess_jes_deploy worked for me but I had to hack it a little to do an --upload-tools so it would use juju from my machine
 * menn0 checks what he did
<thumper> natefinch: I'm not sure how the ci script creates the hosted environment
<abentley> natefinch: Not obviously.  Perhaps bootstrap respects environment variables and create-environment does not, for example.
<menn0> abentley, natefinch: I don't have any EC2 related env vars set
<menn0> abentley, natefinch: here's what I did: ./assess_jes_deploy.py menn0-ec2 ~/tmp/workspace/bin/juju ~/tmp/workspace/logs menn0-testing
<menn0> menn0-ec2 is an EC2 env defined in my environments.yaml
<menn0> menn0-testing is the name of an env that the test will create, cloning the settings from menn0-ec2
<menn0> ~/tmp/workspace/bin/juju is the path to the juju binary (jujud etc are next to it in the same directory)
<natefinch> menn0: that's what I did, too
<menn0> ~/tmp/workspace/logs is where I asked for the artifacts to go
<menn0> natefinch: I also modified assess_jes_deploy.py so that the uploadTools arg to boot_context() is True instead of False
<menn0> but I don't think that will cause the problem you're seeing
<menn0> natefinch: maybe check your env for EC2 variables? Maybe there's some set that are causing a problem.
<menn0> natefinch: try "set | grep -e AWS -e EC2"
<natefinch> hmm, so I do have the AWS keys in my environment
<natefinch> maybe that's the problem
<menn0> natefinch: yep, try removing them
<natefinch> or rather, lack of them in the environments.yaml
<menn0> natefinch: that makes even more sense
<menn0> I imagine the AWS keys will need to be in environments.yaml in order for create-environment to work
<natefinch> gah, now it's giving me "failed to create new environment: admin-secret should never be written to the state"  sigh
<thumper> natefinch: I bet the config from environments.yaml is just being copied, try not explicitly setting admin-secret in the environments.yaml
<thumper> actually, create-environment should read the environment vars
<natefinch> thumper: maybe the script is stripping out the env vars?
 * natefinch shrugs
<natefinch> I can try doing it manually when the script is finished (this is a long-ass test)
 * thumper shrugs
<natefinch> ahh, wondrous exceptions
<natefinch> OSError: [Errno 17] File exists: '../logs/machine-0'
<perrito666> tautological errors, next one should be file is file
<natefinch> lol, I think the CI test failed while trying to dump logs
<natefinch> thanks, exceptions!
<thumper> quiet expectations
<natefinch> os.mkdir(machine_dir)
<natefinch> so after 15 minutes of running the test... it fails because the directory it was trying to create... existed.  Sigh
<menn0> natefinch: I wonder if mgz's changes to grab logs for each environment is trying to write all the logs into the same place
<natefinch> hmm could be, though it was trying to create machine-0 ... do we have a machine-0 in the host environment?
<perrito666> yes, that is a very annoying characteristic of CI tests, they assume a pristine env
<mgz> menn0: I did not commit my change yet
<mgz> CI tends to just be unforgiving about expected start state
<menn0> mgz: ah right
<menn0> so it's just that natefinch needs to clear the artifacts directory. there's probably stuff from a previous attempt hanging around.
<mgz> I need to restart for hangouts, brb
<natefinch> thanks, retrying with empty logs dir
<natefinch> um hmm.. weird... cannot run instances: Your quota allows for 0 more running instance(s). You requested at least 1 (InstanceLimitExceeded)
<wallyworld> menn0: do we still need to use st.docID(localid) when creating a doc to insert into a collection, or is the prefixing of the doc id with env-uuid automatic now?
<wallyworld> everything in state still seems to use st.docID()
<menn0> wallyworld: it's not necessary any more
<wallyworld> awedome, ty
<menn0> wallyworld: we can remove all the calls
<menn0> wallyworld: I've got a tech debt card for that
<wallyworld> yay, ok
<natefinch> katco: I'm not going to be able to figure out this bug before dinner. I have time after dinner, but I've just been strugging with CI too much
<menn0> but you know how it is
<katco> natefinch: ok, i'll discuss in the release meeting. can you log where you're at somewhere
<katco> natefinch: that i can look at?
<katco> axw: wallyworld: does the new azure provider use simplestreams?
<wallyworld> katco: no
<wallyworld> it queries the cloud directly
<katco> alexisb: ^^
<wallyworld> to look up images ids
<katco> wallyworld: ty
<wallyworld> katco: i already told alexisb  taht
<natefinch> katco: not a lot to say.  Couldn't repro manually, CI hasn't gotten through the test yet (each attempt is like 20 minutes)
<natefinch> katco: updated the bug: https://bugs.launchpad.net/juju-core/+bug/1516144
<mup> Bug #1516144: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Fix Committed by menno.smits> <https://launchpad.net/bugs/1516144>
<katco> natefinch: ok
<katco> wwitzel3: ericsnow_: any updates on your end?
<menn0> thumper: review pls: http://reviews.vapour.ws/r/3169/
 * thumper looks
<ericsnow_> katco: patch should be done in the next little while (based on Nate's patch + tests)
<katco> ericsnow_: cool. demonstrably addresses memory issue?
<ericsnow_> katco: yes
<perrito666> super, a bit of rain and power starts doing funny stuff
<menn0> thumper: thanks
<sinzui> katco: cherylj : Do you have time to review http://reviews.vapour.ws/r/3170/
<wwitzel3> katco: not yet, I'll be working on it tonight to try and at least get past this stupid series issue.
<katco> wwitzel3: ok
<wwitzel3> katco: my plan was to bug someone who is starting their day to take a look at ti with me
<katco> wwitzel3: not a bad idea. alexis is also going to see if jam or fwereade have any insights
<wwitzel3> katco: yeah, that'd be great. I was going to bug people after Jessa and I have dinner.
<katco> wwitzel3: k sounds good. say hi to natefinch-afk; he'll be working on trying to repo the master blocker tonight :p
<katco> repro rather
<wwitzel3> :)
<alexisb> thumper, wallyworld, ^^^ if someone is around when wwitzel3 is back on it would be nice to have a AUS/NZ timezone person to bounce ideas off of
<wallyworld> sure
#juju-dev 2015-11-18
<mup> Bug #1517258 opened: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:New> <https://launchpad.net/bugs/1517258>
<anastasiamac> waigani: tyvm for review \o/
<anastasiamac> waigani: i'll prefix the PR with WIP and will add api/apiserver logic to it :D
<alexisb> waigani, did you use your new tool for the review?
<anastasiamac> alexisb: waigani: new tool?
<wwitzel3> wallyworld: ping
<wallyworld> hey
<wwitzel3> hey, hangout?
<wallyworld> ok
<wwitzel3> wallyworld: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<mgz> soooo... how do people actually feel about table tests these days?
<mgz> I tried it as more-idiomatic go thing, but I might just be out of date
<davecheney> mgz: i think table driven tests are ace
<mgz> davecheney: do you normally have two different structs for error cases and non-error cases?
<davecheney> depends
<davecheney> i normally add an err error field to the test table
<davecheney> and then you just test that the actual error and the erro int he test table is the same
<davecheney> for most cases it lets me combine success and fail cases
<mgz> hm, issue is I need ErrorMatches
<mgz> as I'm testing an error that includes at the bottom level a url.Parse error string I don't want to assert on the specifics of
<davecheney> do you care what error it is
<davecheney> or just the presence of an error
<mgz> nope.
<davecheney> got, err :=f ()
<davecheney> if t.err != err { // oops }
<davecheney> should do
<mgz> well, I have two error paths, so I care a bot
<mgz> *bit
<mgz> davecheney: exact code in cinder_test.go http://reviews.vapour.ws/r/3170/
<davecheney> mgz: lgtm
<davecheney> that's how id do it with gocheck
<davecheney> who want's to look at the weirdest data race report
<davecheney> http://paste.ubuntu.com/13322899/
<davecheney> func (fakeAssignCaller) BestFacadeVersion(facade string) int { return 1
<davecheney> }
<natefinch> davecheney: derp?
<davecheney> sure, most things are human error
<davecheney> but how can there be a data race on a function that never touches any data ?
<natefinch> it even leaves out the receiver variable...
<davecheney> why does it need the receiver, it alwasy returns 1
<perrito666> davecheney: gocheck?
<davecheney> nope
<perrito666> ok, I am curious now
<davecheney> http://reviews.vapour.ws/r/3174/
<natefinch> some sort of pointer auto-dereference thing?
<davecheney> have a look
<davecheney> natefinch: if I have a *T and I need to call a method that takes a T, how does the compiler do that ?
<perrito666> interesting
<natefinch> davecheney: it dereferences the pointer, which is what I was thinking...
<davecheney> so why does that lead to a data race ?
<davecheney> Read by goroutine 12:
<davecheney>   github.com/juju/juju/api/unitassigner.(*fakeWatchCaller).BestFacadeVersion()
<davecheney>       <autogenerated>:18 +0xa9
<davecheney> Previous write by goroutine 11:
<davecheney>   sync/atomic.CompareAndSwapInt32()
<davecheney>       /home/dfc/go1.4/src/runtime/race_amd64.s:281 +0xc
<davecheney>   sync.(*Mutex).Lock()
<davecheney> i'm going to have to blog this one
<natefinch> it's copying the value
<natefinch> even though we're not even using the value
<natefinch> and so that counts as being "read", and in other other goroutine it's changing that value... so what gets copied depends on the order in which those two things happen.... even though we don't care.
<perrito666> I would have guessed that it was compiled as a function rather than a method when the receiver is not assigned
<natefinch> I definitely would have hoped that the compiler would figure out not to copy the value and therefore not trigger the race detector... however, it seems like it must not be that smart.... or the race detector's not that smart
<natefinch> The interesting thing then is, it seems like you should _always_ use *T for methods that don't need the receiver, to avoid exactly this problem.
<perrito666> natefinch: methods that dont need a receiver are called functions :p
<natefinch> perrito666: except it has to be a method to satisfy an interface
<davecheney> natefinch: bingo
<davecheney> natefinch: an observation in gopl was if you use pointer receivers for some methods, you shuld probably use them for all methods
<davecheney> and vice versa
<natefinch> davecheney: I've read that, and I wasn't sure if I agreed... sometimes value receivers are nice to both point out that the value isn't being modified, as well as enforce that fact.  Sort of immutability-lite ... but certainly with gotchas like this, it certainly is problematic.
<davecheney> natefinch: yeah, i'm still undecided
<davecheney> http://play.golang.org/p/DTDzYu4b3C
<davecheney> here is a very small repro that shows the problem
<davecheney> no mutex
<davecheney> no sync atomic
<wallyworld> wwitzel3: where are the logs etc? i can't see any in /var/log/juju
<natefinch> davecheney: nice simple repro.  Do you know if it's the compiler's fault or the race detector's?
<natefinch> fantasitc... when CI tests fail, they don't bring down all the machines they created :/
<natefinch> someday I'll get a clean run of the CI tests and maybe actually repo  this bug
<mgz> natefinch: this is an issue with the way this fails
<mgz> natefinch: you call `juju destroy-environment` on an env you've just deployed machines for, but have the machines have not yet come up, juju leaks the machines
<natefinch> mgz: even with --force?
<natefinch> I guess --force shouldn't matter....  but still... ouch, damn.
<natefinch> mgz: I think this is a pass?  https://pastebin.canonical.com/144311/
<natefinch> would be nice if it said "PASS" or something at the end, rather than making me guess :/
<mgz> natefinch: yeah, looks okay, `echo $?`
<natefinch> 0
<mgz> that's a pass.
<natefinch> I didn't change anything past menn0's fix
<natefinch> granted, it's on EC2 not joyent, but...
 * natefinch shrugs
<natefinch> works on my machine :/
<mgz> natefinch: you can use the joyent creds from lp:cloud-city
<natefinch> mgz: k, thanks
<menn0> natefinch, mgz: I found it work with the local provider and EC2 as well
<menn0> so it's beginning to look joyent specific which is weird
<natefinch> menn0: probably a timing issue
<natefinch> probably joyent is faster or slower in some specific part of the script
<menn0> natefinch: agreed, that's likely
<mgz> I suspect you just aren't seeing a race, :12 at last deploy, :19 before status is first called in your log
<mgz> probably long enough for EC2 to allocate instance ids for both machines
<natefinch> yep
<mgz> :09 at deploy on CI to :12 before first status
<natefinch> mgz: the default-joyent creds in the environments.yaml in cloud-city?
<natefinch> s/creds/environment
<mgz> natefinch: yup
<natefinch> mgz: btw, I hope you're not actually in the UK at this hour
<mgz> or parallel-joyent and use the exact stream that the test did
<mgz> natefinch: nah, NY
<natefinch> mgz: ahh, good.  Whatcha doing on this side of the pond?
<mgz> sprint, talking about QA across all of CDO products
<natefinch> neat
<mgz> waigani_: updated r/3170 - thoughts welcome
<natefinch> menn0: you said you hacked the script to do an upload tools, care to show me where I'd do that?
<natefinch> or mgz would you know how I could best do that? ^
<mgz> natefinch: you can just append --upload-tools
<mgz> oh wait, jes is still special?
<mgz> --upload-tools doesn't work with jes, or at least didn't at the time the test was written
<natefinch> wait, what, really?
<natefinch> ffs
<natefinch> how the hell do you test if you can't upload tools?
<menn0> mgz: i'm not aware of a limitation with upload-tools and jes
<menn0> but with joyent there is a routing problem
<menn0> new instances often can't get to the state server's internal IP address
<menn0> so they can't download the tools from the state server
<menn0> I ran into that with my testing
<menn0> wallyworld: where do instances get tools from during provisioning? always the state server or maybe directly from streams?
<waigani_> mgz: +1 to how you've got the tests now. LGTM
<mgz> menn0: yeah, we have specialy hackery in CI to work around the fact the provider can't clean up networks
<mgz> menn0: see http://juju-ci.vapour.ws/job/joyent-deploy-jes-trusty-amd64/configure
<mgz> $RELEASE_TOOLS/joyent-curl.bash /cpcjoyentsupport/fwrules | sed -e 's/[\[\{]/\n\0/g;' | grep $JOB_NAME | sed -e 's/.*"id":"\([^"]*\)".*/\1/' | xargs -I{} $RELEASE_TOOLS/joyent-curl.bash /cpcjoyentsupport/fwrules/{} -X DELETE || true
<mgz> waigani_: thanks
<mgz> menn0: I'm failing to remember why --upload-tools didn't work, just remember I disabled it on abentley's say-so
<mgz> natefinch: there's a one-line change you can make in utility.py that will enable --upload-tools again
<mgz> well, and a dedent.
<mup> Bug #1497316 changed: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Expired> <https://launchpad.net/bugs/1497316>
<menn0> mgz: what about changing the call to boot_context() in assess_jes_deploy.py
<menn0> it takes an uploadTools arg
<menn0> (hardcoded to false)
<mgz> ah, pants, yeah, that too
<mup> Bug #1497316 opened: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Expired> <https://launchpad.net/bugs/1497316>
<natefinch> mgz: seems easy enough.  I think I have it, with the additional change to make False args.upload_tools in boot_context
<mup> Bug #1497316 changed: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Expired> <https://launchpad.net/bugs/1497316>
<natefinch> er in the call to boot_context
 * natefinch tries it out
<mgz> okay, http://reviews.vapour.ws/r/3172/ should be good to go
<mup> Bug #1497316 opened: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Expired> <https://launchpad.net/bugs/1497316>
<mup> Bug #1497316 changed: TestUniterSteadyStateUpgrade permission problem <ci> <intermittent-failure> <windows> <juju-core:Expired> <https://launchpad.net/bugs/1497316>
<natefinch> hmm yeah, not working... getting no tools found when doing create-environment.
<wallyworld> menn0: sorry, was out at 1:1. during provisioning we go to state server
<wallyworld> menn0: cloud init is configured to try all the recorded api host addresses to till connections
<menn0> wallyworld: ok thanks
<menn0> mgz, natefinch: so I must have been running into joyent firewall issues then. I frequently saw new instances that couldn't connect to the state server to get tools.
<menn0> natefinch: you might want to make sure you remove the rules as per the CI job
<natefinch> menn0: this is running the CI test...
<menn0> natefinch: yes, but the CI job that runs assess_jes_deploy.py does some stuff before and after it runs too
<natefinch> ahh
<menn0> natefinch: see the job's config in jenkins
<menn0> natefinch: or the long command mgz mentioned earlier
<menn0> natefinch: that's from the CI job
<natefinch> menn0: gross
<menn0> natefinch: it's not exactly beautfiul no
<wwitzel3> wallyworld: if you juju ssh 0 , you'll see all the logs
<wallyworld> oh, that's not the bootstrap machine, doh
<wwitzel3> wallyworld: nope, that is the client machine, in the home directory there is the 1.26-alpah1 client too
<wwitzel3> wallyworld: the client on the path is 1.22
<wallyworld> ok
<mgz> bug 1451104 could just be fixed in the joyent provider, then CI hackery goes away
<mup> Bug #1451104: Joyent machines can fail to fetch tools <ci> <deploy> <joyent-provider> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1451104>
<mgz> bug 1485781 is more specific
<mup> Bug #1485781: Juju is unreliable on Joyent <joyent-provider> <reliability> <repeatability> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1485781>
<natefinch> le sigh
<davecheney> i read that as "joyent is unreliable on joyent"
<davecheney> it had a nice ring to it
<natefinch> no, it's "CI only really works in CI"
<natefinch> there's just like 100 implicit dependencies that need to be perfectly correct to get things to run
<davecheney> works on my cloud(tm)
<wallyworld> wwitzel3: the data being logged does not match what is on streams.canonical.com
<wallyworld> maybe they have squid or something serving stale data
<wwitzel3> wallyworld: but that shouldn't prevent upload-tools working?
<wallyworld> true, i was looking to see why a normal upgrade fials
<natefinch> mgz: what's $JOB_NAME?
<mgz> natefinch: what you're passing as forth arg to assess_jes.py
<mgz> +u
<natefinch> mgz: so the copied environment name?
<mgz> well, ideally something unique, the idea is jobs don't stomp on each other if running at the same time
<wallyworld> wwitzel3: aha
<wallyworld> the tools metadata is fucked
<wallyworld> incorrectly generated
<wallyworld> this has happened before :-(
<wwitzel3> wallyworld: can we use juju-metadata to generate new data?
<wallyworld> no, it needs to be signed
<wallyworld> it's a CPC issue
<wwitzel3> wallyworld: and this is what is impacting even with upload-tools?
<wallyworld> not sure, that's next on the list to look at
<wallyworld> this is a serious, serious issue
<wwitzel3> wallyworld: ah, ok
<mgz> wallyworld: which streams?
<wallyworld> devel, maybe others, haven't checked
<natefinch> still no tools found...
<natefinch> whelp.  It's after midnight and well past bed time.  I guess I won't be fixing this today.
<wallyworld> mgz: all sreams seem affected
<mup> Bug #1482155 changed: lxc restriction on multiple state servers <ha> <lxc> <state-server> <juju-core:Invalid> <https://launchpad.net/bugs/1482155>
<mup> Bug #1482155 opened: lxc restriction on multiple state servers <ha> <lxc> <state-server> <juju-core:Invalid> <https://launchpad.net/bugs/1482155>
<mup> Bug #1482155 changed: lxc restriction on multiple state servers <ha> <lxc> <state-server> <juju-core:Invalid> <https://launchpad.net/bugs/1482155>
<mgz> wallyworld: so... don't think we actually need cpc, probably from a lp:juju-release-tools change, so we're just sitting on their hardware
<wallyworld> ok, so we can maybe fix?
<wallyworld> or rollback
<mgz> yeah, but it's also night in canada
<wallyworld> SOP \o/
<wallyworld> SPOF
<mup> Bug #1517344 opened: state: initially assigned units don't get storage attachments <juju-core:Triaged> <https://launchpad.net/bugs/1517344>
<menn0> everything is awesome
<menn0> everything is awesome when you're part of a team
<dimitern> menn0, :) are you talking about the blocker bug?
<menn0> not specifically
<menn0> just slightly delirious
<menn0> and that song is stuck in my head
<dimitern> menn0, you should get some rest then ;)
<menn0> dimitern: nah... perfect time to write some more code
<menn0> ;-)
<dimitern> menn0, I know the feeling
<menn0> fwereade: review please: http://reviews.vapour.ws/r/3178/
<fwereade> menn0, ack
<fwereade> menn0, and now that's stuck in my head too
<menn0> you're welcome
<menn0> ;-)
<dimitern> voidspace, dooferlad, frobware, guys, please have a look at http://reviews.vapour.ws/r/3167/ when you can
<voidspace> dimitern: looking
<voidspace> dimitern: good to read this code as I don't (yet) the concepts fully
<dimitern> voidspace, cheers - I'm glad to clarify things where needed
<voidspace> dimitern: straightforward so far
<frobware> dimitern, added some comments; also (for standup) why do we replace " " in space names?
<dimitern> frobware, thanks! spaces are not valid in constraints
<frobware> dimitern, so why do we collapse them? if you pass a name with " " isn't that just invalid?
<voidspace> maas space names can have spaces
<voidspace> we'll have to translate between juju space names and maas names
<dimitern> but not juju space names
<dimitern> fwereade, jam, standup?
<mup> Bug #1517391 opened: MachineStorageIdsWatcher severely undertested <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1517391>
<mattyw> anastasiamac, are you still awake?
<mattyw> anastasiamac, I guess you shouldn't be really
<anastasiamac> mattyw: hi o/
<mattyw> anastasiamac, hey hey. I see http://reviews.vapour.ws/r/3171/ is marked WIP - do you still want reviews or should I leave it for now?
<anastasiamac> mattyw: tyvm for asking - plz leave it for now :D
<mattyw> anastasiamac, will do
<anastasiamac> mattyw: \o/
<mattyw> anastasiamac, feel free to ping me or anyone else from emerald squad with reviews for x-model relations
<anastasiamac> mattyw: gr8 idea - will do :)
<mup> Bug #1517428 opened: state depends on multiwatcher and/or params <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1517428>
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: your PR - parseDelimitedValues
<voidspace> dimitern: where does rawValues come from?
<voidspace> dimitern: is that from the original command line invocation?
<voidspace> dimitern: I wonder why we're doing the " " stripping inside the provider
<voidspace> dimitern: we should have already converted from juju space names to maas space names by here
<voidspace> dimitern: so they *might* have valid spaces in them
<dimitern> voidspace, the raw values come from constraints
<voidspace> dimitern: if they're space names then they need converting to maas names
<voidspace> dimitern: and the provider can't do that as it requires access to state
<voidspace> dimitern: and constraints will use juju names
<dimitern> voidspace, I guess I overengineered it a bit - I'll drop the space stripping and that will simplify it - there's no way we get invalid constraints that far into the provisioning process
<voidspace> dimitern: ok
<voidspace> dimitern: maas space names can have spaces in them - so stripping them is wrong
<voidspace> dimitern: I'll add an issue
<dimitern> voidspace, the conversion needs to happen, but not having it now won't block us from possibly doing the demo
<voidspace> dimitern: but the conversion needs to happen in a different place, not in the provider code
<dimitern> voidspace, yeah, that's true
<voidspace> dimitern: the provider code should only be dealing with MAAS names (or ids)
<dimitern> voidspace, I think it will happen in the provisioner
<voidspace> cool
<voidspace> dimitern: frobware: dooferlad: just to mention that I'm off tomorrow, it's in the calendar.
<dimitern> voidspace, have a good one ;)
<voidspace> dimitern: I'm spending the day with my mum, visiting stratford
<voidspace> should be good
<dimitern> after some minor but required CI surgery on the parallel streams job, I'm happy to report we now have a blessed master!!
<dimitern> don't rush all at once to land your stuff :P
<dimitern> voidspace, I've re-queued your PR #3692 for merging as well as all 3 of mine
<mup> Bug #1516144 changed: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Fix Released by menno.smits> <https://launchpad.net/bugs/1516144>
<dimitern> hopefully no conflicts will emerge
<mattyw> dimitern, ping?
<dimitern> mattyw, pong
<mattyw> dimitern, you know maas, are you able to respond to this guy? https://github.com/juju/juju/issues/3627
<dimitern> mattyw, I have no idea why that happens unfortunately :/
<frobware> voidspace, ack
<frobware> dimitern, you left mine out... sniff. :)
<mup> Bug #1517474 opened: provider/ec2: don't artificially limit EBS volumes to xvdf-xvdp <juju-core:Triaged> <https://launchpad.net/bugs/1517474>
<jam> fwereade: ping for planning meeting?
<dimitern> frobware, sorry, should've checked :/
<dimitern> frobware, voidspace, I've updated http://reviews.vapour.ws/r/3167/ - can you have another look and approve it if it looks ok?
<frobware> dimitern, taking a look
<frobware> dimitern, glad we drooped the " " stripping
<dimitern> frobware, yeah, now that I think about it, it was like this because the --networks argument to deploy (where these came from in an earlier PoC) was not well validated and/or rushed to a demo-able state
<mgz> dimitern: I don't suppose you heard anything from wallyworld on the status of upgrade issue? he was concerned our streams were screwed, but I don't see any mailling list updates from him.
<dimitern> mgz, which upgrade issue is that?
<dimitern> frobware, once our PRs land, it's time to rebase maas-spaces onto master
<frobware> dimitern, +1
<dimitern> mgz, was that about upgrade 1.20.x->1.24.4 not working unless with --version 1.24.4 ?
<mgz> I think it was several layers of investigation into rt #85463
<mup> Bug #85463: [apport] evolution-exchange-storage crashed with SIGSEGV in e2k_restriction_unref() <evolution-exchange (Ubuntu):Invalid by desktop-bugs> <https://launchpad.net/bugs/85463>
<mgz> not that mup
<mattyw> katco, woohoow!
<mattyw> katco, I've been denying myself the lxd provider till it lands in master
<voidspace> dimitern: LGTM
<dimitern> voidspace, cheers!
<mup> Bug #1517499 opened: i/o timeout on bundle deployment <juju-core:New> <https://launchpad.net/bugs/1517499>
<natefinch> axw: thanks for fixing that bug with unit assignment.  Can't believe I forgot to remove the docs after successful assignment.  I'm surprised that didn't show up more often in tests.
<frobware> cherylj, having trouble with the bond0 interface and juju-br0 1516891. Will concentrate on landing 1512371 first
<cherylj> frobware: okay, thanks for the update!
<frobware> cherylj, this may be at the root of some problems - https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1337873
<mup> Bug #1337873: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition <cts> <patch> <ifupdown (Ubuntu):Fix Released by dgadomski> <ifupdown
<mup> (Ubuntu Precise):Confirmed> <ifupdown (Ubuntu Trusty):Confirmed> <ifupdown (Ubuntu Vivid):Confirmed> <ifupdown (Debian):New> <https://launchpad.net/bugs/1337873>
<cherylj> frobware: interesting.  It's an old bug, but wasn't addressed until last month?
<frobware> cherylj, I think there's a bit of work to address the bonding bug (for juju-br0)
<cherylj> frobware: do you know if it's just a problem with MAAS 1.9?
<frobware> cherylj, I don't.
<cherylj> just re-read the bug, it looks like the support for bonding is introduced in 1.9
<cherylj> frobware: is there a workaround where users could manually edit /e/n/i?
<frobware> cherylj, let me try. though I am getting distracted... :)
<cherylj> frobware: thanks :)  I'd feel more comfortable moving it to 1.25.2 if we could give people a manual workaround
<natefinch> ericsnow: you around?
<ericsnow> natefinch: briefly
<frobware> cherylj, synthesizing what juju boostrap would do to /e/n/i and rebooting yields no working interfaces. \o/ ... :(
<frobware> cherylj, so, not sure there's even a quick workaround right now.
<cherylj> frobware: yikes!!
<natefinch> ericsnow: I don't think your fix for the OOM error is actually changing the core behavior... you're running the waits in goroutines, but you're starting all the executables in what is effectively a tight loop... since Cmd.Start() just fires off a goroutine
<natefinch> ericsnow: er, maybe not a goroutine per se... but we'll still be starting processes really fast and could easily have 100 fire off in a second
<ericsnow> natefinch: fork doesn't take long
<ericsnow> natefinch: fork+exec I mean
<ericsnow> natefinch: by the time Start completes it should already be exec'ing
<natefinch> ericsnow: I guess I don't know when linux stops "counting" the memory of the fork against juju... or when it decides the fork doesn't really need that much.  You're going to have 100 ssh processes all running at the same time if there are 100 machines to run on.
<ericsnow> natefinch: once it execs
<katco> cherylj: got a sec?
<cherylj> katco: sure, what's up?
<natefinch> ericsnow: so, once Cmd.Start returns, we're no longer being hurt by the memory the fork uses?
<katco> cherylj: can you hop in https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<ericsnow> natefinch: correct
<natefinch> ericsnow: interesting. ok, thanks.
<ericsnow> natefinch: np
<wwitzel3> mgz: what do you mean isolate? I know if I bootstrap with 1.22.8, set the agent-stream to devel, and issue update-juju --version 1.26-alpha1 I get: no matching tools available
<wwitzel3> s/update/upgrade
<mgz> wwitzel3: I mean set agent-metadata-url to a specific different location
<wwitzel3> mgz: sure, what location?
<ericsnow> natefinch: FWIW, I don't think the 100 ssh procs will be a big problem (~50k each)
<mgz> abentley: do you have bandwidth to work with wwitzel3 to look at the upgrade from 1.22.8 to devel streams?
<natefinch> ericsnow: only a problem due to the memory copying thing from fork
<ericsnow> natefinch: yep
<abentley> mgz, wwitzel3: Yes, I can help out.  I was just dealing with a similar issue 1.20.x
<abentley> wwitzel3: hangout?
<wwitzel3> abentley: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
<mup> Bug #1517535 opened: Agent stuck in "allocating" state <juju-core:New> <https://launchpad.net/bugs/1517535>
<natefinch> katco: in case you missed it, I talked with ericsnow and he convinced me that his code actually is doing the right thing... it was just my lack of knowledge of how linux's memory handling works during fork & exec.
<mup> Bug #1517535 changed: Agent stuck in "allocating" state <juju-core:New> <https://launchpad.net/bugs/1517535>
<mup> Bug #1517535 opened: Agent stuck in "allocating" state <juju-core:New> <https://launchpad.net/bugs/1517535>
<katco> natefinch: cool, looking forward to seeing it land
<katco> mattyw: jujubot merged commit de417eb into master 20 seconds ago. it's in master now :) alpha2!
<katco> natefinch: ericsnow: wwitzel3: lxd provider is now in master. good job team :D
<mattyw> katco, natefinch ericsnow wwitzel3 good work folks - just try to stop me using the lxd provider now!
<ericsnow> katco: \o/
<mgz> cherylj: bug 1512399 fix landed on 1.25
<mup> Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <sts> <uosci> <Go OpenStack Exchange:Fix Released by gz> <juju-core:In Progress by gz> <juju-core
<mup> 1.25:In Progress by gz> <https://launchpad.net/bugs/1512399>
<cherylj> yay!  thanks, mgz!
<wwitzel3> abentley: https://bugs.launchpad.net/juju-core/+bug/1507867/comments/23 figured out the reproduction steps
<mup> Bug #1507867: juju upgrade failures <canonical-bootstack> <upgrade-juju> <juju-core:In Progress by wwitzel3> <https://launchpad.net/bugs/1507867>
<wwitzel3> abentley: seems code related, but thought you might be interested
<abentley> wwitzel3: Yes, using --upload-tools breaks future upgrades.  That is a known bug.  sinzui?
<wwitzel3> abentley: yeah, but I thought setting the tools-url manually worked around it?
<abentley> wwitzel3: Yes, I thought so, too.  Interesting.
<abentley> wwitzel3: Can I see the log?
<abentley> wwitzel3: Can you upgrade to a non-devel version like 1.25.0?
<wwitzel3> abentley: nope
<wwitzel3> abentley: the log doesn't have much in it, even at debug
<abentley> wwitzel3: Sometimes the "reading tools with major.minor version 1.22" line is informative.
<wwitzel3> abentley: that line does not exist in the log
<abentley> wwitzel3: for an upgrade, the machine-0 log may also be useful, but you have to read it very damn closely.
<wwitzel3> abentley: I dont see any streams activity, like it isn't trying at all
<mgz> is the lxd-provider documented anywhere at present?
<katco> mgz: in the release notes; no documentation as of yet
<mgz> katco: ta
<alexisb> the idea of having both bundle deploy support and a lxd provider on a devel ppa juju makes me giddy :)
<katco> alexisb: i know right? those 2 features together = love
<abentley> wwitzel3: Here is the machine-0 log of a successful upgrade from 1.22 to master, if it is useful: http://data.vapour.ws/juju-ci/products/version-3327/aws-upgrade-22-trusty-amd64/build-376/machine-0.log.gz
<natefinch> ericsnow: I see you're still posting on the juu-run bug. Do you think you'll have time to get that landed today?  I was going to try to do the work to get it landed, but if you're doing it, I can move on to something else.
<ericsnow> natefinch: I'm trying but quickly running out of time
<ericsnow> natefinch: I'll let you know and hand it off if needed
<stokachu> kadams54: got a PR for you for theblues pacakge
<natefinch> ericsnow: ok. yeah, I had assumed you weren't going to have any time today, so was prepared to do it. Let me know when you know.
<ericsnow> natefinch: k
<ericsnow> natefinch: will be soon
<stokachu> 21
<kadams54> stokachu: Taking a look
<natefinch> fwereade: btw, really like your point about passing an abort channel rather than a timeout value.  way more flexible, and still trivial to use as a timeout.
<fwereade> natefinch, cool, thanks :)
<wwitzel3> abentley: was that after using upload tools?
<abentley> wwitzel3: no, that was our standard test.  http://reports.vapour.ws/releases/3327/job/aws-upgrade-22-trusty-amd64/attempt/376
<wwitzel3> abentley: yeah, the standard test works for me as well
<natefinch> katco: I'm going to go back to bug #1491688 for now, since ericsnow seems to still be working on his bug
<mup> Bug #1491688: all-machine logging stopped, x509: certificate signed by unknown authority <bug-squad> <landscape> <logging> <rsyslog> <sts> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1491688>
<katco> natefinch: oh, ok. sorry, didn't think ericsnow would be around today
<natefinch> katco: me either :)
<ericsnow> katco: leaving in a few minutes
<katco> ericsnow: ok. do you think you'll get this in by EOD?
<ericsnow> katco: was going to hand it off to natefinch soon
<katco> ericsnow: natefinch: is it possible for you two to pair for the remaining time?
<ericsnow> katco: made the mistake of reading fwereade's review comments :)
<katco> natefinch: i don't want you to get whiplash
<natefinch> katco: I gotta pick up my daughter from preschool now, unfortunately
<katco> natefinch: ok
<katco> ericsnow: please send nate an email with all the info he needs for the hand-off. we need this landed by tonight
<natefinch> katco: I'm very familiar with eric's changes and william's comments, though, so I don't think there will be many rpoblems
<katco> natefinch: ok
<ericsnow> natefinch: I'm going to update my branch and then you can take it from there
<natefinch> ericsnow: cool
<ericsnow> natefinch: thansk
<natefinch> katco: I spent a lot of time looking into it before I realized eric was working on it, so I guess that works out :)
<katco> =|
<katco> communication people!
<katco> ericsnow: how dare you not actually be out today
<natefinch> exactly!
<natefinch> ;)
<natefinch> ok, gotta run
<ericsnow> katco, natefinch-afk: okay, I'm out
<katco> ericsnow: gl
<lazypower> o/  allo core devs. Is there ever a reason to use a scope: container qualifier on a relationship outside of subordinate services? I've been noodling this for a while and dont see a use-case for it outside of subordinate relations.
<thumper> davecheney: isn't the reason the structs moved into the multiwatcher was because state depends on multiwatcher...
<thumper> davecheney: could the dependency change the other way around?
<thumper> so state/multiwatcher just depends on state?
<thumper> I'm not sure I'm remembering correctly
<stokachu> kadams54: is there a way to do a globbed like search with theblues library?
<stokachu> using search('nova') only pulls in nova-compute and not nova-cloud-controller etc
<kadams54> stokachu: I don't rightly know. We use ElasticSearch on the backend, so it would be worth trying ES' query string syntax: https://www.elastic.co/guide/en/elasticsearch/reference/1.3/query-dsl-query-string-query.html#query-string-syntax
<stokachu> kadams54: ok thanks
<mup> Bug #1517611 opened: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>
<stokachu> kadams54: find any issues with that PR?
 * thumper sighs
<thumper> I merged the blessed master into my feature branch
<thumper> and I have so many failures with go 1.5
<thumper> why are go 1.5 test runs not voting?
<natefinch> doh
<natefinch> thumper: because they weren't passing :/
<urulama> stokachu: the way to search anything mentioning "nova" is https://api.jujucharms.com/charmstore/v4/search?text=nova&autocomplete=1&limit=100
<thumper> clearly the fix then is to fix them
<thumper> not just ignore them
<natefinch> agreed
<thumper> FFS
<stokachu> urulama: perfect thank you!
<natefinch> the lxd stuff is behind build tags for go 1.3+, (since it requires go 1.3+)  Hopefully you're not seeing problems with that code
<urulama> stokachu: and it's ranked
<stokachu> urulama: yea it looks like it return tursty/precise first
<stokachu> urulama: so can i assume those are the blessed ones at the top each time?
<urulama> stokachu: yes
<stokachu> urulama: perfect much appreciated
<urulama> stokachu: if you want to see just the blessed ones (no user namespace charms) do this https://api.jujucharms.com/charmstore/v4/search?text=nova&autocomplete=1&limit=100&owner=
<stokachu> even better
<kadams54> stokachu: QA checks out. I'm going to merge it.
<stokachu> kadams54: sweet thanks!
<thumper> natefinch: github.com/juju/juju/worker/provisioner, github.com/juju/juju/payload/api/private, github.com/juju/juju/cmd/jujud/agent (messy db cleanup), github.com/juju/juju/cmd/juju/commands, github.com/juju/juju/api/unitassigner , and some fallout that appears to be due to a clash with my current work
<stokachu> urulama: so i noticed some of the results return charms like glance and neutron, is there a way to just search if the 'term' is in the id?
<natefinch> thumper: hmm weird, yeah, none of that is lxd code.  not sure why it would fail for go 1.5
<thumper> natefinch: most likely the runtime changes in 1.5
<thumper> w.r.t. GOMAXPROCS default
<stokachu> kadams54: ew owned by docs?
<thumper> causes more races in tests
<natefinch> thumper: I don't think so. I always run GOMAXPROCS=8
 * thumper shrugs
<thumper> something else then
<natefinch> sumthin
<natefinch> katco: I have no idea how to write a test to show that eric's code uses goroutines in exactly the right way and not in the wrong way :/
<kadams54> stokachu: Yeah, I'll get it straightened out.
<stokachu> urulama: not a big deal if not, i can filter it out
<stokachu> kadams54: :)
<katco> natefinch: let me take a peek at his code again
<katco> natefinch: what function are you trying to test?
<natefinch> katco: the meat of the change is in startSerialWaitParallel
<natefinch> katco: so, before we were effectively doing the whole inside of the loop in a goroutine, and now we're only doing the second half in a goroutine
<katco> natefinch: i think the trouble is because the wait func should be passed into startSerialWaitParallel
<urulama> stokachu: it should be with something like https://api.jujucharms.com/charmstore/v4/search?name=mongodb&limit=100
<katco> natefinch: pull that out, test it separately, and then test that startSerialWaitParallel calls it properly
<urulama> stokachu: however, some names don't return any results, which makes me wonder why :S
<katco> natefinch: i.e. startSerialWaitParallel calls whatever is passed in properly
<natefinch> katco: yeah, that can work.  I already didn't like that wait was getting half its args from closing over them and half not, so that would fix that problem.
<katco> natefinch: isn't the only var it's closing over, "wg"?
<natefinch> katco: 1 is half of three when you assign it to an int ;)
<katco> lol
<natefinch> techically correct is the best kind of correct!
<natefinch> yeah, I though there was something else, but I guess not :)
<katco> does anyone recall seeing a bug open recently around not being able to "upgrade-juju" after using "--upload-tools" ?
<natefinch> ah hah, the cmd too
<natefinch> katco: upload tools is bad juju, so to speak.
<katco> natefinch: so not the point ;p
<natefinch> I'm not really clear on the rules when you use upload-tools vis a vis upgrades
<thumper> davecheney: ping when you are around
<perrito666> I hate replicaset sometimes... and some other too
 * perrito666 bbl bike time
<stokachu> urulama: so would https://api.jujucharms.com/charmstore/v4/search?name=nova&limit=100 return everything with 'nova' in the name?
<urulama> stokachu: it should, but doesn't :S so, stick with the text=nova&owner= for now and filter out the ones you don't need
<stokachu> urulama: ok cool
<urulama> stokachu: i'll give a look why name queries fails
<stokachu> urulama: thanks again :)
<urulama> stokachu: np
<natefinch> god I hate using external tests.  It's like every time I go to write a nice little unit test, someone is actively trying to make it more difficult :/
<natefinch> katco: well, refactored, but now to write the tests: https://github.com/natefinch/juju/commit/5f5e26441bc250c221e8e8b688432db8c5e8beec#diff-813c65409327242bb7df0d66ac593b91R195
<natefinch> katco: gonna require some... tricks, I think.
<katco> =|
<natefinch> just difficult to detect when you're running in a separate goroutine or not
<natefinch> actually,  I think I can do it.
<natefinch> hmm..
<natefinch> ahh, I have it
<natefinch> some creative locks in the start and wait functions can prove that start is always called in order, and wait gets called all at the same time
<mup> Bug #1517632 opened: juju upgrade-juju after upload-tools fails <juju-core:New> <https://launchpad.net/bugs/1517632>
<perrito666> seriously this country.... a bit of summer and people have barbecue parties ever single night... and my desk is next to the windows
<alexisb> thumper, axw, anastasiamac: release call is running over
<thumper> k
<alexisb> be there shortly
<anastasiamac> k :D
#juju-dev 2015-11-19
<huwshimi> Hey, does anyone know if this list of supported series is up to date? https://github.com/juju/charmstore/blob/v5-unstable/internal/series/series.go#L37
<huwshimi> Also any ideas if there is a list of English labels for those series?
<alexisb> wallyworld_, ping
<wallyworld_> hey
<alexisb> sorry was late, I am on the hangout now
<menn0> alexisb: do we have a hangout now?
<alexisb> menn0, yes
<alexisb> I am running late
<alexisb> menn0, I can see you
<alexisb> can you hear me?
<axw> thumper davecheney: FYI, peergroup fix is landed now
<thumper> thanks axw
<thumper> really appreciate it
<axw> np
<thumper> axw: good work on the unit assignment bit too
<davecheney> axw: hotsauce!
<natefinch-afk> axw: yes, thanks for cleaning up my mess :)
<axw> natefinch: heh, np
<thumper> \o/ sped up the tests by 10s by fixing one test
 * thumper wonders what else he broke
<thumper> huh, tests all pass
<thumper> magic
<wwitzel3> wallyworld_: ping
<wallyworld_> hi
<wwitzel3> wallyworld_: katco said you needed some clarification on things? I'm around poking this bug with a stick
<wallyworld_> i'm bootstrapping a 1.22 env to debug with
<wallyworld_> i don't really need clarification
<wallyworld_> just need to reproduce locally so i don't mess their environment
<wwitzel3> wallyworld_: ahh ok, I can reproduce the issue even with 1.25.0 .. if you upload-tools, it hoses up the ability to upgrade
<wallyworld_> even when we find and fix that, there are still on 1.22 without the fix :-(
<wallyworld_> it will be an agent related issue
<wwitzel3> wallyworld_: yeah, my hope was that since it is in all versions, the problem code would be the same
<wwitzel3> wallyworld_: also my main goal was trying to see if a new version didn't have the problem, so I could do a git bisect to isolate the problem
<wallyworld_> the other issue of course is the conn disconnect preventing upload tools from working
<thumper> davecheney: http://reviews.vapour.ws/r/3182/
<thumper> davecheney: this has the code I wanted to talk to you about in it
<wallyworld_> wwitzel3: when you say 1.25, you mean a 1.25 back end?
<wwitzel3> wallyworld_: yes, I bootstrapped 1.25.0 using upload-tools and then attempted to upgrade and got the same failure
<wwitzel3> wallyworld_: no tools found OR connection shut down, depending on if I used upload-tools or not
<wallyworld_> wwitzel3: and if you bootstrap without upload-tools but attemt to upgrade with upload-tools?
<wwitzel3> works
<wallyworld_> so the upload-tools on bootstrap is the issue?
<wwitzel3> wallyworld_: maybe, I didn't test upgrading after using upload-tools to upgrade
<wwitzel3> wallyworld_: I can try that really quick though
<wallyworld_> ok
<wwitzel3> I can go 1.22 to 1.25 with upload-tools and then try to go to 1.26
<wallyworld_> so just to be clear, you think bootstrap WITHOUT upload-tools is ok
<wallyworld_> but with uploa-tools on bootstrap is not
<wwitzel3> yes, if I bootstrap without upload-tools I can perform an upgrade to 1.26 if I set the agent-stream to devel
<wallyworld_> wwitzel3: so with upload-tools, you could try clearing ALL the tools metadata as we did yesterday
<wwitzel3> if I use upload-tools, upgrades fails, even if using upload-tools again
<wwitzel3> wallyworld_: yep, I did that
<wallyworld_> and it still fails?
<wallyworld_> now that makes no sense what so ever
<wwitzel3> oh you mean even the metadata put there from the upload-tools?
<wwitzel3> not jsut the streams data
<wallyworld_> yes
<wallyworld_> delete * from toolsmetadata collection
<wwitzel3> wallyworld_: ok, let me try that, bootstrapping 1.22.8 right now (no upload-tools)
<wwitzel3> wallyworld_: then I will upgrade to 1.25 with upload-tools, see if that puts it in the broken state
<wwitzel3> wallyworld_: then I'll db.toolsMetadata.remove() and see if I can upgrade to 1.26
<wallyworld_> ok
<davecheney> thumper: me looks
<thumper> davecheney: cheers
<thumper> davecheney: the piece I was talking about this morning is the race condition in the api opening / timeout handling
<thumper> if we hit the timeout, I close a channel
<thumper> the other go routine does check this channel once the open api func returns
<thumper> there is a race condition if the api is returned and the channel checked just before a different goroutine determines that we have timed out
<thumper> so noone reads off the api or error return channels
<thumper> however I figure what I added is better than the guaranteed block forever of the opening goroutine
<thumper> if it did timeout
<thumper> davecheney: I suppose we could fix that by making the apireturn and error return buffered channels of length one?
<thumper> maybe
<thumper> if we did that, perhaps we could get rid of the timeout channel?
<thumper> however...
<thumper> if we did that, the api wouldn't be closed on timeout
<thumper> bah humbug
<davecheney> thumper: i don't like what i see
<davecheney> do you want me to rip it to shreads in review
<davecheney> or should we have a hangout to discuss the design
<natefinch> davecheney: shit, we have the second option?  Someone should have told me two years ago :)
<davecheney> :D
<davecheney> thumper gets special treatment
<thumper> davecheney: hmm
<thumper> davecheney: hangout probably best
<thumper> davecheney: read the review, happy to explain... but given we are trying to pass information through several layers, this is the best approach I could come up with
<davecheney> thumper: 1:1 hangout ?
<thumper> davecheney: sure
<wallyworld> wwitzel3: i'vr narrowed it down to the final upload tools step after the tools are built, need to dig into that a bit more. plus i've also got new logging showing juju is missing tools from simplestreams after all
<natefinch> gah, testing that things run in goroutines is a PITA
<mgz> wallyworld: have you worked out the path where juju is getting correct tools when simplestreams isn't working as expected?
<wallyworld> mgz: not yet. the logging i added doesn't dump the raw metadata as i did previously, i added extra logging at the point where the tools list is actually composed and returned to the caller. there's something really weird going on
<davecheney> thumper: http://play.golang.org/p/7HqKts_Di1
<wallyworld> wwitzel3: so i think i found the reason for the no matching error on upgrade, need to double check my logic
<axw> cherylj: that peergroup bug is fixed now, I just forgot to tick it over
<axw> done now
<axw> and retargeted back to 1.26-alpha2
<menn0> thumper: upgrader working in the dep engine: http://reviews.vapour.ws/r/3185/diff/
 * thumper looks
<thumper> davecheney: I'm off now to walk the dog
<thumper> davecheney: review updated following review and chat
<davecheney> TheMue: ta
<davecheney> thumper ta
<natefinch> holy crap, 150 lines of test code runs perfectly the first time it successfully compiles.
<natefinch> (lol.... all that to test a 23 line function)
<mup> Bug #1517743 opened: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>
<mup> Bug #1517744 opened: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>
<mup> Bug #1517743 changed: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>
<mup> Bug #1517744 changed: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>
<mup> Bug #1517743 opened: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>
<mup> Bug #1517744 opened: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>
<mup> Bug #1517747 opened: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>
<mup> Bug #1517748 opened: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>
<mup> Bug #1517747 changed: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>
<mup> Bug #1517748 changed: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>
<mup> Bug #1517747 opened: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>
<mup> Bug #1517748 opened: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>
<axw> wallyworld: proposed apiserver/remoterelations, containing just the local watchers for now: https://github.com/juju/juju/pull/3779
<dimitern> morning
<anastasiamac> dimitern: o/
<dimitern> anastasiamac, o/
<anastasiamac> dimitern: how is sophia? do u have snow? :D
<dimitern> there's nothing like an unblocked master in the morning :)
<dimitern> anastasiamac, oh not nearly - it's a lat autumn still 10-18 deg.
<anastasiamac> :D
<wallyworld> axw: awesome, thanks will look soon
<mup> Bug #1302498 changed: Ensure network names are validated on deploy/add-machine once possible <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1302498>
<dimitern> frobware, jam, fwereade, standup?
<frobware> dimitern, dooferlad: the answer is "yes" to does an ordinary deploy with network aliases pause with 'Waiting 120 seconds for network devices'", so not a result of butchering /e/n/i
<dooferlad> frobware: fun!
<frobware> dooferlad, it does success though
<frobware> succeed
<dimitern> frobware, well, that's kinda good news
<dimitern> fwereade, hey, I've realized bindings should be updated on svc.SetCharm(), possibly allowing you to do upgrade-charm --bind like with deploy
<fwereade> dimitern, good point, yes they should
<dimitern> fwereade, initially, we could just use default bindings for new endpoints, and not implement --bind for upgrade-charm
<dimitern> fwereade, but the bindings definitely need updating as part of changeCharmOps
<fwereade> dimitern, yeah, I think that's the bulk of the cost/complexity
<fwereade> dimitern, once that's in, which I think it must be, the extra cost of exposing it via upgrade-charm is minimal
<dimitern> fwereade, exactly
<fwereade> dimitern, and is likely to actually be helpful in terms of showing us where concept boundaries truly lie
<fwereade> dimitern, the more sane clients you have, the more likely your abstraction is sane
<dimitern> fwereade, yeah
<dimitern> fwereade, cheers
<dimitern> fwereade, in order to assert bindings haven't changed while updating them I think I need to use txn-revno explicitly as a field, right?
<fwereade> dimitern, hm, quite possibly, yeah
<fwereade> dimitern, as long as it's a small doc only used for that purpose it's fine
<dimitern> fwereade, ok, so it's very much like for settings, but slightly simpler since the values are strings, not interface{}
<fwereade> dimitern, cool
<dooferlad> dimitern, frobware: PTAL https://code.launchpad.net/~dooferlad/gomaasapi/subnets/+merge/277977
<dimitern> dooferlad, looking
<mup> Bug #1517863 opened: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>
<mup> Bug #1517863 changed: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>
<mup> Bug #1517863 opened: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>
<dimitern> dooferlad, reviewed, let me know what you think..
<mup> Bug #1517863 changed: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>
<mup> Bug #1517863 opened: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>
<mup> Bug #1517863 changed: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>
<tvansteenburgh> jw4: you around?
 * tvansteenburgh shamelessly cross-posts:
<tvansteenburgh> anyone know how to get the ID of the currently executing juju action from inside the action itself?
<tvansteenburgh> i've seen other code using JUJU_ACTION_ID, but it's not set, and I don't see any mention of that env var in the docs
<tvansteenburgh> ah, it's JUJU_ACTION_UUID
<kadams54> stokachu: Just submitted a PR to your theblues branch. Once that's landed, it should fix the doc errors that are currently preventing your PR from landing.
<stokachu> kadams54: nice!
<stokachu> kadams54: i have a initial debian package built would you like me to create a pr for that or just maintain it out of tree?
<katco> ericsnow-afk: you going to be here today?
<ericsnow-afk> katco: coming
<stokachu> kadams54: ok merged that PR
<jw4> tvansteenburgh: glad you found it :)
<mup> Bug #1440209 changed: juju action do doesn't accept non-string params on command line <actions> <juju-core:Fix Released> <https://launchpad.net/bugs/1440209>
<frobware> cherylj, I think this (https://bugs.launchpad.net/juju-core/+bug/1516036) should go into 1.25.1 too. Thoughts?
<mup> Bug #1516036: provider/maas: test failure because of test isolation failure <juju-core:Fix Committed by frobware> <https://launchpad.net/bugs/1516036>
<cherylj> frobware: yes, if it's a problem on 1.25 and you can get that in, that would be good.
<frobware> cherylj, it depends to be a problem for devs - if your DNS doesn't use something like 8.8.8.8, or whatever CI uses, then the unit tests can fail.
<cherylj> frobware: things that prevent us from getting good test / CI runs are definitely good to have everywhere.
<cherylj> frobware: but if you can't get it done today, it can wait to 1.25.2
<cherylj> frobware: actually
<cherylj> frobware: would you be up for looking at a different bug?
<frobware> cherylj, need to land the MAAS/19 DHCP first.
<frobware> cherylj, but sure
<cherylj> frobware: ok :)  just ping me if you still feel that way after you land the MAAS 1.9 / DHCP fix :)
<frobware> cherylj, what's the LP#
<frobware> cherylj, curiosity killed the cat!
<cherylj> indeed!
<cherylj> There are two causing problems for 1.25 CI:  bug 1514462
<mup> Bug #1514462: Assertion failure in TestAPI2ResultError <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1514462>
<cherylj> and bug 1517611
<mup> Bug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>
<frobware> cherylj, Xenial - ha... just to add to the matrix
<mgz> frobware: the important bit is less xenial and more go 1.5
<frobware> ENOMOREMATRIX
<frobware> dimitern, dooferlad: please take a look http://reviews.vapour.ws/r/3188/
<dimitern> frobware, looking
<stokachu> kadams54: just setup a seperate repo for the debian package i did https://github.com/battlemidget/theblues-deb
<kadams54> stokachu: thanks for the heads upâ¦ I'm kinda surprised we don't already have one :-)
<frobware> dimitern, thanks
<mgz> frobware: I still don't understand your change for bug 1516036
<mup> Bug #1516036: provider/maas: test failure because of test isolation failure <juju-core:Fix Committed by frobware> <https://launchpad.net/bugs/1516036>
<mgz> the tests actually query a real dns server, so the solution is changing the value that escapes testing to fail more, rather than correctly isolating the tests from the runner's dns setup?
<alexisb> mgz, cherylj are we sure that those two bugs are what is causing the 1.25 curse?
<mgz> alexisb: bug 1517611 is causing the 1.25 curse
<mup> Bug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>
<mgz> alexisb: bug 1514462 is the main cause of failure for master on go 1.5
<mup> Bug #1514462: Assertion failure in TestAPI2ResultError <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1514462>
<alexisb> mgz, bug 1517611 is marked incomplete?
<mup> Bug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>
<mgz> alexisb: it's the "not on trunk, just 1.25" marker
<frobware> mgz, I don't know what to do about it atm. the real issue is on the MAAS side - we're trying to workaround a sporadic bug there,
<alexisb> ok
<mgz> frobware: what's the maas bug number? I can hit roaksoax in person.
<frobware> mgz, https://bugs.launchpad.net/juju-core/+bug/1412621
<mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Fix Committed by frobware> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1412621>
<dooferlad> frobware: reviewed
<ericsnow> mgz: why not just delete the bug task for master?
<alexisb> frobware, that is a juju core bug
<ericsnow> mgz: (the minus sign in the "Affects" column)
<dimitern> frobware, reviewed
<mgz> ericsnow: we don't know it'as not on master, we've just not seen it
<mgz> also, it confuses search
<ericsnow> mgz: ah
<ericsnow> mgz: k
<mgz> frobware: I'm not seeing a maas bug referenced, just that it's a generic error we see when maas dhcp gets screwed, which can be a variety of reasons
<mgz> frobware: roaksoax says that once juju has touched /e/n/i it's our problem, basically
<mgz> frobware: I also don't see how that's related to our unit tests really touching dns
<frobware> mgz: the issue is that MAAS does not always update its DNZ zone entry for the node that is just deployed which  means it is unresolvable.
<mgz> frobware: okay, but there's no maas bug specifically for that in launchpad?
<mgz> or I'm not finding it?
<cherylj> mgz: I'm not sure that there was a separate bug for the MAAS issue.  I think they had just looked at the same bug frobware was working on:  bug 1412621
<mup> Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Fix Committed by frobware> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1412621>
<cherylj> mgz: or maybe I'm remembering wrong.  I thought I saw that the MAAS guys touched that bug
<dimitern> frobware, ah, I've haven't notices runScript takes explicit string arguments, so ignore my comment around using test.params...
<mgz> cherylj: I'm just not seeing any work on the maas side to fix things
<frobware> mgz, I just updated the bug
<mgz> frobware: thanks!
<frobware> mgz, if you drop back to IP addresses the replica set can continue; if you don't drop the unresolvable host names then the node will be unusable. I think we're pushing in the wrong direction. This, to me, is a MAAS issue.
<mgz> frobware: okay, I just didn't see that communicated anywhere
<frobware> mgz, but it was suggested we try and work around broken/sporadic provider behaviour.
<mgz> if we want maas to fix things we need to tell them
<frobware> mgz, that's mostly in the git commit
<frobware> mgz, re: "I just didn't see that communicated anywhere"
<frobware> mgz, resolving the names (which broke the unit tests for some) is a bad idea. We either back it out, fix it MAAS, or continue to workaround and add more crud.
<mgz> I'm generally for backing that out.
<frobware> mgz, the advertised solution is to use static IP addresses but I don't think you can do that for 1.8 - true?
<mgz> frobware: not in default config at least, everything just asks dhcp for an address
<dimitern> frobware, you can do that in 1.8 - with either devices or ipaddresses APIs
<frobware> mgz, dimitern: so if you're using dhcp you're like to run into this problem. if you can switch to static, there's a workaround. Open to backing this out if it is making things worse, et al.
<dimitern> frobware, well, having the option to do it is one thing, but actually doing it is quite a different story :)
<dimitern> frobware, I mean juju can't enforce restrictions on how your maas nodes get their addresses
<frobware> dimitern, right. not clear how practical a solution that is (for customers)
<dimitern> frobware, in most cases I guess customers will use static addresses for nodes
<alexisb> mgz, katco ping
<mup> Bug #1517992 opened: juju-upgrade to 1.24.7 leaves juju state server unreachable <juju-core:New> <https://launchpad.net/bugs/1517992>
<perrito666> sorry ppl, cannot make it to the hangout
<natefinch-afk> I guess I missed it
<katco> natefinch: we called it. too few people
<natefinch> katco: figured.  Sorry, kids' thanksgiving thing at school ran over.
<katco> natefinch: are you porting that fix for bug 1382556 to master?
<mup> Bug #1382556:  "cannot allocate memory" when running "juju run" <cpe-critsit> <run> <juju-core:In Progress by natefinch> <juju-core 1.25:Fix Committed by natefinch> <https://launchpad.net/bugs/1382556>
<natefinch> katco: I am now
<katco> natefinch: ty
<natefinch> man I wish git was better at dealing with moved files.
<katco> natefinch: did you get that bug ported to 1.25? saw the card is moved over
<natefinch> porting to master now, didn't realize the card should include the port, sorry, I can move it back.
<natefinch> katco: hit a snag that the ssh stuff moved outside the repo, so going to have to do a more manual port of that part of the code
<katco> natefinch: no worries, the bug was still open so just wanted to check
<katco> natefinch: bummer =/
<natefinch> we should just rename dependencies.tsv to mergeconflict.tsv
<natefinch> when did we start using gopkg.in/inconshreveable/log15.v2 ?
<katco> natefinch: lxd dependency
<natefinch> katco: gah... libraries shouldn't log :/
<natefinch> for exactly this reason
<natefinch> katco: can I just merge the forward ports?  While I had to manually copy over the changes from 1.25 to the new repo, it really is just an exact copy of the code... there were no changes in between the two as far as I can tell.
<katco> natefinch: do you mean don't go through the bot?
<katco> natefinch: or do you mean no review?
<natefinch> katco: no review
<katco> natefinch: yeah go for it
<mup> Bug #1509032 changed: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1509032>
<natefinch> aww dammit
<natefinch> someone changed juju/utils with a breaking API change, without updating juju core
<natefinch> dooferlad: ^
<alexisb> natefinch, he is sleeping I would think
<natefinch> alexisb: yeah, remembered after I pinged him
<menn0> mgz: ping?
<mgz> menn0: yo
<menn0> mgz: i'm helping out with a unit test failure on ppc64 (TestFilesystemInfo)
<menn0> it only seems to fail on ppc64
<menn0> can I get access to the ppc64 unit test host (stilson-09 I believe)?
<mgz> menn0: sure
<menn0> I already have access to stilson-08 from looking at an issue a long time ago but it doesn't appear to have any go tools installed
<mgz> there are a lot more meenos than I'd expect on lp
<natefinch> can someone review this 5 line patch so head on master actually compiles with head on juju/utils? http://reviews.vapour.ws/r/3192/
<natefinch> katco, menn0, thumper ^
 * menn0 looks
 * thumper shipped it
<natefinch> thanks!
 * menn0 is too slow
<natefinch> katco: once my fix to master lands, then my forward port should land
<natefinch> dinner time, back in a few hours
<katco> natefinch-afk: cool ty
<ericsnow> katco: I'm out like a trout
<katco> ericsnow: tc
<katco> ericsnow: how far did you get?
<ericsnow> katco: not too far
<ericsnow> katco: it *does* reproduce reliably (by re-running the CI job)
<ericsnow> katco: I've updated the bug report
<katco> ericsnow: ty
<mgz> menn0: hey, did you repo? my run just before restarting hit the failure
<menn0> mgz: yep, repoed it immediately
<menn0> mgz: I have a "fix", but it's really looking like a Go toolchain bug
<mgz> mwhudson will love you.
<menn0> mgz: printing out the struct created by state.FilesystemAttachmentInfo{MountPoint: "/srv"} gives {MountPoint: ReadOnly: true}
<menn0> but if I do state.FilesystemAttachmentInfo{MountPoint: "/srv", ReadOnly: false}, you get {MountPoint: "/srv", ReadOnly: false}
<menn0> serious wtf territory
<menn0> mwhudson isn't around today unfortunately
<mgz> menn0: sooo... is your "fix" constructing the thing with full params each time?
<mgz> e
<mgz> menn0: we don't seem to have had any compiler changes or other suspect things on stilson-09 recently, so mystery to me why it started happening on the 1.25 branch here
<menn0> mgz: yeah, it's pretty strange
<perrito666> hello again everybody
<menn0> davecheney: I just sent you and mwhudson details of a fun ppc64 issue via email
<davecheney> menn0: \o/
<davecheney> menn0: unconstructive answer: use go 1.5
<davecheney> nobody will fix gccgo4.9
<menn0> davecheney: joy :-/
<davecheney>         a := s.newAgent(c, ss)
<davecheney>         go func() { c.Check(a.Run(nil), gc.IsNil) }()
<davecheney>         defer func() { c.Check(a.Stop(), gc.IsNil) }()
<davecheney>         // Now run the test.
<davecheney>         s.assertUpgradeSteps(c, state.JobHostUnits)
<davecheney>         s.assertHostUpgrades(c)
<davecheney> what the f
<mup> Bug #1518128 opened: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>
<mup> Bug #1518131 opened: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>
<mup> Bug #1518128 changed: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>
<mup> Bug #1518131 changed: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>
<mup> Bug #1518128 opened: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>
<mup> Bug #1518131 opened: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>
#juju-dev 2015-11-20
<davecheney> thumper: // InitializeFromConfig needs to be called once after the environment
<davecheney> func InitializeFromConfig(config PreferIPv6Getter) { globalPreferIPv6 = config.PreferIPv6() logger.Infof("setting prefer-ipv6 to %v", globalPreferIPv6)
<davecheney> }
<davecheney> urgh
<davecheney> http://paste.ubuntu.com/13356006/
<davecheney> this method does not do what it's comment says
<thumper> wa?
<davecheney> it initalises nothing
<davecheney> unless it's a side effect of calling config.PreferIPv6
<thumper> davecheney: it sets the global variable
<thumper> globalPreferIPv6 = config.PreferIPv6()
<davecheney> oh fuck
<davecheney> welp, there's another data race
<davecheney> really ?
<perrito666> davecheney: can we call you "the prolific dave cheney" from now on?
<perrito666> http://features.slashdot.org/story/15/11/18/1748247/interviews-alan-donovan-and-brian-kernighan-answer-your-questions <-- for those who have not seen it, dave is featured in a Q&A by D&K
<davecheney> \o/
<davecheney> i have to be honest
<davecheney> i never read that post
<davecheney> it was full of toxic slashdotters
<davecheney> maybe I should try again
<perrito666> Nothing new but you are named as a proposer of the solution to version handling in go pks
<davecheney> orly
<perrito666> The rest of the questions are same old ones
<davecheney> i should *definitely* read that then :)
<wwitzel3> how often does the upgrade watcher cycle?
<thumper> davecheney: I want to change s/Opener/APIOpener/ back, as envcmd.Opener doesn't really describe it, but envcmd.APIOpener does a bit more
<thumper> davecheney: can you live with that?
<davecheney> thumper: sure
 * thumper move back to sitting deck
<axw> wallyworld_: I'm back, free to chat whenever you're ready
<wallyworld_> axw: ok, i have another meeting in 15 and need to do some other stuff also so best to wait to our schedule time
<axw> wallyworld_: nps
<davecheney> thumper: menn0 https://github.com/juju/juju/pull/3785
<thumper> davecheney: shipit
<davecheney> ta
<cherylj> hey menn0, are you going to make the change to TestFilesystemInfo?  or are you still waiting on input from mwhudson?
<davecheney> thumper: menn0 http://juju-ci.vapour.ws:8080/job/github-merge-juju/5520/console
<davecheney> here is a great example of why always using etsting.BaseSuite is a bad idea
<davecheney> in this case the test has failed because testing.Base suite also sets up some networking crap
<davecheney> even though the test is just checking did something get written to the log at trace level
<natefinch> it boggles my mind that we have tests that depend on the log output.
<mgz> ...?
<mgz> it makes sense to tese your logging isn't crap
<mgz> it doesn't make sense to do that at a functional test
<natefinch> there are some very specific circumstances where you would want to unit test some logging, I can understand that.   But it should be the exception rather than the rule.... and we have a ton of tests that'll fail if you disable logging (I know, I tried it back when I tried to make our failed test output not so horrific)
<davecheney> completely bonkers
<natefinch> we have a bad habit in juju tests of testing crap we really don't actually care about, so our tests are brittle, and break for ridiculous reasons, like fixing typos
<davecheney> for example
<davecheney> we have a method to set a global singleton to true, or false
<davecheney> and a third method that set it to false, but doens't log that's done anything
<davecheney> da fuq
<davecheney> and tests that rely on this behaviour
<davecheney> while i'm having a rant
<davecheney> i'm really pissed that all the test break if you don't have LXD installed
<davecheney> and not in a
<davecheney> c.FailNow("You don't have LCD installed")
 * natefinch hangs head.
<davecheney> they fail because something in the guts of the code the test is calling is shelling out to /usr/bin/lxd
<davecheney> and trying to parse the output
<davecheney> really shit
<natefinch> Sorry, yeah, we should fix that.
<natefinch> I'll file a bug for it.  Just didn't think of it, since we'd all installed LXD in order to be hacking on it.
<davecheney> thanks
<davecheney> i already logged a bug about the lxd provisioner failing horribly whne lxd is not installed
<davecheney> natefinch: open question: how did this pass in CI ?
<natefinch> / +build go1.3
<natefinch> :p
<natefinch> the lxd library uses some tsl function that's only in go 1.3+
<natefinch> tls
<natefinch> so the answer is... the tests don't get run in go 1.2... I don't know what happens on the wily build machine
<natefinch> eric and wayne were handling most of that
<natefinch> (and wily is still non-voting due to go 1.5 problems)
<davecheney> natefinch: that means the tests are not being run by the landing bot
<natefinch> davecheney: yes
<davecheney> bummer
<natefinch> indeed.   We all wear these now: https://cdn.shopify.com/s/files/1/0287/4374/products/DSC_8422_1024x1024.jpg?v=1411004337
<cherylj> natefinch: should we buy those for the sprint?
<davecheney> i'll have one in large thanks
<davecheney> make mine extra black
<davecheney> like my soul
<natefinch> lol
<cherylj> davecheney is so emo
<davecheney> pain, etc
<natefinch> also, this makes me so very sad:
<natefinch> /home/nate/src/github.com/juju/juju$ grep -r "ErrorMatches" . | wc -l
<natefinch> 2848
<natefinch> are there 2800 places where we care what the (more or less) exact error message is?  I doubt it.
<davecheney> make that two jumpers
<natefinch> does anyone even look at the bugs filed on charms?
<natefinch> the wordpress charm is fundamentally broken for people who actually want to like, you know, use wordpress (not just show the login screen).  I reported a bug about it 2 months ago and the bug hasn't even been triaged.
<natefinch> https://bugs.launchpad.net/charms/+source/wordpress/+bug/1491995
<mup> Bug #1491995: Can't upload files to wordpress <wordpress (Juju Charms Collection):New> <https://launchpad.net/bugs/1491995>
<Michael_temp> anybody?
<mup> Bug #1488523 changed: Azure provider attempts to reuse dying vnet <azure-provider> <bootstrap> <ci> <destroy-environment> <reliability> <repeatability> <juju-core:Won't Fix> <https://launchpad.net/bugs/1488523>
<mup> Bug #1494002 changed: azure deployment failure with mem constraints <azure-provider> <constraints> <deploy> <juju-core:Won't Fix> <https://launchpad.net/bugs/1494002>
<voidspace> dimitern: stdup?
<dimitern> voidspace, omw, 2m
<voidspace> frobware: https://github.com/juju/juju/pull/3788/files
<voidspace> dimitern: https://github.com/juju/juju/pull/3788/files
<voidspace> frobware: I do have test failures on that rebase branch but they're "weird"
<voidspace> frobware: can you run tests on that branch please
<frobware> voidspace, yep
<voidspace> frobware: all tests are passing so far on maas-spaces (as is) for me, so new failures are probably genuine :-/
<voidspace> might be worth you re-trying the rebase locally and seeing if you get the same result
<frobware> voidspace, that's what I was initially doing.
<voidspace> maas-spaces is all pass for me
<voidspace> trying master now
<frobware> voidspace, I rebased maas-spaces against master; make check works for me too
<voidspace> frobware: I'm getting test failures on master - at least some lxd related
<voidspace> so that maybe the problem
<frobware> voidspace, scrolling back through the chat there is mention of tests failing & (lack of) lxd installation
<frobware> voidspace, but given our rebase attempt they should fail in the maas-spaces branch as well... ?
<voidspace> container_initialisation_test.go fails on master for me too
<voidspace> as far as I can see the tests that fail on the rebase fail on master for me too
<voidspace> so should be ok
<voidspace> other than tests failing on master being a problem!
<voidspace> I'm installing lxd...
<frobware> voidspace, master is OK for me. I don't have lxd installed.
<voidspace> frobware: I'm on wily, I wonder if that's it
<voidspace> installing lxd doesn't make a difference
<voidspace> frobware: so do tests pass for you on my rebase branch?
<voidspace> if so I'll merge it
<frobware> voidspace, let me try your branch
<frobware> voidspace, ah. so wily will be go-1.5.
<voidspace> frobware: no, I'm using go 1.3.3
<voidspace> I thought lxd provider required go 1.5
<voidspace> hmmm, it used to - maybe that changed
<voidspace> it all builds ok without 1.5
<frobware> I have a wily plaground and `apt-get install golang-go' gives me 1.5. Are you building or using your own go build?
<voidspace> frobware: yes :-)
<voidspace> dimitern: frobware: so some of my failing tests on *my WIP branch* (not the rebase branch) were because with the addition of Spaces to NetworkingEnviron the dummy provider was no longer "supporting networking"
<voidspace> dimitern: frobware: so that's an easy fix
<voidspace> thank goodness
<dimitern> voidspace, alright!
<dimitern> voidspace, nice :)
<fwereade> goddammit just as I am properly getting into something I have to go out for a while -- back this evening
<perrito666> gluck
<perrito666> does anyone know if a maas can be done whith storage from a nas instead of having each machine have storage?
<maht> I am maas newbie, but I guess you would need to create a custom image that use the NAS as remote filesystem
<mup> Bug #1518347 opened: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
<mup> Bug #1518347 changed: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
<mup> Bug #1518347 opened: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
<mup> Bug #1518347 changed: LXD tests require LXD, but there's no friendly "you don't have LXD" error message <juju-core:New> <https://launchpad.net/bugs/1518347>
<voidspace> I have lxd installed, but get lots of test failures "can't connect to the local LXD server"
<voidspace> (permission denied)
<natefinch> voidspace: weird. we're in a meeting now.  what series are you on?
<frobware> voidspace, you still about? did we rebase?
<lazypower> o/ - can someone lend a hand in clueing me in as to the purpose/case for JUJU_ACTION_TAG is?
<lazypower> it appers to be a copy of JUJU_ACTION_UUID with the word "action" prepended, and thats the only discernable difference
<fwereade> lazypower, um, don't use it
<fwereade> lazypower, we probably never should have exposed it
<fwereade> lazypower, tags are meant to be homogeneous ids for the api layer
<voidspace> natefinch: I'm on wily
<voidspace> frobware: I didn't merge - I don't get a clean test run on master so it's not easy to tell if the merge works
<frobware> voidspace, ack
<frobware> voidspace, upstream/maas-spaces rebased seem to be OK though.
<voidspace> frobware: did you try my branch?
<voidspace> frobware: if tests pass on that I'll merge it
<voidspace> frobware: https://github.com/juju/juju/pull/3788
<frobware> voidspace, well they did about 10am... :)
<frobware> voidspace, I need to EOD in a bit. If you don't need this until Monday I could double-check again and then merge.
<voidspace> frobware: hah, I was waiting for you to tell me you'd tried it...
<voidspace> :-p
<frobware> voidspace, I did at 10am.
<voidspace> frobware: no hurry, Monday is ok
<voidspace> frobware: although I haven't touched that branch since, so if they passed then they'll pass now
<frobware> voidspace, I subsequently noticed later in the day I was using go 1.5 for that build so I should try again with 1.2.
<voidspace> frobware: I think the CI bot will try with 1.2
<voidspace> frobware: I've hit $$merge$$ anyway
<frobware> good point
<voidspace> natefinch: I'm using wily but using go 1.3
<alexisb> voidspace, lxd needs at least 1.3, for the lxd provider juju builds with what is in wily 1.5
<alexisb> voidspace, not sure if that helps
<natefinch> go 1.3 should work fine. I usually build with 1.4.2, just because it's the newest non-1.5 build (and the 1.5 builds are significantly slower).
<natefinch> wonder if it's a wily thing
<voidspace> alexisb: thanks, I have 1.3
<voidspace> it builds fine but I have test failures
<alexisb> voidspace, related to this: https://bugs.launchpad.net/juju-core/+bug/1517748
<alexisb> ??
<mup> Bug #1517748: provider/lxd: test suite panics if lxd not installed <juju-core:Triaged> <https://launchpad.net/bugs/1517748>
<voidspace> alexisb: see my comment on that bug
<alexisb> aah I hadn't refreshed
<voidspace> frobware: test failures for that merge, hard to see if they're the same or related or spurious or what
<voidspace> frobware: http://juju-ci.vapour.ws:8080/job/github-merge-juju/5525/console
<katco> voidspace: we will be addressing that next week. are you sure you're on tip of master?
<voidspace> katco: I was a couple of hours ago...
<voidspace> katco: I have lxd installed and still have test failures though
<voidspace> katco: so not *entirely* sure it's the same bug
<katco> voidspace: is your user in the lxd group?
<voidspace> katco: yep
<voidspace> I gotta go, 7pm here and guests arriving
<voidspace> EOW, sorry
<katco> voidspace: np ty for input
<katco> voidspace: we'll get it fixed enxt week
<voidspace> katco: cool, thanks
<frobware> cherylj, I pretty sure I understand why the bond and juju-br0 don't work. Need to futz with our script a bit -
<cherylj> frobware: ah, good to hear!
 * frobware EOF -- that's End of Friday. :)
<rick_h_> frobware: have fun!
<katco> natefinch: hey you're going to make sure the min-version branch has a bless before you land it into master, correct?
<natefinch> katco: yeah, good point.  I'll move it into a feature branch so it can get CI'd.
<katco> natefinch: k
<natefinch> katco: it's really not a hugely sweeping change by any stretch of the imagination, but I think it pays to be overly careful given the problems of the recent past.
<katco> natefinch: not even a question of impact, it's just policy
<natefinch> katco: fair enough
<katco> natefinch: talk to mgz or sinzui to see if you can get the next ci run to hit it
<mgz> natefinch: I can push your branch into the juju namespace if you need that
<natefinch> mgz: that would be very helpful
<natefinch> mgz: it's the minver branch on github.com/natefinch/juju
<mgz> natefinch: doing it
<mgz> natefinch: you are in and up next
<natefinch> mgz: thanks
<natefinch> rogpeppe3: are you actually here?
<natefinch> gah, I really hate it when people leave juju/juju in a state where it can't build against master of its dependent branches.  it means I have to fix the build before I can land anything
<natefinch> well, not getting juju min version in today it seems.
<katco> natefinch: =/ b/c of the libs ?
<natefinch> katco: yeah.  I can land the stuff in charm.v6, but the stuff in master won't be able to go in without fixes first... axw has what might be the fixes on a personal branch, but they're slightly above trivial, so I wouldn't want to touch them without talking to him
<katco> natefinch: makes sense. well at least you have ci building against your branch
<natefinch> katco: yeah, but I don't think I can make my branch compile for CI, even
<natefinch> katco: it works locally because I can hack things so that my commits are against an earlier version of charm.v6, but it can't be set up to run in Ci where it runs godeps
<katco> natefinch: oh. doh.
<katco> natefinch: well, once your fix to charm.v6 lands, you can patch your feature branch to use that version and run ci, yeah?
<natefinch> katco: this is the whole problem... landing the code in charm.v6 means landing after those breaking changes
<natefinch> katco: I fcan make it work locally because I can make a local branch off an earlier version of charm..v6 that excludes the breaking changes... but I can't create that kind of a branch in github.com/juju/charm
<natefinch> (I mean, In theory an admin could, but it would be a heinous thing to do)
<natefinch> I'll update my email to indicate that it's not just master but my feature branch that has this issue.
<katco> natefinch: sorry, not sure i understand. you're landing some fixes in charm.v6, why couldn't you patch up your feature branch to be compatible with those changes?
<natefinch> katco: oh, I could. They're just slightly beyond trivial... so I wouldn't want to get my feature branch in a bad state if I mess up those fixes
<natefinch> katco: if I talk to andrew and confirm that I just need to cherry picky a couple commits, then yeah, I can do that.
<katco> natefinch: oh i think i see.. you'd have to apply axw's changes to your feature branch and that is non trivial
<natefinch> correct
<katco> gotcha
<katco> natefinch: can you rebase your feature branch to a blessed version of master?
<katco> natefinch: at least then you've utilized your "dead time" and tested up to that point
<natefinch> katco: yes, but the problem is in charm.v6, so it would still be there.  The solution could be to make a feature branch in charm.v6 off the earlier blessed version
<katco> natefinch: yeah, not a bad use of the "dead time". also looks like mgz just sent an email
<katco> natefinch: might have some other stuff to fix up
<natefinch> gah, yeah
<natefinch> just read it
<natefinch> ok, I'll work on that tonight.  Gotta run to make dinner now.
<katco> natefinch: have a good thanksgiving
<natefinch> katco: you too!
<fwereade> hey, do we have a way of flagging long-running tests as not-for-normal-runs?
<perrito666> fwereade: I believe we do
<fwereade> perrito666, do you happen to know what it might be?
<perrito666> fwereade: nope, katco told me a gazillion times and I forgot a gazillion + 1
 * fwereade glances hopefully at katco
<fwereade> ...although I've almost convinced myself that it's ok to patch just this once
<katco> fwereade: o/ is this what you're looking for? https://github.com/juju/juju/blob/master/featuretests/package_test.go#L15
<fwereade> katco, I was wondering if there was something that'd work globally
<fwereade> katco, but I am being silly anyway
<katco> fwereade: oh, no i don't think we've begun flagging certains tests as long or short yet
<fwereade> katco, cheers
<katco> fwereade: happy friday to you :)
<fwereade> katco, and to you :)
<fwereade> katco, by the way, do you recall state/testing.NotifyWatcherC et al?
<katco> fwereade: not at all... what is it?
<fwereade> katco, it's a test harness for a watcher
<fwereade> katco, was wondering, if you'd used it, whether you thought it was a sane interface
<katco> fwereade: i haven't used it, sorry :(
<fwereade> katco, no worries :)
<katco> fwereade: however, i do almost have a working charm that starts an emacs web server. so that must count for something.
<fwereade> katco, sweet :D
<katco> fwereade: this is going to be such an unholy abomination. i love it.
<fwereade> katco, in principle, I heartily approve, but please be ready to pull the plug in case skynet
<katco> fwereade: it's too late, dear william. it's already gotten to me.
 * fwereade welcomes our new robots overlords
<perrito666> uh, robot overlords? sweet I could do with a break on all the thinking stuff
<katco> perrito666: i was very happy to see you still using emacs in your tweet :)
 * perrito666 is as close to burnout as one can be before being actually burnt
<perrito666> katco: it totally stuck this time, Just need to get a bit more proficient, but I am on a good path
<katco> perrito666: good to hear
<katco> perrito666: the packaging system + use-package is a great combination
<perrito666> I might use a couple of hours of my holidays to learn a few tricks more
<perrito666> and perhaps tune it a little more
<katco> perrito666: this is a fun site: http://emacsrocks.com/
<perrito666> I see you are not only working in new clients but also in retention :p
<perrito666> my next conquest is to try to get a marker in the lines that are not git committed yet, which is a feature I miss a lot
<katco> perrito666: i must do as the master suggests.
<katco> perrito666: there might be something better, but a quick scan: https://github.com/nonsequitur/git-gutter-plus
<perrito666> nice, actually I am going for something simpler, I am completely happy to use the command line for git :p
<perrito666> I just want the +, ~ and - next to the line number
<perrito666> Ill try all options I find :D
<katco> perrito666: i highly recommend magit as a better way to git
<perrito666> uhh, sweet, new github design
<katco> perrito666: it's so nice. remind me to show you in dec. if you'd like
<perrito666> katco: after years of git, I believe a better way to git is not to git at all :p
<perrito666> katco: totally, I always dig learning new tools
<katco> magit makes so many things much simpler
<katco> i think any gui for git might
<katco> but it's nice that it's built into emacs
<perrito666> katco: Ill be honest here, the only git guis that I liked where for OSX
<perrito666> and iirc, commercial :p
<katco> magit might change your mind. it is really nice.
<perrito666> git and diff displaying in general can benefit a lot from modern graphic paradigms
<perrito666> but hey, in linux Ill take what I can get :p
<katco> perrito666: with magit, you have a file you need to merge, you cursor down over the file, hit e and you get a side-by-side with merged at the bottom
<katco> red/green highlighting, etc.
 * perrito666 watches screenshots
<perrito666> I really dig stuff like this https://deeperdesign.files.wordpress.com/2011/05/screen-shot-2011-05-27-at-12-59-14-pm.png
<katco> perrito666: here's what ediff looks like: http://www.tldp.org/LDP/LG/issue27/gx/marsden/ediff-merge.gif
<katco> perrito666: and then you hit a or b depending on which side you want merged
<perrito666> is that motif?
<katco> lol no idea
<katco> the bottom is the merged version
<perrito666> blast from the past :p but hey, I have seen worse, ill give it a shot
<mup> Bug #1518480 opened: Invalid storage prevents machine removal <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1518480>
<mup> Bug #1518482 opened: Invalid storage returned by storage-list causing charm breakage <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1518482>
#juju-dev 2015-11-22
<axw> katco natefinch-afk: sorry, I should have had my juju/juju branch ready in time to land it along with the others. it's landed now, anyway.
<fwereade> I'm feeling a strong desire not to test worker/environ/manifold.go -- which currently looks like http://paste.ubuntu.com/13458228/
<fwereade> someone please disabuse me of the notion that it's so simple that there are obviously no bugs
<perrito666> fwereade: I am officially on holiday so, since this will not be my problem for a week: knock yourself out
<perrito666> :p
 * fwereade cheers heartily at perrito666
<fwereade> enjoy your holiday :)
<perrito666> fwereade: tx :)
<thumper> fwereade: hey ,would love a 5 min chat if you have time
<fwereade> thumper, heyhey
<fwereade> thumper, let's
<thumper> k
<thumper> fwereade: https://hangouts.google.com/hangouts/_/canonical.com/machine-dep-engine?hl=en&authuser=1
<menn0> fwereade: fine by me
<axw> wallyworld: webcam isn't working, be there soon as I fix it
<wallyworld> sure
#juju-dev 2016-11-21
<babbageclunk> thumper: review plz? https://github.com/juju/juju/pull/6588
 * thumper looks
 * babbageclunk thanks thumper kindly.
<babbageclunk> thumper - any idea why my !!build!! isn't triggering a check build?
<thumper> nope, I've not grokked that part much
<babbageclunk> thumper: thanks for the comments - good points.
<babbageclunk> thumper: I'm not sure about having a log file per model.
<babbageclunk> At the moment the log file is managed by lumberjack so it does rolling and doesn't take up too much space.
<babbageclunk> If it was per-model wouldn't we have to come up with something else on top to do the same thing?
<thumper> yeah...
<thumper> it would be more manual
<thumper> I'm happy enough with a global one..
<thumper> given that it is really just a backup
<babbageclunk> thumper: cool
<babbageclunk> thumper: at the moment debug-log (which will be the source of the logs) doesn't send the version with the log records.
<thumper> no... I don't even know why it is there TBH
<babbageclunk> I'm not sure whether the version is important
<thumper> I think I know who might ahve added it but no idea why
<babbageclunk> It does seem a pity to just throw that info away when we migrate though.
 * thumper has to run
<babbageclunk> okbye
<babbageclunk> whoa, he really meant it
<mup> Bug #1592188 opened: No 'enable-ha' for manual provider <juju-core:New> <https://launchpad.net/bugs/1592188>
<Andrew_jedi> Hello Folks, I am playing with liberty release and by default i get keystone v2 endpoints. Is it possible that i can turn on keystone v3 api by default for liberty.
<Andrew_jedi> jamespage: ^^
<jamespage> Andrew_jedi, yes
<jamespage> the keystone charm has a configuration option to allow v3 to be used
<Andrew_jedi> jamespage: Ok and to enable it, I will have to recreate the keystone service after making changes to the config file?
<jamespage> Andrew_jedi, no I think you can just enabled it on the running environment
<jamespage> juju config keystone preferred-api-version=3
<jamespage> I think
<jamespage> check the key
<Andrew_jedi> jamespage: Ok, let me execute this command.
<Andrew_jedi> jamespage: http://paste.openstack.org/show/589861/
<jamespage> config/set
<jamespage> config is juju 2.0
<Andrew_jedi> jamespage: thanks i was looking for this everywhere. Executing again :)
<mattyw> does anyone know a way that I can find out what relation values are being set in given relationships?
<deanman> I
<deanman> Hi I'm running into a problem with LXD where when attached using the `lxc exec` command and running a command in the background then i cannot dettach from that LXD.
<deanman> Is there a channel specific to LXD?
<natefinch> rick_h, do you know ^
<rick_h> deanman: natefinch not that I know of no. I think the issue is just how exec works with lxd. I'd use ssh for that if you can deanman.  https://github.com/lxc/lxd/issues/1830 for instance walks through some of the tricks that goes into things.
<katco> rick_h: my browser is not loading hangouts for some reason; trying to figure it out
<rick_h> katco: I had to restart FF today as it upgraded and needed a restart to pick up the plugin
<katco> rick_h: i use chrome; restart doesn't appear to have worked... lemme try ff
<katco> rick_h: going to try and reboot the machine
<deanman> Hey rick_h, thanks for the tip, will look into it more.
<menn0> thumper, babbageclunk, mwhudson: o/
<thumper> menn0: would love a chat when you've read my email
<thumper> menn0: it's the one with the body that starts with "well... fuck"
<perrito666> lol, like he has only one email from you with that subject
<babbageclunk> menn0: hi!
<mwhudson> menn0: hi
<menn0> thumper: i've read it once, will read it again with more attention to the details
<thumper> menn0: ack, let me know when you're ready
<menn0> thumper: ok 1:1?
<thumper> menn0: just in the middle of a web form, be there in a sec
<katco> natefinch: ping
<natefinch> katco: only here for a moment... what's up?
<katco> natefinch: hey i'll be quick
<katco> natefinch: starting work on allowing IB to give a cloud a name. 1. can i start from develop, 2. does that overlap with anything you're doing?
<natefinch> katco: it will tie into what I'm doing, but I haven't gotten there yet, so you're welcome to get the ball rolling :)
<katco> natefinch: is there anything i should look at in terms of integration?
<katco> natefinch: commit, branch, etc.
<natefinch> katco: interactive add cloud is the current state of the art.  cmd/juju/cloud/add.go  it uses cmd/juju/interact.Pollster to interact with the user, we should be moving toward using that, since it standardizes the formatting etc.
<natefinch> katco: that's all available in develop
<katco> natefinch: cool cool
<katco> natefinch: ty
<natefinch> katco: welcome :)
<babbageclunk> menn0: ping
<menn0> babbageclunk: hi, sorry on a call
<babbageclunk> tsk, thumper!
<babbageclunk> ;)
<perrito666> mm, a heavy earthquake hit japan, are you guys ok at nz?
<perrito666> babbageclunk: thumper menn0
<thumper> we are a long way from japan
<menn0> nothing here
<perrito666> thumper: I know, but I though usually eqs on japans sea on your side would end up being felt there
 * perrito666 well look at that, I thought the indo-australian plate was covering jp too, I stand corrected
<babbageclunk> perrito666: ring of fire baby
<babbageclunk> perrito666: oh man, Fukushima again. :(
<perrito666> babbageclunk: sadly yes
<babbageclunk> perrito666: Wow, the 2011 earthquake was magnitude 9!
<perrito666> yup, yet todays is advertised as 7.3 which is a big shake
 * perrito666 tries to purchase a used 11" macbook air to try some things and finds it has the same price tag as a new 13".... what is wrong with people?
<menn0> babbageclunk: ok, i'm free
<babbageclunk> menn0: I think I just had an epiphany, but I'll run it by you.
<babbageclunk> menn0: Oh, did you work out what was going on with thumper's thing?
<babbageclunk> his problem I mean
<menn0> babbageclunk: yep
<babbageclunk> oh nice - what was it?
<menn0> babbageclunk: it was a tough one but it ended being due to old indexes
<babbageclunk> ugh
<menn0> babbageclunk: mgo handles index violations badly
<menn0> babbageclunk: so failed updated were being silently ignored
<menn0> updates
<babbageclunk> gross
<thumper> it is so frustrating
<thumper> because I knew the indices were wrong
<thumper> and we deleted them
<thumper> but after the updates
<thumper> not before
<thumper> so they were interferring
<babbageclunk> how is "old indexes" even a thing you need to worry about with a database?
<menn0> babbageclunk: this isn't mongodb's fault, it's more a problem with mgo
<babbageclunk> Oh wow, so you can have a transaction where the assertions pass, so it's applied, but fails and partially applies because of an index error?
<thumper> yes
<menn0> babbageclunk: afaics it's due to the logic to prevent txn's failing if multiple txns attempt to insert the same doc at the same time
 * babbageclunk throws up in mouth
<menn0> babbageclunk: I'll send an email about it later today. it's probably worth getting niemeyer involved as well.
<perrito666> babbageclunk: I believe we owe you the "what mongo is and isnt" talk
<babbageclunk> presumably over some strong drinks
<perrito666> babbageclunk: short one txn is a task queue not a transactional engine and mongo is a bag of hopeful storage not a db
<perrito666> I go by these rules and they work for me
 * babbageclunk sighs
<perrito666> no, seriously, you need to make your head stop thinking in mongo+txn as if it was a rdbms because many of us did and that is where you eff up
 * perrito666 pats babbageclunk on the back and hands a beer
<menn0> babbageclunk: did you want to chat?
<babbageclunk> Yeah, I can get behind that. Except for the transaction being marked as successful.
<babbageclunk> menn0: yes please! ok, so on a happier note, I'm trying to work out how to get to the debug log api from the migrationmaster worker
<babbageclunk> menn0: It's a bit fiddly to call api.Client.WatchDebugLog, because I need a *state.
<menn0> babbageclunk: and workers can't use *State directly... they have to use the API
<babbageclunk> menn0: It seems like I can change that to use FacadeCaller.RawAPICaller().ConnectStream instead.
<babbageclunk> menn0: Oh, no - it's an api.state, not a state.State.
<menn0> babbageclunk: ok cool
<babbageclunk> menn0: But I don't have a *api.state either.
 * menn0 looks at code to refresh his memoory
<menn0> memory too
<babbageclunk> menn0: Basically, once I can call WatchDebugLog then I can call openAPIConn to get to the target /migrate/logtransfer endpoint and everything else should be straightforward.
<menn0> babbageclunk: probably the most correct thing to do is to extract the guts of WatchDebugLog to api/common and then add a similar (probably simpler) API to the api/migrationmaster facade
<babbageclunk> menn0: ok - you mean make the guts take a stream or streamconnector then?
<babbageclunk> menn0: yeah, that sounds good.
<menn0> babbageclunk: yep
<babbageclunk> menn0: I was a bit nervous about changing the api.Client.WatchDebugLog bit to use the FacadeCaller instead of the st, just in case something was making a Client where they were different for some reason.
<menn0> babbageclunk: you'll also need to consider the transfer of logs getting interrupted
<babbageclunk> menn0: I was worried you might say that.
<menn0> babbageclunk: that'll make things "fun" ...
<babbageclunk> menn0: We don't really have any kind of sequence number we could yse for that on the logs themselves, right?
<babbageclunk> use
<menn0> babbageclunk: no we don't... the best we've got is the timestamps
<menn0> babbageclunk: a small amount of overlap on retry is probably ok
<menn0> babbageclunk: there is the LastSentLogTracker in state/logs.go
<menn0> babbageclunk: maybe that could be used for this too (it was developed for shipping logs offsite)
<babbageclunk> menn0: So I need to make the receiving side discard logs when they're before the last sent log?
<menn0> babbageclunk: I was thinking more that the sender (i.e. the migrationmaster) would track what had already been sent and not send again
<babbageclunk> menn0: ah, ok
<menn0> babbageclunk: otherwise if there's 3GB of logs to send and 2GB has already been sent, that's a lot of wasted bandwidth
<perrito666> brb grocery shopping
<babbageclunk> menn0: But it needs to be able to query what the target has, right?
<menn0> babbageclunk: in theory it should know if it's recorded locally
<menn0> (that's what the LastSendLogTracker does)
<menn0> babbageclunk: but it might be better to ask
<menn0> babbageclunk: in fact that would simplify things a lot
<menn0> babbageclunk: do that :)
<menn0> babbageclunk: so the LOGTRANSFER phase ends up looking like: ask the timestamp that the target has, stream from that timestamp onwards
<babbageclunk> menn0: So that would be another method on the migrationmaster facade to get the latest log time? Or probably have something in the logtransfer endpoint to track the last time.
<babbageclunk> menn0: quick chat to clarify? :)
<menn0> babbageclunk: the migrationtarget facade will need a new API to query the latest log timestamp
<menn0> babbageclunk: HO would be good
<babbageclunk> menn0: yeah, I meant migrationtarget rather than migrationmaster.
<babbageclunk> menn0: https://hangouts.google.com/call/p4p47uhzxzbm5iycpkv66uc3tae
<babbageclunk> menn0: actually. try this https://hangouts.google.com/hangouts/_/canonical.com/menno
<alexisb> thumper, on the HO whenever you are ready
<thumper> HO or blue jeans?
<alexisb> bluejeans
<alexisb> menn0, ping
#juju-dev 2016-11-22
 * babbageclunk goes for a run
<perrito666> wallyworld: see priv msg
<axw> anastasiamac menn0: on the topic of not being entirely confused: https://en.wiktionary.org/wiki/mersi
<menn0> axw: cool :)
<anastasiamac> axw: we should start a club \o/
<babbageclunk> menn0: ping
<menn0> babbageclunk: pong
<babbageclunk> menn0: So the other thing that I forgot to ask about because you threw that bijou spannerette into the works was about the version numbers on the log messsages.
<babbageclunk> menn0: on https://github.com/juju/juju/pull/6588 thumper-dogwalk was wondering whether we should maintain them from the source system.
<babbageclunk> menn0: link to relevant comments https://github.com/juju/juju/pull/6588#discussion_r88825956
<menn0> babbageclunk: sorry, got distracted
<menn0> babbageclunk: I didn't know that the version number was being sent
 * menn0 looks at the code
<babbageclunk> menn0: Well, it's sent as a url parameter when the logsender connects to the logsink api handler.
<menn0> babbageclunk: yep I see that
<menn0> babbageclunk: given that the current code requires it, I guess continue passing the version from the source controller
<menn0> babbageclunk: it's terrible that each log record in the DB stores the version
<menn0> babbageclunk: but I don't think you should try to fix that now
<menn0> babbageclunk: all the logs in the DB should be in the same format
<babbageclunk> menn0: ok, but not changing debug-log to get the version from the source DB and emit it?
<babbageclunk> menn0: I'm good with not doing that, just want to check.
<menn0> babbageclunk: sorry... can we HO, I'm not understanding
<babbageclunk> menn0: sure https://hangouts.google.com/hangouts/_/canonical.com/menno
<thumper> menn0, babbageclunk: I'd like to know the rationale behind the sending of the juju version
<thumper> I just don't see the point
<thumper> and especially storing extra data we don't need in the lgos
<thumper> logs
<menn0> thumper: I just chatted to babbageclunk. we all agree that storing version on each log record is dumb.
<menn0> thumper: babbageclunk is filing a bug about that
 * thumper agrees
<menn0> thumper: that's what I meant by *all* :p
<thumper> :)
<menn0> thumper: the version isn't going to be sent per record when the logs are transferred during migration
<menn0> thumper: but to avoid having to change too much now it's still going to be sent at connection time (it might end up being useful too)
<thumper> sure
 * thumper needs coffee badly
<natefinch> I cant believe someone would write a REST API "wrapper" and just give it methods for Get, Delete, Post, etc.
<natefinch> thumper: totally unrelated... any idea the easiest way to ping a maas to make sure the endpoint is correct?
<thumper> natefinch: yeah
<thumper> natefinch: there is an unauthenticated endpoint I think you can hit
<thumper> which will tell you version info
 * thumper looks
<natefinch> that's what I was thinking of... the gomaasapi package documentation is somewhat less than helpful
<thumper> given an endpoint
<thumper> do a GET endpoint/version
<thumper> see if that works
 * thumper thinks...
<thumper> nope
<thumper> endpoint/api/2.0/version
<natefinch> thumper: I was going to use gomaasapi's NewUnauthenticatedClient.... a little search in our codebase shows client.GetSubObject("version/").CallGet("", nil) might work?
<thumper> if you have go
<thumper> then it is very easy
<natefinch> yeah.... this is an addition to the maas provider
<natefinch> a way to precheck a url when doing interactive add-cloud to make sure you don't typo the endpoint
<thumper> gomaasapi.NewController(gomaasapi.ControllerArgs{
<thumper> 		BaseURL: maasServer,
<thumper> 		APIKey:  apiKey,
<thumper> 	})
<thumper> if it errors, it isn't there
<natefinch> this is pre-controller
<natefinch> before bootstrap
<thumper> this isn't a juju controller
<thumper> but a gomaasapi controller
<natefinch> oh, I see
<thumper> it is just a nice endpoint to hit
<thumper> it wraps all the maas objects
<thumper> part of the controller creation
<thumper> is to check that the endpoint supports the 2.0 api
<thumper> if it isn't up, or doesn't support it
<natefinch> what's apikey?
<thumper> it will error out
<thumper> the oauth key
<thumper> that they need to provide for authentication / authorization
<natefinch> the problem with that is that add-credential is separate from add-cloud, so I won't have the apikey yet.
<natefinch> the version check should work though, assuming it can be done unauthenticated
<thumper> yeah, not 100% sure, but worth checking
<thumper> the new controller might barf if not given a valid key
<thumper> natefinch: this is icky
<thumper> natefinch: but specify an empty apikey with "::"
<thumper> the code does a split on ":" and checks for 3 elements
<natefinch> ha
<babbageclunk> thumper: ping?
<thumper> babbageclunk: hey
<babbageclunk> thumper: So I was gearing up to use ConnectStream to talk to the migration target when I realised that it sticks a model uuid on the front of the path
<babbageclunk> thumper: plus there's no way to add the model uuid header to the request.
<thumper> yeah... there is
 * thumper thinks
<babbageclunk> It looks like the machine nonce has some specific handling.
<thumper> babbageclunk: it may need a little refactoring with a hammer
<babbageclunk> Yeah, that's what I figured.
<babbageclunk> thumper: I was thinking a ConnectControllerStream, which would also take some headers to add to the request.
<thumper> babbageclunk: sounds reasonable
<babbageclunk> thumper: And then an adapter that takes some headers and exposes a ConnectStream method that calls ConnectControllerStream internally...
 * thumper nods
<babbageclunk> So I can pass it to something that takes a StreamConnector.
<babbageclunk> Make sense?
<thumper> babbageclunk: you probably want to do something similar to what I did for the binary transfer
<thumper> but yes
<thumper> it matches what you are saying
<babbageclunk> ok great!
<babbageclunk> thanks
<babbageclunk> oh, actually, I don't think I need the adapter - I thought I needed to call something that expected a StreamConnector, but that's on the reading side.
<thumper> menn0: https://github.com/juju/juju/pull/6592
<natefinch> tfw you haven't run your vmaas in forever and now can't remember what the login info is
<wallyworld> axw: there's no rush because farking bot is broken, if you get a chance at somepoint, here's a boilerplate PR to set up the remote relations worker https://github.com/juju/juju/pull/6593
<axw> wallyworld: okey dokey, will look after lunch. just about ready to send my PRs so will have a break
<wallyworld> sure, np, ty
<wallyworld> can't land till bot is fixed anyway
<wallyworld> i need to go get food as well
<anastasiamac> babbageclunk: updated PR as discussed, so far has been running without failures for 45+mins (over 1700 runs)
<anastasiamac> babbageclunk: https://github.com/juju/juju/pull/6574
<anastasiamac> babbageclunk: before it used to fail within then first 400 depending on my mood :)
<anastasiamac> babbageclunk: is it what u had in mind? :D
<voidspace> katco: https://www.facebook.com/mfoord/posts/10153916822535880
<katco> voidspace: tal
<katco> voidspace: are the diamonds ethically mined?
<voidspace> katco: that is a good question to which I do not know the answer.
<voidspace> katco: I will ask
<voidspace> katco: rick_h: https://www.etsy.com/uk/shop/MirielDesign?ref=l2-shopheader-name
<mgz> voidspace: I'm reading several slightly confusing sets of instructions on stackoverflow involving git rev-list
<voidspace> mgz:  a manual bisect is probably less hassle...
<voidspace> katco: I have emailed Josephine and asked her - I will be astonished if they are not, but worth asking.
<natefinch> mgz: thoughts on implementing a Ping(endpoint) method for the openstack provider?
<mgz> natefinch: my first thought is the method just needs to call authClient()
<natefinch> mgz: ideally it needs to be without auth.  This is during add-cloud, so we don't have creds yet
<mgz> well, until Authenticate is called I don't think it actually talks, lets just see if there's a keystone command we can do without auth
<mgz> well, listing certainly can be, lets see if goose exposes rather
<mgz> there's FetchAuthOptions
<mgz> is that sensibly exposed...
<mgz> natefinch: looks like you can create an authenticcatingClient, then rather than calling Authenticate, call IdentityAuthOptions
<mgz> which will return not-nil, nil if the endpoint is valid keystone
<natefinch> mgz: interesting, ok
<mgz> that doesn't give you region info
<balloons> what's the best way to confirm which agent was used to bootstrap with? I can look at the logs -- anything more programmatic than that? I want to confirm I used a specific location that isn't streams.c.c
<natefinch> mgz: I just need to check if there's actually an openstack at that endpoint
<mgz> balloons: bootstrap output is the best way
<natefinch> mgz: can I check region endpoints the same way?
<balloons> mgz, redirect and grep the debug log?
<mgz> natefinch: I think you might need valid creds to get service/region pairs
<natefinch> mgz: I mean, can I call IdentityAuthOptions with the url of the region endpoint?
<mgz> balloons: yes, I don't think I can come up with a better options
<mgz> natefinch: no, IdentityAuthOptions only looks at what the keystone service itself is advertising as endpoints
<mgz> to get a list of services, you need a url under that, which I think will generally require creds
<natefinch> ahh, three line error message from goose, fantastic
<natefinch> mgz: seems to work :)
<natefinch> mgz: interestingly enough, that should let us just avoid asking what kind of auth the cloud uses
<mgz> natefinch: ah yes, that is also upside
<natefinch> mgz: somewhat tricky to add, though, given that this is in the middle of some very generic code.
<natefinch> I'll skip it for now and make a todo for later.
<voidspace> katco: Josephine of Miriel is confident that her diamonds are ethically sourced and has pointed me to the two places she sources them from
<katco> voidspace: awesome!
<voidspace> katco: I'm glad you asked actually, it should have occurred to me
<katco> voidspace: i don't know much, but i do know that is a bloody business :(
<voidspace> katco: yup :-(
<voidspace> time to collect daughter
<natefinch> I think most places these days use ethically sourced diamonds, but it's definitely always good to ask.
<natefinch> (at least in first world nations)
<katco> natefinch: do you know how my card is different from https://github.com/juju/juju/blob/develop/cmd/juju/cloud/add.go#L162 ?
<katco> rick_h: ping
<rick_h> katco: otp pong
<katco> rick_h: it can wait
<alexisb> mgz, ping
 * voidspace is currently deploying about 60 machines with juju 2.3.0
<rick_h> voidspace: wooo! you'll soon reach deployment master levels
<voidspace> :-)
 * alexisb changes locations 
<mup> Bug #1592188 changed: No 'enable-ha' for manual provider <ensure-availability> <juju-core:Triaged> <https://launchpad.net/bugs/1592188>
<mup> Bug #1357760 opened: ensure-availability (aka HA) should work with manual provider <cloud-installer> <ha> <landscape> <manual-provider> <manual-story> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1357760>
<mup> Bug #1493058 opened: ensure-availability fails on GCE <docteam> <enable-ha> <gce-provider> <ha> <jujuqa> <juju:Invalid by thumper> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1493058>
<mup> Bug #1357760 changed: ensure-availability (aka HA) should work with manual provider <cloud-installer> <ha> <landscape> <manual-provider> <manual-story> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1357760>
<mup> Bug #1493058 changed: ensure-availability fails on GCE <docteam> <enable-ha> <gce-provider> <ha> <jujuqa> <juju:Invalid by thumper> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1493058>
<mup> Bug #1592188 opened: No 'enable-ha' for manual provider <ensure-availability> <juju-core:Triaged> <https://launchpad.net/bugs/1592188>
<mup> Bug #1592188 changed: No 'enable-ha' for manual provider <ensure-availability> <juju-core:Triaged> <https://launchpad.net/bugs/1592188>
<mup> Bug #1357760 opened: ensure-availability (aka HA) should work with manual provider <cloud-installer> <ha> <landscape> <manual-provider> <manual-story> <juju:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1357760>
<mup> Bug #1493058 opened: ensure-availability fails on GCE <docteam> <enable-ha> <gce-provider> <ha> <jujuqa> <juju:Invalid by thumper> <juju-core:Triaged> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1493058>
<perrito666> gah, this way of testing things breaks GoImpl
<babbageclunk> oh my goodness everyone! I cleaned my keyboard yesterday evening and it is soooooo good!
<perrito666> babbageclunk: I am not sure if that is cool or gross :p
<perrito666> I am confused
<babbageclunk> perrito666: it was very gross. But now it is supercool.
<perrito666> babbageclunk: laptop kb?
<babbageclunk> perrito666: no, proper keyboard
<babbageclunk> perrito666: tempted to bring it to the sprint to show you, but obviously that's madness.
<babbageclunk> perrito666: just imagine a really gross dirty keyboard, and juxtapose that in your mind with a really hyper clean one.
<perrito666> babbageclunk: lol, well my kb is not the image of cleanness
<perrito666> i am too lazy to remove all keys though
<babbageclunk> perrito666: one touches them all day with one's gross hands.
<babbageclunk> perrito666: I thought I was too lazy too, but it turned out to be a) easier than I expected and 2) way more satisfying.
<babbageclunk> perrito666: so now I'm a swivel-eyed kb-cleaning loon
<babbageclunk> perrito666: on a more work-related note - is there any easy way to get go to build all the tests under juju/juju?
<babbageclunk> perrito666: I keep moving stuff as part of refactoring and then find I haven't updated the tests that refer to it.
<perrito666> go test -run=XXX
<perrito666> iirc
<perrito666> that will build all but not run any
<babbageclunk> Ah, ok - I'll try that the next time I move something. Thanks!
<babbageclunk> perrito666: ^
<alexisb> babbageclunk, perrito666 my keyboard is covered in peanut butter and jelly from this morning
<perrito666> babbageclunk: I am not 100% sure of the syntax but its near that
<perrito666> alexisb: why? lost apetite after spreading it and are saving it for later?
<alexisb> jay's discovery of reading letters has made my keyboard a constant victim
<perrito666> lol
<babbageclunk> alexisb: ha ha
<perrito666> mine is covered by the continuous reminder that I am going bald
<alexisb> lol
<perrito666> I am thiking on buying the vi cheatsheet variant of the keys for my kb
<perrito666> so that might be a chance for a cleanup
<alexisb> perrito666, I can meet early for our 1x1 if you would like
<perrito666> alexisb: sure, going
<katco> natefinch: ping
<katco> mgz: ping
<mgz> katco: heya
<katco> mgz: hey was natefinch talking with you about methods on providers?
<mgz> yeah
<katco> mgz: hop in ?core for a sec?
<mgz> surething
<alexisb> wallyworld, ping
<wallyworld> yo
<alexisb> wallyworld, can you jump into our 1x1 HO really fast
<wallyworld> i can
<axw> thank mgz and menn0 for the reviews
<mgz> axw: no worries, I'm still around for a bit if you need to bug me
<axw> mgz: nah all pretty clear. the switching thingy is ugly I know. we need to defer auth until the methods are called, because Open is not meant to make any API calls
<axw> mgz: might be able to tidy it up a bit by making additional calls at the callsites though
<blahdeblah> axw: I have an lp:1587644-affected environment in Canonistack right now and am about to try the "block traffic to 17070" trick to see if the controller recovers.  Anything you want me to gather from the controller first?
<axw> blahdeblah: just the current CPU/mem, but I guess you have that from monitoring already?
<blahdeblah> Should do; let me double-check
<menn0> axw: that auth thing wasn't a show stopper... just wondering if it could have been tidier
<axw> menn0: yup
<axw> alexisb: pool guy chose a great time to arrive, gonna be late sorry
<blahdeblah> axw: Load doesn't seem outrageous: https://libertysys.com.au/imagebin/rdIGeIze.png - smoking gun is really memory & network traffic: https://libertysys.com.au/imagebin/IZFYoL51.png https://libertysys.com.au/imagebin/2rJpeCDe.png
#juju-dev 2016-11-23
<blahdeblah> axw: Does jujud-machine-0 need to contact itself on 127.0.0.1:17070?  I'm seeing those connections pop up even after seeing remote ones drop away.
<blahdeblah> axw: i.e. should I allow the loopback ones?
<axw> blahdeblah: it does yeah, maybe just stop the agents *except* jujud-machine-0 because jujud-machine-0 talks to itself over loopback also
<blahdeblah> axw: Righto; so allow loopback, and stop the other agents on the machine 0
<axw> blahdeblah: yup
<blahdeblah> axw: OK - that's done; how long shall I leave it before checking for recovery?
<axw> blahdeblah: I would expect it to be fairly quick if it's going to fix the issue. 10-15 mins
<blahdeblah> OK - time to make a coffee and see how it goes then. :-)
<blahdeblah> axw: load dropped off pretty dramatically: https://libertysys.com.au/imagebin/2iugcW6L.png
<blahdeblah> and network traffic, but that's pretty much expected given I'm stopping the packets: https://libertysys.com.au/imagebin/B8B9g8F7.png
<blahdeblah> axw: and here's your smoking gun: network https://libertysys.com.au/imagebin/Dqygzb0N.png
<blahdeblah> axw: what next - start the local agents back up?
<axw> blahdeblah: yes, unblock them and see what happens please
<blahdeblah> OK - that's done
 * blahdeblah starts writing an update for the bug report
<axw> blahdeblah: thanks for that
<blahdeblah> axw: So, where to next with this?  The agents have gone straight back to spamming the controller's logs...
<blahdeblah> lots of these: unit-ntpmaster-5[2554]: 2016-11-23 00:58:53 INFO juju.worker.dependency engine.go:351 "uniter" manifold worker stopped: dependency not available
<blahdeblah> and these:
<blahdeblah> unit-nrpe-6[2568]: 2016-11-23 00:59:20 DEBUG juju.worker.dependency engine.go:301 starting "uniter" manifold worker
<blahdeblah> unit-nrpe-6[2568]: 2016-11-23 00:59:20 DEBUG juju.worker.dependency engine.go:268 "uniter" manifold requested "agent" resource
<blahdeblah> axw: And we're straight back to previous load & network traffic levels
<blahdeblah> RAM still creeping up
<axw> blahdeblah: are there errors in the log? about lease manager not being available or whatever it is
<thumper> FAIL: pinger_test.go:104: pingerSuite.TestAgentConnectionDelaysShutdownWithPing
<thumper> seriously?
<thumper> this test is still failing?
<thumper> FFS
<menn0> thumper: yep... I thought I had it licked but not
<anastasiamac> thumper: menn0: funny how it's not on my hit list of intemittents that block promotion from develop to staging..
<anastasiamac> thumper: menn0: do u have time to pick it up?
<thumper> dealing with migration stuff right now
<menn0> anastasiamac: ditto... I'm not supposed to pick up anything else
<anastasiamac> awesome \o/
<blahdeblah> axw: Sorry - missed that message earlier.  Should the messages be of type ERROR?
<axw> blahdeblah: yes
<axw> blahdeblah: in the agent logs
<blahdeblah> axw: not machine 0?
<axw> blahdeblah: there might be some in there too, but the errors I'm thinking of are the cause of the (non-controller) agent restarts
<menn0> wallyworld: review done
<wallyworld> tyvm
<blahdeblah> axw: no sign of any errors to do with lease manager
<axw> blahdeblah: hmm, ok. no errors at all in the agents, suggesting they're restarting?
<blahdeblah> axw: only the ones relating to the connection going down when I blocked traffic
<blahdeblah> you want me to collect full logs from machine 0 for you?
<axw> blahdeblah: yeah wouldn't hurt, thanks
<anastasiamac> thumper: i wonder what the magic incantation is - still can't reproduce it after 520 runs under stress
<thumper> menn0: https://github.com/juju/juju/pull/6597 easy one
<menn0> thumper: looking
<menn0> thumper: QA steps?
<thumper> run the tests
<thumper> I made sure it failed first
<menn0> thumper: ok fine
<menn0> thumper: how serious is the problem that's being fixed?
<menn0> seems problematic
<thumper> menn0: migrations will fail
<thumper> if anyone has ever removed a unit that had an action
<thumper> as the cleanups needs to be empty for the model
<thumper> also, data just hangs around
<thumper> plan on backporting to the 2.0 branch...
<menn0> thumper: glad you found it now then
<thumper> well
<thumper> are we going to do another 2.0 release?
<menn0> nfi
<menn0> thumper: ship it
<thumper> menn0: found it as part of the b7 upgrade
<thumper> as horrible as that work has been, found many issues
<anastasiamac> thumper: another 2.0.x release mayb a possibility -it's on a per-need basis..
<anastasiamac> thumper: original plan is to support 2.0.x until feb
<wallyworld> menn0: tech board?
<menn0> wallyworld: just when I was actually starting to make some progress today...
<wallyworld> yeah, always the way
<macgreagoir> voidspace frobware: I've a couple of IPv6-related PRs in, if you have a minute. Both required for the next juju PR.
<macgreagoir> https://github.com/juju/testing/pull/117
<macgreagoir> https://github.com/juju/replicaset/pull/3
<macgreagoir> Both simple too.
<jam> frobware: ping
<jam> just wondering what you discovered WRT the bridge script in your testing yesterdoy
<jam> macgreagoir: just to mention, you can ping me as well now. :)
<macgreagoir> jam: Of course :-) cheers.
<frobware> jam: well, one thing is that if there's nothing to do we still run ifupdown - which was fine before, but not now.
<frobware> jam: was offline - powercut
<jam> frobware: good catch
<jam> good thing you're using 4g everywhere, right? :)
<jam> macgreagoir: reviewing
<frobware> jam: I got sidetracked by landing https://github.com/juju/juju/pull/6599
<frobware> jam: we will need the script to be present from now on so it seemed prudent to make that so...
<jam> sure, though maybe we should just trigger writing it from jujud itself? given we have a copy inside the jujud binary
<frobware> jam: can do. baby steps.
<jam> :)
<jam> I also wonder if we ultimately want it as a python script if we are moving to doing it ourselves. It made sense when it was driven by cloud-init. Stuff to consider, at least.
<frobware> jam: I got a little annoyed it wasn't on there during my testing.
<frobware> jam: yes, something I had considered too.
<frobware> jam: as it stands now, it will work for dynamic and our current static bridging.
<macgreagoir> frobware: replicaset comments amended.
<jam> macgreagoir: commented.
<frobware> macgreagoir: was still looking at this
<frobware> macgreagoir: reviewed both
<frobware> jam, macgreagoir, voidspace: PTAL @ https://github.com/juju/juju/pull/6599
<frobware> it seems the pre-flight PR checks are failing
<frobware> take a look at: http://juju-ci.vapour.ws/job/github-check-merge-juju/268/artifact/artifacts/trusty-err.log
<frobware> scripts/setup-lxd.sh: line 10: lxd: command not found
<voidspace> rick_h: grabbing coffee will be 2 mins late to first standup
<rick_h> voidspace: rgr
<jam> mgz: http://juju-ci.vapour.ws/job/github-check-merge-juju/268/ is that just out-of-disk space error?
<jam> lxd-out.log at least has: "Failed to copy file. Source: /var/lib/jenkins/cloud-city/jes-homes/merge-juju-lxd/models/cache.yaml Destination: /var/lib/jenkins/workspace/github-check-merge-juju@2/artifacts/lxd/controller"
<jam> and why does http://juju-ci.vapour.ws/job/github-check-merge-juju/268/artifact/artifacts/trusty-out.log have "17.04,Angsty Antelope,angsty,2016-10-23,2017-04-30,2018-01-29 "
<jam> ++ lxd --version
<jam> scripts/setup-lxd.sh: line 10: lxd: command not found
<jam> seems fishy
<perrito666> hey jam are you on our tz this week? or just working incredibly late?
<jam> perrito666: it is just hitting 5pm here.
<jam> I'm UTC+4, so not *that* far away from your TZ, just not very close.
<perrito666> its 7hs, it far enough
<perrito666> also I forgot it was morning here :p
<mgz> jam: the Angsty thing is a hack to make sure distro-info behaves
<perrito666> I might be needing vacations
<jam> perrito666: when you start mixing up day and night...
<jam> mgz: k, just thinking that since it is labeled 17.04 it will become wrong pretty soon.
<perrito666> jam: just morning and afgernoon, to be fair 10AM and 8PM are not really different around here
<jam> perrito666: more drinking at 10am?
<perrito666> I wont admit nor deny that
<jam> mgz: so I think the final thing is that trusty somehow is missing LXD, (not installed from trusty-backports?)
<mgz> jam: the thing is, it works a portion of the time
<mgz> and the script isn't changing
<mgz> so I don't at a glance know what's up
<mgz> someone just needs to spend some time to debug it, happens enough that it really needs resolving
<mgz> I'll see if there's a bug already
<jam> mgz: I don't see anything in http://juju-ci.vapour.ws/job/github-check-merge-juju/268/artifact/artifacts/trusty-out.log that indicates it is installing lxd
<jam> is it doing something like accidentally using the Xenial script where lxd is preinstalled ?
 * mgz finds a passing one to compare
<jam> mgz: also, looking at the apt-update HTTP list, I don't see trusty-backports in there
<jam> trusty and trusty-updates, but not trusty-backport
<jam> mgz: I remember there were some issues with particular Trusty MAAS images that didn't have trusty-backports enabled by default, which differed from CPC images
<mgz> ha, a passing one also fails there
<mgz> but exits 0
<jam> mgz: so passing is because it failed-to-fail ?
<mgz> see 267
<mgz> no, it ran the tests, by the trusty-out.log and they pass
<jam> mgz: yeah, I see the "lxd not found" line.
<mgz> so, the fatal error is actually the "Connection to ...amazonaws.com closed by remote host."
<mgz> I don't see a bug, so will file one.
<mgz> atm check job history is mostly red, and I suspect that's largely spurious
<jam> frobware: commented on https://github.com/juju/juju/pull/6599
<voidspace> every time the SSO two factor login annoys me, I remember I implemented it...
<voidspace> dammit
<mgz> voidspace: aha! does this mean we can all come to you with complaints? :)
<voidspace> mgz: haha, I'm not on that team any more
<voidspace> mgz: but feel free to complain, sure
<gnuoy> do juju 1.X and 2.X both use the same version of goose ?
<voidspace> mgz: ^^^^
<voidspace> gnuoy: I doubt it
<voidspace> gnuoy: different revisions of goose.v1
<gnuoy> voidspace, hmm, ok, ta
<voidspace> gnuoy: http://pastebin.ubuntu.com/23522141/
<voidspace> gnuoy: 2.0 is on a 2016-11 revision
<voidspace> gnuoy: 1.25 a 2015-11 revision
<gnuoy> voidspace, ok thanks, thats v. helpful
<mgz> gnuoy: nope
 * mgz was late
<mgz> gnuoy: we can bug fix goose for 1.25 if needed though
<mgz> but it notably isn't going to have the new neutron stuff
<gnuoy> mgz, I think the bug impacts both tbh but I've only confirmed on 1.X
<gnuoy> mgz, the new neutron stuff has landeD ?
<mgz> gnuoy: yes, I've delayed sending out announcement as there was some fallout to handle
<mgz> but will do so.
<voidspace> rick_h: I'm out of bourbon, can you bring me a nice bottle to Barcelona and I'll recompense you there... (pretty please :-)
<voidspace> rick_h: if you can remember and be bothered of course...
<rick_h> Voidspace hah, what is your preferred one?
<voidspace> rick_h: any reasonable kentucky bourbon will be fine, I'm no expert
<voidspace> rick_h: the one I've just finished that I liked
<voidspace> rick_h: was bulleit (or something like that)
<voidspace> rick_h: scotch is too rough for me, but you Americans can make nice whisky
<frobware> jam: there is a wrapper around the bridge script which invokes it at its new location
<frobware> jam: that wrapper always existed. It looks to see what version of python is available, and whether all interfaces should be bridged.
<frobware> jam: and then runs: /path/to/python /path/to/the/bridge/script.py
<gnuoy> mgz, fwiw https://bugs.launchpad.net/juju/+bug/1625624/comments/7
<mup> Bug #1625624: juju 2 doesn't remove openstack security groups <ci> <landscape> <openstack-provider> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1625624>
<voidspace> rick_h: and if there's anything I can bring from the UK just let me know, scotch, marmite, scottish shortbread....
<mgz> gnuoy: thanks, having a look
<frobware> note bug 1643057 was fixed in MAAS 2.1.2
<mup> Bug #1643057: juju2 with maas 2.1.1 LXD containers get wrong ip addresses <cdo-qa-blocker> <landscape> <juju:Invalid> <MAAS:Fix Committed by mpontillo> <MAAS 1.9:Won't Fix> <MAAS 2.0:Won't Fix> <MAAS 2.1:Fix Released by mpontillo> <https://launchpad.net/bugs/1643057>
<mgz> gnuoy: do you know if this is tied to a particular openstack version?
<mgz> because goose hasn't changed the underlying http handling in a long time I believe
<gnuoy> mgz, that is an excellent question. I believe this broke for us when we went to Mitaka
<mgz> gnuoy: that sounds very likely
<mgz> most of our CI testing is against older (much older) versions
<balloons> ahh frobware, you need to look at http://juju-ci.vapour.ws/job/github-check-merge-juju/269/artifact/artifacts/trusty-out.log/*view*/. You have unit test failures. Everything else is noise
<frobware> balloons: heh, none of these seem to be related to what I changed.
<mgz> balloons: 268 is the one to look at. it either dced after build or something else similar.
<mgz> 269 is perrito666's
<mgz> (which does have real unit test failures)
<mup> Bug #1625624 opened: juju 2 doesn't remove openstack security groups <ci> <landscape> <openstack-provider> <juju:Triaged by alexis-bruemmer> <juju 2.0:Triaged> <juju-core:Triaged> <https://launchpad.net/bugs/1625624>
<katco> natefinch: on that branch; not shown: i have to land the CallMocker type into juju/testing
<natefinch> katco: ahh, thanks, that would be a key piece :)
<katco> natefinch: yeah sorry i just ran out of time last night
<katco> natefinch: you can see what it looks like because it's removed from deploy_test.go
<katco> natefinch: but doesn't build atm. feel free to wait on review if you like
<katco> natefinch: i will endeavor to get that landed around lunch
<natefinch> katco: I can start the review now, that's no problem
<natefinch> wow that call mocker adds a lot of complexity
<katco> natefinch: going into a meeting, but would appreciate more thoughts on that
<perrito666> mgz: ??
<perrito666> mgz: I dont have a merge in progress
<mgz> perrito666: the check on pr #6564
<perrito666> mgz: ah yes, I know
<mup> Bug #1644333 opened: !amd64 controller on MAAS cloud requires constraints <juju-core:New> <https://launchpad.net/bugs/1644333>
<babbageclunk> hey menn0
<menn0> babbageclunk: howdy
<babbageclunk> so my logtransfer stuff is failing because the migrationmaster worker is connecting as a machine agent but the debuglog endpoint expects a user.
<katco> menn0: hey, curious what you think of this https://github.com/juju/testing/pull/118/files in relation to this https://github.com/juju/juju/pull/6598/files
<babbageclunk> menn0: I guess I should add another httpContext authentication method that has an authfunc for any one of machine/unit/user?
<menn0> babbageclunk: well just machine+user would be enough right?
<babbageclunk> menn0: oh, right
<menn0> katco: i'll take a look shortly
<katco> menn0: no rush, ta
<babbageclunk> menn0: I was going to use stateForRequestAuthenticated, but that doesn't check permissions
<menn0> babbageclunk: but yes that seems ok. there's not much danger in opening up that endpoint to machines
<babbageclunk> menn0: Ok, thanks, I'll do that. Tempted to do it as a function that accepts the tag kinds and rework the others in the same way.
<menn0> babbageclunk: that could be nice as long as it's not too big a change
<menn0> babbageclunk: i.e. don't get too distracted
<babbageclunk> menn0: No, it's simple.
<menn0> babbageclunk: cool, then go for it
<babbageclunk> menn0: I'm so close to getting this working I can taste it!
<menn0> babbageclunk: what does it taste like? :)
<babbageclunk> menn0: it tastes like... victory
<perrito666> babbageclunk: for a moment I thought we where still talking about what came out of your keyboard :p
<babbageclunk> perrito666: ugh, who put all this cat hair on my keyboard!?
<babbageclunk> perrito666: never clean anything, it only leads to heartache
<thumper> anyone else noticed a plethora of ERRORs now being written to the logs like this:  11:17:30 ERROR juju.rpc error writing response: write tcp 127.0.0.1:17070->127.0.0.1:52408: write: connection reset by peer
<thumper> normally about 10 at a time
<babbageclunk> thumper: yeah, I think I've seen those - I didn't realise they were new though
<babbageclunk> axw, thumper, menn0: can someone take a look at this? https://github.com/juju/juju/pull/6606
<menn0> katco: I like the approach. i've added a bunch of suggestions let's get that in.
<menn0> babbageclunk: looking
<thumper> menn0: oh fuck...
 * menn0 cringes
<thumper> menn0: I've just hit something quite interesting
<thumper> quick HO to discuss?
 * menn0 doesn't like interesting
<menn0> thumper: no :)
<thumper> :(
 * menn0 buries head in sand
<menn0> thumper: see you in 1:1
<thumper> ack
<thumper> machine-0: 12:01:20 ERROR juju.worker.migrationmaster:9097b3 source prechecks failed: unit ubuntu/0 not idle (failed)
<babbageclunk> thumper: ping?
<thumper> babbageclunk: hey
<babbageclunk> thumper: my migration master's getting an error when connecting to the logtransfer endpoint - the target model isn't importing (since it's already at success).
<thumper> ah...
<babbageclunk> thumper: how do you think I should handle that - another phase?
<thumper> what comes after success?
<babbageclunk> thumper: ...profit?
<thumper> heh
<menn0> thumper, babbageclunk: SUCCESS -> LOGTRANSFER
<babbageclunk> menn0: but is the target model in that state?
<thumper> I think perhaps the method should take the expected import state
<thumper> stateForMigration should take an expected state
 * menn0 agrees with thumper
<thumper> and check against that
<thumper> rather than just assuming importing
<menn0> the logtransfer endpoint should only work if the migration state is "none"
<babbageclunk> thumper, menn0 - yeah, makes sense. In this case that's MigrationModeNone
<menn0> (that's not the exact name)
<thumper> why is the state none?
<babbageclunk> ok, thanks chaps - doing that now
<thumper> if it is still migrating?
<babbageclunk> menn0: ^
<thumper> menn0: FYI, the precheck is failing because the machine instance status is "started" not "running"
<menn0> thumper: ok cool .. easy to fix then
<thumper> I'm looking at what full status is looking at
 * thumper is still digging
<menn0> thumper: fullstatus should be using the same thing to generate the status but perhaps it's the interpretation of the status
<thumper> yeah, that's what I'm checking
<menn0> babbageclunk: review done. looks great.
<babbageclunk> menn0: thanks!
<axw> mgz: thanks for the review, PTAL at my response when you have a moment
<perrito666> axw: wallyworld I need to skip standup sorry ill update you guys upon return
<perrito666> axw: good catch with region check
<axw> perrito666: ok, ttyl
<axw> perrito666: BTW see validateCloudRegion in state/model.go for one place we're doing validation of region. I think we just want to copy that logic into environs.MakeCloudSpec
<axw> we're validating when we *do* pass a region, but not when we don't
<thumper> menn0: status always shows "started" never "running"
 * thumper sighs
<thumper> apiserver converts running -> started somewhere
 * thumper still digging
<menn0> thumper: i'll show you where after the standup
<thumper> ok
<wallyworld> perrito666: standup?
<thumper> menn0: fyi https://bugs.launchpad.net/juju/+bug/1620438
<mup> Bug #1620438: model-migration pre-checks failed to catch issue: not idle <ci> <intermittent-failure> <regression> <juju:Triaged by menno.smits> <https://launchpad.net/bugs/1620438>
<mup> Bug #1640521 changed: Unable to deploy Windows 2012 R2 on AWS <juju-core:Won't Fix> <https://launchpad.net/bugs/1640521>
<mup> Bug #1644333 changed: !amd64 controller on MAAS cloud requires constraints <juju:New> <https://launchpad.net/bugs/1644333>
#juju-dev 2016-11-24
 * babbageclunk goes for a run, bye!
 * babbageclunk comes back, just want to $$merge$$ that PR first
<katco> menn0: thanks for the feedback. i responded to a few of your comments and i'm implementing the others
 * babbageclunk is actually foing for a run now.
 * babbageclunk gah, going
<anastasiamac> axw: as an OCR, there is also this PR that's worth looking at :D https://github.com/juju/juju/pull/6563
<menn0> katco: looks good. i've approved the pr.
<katco> menn0: ta
<mup> Bug #1468752 opened: "juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode <ssh> <windows> <juju:In Progress by gz> <juju 2.1:In Progress by gz> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1468752>
<anastasiamac> wallyworld: u r off the hook - all is good in the land :)
<wallyworld> yay
<anastasiamac> menn0: ping me when u want a break from migrations (not in the next 30mins tho)
<menn0> anastasiamac: ok
<thumper> menn0: you'd think that finding this would be easy...
 * thumper grumbles
<menn0> anastasiamac: now?
<menn0> babbageclunk: your last merged PR was perfect timing. I needed exactly the changes you made for something I'm doing.
<anastasiamac> oh menn0'
<anastasiamac> i mean 'ok menn0'... h is the new k, right?
<anastasiamac> ho or irc?
<menn0> anastasiamac: HO is probably more efficient
<babbageclunk> menn0: :)
<menn0> anastasiamac: just noticed this: https://github.com/natefinch/lumberjack/pull/16
<menn0> anastasiamac: someone already has a PR up that does gzip compression on rotation
<menn0> seems like it's close to ready
<anastasiamac> menn0: \o/ this will make asking Nate nicely even easier :D
<menn0> anastasiamac: and it will give him permission to work on it during work hours
<anastasiamac> axw: this one does not seem to be transacation related... https://bugs.launchpad.net/juju/+bug/1644396
<mup> Bug #1644396: machine-0 takes up massive memory, slows down to unusable, "upgrade in progress" loops <juju:New> <https://launchpad.net/bugs/1644396>
<anastasiamac> transaction* (who needs to type today?)
<axw> anastasiamac: interesting. I don't have time to look into it atm, doing OCR
<babbageclunk> thumper, menn0: Should I be deleting logs for the migrated model from the source controller after the transfer is complete?
<thumper> babbageclunk: I'd say yes
<thumper> menn0: ?
<babbageclunk> migrating back and forth between two controllers, now I've got quite a lot of logs.
<menn0> babbageclunk: yes I think so
<menn0> otherwise they'll never go away
<menn0> babbageclunk: in fact, that should be part of the REAP phase
<wallyworld> anastasiamac: i cannot reporduce any "unknown remoteApplications collection" errors. The only bug I can see refers to the cmr feature branch which has been obsolete for some time now. Do you have any recent occurrences?
<anastasiamac> wallyworld: let me have a look at CI logs.. this were i saw them yesterday :)
<anastasiamac> wallyworld: it's behind feature flag on both 2.0 and develop, right?
<wallyworld> always has been :-)
<wallyworld> unless i missed a place
<wallyworld> but i diffed 2.0 and develop
<anastasiamac> wallyworld: k.. i'll ping u if i find anything :) pretend everything is awesome for now... \o/
<wallyworld> ok
<wallyworld> i couldn't see anything
<anastasiamac> wallyworld: so... in the latest develop run, http://reports.vapour.ws/releases/4591, go to first failure - azure - http://reports.vapour.ws/releases/4591/job/azure-arm-native-deploy-bundle/attempt/1017
<anastasiamac> wallyworld: under artifcats, open up controller/machine-0/machine-0.log.gz
<anastasiamac> wallyworld: lines from 1447 :)
<jam> menn0: are you still able to meet today?
<wallyworld> axw: i've not used the new worker catacomb before - i didn't know about Plan.Init. but that makes it much easier
<axw> wallyworld: cool
<axw> wallyworld: catacomb makes this particular worker a whole lot easier to write in general
<wallyworld> axw: even though i wasn't using Init, the logic resulted in te same thing but the code was clumsy
<natefinch> menn0, anastasiamac: just saw your ping about log compression
<wallyworld> yeah, the catacomb is nice
<axw> wallyworld: not quite, because if Invoke failed, you weren't killing the watcher (unless I missed something)
<wallyworld> axw: the invoke could only fail if things were not properly set up. and those same failures would not see the init thngs registred either
<axw> wallyworld: Invoke *always* kills the Init workers, regardless of how it fails. see the defer at the top of Invoke
<wallyworld> oh, so it does
<wallyworld> axw: testing the sub worker wait errors will be a pita since there's no easy way right now to override the Wait() methods
<wallyworld> i could override the new() methods in export test and use a shim where i control the error
<wallyworld> or go all the way and pass in the new methods via the worker config
<wallyworld> or i could ignore for now
<axw> wallyworld: that doesn't sound quite right. I think you should have ObserveRelationUnitsChange return an error; trigger a RU change; trigger a relation change, and arrange for it to be NotFound
<axw> wallyworld: that would cause it to try and stop the RUW, at which point it'll get the error that ObserveRelationUnitsChange returned
<wallyworld> axw: aren't we talking about the worker.Stop() errors being propagated?
<wallyworld> they are the ones i was ignoring
<wallyworld> i can also add that other scenario
<axw> wallyworld: if you cause the RUW to fail atm (e.g. by having Observe... return an error), what happens to the remote application worker?
<wallyworld> it should exist with that error, but there's no test for that, i'll add one
<wallyworld> *exit
<wallyworld> axw: i've pushed some changes to fix some races, should be good now i think
<axw> wallyworld: ok, looking
<wallyworld> axw: thanks for review. so many pieces to this cmr puzzle. will be several more prs yet
<wallyworld> axw: i have a one liner as well https://github.com/juju/juju/pull/6610
<anastasiamac> axw: i have a small but volatile one too :-P ... yes, wallyworld :) https://github.com/juju/juju/pull/6422
<axw> anastasiamac: reviewed
<frobware> axw: thanks for the review comments
<anastasiamac> axw: thnx \o/
<SimonKLB> would it be out of the question to allow some kind of generic relation where the only thing youre really interested in is the name of the other charm you add the relation to? a relation that didnt require an interface that is
<macgreagoir> jam frobware voidspace: Any need for the regular juju-core-team HO?
<jam> macgreagoir: given Turkey day, I'd guess not many will show, thoughts?
<macgreagoir> Likely just the same people as the stand-up later. I say can it.
<jam> macgreagoir: nobody is there right now, at least.
<jam> just me
<macgreagoir> I just left :-)
<anastasiamac> axw: add-model help PR updated.. :)
<jam> frobware: I need to grab some food, but I'll join the hangout in a moment.
<frobware> jam: np
<jam> I ended up doing back-to-back meetings today and haven't carved out food time yet.
<axw> anastasiamac: thanks, your wording on name uniqueness is very clear
<jam> frobware: I'm joining the hangout now
<anastasiamac> axw: \o/ made my day! m going to land it ;)
<anastasiamac> axw: (especially since it's ur wording all the way!) :D
 * perrito666 just realizes that today is a holiday in the US
<mup> Bug #1644566 opened: juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22" <amd64> <apport-bug> <zesty> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1644566>
<mattyw> evilnickveitch, it's there, many thanks
<mup> Bug #1644566 changed: juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22" <amd64> <apport-bug> <zesty> <juju-core:Invalid> <golang (Ubuntu):New for mwhudson> <juju-core (Ubuntu):Invalid> <lxd (Ubuntu):Invalid> <https://launchpad.net/bugs/1644566>
<babbageclunk> hey menn0, I proved to myself that mongo's sort isn't stable, quelle surprise. Do  you think it would be feasible to add _id to the model,time index?
<menn0> babbageclunk: so make the index model,time,_id?
<babbageclunk> yeah
<menn0> that should be fine
<menn0> queries that use model,time will still take advantage of the index
<babbageclunk> menn0: I'm just making a test to show the problem and then I'll try that.
<babbageclunk> menn0: quick review? https://github.com/juju/juju/pull/6612/files
<menn0> babbageclunk: give me 5 mins
<babbageclunk> menn0: no rush
<babbageclunk> menn0: I meant quick in the sense that it should be straightforward, not "hey do this quickly"! :)
<menn0> babbageclunk: got it :)
<menn0> babbageclunk: your change looks great but something needs to remove the previous index
<menn0> babbageclunk: the correct way to do that is to add an upgrade step
<menn0> babbageclunk: have you done one before? I can guide you through it.
<babbageclunk> menn0: No, I haven't
<menn0> babbageclunk: quick HO?
<babbageclunk> menn0: Sure
<babbageclunk> menn0: https://hangouts.google.com/hangouts/_/canonical.com/menno
<blahdeblah> Anyone around to give some quick advice/explanation on how relation scoping works in juju 1.x?  Here's my environment: https://pastebin.canonical.com/171809/
<blahdeblah> The canonical-livepatch charm has an nrpe-external-master relation which allows it to relate to nrpe.  However, there are two nrpes in the environment with different service names.
<blahdeblah> I've found relating it to both doesn't work; do I need two separate canonical-livepatch services to make that happen?
<menn0> blahdeblah: let me dig into that for you
<blahdeblah> menn0: thanks; I'm guessing this is something to do with relation scopes, which is an area that I've always found a bit head-scratchy
<menn0> blahdeblah: you're not the only one :)
<blahdeblah> I'm glad. :-)
 * blahdeblah goes to re-read charm author doc on that stuff
<menn0> blahdeblah: when you say "relating it to both doesn't work", is Juju giving you an error or the relation doesn't do what you expect?
<blahdeblah> it just never seems to build the relation
<blahdeblah> No errors or anything; it's just that nothing seems to happen in debug-log
<menn0> blahdeblah: so in your environment what is canonical-livepatch subordinate to?
<blahdeblah> the main primary charm
<blahdeblah> but we need to add the relation to the nrpe charm so that canonical-livepatch produces a nagios check which we can monitor
<blahdeblah> I've looked at the source of both charms, and they're both set to use container scope for the nrpe-external-master relation, which is correct from my reading of the documentation.
 * menn0 looks at the code
<menn0> blahdeblah: actually, i've got a standup now... back in a bit
<blahdeblah> no worries - thanks anyway
#juju-dev 2016-11-25
<blahdeblah> I've been digging some more, and I don't think this is a problem with juju or relation scopes; I think it's just a bug with reactive states not firing.
<menn0> blahdeblah: ah ok. i've asked around in our standup and the general thinking was that what you're trying should work
<menn0> blahdeblah: and certainly if it isn't supported and juju isn't giving you an error then that's a bug
<blahdeblah> menn0: yeah - I think this is a charm or layer bug
<menn0> blahdeblah: ok well let me know if you want me to look further
<blahdeblah> The hooks are definitely firing
<blahdeblah> all good - thanks for the help
<blahdeblah> menn0: Although if you know anyone around who understands the ins & outs of https://jujucharms.com/docs/2.0/developer-layers-interfaces, please point me to them. :-)
<blahdeblah> Ecosystem channel is dead quiet in APAC times.
<blahdeblah> esp. with US holidays on
<menn0> blahdeblah: I don't think there's any layers experts here atm
<menn0> blahdeblah: the eco team are definitely your best bet
<blahdeblah> menn0: Yeah - this might end up having to wait until next week.  AFAICT, though, the scopes referred to in the above link don't have anything to do with juju relation scopes as defined in metadata.yaml.  I could be wrong, though.
<anastasiamac> axw: forgot to mention at standup - i'll b missing monday one :) have fun \o/
<axw> anastasiamac: okey dokey
<anastasiamac> axw: and wednesday one :)
<babbageclunk> menn0: Can you chuck a tick on https://github.com/juju/juju/pull/6612?
<menn0> babbageclunk: done
<menn0> babbageclunk: did you try the upgrade with the index missing?
<menn0> just in case
<babbageclunk> menn0: I mean, I have a test for that case
<babbageclunk> menn0: Ok, trying it on the controller I have running now.
<wallyworld> axw: if you get a chance, here's a small +37/-30 cmr tweak https://github.com/juju/juju/pull/6613
<axw> wallyworld: I don't really understand why you've changed it from token back to ID, we're not supposed to be exposing IDs across controllers
<wallyworld> axw: the next step in the processing will take the local info and 1) export, 2) send to other model
<wallyworld> so instead of exporting relations as a side effect of loading the info, and then exporting units explicitly later
<wallyworld> the exports will all be done together
<wallyworld> exporting as a side effect of RemoreRelations() which is a getter is wrong imo
<axw> wallyworld: don't understand "take the local info ..." implies we're pushing, I thought this was all going to be a pull model? i.e. I watch relations in the remote side, it doesn't push them to me
<wallyworld> quick ho?
<axw> sure, see you in 1:1
<babbageclunk> menn0: So I tried it with the index dropped and it gives an error - apparently the code isn't 0 sometimes. I'll change it to look before leaping instead.
<babbageclunk> menn0: Wow, apparently if you screw up an upgrade step you can really leave the controller pretty hosed.
<menn0> babbageclunk: yeah... there was a rough plan of how we might roll back but that was dropped from scope
<menn0> babbageclunk: hence the need to make sure upgrade steps are really solid
<menn0> babbageclunk: in fact, do you have a unit test which runs the upgrade step twice
<menn0> babbageclunk: that's pretty standard ... to help ensure they are idempotent
<menn0> babbageclunk: would have caught this
<babbageclunk> menn0: I have a test that checks this, although not running it twice, just running it with the index already not existing. It seems like the error code changes for some reason, although the message doesn't.
<babbageclunk> menn0: I'll add another call to the upgrade function test just to be extra sure.
<menn0> sweet
 * menn0 is DONE
<menn0> after several super long days this week I'm toast
<menn0> have a good weekend all
<axw> wallyworld: havent gone anywhere yet :)  lgtm
<wallyworld> axw: awesome ty
<voidspace> macgreagoir: the standup idea was fine
<voidspace> macgreagoir: what are we doing instead?
<voidspace> macgreagoir: I'm still half dead with exhaustion (poorly kid), but working today...
<macgreagoir> voidspace: I'm easy, if ngz and frobware are about at 11 to have stand-up earlier. Otherwise,  I guess stick with the usual.
<macgreagoir> *mgz
<macgreagoir> voidspace: Sick child is no fun! :-/
<mgz> macgreagoir: yeah, I'm fine with 11
<macgreagoir> voidspace mgz: Cool, let's see if frobware can make 11 and take it from there.
<voidspace> mgz: macgreagoir: cool
<voidspace> macgreagoir: yeah, the lad is fine - but he has croup and a chest infection, so his sleep (and therefore ours) is very interrupted
<voidspace> he's a bit better today and by the end of the weekend he'll be fine
<macgreagoir> voidspace: Good luck. You have my sympathy.
<voidspace> macgreagoir: thanks
<macgreagoir> voidspace frobware HO?
<voidspace> macgreagoir: omw
<kjackal> Hey just noticed something with the "juju register" command. It does not add the password field inside the ~/.local/..../accounts.yaml . is this intentional?
<perrito666> morning all
<perrito666> voidspace: sorry to botter, would you mind reviewing https://github.com/juju/juju/pull/6617 and https://github.com/go-goose/goose/pull/34/files they are rather urgent
<macgreagoir> mgz: I see some new goose-related PRs are in.
<voidspace> perrito666: looking
<voidspace> perrito666: 6617 looks fine
<voidspace> perrito666: has it been verified that it fixes the issue (no QA steps in PR)?
<voidspace> perrito666: if it has been actually tried and we know it works I will LGTM it
<voidspace> mgz: could you take a look at https://github.com/go-goose/goose/pull/34/files
<voidspace> mgz: I don't feel qualified.
<macgreagoir> mgz: fnordahl's juju change lgtm. I'll let you look at the go-goose change (seems OK too, at first glance).
<perrito666> voidspace:
<voidspace> perrito666
<perrito666> I believe you are in cc on the mail where the guy sent the patch
<voidspace> perrito666: I can't easily find it if I am
<voidspace> perrito666: what's the title?
<voidspace> perrito666: I've added my LGTM on the proviso that we know it works
<voidspace> perrito666: I think mgz needs to review the goose PR
<perrito666> sorry I was afk
<perrito666> voidspace: "broken openstack deployment"
<mattyw> hey folks, does anyone know of a reason we might get an error calling the is-leader tool? (https://github.com/juju/juju/blob/juju-1.24.7/worker/uniter/runner/jujuc/is-leader.go#L47)
<mgz> I approved the goose pr.
<macgreagoir> mgz: I had a couple of comments in the PR, but no show-stoppers.
<mgz> yeah, I saw
<Mmike> marcoceppi, 1.25.8 is still not in the archives - sorry to bother you like this, but customers.... :/
<frobware> macgreagoir, voidspace, jam: PTAL @ https://github.com/juju/juju/pull/6618
<voidspace> frobware: tal
<frankban> hey wallyworld, or anyone: how can I specify to always use local jujud as the agent when bootstrapping? AFAICT from reading the code, --build-agent always builds the agent, and I don't want simplestreams tools in the server for my usecase
<frobware> looks like the build bots are out of RAM - /usr/lib/go-1.6/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
<voidspace> frankban: I've had to force it by putting a fake version in place
<mgz> frobware: what job, more specifically?
<frobware> mgz: http://juju-ci.vapour.ws/job/github-check-merge-juju/296/console
<mgz> okay, so probably not cleaning up lxd containers still and no one's been around to manually delete them
<frobware> macgreagoir, voidspace, jam: PTAL @ https://github.com/juju/juju/pull/6619
<voidspace> frobware: 6618 LGTM
<frobware> voidspace: ty
<voidspace> frobware: what are the additional print statements for in 6619?
<frobware> voidspace: they print to memory files. I then compare and if the nett result of all the stanzas is the same before bridging, then we don't do anything.
<voidspace> frobware: ah!
<voidspace> frobware: cool, LGTM
<frobware> voidspace: I could have compared data structures, but that seemed messier and more involved.
<voidspace> frobware: no test for this?
<frobware> voidspace: there are already tests - but those tests don't test beyond --activate (that calls ifdown/up)
<voidspace> frobware: so you think this change is untestable?
<mgz> frobware: http://paste.ubuntu.com/23532856
<frobware> voidspace: for each input sample we have we already call the script, then call the script again verifying it is idempotent.
<voidspace> frobware: but that will be true both before and after this change
<frobware> voidspace: https://github.com/juju/juju/blob/staging/provider/maas/bridgescript_test.go#L130
<voidspace> frobware: so it doesn't test the exit call
<frobware> voidspace: that should have been line #138
<frobware> voidspace: nope
<voidspace> frobware: if you think it isn't reasonably  possible to test then fine
<voidspace> so long as we've thought about it
<voidspace> frobware: I've added a reluctant LGTM ;-)
<frobware> voidspace: the problem is, once you get to this part of the code, it calls ifdown/ifup,brtcl,et al and needs to run as root. We could mock all that, but ... ?
<voidspace> frobware: yeah, that's a horrible road to go down
<frobware> voidspace: IMO, nothing would be gained from mocking those.
<frobware> voidspace: I'm open to moving the cur/new comparison to before those calls.
<voidspace> yep
<frobware> voidspace: mocking perfectly behaving bonded interfaces... nah!
<mgz> frobware: okay, manually deleted all those, 12G mem free again, feel free to retrigger check
<frobware> mgz: retrigger is just !!retry!! ?
<voidspace> frobware: if you can think of a way to make it testable, then great - but don't burn too much time on it
<mgz> frobware: yup
<frobware> voidspace: I think one problem we have is sepration of concerns: the bridge script should just do the transformation. something else should invoke the $necessary.
<voidspace> frobware: yep, that sounds better
<frobware> voidspace: http://pastebin.ubuntu.com/23532923/
<voidspace> frobware: I think I'm being dumb, how does that help us?
<voidspace> frobware: it means there's no output at all for nil changes
<voidspace> frobware: so we can now test that?
<frobware> voidspace: the unit tests never pass --activate
<frobware> voidspace: you'd be disappointed if they did.
<voidspace> frobware: so they weren't getting that far
<frobware> voidspace: nope, hence why I stuck this after the case where the unit tests never deal with
<voidspace> cool
<frobware> voidspace: so A or B?
<voidspace> hah
<frobware> voidspace: Rock and Hard place. :)
<voidspace> frobware: with the latest one, can you add a new test case for the "nil change"?
<frobware> voidspace: nope, because we never want activate.
<voidspace> oh, I see - we'll still exit either way
<voidspace> in which case it makes no difference
<voidspace> not really
<voidspace> frobware: go with what's in the PR
<frobware> voidspace: right. what we have now only happens at runtime (as opposed to unit test time)
<frobware> voidspace: I would agree that we're not testing this case. But I think the bigger / better change is to split the functionality up as suggested ^^
<voidspace> frobware: yep
<frankban> voidspace: fake version in place?
<voidspace> frankban: I change the version number of juju so that it can't possibly match anything in simplestreams
<voidspace> frankban: this forces juju to upload the jujud I provide
<voidspace> frankban: I'm currently using 2.3.0
<frankban> voidspace: I see, so juju bootstrap --agent-version 99.0.0 should work...
<voidspace> frankban: I change the version number in version.go and recompile
<voidspace> frankban: I'm not aware of a command line invocation that will work
<voidspace> frankban: just because I'm not aware of it doesn't mean there isn't one though
<frankban> voidspace: ok, sounds good, ty
<voidspace> frankban: it just means I can't help with that, sorry
<frankban> voidspace: you already helped patching versions.go could work in my case
<frobware> mgz: ongoing problems? http://juju-ci.vapour.ws/job/github-check-merge-juju/298/artifact/artifacts/lxd-err.log
<mgz> frobware: >_<
<mgz> this stuff is just not well set up
<mgz> there's disk space as far as I can see, what does that error mean exactly...
<frobware> mgz: so it appears that the container simply doesn't exist??? Is that what I'm seeing from the logs?
<mgz> frobware: I think the implication is the zfs filesystem is screwed
<mgz> but I'm really not sure
<frobware> mgz: why don't we reduce the surface area for things that can go wrong. Let's switch to ufs/ext4. For testing, I care about stability. then speed.
<frobware> mgz: I need to EOD. Apologies for leaving this hanging.
<mgz> though the error on the run after is different
<mgz> I'll restart the box and retry, and leave a note for balloons
#juju-dev 2016-11-26
<bdx> hey anyone around
<bdx> trying to get some insight on this -> http://paste.ubuntu.com/23538994/
<bdx> its a manual provider, 2.0 bootstrapped to trusty
<bdx> ultimate death
<bdx> logsink -> http://paste.ubuntu.com/23539014/
#juju-dev 2016-11-27
<babbageclunk> quiet here today
<anastasiamac> babbageclunk: .. it was :)
<babbageclunk> anastasiamac: sorry for ruining it!
<anastasiamac> babbageclunk: u never would :D
 * menn0 expects a tumbleweed
<menn0> anastasiamac: stand up?
#juju-dev 2017-11-20
<thumper> axw_: ping
<axw_> thumper: gah sorry, overlap with standup
<axw_> thumper: can we make it in 5-10 please?
<thumper> sure
<axw_> wallyworld: last one: https://github.com/juju/juju/pull/8106
<thumper> well... a great day of race conditions and deadlocks
<thumper> https://github.com/juju/juju/pull/8107
<babbageclunk> thumper: stink
<thumper> yeah
<babbageclunk> thumper: oh nasty - so the rate-limiting would start causing the agents to timeout and then what - they go into a never-ending loop trying to connect and timing out?
<thumper> babbageclunk: the apiserver got stuck ratelimiting every agent
<thumper> because the forwarder tried too often
<babbageclunk> thumper: approved
<thumper> laters peeps
<jam> babbageclunk: I looked at 8108
<jam> I don't think we want to refuse any downgrade
<jam> but maybe restrict it within a major.minor series
<jam> the most important thing is to get "juju upgrade-juju" to agree with what the actual Upgrade logic will do.
<wallyworld> axw: if you get a chance later, could you look at https://github.com/juju/juju/pull/8104. the jujud operator branch depends on this one. i've got other stuff to do so  no huge rush
<axw> wallyworld: ok. still working on provisioner stuff, will see how I go
<wallyworld> no worries, it can wait
<jam> axw: reviewed 8109
<babbageclunk> wallyworld: ping?
<wallyworld> babbageclunk: hey
<babbageclunk> wallyworld: sorry chatting to thumper
<wallyworld> ok, np
<babbageclunk> wallyworld: hey, did you see the message from jam above?
<babbageclunk> (off the phone now
<babbageclunk> )
<wallyworld> looking
<babbageclunk> thumper points out that the problem with downgrading is that we don't have inverses for the upgrade steps
<wallyworld> babbageclunk: i haven't looked at your PR yet, but what he says has sound logic
<babbageclunk> Yeah, and it matched a bit with some of the code in the upgrade-juju command. But I think the check in state.checkUpgradeInfoSanity is there because downgrading would require undoing upgrade steps.
<babbageclunk> wallyworld: ^
<wallyworld> i'll need to look at the code
<wallyworld> but in general downgrading has been an issue due to not being able to revserse schema changes etc
<wallyworld> babbageclunk: it looks like that state code refuses any doengrade, right?
<babbageclunk> wallyworld: yeah, it's pretty clear, and it's been like that since the beginning.
<babbageclunk> wallyworld: So that sounds like I probably can't allow downgrades even within the same major.minor.
<babbageclunk> (by since the beginning, I mean, since upgrading was introduced in 2014.)
<wallyworld> babbageclunk: yes, we have never supported downgrading IIANM
<wallyworld> babbageclunk: since that's the case, making the CLI match what the server will do is to me the most important bit, and then we can discuss whether to allow downgrades separately
<babbageclunk> wallyworld: makes sense
<babbageclunk> wallyworld: there are a couple of test failures about trying to do downgrades - it's kind of surprising that they were considered to pass when the sanity check would still fail.
<wallyworld> babbageclunk: you mean the there are CLI tests? that assert we can do downgrades?
<babbageclunk> wallyworld: yeah, one in the apiserver tests for model manager, one in featuretests
<babbageclunk> wallyworld: just looking at them now. Maybe we need to distinguish between allowing downgrades for the controller and hosted models?
<wallyworld> i'd need to look at those, perhaps we should allow minor
<wallyworld> controller versions needs to be > hosted model version
<babbageclunk> That's already checked. But would there be any benefit for downgrading hosted models?
<wallyworld> that's up to the user of thse models
<babbageclunk> wallyworld: it doesn't look like the modelmanager test is actually trying to downgrade - just happens to trip that in setting up the test.
<babbageclunk> wallyworld: but the feature test is trying to do it.
<wallyworld> and the feature test passes? how?
<wallyworld> since there is that state check
<babbageclunk> I mean, it did pass until I broke it.
<wallyworld> but the feature test is meant to be full stack which mean the state check would have been run
<babbageclunk> wallyworld: I presume that means that it wasn't checking that there weren't any errors.
<wallyworld> maybe, not sure without looking
<babbageclunk> wallyworld: hmm, the test is about HA - there's a need for the leader to be able to downgrade if one of the followers can't upgrade?
<babbageclunk> wallyworld: https://github.com/juju/juju/blob/develop/featuretests/upgrade_test.go#L157
<wallyworld> makes sense
<wallyworld> so we must bypass that state check then for that case
<wallyworld> but that's internal, not a user driven thing
<wallyworld> thumper: small one https://github.com/juju/bundlechanges/pull/33
<babbageclunk> wallyworld: ok, I'll try to chase that code down...
<thumper> wallyworld: approved
<wallyworld> ta
<wallyworld> thumper: a larger one https://github.com/juju/juju/pull/8111. sadly we still need to use charmstore.v5-unstable, but at least that's only in tests
#juju-dev 2017-11-21
<thumper> why?
<babbageclunk> Hey jam - I've replied to some of your comments. I think the problem is that the agents will reject any downgrade because we don't have a way to undo any upgrade steps that have run.
<axw> jam: thanks for the review. I've updated, PTAL
<wallyworld> thumper: why we still need charmstore.v5-unstable?
<wallyworld> because it pulls in deps incompatible with juju
<thumper> yes
<wallyworld> we need charmstore.v5 t be updated
<wallyworld> it uses an old idmclient
<thumper>  what is incompatible?
<wallyworld> and also pulls in bakery.v-unstable
<thumper> I'd prefer not to update the code so we have both
<wallyworld> v2
<wallyworld> juju uses v1
<wallyworld> so structs don't work together
 * thumper sighs
<wallyworld> and idmclient has api changes
<thumper> I guess that is a no go then
<wallyworld> we can keep v5-unstable for now
<wallyworld> it's only used in tests
<wallyworld> the pr as is can land - it takes charm and charmrepo stable branhces for prod code
<wallyworld> thumper: the only place charmstore.v5-unstable is used is in a small number of tests for juju repo. all other code uses charm.v6 and charmrepo.v2 and other stable branches.
<thumper> but I'm not happy about bringing multiple copyes if the bakery code either
<wallyworld> it's not used by juju, just a transitive dep
<wallyworld> juju itself only uses charm.v6, charmrepo.v2
<wallyworld> and some tests use charmstore.v5-unstable
<wallyworld> that's it
<wallyworld> you can see the import changes to juju in the PR - they are well contained to just charm.v6-unstable -> charm.v6 etc
<wallyworld> ince we land this now, we can follow up in a point release with a charmstore.v5 update and just 5 test files will be updated
<thumper> ok, fair enough
<wallyworld> thumper: you able to +1 the PR?
<thumper> done
<wallyworld> ta
<axw> wallyworld: so, it's safe to remove the juju-upgrade-mongo plugin from develop? I'm trying to fix these login issues cleanly, and removing that would help a bit I think
<wallyworld> yup
<axw> that and related code I mean... maybe I'll just remove the agent bits on develop
<axw> k
<wallyworld> it ws only ever for in situ mongo upgrades from 2.4 -> 3.2
<wallyworld> jam: i just looked at the upgrade PR - the PR as written makes the CLI enforce what the backend (has always IIRC) done. we do allow downgrades in the HA case where a controller itself needs to roll back. but not user initiatd ones - i don't think we ever have, or at least not for a long time. i'm personally reluctant to allow the user a foot gun here. we now have your script to force downgrades if we really want to get someone unstuck down't we?
<wallyworld> maybe if we ever implement downgrade steps
<wallyworld> but it's not just schema changes to worry about
<admcleod_> anyone around?
<admcleod_> wondering if its possible to --force a charm (series issue) in a bundle
<jam> wallyworld: so he had to make a change to the State side of the code. I have the feeling we do a Major.Minor check but not a Major.Minor.Patch
<jam> which I think he's adding, and then also adding to the client as well.
<wallyworld> jam: the state changes have been backed out IIANM
<babbageclunk> jam: I added a check to State.SetModelAgentVersion (to match the one in state.checkUpgradeInfoSanity), but I've backed it out now because it caused problems with a feature test.
<jam> babbageclunk: k. So ideally we would use the same logic front and back, but I'd also rather the version be validated server side and rejected before it gets set.
<jam> the particular bug was that what was allowed was ultimately rejected by the Upgrader, but so late in the process that everything got wedged.
<jam> babbageclunk: wallyworld: I think we'd get more traction on upgrades if we had a better downgrade story
<jam> I appreciate that its a bit hard
<wallyworld> jam: agreed, but to do that a day before thr rc....
<wallyworld> when this has been the behaviour since forever
<wallyworld> sure fix it, but in 2.3.x or 2.4
<jam> wallyworld: pretty sure that .PATCH has been allowed for a long time
<wallyworld> the code in state suggests otherwise? not sure, i'll have to read it in detail
<jam> I'll test in a sec
<jam> not hard to try 2.2.6 => 2.2.5
<babbageclunk> jam: The version check in checkUpgradeInfoSanity has been there since 2014.
<jam> babbageclunk: so checkUpgradeInfoSanity certainly dates back to 2014 from William. But I know that CI has for a long time bootstrapped 2.X.Y and then targeted a rollback to 2.X.Y-?
<jam> babbageclunk: I'm trying to figure out if something used to be setting .Patch to 0 or something to make it work
<babbageclunk> jam: ah, good point - that's certainly possible
<jam> babbageclunk: so "juju upgrade-juju --debug -m controller --agent-version 2.2.5" is perfectly accepted, and never complains, but doesn't actually do the change
<jam> there is a line in the log file
<jam> but nothing on any machine, etc.
<jam> and you can't "juju upgrade-juju --agent-version 2.2.6" to fix anything because it complains that not all agents are version 2.2.5 yet
<jam> babbageclunk: so good enough on your patch, I'm not sure why it worked in the past, but at least it makes it consistent with current internals.
<axw> jam: can you PTAL at https://github.com/juju/juju/pull/8109? would like to land for rc2
<babbageclunk> jam: ok, thanks for looking a closer look.
<jam> axw: looking
<jam> axw: did you check if we still get the right error stack out the far end by annotating the inner Err: if we are wrapping it with StartInstanceError ?
<jam> axw: reviewed
<axw> jam: error stack in what context? which "far end" are you talking about?
<axw> thanks
<jam> axw: the goal of a stack trace is to see where the originating error comes from
<jam> if we are wrapping, do we lose the ability to see the stack trace if we ever bubble the errors up to (say the DependencyEngine)
<axw> jam: of course. so just a general question - no I haven't checked that, I'll do so before landing
<jam> sgtm
<wallyworld> axw: here's a fix for that file handle leak. i have to pop out for a bit for dinner but will do more than smoke testing when i get back https://github.com/juju/juju/pull/8112
<axw> wallyworld: ok, will look after I'm done here
<wallyworld> yup. no ruah
<axw> jam: my previous approach doesn't work with stacks. the definition of "cause" in errors seems a bit whacko, so I didn't quite understand how Mask could work before. I'm reworking to use that now
<axw> jam: I'll add a common function in provider/common and just fix up the source location from there
<jam> axw: thanks
<axw> jam: https://github.com/juju/juju/pull/8109 is updated with a function, do you want to take another quick look before I land?
<axw> helper function*
<axw> gotta go cook dinner, I'll bbl
<jam> looking
<jam> axw: 2 small tweaks and its good to land
<axw> jam: thanks (didn't get away yet - realised I missed ec2)
<axw> jam: errors.Wrap always returns *errors.Err
<jam> axw: k. I'm always scared of bare casts, I thought it was the underlying "err" that we were touching, but if its the Wrap return that's ok.
<axw> jam: if you have time, can you please take a look at https://github.com/juju/juju/pull/8113. I'll be back later
<jam> lgtm
<jam> anyone up for a trivial review: https://github.com/juju/juju/pull/8114
<axw> jam: I'm not sure I understand your question about restoreStatus being set correctly. It's set by the restoreChanged method - does that answer it?
<axw> anyway, that bit should be fine - landing. I'll address concerns in a followup if I missed the point
<jam> axw: I saw a change that introduces a new way to read a variable, but didn't see where that variable was being set. But presumably its already been taken care of elsewhere.
<axw> jam: yeah. there's a small change in the PR, to an existing method. it's just a mutex protected write to the same var
<axw> commented on the PR if you're interested
<wpk> thumper: re: containers MTU - I worked with ivoks on this today, we have confirmed that machiner is reporting correct MTU of the parent bridge (which should be used for the container device). Tomorrow I'll investigate further.
<thumper> wpk: ok
<thumper> wpk: is there someone else that could pick this up?
<thumper> wpk: either that or we'll hold rc2 for it
 * thumper quietly wishes we had someone that understood all the networking bits in NZ/AU
<wpk> thumper: I'll put a comment on the ticket with what I've discovered so far and will be my next steps.
 * wpk loudly wishes we had someone that understood all the networking bits.
<babbageclunk> (wpk: I thought that was you!)
<thumper> wpk: thanks
<wpk> babbageclunk: everybody seems to think that, I don't understand why...
<wpk> btw, weirdest completely non-juju bug on Artful - I plugged ps4 pad to my laptop to charge, and my screen started to rotate with pad - if the pad is upside down the screen is right side up, when I rotate it 90deg the screen rotates, when the pad is right side up the screen is upside down....
<babbageclunk> ha, amazing
<wpk> and that's probably enough computers for me for today ;)
<babbageclunk> wpk: when you say pad do you mean controller? Or is this some other crazy peripheral?
<wpk> babbageclunk: 1. pad has accelerometers 2. for some reason, unknown to me, Ubuntu decides that this accelerometer should dictate screen orientation
<wpk> babbageclunk: https://gameidealist.com/wp-content/uploads/magma-red-dualshock4.jpg this exact model
<babbageclunk> ooh, fancy
<wpk> I don't even know where to report this kind of bug
<wpk> It reminds me of a 'bug' in my Peugeot 307 - if ashtray lightbulb is blown headlights leveling doesn't work.
<balloons> wallyworld, thumper, veebers, I'm feeling well enough, let's do chat about upgrades in 10
<wallyworld> ok
#juju-dev 2017-11-22
<axw> wallyworld: took a look at your PR. mostly looks fine, left some questions about possible simplification
<thumper> axw: got a minute?
<thumper> axw: trying to debug a prodstack issue
<axw> thumper: ok
<thumper> axw: 1:1 HO ?
<axw> thumper: brt
<wallyworld> axw: thanks for review. i commented on the caas model update worker - i think we can keep it as we will surely be adding upgrade support etc soon. plus it sets model status to "available"
<axw> wallyworld: seems like a bit of an odd place to be setting the status, but fair enough on keeping it for probable future use
<wallyworld> axw: thst's what the IAAS model upgrade worker does - i just cribbed from that
<wallyworld> i guess it sets to available when everything like upgrades etc has been done
<axw> wallyworld: I've approved, please see my comment on the authoriser. I'm going for a ride to get some lunch, bbs
<wallyworld> axw: tyvm
<thumper> babbageclunk: I'm hitting an upgrade-juju problem
<thumper> babbageclunk: got 5 minutes to discuss?
<babbageclunk> thumper: oops, yup?
<babbageclunk> in 1:1 HO?
<thumper> yeah
<thumper> babbageclunk: yeah
<axw> poop, rear wheel is buggered, no ride for me
<babbageclunk> axw: bums
<babbageclunk> flat tyre or something more serious?
<axw> babbageclunk: wobbling, rubbing against the brake pads. also the kick stand was getting in the way of the pedals... not sure what happened
<babbageclunk> axw: I've had something similar with a broken spoke (although not the kick stand part).
<axw> babbageclunk: yeah there's a broken spoke too :) probably has warped on the way home after it broke
<admcleod_> is there a way to specify options for the lxd profile when deploying a unit?
<wallyworld> jam: small PR based on yesterday's work - logs are not as noisy https://github.com/juju/juju/pull/8119
<jam> wallyworld: lgtm
<axw> wallyworld jam: if either of you have time, https://github.com/juju/juju/pull/8120 fixes https://bugs.launchpad.net/juju/+bug/1733259
<mup> Bug #1733259: API server validator should allow other API server connectings during upgrade process <apiserver> <upgrade-juju> <juju:In Progress> <https://launchpad.net/bugs/1733259>
<jam> axw: so what is the Pinger for the controller agent now? Just when it is a controller logging in exactly to itself? Does that mean we always have exactly 1 pinger, or do we have 2 (one for RPC one for Logging)
<axw> jam: if you looked earlier than a few minutes ago, you would've caught a mistake. the old code for starting the pinger was correct, just highly confusing (to me at least)
<jam> axw: because of the "is controller" stuff and it only being set when a controller logs in for a different model?
<jam> I don't think that logic is very clear
<axw> jam: we should be starting the pinger if it's a non-controller connecting, or if it's a controller connecting to the controller model
<jam> axw: arguably the latter isn't 100% true. it should be if the controller is connecting to itself in the controller model (IMO)
<jam> axw: Tim's changes to pubsub mean that the controllers connect to each other
<jam> but we shouldn't treat them as alive/dead based on that
<axw> jam: sorry, which "latter" are you referring to? controller connecting to controller model is what I said just before...
<jam> axw: Tim changed pub-sub so that machine-0 will connect to machine-1 in the controller model, but IMO we still shouldn't start a Pinger for it
<jam> we should only start one when machine-0 connects to machine-0 for the controller model
<axw> jam: right, I see
<axw> jam: if we were to do that, then older API servers that didn't prefer localhost wouldn't have a pinger at all
<axw> maybe no big deal, because they should upgrade pretty quickly
<jam> axw: we never have mixed api servers
<jam> axw: they wait to upgrade for the other ones to notice
<jam> because otherwise they can't talk to the db schema
<jam> axw: we might have machine agents older than controllers, but the controllers actually wait for all controllers to ack that they're ready to upgrade before any will upgrade.
<axw> jam: and they do that through state directly, without involving the API server?
<jam> axw: that's actually the cause of the deadlock, because machine 0 & 1 go into "we're ready to upgrade, waiting for 2" and 2 ends up in a reboot loop
 * axw is trying to find the code
<jam> axw: yeah, they record in the database ready-to-upgrade-to, IIRC
<axw> jam: I think I'd like to move the pinger for controller agents outside of the apiserver, but will do after 2.3. I'll have it run only if the tag matches the local machine
<axw> jam: by which I mean presence pingers. we currently don't run connection pingers for user connections, or for connections from controller-to-controller-model; that doesn't seem right, does it?
<jam> axw: we stopped doing connection pingers for users because of long lived connections that were dying (maybe that was gui issues?, or maybe just transferring data issues).
<jam> axw: personaly, I'd rather have the connection-keep-alive-pinger *be* the presence trigger
<jam> rather than 2 separate things
 * axw nods
<axw> jam: pushed a small change to stop running pingers for other controllers
<wallyworld> jam: just back from dinner, ty for review
<axw> jam: I don't understand your comment on https://github.com/juju/juju/pull/8116. why would $gt fail with a time.Time?
<jam> axw: the record in the database is a ISODate
<jam> and ISODate is never $gt: 0
<jam> we need to compare to a {$gt: time.Time{}}
<axw> jam: but it can be $lt something else?
<jam> axw: Time struct vs integer
<axw> jam: my point is we already compare with integers using $lt, why is $gt different?
<jam> axw: it doesn't
<jam> axw: there is an iportant "if p.unitTime == Nanoseconds" earlier
<jam> axw: so for the statusesC collection, it uses UnixNano and compares with 0
<jam> axw: for actions, it is a "GoTime" and compares against a time.Now().Sub(somtehing)
<axw> jam: aha, my bad
<axw> thanks
 * axw disappears again
<jam> axw: I worked with eric on debugging why some tests were failing, and just did a quick bootstrap and then was playing with db queries
<mup> Bug #1733847 opened: same ip got assigned to two different container  <juju-core:New> <https://launchpad.net/bugs/1733847>
<babbageclunk> thumper: so I should be ripping out all of the observer stuff? Is it ever used for anything other than audit logging?
<babbageclunk> It's kind of vague
<thumper> no
<thumper> lets talk
<thumper> but otp just now
<babbageclunk> ah, metrics
<babbageclunk> thumper: ok, ping when you're ready
<thumper> ready
<thumper> babbageclunk: now?
<thumper> babbageclunk: 1:1
<mup> Bug #1733968 opened: virtual IP addresses should not be registered <sts> <juju:New> <juju-core:New> <https://launchpad.net/bugs/1733968>
<thumper> babbageclunk...
<thumper> bueller
<thumper> bueller
<thumper> bueller
<babbageclunk> gah sorry, looking at the bottom of the monitor, didn't notice the bubbles at the top
#juju-dev 2017-11-23
<thumper> axw: thanks for that controller login branch, I'm sure it'll help some 2.2.4 controllers going to 2.3
<axw> thumper: np
<axw> thumper: I think it's a little tidier now anyway, but I'm biased
 * babbageclunk steps out to look at a house
<axw> jam: I think I'm going to have to back out the change to stop running a pinger for other controllers
<axw> jam: it seems there's no guarantee that the controller workers will connect to their own apiserver. that seems wrong, but I don't know that I can fix it in time for 2.3
<axw> jam: post 2.3, each controller machine can just run a pinger for itself in its dependency engine
<axw> thumper: can you please review https://github.com/juju/juju/pull/8122?
<thumper> axw: sure
<thumper> axw: we should talk about this change, because I don't think it is right
<axw> thumper: it's reverting a change to how it was, but ok
<thumper> oh...
<thumper> right you are
<thumper> this is fine
<axw> thumper: you wanna HO?
<thumper> although, just 5m to confirm
<thumper> lets 1:1 HO
<axw> sure
<babbageclunk> thumper: are we going to have something that's going to collect and amalgamate audit logs from different controller machines?
<thumper> babbageclunk: um...
<babbageclunk> ?
<thumper> we aren't looking at writing a tool at this stage
<thumper> they are aware that an amalgamated view would be needed
<babbageclunk> thumper: just occurred to me as I was ripping out the DB storage pieces.
 * thumper nods
<babbageclunk> thumper: since this is a stream of either calls or facade methods, it should probably include a type indicator on each record. Maybe just have a top-level item struct with an omitempty field for each of the two records?
<babbageclunk> thumper: I remember you saying something about introspecting the types of API results to find errors - what was that about?
<thumper> babbageclunk: otp right now
<thumper> with you after
<babbageclunk> tsk you're always on the phone
<thumper> that's what managers do
<babbageclunk> :(
<axw> veebers: can https://github.com/juju/juju/pull/7715 be closed?
<axw> veebers: and is https://github.com/juju/juju/pull/7858 still something you intend to land?
 * veebers looks
<veebers> axw: ah right, ci-run is work in progress I need to get back to it and land it, same with the 2nd, I can bring down the PR for that one if it's distracting as there is a little more work needed there (was put up as a PR for the discussion)
<axw> veebers: no worries, just checking
<axw> sometimes PRs just hang around forever
<veebers> axw: axk, thanks for the heads up; I do need to move them forward
#juju-dev 2017-11-24
 * babbageclunk goes to look at another house
<axw> wallyworld: https://github.com/juju/juju/pull/8126 merges develop into the feature branch. there's one commit that's added on top of the merge, mentioned in the comments
<wallyworld> righto
<wallyworld> axw: lgtm, will be good to get that landed
<axw> wallyworld: thanks
<axw> wallyworld: thanks for splitting up your PR, I'll take a look a bit later on after I've got my next PR up, and merge fixed
<wallyworld> yup, no worries
<axw> wallyworld: https://github.com/juju/juju/pull/8127 fixes the other half of the storage bug
