#juju-dev 2012-12-17
<wallyworld_> davecheney: hi there, i'd love a review if you have a change sometime https://codereview.appspot.com/6940069/
<wallyworld_> also maybe https://codereview.appspot.com/6923056/
<davecheney> wallyworld_: no probs
<wallyworld_> awesome thanks
<geddan> wallyworld___: heading off, are there any more reviews to do tonight ?
<fwereade> breakfast break, bbiab
<rogpeppe> mornin' all
<jam> morning
<jam> I'm running into a test suite hang, where I end up with a "mongod <defunct>" process, and the test suite ends up being killed after waiting 5 minutes.
<jam> Anyone seen that and can help me fix it?
<jam> (very reproducible, it happens with about 10 of the juju-core packages)
<jam> rogpeppe, fwereade: ^^ ?
<rogpeppe> jam: do you know which test is hanging?
<jam> rogpeppe: START: /home/jameinel/dev/go/src/launchpad.net/juju-core/cmd/juju/addrelation.go:0: AddRelationSuite.SetUpTest
<jam> TestAddRelation
<jam> but similar behavior is in a bunch of packages, so there may be a smaller one we could track down.
<rogpeppe> jam: have you got a stack dump out of it, so that we can see what line it's hanging on?
<jam> rogpeppe: well, if I try to connect with gdb, I get a permission denied, if I try as root, it dumps a memory map, perhaps there is a back trace.
<rogpeppe> jam: i usually do it by killing the process with SIGQUITE
<rogpeppe> QUIT
<jam> rogpeppe: http://paste.ubuntu.com/1444879/
<fwereade> rogpeppe, jam, heyhey
<rogpeppe> fwereade: yo!
<fwereade> jam, sorry, I'm not familiar with that problem
<rogpeppe> jam: hmm, that's not very helpful :-)
<jam> rogpeppe: SIGQUIT output: http://paste.ubuntu.com/1444882/
<jam> formatting seems hard to read
<rogpeppe> jam: i agree, but i lost that argument a while ago (in go core)
<jam> It looks like the test is hanging in a cleanup section, possibly as a bad side effect of something failing.
<rogpeppe> jam: it looks to me as if it's hanging trying to connect to mongo
<rogpeppe> jam: ah, i see where your bad formatting is coming from
<rogpeppe> jam: you probably just typed ^\
<jam> rogpeppe: correct
<rogpeppe> jam: which is actually ok now on go tip, i believe, but in earlier versions, go test doesn't catch the signal
<rogpeppe> jam: so you get two stack dumps interleaved
<jam> rogpeppe: ah, interestting. new dump: http://paste.ubuntu.com/1444889/
<rogpeppe> jam: the easiest way around it is to compile the binary with go test -c, then run that
<jam> using "kill -SIGQUIT"
<rogpeppe> jam: is mongod actually running?
<jam> rogpeppe: I've tried it with it alive and dead
<jam> that one could have been stopped
<jam> one more with it "start/running"
<jam> http://paste.ubuntu.com/1444893/
<fwereade> rogpeppe, offhand, does a `func (*State)Info() *Info` method sound like a sensible thing to you?
<rogpeppe> fwereade: i've been wondering about that, off and on
<rogpeppe> fwereade: i *think* so. it could just return the info it was opened with
<fwereade> rogpeppe, well, it would be very convenient for the deployer, which needs to tell its deployees how to connect
<rogpeppe> fwereade: the problem is that it's not always appropriate to use
<rogpeppe> fwereade: for instance, we might have opened the state with a localhost address, which might not be appropriate to use in a container
<rogpeppe> jam: could you try it against go tip on amd64, just to see if it's a go issue?
<fwereade> rogpeppe, well, we're always going to be deploying things which use a modified variant of the deployer's state info anyway, so having another field to swap out isn't the end of the world I think
<jam> rogpeppe: is there a simple way to do so?
<fwereade> davecheney, morning
<jam> rogpeppe: dimitern says he sees the same thing
<rogpeppe> jam: hg clone the go repo, cd src; all.bash
<rogpeppe> jam: then set $GOROOT=your-go-repo, and rebuild
<rogpeppe> jam: (i actually have a separate juju tree that i compile against 1.0.2 rather than tip)
<rogpeppe> jam: if you just test cmd/juju on its own, do you see the same hangup?
<fwereade> rogpeppe, but there is a minor wrinkle... so, if I expose an Info method and use that to create the deployer manager, I no longer need to pass in a separate (deploying) entity name, because that is already in the state info
<fwereade> rogpeppe, and this mostly feels like a win, *so long as* we always want to run an agent against a state opened on that agent's behalf
<jam> rogpeppe: yes
<jam> this is doing "cd cmd/juju; go test -gocheck.v -gocheck.vv"
<fwereade> rogpeppe, that seems reasonable to me, but it will complicate the tests a bit, because the test State is not connected with an EntityName matching the arbitrary unit/machine I want to use for testing
<rogpeppe> fwereade: the entity name issue makes me feel like this might not be such a great idea
<rogpeppe> fwereade: because the info isn't just about the state, it's also about who is connecting to the state
<fwereade> rogpeppe, well, yes, this is the property of the Info that I want to use
<fwereade> rogpeppe, what I'm trying to figure out is whether it's ok for me to do so or whether it's icky and wrong
<rogpeppe> fwereade: it means we can't hand a state off to some code without giving them our password, which seems... i dunno, maybe it's not an issue, it just seems potentially so
<fwereade> rogpeppe, ok, alternative: how would you feel about Addrs() and CACert() methods?
<rogpeppe> fwereade: that feels less controversial
<fwereade> rogpeppe, ok, thanks :)
<rogpeppe> fwereade: although there's still the localhost vs non-localhost address issue
<fwereade> rogpeppe, well, we always need CACert and we sometimes need Addrs
<fwereade> rogpeppe, and always have to supply our own EntityName and Password
<davecheney> fwereade: shouldn't you be somewhere else, drinking tall drinks with umbrellas in them ?
<fwereade> davecheney, nah, I took a holiday on fri to synergise with the public holiday on thu, working again until EOD weds
<fwereade> davecheney, that said, when did a breakfast cocktail ever fail to improve the day?
 * fwereade falls over
 * rogpeppe wouldn't mind a bloody mary
<davecheney> mmmm, rum
<davecheney> lads, i am very happy
<davecheney> juju now works properly in ap-southeast-2
<rogpeppe> davecheney: good work!
<davecheney> also, if anyone see's frank
<davecheney> please send my apologies
<davecheney> i had to roll back his change because it broke the initial auth phase
<davecheney> i don't know how
<davecheney> and I wasn't going to get into it trying to cut a release
<davecheney> speaking of that does cmd/jujud import environs/openstack
<davecheney> i noticed that I didn't have to update the deps when doing the deb build
<jam> davecheney: probably not yet
<davecheney> jam: that is fine
<davecheney> it was only something i noted doing the build
<fwereade> davecheney, was it maybe just that the jujud tests were expecting the FW to act differently somehow (ie just hadn't been run)? or something weirder?
<davecheney> nah, the auth code is quite touchy
<davecheney> rogpeppe: would you say that is a fair statement ?
<dimitern> jam: the standup is at 10:30 or at 11 utc?
<rogpeppe> davecheney: any auth code is touchy :-)
<rogpeppe> davecheney: i'm interested to know how it failed BTW
<rogpeppe> davecheney: here's an interesting little problem i found when trying to build juju for 386 (to try to replicate jam's problem)
<davecheney> rogpeppe: revert your working copy to r780 and see
<rogpeppe> davecheney: if you do, GOARCH=386 GOBIN=/tmp/foo go install launchpad.net/juju-core/cmd/juju
<rogpeppe> davecheney: the binary doesn't end up in $GOBIN
<rogpeppe> davecheney: but in $GOBIN/linux_386
<rogpeppe> davecheney: which means our install script in environs/tools.go fails to work
<davecheney> rogpeppe: yup
<davecheney> cross compile will do that
<davecheney> GOHOSTARCH=386 ./all.bash
<davecheney> might help
<davecheney> is jam using 386 ?
<davecheney> ewww
<rogpeppe> davecheney: yes, as far as i could make out
<rogpeppe> davecheney: see http://paste.ubuntu.com/1444893/
<rogpeppe> davecheney: note, for instance: 	/build/buildd/golang-1.0.2/src/pkg/runtime/zsema_386.c:146 +0x29
<jam> davecheney: yes to 386 I believe
<rogpeppe> davecheney: i'll try the GOHOSTARCH thing
<davecheney> those pointers are rather small :)
<jam> dimitern: 11
<dimitern> jam: ok, wasn't sure
<Aram> hello.
 * davecheney waves at Aram
<jam> dimitern: I run juju and launchpad in a VM to avoid having Mongo exposed to the world
<jam> and I tend to run 386 vms
<dimitern> Aram: hiya
<dimitern> jam: and it worked that way?
<davecheney> jam: honeslty, juju probalby wont' work compiled on 386
<davecheney> we've never considered that case
<davecheney> it'll probably produce a stillborn toolset using juju bootstrap --upload-tools
<rogpeppe> davecheney: i dunno, why should it be a problem?
<davecheney> rogpeppe: i'm worried about a default-series kind of 'oh, we never tested that' situation
<rogpeppe> davecheney, jam: cmd/juju tests pass for me, at any rate
<jam> I'm pretty sure juju tests worked for me at one point. Though perhaps not on this VM. More oddly, why would it be hanging trying to talk to mgo based on CPU word size?
<davecheney> jam: i doubt that is the problem
<davecheney> but i am concerned there are assumptions baked into the tests that assume amd64
<davecheney> i'm pretty sure environs/ec2 image tests assume amd64
<rogpeppe> jam: just tried with latest juju trunk against i386 and all tests pass for me
<rogpeppe> jam: haven't tried live tests yet
<davecheney> rogpeppe: my concern is tests != juju bootstrap --upload-tools
<rogpeppe> davecheney: exactly, i'm just gonna try live tests
<Aram> unrelated, juju tests are sometimes flaky in a VM, especially with -gocheck.vv
<Aram> there's some timing issues exposed only in VMs.
<rogpeppe> davecheney: but jam's test failures were local ones, and that's what i was trying (and failing) to reproduce
<jam> Aram: well, it fails with and without -gocheck.vv
<jam> I just used that to see what was actually hanging, though SIGQUIT worked out better for that
<rogpeppe> ah, here's a problem:
<rogpeppe> http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-precise-i386.tgz:
<rogpeppe> 2012-12-17 10:50:22 ERROR 404: Not Found.
<rogpeppe> other than that, it all seems to have worked ok
<jam> rogpeppe: the 386 thing is probably a red herring. dimitern is hanging as well, but he's on a amd64
<rogpeppe> jam: ah.
<rogpeppe> jam: i just wanted to make sure that i could run tests ok in a similar env to yours
<jam> sure.
<rogpeppe> jam: (and it's an interesting experiment too...)
<jam> btw, do you know the difference between "apt-get install mongodb" and "apt-get install mongodb-server" ?
<jam> (I used to have nothing installed, installed mongodb-server, and it stopped the 'could not find binary' failures. I'll try installing the former and see if that changes anything)
<jam> same failure (in Semacquire during (*mongoCluster).AcquireSocket
<jam> dimitern is also running on bare metal, vs a VM
<jam> rogpeppe: rev 780 seems to fail in the same place
<rogpeppe> jam: hmm.
<rogpeppe> jam: what version of mgo are you using?
<rogpeppe> jam: (i.e. what revision number are you on?)
<fwereade> rogpeppe, jam: lots of nice deletions in https://codereview.appspot.com/6938072
<fwereade> dimitern, and you, if you feel like reviewing ^^
<jam> mongodb-2.0.6-1ubuntu4, mgo: v2/mgo/ revno 183
<dimitern> fwereade: 10x, I'll look at it
<fwereade> Aram, or you, sorry, I didn't see you come on -- morning :)
<Aram> yo
<rogpeppe> fwereade: looking
<jam> rogpeppe: ^^
<jam> (rev 183 of mgo)
<rogpeppe> jam: darn, same as me
<mramm> jam: thanks for the update on dependencies, reading through it now.
<dimitern> fwereade: FWIW you have LGTM from me
<fwereade> dimitern, cool, thanks
<fwereade> rogpeppe, dimitern: a followup: https://codereview.appspot.com/6944058
<rogpeppe> fwereade: why conflate provisioner and firewaller? is it never reasonable to have one without the other?
<rogpeppe> fwereade: also, perhaps HostPrincipalUnits would be better as HostUnits - you can't have subordinates without principals.
 * dimitern looking
<rogpeppe> fwereade: (and principals imply subordinates too)
<fwereade> rogpeppe, at the moment, we always want to run the FW and the P together, and the jobs are explicitly not meant to be 1:1 with workers
<fwereade> rogpeppe, things may migrate in future
<fwereade> rogpeppe, re HPA, the MA's job is to host the principal units -- those units' agents may then host subordinates, but the MA doesn't know or care about that
<rogpeppe> fwereade: from the point of view of AddMachine, i think HostUnits makes sense - we're asking that machine to host any units, and we don't care if it's the machine agent interpreting those flags, or something else.
<fwereade> rogpeppe, I'm fine with that too :)
<fwereade> rogpeppe, HostUnits then has an uncomfortable similarity to WatchUnits though
<fwereade> rogpeppe, HostPrincipalUnits/WatchPrincipalUnits is clearer
<rogpeppe> fwereade: well, if you think about it, WatchPrincipalUnits is only used for the top level, but that's just an implementation detail - we want the machine to host any kind of unit in the end
<dimitern> fwereade: done
<rogpeppe> fwereade: another thing i'm not entirely sure about: there was a nice correlation between worker constant names and the Workers function, but Host* doesn't relate strongly to "job"
<fwereade> rogpeppe, both the jobs are currently about hosting other things
<fwereade> rogpeppe, JobHostBlah felt over-wordy
<rogpeppe> fwereade: so if we had more constants, they might not all have a common element in the names?
<fwereade> rogpeppe, that might be the case -- I presume you are advocating for Job*
<rogpeppe> fwereade: i'm not sure. i'm possibly advocating changing AgentJobs to HostJobs or something along that kind of line
<fwereade> rogpeppe, am definitely fine with that
<fwereade> rogpeppe, ah not so much with that, sorry
<fwereade> rogpeppe, well, letme think ;)
<fwereade> rogpeppe, I think I would maybe like HostPrincipalUnits/RunEnvironController, probably with a Job prefix
<rogpeppe> fwereade: those names seem, erm, a bit verbose
<rogpeppe> fwereade: i'm thinking that from a top-down pov, we're declaring what kinds of things a given machine will run
<rogpeppe> fwereade: so maybe RunUnits, RunEnvironController?
<rogpeppe> fwereade: i definitely think we should lose the "Principal" - we want a machine to run all units, not just principals
<fwereade> rogpeppe, I still feel the other way re Principal, but not enough to fight it :) -- Run SGTM
<rogpeppe> fwereade: actually Task might work
<rogpeppe> fwereade: UnitsTask, EnvironControllerTask
<fwereade> rogpeppe, uncomfortable collision with jujud.task
<rogpeppe> fwereade: that should probably be named worker
<rogpeppe> fwereade: because it corresponds to the interface implemented by workers
<fwereade> rogpeppe, well, niemeyer is adamant that there is a distinction between a task and a worker, and an upgrader is not a worker
<rogpeppe> fwereade: hrmph
<fwereade> rogpeppe, or that is my understanding, which is probably flawed
<fwereade> rogpeppe, I don't think there's a meaningful distinction
<rogpeppe> fwereade: i *think* that was due to the old state Worker constants
<fwereade> rogpeppe, ha, ok
<rogpeppe> fwereade: which were the high level description of what to do
<rogpeppe> fwereade: and i'm proposing to rename those to tasks, to make the distinction clear.
<rogpeppe> fwereade: that starts to make quite a lot of sense to me, actually.
<rogpeppe> fwereade: the machine agent uses some number of workers in order to fulfil its allocated tasks.
<fwereade> rogpeppe, task feels a bit too singular for the intent here, I think -- in my mind I'm not thinking of workers at all, I'm thinking of tasks (ie runTasks(...task)), and I'm thinking of a Job as something that is made up of some number of tasks
<rogpeppe> fwereade: for me, "task" is a description of something to do, and "worker" is a something that accomplishes that
<rogpeppe> fwereade: "job" works ok as well as "task", but seems more like something with a defined beginning and end.
<rogpeppe> fwereade: whereas the tasks we're talking about are indefinite in extent
<fwereade> rogpeppe, IMO "job" is a pretty good name for a group of ongoing tasks
<rogpeppe> fwereade: "job" feels like something that can be finished. then again, maybe "task" does too...
<rogpeppe> fwereade: "we task this machine with the job of running the environment controller" :-)
<fwereade> rogpeppe, haha
<fwereade> rogpeppe, (IMO task feels >= job re finishitude)
<rogpeppe> fwereade: ok. UnitsJob, EnvironControllerJob ?
<fwereade> rogpeppe, I still want the common prefix for some reason
<fwereade> rogpeppe, what's the argument the other way?
<rogpeppe> fwereade: we had Worker as a suffix before; it seems to read more nicely to me, at any rate
<fwereade> rogpeppe, heh, it always seemed icky to me
<rogpeppe> fwereade: JobUnits seems... non-obvious. JobRunUnits perhaps
<rogpeppe> afk, one mo
<fwereade> rogpeppe, hmm: JobHostUnits/JobManageEnviron?
<rogpeppe> fwereade: sgtm
<fwereade> rogpeppe, cool
<rogpeppe> fwereade: and i think the task interface *should* probably be renamed to worker, but maybe in another cl
<fwereade> rogpeppe, I'd prefer the opposite change, I will let it stew in my mind for a bit
<rogpeppe> fwereade: renaming worker to task is a much bigger change
<rogpeppe> fwereade: we'd have to rename the whole worker package hierarchy
<rogpeppe> fwereade: (and i quite like the "worker" name currently - it seems to represent what's going on quite well)
<fwereade> rogpeppe, (I have worse thoughts -- "task/uniter", uniter.NewTask(), etc, which would then let me get a Deployer naming I'm happy with)
<fwereade> rogpeppe, but, anyway :)
<rogpeppe> fwereade: i'm not quite sure what you're thinking of there
<fwereade> rogpeppe, it's really not important -- as I say I will ponder worker/task some more, and perhaps attain enlightenment
<dimitern> rogpeppe, fwereade: PTAL https://codereview.appspot.com/6940073
 * fwereade looks
<dimitern> brb
<dimitern> back
<rogpeppe> fwereade: you've got a review
<fwereade> rogpeppe, awesome, ty
<fwereade> rogpeppe, I dunno -- at the moment it seems that an agent with no jobs is just not a useful thing to have
<dimitern> rogpeppe: would you ? ^^
<rogpeppe> fwereade: it is for tests :-)
<rogpeppe> dimitern: will do
<fwereade> rogpeppe, ha, well, yeah -- it always was, though, and that didn't stop us then ;p
<rogpeppe> fwereade: although a test for no jobs in AddMachine seems reasonable too
<fwereade> rogpeppe, there is one, isn't there?
<rogpeppe> fwereade: quite likely, i didn't check
<fwereade> rogpeppe, I think I wrote one :0
<fwereade> rogpeppe, +1 on MachineJob, I think
<rogpeppe> fwereade: cool
<fwereade> rogpeppe, then I guess Jobs() rather than AgentJobs()
<rogpeppe> fwereade: didn't i suggest that?
<fwereade> rogpeppe, ha, hadn;t read far enough
<fwereade> rogpeppe, not sure about the bitmask though -- feels like going to extra effort to restrict the number of jobs we have and make it fiddlier to add or remove them (when we eventually want to do that)
<rogpeppe> fwereade: i don't think it makes it any fiddlier to add or remove jobs
<rogpeppe> fwereade: and i think most logic gets simpler
<fwereade> rogpeppe, more complicated txn retries anyway, surely
<rogpeppe> fwereade: (no need to check for dupes for example)
<rogpeppe> fwereade: why is the txn retry more complicated?
<rogpeppe> fwereade: we're just setting an integer, no?
<fwereade> rogpeppe, $addToSet?
<fwereade> rogpeppe, we can $addToSet and $pull jobs out of an []int without having to mess around retrying because we're trying to store bitmask X which was dervived from Y which has become Z in the meantime
<rogpeppe> fwereade: we don't want to use that for jobs, do we?
<fwereade> rogpeppe, won't we?
<fwereade> rogpeppe, so the bootstrap machine will be the single bootstrap machine forever?
<fwereade> rogpeppe, (forgive the terminology)
<rogpeppe> fwereade: there's nothing to say we can't change the jobs for a machine; it just means we can't have an AddJob/RemoveJob API rather than a SetJobs API.
<rogpeppe> fwereade: ... which is quite possibly a sufficient reason
<fwereade> rogpeppe, I *think* it is... or at least it looks close enough from here
<rogpeppe> fwereade: but even if we store stuff in the database as []int, we could still have a bitmask as the externally visible API
<fwereade> rogpeppe, is there some advantage of a bitmask I'm not seeing? it seems strictly worse to me -- by the time we have enough flags we care about the extra space of an [], we have enough flags that we're worried about space in a bitmask
<rogpeppe> fwereade: it's not about space
<fwereade> rogpeppe, not looping through it?
<rogpeppe> fwereade: it's about the ease of checking for membership and the automatic duplicate deletion
<fwereade> rogpeppe, how common are these operations, and how much code do we waste each time we do them?
<rogpeppe> fwereade: not that common - most code never manipulates a set of jobs. maybe 8 or so lines in the places we do.
<rogpeppe> fwereade: to me, a bitmask represents like a natural representation of a set
<rogpeppe> s/represents/seems/
<fwereade> rogpeppe, to me, it's something I use when there's a compelling reason to pack stuff into a small space and never besides :)
<rogpeppe> fwereade: ha
<rogpeppe> fwereade: C vs Python background i guess :-)
<Aram> bitmaks are awesome.
<fwereade> rogpeppe, it's not like I *didn't* spend time up to my elbows in bits, it's just that that time was not generally otherwise representative of sensible development practices ;)
<rogpeppe> fwereade: using bitmasks as sets actually works pretty well, and isn't unsafe
<fwereade> rogpeppe, still feels like an [] is the more natural mongo representation, and I'm still not sure the other benefits really outweigh that
<rogpeppe> fwereade: i think i agree with that. seems like a pity that mongodb doesn't have bitwise ops, but there we go
<fwereade> rogpeppe, cool, cheers
<fwereade> dimitern, I'm afraid cath has just gone out without laura, so I won't finish your review any time soon: probably tomorrow :(
<dimitern> fwereade: sure, no probs
<fwereade> rogpeppe, dimitern, Aram: but I do have another CL for a horrifying moronic uniter bug: https://codereview.appspot.com/6946071
<fwereade> I would very much appreciate reviews of that
<rogpeppe> fwereade: a surprisingly large change for such a small bug :-)
<rogpeppe> dimitern: sorry, run out of time on your review. FWIW, i got stuck on getId. i couldn't work out whether it's the right function with a dubious doc comment, or if it should be refactored somehow
 * rogpeppe is off for the evening. g'night all.
<davecheney> fwereade: ping
#juju-dev 2012-12-18
<fwereade> davecheney, pong
<davecheney> fwereade: just checking in about that config hook bug
<davecheney> but i solved my own problem
<fwereade> davecheney, ah cool
<fwereade> davecheney, the config hook -- I, er, just remembered python wrong and just kept on reinforcing my own crackfulness :/
<davecheney> fwereade: fairy nuf
<davecheney> it worked properly for a while
<davecheney> but i'll stop blaiming the charmers for breaking the charm
<fwereade> davecheney, it did change pretty recently, last few days, and that's the only time I've seen the bug exposed
<davecheney> fwereade: was broken for 1.9.4
<davecheney> possibly not broken for 1.9.3
<davecheney> fwereade: https://bugs.launchpad.net/juju-core/+bug/1090176/ raised on 14/12
<_mup_> Bug #1090176: worker/uniter: precise:wordpress charm is unstable <juju-core:New> < https://launchpad.net/bugs/1090176 >
<davecheney> holy shit launchpad is being a bitch today
<davecheney> EOF after EOF
<fwereade> davecheney, thanks, sorry I missed that bug
<fwereade> rogpeppe, ping
<rogpeppe> fwereade: pung
<fwereade> rogpeppe, heyhey
<rogpeppe> fwereade: mornin'
<fwereade> rogpeppe, I am wondering about InitDir and LogDir, and how we should be setting those for principal units such that their subordinates are set up right, but in such a way that we can run sane tests
<fwereade> rogpeppe, eg currently I can't test actual subordinate deployment without hitting /etc/init
<rogpeppe> fwereade: yeah, i've wondered about this
<rogpeppe> fwereade: python just does it with mocks, presumably
<fwereade> rogpeppe, the obvious answer is to just make the default InitDir and LogDir in the deployer package accessible, so we can swap them out for tests
<fwereade> rogpeppe, but I'm not quite sure that's actually the right thing to do
<fwereade> rogpeppe, a bit too much action-at-a-distance for my tastes
<rogpeppe> fwereade: are you thinking of making them parameters?
<fwereade> rogpeppe, maybe-probably, but the question that is really vexing is the ultimate source of those values
<fwereade> rogpeppe, ah, sorry, you mean command line params?
<fwereade> rogpeppe, because I am still very keen on the idea that we can basically drop all the command-line params except entityName and dataDir
<rogpeppe> fwereade: no, i didn't
<rogpeppe> fwereade: and i'm working on a CL that does that as we speak
<fwereade> rogpeppe, really? awesomesauce
<fwereade> rogpeppe, I sketched something similar over the weekend but it's not really primetime-capable yet
<fwereade> rogpeppe, the code seemed to be leading me towards an agent package with a Conf{DataDir,EntityName} and a bunch of Read/Write methods for state info bits
<fwereade> rogpeppe, (and also the agenty bits of environ/tools.go, and the upgrader, and possibly openState and runTasks from curent jujud)
<rogpeppe> fwereade: i'm not changing anything other than the way the parameters get to jujud
<rogpeppe> fwereade: but you may be right that that's the way to go
<fwereade> rogpeppe, ah, interesting, how are you doing bootstrap?
<rogpeppe> fwereade: just plonk the params in files rather than put them on the command line
<fwereade> rogpeppe, if the above suggestion doesn't immediately turn you off I will probably do a bit more in that direction
<fwereade> rogpeppe, I was wondering in particular about the paths to those files for bootstrap vs for agents
<fwereade> rogpeppe, but this is not actually a very interesting thing to ask you
<fwereade> rogpeppe, I shall await a CL with good cheer
<rogpeppe> fwereade: why should bootstrap be different?
<rogpeppe> fwereade: (perhaps i just haven't encountered the problem yet!)
<fwereade> rogpeppe, it doesn't have its own directory, but the agents do, that's all
<fwereade> rogpeppe, putting the files it needs *somewhere* is easy -- putting them in the *right* place seemed a bit trickier
<rogpeppe> fwereade: for the time being, i was keeping the parameters global
<rogpeppe> fwereade: (thinking that we can move towards a per-agent model as a next step - the main thing is getting params off the command line)
<fwereade> rogpeppe, my only issue there is that you still need per-agent storage for password/oldPassword
<fwereade> rogpeppe, so I'm not sure whether it's even possible to *completely avoid the issue
<rogpeppe> fwereade: initial-password can still be global
<fwereade> rogpeppe, so we always set the same initial password for everything? feels like a bit of a step back
<fwereade> rogpeppe, (but password cannot be, anyway, right?)
<rogpeppe> fwereade: we do currently use the same initial password for all agents started from cloudinit
<rogpeppe> fwereade: and password already uses the entity name specific storage
<fwereade> rogpeppe, the first bit surprises me -- I'd expect the provisioner to set an initial password for the MA and write that into the cloud-init
<fwereade> rogpeppe, similarly to what the deployer does before installing the upstart job
<rogpeppe> fwereade: the cloudinit is passed a single StateInfo
<rogpeppe> fwereade: that tells anything in the new instance how to connect to the state.
<fwereade> rogpeppe, right, and shouldn't that StateInfo have a fresh password, generated by the provisioner and assigned to the machine?
<rogpeppe> fwereade: that it does
<rogpeppe> fwereade: your point being?
<fwereade> rogpeppe, that I don;t see how a global initial-password can fit in with per-entity initial passwords, because it's perfectly possible that two new entities might come up at the same time and each need their own initial-passwords
<fwereade> rogpeppe, if we only have one slot to store that in, we have a problem
<rogpeppe> fwereade: ah, one mo. it's not a problem for the provisioner vs MA, but it is a problem for the MA starting the unit agent
<fwereade> rogpeppe, yeah, indeed
<fwereade> rogpeppe, sorry, that is my perpetual perspective, I frequently forget that it is different to other peoples'
<fwereade> 's
<rogpeppe> fwereade: in which case, i don't see (at this moment) any particular problem with having bootstrap-state getting the password from the machine agent's dir (or we could have a "bootstrap" entity name if we wanted)
<fwereade> rogpeppe, a possibility is to keep the command-line args to bootstrap, because that's a one-shot, and we don't need t worry about it being run with stale data
<rogpeppe> fwereade: that is a possibility, yeah. except i'd like to reuse the code that makes the state.Info, but perhaps it's not worth it.
<fwereade> rogpeppe, I didn't finish it at the w/e but I was coming down on that side of the question
<rogpeppe> fwereade: and bootstrap-state is different too, as it doesn't change the password
<fwereade> rogpeppe, I thought that was indeed maybe the case but I didn't dig in
<rogpeppe> fwereade: it is the case - that initial password is changed when the first connection arrives
<fwereade> rogpeppe, ok, cool
<fwereade> rogpeppe, well, I shall hold off from any fancy agent packages for now
<rogpeppe> fwereade: what else did you see as a possible client for this possible package (other than jujud itself)?
<fwereade> rogpeppe, when we're deploying, ISTM that it would be nice to construct the appropriate Conf and just WriteAddrs(), WriteCACert(), WriteOldPassword()
<rogpeppe> fwereade: problem is that it doesn't work for cloudinit
<rogpeppe> fwereade: and in the end it's just three file names
<fwereade> rogpeppe, also WriteTools, I suspect
<fwereade> rogpeppe, and, honestly, "it's just 3 file names" is not IMO a valid argument for having 2 or 3 copies of the same data
<fwereade> rogpeppe, I think the bar for data duplication is much higher than that for code duplication
<rogpeppe> fwereade: three path name constants ? :-)
<fwereade> rogpeppe, one day, agents will have some mechanism by which we can update certs and servers, right?
<rogpeppe> fwereade: yup
<fwereade> rogpeppe, ok, that's a derail, sorry, I think I have a tighter focus if I can articulate it
<fwereade> rogpeppe, I feel the burden of proof is on you, to demonstrate the overwhelming advantages of separating the code for reading and writing the same information
<fwereade> rogpeppe, but I suspect you do not share this perspective
<rogpeppe> fwereade: i tend to factor out only when it becomes useful. currently we read this info in one place only, and write it in two places (but in two different ways)
<rogpeppe> fwereade: so actually factoring out will only add code currently (package overhead)
<rogpeppe> fwereade: but i agree that it will probably be a good thing for the future
<fwereade> rogpeppe, my own global perspective is that we already have agenty stuff scattered all over jujud, environs, and deployer, and that the overhead of an additional package to collect those things is dwarfed by the current overhead of having to remember how all those bits fit together
<fwereade> rogpeppe, it's primarily a my-puny-brain argument
<rogpeppe> fwereade: if it really is possible to collect all those things in a nice way, i'm definitely +1
<fwereade> rogpeppe, my problem is basically that I can't see anyone agreeing to review the change if it happens all at once, but that the initial moves to get us into a position where it makes sense are all kinda pointless and inconvenient in isolation
<fwereade> rogpeppe, probably I should hack the whole thing out in a frenzy, propose -wip, and also propose a bunch of others with links saying "it may look crazy now, but it lets us do this"
<fwereade> rogpeppe, or maybe I should just be biding my time
<fwereade> rogpeppe, I believe that the jujud change you are making is a big step in the right direction, and it may be that the landscape will look different once that's in
<rogpeppe> fwereade: leave it for now - this CL i have may go in that kind of direction, we'll see
<rogpeppe> fwereade: i feel that the most important thing is removing the command-line params (because that makes us upgradable) - the rest is internal refactoring
<fwereade> rogpeppe, yeah, agreed
<dimitern> rogpeppe: hey, could you take a look please - https://codereview.appspot.com/6940073/
<fwereade> rogpeppe, incidentally, how would you feel about old-password rather than initial-password? it makes it a little bit clearer that we can get password-changing for free just by renaming password to old-password
<fwereade> rogpeppe, nbd, just a suggestion
<fwereade> rogpeppe, aaaanyway, I'll be going for the mocked-dirs approach for InitDir and LogDir
<rogpeppe> fwereade: i hadn't thought about it from that perspective before; let me think a mo
<fwereade> rogpeppe, with a possible view to one day putting those into whatever state dir you choose for the agent
<fwereade> rogpeppe, (one request -- please put them in a subdir, like "agent" or "conf" or something, rather than just in the agent dir)
<rogpeppe> fwereade: any particular reason?
<fwereade> rogpeppe, tidiness :)
 * rogpeppe thinks extra directory hierarchies are often more clutter than tidiness :-)
<rogpeppe> fwereade: too many times i've been in situations where everything is buried in small collections of files in too many directories
<rogpeppe> fwereade: what is the agent dir *for* if not to store this kind of info?
<fwereade> rogpeppe, I guess all the uniter currently has is charm/ and state/, for some reason I thought it was more
<fwereade> rogpeppe, but then state/ is uncomfortable in the same namespace as things like addrs and ca-cert, I think
<rogpeppe> fwereade: if we were dynamically creating all kinds of different names, i'd agree. but for a few well-known names, i'd prefer them at the top level
<rogpeppe> fwereade: i don't think so
<rogpeppe> fwereade: we have control over that name space
<fwereade> rogpeppe, I'm not sure about our discipline levels though -- I have certainly been thoughtlessly dumping uniter-specific stuff directly into the agent's directory
<fwereade> rogpeppe, maybe the answer is that those should be uniter/state and uniter/charm, leaving the "agent" dir to have "agent" things in it
<rogpeppe> fwereade: i dunno. if "state" and "charm" are all there are, i don't see a particular need to have them in their own directory. "uniter.state" and "uniter.charm" might be better if you're worried about collisions.
<fwereade> rogpeppe, yeah, that's not bad
<fwereade> rogpeppe, but as you say probably not even necessary
<fwereade> rogpeppe, anyway, do you agree that exposing deployer.InitDir and .LogDir for tests to mess with is probably the right approach?
<fwereade> rogpeppe, (for now only)
<rogpeppe> fwereade: sounds reasonable, yeah
<fwereade> rogpeppe, cool, cheers -- interesting discussion, looking forward to seeing the cmdline params going away
<rogpeppe> fwereade: me too :-)
 * fwereade -> breakfast
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<rogpeppe> dimitern: am looking at your CL BTW
<dimitern> rogpeppe: ok, thanks!
<fwereade_> dimitern, sent a few comments
<dimitern> fwereade_: thanks!
<jam> mramm: /wave
<mramm> jam: /wave back
<jam> mramm: do you have mumble installed? We generally chat on mumble.canonical.com
<mramm> jam: I don't, installing it now
<rogpeppe> dimitern: you've got some comments.
<dimitern> rogpeppe: cool, ty
<rogpeppe> dimitern: i haven't finished yet, but i thought there's enough for you to be getting on with for the time being
<dimitern> rogpeppe: yes,  and i have some from william as well, so I'll get on to it
<rogpeppe> dimitern: ping
<dimitern> rogpeppe: pong
<rogpeppe> dimitern: i'm looking at lines 852 to 873 and wondering what they do that isn't done by lines 874-876
 * dimitern looking
<dimitern> which file?
<rogpeppe> dimitern: service_http.go, sorry
<dimitern>  rogpeppe: well, the first part handles the more bizarre urls, while the second part handles the main urls
<dimitern> rogpeppe: and also because of the trailing slash auto redirection in net/http server
<jam> wallyworld___: if you're still around, I dug into the openstack code, and it looks like TempURL is a WSGI middleware, which hints that it it something that may or may not be actually installed on a given openstack site
<dimitern> rogpeppe: *missing trailing slash* actually
<jam> wallyworld___: so that would be something to check
<wallyworld___> jam: yes, that agrees with what martin said also
<wallyworld___> jam: i sent an email to someone who has helped me previously, we'll see what comes of it
<rogpeppe> dimitern: can you give me an example?
<dimitern> rogpeppe: ok, so I need to handle /v2/tenant-id/servers/<id> but also /v2/tenant-id/servers (no slash at both places), AND also .../ (any url with trailing slash)
<jam> wallyworld___: right, so it isn't that you need to have an admin set up a temp key for each user, they can do that themselves. But an admin needed to have the whole site have temporary urls enabled.
<dimitern> rogpeppe: the first one will get handled in the /v2/tenant-id/ part, so I need to catch it and handle it with the second
<wallyworld___> jam: yes, so we'll see what we are told as to whether it has been setup for canonistack or not
<rogpeppe> dimitern: won't the /v2/tenant-id/servers handler catch all of them?
<rogpeppe> dimitern: sorry, /v2/tenant-id/servers/
<dimitern> rogpeppe: no, because it's /v2/tenant-id/servers
<rogpeppe> dimitern: well, you'd need a handler for /v2/tenant-id/servers *and* /v2/tenant-id/servers/
<dimitern> rogpeppe: and if it was ../servers/ it will, but I don't need that, since the API expects no slash anywhere at the end
<dimitern> rogpeppe: hmm.. I'll try this it may simplify that func
<rogpeppe> dimitern: that's easy enough to check for (you could even have a general handler, wrapping another handler, that forbids a trailing slash)
<dimitern> rogpeppe: can you give me an example of that?
<rogpeppe> dimitern: ok, one mo
<rogpeppe> dimitern: http://paste.ubuntu.com/1447373/
<fwereade_> yay: http://paste.ubuntu.com/1447375/
<dimitern> rogpeppe: ty
<rogpeppe> dimitern: that's a fairly general technique - you can use it for all kinds of things
<dimitern> rogpeppe: I see, ok, sounds good, will give it a try
<rogpeppe> fwereade_: did the juju charm not work before?
<fwereade_> rogpeppe, I thought it was a subordinate, and it appears to be acting like one :)
<rogpeppe> dimitern: i recommend going for some of my other suggested changes first BTW - they're pretty much orthogonal to the path handling
<fwereade_> rogpeppe, however a bunch of the subordinates declare a juju-info interface :/
<rogpeppe> fwereade_: yay!
<fwereade_> rogpeppe, so I can't work with those
<rogpeppe> fwereade_: hmm, is that not allowed now?
<fwereade_> rogpeppe, duplicate relations were never allowed, it's a straight-up bug IMO
<rogpeppe> fwereade_: ah yeah
<fwereade_> sorry a juju-info *relation*
<fwereade_> rogpeppe, (requiring juju-* interfaces is ok, but not providing them; and hooks and relations can't start with juju-)
<fwereade_> oh, are we meeting?
<rogpeppe> fwereade_: good question
<rogpeppe> fwereade_: i have some lunch smells coming from downstairs
<fwereade_> rogpeppe, oh, no, apparently it's an hour away yet
<rogpeppe> fwereade_: cool. mmm scrambled eggs & smoked salmon on bagels. not so healthy but v tasty
<jam> so I went to: https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7# but so far nobody else has joined. I know I'm still early, but I figured I'd check if I have the right link.
<jam> It was part of one of the calendar invites. (though I seem to have 2 invites... ?)
<dimitern> guys?
<jam> mramm: we see you, but I don't hear you, or you seem to hear me
<jam> rogpeppe: are you still here this week? ^^
<rogpeppe> jam: i am
<rogpeppe> jam: i'm joining now
<jam> sounds good
<fwereade_> wallyworld___, ping
<wallyworld___> hi
<fwereade_> wallyworld___, I seem to be seeing duplicate changes in some of your CLs
<wallyworld___> hmmm. i just lbox proposed them, but there's about 3 branches stacked on each other so perhaps it got confused
<fwereade_> wallyworld___, for future reference, please ease my puny brain by doing `lbox propose -req lp:some/branch`, and the
<fwereade_> wallyworld___, yeah, it doesn't autodetect
<wallyworld___> sorry, i did think i did the -req param but i must have messed it up
<wallyworld___> too many things on the go
<fwereade_> wallyworld___, -req only works the first time you propose I'm afraid
<wallyworld___> i'm also used to just using lp
<fwereade_> wallyworld___, to fix it I think you need to delete the MP and start again
<fwereade_> wallyworld___, from my pov don't waste time with that now
<wallyworld___> oh, so if i lbox propose some futher changes, it doesn't work?
<fwereade_> wallyworld___, yeah, -req status can't change
<wallyworld___> i -req i mean?
<fwereade_> wallyworld___, I think it's a property of the LP MP and LP doesn't let yu change it
<wallyworld___> lp does handle things correctly
<wallyworld___> you can change a base branch and the diffs up the line are all ok
<wallyworld___> i'll just try not to have so much stuff in progress
<fwereade_> wallyworld___, ha, yeah, that's probably the answer
<wallyworld___> part of the issue is the need to land stuff in lock step
<fwereade_> wallyworld___, fwiw LP doesn't seem to know that https://codereview.appspot.com/6923056/ and https://codereview.appspot.com/6929055/ share content either
<wallyworld___> lp only knw about its own diffs, not codereview
<fwereade_> wallyworld___, I *think* lockstep package ugliness is orthogonal to this
<wallyworld___> what i mean is i have to delay goose stuff till jujucore is +1, and visa versa
<fwereade_> wallyworld___, yeah, but LP is claiming a 600-odd-line diff for each of those, and they definitely share content
<wallyworld___> ah ok. that implies i forgot the -req sadly
<fwereade_> wallyworld___, meh, it happens :)
<rogpeppe> boiler man has just come. will be afk for a little
<wallyworld___> plus today go get ate my homework, so when i pushed stuff after that it may have screwed up also
<fwereade_> wallyworld___, you have a review on https://codereview.appspot.com/6923056/ which may cover some others too, I will try to figure it out
<fwereade_> wallyworld___, haha, ouch, that's happened to me too :)
<wallyworld___> i really hate go's lack of proper dependency versioning
<wallyworld___> thanks for wading through all my crap though
<wallyworld___> i owe you a beer
<fwereade_> wallyworld___, np at all, but I may take you up on that all the same ;p
<wallyworld___> ok, for sure
<wallyworld___> right now, i just want to land them all to clear my plate :-)
<fwereade_> wallyworld___, if the bits I've said look good are actually originally from a different branch, feel free to assume their little micro-LGTMs apply
<fwereade_> wallyworld___, the only blocker there is the "local" test
<wallyworld___> ok, i'll look at the email, which local test?
<fwereade_> wallyworld___, https://codereview.appspot.com/6923056/patch/6001/3006
<fwereade_> wallyworld___, or rather https://codereview.appspot.com/6923056/diff/6001/environs/openstack/local_test.go
<fwereade_> wallyworld___, which lets you see my actual comments
<wallyworld___> the was alsoi *think* i just copied the ec2 stuff for that
<wallyworld___> bah
<wallyworld___> ignore the first bit of garbage above
<fwereade_> wallyworld___, (I did mean to fix those tests when I noticed them but... y'know how it is :))
<wallyworld___> np, i'll fix the openstack stuff tomorrow
<wallyworld___> fwereade_: i'm off to bed now (well after midnight here), thanks for reviewing, have a good break if i don't "see" you again before you go
<fwereade_> wallyworld___, cheers, sleep well -- sorry to keep you up
<fwereade_> wallyworld___, and happy holidays :)
<wallyworld___> np, i was awake anyway, too much to do
<fwereade_> rogpeppe, btw, https://codereview.appspot.com/6944058/ has been addressed I think
<fwereade_> and, jam or dimitern (or anyone else on?) I would *really* like to get https://codereview.appspot.com/6946071/ merged before I finish today and want for but one LGTM
<dimitern> fwereade_: ok, looking
<fwereade_> dimitern, awesome
<fwereade_> dimitern, if you're new to the uniter you may have questions, ask away as you encounter them
<dimitern> fwereade_: sure
<dimitern> fwereade_: so basically, instead of reading the state in a few places, you read it once?
<fwereade_> dimitern, that is one of the important bits, yes
<fwereade_> dimitern, the rough chain is:
<dimitern> fwereade_: i didn't see what happened to the ModeStart though
<fwereade_> dimitern, keep a local copy of state, because:
<fwereade_> dimitern, I need to write my started state, and don't have any other easy way of inferring what it should be, and I don't want to have to read state every time I write it
<fwereade_> dimitern, because: I now need to keep track of whether I've run the start hook
<dimitern> fwereade_: yeah
<dimitern> ok
<fwereade_> dimitern, because: I can no longer assume that we've already started when we run config-changed, and the correct action at that point depends on whether we've started
<dimitern> fwereade_: I see
<dimitern> fwereade_: I'm looking at that exactly
<fwereade_> dimitern, I don;t think there ever was a ModeStart -- there's a ModeStarting, which no longer needs to set unit status because ModeConfigChanged will have already done it
<fwereade_> dimitern, and then there's the mode that runs "normally" which is ModeAbide
<dimitern> fwereade_: yeah, ModeStarting
<dimitern> fwereade_: LGTM
<dimitern> it's actually not hard to follow
<dimitern> :)
<fwereade_> dimitern, awesome :D
<fwereade_> dimitern, tyvm
<fwereade__> rogpeppe, heh, deployer tests will be much easier once you've killed the cmdline params too
 * fwereade__ finds something else to do
<rogpeppe> fwereade__: ping
<fwereade__> rogpeppe, pong
<rogpeppe> fwereade__: what do you think of storing the server cert and key inside mongodb?
<rogpeppe> fwereade__: so the only time we need to store them in a file is for mongodb itself
<fwereade__> rogpeppe, not sure what the benefit is
<fwereade__> rogpeppe, we need the cert to connect in the first place though
<rogpeppe> fwereade__: no, we never need the server cert to connect
<rogpeppe> fwereade__: it's for the server only
<fwereade__> rogpeppe, ah, sorry, wrong cert -- and, um, actually not sure at all
<rogpeppe> fwereade__: currently the server cert and key gets passed in cloudinit, but with the api server being a task/worker of the machine agent, we don't necessarily know whether we want to do that when we create the cloudinit script
<fwereade__> rogpeppe, ah, ok, this makes sense
<fwereade__> rogpeppe, yeah
<rogpeppe> fwereade__: storing them in mongodb means that anyone with access to mongodb can act as a state server, which seems reasonable
<fwereade__> rogpeppe, I am generally -1 on storing anything outside state tbh
<fwereade__> rogpeppe, I think I'm firmly +1 on keeping them in mongo
<rogpeppe> fwereade__: ha, we can even store the mongodb passwords inside mongo, i think
<rogpeppe> fwereade__: and i think that might be necessary
<fwereade__> rogpeppe, yeah -- long-term they'll be API passwords, not mongodb passwords, right?
<rogpeppe> fwereade__: no, we will need a mongodb password too
<rogpeppe> fwereade__: otherwise anyone could get access to the mongodb
<fwereade__> rogpeppe, for each agent?
<rogpeppe> fwereade__: and bypass the api
<rogpeppe> fwereade__: i dunno. probably not. maybe just one password
<fwereade__> rogpeppe, that sounds more like it to me, but I may be missing something
<rogpeppe> fwereade__: but we'll still need some way of communicating that password to new machines that we might wish to become api servers.
<rogpeppe> fwereade__: and i think the solution is simply to make it available through the API
<rogpeppe> fwereade__: (only to sufficiently deserving entities, of course)
<fwereade__> rogpeppe, yep, I'm convinced
<fwereade__> rogpeppe, probably one password per deserving entity, I guess
<rogpeppe> fwereade__: maybe, i dunno
<rogpeppe> fwereade__: probably, as that's exactly what we do now
<rogpeppe> fwereade__: depends if mongodb provides some kind of log of stuff any particular user has done
<rogpeppe> fwereade__: if not, there's probably no point
<fwereade__> rogpeppe, all will no doubt become clear in the fullness of time :)
<rogpeppe> fwereade__: only problem is i can't store the server cert and key in the state currently, because everyone has access to it.
<rogpeppe> fwereade__: gotta go, haven't got it working yet, sorry.
<rogpeppe> g'night all
<hazmat> anybody around?
<hazmat> just trying to verify go 1.0.2 is the one with the http client regression
<hazmat> cause its also the distro version for golang in quantal i believe..
<arosales> davecheney: Hello
<arosales> fwereade_:  you guys having a G+ hangout?
<davecheney> arosales: doubt it
<davecheney> isn't mark on medical leave ?
<arosales> he is, but he asked I kick a G+ off if folks were interested in having one.
<arosales> davecheney: just saw you and fwereade_ in channel though  . . .
<davecheney> william is _supposed_ to be on leave
<arosales> :-)
<arosales> davecheney: so its just you huh
<arosales> at this time anyways
<fwereade_> arosales, davecheney: I, er, sort of am -- I'm just writing documentations, which hardly counts as work ;p
<davecheney> arosales: two secs, changing computers
<fwereade_> arosales, davecheney: but no, I don;t really fancy a call ;)
<arosales> fwereade_: hey thats my whole job ;-)
<arosales> lol
<fwereade_> arosales, it was perhaps hard to detect the irony dripping from my voice
<fwereade_> or not ;)
<arosales> fwereade_: ah
<fwereade_> but, y'know, the CL's still open and if I come back to it in 2 weeks it'll be the last thing I want todo
<arosales> fwereade_: davecheney: totally up to you guys on a G+. Only if it is useful or you need some one to say hello to :-)
<fwereade_> arosales, I'm good thanks :)
<arosales> fwereade_: I'll let you get back to the all too important work of docs ;-)
#juju-dev 2012-12-19
<rogpeppe> mornin!
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: hey, I wanted to ask you about your suggestion to implement a response which is also an error
<rogpeppe> dimitern: ok
<dimitern> rogpeppe: what do I need there? func (resp..) Error() string ?
<rogpeppe> dimitern: exactly that
<dimitern> rogpeppe: and how to verify the type? x.(respError) ?
<rogpeppe> dimitern: i suggest you use *response throughout, as it's conventional to use pointer types for errors
<dimitern> rogpeppe: ok
<rogpeppe> dimitern: the type is already verified - it's the receiver
<rogpeppe> dimitern: ah, you mean for actually sending the error?
<dimitern> rogpeppe: a short example of your idea will be appreciated
<rogpeppe> dimitern: ok, one mo
<rogpeppe> dimitern: i'm thinking of something like this: http://paste.ubuntu.com/1449605/
<dimitern> rogpeppe: 10x!
<rogpeppe> dimitern: there are quite a few places that might be different based on requirements, but i *think* the basic idea is sound
<dimitern> rogpeppe: I'll try it out, looks good
<dimitern> rogpeppe: couldn't I instead of having all the fields of the response object, just embed it, then I'll have send(w, r) already and just need Error() string
<rogpeppe> dimitern: do you actually need the response type any more?
<dimitern> rogpeppe: also, is there a particular reason to create *errorResponse vars instead of non-pointers?
<dimitern> rogpeppe: ah, you mean replace it, ok
<rogpeppe> dimitern: error types are conventionally pointers
<dimitern> rogpeppe: but is it enough to have Error() on it to be treated like *error ?
<rogpeppe> dimitern: it is, yes
<rogpeppe> dimitern: but concrete error types are usually pointers
<dimitern> rogpeppe: ok, cool, I though it was more complex :)
<rogpeppe> dimitern: BTW s/*error/error/ above
<rogpeppe> dimitern: the error interface is just interface{Error() string}
<dimitern> rogpeppe: but then not all responses are errors, wouldn't it be misleading to call it errorResponse?
<rogpeppe> dimitern: AFAICS you're only using the response type for errors currently
<dimitern> rogpeppe: well, not exactly - noContentResponse is one example
<dimitern> acceptedResponse is another
<rogpeppe> dimitern: both of those seem like things that could be done inline or with a simple helper function
<rogpeppe> dimitern: (neither include any significant nova-specific text)
<dimitern> rogpeppe: well, they're exactly as nova sends them, but I'll think of a helper
<rogpeppe> dimitern: both of them can be done by simply setting the http status code
<rogpeppe> dimitern: as in, w.WriteHeader(http.StatusNoContent)
<rogpeppe> dimitern: i don't think you need anything more
<dimitern> rogpeppe: I need the body for accepted
<dimitern> rogpeppe: but I'll create a simpleResponse or something for that
<rogpeppe> dimitern: accepted has an empty body - don't you get that by default?
<dimitern> rogpeppe: yes, you're right, actually for swift there was a body
<rogpeppe> dimitern: anyway, if you do need a custom body, a helper like your sendJSON function would work fine
<dimitern> rogpeppe: ok
<jam> rogpeppe: I found the reason mongod is failing to start: error command line: unknown option sslOnNormalPorts
<rogpeppe> jam: ah!
<rogpeppe> jam: you need to use the mongodb that we're using in the cloud
<rogpeppe> jam: doh, i should have thought of that
<jam> dimitern: ^^ so the issue is that mongod that is available by default from Ubuntu doesn't have the new flags that juju-core wants.
<jam> rogpeppe: where can you get that one? A ppa?
<jam> build from scratch?
<jam> rogpeppe: oddly enough, .Start() sees no failure, but we also don't set cmd.Stderr or cmd.Stdout to anything, so we never see that it actually says there is a problem.
<rogpeppe> jam: fetch it from s3. you can find the URL in environs/cloudinit.
<dimitern> jam: so that was the problem
<jam> d
<jam> dimitern: that was the first problem at least
<rogpeppe> jam: start won't see a failure, because the binary started just fine
<jam> rogpeppe: and then put it where?
<rogpeppe> jam: in your path
<rogpeppe> jam: http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-$series-$arch.tgz
<rogpeppe> jam: i think we've only built it for precise and quantal so far
<rogpeppe> jam: and amd64
<jam> rogpeppe: I'm on quantal which is fine, but 32-bit, and http://juju-dist.s3.amazonaws.com/tools/http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-quantal-amd64.tgz still gives me 404
<rogpeppe> jam: presumably you didn't double up the URL when you actually tried it?
<jam> I did, I guess.
<jam> i386 doesn't exist
<jam> amd64 does
<rogpeppe> jam: there's a builddb charm if you want to build your own
<rogpeppe> jam: unfortunately there's a chicken/egg problem, i think
<rogpeppe> jam: 'cos i'm not sure we can have units with a different architecture to the bootstrap node yet
<rogpeppe> jam: you might be able to use the python juju to run the builddb charm on 386
<jam> rogpeppe: so to go back to a bit more basic, what is a good way to make sure the test suite doesn't just hang with no information in these circumstances?
<jam> It seems to wait indefinitely to try to connect to a mongod that isn't running
<rogpeppe> jam: it's a good question. the problem is that mongodb prints out shitloads of info, far too much to log by default
<jam> (I may have to switch to 64-bit, but dimitern still has that problem without indication of what is wrong)
<rogpeppe> jam: i'm not sure if it prints to stdout or stderr though
<rogpeppe> jam: one possibility might be to wait for a little while after starting mongodb, to make sure it doesn't exit quickly with a usage or similar startup error
<jam> rogpeppe: well my thought is that whatever bit is polling trying to connect to the port could timeout if it hasn't connected, then check if the child process is running, then try to connect again
<jam> rather than to just hang trying to connect.
<jam> not sure how the layering is.
<jam> Unfortunately, the "bad command line" error message goes to Stdout, just like all the other spew when things are working correctly.
<rogpeppe> jam: the code that is trying to connect is just the regular state open code - it has no idea that it's connecting to a local mongodb
<jam> we could still put that into a bytes.Buffer in case we want to log it because the process died early.
<jam> rogpeppe: but why would state.Open wait indefinitely either?
<rogpeppe> jam: because we might be connecting to a mongodb on an instance that's starting up, which may take 10 minutes
<rogpeppe> jam: i think that probably the code that starts mongodb should log something when mongodb dies.
<jam> rogpeppe: so the code starting mongo is MgoTestPackage, which has a defer destroyMgoServer
<rogpeppe> jam: yup
<jam> would it be sensible to start a goroutine to monitor it for stopping early (not by destroy) and log something?
<rogpeppe> jam: i think so. although there may be subtle issues around that. i'll have a look.,
<jam> rogpeppe: there doesn't seem to be a exec.Cmd.Poll()
<jam> just Wait()
<rogpeppe> jam: Wait should be sufficient
<jam> rogpeppe: so how does it get layered if you want to Wait() to see if it exits early, but have a kill switch in destroy...() so that if destroy is stopping it, that the Wait goroutine doesn't print debug info.
<jam> I'd also arguably like to grab log info, but preferrably not buffer all of it for the whole lifetime of the process.
<rogpeppe> jam: it's not too hard - i'll knock something up
<rogpeppe> jam: i think it's easier just to buffer the whole thing
<rogpeppe> jam: otherwise you'll need to implement some kind of bounded buffer, which is probably unnecessary.
<jam> well, its easier, but the total output from mongodb during the course of a full test suite (it is started once at the beginning, and not shut down until the test suite finishes) could be a bit much
<rogpeppe> jam: i guess, but what's a few MB these days? :-)
<jam> so dimitern, short answer for you is to download http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-quantal-amd64.tgz and put the binary in your path, we'll try to sort out the rest.
<jam> rogpeppe: as long as it is small MB, not a big deal.
<dimitern> jam: yeah, pity I'm still on precise
<jam> dimitern: there should be a precise-amd64 as well
<rogpeppe> dimitern: precise works too
<jam> there just isn't a i386 version.
<dimitern> ah, ok
<jam> rogpeppe: a thought. You could wait until you get 1 line of output from mongodb since you end up waiting for it to start regardless.
<jam> if it then dies, you can log the output
<jam> at least, if there is a commandline problem, you'll see it right away.
<jam> though having a bigger "dump the mongodb output if the process dies" would be useful for lots of other sorts of failures
<jam> so it is probably good to have something more generic anyway.
<rogpeppe> jam: you'll see the line of output before you know if it's died with an error
<rogpeppe> jam: so you'll still have to wait a while to see if you want to print the line
<jam> rogpeppe: well the one line is "error command line: ..."
<rogpeppe> jam: so we catch that one particular class of error, but there may be other kinds of error that don't fit that pattern
<jam> yeah
<jam> so if you had a way to short-term Wait() it would work
<jam> but you don't, you have to put out a goroutine to wait and put it on a channel or whatever.
<rogpeppe> jam: we can easily short-term wait if we want to
<jam> rogpeppe: I don't see a way to interrupt Wait()
<jam> so how do you make it 'short-term' ?
<rogpeppe> jam: as you say, start a goroutine that does wait and sends the result on a channel
<jam> rogpeppe: which means it is around forever?
<rogpeppe> jam: sure, why not?
<jam> rogpeppe: I don't see a "builddb" charm in the charmworld "precise" list that I downloaded, I do see mongodb, but no mention of builddb. Is there a doc I should be looking at?
<jam> BTW, the 'README' should be updated with how to install mongodb, since "apt-get install mongodb" isn't sufficient anymore.
<rogpeppe> jam: builddb is a command in the source tree. tbh, i think it should just be a charm, but it was an interesting experiment.
<rogpeppe> jam: BTW it seems that mongodb always does exit(0) even when it gets a usage error
<rogpeppe> jam: marvellous
<jam> rogpeppe: how very nice of it. But at least you could detect that it had exited early, I guess.
<jam> so just running "builddb" it tries to bootstrap my environment and says it is already bootstrapped...
<rogpeppe> jam: that's true. i think it should never exit unless killed, and that's easy to detect
<rogpeppe> jam: yeah, it shouldn't bootstrap. have you actually got a bootstrapped environment, or is that just a hangover from a previous bootstrap?
<jam> rogpeppe: I probably ran something in the past
<rogpeppe> jam: if the latter, just do juju destroy-environment first
<rogpeppe> jam: https://codereview.appspot.com/6966045
<dimitern> rogpeppe, fwereade_: PTAL https://codereview.appspot.com/6940073/
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: you've got another review
<dimitern> rogpeppe: cheers!
<dimitern> rogpeppe: ok, I'm a bit confused why you think sendError(err, w, r) is redundant - how can I send errors which are not errorResponse then?
<rogpeppe> dimitern: novaHandler.ServeHTTP handles this case
<rogpeppe> dimitern: that's why you're testing for err.(http.Handler)
<dimitern> rogpeppe: you mean after the internal handler is called?
<dimitern> rogpeppe: I see, ok
<rogpeppe> dimitern: basically, we allow some errors to know how to marshal themselves as an http response.
<rogpeppe> dimitern: others we use the default internal error for
<dimitern> rogpeppe: and others we wrap, yeah, nice!
<dimitern> rogpeppe: I wanted something like that initially, but wasn't sure how's best
<rogpeppe> dimitern: i think it works quite nicely :-)
<rogpeppe> dimitern: it's a pity that we need to match all the real server's errors so exactly. it really clutters the code.
<dimitern> rogpeppe: yeah, but I was thinking of implementing like a generic subhandler for a path + method
<dimitern> rogpeppe: then, I can have several of these which are just doing the same (like put/post or get/delete pairs - lots of these can be trimmed)
<rogpeppe> dimitern: that probably wouldn't be too hard.
<dimitern> rogpeppe: assuming we define them similarly in a map like setupHTTP
<dimitern> rogpeppe: or, maybe even better - implement them an get a helper to be called for a list of methods, path and handler
<dimitern> rogpeppe: come to think of it, not even the path is needed
<dimitern> rogpeppe: can I have a handlersMap := map[[]string][]*handler
<rogpeppe> dimitern: no
<rogpeppe> dimitern: but there's actually no particular reason for handlersMap to be a map
<rogpeppe> dimitern: tbh, i'm not sure how much you'd win
<dimitern> rogpeppe: yeah, probably shouldn't bother anyway - this is just a testing service
<dimitern> rogpeppe: i should just work
<rogpeppe> dimitern: i think it's quite nice to have all the irregularity of the server's interface laid out so it's easy to see. like errNotFound vs errNotFoundJSON, wtf?!
<dimitern> rogpeppe: yep, it's like that - probably as a result of stitching different backends together :)
<dimitern> rogpeppe: or more likely smart inner and quick and dumb outer API handlers - the inner taking into account I said Accept: json
<dimitern> rogpeppe: and the outer just returning 404 plain early for unexpected URLs
<hazmat> rogpeppe, do you happen to recall which version of golang has the broken http client.. one of our lbox users is still hitting panics.. even after a manual compile of lbox with 1.0.3 ... https://pastebin.canonical.com/80719/
<rogpeppe> hazmat: 1.0.3
<rogpeppe> hazmat: the most recent version, unfortunately
<hazmat> eek
<rogpeppe> hazmat: they could use tip or 1.0.2
<hazmat> rogpeppe, so 1.0.2 which is the default in the quantal archive should work ok then
<hazmat> cool
<rogpeppe> hazmat: it should
<hazmat> rogpeppe, thanks
<rogpeppe> hazmat: np
<hazmat> rogpeppe, i think he tried it with 1.0.2 as well, but i'll verify next year (he's on holiday)
<dimitern> rogpeppe: ping
<rogpeppe> dimitern: pong
<dimitern> rogpeppe: I'm almost done, fixing a few tests, but I'm having trouble debugging "multiple WriteHeader calls" message - how can I plug into the log that gocheck uses?
<rogpeppe> dimitern: is that a panic, or is WriteHeader returning an error?
<dimitern> rogpeppe: "2012/12/19 17:20:12 http: multiple response.WriteHeader calls" - think it's more like a warning
<rogpeppe> dimitern: i recommend just finding that log message in the http package and turning into a panic, then running the test again
<rogpeppe> dimitern: (remember to change it back afterwards...)
<rogpeppe> dimitern: there are other ways, but that's the easiest
<rogpeppe> dimitern: alternatively, change all occurrences of WriteHeader in your code to call a local function that writes a log message before calling WriteHeader
<rogpeppe> dimitern: (that should be easy enough to do with a global substitution)
<dimitern> rogpeppe: ha, ok.. wouldn't think it's that easy :)
<dimitern> rogpeppe: ok, all done, please take a look, I'd really like to land this today https://codereview.appspot.com/6940073/
<rogpeppe> dimitern: looking (thanks for bearing with me - i hope you think it's worth it!)
<dimitern> rogpeppe: sure, I appreciate your comments and see how to do things simpler in the future
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe: thanks!
<dimitern> rogpeppe: ready with all suggestions - do you want to look at it or I should just submit it?
<rogpeppe> dimitern: i'll just have a quick look
<rogpeppe> dimitern: have you proposed it?
<dimitern> rogpeppe: it's under way
<dimitern> https://codereview.appspot.com/6940073
<rogpeppe> dimitern: reviewed. looks great. two small things still to do, but it looks great in general.
<dimitern> rogpeppe: thanks again
<dimitern> rogpeppe: with these, I'm submitting
<rogpeppe> dimitern: great
<dimitern> I'm off then, 'night guys!
 * rogpeppe is off too.
<rogpeppe> g'night all
<fwereade__> rogpeppe, heyhey, I'm very much not working -- but if you are later this week, I'd love a final look at https://codereview.appspot.com/6944058/
<rogpeppe> fwereade__: me neither currently (just playing with new camera) but will look tomorrow
<fwereade__> rogpeppe, cheers :)
#juju-dev 2012-12-20
<jam> wallyworld_: I figured out what broke the test suite for the "no such variable hostname".
<jam> The issue is that "hostname" is defined in service_test.go, but used in "service_http.go".
<wallyworld_> ah ok, i looked but didn't see how i broke it
<jam> So everything works fine when you run tests in novaserviec
<wallyworld_> i found that too
<jam> because it imports the test files to run the test suite.
<jam> but when "nova" tests import "service_http"
<jam> it doesn't import the test files
<jam> (because it shouldn't)
<wallyworld_> makes sense
<jam> so it is one of those cases where test definitions leak and make real code pass
<jam> when it is broken if you try to use it directly.
<wallyworld_> too bad go fmt doesn't check compilation
<wallyworld_> there's also another breakage
<jam> wallyworld_: right, so "go build" doesn't work in the novaservice directory
<wallyworld_> to do with nova something or other not implementinng HTTPServe
<jam> so we should be using: go build ./... && go test ./...
<wallyworld_> go test ./... fails if there is a compile error
<wallyworld_> so perhaps go build is redundant there
<jam> and, as I've said before, global state is terrible, we shouldn't have it in the first place.
<wallyworld_> yeah, agree
<jam> wallyworld_: As I just said, cd testservice/novaservice ; go test passes
<jam> go build fails
<jam> we didn't *notice* until we used novaservice in nova testing.
<wallyworld_> hmm, i've never seen go test not have an error if go build fails
<jam> because nova doesn't import the novaservice test package
<jam> wallyworld_: try it right now with trunk
<wallyworld_> i'm prototyping in trunk, so it's a bt hard atm
<wallyworld_> i need to create a new branch to work in
<jam> wallyworld_: essentially, we had a latent build failure that we didn't see at r40, in r41 you started importing the code, and triggered the failure.
<jam> wallyworld_: "bzr shelve" ?
<wallyworld_> yeah, but i don't want to disrupt my train of thought just atm
<jam> wallyworld_: np
<wallyworld_> thanks for looking into that further, i was going to mention itagain at the standup
<hazmat> so for updating the juju-core src tree w. goose .. what do folks do.. go get -u ?
<jam> hazmat: yes
<jam> its not perfect, but it seems to be the best we have right now
<hazmat> jam.. with what value/pkg name?
<jam> hazmat: "go get -u launchpad.net/juju-core/..."
<jam> should also update all dependencies
<hazmat> jam, thanks
 * hazmat always forgets where to put ...
<hazmat> i'm sure its easy once your used to it
 * hazmat wonders if roger published his api callee tool
<hazmat> aha http://godoc.org/code.google.com/p/rog-go/exp/cmd/gosym
<jam> wallyworld_: poke if you are still around
<wallyworld_> hi
<jam> wallyworld_: so it might just be naming, but I'm looking over the code you pushed up, and it doesn't quite sit right.
<wallyworld_> which bit?
<jam> "unauthenticatedClient": IMO unauthenticated is a state that can be remedied by authenticating
<wallyworld_> ok, i am happy to change names
<jam> and having an Authenticator that doesn't authenticate...
<wallyworld_> it's a means to allow code to be shared
<wallyworld_> so the core logic to send requests can be ignorant of if it is running with somwthing that needs authenticatin
<wallyworld_> so the authentication stuff is just noops
<jam> so, nonAuthenticatingClient seems to me like a client that wouldn't try to authenticate (naming), but I don't know that it would be an Authenticator.
<jam> wallyworld_: but is that better than just having a boolean about whether it *needs* to authenticate?
<wallyworld_> hmmm. i could look at that for sure
<wallyworld_> the AUthentication interface though also provides MakeServiceURL
<wallyworld_> since that is different depending on the type of client
<wallyworld_> and go doesn't support virtual methods :-(
<wallyworld_> i really wanted to do it differently, like I would have in Java or C++, but alas
<jam> wallyworld_: I agree that we likely need an interface at that level, I'm just trying to sort out how the pieces fit. And at least the naming of things meant it didn't quite fit well in my head.
<wallyworld_> i did struggle with the naming
<wallyworld_> the auth client needs to provide Authernticate(), UserId(), Token() etc
<wallyworld_> and the non auth client needs to provide noops for those if we want to allow the same client interface to be used everywhere
<wallyworld_> unless I cast when needed
<wallyworld_> which I can do
<jam> wallyworld_: since we won't have any of that actual data, it seems like we should be doing it differently.
<jam> we shouldn't return fake data for each one.
<jam> like, if we don't have an authenticator, we try to do the request without authentication
<jam> vs we have one that may just not have auth'd yet
<wallyworld_> i was trying to avoid type casts but i think i will need to do that
<wallyworld_> i'll rework it and resubmit
<jam> c.auth != nil doesn't need a type cast :)
<wallyworld_> i wasn't 100% happy with the result, but I was happy that it all worked
<wallyworld_> no not there, in other places
<wallyworld_> like tests
<wallyworld_> but let me rework it - the 2nd version should be better
<Aram> > go doesn't support virtual methods
<wallyworld_> yeah i know :-(
<Aram> what? dynamic dispatch is an extremely used idiom in Go.
<jam> Aram: go doesn't support subclassing in the standard sense
<jam> is I think more what he was talking about
<wallyworld_> methods are staically bound to classes
<Aram> use an interface.
<wallyworld_> it's a limitation Java and C++ refugees initially have to learn to deal with
<wallyworld_> yes, the zgo idiom is an interface but sometimes it would be easier not to have to do that
<Aram> you don't have to do anything. you define an interface and type i := c somewhere instead of typing C implements I somewhere else.
<wallyworld_> you do have to rearrange your business logic sometimes
<wallyworld_> if you are used to virtual methods and expect a subclass to invoke the right method, you need to extract the business logic when you discover it doesn't work
<wallyworld_> to get it off the class and into an interface created just because virtual methods aren't supported
<Aram> i.m() always invokes the right method if you set up i correctly (equivalent to setting a subclass correctly)
<Aram> s/ui i/it up/
<wallyworld_> yes, but it's a different arrangement of business logic and sometimes it means that stuff which belongs together on a class has to be split
<wallyworld_> because of non support for virtual methods
<wallyworld_> it's not such a big issue, just different to other languages which support such things
<Aram> have to go buy some bread.
<Aram> rogpeppe: ^ ^
<jam> wallyworld_: if you can set the MP to WIP (I can do it, but I'd rather not do that to other people's MPs)
<wallyworld_> jam: sure, thanks for the input, i'm glad you brought up the same issues i was having when i hit submit :-)
<jam> wallyworld_: I'm glad you felt the same way, too. :)
<wallyworld_> jam: yeah, it was EOD and I just wanted to feel i had something done, so i thought it would be worth getting input
<rogpeppe> jam, wallyworld: i'll have a look at this
<wallyworld_> rogpeppe: thanks, although i'm setting it back to wip to clean up some stuff, so don't look too hard just yet
<rogpeppe> jam: in my experience, when these kinds of issues are resolved, the result is better structured.
<rogpeppe> s/jam/wallyworld/ :-)
<wallyworld_> which issues? the virtual method dicussion?
<rogpeppe> wallyworld_: yes
<rogpeppe> wallyworld_: presumably we're talking about https://codereview.appspot.com/6962052/ here?
<rogpeppe> wallyworld_: (i haven't looked at it yet)
<wallyworld_> yes
<wallyworld_> i do like virtual methods, but if they are no supported, then stuff needs to be done differently
<rogpeppe> wallyworld_: i'm not sure what you mean. all interface methods are virtual
<wallyworld_> i mean on classes
<wallyworld_> stucts
<wallyworld_> structs
<rogpeppe> wallyworld_: ah, you mean a class hierarchy isn't supported. that's true.
<wallyworld_> yeah, so logic in a bases class calls method foo() and if it is a subclass, the subclass's foo() get invoked
<wallyworld_> since that's not supported, you are forced to rip logic out of a class where it might be considered to belong
<wallyworld_> and put it elsewhere
<rogpeppe> wallyworld_: this is actually a good thing, although it's probably difficult to see that currently...
<wallyworld_> yeah, difficult to see :-) since if everything else does it, it can't be that bad :-)
<rogpeppe> wallyworld_: each type does what it does completely.
<wallyworld_> and it causes issues when you loose access to class state when the logic is removed
<wallyworld_> it's not necessarily bad, just different
<rogpeppe> wallyworld_: in the end, IMHO, you get a better separation of concerns and more modular code.
<wallyworld_> i'll take your word for it, i'm still to come around to that way of thinking :-) not enough Go experience yet
<wallyworld_> i guess many people new to go have to unlearn past habits
<rogpeppe> wallyworld_: it's certainly a different way of thinking. i think perhaps the crux is moving from thinking, when designing, "what *is* this?" to "what does this *do*?"
<rogpeppe> wallyworld_: Go doesn't do "is a" relationships, other than when implementing interfaces
<wallyworld_> sure, i guess at the moment i don't see that "what does this do" way of thinking is mutually exclusive to having virtual methods. but maybe i'll get there
<wallyworld_> i'm actually having more of an issue with go's dependency version management
<rogpeppe> wallyworld_: AFAICS, virtual methods are about defining something that is *almost* something else (but for the virtual methods).
<rogpeppe> wallyworld_: yes, that's unfortunate - i have an idea for a little tool that might help with that.
<wallyworld_> rogpeppe: it seems that many go people will defend the current state of affairs with go get etc, even though it just seems so wrong
<wallyworld_> mixing what you are importing with the version you are import in the url which is then spread through every source file seems crazy to me
<wallyworld_> violates the dry principal big time
<rogpeppe> wallyworld_: i'm not sure. it doesn't seem too different from having the version in some metadata file somewhere in the same source tree
<wallyworld_> big difference - you change the meta file in one place
<wallyworld_> not update each and every import
<rogpeppe> wallyworld_: sure, it's repeated info, but what if it was a single two-word command to change all the paths (and check consistency)?
<wallyworld_> it introduces revision noise for starters
<rogpeppe> wallyworld_: in the CL diffs?
<wallyworld_> yes, and source revision history
<rogpeppe> wallyworld_: i'm not sure that's a big issue. you're going to have a revision change there anyway (for the metadata) - the only question is the size of the diff.
<wallyworld_> when reviewing or looking at past revisions, any excess noise distracts from trying to get to the heart of any changes
<wallyworld_> and why repeat something all throughout the source code?
<rogpeppe> wallyworld_: because it makes the version dependency clear in every piece of code that has it?
<rogpeppe> wallyworld_: i agree it's verbose, but i'm not sure that i see a better alternative currently.
<wallyworld_> that is true but i feel the cost outweighs the benefit
<wallyworld_> there's lots of better alternatives :-)
<wallyworld_> other languages/environments have solutions used successfully
<rogpeppe> wallyworld_: there are quite a few benefits from having the package path as a universal currency that works independently of anything else.
<wallyworld_> perhaps if it weren't copy and pasted throughout the source code
<rogpeppe> wallyworld_: honestly, i think that's a benefit. each piece of source code completely describes its own dependencies.
<wallyworld_> each peice of source code doesn't need to do that though - it's surperfulous boiler plate
<wallyworld_> humans make mistakes and i would be surprised if someone didn't miss changing one import somewhere, or worse, 2 people committed at around the same time with different imports
<wallyworld_> since the imports are repeated, someone might write a new source file with the "old" import version
<wallyworld_> and commit that not realising someone else has committed a change which updates the imports elsewhere
<rogpeppe> wallyworld_: ok, here's my plan for a tool
<rogpeppe> wallyworld_: called, say, godep
<rogpeppe> wallyworld_: usage: godep pkg....
<rogpeppe> wallyworld_: it will look in all the source files under the current directory, and find any that have a version-independent matching package path
<rogpeppe> wallyworld_: and change it to the specified package path
<dimitern> wallyworld_, jam, etc. PTAL - just some comments and improved docs -  https://codereview.appspot.com/6968051
<rogpeppe> wallyworld_: where a versioned package path is defined to be anything with an intermediate path name matching v[0-9]+
<rogpeppe> s/intermediate path name/intermediate path element/
<wallyworld_> rogpeppe: so the first time it is run, version independent paths get changed, but what about the next time?
<rogpeppe> wallyworld_: it will also check all dependencies and make sure that they all import the same version
 * dimitern >> lunch
<rogpeppe> wallyworld_: all paths are versioned
<rogpeppe> wallyworld_: just that labix.org/v2/mgo will match labix.org/v3/mgo, for example
<wallyworld_> ah ok
<rogpeppe> actually, govers was the name i was thinking of originally
<wallyworld_> rogpeppe: that all sounds reasonable. it's the go equivalent of editing versions.cfg and changing mgo v2 to mgo v3 and comitting :-)
<rogpeppe> wallyworld_: so then, to make juju-core use a new version of goose, you'd cd to juju-core root, and do govers launchpad.net/goose/v2
<rogpeppe> wallyworld_: yes, but without the commit
<wallyworld_> right
<wallyworld_> rogpeppe: late here, off to bed, thanks for the interesting discussion. too bad it wasn't at a pub over some beers
<rogpeppe> wallyworld_: too right
<wallyworld_> next UDS maybe :-)
<rogpeppe> wallyworld_: lets!
<rogpeppe> wallyworld_: sweet dreams :-)
<wallyworld_> be warned, i start dancing on the table after i have 1 or 2 pints
<rogpeppe> wallyworld_: lol
<rogpeppe> Aram, dimitern, fwereade_: i'd be interested to know what you think of the above idea
<hazmat> rogpeppe, would you have any time today or tomorrow to discuss api
<rogpeppe> hazmat: definitely
<rogpeppe> hazmat: could do it now if you'd like
<hazmat> rogpeppe, sounds good
<rogpeppe> hazmat: https://plus.google.com/hangouts/_/2887f22fb3213cc9e9ccd07cd3569c8e06a255ee?authuser=0&hl=en-GB
<fwereade__> rogpeppe, I hate to be a bore, but I think that https://codereview.appspot.com/6944058/ is uncontroversial in the light of our discussions online, and so I hope it should be an easy re-review
<rogpeppe> fwereade__: ok. i thought you were on hols! :-)
<rogpeppe> fwereade__: am on it
<fwereade__> rogpeppe, I am, but, y'know -- laura is painting, cath's out buying booze, I am otherwise at a loose end ;p
<rogpeppe> fwereade__: here's a little one for you (preparatory to losing flags from jujud): https://codereview.appspot.com/6972048/
<fwereade__> rogpeppe, cool
<fwereade__> rogpeppe, except that CL apparently does not exist
<rogpeppe> fwereade__: oh bugger, one mo
<rogpeppe> fwereade__: https://codereview.appspot.com/6963050/
<rogpeppe> fwereade__: (i proposed it against a badly named branch originally)
<rogpeppe> fwereade__: LGTM
<fwereade__> rogpeppe, thanks -- and likewise :)
<fwereade__> rogpeppe, I won;t merge it for a bit yet, so go ahead with yours if it's convenient
<rogpeppe> fwereade__: it's fine - i'm actually knocking up a quick tool to try to ease the goose versioning pains
<rogpeppe> fwereade__: i'd be interested in your views on the idea actually
 * rogpeppe is off for the night.
<rogpeppe> g'night anyone who's around
<arosales> jcastro_: ping
<hazmat> arosales, aren't you on holiday
<arosales> hazmat:  sudo holiday :-)
<jcastro_> that should be pseudo holiday, heh
#juju-dev 2012-12-21
<rogpeppe> wallyworld_: ping
<rogpeppe> fwereade: yo!
<rogpeppe> Aram: hiya
<fwereade> rogpeppe, Aram: heyhey, not really here tbh
<rogpeppe> fwereade: just replied to https://codereview.appspot.com/6966045/ . i'm not sure it needs a comment, but YMMV.
<fwereade> rogpeppe, ah, ok, LGTM then
<rogpeppe> Aram, fwereade: i'd be interested in any reaction you have to my govers tool that i hacked up yesterday afternoon.
<rogpeppe> Aram, fwereade: launchpad.net/govers
<rogpeppe> i made a post to juju-dev about it
<rogpeppe> will be on and off line for a couple of hours from now.
<Aram> rogpeppe: fwereade_: mramm2: going now. I wish you all merry christmas and a happy new year! I'll be back on January 7th.
<rogpeppe> Aram: me too
<rogpeppe> Aram: merry christmas to you too!
<rogpeppe> Aram: have a great one
<rogpeppe> Aram: see ya in the new year
<Aram> cheers!
#juju-dev 2013-12-16
<thumper> o/ axw
<axw> hey thumper
<thumper> axw: can I talk some things through with you?
<axw> thumper: certainly
<axw> hangout?
<thumper> axw: https://plus.google.com/hangouts/_/72cpidoufej0otv9gnrrc6cbns?hl=en
<axw> thumper: are you aware of any particular reason why we use a static bootstrap nonce?
<thumper> axw: nope
<axw> thumper: I'm thinking of using that to verify that the machine is in fact the bootstrap node
<axw> would need to be made a UUID tho
<thumper> I can't really think of a reason not to change the bootstrap nonce to a uuid
<thumper> I would consider checking with fwereade just in case there is a reason we aren't aware of
<axw> thumper: thanks, will do
<thumper> axw: how to I assert in a test that two slices may have the same content but have different underlying arrays?
<thumper> axw: or in another way, should I care?
<axw> thumper: DeepEquals
<axw> oh
<thumper> axw: I'm writing a gnuflag.Value for []string
<axw> you want to know that they *must* be different?
<axw> why?
<thumper> that wrapts the comma separated values
<thumper> I guess I shouldn't care
<thumper> the default value is fine?
<thumper> value[:] forces a copy?
<axw> [:] creates a new slice, but the backing array/slice is the same
<thumper> I think I'm caring too deeply
<thumper> I think this'll be ok
 * thumper discards the need to be different
<axw> sounds like it, but I don't quite understand the use case :)
<thumper> axw: I'll show you the code in a while :)
<axw> okey dokey
<thumper> axw: http://paste.ubuntu.com/6581765/
<axw> looking
<thumper> axw: and the tests http://paste.ubuntu.com/6581766/
<thumper> seems to work how I'd like
<thumper> also noticed that gnuflag already has a time.Duration type
<thumper> which uses the go ParseDuration
<axw> cool
<thumper> A duration string is a possibly signed sequence of decimal numbers, each with optional fraction and a unit suffix, such as "300ms", "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "Âµs"), "ms", "s", "m", "h".
<thumper> but no days
<thumper> but I think that's fine
<thumper> not quite sure what -1.5 hours is
<thumper> but can set the test timeout to 50ms :)
<axw> yeah I think that'll do
<axw> thumper: where were you going to check backing arrays?
<axw> looks fine as is anyway
<thumper> axw: probably paranoia
<thumper> axw: but I agree, seems fien
<thumper> fine
<thumper> axw: is there a pop front type method on slices?
<axw> thumper: nope
<thumper> :(
<axw> [1:]
<thumper> except I need to do: value, args := args[0], args[1:]
<thumper> when I want to write: value = args.pop_front()
 * thumper shrugs
<thumper> see y'all tomorrow
<dimitern> guys, fwereade has power issues and is waiting for someone to come and fix them - just texted me, so i'm letting y'all know
<axw> thanks dimitern (and hi)
<axw> dimitern, jam: do either of you know if there's a reason why we have a static nonce for the bootstrap node?
<dimitern> hi axw
<dimitern> axw, yes, because there's no state yet to verify the nonce from
<axw> dimitern: ok. it won't break anything if I make it random tho right? I see very few references to it
<axw> dimitern: I'd like to use it to verify the machine connected to during synchronous bootstrap is the right one
<dimitern> axw, in some places it might be specified as a literal, rather than a const
<axw> ah yeah, didn't check that
<axw> nah, just a test. I think it's safe
<dimitern> axw, as long as it can be verified at machine agent startup time (where CheckProvisioned is called), I see no problem with making it random, following the same scheme as for the others ofc
<dimitern> axw, the idea behind the nonce format is to specify the parent machine that created the machine, i.e. "machine-0:<random id in hex>"
<dimitern> axw, since the bootstrap machine has no parent, it might be "user-admin:<random id>" perhaps?
<axw> dimitern: yeah that sounds sensible, I guess that was the rationale behind what it is now
<dimitern> axw, yes, precisely
<axw> dimitern: thanks, I'll look into doing that. looks fairly trivial
<jam> rogpeppe1: ping
<rogpeppe1> jam: pong
<rogpeppe1> jam: oh!
<rogpeppe1> jam: hangout, i guess!
<rogpeppe1> natefinch, dimitern, fwereade, jam, axw: review appreciated https://codereview.appspot.com/42760043
<rogpeppe1> axw: this may well be directly useful for stuff you've been doing recently
<natefinch> rogpeppe1, looking
<rogpeppe1> natefinch: thanks
<natefinch> rogpeppe1, would reporting the last error by default, rather than the first error maybe be more useful?  It would represent the most recent reason for failing.  Reporting the first error could result in spurious information, such as when you're waiting for a network to come up, maybe the first few errors are "can't connect" but then the network is up and you get a 404 from the remote server... the 404 is a lot more useful
<natefinch> to know.  Sure, you can customize the moreImportant function, but seems like last error would generally be more useful.
<rogpeppe1> natefinch: hmm, possibly
<rogpeppe1> natefinch: i'm not sure though - the usual case will be that we're trying several addresses with fallbacks, rather than several attempts for one address.
<rogpeppe1> natefinch: is the error from the last address we try likely to be any more useful than the first one?
<natefinch> rogpeppe1, maybe a more generally useful implementation for moreImportant would be something that returns an error instead of returning a boolean, that way if someone wants to just aggregate all the errors, they can add them all to a custom MultiError struct
<rogpeppe1> natefinch: possibly.
<rogpeppe1> natefinch: that would be easy enough to add if we decide we want that
<rogpeppe1> natefinch: i've gone with moreImportant for the time being because we already use that concept elsewhere in the system
<natefinch> rogpeppe1, it's tricky.... returning just one error out of a N that are tried doesn't seem terribly useful, unless you're relatively sure they're all going to fail for the same reason.
<rogpeppe1> natefinch: agreed, it's not easy
<natefinch> rogpeppe1, I guess if they want to aggregate the errors, they can still do that with your moreImportant function, they'd just store them outside
<rogpeppe1> natefinch: likewise though, it's not great to print lots of similar errors to the user
<natefinch> rogpeppe1, absolutely
<natefinch> rogpeppe1, man, I hate the name tomb.
<rogpeppe1> natefinch: for its morbid associations?
<natefinch> rogpeppe1, nah, I don't care about that, it's just so uninformative, I forget what exactly it does until I go look at it.
<rogpeppe1> natefinch: interesting. i find it ok
<natefinch> rogpeppe1, I'm sure once I've used it a bunch it'll be fine.  but when I first see it, the name just doesn't tell me much.  I guess I'd prefer something more boring and generic like gowatcher or something (one of the few times when go in the name of the package actually helps describe the package)
<rogpeppe1> natefinch: gowatcher wouldn't really be right
<rogpeppe1> natefinch: it really is a bit like a tombstone - it acts as a marker for a death
<rogpeppe1> natefinch: interestingly, tomb is another place that could do with a combineErrors/moreImportant function
<natefinch> rogpeppe1, I guess my problem is that you write tomb.Dying() and tomb.Dead() and tombs are never either
<natefinch> rogpeppe1, maybe redshirt would be a better name.... something that is just inevitably going to die, and the only question is when
<rogpeppe1> natefinch: yeah, it's just a signifier
<rogpeppe1> natefinch: redshirt??
<natefinch> rogpeppe1, star trek joke.  In the original star trek, it's really common for the guys in the red shirts (generally no-name crew members) to die when the crew goes on missions to a planet etc
<rogpeppe1> natefinch: ah. i don't do star trek.
<natefinch> rogpeppe1, a way for the TV show to say "look, it's dangerous!" without killing off anyone you care about
<natefinch> rogpeppe1, I'm not a huge trekkie, though I did enjoy the shows when they were airing.
<rogpeppe1> natefinch: i like sf :-)
<natefinch> rogpeppe1, I love sci-fi.  no time for tv & movies with the young kids, but that'll just give me all the more stuff to catch up on when they're older :)
<rogpeppe1> natefinch: i don't consider star trek to be sf... :-)
<natefinch> rogpeppe1, oh come on, just because it's dated and campy... it may not pass for *good* sci fi these days, but it's still sci fi :)
<rogpeppe1> natefinch: it certainly has sf trappings
<natefinch> rogpeppe1, seems like Try.Wait() isn't really useful... it's the same as _, err := t.Result()
<rogpeppe1> natefinch: it's useful because it means that Try fits the normal Kill/Wait interface for workers
<rogpeppe1> natefinch: so you can use worker.Stop on it, for example
<natefinch> rogpeppe1, Ahh, I didn't make the connection.
<natefinch> rogpeppe1, why not call the package try?  t := try.New()   t.Start()  etc
<rogpeppe1> natefinch: because i thought it fitted quite neatly into the parallel package
<rogpeppe1> natefinch: parallel.Try reads quite nicely, i think
<natefinch> this seems like an excellent case for a package that should be outside juju-core
<rogpeppe1> natefinch: and it's about the same level of abstraction as parallel.Run
<natefinch> rogpeppe1, I actually missed that parallels was already a package :)
<rogpeppe1> natefinch: perhaps so, but i'd prefer to keep in internal for the time being
<rogpeppe1> s/in int/it int/
<rogpeppe1> natefinch: it's certainly a candidate for abstraction into an external package at some point
<natefinch> rogpeppe1, I disagree, because "for the time being" pretty much always ends up being forever, but it's not really my call
<rogpeppe1> natefinch: please, i really don't want to spend more time on overhead currently.
<rogpeppe1> natefinch: and an external package is just overhead at this point.
<natefinch> rogpeppe1, like I said, not my call :)  I'll submit my comments.  LGTM in general
<rogpeppe1> natefinch: thanks
<rogpeppe1> natefinch: i've just changed the code to use combineErrors rather than moreImportant, FWIW
<natefinch> cool
<axw> rogpeppe1: I won't be much chop, reviewing under the influence. does indeed look like it'll be useful for bootstrap though
<rogpeppe1> axw: reviewing under the influence is so much more fun :-)
<axw> rogpeppe1: I did a reflect-based thing here https://codereview.appspot.com/40860048/patch/40001/50014
<axw> I did wonder if generalising would be useful
<rogpeppe1> axw: ah, i think i saw your comment there and remember thinking i was dubious about using reflect.Select
<rogpeppe1> axw: in general it's almost always a bad idea to use reflect.Select as a substitute for variable-length select in Go, IMHO
<axw> rogpeppe1: yeah, I agreed. I will rework it tomorrow
<axw> *agree
<axw> using your code if it's landed :)
<rogpeppe1> axw: will be landing v soon :-)
<axw> rogpeppe1: aside from that bit, I'd appreciate a review for general soundness of what I've done
<rogpeppe1> axw: will do
<axw> rogpeppe1: any particular reason for not taking an error in Kill?
<axw> in synchronous bootstrap I pass an error in on SIGINT
<axw> then that comes out the other end and up the stack
<rogpeppe1> axw: it fits the usual Kill paradigm
<rogpeppe1> axw: (see the worker.Worker interface, for example)
<rogpeppe1> axw: if you want to distinguish between ways that you've killed it, you'd need to record that somewhere else
<axw> rogpeppe1: ok
<rogpeppe1> axw: i'd probably have something waiting for either interrupt or timeout to happen - then you wouldn't need a mutex
<rogpeppe1> axw: that's an example of why it's nice to map signals to channels
<axw> rogpeppe1: yeah, fair enough
<axw> I haven't gotten back to the other one yet
<axw> (refactoring BootstrapContext)
<rogpeppe1> axw: ah yes, i was just looking to see if i'd missed it somewhere
<axw> rogpeppe1: I was hoping to get bootstrap actually working again before fixing that bit up
<axw> maybe it'll be involved tho
<dimitern> rogpeppe1, hey
<rogpeppe1> dimitern: hiya
<dimitern> rogpeppe1, what user do you think should be used to upload charms through the cli?
<rogpeppe1> dimitern: we've only got one user currently, so not much choice :-)
<dimitern> rogpeppe1, for now I hard coded user-admin + admin-secret
<rogpeppe1> dimitern: i think that's correct currently
<dimitern> rogpeppe1, ok
<rogpeppe1> dimitern: it's the usual command line user
<dimitern> rogpeppe1, too bad some tests are not written with that in mind
<rogpeppe1> dimitern: really?
<dimitern> rogpeppe1, like the apiserver/client tests
<rogpeppe1> dimitern: how so?
<dimitern> rogpeppe1, yeah, it adds user "admin" and sets some default password
<dimitern> rogpeppe1, which simplifies the test a bit but wreaks havoc with putcharm
<rogpeppe1> dimitern: ah - that's actually correct
<rogpeppe1> dimitern: you shouldn't hardcode adminsecret
<rogpeppe1> dimitern: you can hardcode user-admin, but the password should be checked against state's admin password
<dimitern> rogpeppe1, what do you mean? I'm getting it from Environ.Config().AdminSecret()
<dimitern> rogpeppe1, if I get it from state we're not entirely divorcing the cli from state
<rogpeppe1> dimitern: state is where the user info is stored
<rogpeppe1> dimitern: you should be using state.User.PasswordValid to check the user
<rogpeppe1> dimitern: but i think that's already done for you, isn't it?
<dimitern> rogpeppe1, so you think the Conn object will have access to state even after CLI API is done?
<rogpeppe1> dimitern: so all you need to do is check that user is user-admin
<dimitern> rogpeppe1, I do that in the apiserver, yes
<rogpeppe1> dimitern: ah, sorry, i thought you were talking about the server side
<rogpeppe1> dimitern: in the client, yes, it'll need to use admin-secret, just like all the other parts of the CLI that talk to the API
<dimitern> rogpeppe1, so that's what I'm doing, but that apiserver/client test with the setUpScenario monstrosity changes the admin user password
<dimitern> rogpeppe1, without touching the environ config, and hence the problem
<dimitern> rogpeppe1, I'm refactoring those tests not to rely on a "default password" for user-admin
<rogpeppe1> dimitern: one mo - how do the tests work currently?
<rogpeppe1> dimitern: i don't quite see why putcharm is any different from the other CLI tests
<dimitern> rogpeppe1, look at api_test.go:setUpScenario
<dimitern> rogpeppe1, one of the very first things we do is 	u, err := s.State.User("admin"); setDefaultPassword(c, u)
<dimitern> rogpeppe1, which screws up AddTestingCharm(), which uses PutCharm() internally, relying on admin-secret from the environ config to be the user-admin's password
<rogpeppe1> dimitern: so how do the existing tests know how to log in using that password?
<rogpeppe1> dimitern: so AddTestingCharm is making its own connection to the state?
<dimitern> rogpeppe1, they don't - all tests assume the password is all the same for all entities: tag + " password-1234567890"
<rogpeppe1> s/the state/the API/
<dimitern> rogpeppe1, no, ATC() uses Conn.PutCharm internally, and put charm now does a https-basic-authenticated upload request
<rogpeppe1> dimitern: does AddTestingCharm need to go through the API?
<dimitern> rogpeppe1, it currently uses PutCharm
<dimitern> rogpeppe1, do you suggest otherwise?
 * rogpeppe1 thinks
<dimitern> rogpeppe1, the code for uploading, calculating the hash, updating state, etc. is all there
<dimitern> rogpeppe1, I haven't changed that, I'm only trying to make it work
<rogpeppe1> dimitern: presumably AddTestingCharm now uses s.APIConn.PutCharm ?
<dimitern> rogpeppe1, there's no such thing
<rogpeppe1> dimitern: hmm. i didn't realise juju.Conn ever talked to the API
<dimitern> rogpeppe1, only PutCharm does
<rogpeppe1> dimitern: that seems a bit wrong to me
<dimitern> rogpeppe1, with my changes, and only to the https handler for charm upload
<rogpeppe1> dimitern: currently a Conn is just Environ+state.State
<rogpeppe1> dimitern: there should be no API dependency there
<dimitern> rogpeppe1, how about 1.16 compatibility?
<rogpeppe1> dimitern: the plan is to deprecate Conn entirely for user use eventually
<rogpeppe1> dimitern: *eventually*
<dimitern> rogpeppe1, right now addCharm() is the internal method that does the packaging, hash calc + upload to storage using state, and it's called inside PutCharm
<dimitern> rogpeppe1, what I did is to move that code to addCharm1dot16 and add a new code to upload the charm through the API
<rogpeppe1> dimitern: so, firstly, PutCharm should be defined inside APIConn, not Conn
<dimitern> rogpeppe1, how can we have both 1.16 compatibility and API access?
<rogpeppe1> dimitern: we can leave Conn.PutCharm as is for the time being
<dimitern> rogpeppe1, hmm, ok
<dimitern> rogpeppe1, and once we're not using it inside the CLI, we can drop it (or put it inside a testing package only, for AddTestingCharm's sake)
<rogpeppe1> dimitern: yeah
<dimitern> rogpeppe1, but all that won't solve the issue with how the client api tests are written
<rogpeppe1> dimitern: i think that's not too hard - we just need a version of AddTestingCharm that uses a given API connection.
<dimitern> rogpeppe1, ok, I'll look into that, thanks
<rogpeppe1> dimitern: there's an interesting issue there actually
<rogpeppe1> dimitern: which is that we need to keep the API connection password lying around so that we can use it again
<dimitern> rogpeppe1, expand please
<rogpeppe1> dimitern: so, when you open an API connection, you use a tag and password, right?
<rogpeppe1> dimitern: if you later use PutCharm on that connection, the API needs to authenticate for the PUT request
<rogpeppe1> dimitern: so it needs the password
<rogpeppe1> dimitern: but currently the client-side API connection doesn't store the password that was used for the initial authentication AFAIK
<dimitern> rogpeppe1, yeah
<rogpeppe1> dimitern: so we'll need to do that.
<dimitern> rogpeppe1, but putcharm is a totally different per-request auth
<rogpeppe1> dimitern: agreed, but from the API point of view, it'll just be a method on client.State, right?
<rogpeppe1> dimitern: client.Client, rather
<rogpeppe1> api.Client even!
<dimitern> rogpeppe1, not really
<rogpeppe1> dimitern: no?
<dimitern> rogpeppe1, it's not a method, it's a server handler accepting requests
<dimitern> rogpeppe1, and PutCharm is the client-side interface to that handler
<dimitern> rogpeppe1, on a APIConn
<rogpeppe1> dimitern: but what does the client-side interface look like?
<rogpeppe1> dimitern: in Go, that is
<rogpeppe1> dimitern: i think it should be a method on api.Client
<dimitern> rogpeppe1, it looks exactly like PutCharm, minus the bumpRevision flag
<rogpeppe1> dimitern: i don't see a reason for it to be on APIConn
<rogpeppe1> dimitern: in fact, i think APIConn will probably go entirely in time
<dimitern> rogpeppe1, I don't see a reason for it to be on api.Client
<dimitern> rogpeppe1, it's faking it if we put it there
<rogpeppe1> dimitern: what's the reason for APIConn to exist?
<dimitern> rogpeppe1, you don't need an api connection to upload a charm
<dimitern> rogpeppe1, api connection authenticated through login i mean
<rogpeppe1> dimitern: strictly speaking that's true, but in practice i think we're always going to want an API connection (to create the service), and if we do it this way, then it makes it easy for us to change to using API-obtained auth tokens in the future
<rogpeppe1> dimitern: which is something we may well want to do
<dimitern> rogpeppe1, to use the API, but before charm upload support the only way to use the api was through an apiconn's web socket
<dimitern> rogpeppe1, deploy for example does PutCharm before trying to do ServiceDeploy
<dimitern> rogpeppe1, and gets a connection (apiconn) before that
<rogpeppe1> dimitern: sure, but it won't slow things down in the usual case if it does an API connection before doing the PutCharm, will it?
<rogpeppe1> dimitern: so it's making an API connection before doing the PutCharm anyway
<dimitern> rogpeppe1, so what do you propose? caching the user/pass in api.client() after login?
<rogpeppe1> dimitern: yes
<dimitern> rogpeppe1, I'll have to think about it
<dimitern> rogpeppe1, it changes my whole approach
<rogpeppe1> dimitern: so if/when we decide in the future to use an auth token rather than user/pass, we can make the PutCharm method do that transparently
<dimitern> rogpeppe1, most of the code in putcharm i could keep, but move it away from conn and leave the old one untouched
<rogpeppe1> dimitern: the only reason that juju.APIConn is around is for the pairing of Environ and api.Conn
<dimitern> rogpeppe1, auth token or not, the deal doesn't change for putcharm - with cached auth creds
<rogpeppe1> dimitern:  but we want clients to be able to use the API without an Environ
<rogpeppe1> dimitern: yeah
<rogpeppe1> dimitern: i don't think it changes too much
<rogpeppe1> dimitern: even if we don't make PutCharm a method on api.Client, it should still be implemented as a function inside the state/api package
<dimitern> rogpeppe1, ok, will take that into consideration
<rogpeppe1> dimitern: thanks
<dimitern> rogpeppe1, but unfortunately I won't propose it today as I hoped, due to the refactoring
<rogpeppe1> dimitern: sorry about that
<rogpeppe1> dimitern: FWIW the way i look at it is this: the state/api package abstracts all details of transport away from the client code, and that includes whether an individual request is made with a json RPC or an http PUT request
<dimitern> rogpeppe1, it's ok, i appreciate the discussion - it opened up some things i didn't think about
<rogpeppe1> or POST request, even
<rogpeppe1> dimitern: cool
<rogpeppe1> dimitern: it also made me think about some issues i hadn't previously considered
<dimitern> rogpeppe1, yeah, the time is not lost :)
<rogpeppe1> dimitern: i always find it interesting how a seemingly minor issue encountered just trying to make some tests pass can blow up into a significant design change
<dimitern> rogpeppe1, :D it happens to me all the time
<rogpeppe1> natefinch: i've updated the CL, with one significant logic change
<rogpeppe1> natefinch: https://codereview.appspot.com/42760043
 * dimitern signs off, will be back later
<natefinch> sometimes IRC is wacky
<natefinch> rogpeppe1, dimitern: did either of you guys get a chance to run the tests on my branch?  lp:~natefinch/juju-core/mongo-ha
<rogpeppe1> natefinch: ah, will do
<rogpeppe1> natefinch: BTW in case you didn't see, i updated the Try CL
<rogpeppe1> natefinch: given your LGTM, i assumed you'd be ok with the changes, and have approved it, but i'd appreciate another once-over
<natefinch> rogpeppe1, I'll double check, and thanks
<natefinch> rogpeppe1, the failing tests are in environs/replicaset
<rogpeppe1> natefinch: i seem to have mislaid your branch link
 * rogpeppe1 wishes the G+ chats weren't so ephemeral
<rogpeppe1> has anyone got access to the bot? it seems to have run out of temporary directories again
<rogpeppe1> fwereade: ^
<rogpeppe1> fwereade: i don't think any branch can land currently
<fwereade> rogpeppe1, um, not immediately, let me poke around
<rogpeppe1> natefinch: i changed juju.NewAPIConn to use parallel.Try: https://codereview.appspot.com/37650048
<rogpeppe1> natefinch: any update on the 'bot?
<rogpeppe1> fwereade: ^
 * rogpeppe1 is done for the day
<rogpeppe1> natefinch: review of the above appreciated, if you have a mo. https://codereview.appspot.com/37650048
<rogpeppe1> g'night all
<rogpeppe1> fwereade: ^
<natefinch> rogpeppe1, looking
<natefinch> rogpeppe1, did you get a chance to run those tests?
<thumper> morning juju hackers
<natefinch> thumper, morning... you up early today?
<thumper> natefinch: yeah
<thumper> natefinch: school holidays and Rachel went to work early
<thumper> so I thought I might as well get up and work
<thumper> fwereade: if you are up and want a catch-up call, that would be good :-)
<thumper> mramm: hey, hope you are feeling better
<mramm> yep
<mramm> not 100% but, quite a bit better
<mramm> just got off the phone with hazmat
<mramm> thumper: I see you in the hangout, but don't see you in the hangout ;)
<thumper> hmm.. I'll rejoin
<natefinch> thumper, what version of mongo do we officially support, server-side?  I have a test failure in 2.2, but I'm pretty sure we only deploy 2.4
<thumper> I think we need 2.4 for the ssh bits
<thumper> 2.2 doesn't have it
<thumper> we are probably a bit shit in detecting this and enforcing minimum versions
<natefinch> thumper, I think the bot has 2.2, which is why I asked... but I'm not sure of how to get to the bot to check
<natefinch> thumper, not important now, I'm getting the test failure locally with 2.4 installed, so.... I'm back to square one, no easy out of "we don't support that anyway" ;)
<thumper> heh
#juju-dev 2013-12-17
<thumper> hazmat: ping
<hazmat> thedac, pong
<hazmat> whoops
<hazmat> axw, ping
<axw> hazmat: heya
<axw> jam: are you around? if so, can you please prod the bot?
<jam> axw: looking
<jam> axw: poked, it should be trying to merge rogpeppe1's branch right now (473-parallel-try)
<axw> thanks jam
<dimitern> jam, ping
<jam> dimitern: pong
<dimitern> jam, i need some bzr surgery :)
<jam> what's up?
<dimitern> jam, I removed the current branch I was working on using rmbranch (didn't even get a warning!, but I'm usually careful not to do that)
<dimitern> jam, and now pretty much every command returns bzr: ERROR: Not a branch: "/home/dimitern/src/juju-core/223-putcharm-uses-charm-upload/.bzr/branch/".
<dimitern> jam, is there an easy way to reset that and switch to trunk?
<jam> dimitern: bzr switch trunk --force
<dimitern> jam, wow! tyvm it worked :)
<jam> dimitern: by default switch does some sort of introspection on the "current" branch, which obviously doesn't work well when it isn't there, but --force skips that step
<rogpeppe1> mornin' all
<axw> hey rogpeppe1. your branch timed out in the tests in utils/parallel earlier. I couldn't reproduce it on my machine, but haven't looked into the code in detail yet
<rogpeppe1> axw: yeah, i just saw that
<rogpeppe1> axw: i can't repro either
<rogpeppe1> axw: :-(
<rogpeppe1> axw: it's a pity that the output for a timed-out test is so meagre
<axw> indeed, don't even get to see which test it was...
<rogpeppe1> yup
<dimitern> jam, I was already dreading the possibility that I actually need to start from scratch :)
<rogpeppe1> axw: i'm just trying with go1.1.2 in case that makes a difference
<axw> rogpeppe1: okey dokey. I'll do some code inspection to see if I spot anything
<rogpeppe1> axw: that would be useful, thanks
<rogpeppe1> axw: still passes consistently with go1.1.2
<axw> :(
<rogpeppe1> axw: i guess i'll try it in a machine in the cloud
<axw> rogpeppe1: I'd try it on my underpowered VM, but my server's crapped itself
<dimitern> rogpeppe1, I think you'll like this https://codereview.appspot.com/43330043
<rogpeppe1> dimitern: looking
<axw> rogpeppe1: it would appear that something in the trySuite is leaking goroutines. I added -test.cpu=1,1,1,1,1,1,... and number of goroutines keeps going up, and runtime keeps going up
<axw> possibly related, but ...
<axw> seems unlikely
<rogpeppe1> axw: it will probably go up for a while, but then settle down - it leaks a few goroutines that sleep for 4 or 5 seconds
<axw> rogpeppe1: didn't ever go down, but I may not have waited long enough
<rogpeppe1> axw: hmm, i'll have a look
<axw> I'll keep digging
<axw> rogpeppe1: trySuite.TestStartBlocksForMaxParallel
<axw> gtg
<rogpeppe1> axw: thanks
<rogpeppe1> axw: yeah, i've just repro'd that
<rogpeppe1> axw: it would have to be the last test i added...
<mgz> jamespage: free for a fast catchup?
<mgz> jamespage: er... actually, ignore me
<mgz> jam: free for a fast catchup?
<rogpeppe1> found the problem!
<dimitern> rogpeppe1, mgz, jam, standup
<mgz> dimitern: I'll have to skip as in sprint, but can give update on irc
<dimitern> mgz, sure, go for it
<mgz> at mini-sprint in london trying to help the CI guys with testing in charms, testing with charms, and testing juju setups
<mgz> if there are any questions that come up over the next few days will bug people here for answers where I'm not sure
<dimitern> rogpeppe1, btw while fixing the test, I have a couple of comments on https://codereview.appspot.com/42760043/
<dimitern> rogpeppe1, i'll publish them shortly
<rogpeppe1> dimitern: please do - i was about to push and re-approve
<dimitern> rogpeppe1, sent
<jam> mgz: sorry I missed you earlier. So when I went to sign up my son yesterday, one of the after school activities didn't show, so I had to go *again* today to actually sign him up. I have a 1:1 with Nate, but then I'm available to chat after that
<mgz> jam: sure, I'll find a gap
<dimitern> rogpeppe1, and you've got another review
<rogpeppe1> dimitern: ta!
<axw> rogpeppe1: what was the issue?
<rogpeppe1> axw: the loop was spinning
<rogpeppe1> axw: so nothing made progress
<axw> rogpeppe1: in the test or code-under-test?
<rogpeppe1> axw: i'm a bit surprised that nothing made progress even with GOMAXPROCS>1 actually
<rogpeppe1> axw: in the code under test - it was a bona fide bug
<rogpeppe1> axw: the problem was that i was closing t.close, and always reading from it
<rogpeppe1> axw: trivially fixed
<axw> ah, not setting to nil?
<rogpeppe1> axw: yeah
<axw> yeah I see it
<axw> cool
<rogpeppe1> axw: the fix actually made the code slighly simpler, which was nice
<axw> rogpeppe1: I changed my code to using parallel.Try today. seems a bit more convoluted now due to the need to retry, but I may just have overlooked a simple alternative
<axw> once your MP is landed I'd appreciate a glance over
<rogpeppe1> axw: i'd put the retries inside the functions started by Try
<axw> rogpeppe1: that's what I did :)
<dimitern> rogpeppe1, review poke
<axw> each one is given a channel to wait on that's closed when it should stop retrying
<rogpeppe1> axw: Try does that for you, right?
<rogpeppe1> dimitern: thanks; getting back to it :-)
<dimitern> rogpeppe1, cheers :)
<axw> rogpeppe1: maybe I've overcomplicated it. my current code caters for stopping retries on individual addresses
<axw> rogpeppe1: for pathological case where addresses come and go
<axw> maybe it should just keep going forever (until one wins or global timeout) for each address it sees?
<rogpeppe1> axw: i'm just wondering that too
<jam> mgz: poke
<axw> rogpeppe1: when you have time, https://codereview.appspot.com/40860048/
<rogpeppe1> axw: will do after this
<axw> the parallel.Try bit is all in provider/common/bootstrap.go
<axw> rogpeppe1: nps
<axw> thanks
<dimitern> rogpeppe1, I was thinking of renaming UploadCharm to UploadLocalCharm actually, because we've been just discussing with william about having an Upload[Charm?]StoreCharm to deal with CS urls
<rogpeppe1> dimitern: so you can override the default charm store fetching?
<rogpeppe1> dimitern: reviewed
<dimitern> rogpeppe1, yeah, all the charm upload ops will be performed by these two methods, which will get rid of some code duplication
<dimitern> rogpeppe1, thanks
<rogpeppe1> dimitern: so how would the api Deploy call work?
<rogpeppe1> dimitern: would that need to call the api itself?
<mattyw> fwereade, any news on that branch? is there stuff I need to be fixing?
<rogpeppe1> dimitern: sorry, i probably mean the api AddService call
<dimitern> rogpeppe1, right now there is some shared code between the CLI and API - DeployService
<fwereade> mattyw, sorry, I'll reapprove, the bot was throwing a fit
<dimitern> rogpeppe1, I'd like to move all that code into the ServiceDeploy API call and make use of the UploadCharm calls in there
<rogpeppe1> dimitern: i think i'm confiu
<rogpeppe1> dimitern: i think i'm confused
<rogpeppe1> dimitern: are you suggesting that we add an api call UploadStoreCharm?
<fwereade> rogpeppe1, basically yes
<rogpeppe1> dimitern: so how would the ServiceDeploy API call be implemented (server-side)?
<fwereade> rogpeppe1, it means "go and do this charm-related operation that has hitherto been hidden away inside deploy/upgrade-charm"
<rogpeppe1> fwereade: so this is essentially an AddCharm call?
<fwereade> rogpeppe1, ServiceDeploy would start with "if the charm url isn't already recognised, barf"
<fwereade> rogpeppe1, yeah
<rogpeppe1> fwereade: with no uploading from the client to the server?
<fwereade> rogpeppe1, we'd have to deprecate
<fwereade> rogpeppe1, yes
<dimitern> rogpeppe1, exactly
<rogpeppe1> fwereade: ah, that makes sense. but i don't think that "Upload" is great in this context
<fwereade> rogpeppe1, fair enough, I'm not married to the name
<rogpeppe1> fwereade, dimitern: it made me think that it was something that the client was uploading
<fwereade> rogpeppe1, there's some advantage to having it rhyme with the local version
<rogpeppe1> fwereade: perhaps we should call them both Add(Local)?Charm
<fwereade> rogpeppe1, sounds good?
<rogpeppe1> fwereade: AddCharm(*charm.URL); AddLocalCharm(*charm.URL, charm.Charm)
<rogpeppe1> dimitern: what do you think?
<dimitern> rogpeppe1, why Add when we're doing an upload?
<rogpeppe1> dimitern: because we want them both to rhyme, and Upload is inappropriate for the other one
<dimitern> rogpeppe1, in both cases really - there's always a "upload to provider storage" step
<axw> fwereade: I updated the DestroyEnvironment API based on our previous discussions (https://codereview.appspot.com/41280043/). The API call can still render the environment unusable (apart from destroying things) if there are manual machines, if two API clients race. I'm nervous about allowing them to leak, but if you feel strongly enough I can remove that
<rogpeppe1> dimitern: and they're both adding a charm - one just happens to take the charm from locally
<rogpeppe1> dimitern: i think of that as an implementation detail - it's downloading as much as uploading
<fwereade> axw, thanks, I will try to get to it soon, today is meetingy again though
<dimitern> rogpeppe1, well, i suppose so
<axw> fwereade: no worries
<rogpeppe1> dimitern: in the future, we probably won't store charms in provider storage, so it'll be even more like download-only
<dimitern> rogpeppe1, AddStoreCharm perhaps? instead of AddCharm - too generic and confusingly similar to AddLocalCharm, without providing a distinction
<rogpeppe1> dimitern: i think AddCharm is better because it gives freedom to expand to allow other kinds of URL in the future
<rogpeppe1> dimitern: for instance we might allow the API server to download github charms directly.
<dimitern> rogpeppe1, ok, fair enough
<rogpeppe1> dimitern: it's really "add this url" - we just happen to support only cs: prefixes currently
<rogpeppe1> dimitern: i just noticed something dubious
<rogpeppe1> dimitern: why are you using GetNonValidatingHTTPClient ?
<dimitern> rogpeppe1, because the API server's cert is self-signed
<rogpeppe1> dimitern: no it's not
<rogpeppe1> dimitern: it's signed by the CA public key, which we have
<rogpeppe1> dimitern: the websocket connection is appropriately verified
<rogpeppe1> dimitern: the POST should be too
<dimitern> rogpeppe1, somehow I couldn't make a connection with it without skipping the validation
<rogpeppe1> dimitern: you'll need to add the CA cert to the trusted root keys
<dimitern> rogpeppe1, the SSL cert for a web server is different than others - domain name needs to match
<dimitern> rogpeppe1, how do I do that?
<rogpeppe1> dimitern: how is the websocket code not talking to the web server?
<dimitern> rogpeppe1, I don't get any issues with the websocket connections, only with HTTPS ones
<rogpeppe1> dimitern: did you try setting the tls config?
<dimitern> rogpeppe1, where?
<rogpeppe1> dimitern: in the http Transport
<rogpeppe1> dimitern: one mo, i'll investigate
<dimitern> rogpeppe1, i'm not sure what are you referring to
<dimitern> rogpeppe1, when I try using http.DefaultClient instead of utils.GetNonValidatingHTTPClient, I get this http://paste.ubuntu.com/6588688/
<rogpeppe1> dimitern: you can't use http.DefaultClient
<rogpeppe1> dimitern: i'm just writing a code fragment for you
<dimitern> rogpeppe1, why not?
<rogpeppe1> dimitern: because DefaultClient uses the default root CA certs, which don't include the juju ones
<dimitern> rogpeppe1, that seems wrong - inventing a self-signed ca cert and using it
<rogpeppe1> dimitern: huh?
<rogpeppe1> dimitern: that's the entire basis of our server authentication
<rogpeppe1> dimitern: what's wrong with using your own certs?
<rogpeppe1> dimitern: anyway, it's not self-signed - it's just a very short chain :-)
<dimitern> rogpeppe1, well, anyway
<dimitern> rogpeppe1, it strikes me as odd
<rogpeppe1> dimitern: how else can we verify what server we're talking to?
<dimitern> rogpeppe1, i'm not going there
<dimitern> rogpeppe1, :) a discussion for another time perhaps
<rogpeppe1> dimitern: honestly, if you think there are issues with our security model, it would be good to know about them
<dimitern> rogpeppe1, i think it's inconvenient for others, that want their own hosted juju stuff to talk with standard clients
<rogpeppe1> dimitern: unfortunately i think that juju is fundamentally incompatible with the standard client authentication model
<rogpeppe1> dimitern: s/client auth/http server auth/
<rogpeppe1> dimitern: for one, we don't have a well known domain name that the API server lives on
<dimitern> rogpeppe1, not really - as far as tls is concerned
<rogpeppe1> dimitern: for another, we don't want to require everyone that runs a juju API server to buy a certificate
<dimitern> rogpeppe1, having the private and public key available makes is very easy for anyone to mount MITM attacks against a running environment
<rogpeppe1> dimitern: how is the private key available?
<dimitern> rogpeppe1, well, not very easy, but it's plausible
<dimitern> rogpeppe1, isn't it in the source?
<rogpeppe1> dimitern: no
<rogpeppe1> dimitern: it's created when the env is prepared
<dimitern> rogpeppe1, so how does the server use it for decryption?
<dimitern> rogpeppe1, ah, ok
<rogpeppe1> dimitern: the server is given the private key when it's bootstrapped
<rogpeppe1> dimitern: (and in general, tls keys are never used for encryption or decryption)
<dimitern> rogpeppe1, having the ca cert and key, can you generate a key that works for certain environment?
<dimitern> rogpeppe1, they are, in the handshake process
<rogpeppe1> dimitern: diffie-hellman isn't really encryption
<rogpeppe1> dimitern: if you have the root ca private key, you can generate any number of server certs and keys
<dimitern> rogpeppe1, signing or encryption - it's all the same
<rogpeppe1> dimitern: it's not even signing really
<dimitern> rogpeppe1, how about generating a *specific* key - preseeding or something, so you can end up with a running env's key pair?
<rogpeppe1> dimitern: i don't understand that
<dimitern> rogpeppe1, i'll check it out
<dimitern> rogpeppe1, so how about that sample code?
<rogpeppe1> dimitern: almost there
<rogpeppe1> dimitern: http://paste.ubuntu.com/6588771/
<rogpeppe1> dimitern: (something approximately like that anyway)
<mattyw> fwereade, failed again - I wonder if something is wrong with the branch - I don't see any of those errors though when I run it locally
<dimitern> rogpeppe1, thanks, looking
<dimitern> rogpeppe1, is the api.Info.CACert always the same or that's the one we're generating?
<rogpeppe1> dimitern: it's generated at prepare time currently
<dimitern> rogpeppe1, so i'm thinking of adding utils.GetClientFromInfo(info *api.Info) *http.Client, which can be reused
<rogpeppe1> dimitern: that doesn't seem quite right (and i don't think you'll be able to anyway)
<dimitern> rogpeppe1, why?
<rogpeppe1> dimitern: because you'd get an import cyclre
<rogpeppe1> cycle
<dimitern> rogpeppe1, well, then taking a CACert []byte
<mgz> rogpeppe1: any reason I shouldn't just land the state api branch?
<rogpeppe1> dimitern: that could work.
<mgz> rogpeppe1: I want to make some more changes, but breakage on a dev version is okay, right?
<rogpeppe1> dimitern: although i think it would probably live better in the api package
<rogpeppe1> mgz: which branch is that?
<rogpeppe1> dimitern: because it's actually all about making an http client that's good for connecting to the api
<mgz> rogpeppe1: https://codereview.appspot.com/40350043/
<rogpeppe1> dimitern: also, that wouldn't be that convenient to use because the api code actually needs the tls.Config, so would need to type-assert the Client.Transport
<rogpeppe1> mgz: ah, the *status* api branch :-)
<mgz> rogpeppe1: ah yes, whoops
 * rogpeppe1 woz confused for a moment
<dimitern> rogpeppe1, I don't want to copy 20 lines every time I need to connect to the api server though
<rogpeppe1> mgz: i have a feeling that rpc calls cannot return both an error and some data
<rogpeppe1> dimitern: why would you need to do that?
<rogpeppe1> dimitern: the only place you'd be connecting to the api server would be in the api packages, right?
<mgz> rogpeppe1: really? the api doc didn't say that
<dimitern> rogpeppe1, how about tests?
<dimitern> rogpeppe1, it doesn't seem right to use a non-validating client there
<rogpeppe1> dimitern: you might want to export api.State.HTTPClient, similar to how Call is exported
<mgz> rogpeppe1: I'm also not clear on the meaning of returning api.Struct vs *api.Struct from rpc
<rogpeppe1> mgz: rpc requires struct returns for all methods
<rogpeppe1> mgz: the data is ignored if the error is non-nil... i'm pretty sure - let me check
<dimitern> rogpeppe1, modify the Caller interface?
<dimitern> rogpeppe1, that seems way too intrusive
<mgz> rogpeppe1: as in, not struct pointers?
<rogpeppe1> mgz: yup
<mgz> I'm confused as to why the tests passed then...
<rogpeppe1> dimitern: no, you wouldn't necessarily need to modify the Caller interface
<rogpeppe1> mgz: perhaps there's nothing that tests partial-status-with-error
<mgz> rogpeppe1: right, I'm pretty sure there's not for that. but I changed the api return code to *api.Status and if that's illegal I'd expect all the tests to fail
<rogpeppe1> mgz: hmm, yes
<rogpeppe1> mgz: ah!
<rogpeppe1> mgz: perhaps it was just using the fallback code in those tests
<rogpeppe1> mgz: did you try running all the tests in the tree?
<rogpeppe1> mgz: i'm pretty sure there's one that tests for inappropriately-ignored rpc methods
<mgz> rogpeppe1: I *thought* so, but will recheck
<rogpeppe1> mgz: launchpad.net/juju-core/state/apiserver tests should have caught that
<rogpeppe1> mgz: if it didn't then that test is bogus :-)
<rogpeppe1> dimitern: yeah, i wouldn't modify the Caller interface - but you can add a method State.HTTPClient() *http.Client
<rogpeppe1> dimitern: then api sub-packages that need to make direct http calls can use an interface that's something like: interface{common.Caller; HTTPClient() *http.Client}
<dimitern> rogpeppe1, what's wrong with having a common function for that?
<dimitern> rogpeppe1, in utils
<rogpeppe1> dimitern: it seems like internal implementation detail of api to me
<dimitern> rogpeppe1, it's quite useful
<rogpeppe1> dimitern: we put stuff in utils that's generally useful
<rogpeppe1> dimitern: where else might we want to use it?
<dimitern> rogpeppe1, in plugins perhaps?
<rogpeppe1> dimitern: surely plugins should be using the api package?
<dimitern> rogpeppe1, i see no harm in add it there
<rogpeppe1> dimitern: if we find ourselves wanting it somewhere else, i'd factor it out then (it will be trivial to do so)
<rogpeppe1> dimitern: i prefer to avoid expanding utils indefinitely just because we think that something might be generally useful
<dimitern> rogpeppe1, btw the code you gave me still causes the same error
<dimitern> rogpeppe1, x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
<rogpeppe1> dimitern: could you paste the code you're using?
<dimitern> rogpeppe1, http://paste.ubuntu.com/6588953/
<dimitern> rogpeppe1, and the caCert i'm passing is the one from api.Info used to call Login
<rogpeppe1> dimitern: could you push your branch please?
<rogpeppe1> dimitern: aside: it's not right for that code to use a global variable
<dimitern> rogpeppe1, there's a mutex around it
<rogpeppe1> dimitern: it looks like you've cargo-culted from NonValidatingHTTPClient
<dimitern> rogpeppe1, yes
<rogpeppe1> dimitern: what happens if you pass a different CACert in?
<dimitern> rogpeppe1, where should I get it from?
<rogpeppe1> dimitern: where should you get what from?
<dimitern> rogpeppe1, a different ca cert
<rogpeppe1> dimitern: maybe you're talking to two environments at once?
<rogpeppe1> dimitern: that's perfectly allowable
<dimitern> rogpeppe1, i don't think so
<rogpeppe1> dimitern: why not?
<rogpeppe1> dimitern: i should certainly hope it's ok
<dimitern> rogpeppe1, why should I be doing that? it's a standard code
<rogpeppe1> dimitern: i'd consider it a serious bug otherwise
<rogpeppe1> dimitern: what's a standard code?
<dimitern> rogpeppe1, i mean i'm not doing anything fancy
<rogpeppe1> dimitern: regardless of anything else, the output of a function should be, if at all possible, a deterministic function of its arguments
<dimitern> rogpeppe1, pushed lp:~dimitern/juju-core/225-upload-charm-via-api - if you run the tests in state/api you'll see the error
<rogpeppe1> dimitern: if I call GetHTTPClientFromCert(certA); then i call GetHTTPClientFromCert(certB) the second return will return the http client for certA. that's just wrong.
<dimitern> rogpeppe1, ok, that's true, I'll remove the mutex + caching and just return a new client every time
<dimitern> rogpeppe1, but that didn't help with the error - i tried already
<rogpeppe1> dimitern: no, it wouldn't
<rogpeppe1> dimitern: it was just an aside
<dimitern> rogpeppe1, any clue about the error?
<rogpeppe1> dimitern: i'm investigating currently
<dimitern> rogpeppe1, ok
<rogpeppe1> dimitern: this code works fine for me: http://paste.ubuntu.com/6589085/
<rogpeppe1> dimitern: (i get a 401 response which indicates that all the tls handshaking and client cert stuff has worked ok)
<rogpeppe1> dimitern: so i suspect you're not actually using the http client that you created
<dimitern> rogpeppe1, I am using it
<dimitern> rogpeppe1, but perhaps the caCert from the api.Info used for Login is not the same as in Environ.Config()
<rogpeppe1> dimitern: you mean the bug i pointed out above might be triggering the problem?
<dimitern> rogpeppe1, i'm not using the mutex anymore
<dimitern> rogpeppe1, so the bug cannot occur
<dimitern> rogpeppe1, i'm trying to get the environ config and the ca cert in AddLocalCharm to see if it helps
<rogpeppe1> dimitern: so which test fails?
<dimitern> rogpeppe1, TestAddLocalCharm, the only one
<rogpeppe1> dimitern: it passes for me
<rogpeppe1> dimitern: just to sanity check: what go version are you using?
<dimitern> rogpeppe1, go version go1.1.2 linux/amd64
<rogpeppe1> dimitern: ok, i'll try with that
<dimitern> rogpeppe1, using the ca-cert from the environ config didn't help
<rogpeppe1> dimitern: ha! i now see the problem - with go1.1.2
<dimitern> rogpeppe1, huh?
<dimitern> rogpeppe1, those things always happen to me :)
<rogpeppe1> dimitern: yeah, you seem to be blessed like that
<dimitern> rogpeppe1, but 1.1.2 is the official version we're building against
<rogpeppe1> dimitern: yeah
<dimitern> rogpeppe1, so what's the underlying issue?
<rogpeppe1> dimitern: i'll try to find that out
<dimitern> rogpeppe1, so I think the only way around this is to use the non-validating client
<rogpeppe1> dimitern: we should avoid that if at all possible
<rogpeppe1> dimitern: but perhaps for now as a workaround with a huge "BUG HERE" comment
<dimitern> rogpeppe1, i'm open to suggestions for a workaround the issue
<dimitern> rogpeppe1, yeah, will do
<rogpeppe1> dimitern: hmm, interestingly my little test example still works ok with go1.1.2
<rogpeppe1> dimitern: maybe it's something to do with the cert generation
<dimitern> rogpeppe1, perhaps
<rogpeppe1> dimitern: looks like that's the case
<rogpeppe1> dimitern: my test program succeeds or fails depending on whether the server is compiled with go1.1.2 or go1.2
<dimitern> rogpeppe1, if you managed to find an issue# to include in the bug report?
<rogpeppe1> dimitern: i need to find out what the issue is...
<dimitern> rogpeppe1, ok, I'll just describe it in general
<rogpeppe1> dimitern: give me a little more time
<rogpeppe1> dimitern: i'm just about to find out what the difference between the generated certs is
<dimitern> rogpeppe1, ok, no rush
<dimitern> rogpeppe1, it seems we're generating certs without Subject_Alternative_Name field - https://groups.google.com/forum/#!topic/golang-nuts/hCCsphIUuBA
<rogpeppe1> dimitern: that may be true, but it looks like that's still the case with go1.2, and it works there
<dimitern> rogpeppe1, x509 in go 1.2 is different than that in 1.1.2 - some more things are supported
<dimitern> rogpeppe1, specifically the SANs handling has changed, perhaps that's the cause
<rogpeppe1> dimitern: possibly. but it seems a bit weird that the client version doesn't matter
<dimitern> rogpeppe1, although the code handling the validation seems unchanged
<dimitern> rogpeppe1, weird..
<dimitern> rogpeppe1, does https://codereview.appspot.com/43330043 look ok to land?
<rogpeppe1> dimitern: looks like the address->serverRoot name change hasn't been pushed yet
<dimitern> rogpeppe1, oh, sorry, will repropose
<dimitern> rogpeppe1, done
<natefinch> fwereade, rogpeppe1: so here's the problem I've been having with mongodb... the default distribution doesn't support SSL, so creating a new mongo server is failing.  That's at least why it's failing locally on my machine.  The problem is, I don't know how it was working before, since I'm pretty sure I was running a generic build before, too.
<rogpeppe1> natefinch: i can't see how you could have run any juju tests with default distribution - we've required that for ages
<natefinch> rogpeppe1, I must have gotten the special version and forgotten about it, then when I rolled back to 2.2 yesterday, I messed it up.
<natefinch> rogpeppe1, where do I get the SSL-ified version?
<rogpeppe1> natefinch: i'm not sure i'm afraid
<rogpeppe1> natefinch: you can probably apt-get it from somewhere
<rogpeppe1> natefinch: when you find out, let me know, 'cos i'd like to upgrade to mongo 2.4...
<rogpeppe1> dimitern: i posted a comment on your CL
<dimitern> rogpeppe1, let's not use rpc.NoSuchRequest, because it's nothing like it
<rogpeppe1> dimitern: in which case, let's unify the two
<dimitern> rogpeppe1, the transport is different as well
<rogpeppe1> dimitern: so an api client doesn't have to use several different ways of determining errors
<natefinch> rogpeppe1, sounds like it has to be built from source or purchased
<dimitern> rogpeppe1, there are only 2 ways
<rogpeppe1> dimitern: sure, but there should only be one
<dimitern> rogpeppe1, and there are 2 transports underneath
<rogpeppe1> dimitern: the transport is an implementation detail
<dimitern> rogpeppe1, so you propose to make NoSuchRequest a NotImplementedError
<rogpeppe1> dimitern: i propose to define CodeNotImplemented and make a non-implemented error just like all the other errors defined in params
<rogpeppe1> dimitern: so that if you're using state/api/* you only have one way of classifying errors
<dimitern> rogpeppe1, and how is that going to work for rpc.NoSuchRequest?
<rogpeppe1> dimitern: one possibility is outlined in my comment
<rogpeppe1> dimitern: another possibility is to change api.State.Call so that it transforms the rpc error as appropriate
<dimitern> rogpeppe1, so we can return serverError(&Error{Message: "not impl. blah", Code: params.CodeNotImplemented}) instead of NotImplementedError, and make rpc.NoSuchRequest ErrorCoder-compatible, using params.CodeNotImplemented as code
<rogpeppe1> dimitern: i *think* params should import rpc rather than the other way around
<rogpeppe1> dimitern: because we might make rpc into an external package at some point
<rogpeppe1> dimitern: and serverError is for server-side not client-side use
<rogpeppe1> dimitern: this is a change that really should be part of another CL; hence i suggest the quick fix so you can land this, then fix all calls to rpc.IsNoSuchRequest to call params.IsNotImplemented instead
<dimitern> rogpeppe1, problem is, it already landed, sorry
<dimitern> rogpeppe1, but i'm preparing a follow-up
<rogpeppe1> dimitern: ok, thanks
 * dimitern will be back soon
<TheMue> hmm, ears are still closed and whistling, hope it will be better tomorrow. but at least my tests are working fine so far.
<dimitern> rogpeppe1, how do you suggest doing "make the rpc package return error code CodeNoSuchRequest on method-not-defined
<dimitern> error"
<dimitern> rogpeppe1, where should I catch and report this error?
<rogpeppe1> dimitern: ok, there are few aspects to this:
<rogpeppe1> dimitern: 1) in rpc/rpcreflect, define type NoSuchMethodError {Method, RootMethod string}
<dimitern> rogpeppe1, ok
<rogpeppe1> dimitern: 2) change rpcreflect.MethodCaller to return that error instead of using fmt.Errorf
<dimitern> rogpeppe1, ok, but why do I need RootMethod if I never set it?
<rogpeppe1> dimitern: 3) in rpc, define const CodeNotImplemented = "not implemented"
<rogpeppe1> dimitern: because you'll need it to define the Error return
<rogpeppe1> dimitern: s/return/method
<rogpeppe1> dimitern: (more specifically, NoSuchMethodError.Error)
<dimitern> rogpeppe1, I can do that with only NoSuchMethodError.Method, I don't need RootMethod
<rogpeppe1> dimitern: the message should not change, which means that it should include the root method name too
<rogpeppe1> 4) in rpc, change bindRequest to check if MethodCaller returns a *NoSuchMethodError, and return RequestError{Message: err.Error(); Code: CodeNotImplemented} if so
<dimitern> rogpeppe1, in func (t *Type) Method(name string), the only place NoSuchMethodError is returned, I don't have the rootmethod, so I can't set the RootMethod field
<dimitern> rogpeppe1, ok, so in ObjType.Method as well - but same case - RootMethod is unknown
<rogpeppe1> dimitern: ha, i'd forgotten about ErrNoSuchMethod!
<dimitern> rogpeppe1, yeah, that's what you meant, right?
<rogpeppe1> dimitern: no, i was talking about the error returned from Value.MethodCaller
<dimitern> rogpeppe1, aha!
<dimitern> rogpeppe1, but Type.Method should also change, right?
<rogpeppe1> dimitern: i'm just thinking over that
<dimitern> rogpeppe1, perhaps there, i can use Type.root.Name() to populate the root method
<rogpeppe1> dimitern: there are two places that currently return ErrMethodNotFound
<dimitern> rogpeppe1, yes both Method() methods on Type and ObjType
<rogpeppe1> dimitern: i think we should leave type.go unchanged
<dimitern> rogpeppe1, won't it be confusing to have both NoSuchMethodError and ErrNoSuchMethod?
<rogpeppe1> dimitern: and implement a new type, say CallNotImplementedError
<dimitern> rogpeppe1, sounds reasonable
<rogpeppe1> dimitern: i hope that's sufficiently different to be not confusing
<dimitern> rogpeppe1, ok
<rogpeppe1> 5) in rpc, in Conn.handleResponse, change it to set call.Error.Code = CodeNotImplemented if the error message begins "no such request" or "unknown object type"
<rogpeppe1> dimitern: (with a "deprecate this" comment, because it's only for compatibility)
<rogpeppe1> 6) in rpc, change IsNoSuchRequest to check ErrorCode==CodeNotImplemented
<rogpeppe1> 6b) rename IsNoSuchRequest to IsNotImplemented, or delete entirely.
<rogpeppe1> 7) define params.CodeNotImplemented = rpc.CodeNotImplemented
<rogpeppe1> 8) implement params.IsNotImplemented
<rogpeppe1> 9) 8) change all callers of rpc.IsNoSuchRequest to use params.IsNotImplemented instead
<rogpeppe1> 5a) ... only if the error code is not already set
<rogpeppe1> dimitern: i think that's about it
<dimitern> rogpeppe1, you know, the time it took to explain to me how to do it, you could've probably done it and put it up for review :)
<rogpeppe1> dimitern: it would have taken that amount of time just to run lbox propose once :-(
<dimitern> rogpeppe1, in 5) I presume you mean handleRequest, not response
<dimitern> rogpeppe1, or perhaps writeErrorResponse
<rogpeppe1> dimitern: no, i did mean handleResponse
<dimitern> rogpeppe1, there's no such method
<dimitern> rogpeppe1, ah, sorry
<rogpeppe1> dimitern: in the "case hdr.Error != "":" branch of the switch
<dimitern> rogpeppe1, i'm blind
<rogpeppe1> dimitern: sorry, i should've said it's in client.go
<dimitern> rogpeppe1, but there I don't have the error anymore, so I have to do strings.HasPrefix there
<rogpeppe1> dimitern: yeah, same as IsNoSuchRequest does now
<dimitern> rogpeppe1, well ok
<rogpeppe1> dimitern: lack of foresight on my part i'm afraid - i should have implemented it as an error code when i first did error codes
<dimitern> rogpeppe1, but hdr.Error is a string, so I have to convert it to an error just to check it's string rep
<rogpeppe1> dimitern: huh?
<rogpeppe1> dimitern: it *is* its string representation :-)
<dimitern> rogpeppe1, but IsNoSuchRequest takes an error
<rogpeppe1> dimitern: don't call IsNoSuchRequest
<rogpeppe1> dimitern: see 6)
<rogpeppe1> dimitern: i tried to formulate the CA cert problem in a standalone program and couldn't reproduce the issue. http://play.golang.org/p/WVM3GfphOu
<rogpeppe1> dimitern: (which works fine under both go1.1.2 and go1.2, bother it!)
<dimitern> rogpeppe1, so apparently something is wrong with how our code handles certs
<rogpeppe1> dimitern: i'm not making any assumptions
<rogpeppe1> dimitern: as far as i know, that *is* our code... and it works
<dimitern> rogpeppe1, maybe there are some subtleties which are intervening
<dimitern> rogpeppe1, anyway, I'm almost ready with the CL
<dimitern> rogpeppe1, so no changes needed in bindRequest after all
<rogpeppe1> dimitern: no?
<dimitern> rogpeppe1, the ones in handleRequest did the job, otherwise with changes to bindRequest i get double wrapping
<dimitern> error string = "request error: request error: no such request - method SimpleMethods.No is not implemented (not implemented) (not implemented)"
<rogpeppe1> dimitern: do you mean handleResponse there?
<dimitern> rogpeppe1, oh, yeah right
<rogpeppe1> dimitern: see 5a)
<rogpeppe1> dimitern: i think you should make the change to handleRequest
<dimitern> rogpeppe1, yeah, i'm doing ths
<dimitern> rogpeppe1, which change?
<rogpeppe1> dimitern: because the prefix checking is wrong, and should only be used for compatibility
<rogpeppe1> dimitern: the change to set the error code in the returned error
<dimitern> rogpeppe1, ok, before my head blows, let me propose it, so i can have your comments in one place please
<rogpeppe1> dimitern: oops, sorry, i meant bindRequest...
<rogpeppe1> dimitern: ok, np
<natefinch> So, does anyone know *if* we're installing mongo 2.4 in the field, and if so, where we get it from?  I have directions from TheMue from when I joined to download 2.2 from an amazon s3 address, but none of the likely 2.4 names are available from that bucket.  I am trying to build mongo myself, but their directions appear to be incomplete, because it doesn't build successfully.
<dimitern> rogpeppe1, ok, so it's not really working fully
<dimitern> rogpeppe1, but I'll propose it, so you can pull it and make suggestions how to do it as you think is should be done
<dimitern> rogpeppe1, so only the rpc testBadCall tests fail, all others pass - take a look please and have your say https://codereview.appspot.com/38540044
 * dimitern reached eod
<rogpeppe1> dimitern: looking
<rogpeppe1> dimitern: this fixes those tests: lp:~rogpeppe/juju-core/dimitern-225-unify-not-implemented-errors/
 * rogpeppe1 has also reached eod
<rogpeppe1> g'night all
<thumper> night rogpeppe1
<thumper> fwereade: you around at all?
<thumper> fwereade: I'd like to chat design issues around juju run with you, I'm going to make coffee but back shortly
<dimitern> thumper, he's afk atm
<thumper> hi dimitern
<thumper> dimitern: I kinda guessed that :)
<thumper> i'm trying the ping with context :)
<natefinch> thumper, do you know where/if we keep binaries for mongo 2.4?
<dimitern> thumper, :) just an on-site observation
<thumper> um...
<thumper> natefinch: look in the cloudinit code
<thumper> it has code to add the source for mongodb
<natefinch> thumper, it looks like it's just in the juju/stable ppa, which means it's just 2.2.4
<thumper> natefinch: ah, that may be our patched version of things
<thumper> natefinch: is there mongodb-server in the cloud archive?
<natefinch> thumper: not sure how to check that
<natefinch> thumper: I guess other than deploy a server and go look
<natefinch> thumper: that says 2.4.6.  Just not sure where it's from
<natefinch> I actually started building 2.4.8....  holy crap C++ builds slowly
<marcoceppi> natefinch: is this accurate? https://juju.ubuntu.com/docs/authors-charm-interfaces.html#documenting-interfaces
<marcoceppi> The gets/sets stuff
<marcoceppi> nate, or anyone else
<natefinch> marcoceppi, doesn't sound familiar
<marcoceppi> I didn't think so. I'm going to remove it
<natefinch> nothing like a 15 minute build that fails at the end.
<thumper> gary_poster: you around?
<gary_poster> thumper, yeah, hey
<thumper> gary_poster: can fwereade and I ask you a few questions around the UI and API in a hangout?
<thumper> gary_poster: https://plus.google.com/hangouts/_/7acpijrir4uqnfkk2qgfdtrgpk?hl=en
<gary_poster> thumper, of course. coming
#juju-dev 2013-12-18
<thumper> axw: hey there
<thumper> axw: sinzui_ is having issues with your hp fix branch, seems to have a bad import
<axw> thumper: reading the email now
<axw> eh wtf
<axw> aw crap, I think I enabled goimports and it mucked about with the imports
<thumper> heh
<thumper> axw: so, after talking with fwereade this morning, I'm going to implement a system ssh key right now
<axw> thumper: excellent
 * axw feels vindicated
<axw> ;)
<thumper> davecheney: I don't suppose your ssh go stuff has keygen?
<axw> thumper: AFAIK they
<axw> are just PEM keys
<thumper> axw: I'm not entirely sure what that means
<axw> thumper: same format used by the private keys we generate already
<axw> for mongo
<thumper> oh?
<thumper> hmm...
<axw> thumper: in fact, we could perhaps just use the same one
<thumper> axw: maybe...
<axw> not sure what the requirements are for SSH
<thumper> yeah, well luckily I have another machine here I can ssh to to test
<davecheney> thumper: it wouldn't be hard to write
<thumper> davecheney: yeah, axw said as much
<thumper> I think what I'd like is a function in utils/ssh called "GenerateKey" (surprise)
<thumper> that generates to byte arrays,
<thumper> one private key and one public key
<thumper> equivalents of "id_rsa" and "id_rsa.pub"
<thumper> given the core go team's affinity for crypto
<thumper> chances are all I need is glue
<davecheney> yup
<davecheney> lemmie look in the ssh package tests
<davecheney> we probably have some code
<thumper> davecheney: awesome sauce
 * thumper channels fwereade
<thumper> davecheney: found any? I've found some docs as to the file format, so could hack something up
<thumper> davecheney: but you sould probably be saving me time
<davecheney> thumper: yup
<davecheney> looking after lunch
<thumper> ok
<thumper> ta
<axw> thumper: I'm just looking to see if we can reuse the existing private key we have
<axw> there's code in go.crypto/ssh to generate an authorized_keys line from an RSA public key
<axw> thumper: https://gist.github.com/axw/8016123
<thumper> axw: what about the identity file that you can hand off to ssh?
<axw> thumper: I just fed in the key we give to mongo, added the output of that program to ~/.ssh/authorized_keys, and used ssh -i local-private-key.pem
<axw> thumper: it's just the key file
<thumper> axw: and that works?
<axw> yup
<thumper> awesome!
<thumper> axw: let me poke around in the code and see if I can get this working nicely...
<thumper> axw: I think perhaps we should default to use the system key for 'juju ssh'
<thumper> axw: that would make the windows code work nicer
<thumper> axw: you are doing the ssh util work for windows yes?
<axw> thumper: I'm not so sure we should be passing that key around in the .jenv though, should we?
<axw> that would make it difficult to revoke access
<thumper> axw: oh, interesting point
<axw> thumper: I will be working on making it work for windows, yes
<thumper> hmm...
<thumper> axw: so, what are your thoughts on that?
<thumper> we want a system identity
<thumper> and if we can use the same that we have for mongo, then that should be fine
<thumper> but we still need something to watch bootstrap with
<thumper> perhaps that is a different id?
<axw> thumper: sure, I just don't think we should carry it around outside the system; ideally we should dispose of it after bootstrap
<axw> from the client I mean
<thumper> we want something that will work out of the box with windows users
<thumper> axw: but I think we should create a default user key...
<thumper> or...
<thumper> perhaps we just create the default user key if there is no local one found
<thumper> and that is a separate issue
<thumper> from the bootstrap issue
<axw> thumper: yeah I see your point. I guess we do want another one
<axw> we want the system one to be different to the default one used by the CLI
<thumper> ok, my branch will work to make this system identiy
<thumper> work
<axw> because of revocation
<axw> sounds good
<thumper> axw: yes agree to that last statement
<axw> thumper: I think bootstrap can just create another key if it doesn't have one
<axw> for the CLI
 * thumper nods
<thumper> axw: that is a separate bit of work though
<axw> thumper: yes, I can do that later
<thumper> lets go with the system identity, and using that for the bootstrap
<thumper> ...
<axw> thumper: what about CLI users other than the bootstrapper?
<thumper> not sure yet
<thumper> I'm actually trying to find the code where it loads the authorized keys
<thumper> the code I'm reading seems to indicate that it doesn't bother
<thumper> unless I set them explicitly
<thumper> but I know this is wrong...
<thumper> ugh
<thumper> an OR
<axw> thumper: maybe just updated environs.BootstrapContext to add the key to whatever's computed?
<thumper> axw: is the ca-private-key the thing we use to talk to mongo?
<thumper> axw: if so, that is in the .jenv file in the bootstrap config
<thumper> so perhaps we do want a different identity?
<thumper> something that gets generated and written to cloud init, but not on the client side
<axw> thumper: it is in there, but I think fwereade wants it out
<axw> thumper: and yes that's what we use for mongo
<thumper> ah, fair call
 * thumper goes to make coffee
<thumper> this takes more thinking than I thought :)
<thumper> the identity stuff that is
<thumper> not the making coffee
<axw> hehe
<axw> not enough coffee makes making coffee more difficult
 * axw -> lunch
<hazmat> wrt to put charm api, it appears to be unconditionally setting the scheme to local, deploy cli landing should resolve
<thumper> axw: are you good with me updating our go.crypto to tip?
<thumper> also, how do I find the full hash of an hg tip revision?
<thumper> axw: in the end, I have gone with a ssh.GenerateKey function
<thumper> axw: I'm going to poke things tomorrow and test
<thumper> but for today, I'm done
<thumper> night all
<axw> jam: I *think* the streams.canonical.com URL it's going to is correct, but what's there at the moment is in the wrong place
<jam> axw: that's sort of what I expect as well, and we don't really want to be using it anyway
<axw> that's the impression I got from wallyworld
<jam> the bigger question is what else did we try (and fail) and why
<axw> yep
<jam> and they don't want to use --debug because of security purposes, but that's where we dump all the URLs we try
<axw> It'd be good to see that in "verbose output" (that never got landed did it?)
<axw> thumper's stuff
<jam> verbose was never intended to dump step-by-step stuff,(I think) I think it was meant to stay in --debug, we just dump other useful but-maybe-dangerous stuff there.
<axw> when I'm bootstrapping without --debug, it can sit there doing image/tools stuff for a fair while without any feedback
<jam> --verbose is more about user info about what we're doing
<axw> yeah I suppose that is a bit too much info for general consumption
<jam> I think we also have a bug that we don't write the debug information for the one that actually worked :)
<axw> heh
<rogpeppe1> mornin' all
<axw> hey rogpeppe1
<rogpeppe1> axw: sorry i didn't manage to do your review yesterday - am looking at it now
<axw> rogpeppe1: nps, thanks. actually it gave me time to make it a bit nicer :)
<rogpeppe1> axw: my first thought when i looked at it was that it could probably be factored out into a separate little type
<dimitern> rogpeppe1, jam, https://codereview.appspot.com/38540044/ if you can please
<rogpeppe1> dimitern: will do
<dimitern> ta!
<axw> rogpeppe1: do we need go.crypto pinned at the rev it's at?
<axw> rogpeppe1: thumper's doing some SSH key stuff and was wondering if we can move to the tip
<rogpeppe1> axw: not as far as i'm aware
<rogpeppe1> axw: it would be good to try tip
<axw> ok
<rogpeppe1> axw: but it may not be possible
<rogpeppe1> axw: it might have some go1.2 deps
<axw> yeah ok, will have to check that
<axw> thanks
<jam> axw: so... do you know why we need a juju-run process to be running if we are just ssh'ing into each machine anyway?
<axw> jam: I was under the impression it was not long running
 * axw re-reads thumper's email
<jam> axw: tim's statement was that it couldn't be the existing code because the existing stuff wasn't long lived
<jam> at least, I thought I remembered seeing that
<axw> jam: are you referrng to this statement? `"juju run" is really syntactic sugar around "juju ssh" and the server
<axw> component "juju-run" that does the execution inside a hook context.`
<jam> axw: so I know Tim has a Runner object that sits on a port and lets hooks fire queries into it (the way the current one does, but apparently somehow different)
<jam> it might be that we "juju ssh" into each machine, fire up that juju-run process, and then have it (or something else) spawn of clients that run the script you wrote.
<jam> I'm not sure how it actually all ties together.
<jam> it sounded ilke you ssh in to poke the juju-run process
<jam> but it might be that you are doing "juju ssh juju-run myscript.bash"
<jam> well
<jam> for i in ???; do juju ssh $i juju ssh /usr/bin/juju-run myscript.bash; done
<rogpeppe1> jam: are there some design docs for juju-run somewhere?
<axw> jam: sorry, I haven't actually looked at the code yet - not entirely sure. that's not how I thought it worked. what I thought was that you ssh'd in, then ran "juju-run <hook> <command>", and <command> was executed within the hook context
 * axw looks at code
<axw> jam: so, I have only taken a very brief look, but it looks to me that the runner/socket is just for that process
<axw> it's just reusing the existing jujuc code
<axw> hrm, or maybe not
<jam> axw: related code, but definitely a different object
<jam> can anyone look at: https://codereview.appspot.com/40670043/ its been sitting for a week now
<axw> jam: I see; in that case, I'm not sure why SSH is required here.
<axw> there's still the machine case, but that's a bit different anyway
<axw> jam: I'll take a look
<axw> jam: re the juju-run stuff: how else would you do it? you'd need to put something in state, right? and then record the results there?
<dimitern> rogpeppe1, is it good to land?
<rogpeppe1> dimitern: sorry, still reviewing axw's
<dimitern> rogpeppe1, ok
<jam> axw: so it depends what you want as a result. If you're meant to just trigger a script to run, yes. If you're meant to end up in an interactive session on the remote machine, then you'd have to ssh
<jam> axw: an open question, is this intended to run sequentially on all machines, or would all machines fire up at the same time
<jam> if parallel, then interactive session (or even printing to the screen) is pretty useless
<jam> if sequential, then this really scales poorly when you have 100s of machines
<axw> jam: my understanding is it's meant to be parallel and non-interactive, but I'm not 100% sure
<axw> fwereade: hah, good point about the nonces
<axw> fwereade: yes, pretty certain it was always "manual:..."
<axw> I will double check before basing anything on that tho
<fwereade> axw, cool, thanks
<fwereade> axw, I'm just on destroy-environment at last, sorry delay
<axw> fwereade: cool
<jam> axw: if non-interactive, then it seems like you *don't* want to ssh into each one. (you don't really want to fire off 100 ssh connections all at once, either)
<jam> btw, hi fwereade
<fwereade> jam, heyhey
<rogpeppe1> axw: you have a review
<axw> rogpeppe1: thanks
<fwereade> jam, axw: `juju run` is non-interactive, there's juju ssh for direct interactivity
<axw> right
<fwereade> jam, axw: the actual degree of parallelism required has not been specified, but a number of ideas have been floated around the concept
<jam> fwereade: so some review questions... Do we want to have 'remove-machine' in a 1.16 branch? It has been approved, but it is more of a do-we-want-this-policy
<fwereade> jam, axw: round-robin has been mentioned; parallel has been mentioned; parallel with horrid hacked-on interactivity has ever come up
<fwereade> jam, what do we gain from a new 1.16 with that in?
<jam> fwereade: or it could be driven from the db without ssh at all?
<jam> fwereade: compatibility, especially with docs
<jam> though you still have "you must have newer than X"
<jam> but it would make "remove-machine" available in a stable release
<axw> jam: the only thing I see being an issue with going through the db is that there's no ephemeral node support to handle the edge cases around client termination
<axw> jam: it's not interactive, but there's still a session to maintain
<axw> rogpeppe1: "This should probably allow itself to be stopped when closed.j"  -- do you mean use an additional select with a time.After?
<rogpeppe1> axw: yeah
<axw> thanks
<jam> axw: I don't quite see how it is different from how we fire hooks normally, it is just a custom script instead of a charm hook
<rogpeppe1> dimitern: reviewed
<dimitern> rogpeppe1, thank
<dimitern> s
<axw> jam: the main difference is that the result needs to live somewhere. who owns that?
<fwereade> jam, sorry, I missed the context on remove-machine
<fwereade> jam, did you have any thoughts re the more human vocabulary I handwaved around in that thread yesterday?
<jam> axw: seems easy enough to put it into the DB as a result of running the request
<fwereade> jam, axw: questions of how much we store and for how long become interesting
<jam> fwereade: so, there was a discussion that we should use "remove-*" for stuff instead of "destroy-*" and it is easy to add those aliases into a 1.16 release. I have a fairly trivial patch up, just waiting on whether we *want* to do it. Its approved, but I wanted to run it by you.
<fwereade> jam, so, indeed, I think I am now up to speed on it
<jam> fwereade: as for your natural language stuff, I think you had interesting points, but part of that is what we can evolve into, and we can have a consistent lower level terminology
<jam> fwereade: for juju-run, if you aggregate the results somewhere (like the DB) then you do need a way to see it (is the suggestion that normally it just prints to your console via ssh?) that still seems like a whole lot of spam unless you very carefully craft the script to give enough context so you can figure out which machine actually "failed"
<jam> so either, there isn't much result, so it doesn't matter, or there is some result, but you'd really rather have that logged and aggregated
<jam> you *can* do "juju run foo.sh >aggregate.this.txt"
<rogpeppe1> jam, fwereade: is there a design doc for juju-run? i'd like to contribute to the discussion, but i don't actually know what the goals are.
<axw> rogpeppe1: updated
<rogpeppe1> axw: re: "shouldn't this use the mutex?"
<rogpeppe1> axw: it looks to me as if inst.InstanceId is inside the embedded ec2.Instance
<rogpeppe1> axw: and hence should be protected by the same mutex
<axw> rogpeppe1: gah, so it is
<axw> rogpeppe1: sorry, will fix it now
<rogpeppe1> axw: thanks
<jam> rogpeppe1: I don't know of one, but tim is the one driving it
<axw> rogpeppe1: updated again, sorry about that
<rogpeppe1> axw: np
<axw> bbl
<jam> rogpeppe1: axw, mgz_: standup
<jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<jam> fwereade: poke about where to put worker/provisioner/authentication.go
<fwereade> jam, how do you feel about environs?
<jam> fwereade: so "NewAPIAuthenticator" doesn't feel like it should be in environs
<jam> and NewEnvironAuthenticator feels ok there
<jam> the issue is that they both want to share the actual underlying implementation
<fwereade> jam, well, it's about giving access to a <handwave> environ
<jam> which just has a way to get a StateInfo and then populate it with its final machine password stuff
<fwereade> jam, I'm at least halfway inclined to just give it its own package somewhere
<fwereade> jam, the only thing I'm sure of is that it's not exclusive to worker/provisioner, but it is something to do with setting up instances
<jam> fwereade: arguably the simpleAuth code should be exposed in state/ and the others lay on top of that?
<fwereade> jam, state doesn't seem very correct, in every case but bootstrap I think it's api-ey really
<jam> well, the api server uses it internally
<jam> which is why NewEnviron* is still necessary
<fwereade> natefinch, https://codereview.appspot.com/36290043/patch/190001/200015 is going to collide with you, isn't it?
<natefinch> fwereade, ish.  Shouldn't be a big deal.
<mattyw> fwereade, jam I still can't reproduce the problem in https://code.launchpad.net/~mattyw/juju-core/add-owner-to-service/+merge/191192. I sometimes see Error: Test left sockets in a dirty state but no other errors (although that happens on trunk as well - has done for a while)
<mattyw> ^^ any idea what might be going wrong?
<jam> mattyw: we've had some issues with flaky tests, I just wanted to know if this was caused by your change. As it doesn't seem related, I'll just submit again.
<jam> fwereade: when are we running mongo without ssl?
<mattyw> jam, ok thanks - I'll keep an eye on it
<natefinch> man, this USB ethernet adapter crashing my laptop is not cool (especially given there is no ethernet plug on the laptop).....
<natefinch> anyway, I have to go snowblow my driveway, which will probably  take me a couple hours all told.
<natefinch> jam, rogpeppe1: I verified that the test failure I'm having definitely is only happening with mongo 2.2, and not 2.4.  Not sure exactly why yet, but now that I can A/B test easily, I should be able to figure it out.
<fwereade> jam, sorry I missed you -- it's for the store... but I am suddenly suspicious of the Right Thing to do there
<fwereade> jam, I think it's probably better to factor out the existing store test harness and use that
<fwereade> jam, than to introduce a fresh entanglement between the two
<rogpeppe1> wow, my internet is super flaky today
<rogpeppe1> can anyone see this?
<mattyw> rogpeppe1, I can
<rogpeppe1> mattyw: ok, that's something at least :-)
<mattyw> rogpeppe1, also - I'm getting a "x509: certificate is valid for *" error when trying to connect to the core api on 17070 (it seems to happend in my call to websocket.Dial)
<mattyw> is there a particular version of websocket I should be using do you think?
<rogpeppe1> mattyw: could you paste the code that you're using to dial?
<rogpeppe1> mattyw: in general, you should be using the state/api package to connect to the API
<rogpeppe1> mattyw: (assuming you're using Go)
<mattyw> rogpeppe1, I am, I was just kinda messing around with connecting to the websocket in go
<rogpeppe1> mattyw: you can connect if you use InsecureSkipVerify
<mattyw> rogpeppe1, 	ws, err := websocket.Dial("wss:/adr:17070", "", "http://localhost")
<mattyw> ah, I'm not doing any tls at all
<rogpeppe1> mattyw: otherwise your client won't know about the root CA cert that's used for the server
<rogpeppe1> mattyw: you *are* doing tls
<rogpeppe1> mattyw: that's the "wss:" thing
<mattyw> rogpeppe1, but I'm not setting up any tls config
<rogpeppe1> mattyw: ah yes.
<mattyw> (which is what I meant in my head at least :))
<rogpeppe1> mattyw: look at how it's done in state/api/apiclient.go:/Open
<mattyw> rogpeppe1, will do, thanks again
<axw> rogpeppe1: https://codereview.appspot.com/43650045 exercises the Addresses/Refresh code in provider/ec2
<rogpeppe1> axw: looking
<axw> rogpeppe1: I updated provider/ec2 again, there was a bug
<mattyw> rogpeppe1, thanks for the acme-friendly shortcut ;)
<rogpeppe1> mattyw: are you using acme now?
<rogpeppe1> axw: what was the bug?
<axw> rogpeppe1: Addresses was holding the lock around refresh(), which called inst.Id() and took the lock
<axw> well, tried to
<axw> so, deadlock
<rogpeppe1> axw: ah, good thing i suggested the test then :-)
<axw> very
<rogpeppe1> axw: i still think we should use AddScripts rather than AddFile - someone might change AddFile to use the cloudinit write_files feature, which would then potentially break the nonce.txt logic
<axw> rogpeppe1: fair point
<axw> ok, I'll change it
<rogpeppe1> axw: thanks
 * rogpeppe1 goes for lunch
<jamespage> hazmat, re mongodb build without scripting - which scons option are you referring to?  I can toggle between v8 and spidermonkey in our current source package (2.4.8) but I can't figure out how to disable it completely
<axw> rogpeppe1: can you please approve the ec2test MP when you're back? I'm not in the group
<hazmat> jamespage, usev8
<axw> rogpeppe1: and/or merge it if there's no bot
<hazmat> jamespage, https://github.com/mongodb/mongo/blob/master/SConstruct#L452
<hazmat> jamespage, it comes up a few times.. agreed its not clear if its  toggle for spidermonkey or disable
<jamespage> hazmat, it certainly was
<jamespage> but upstream don't ship spidermonkey any longer
<jamespage> "--usesm"
<hazmat> jamespage, so reaching out to upstream sounds like the thing to do.. i don't see the usesm option in trunk scons.
<hazmat> either that or trying a build without the v8 option
<jamespage> hazmat, no its gone
<jamespage> hazmat, if you don't specify it default to v8
<jamespage> I'll poke at it a bit
 * hazmat fires up a build on a spare server
<dimitern> jam, rogpeppe1, https://codereview.appspot.com/43860043 AddCharm via the API
<axw> fwereade: the nonce for manual bootstrap nodes does not start with "manual:". do you think it's still okay to use it, documenting that?
<rogpeppe1> niemeyer: does this look reasonable to you? https://codereview.appspot.com/43650045/
<axw> fwereade: that case *could* be detected by checking that id == "0" && extracting the provider type from EnvironConfig, but that's pretty heavy handed
<fwereade> axw, hmm, possibly, I don't suppose that one has any useful distinguishing features?
<axw> fwereade: not that I've thought of so far
<niemeyer> rogpeppe1: What happens in practice?
<niemeyer> rogpeppe1: I mean, what is the real EC2 doing about this?
<rogpeppe1> niemeyer: the DNS name appears some time after the instance has been started
<axw> fwereade: its instance-id is "manual:", but we've established that's not good enough to rely on
<rogpeppe1> niemeyer: so any realistic client will need to poll it
<niemeyer> rogpeppe1: Sounds good then
<rogpeppe1> niemeyer: cool, thanks
<niemeyer> rogpeppe1: np, thanks for asking
<rogpeppe1> axw: will submit now
<fwereade> axw, you know, I'm not so bothered by the weight as I am by the correctness
<fwereade> axw, it's not a cost we'll be paying often enough to worry about, I think
<axw> rogpeppe1: thanks
<axw> fwereade: true
<axw> fwereade: in fact, I won't even be passing it in in my case, because I don't check manager machines
<fwereade> axw, thought that might be the case
<axw> fwereade: so, now might be a good time to change the provider name from "null" to "manual"
<fwereade> axw, please still test that behaviour in case we do ever end up with demoted machine 0s ;)
<axw> certainly
<fwereade> axw, most certainly, but I suspect that may take some finessing around upgrades
<fwereade> axw, *maybe* you could get away with registering the same provider twice under different names..?
<axw> hmm maybe, will have to see. I can make this code check for either "null" or "manual" for now
<rogpeppe1> axw: FYI i just got this error when bootstrapping:
<rogpeppe1> Connection to ec2-54-196-224-38.compute-1.amazonaws.com closed.
<rogpeppe1> error: cannot open state: cannot create log collection: unauthorized mongo access: unauthorized
<rogpeppe1> axw: i haven't looked into it but i suspect something is trying to talk to mongo before it's ready
<axw> rogpeppe1: hmm, there's no changes regarding mongo communications in synchronous bootstrap
<axw> rogpeppe1: are you on trunk?
<rogpeppe1> axw: yeah
<axw> rogpeppe1: with my just-merged branch?
<axw> I'll test it again
<rogpeppe1> axw: hmm, not sure
<axw> rogpeppe1: shouldn't actually matter, just curious
<rogpeppe1> axw: it's the kind of thing that wouldn't happen very often, if it's what i suspect
<rogpeppe1> axw: i'll see if it happens again
<rogpeppe1> axw: your goamz branch is now merged
<axw> rogpeppe1: great, thanks
<axw> rogpeppe1: ah, I should've updated dependencies.tsv... will do that now
<rogpeppe1> axw: good point
<rogpeppe1> axw: revno 44
<axw> thanks
<rogpeppe1> axw: ah, it's not bootstrap's fault at all
<rogpeppe1> axw: i just wasn't printing enough log messages
<axw> rogpeppe1: thanks for checking
 * rogpeppe1 reboots
<axw> night all
<dimitern> natefinch, ping
<dimitern> natefinch, can you take a look at this please? since roger is not around. https://codereview.appspot.com/43860043
<natefinch> dimitern, sure
<mattyw> fwereade, I guess we should have a chat about the next stage of the juju id stuff
<natefinch> dimitern, can we put Info in the charm.Repository interface? I'd much prefer that than doing some casting to anonymous interfaces to access that method.
<dimitern> natefinch, actually, I wasn't sure about using Info() or maybe just lazy not to calculate the sha256 from the already downloaded file
<dimitern> natefinch, i'll change that to use only Get and read and calculate the hash from the downloaded charm
<natefinch> that also works
<rogpeppe> dimitern: you've got a review
<rogpeppe> natefinch, dimitern: i made an alternative suggestion
<rogpeppe> natefinch, dimitern: which hopefully works out a bit simpler than calculating the hash yourself
 * rogpeppe is done for the day
<rogpeppe> darn juju-restore is destroying its own re-bootstrapped machine
<rogpeppe> g'night all
<natefinch> thumper, morning
<thumper> o/ natefinch
 * thumper trawls through the overnight emails
<natefinch> thumper, how's your knowledge of mongo?
<thumper> natefinch: virtually non-existent
<natefinch> thumper, heh.  My HA tests are failing on 2.2 but passing on 2.4.... and I can't figure out why.
<thumper> hmm... trying to bootstrap ec2 failed with an error around simple streams
<thumper> WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju
<thumper> ERROR bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9: element <hr> closed by </body>
<natefinch> thumper sounds like you might be getting a 404 not found page instead of the XML you're supposed to get, and it's trying to parse the page's HTML
<thumper> natefinch: that's what I thought too
<thumper> but since I actually needed to upload tools
<thumper> it was a convenient error
<natefinch> heh
<natefinch> thumper, it does worry me that we're not checking the http error code before trying to parse what's returned, though
<thumper> heh
<thumper> yeah
<thumper> should file a bug
<thumper> I'm now confused...
<thumper> with my work
<thumper> WTF!
<thumper> natefinch: hangout?
<thumper> it might help if I talk this through
<natefinch> sure... one sec
<thumper> natefinch: I worked it out :)
<natefinch> thumper, ha, ok, cool
<thumper> dumb permissions...
<natefinch> thumper, heh, something like that happened when I was building mongo from source yesterday.  30 minute build, fails at the very end with a permissions issue.
<thumper> I have code that now creates a juju system ssh identity file and adds to the authorized keys
<thumper> and it works for ec2 and local
<thumper> so probably everything
<thumper> although care should be taken with manual
<thumper> wallyworld_: o/
<wallyworld_> heloooo
<thumper> wallyworld_: good break?
<wallyworld_> so many emails
<thumper> :)
<wallyworld_> yeah, no internet
<wallyworld_> great result in the cricket :-D
<thumper> wallyworld_: I'm heading off to the gym shortly, but we have a scheduled call in just over 2 hours
<wallyworld_> yep
<thumper> so we can chat then
<wallyworld_> ok
#juju-dev 2013-12-19
<thumper> wallyworld_: I'm in the hangout now if you feel like joinging
<thumper> or joining
<thumper> o/ axw
<axw> heya thumper
<thumper> axw: just for you https://codereview.appspot.com/43730044/
<axw> cool beans
<davecheney> sinzui: i cannot reproduce that failure in aws
<davecheney> does anyone have hp credentials I can use ?
<axw> thumper: why did you end up not using they private key we already have?
<thumper> axw: it felt wrong
<thumper> that's the guts of it
<thumper> hard to explain
<axw> mmk
<thumper> I think separate keys for different jobs is a good thing
<wallyworld_> +1
<thumper> ugh
<thumper> need coffee
 * thumper decides not to wait for Rachel
<axw> wallyworld_: why did you remove TestNoWarningForDeprecatedButUnusedEnv?
 * axw is particularly slow today
<wallyworld_> axw: not sure. that code block was in a place that tested for deprecated attr processing which was moved. i must have missed the fact that there was a test which should have been kept
<wallyworld_> i'll take a look and add it back if needed.
<axw> wallyworld_: thanks
<wallyworld_> i'm the one who is slow
<wallyworld_> thumper: it seem we already show rev info in status, at least at the service level. the charm url includes the rev no
<wallyworld_> did we need to extend that to the unit level? is it possible to have units with different rev numbers to the parent service?
<thumper> wallyworld_: I don't think so
<thumper> wallyworld_: I think all our charms should be at the same version
<thumper> wallyworld_: and all we actually care about is the service itself, not the individual units
<thumper> I think
<wallyworld_> thumper: we do record versions for unit charms and i can see how a unit charm could get out of date with the nominal service version so we may want to report on both
<wallyworld_> thumper: fwiw, i've hacked togethe rsome code to produce the following https://pastebin.canonical.com/102221/
<dimitern> rogpeppe, morning
<rogpeppe> dimitern: hiya
<dimitern> rogpeppe, I decided to change the code to calculate the hash in place
<rogpeppe> dimitern: why?
<dimitern> rogpeppe, instead of messing with charm store code
<dimitern> rogpeppe, it's just 5 lines of code anyway
<rogpeppe> dimitern: you don't need to mess with the charm store code - just the charm client code
<rogpeppe> dimitern: and it already calculates the hash in exactly the way we need
<rogpeppe> dimitern: and it's actually a trivial change
<dimitern> rogpeppe, how about if we support github charms?
<dimitern> rogpeppe, then the hash and size have to come from the file we download
<rogpeppe> dimitern: then we can implement GetBundle on the GithubRepository
<dimitern> rogpeppe, this way it's more future proof, in case we need to support other stores than the charm store
<rogpeppe> dimitern: i think it's good that the charm package is in charge of calculating the hashes in exactly the right way
<rogpeppe> dimitern: if we implement github charms, we won't put the code to talk to github inside the api server, will we?
<dimitern> rogpeppe, well, I talked to william and we decided it's best to do it that way
<rogpeppe> dimitern: we'd implement it in the charm package
<dimitern> rogpeppe, I have updated https://codereview.appspot.com/43860043/
<dimitern> rogpeppe, we can change it later if needed
<rogpeppe> dimitern: your code will fail with github charms anyway, as you're type asserting the downloaded charm to *charm.Bundle, and github charms will probably not be in bundled form
<rogpeppe> dimitern: if you're asserting that the result is a bundle, you may as well leverage the code that knows that (and knows the sha sum)
<rogpeppe> why do we have to make things more complex than they need to be?
<dimitern> rogpeppe, please, I want to get on with it and start on ServiceDeploy
<axw> rogpeppe: I've updated https://codereview.appspot.com/38240043/, but the diff got messed up after I merged in trunk. I might just end up doing a new CL... but the changes are all in there
<rogpeppe> axw: thanks - currently i need to finish my action item before the meeting, but will take a look afterwards
<axw> rogpeppe: no problems, thanks
<axw> jam: FYI, destroy-environment is LGTM'd, just need to do a final test and I'll land it (hopefully this evening)
<dimitern> rogpeppe, thanks for the review btw
<rogpeppe> dimitern: np
<dimitern> rogpeppe, jam, mgz, meeting?
<thumper> fwereade: you too
<jam> mgz: if you're around, weekly standup is now
<axw> jam: not sure if it's related to compatibility, but add-machine seems to be busted on trunk
<axw> I'm digging into it now
<jam> axw: I'm just finishing up my patch to do 1.16.3 compat add-machine
<axw> jam: I mean targeting a 1.17.0 env
<axw> actually I'm not on trunk, I shouldn't assume it's in the truk code... just pretend I didn't say anything yet
<axw> wallyworld_: authenticationworker doesn't look happy
<wallyworld_> i what way?
<axw> it's continuously dying, with "generating key fingerprint: exit status 1"
<wallyworld_> hmmm. sounds like ssh-keygen is not being run
<wallyworld_> that should be installed i would hope
<axw> wallyworld_: I'll have a look
<wallyworld_> it runs ssh-keygen -lf blah from memory
<wallyworld_> i ran a system on trunk today and it appeared fine
<axw> wallyworld_: it's there, and running that directly works fine
<wallyworld_> hmmm
<wallyworld_> axw: sadly i think our command running infrastructure tends to swallow the real error, so possibly some debug code might be needed
<wallyworld_> is this for an env you are running on ec2 or?
<axw> wallyworld_: azure
<wallyworld_> i'm not sure what would be wrong
<axw> wallyworld_: I can see one of the RPC responses is returning what looks like a list of authorised keys, one of which is ""
<wallyworld_> that's interesting. i wonder what the authorised_key file has in it
<axw> wallyworld_: and authorized-keys in my .jenv has a blank line at the end
 * axw looks
<wallyworld_> the \n are supposed to be stripped out
<wallyworld_> well, they are when reading the .ssh/auth_keys file
<wallyworld_> and also the auth_keys env setting from the db
<wallyworld_> not sure about the jenv
<wallyworld_> but i would hope so
<axw> wallyworld_:  ~ubuntu/.ssh/authorized_keys has a single line, with a key on it
<wallyworld_> that sounds correct
<axw> wallyworld_: looks like that's it
<axw> wallyworld_: I did juju set-env with what it had minus the blank line, and it's fixed
<wallyworld_> so you saying if the auth keys env setting has a blank line it barfs?
<axw> wallyworld_: yes
<axw> wallyworld_: well, I'll try add it back in and see what happens
<wallyworld_> from memory blnak lines are ignored everywhere else, i think perhaps i though env setting would not have blank lines
<axw> wallyworld_: although, is it too late after it's started?
<wallyworld_> you should be able to use set-env i think
<wallyworld_> i wonder how the env setting got an extra \n added
<wallyworld_> i will do a patch to fix it, curious how it got there though
<wallyworld_> cause as i said, i ran up an ec2 env today and it appeared ok
 * axw shrugs
<axw> I'm not sure why it'd be blank, I'm not familiar with that code
<axw> oh shit, add-machine has been working, it's just returning an error as well
 * axw quickly destroys 5 machines
<wallyworld_> the code should be defensive anyway. the \n issue is handled properly for reading .ssh/auth_keys etc
<dimitern> rogpeppe, natefinch, https://codereview.appspot.com/44240045 deploy using the API
<rogpeppe> dimitern: looking
<rogpeppe> dimitern: do you need to worry about compatibility with an API server that has API EnvironmentGet but not AddLocalCharm ?
<rogpeppe> dimitern: i'm concerned that the code that's in cmd/juju/deploy.go won't actually cope with a legacy environment
<dimitern> rogpeppe, 1) wasn't sure, because EnvGet was there before and some 1.16 releases have it I think
<dimitern> rogpeppe, 2) what do you mean?
<rogpeppe> dimitern: one mo, just checking something
<rogpeppe> dimitern: have you verified that 1.16 environments return a MethodNotAllowed status when trying to POST?
<dimitern> rogpeppe, yes
<rogpeppe> dimitern: ah, that's lucky
<rogpeppe> dimitern: i guess the websocket handler does the right thing there
<rogpeppe> dimitern: we'll have to be a bit careful when we do charm GETs though
<dimitern> rogpeppe, agreed
<axw> rogpeppe: I got an LGTM on https://codereview.appspot.com/41280043/, but it occurred to me today as I was testing that we should probably have a --force on destroy-environment now to not call the API
<axw> rogpeppe: does that sound okay to slip in there?
<rogpeppe> axw: we definitely need that, yes
<rogpeppe> axw: how much of a change to that CL do you think it will be?
<axw> rogpeppe: +8/-4 lines in destroyenvironment.go
<rogpeppe> axw: well worth it
<axw> rogpeppe: basically just adding a boolean flag to destroy-environment, and not callig the API if it's enabled
<axw> does that sound sensible to you?
<rogpeppe> axw: yeah.
<axw> rogpeppe: thanks for the review before. I'll unexport the testing.BootstrapContext type as you suggested
<axw> rogpeppe: it needed to be because the embedded Context is modified in tests
<axw> rogpeppe: but I'll just have the constructor take a cmd.Context as an arg instead
<rogpeppe> axw: ok
<axw> rogpeppe: what makes you say that Bootstrap is no longer viable inside a web service? I don't see how any of the recent changes would prevent that
<rogpeppe> axw: if you're running it inside a web service, how would you, for instance, allow the user to enter an ssh password inside the web page when requested?
<axw> rogpeppe: you don't ever need to, unless you're doing manual provisioning
<rogpeppe> axw: it would be nice to be able to do manual provisioning too, i'd imagine
<axw> rogpeppe: actually, that's possible too with a pty
<rogpeppe> axw: and expect(1)-like logic...
<rogpeppe> axw: yuck :-)
<axw> rogpeppe: how else would you do it?
<rogpeppe> axw: i'd make the package API have some kind of a password callback function
<rogpeppe> axw: and use sshpass to call back into juju
<rogpeppe> axw: it would definitely be more work though
<rogpeppe> axw: for not much benefit at this point
<axw> rogpeppe: sshpass wrapping juju doesn't seem viable, since we shell out multiple times
<axw> rogpeppe: not sure if you saw the branch, but you can now set $SSHPASS and sshpass will be used if it's available
<rogpeppe> axw: that's ok, but it's unfortunately global
<axw> true
<axw> rogpeppe: alternatively we could just use go.crypto/ssh, which I've started looking into when the system shell isn't available for bootstrapping
<axw> rogpeppe: I was also thinking that it'd be nice to be able to manually provision from the GUI
<axw> that could be useful there
<rogpeppe> axw: i'd be so much happier if we could do that, but i know that the go.crypto/ssh is in a state of flux
<rogpeppe> axw: it's also important if we want to run under non-unix platforms
<axw> rogpeppe: yes indeed, that's the prime motivation at the moment - Windows CLI is currently broken on 1.17
<rogpeppe> axw: forgive my badly-articulate comments, but i just wanted to indicate some level of discomfort...
<rogpeppe> s/ate/ated/
<axw> rogpeppe: not at all, I'm glad to discuss it. if CLI things are getting too interwoven with the core, then that's not ideal
<rogpeppe> axw: yeah, it's the kind of thing that feels a bit like breaking of abstraction boundaries
<rogpeppe> axw: i also feel like that with respect to the Stderr stuff, BTW
<rogpeppe> axw: i've been wondering whether we could leverage the logging mechanism instead of that
<rogpeppe> axw: for instance logging to the "progress" module could be a convention for printing progress messages
<rogpeppe> axw: which would make it easy to run in quiet mode, for example (which is something we don't support now, AFAIK)
<axw> rogpeppe: I thought thumper was working on something longer-term for that, but I don't know what happened
<rogpeppe> axw: i don't know anything about that
<dimitern> rogpeppe, review poke
<dimitern> :)
<rogpeppe> dimitern: i'm still on it, sorry
<rogpeppe> dimitern: it's been a bit involved
<dimitern> rogpeppe, np, just checking :)
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, ta!
 * rogpeppe passes the -e flag to destroy-environment almost every time :-\
<dimitern> rogpeppe, ok, I just checked EnvironmentGet was not available in 1.16, so checking for IsCodeNotImplemented there will allow nice splitting of 2 straight code paths
<dimitern> rogpeppe, InferURL will return an error when defaultSeries is empty and the URL does not provide one
<rogpeppe> dimitern: cool
<rogpeppe> dimitern: yeah, i checked that InferURL error
<rogpeppe> dimitern: but you might want to make it return a specific error in that case
<dimitern> rogpeppe, I don't think skipping EnvironmentGet for the sake of 1 less round-trip is worth it, because we need the config later anyway (for local charms), and most importantly will allow me to gate the 1.16 compatibility code nicely
<rogpeppe> dimitern: sure, that's good enough reason to keep it for the time being
<dimitern> rogpeppe, that's and entirely different CL
<rogpeppe> dimitern: BTW why do you need the config for local charms?
<dimitern> rogpeppe, but I agree that behavior can be better
<rogpeppe> dimitern: (i can't see that it's used in that case, but i'm probably missing something)
<axw> dimitern, rogpeppe: do either of you have time for a small review? hazmat found a bug, and is waiting on this: https://codereview.appspot.com/44200043/
<rogpeppe> axw: will look
<axw> thanks
<dimitern> rogpeppe, we need the config to get the default series
<rogpeppe> dimitern: so you need that for local or cs charms, right? depending on whether the user specified the series in the charm url.
<rogpeppe> dimitern: that's just the step i was suggesting that could be skipped.
<rogpeppe> axw: reviewed
<axw> rogpeppe: ta
<dimitern> rogpeppe, both local and cs charms
 * rogpeppe goes for lunch
<mramm> anybody for the cross team meeting?
<natefinch> mramm: if you need a warm body, I can sit in
<dimitern> rogpeppe, when you're back, I've updated https://codereview.appspot.com/44240045/ and I think it's ready to land
<natefinch> man #mongodb is useless.  Asked twice in two days for suggestions about this 2.2 vs 2.4 problem I'm having with replicasets, and can't even get anyone to respond
<natefinch> makes me glad I've at least responded to people asking questions on here
<mgz> two times is certanly fall back to mailinglist moment
<sinzui> hazmat, The devs want to release 1.17.0 this week, and then do a 1.17.1 the first week of January. Does that work for you?
<sinzui> hazmat, I see axw has three things in review. Are these the items you wanted in a release: https://code.launchpad.net/~axwalk
<natefinch> mgz: I posted to their google group, can't hardly get anyone to even look at my post :/  They don't seem to have a more traditional mailing list
<natefinch> mgz: granted, it's only been a couple hours
<hazmat> sinzui, sounds good
<hazmat> sinzui, just the manual detection stderr, there will be more i suspect though in the new year.
<hazmat> i've worked around it for now, by shipping binaries built from the branch
<sinzui> hazmat, fab. I am writing release notes. I expect it to take most of my day. I will release any goodness that arrives in trunk while I write
<rogpeppe> dimitern: looking
<dimitern> rogpeppe, thanks
<dimitern> rogpeppe, and once you're done with it, I have one last one: https://codereview.appspot.com/44230045/
<dimitern> :)
<rogpeppe> dimitern: with regard to this:
<rogpeppe> Of course we do! The changes actually assume we're using the API properly,
<rogpeppe> instead of in a compatible mode.
<rogpeppe> AFAICS the changes don't assume anything of the sort
<dimitern> rogpeppe, yes?
<dimitern> they do
<rogpeppe> the API works equally well if someone isn't using the API properly
<dimitern> checking the charm exists in state implies this
<rogpeppe> thus the old code is perfectly sufficient
<rogpeppe> AFAICS
<dimitern> the old code will be gone eventually
<dimitern> so the API shouldn't do more than it should and duplicate features
<rogpeppe> dimitern: sure - when we want to break compatibility, we can remove the PutCharm piece
<rogpeppe> dimitern: i don't understand that last remark
<rogpeppe> dimitern: the API behaviour has not changed at all
<dimitern> we have Add(Local)Charm and ServiceDeploy - all API calls taking charm urls assume they're already in stte
<dimitern> state
<rogpeppe> dimitern: so why change the code?
<dimitern> rogpeppe, a good API has one call per feature more or less, not some calls that internally do what other calls are doing in a different way
<rogpeppe> dimitern: i'm not saying that we should not change it in the future
<rogpeppe> dimitern: that's definitely the plan
<rogpeppe> dimitern: but i don't see that we need to change it now
<rogpeppe> dimitern: because we still need all the old (addcharm + putcharm) functionality for backward compatibility
<rogpeppe> dimitern: can you give me an example of how the new API call differs at all semantically from the old API call?
<dimitern> rogpeppe, yes
<dimitern> rogpeppe, when the charm is there, no conn is used at all
<fwereade> rogpeppe, I think the idea here is to structure the code so as to demonstrate intent, and what's important, and make it easy to extract the simpler version
<rogpeppe> fwereade: honestly, i think that a simple comment is sufficient there
<fwereade> rogpeppe, and demanding that add-service reference a charm is no worse than demanding that add-unit reference a service ;p
<rogpeppe> fwereade: rather than cluttering the logic
<rogpeppe> fwereade: the new code does not demand that
<rogpeppe> fwereade: it's exactly the same as the old call
<rogpeppe> fwereade: except with more logic
<rogpeppe> fwereade: and maybe a touch more efficient (as dimitern says, it avoids an EnvironConfig when the charm already exists in state)
<fwereade> rogpeppe, the extra logic looks to me like it's separating the weird and deprecated bits from the intended thrust of the logic
<rogpeppe> fwereade: (but we could easily avoid that by making conn.PutCharm a function that takes a *state.State as an argument rather than requiring a Conn
<rogpeppe> fwereade: it looks a lot more complex to me, and it really isn't that complex.
<fwereade> rogpeppe, it STM to exist for a valid purpose
<rogpeppe> fwereade: which is?
<fwereade> rogpeppe, to structure the code so as to demonstrate intent, and what's important, and make it easy to extract the simpler version
<rogpeppe> fwereade: (i can understand the old logic at a glance; i'm spending a while on the new logic now)
<fwereade> rogpeppe, the old logic is wrong, though, right? it barfs on local charm urls
<rogpeppe> fwereade: i don't see how it makes it any easier to extract the simpler version (which will be *much* simpler)
<fwereade> rogpeppe, there needs to be some sort of change
<rogpeppe> fwereade: that is a good point about the local charm barfing
<rogpeppe> [16:45:59] <dimitern> rogpeppe, when the charm is there, no conn is used at all
<rogpeppe> actually that doesn't appear to be the case
<rogpeppe> dimitern: i think you can lose the need1dot16Compatibility variable entirely and things become much simpler (and i'll be happier :-
<rogpeppe> ])
<dimitern> rogpeppe, sorry, yes
<dimitern> rogpeppe, I was thinking of upgrade-charm
<dimitern> rogpeppe, but it needs conn because of DeployService - we can get rid of this once we drop 1.16 compat + PutCharm and stuff
<rogpeppe> dimitern: let's just turn DeployService into a function that takes state.State as an argument
<rogpeppe> dimitern: it has no need to be a method on Conn
<sinzui> Hi devs. I am pondering why Hp is so prone to interment mysql hook errors. I wonder if the machine is under powered. Do you think 2G for mysql + juju agent is low?
<dimitern> rogpeppe, and conn.AddUnits as well
<rogpeppe> dimitern: yeah
<dimitern> rogpeppe, then we can skip creating a conn entirely for the API I think
<rogpeppe> dimitern: indeed
<dimitern> rogpeppe, compat. code will still be using it though
<rogpeppe> dimitern: it's easy to change conn.DeployService(...) into juju.DeployService(conn.State, ...)
<dimitern> rogpeppe, yeah, I agree, let's do that
<dimitern> rogpeppe, and land it :)
<dimitern> rogpeppe, and this will also fix bug 1216830
<_mup_> Bug #1216830: apiserver should not depend on Conn <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1216830>
<rogpeppe> dimitern: i don't think you actually need to call Conn.PutCharm at all BTW
<rogpeppe> dimitern: am just making a small suggestion
<dimitern> rogpeppe, it's needed, because the GUI doesn't yet use Add(Local)Charm() calls
<dimitern> rogpeppe, and needs to keep working
<rogpeppe> dimitern: ha, but you can call Client.AddCharm from Client.ServiceDeploy...
<dimitern> rogpeppe, so alas, the bug cannot be fixed because of this single PutCharm
<dimitern> rogpeppe, hmm
<dimitern> rogpeppe, yes, actually!
<rogpeppe> dimitern: yeah, i've just published that suggestion
<rogpeppe> dimitern: it takes the compatibility code down to 4 lines
<dimitern> rogpeppe, cheers, looking
<dimitern> rogpeppe, about a cs: charm deploy test - I really tried, in fact I was almost at the point of changing the mock charm store to have all methods of *charm.CharmStore and making the latter an interface, but it's too much work for this CL
<rogpeppe> dimitern: yeah, i wondered that
<dimitern> rogpeppe, fortunately I tested charm deployment from the charm store live on ec2 and it seems to work fine
<rogpeppe> dimitern: that's good
<rogpeppe> dimitern: serviceSetCharm could call Client.AddCharm too, i think
<rogpeppe> dimitern: then we really would be no juju.Conn dependencies in apiserver
<rogpeppe> dimitern: which would be cause for minor celebration :-)
<dimitern> rogpeppe, yes, indeed
<hazmat> hmm.. deploy silently ignores invalid service names
<hazmat> through the api that is
<dimitern> rogpeppe, did you manage to look at upgrade-charm as well?
<dimitern> hazmat, file a bug please
<rogpeppe> dimitern: no, totally distracted by other conversation and development.
<rogpeppe> dimitern: looking now
<dimitern> rogpeppe, thanks
<dimitern> rogpeppe, i'm almost done with the suggestions about deploy - reproposing shortly, + conn removal from apiserver
<rogpeppe> dimitern: great! thanks.
<rogpeppe> anyone got an idea why this might die with a "SyntaxError: Unexpected identifier" error?
<rogpeppe> mongo --ssl -u admin -p mypassword localhost:37017/admin --eval "use juju"
<hazmat> rogpeppe, use symbol valid for shell not for eval
<hazmat> i'd guess
<rogpeppe> hazmat: yeah, i'm thinking that "use juju" isn't valid js
<rogpeppe> hazmat: i thought the two things were the same
<rogpeppe> hazmat: i hope there's a js equivalent of "use"
<hazmat> no.. its a mysqlism propogated
<hazmat> re db shells
<rogpeppe> hazmat: hmm, there must be some other way of accessing a different db then
<hazmat> rogpeppe, see top of mongo -h
<rogpeppe> hazmat: i can't do that unfortunately
<rogpeppe> hazmat: i have to log into a different db then switch
<rogpeppe> hazmat: i guess i can just pipe into mongo
<hazmat> its trivial in the client drivers, through the shell you point to the one you want.. or use shell syntax ('use')
<rogpeppe> hazmat: db=db.getSiblingDB("juju")
<rogpeppe> hazmat: useful to know that db is just a normal variable actually
<dimitern> rogpeppe, also updated https://codereview.appspot.com/44240045/ - just needs an LGTM :)
<rogpeppe> dimitern: don't they all? :-)
<rogpeppe> dimitern: looking
<hazmat> rogpeppe, is it okay to strip go binaries?
<rogpeppe> hazmat: no
<rogpeppe> hazmat: the symbols are used by the runtime
<rogpeppe> hazmat: you can create executable compressed binaries though
<rogpeppe> hazmat: though i can't remember the tool that was used
<hazmat> rogpeppe, oh? do tell.. you just mean gzip?
<rogpeppe> hazmat: no
<hazmat> i'll dig through our tools code
<rogpeppe> hazmat: i mean you can get a much smaller binary that uncompresses itself when run
<rogpeppe> hazmat: i'll have a quick search, one mo
<rogpeppe> hazmat: https://github.com/pwaller/goupx
<rogpeppe> hazmat: i can't verify that it still works though
<rogpeppe> hazmat: it seemed to work when i last played with it
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, cheers
 * rogpeppe just got a working status from a restored environment, woo
<rogpeppe> if anyone cares to take a look, juju-restore now seems to work: https://codereview.appspot.com/44350043/
<rogpeppe> natefinch: ^
<natefinch> rogpeppe, cool
<natefinch> rogpeppe, I just got confirmation from a mongo engineer that the problem I was having with replica sets in mongo 2.2.0 is likely just a bug in 2.2.0.  I think we may have to just tell people they need to upgrade to get HA
<rogpeppe> natefinch: ok, that's good to know
<thumper> o/
<thumper> as hazmat mentioned on the mailing list, I thought we already did use a later version
<natefinch> thumper, I thought older environments had 2.2.0 that didn't get upgraded when we upgraded juju... but I might be wrong about that.
<thumper> natefinch: hmm.. not sure about that
<natefinch> thumper, it may be my misunderstanding
<thumper> I just don't know
<thumper> dimitern: well done on getting deploy done \o/
<dimitern> thumper, and upgrade-charm
<thumper> dimitern: that's great. what's left?
<dimitern> thumper, both are about to land as soon as the bot finishes with them
<dimitern> thumper, let me check
<dimitern> thumper, only one - apiendpoints
<thumper> dimitern: is status done?
<dimitern> thumper, but it's trivial and might benefit from some caching
<dimitern> thumper, yes, i think it got landed
<thumper> oh yay
<dimitern> thumper, i'm updating the blueprint now
<dimitern> thumper, actually, looking at status it seems it still uses state
<dimitern> thumper, https://code.launchpad.net/~gz/juju-core/status_api/+merge/198444 this is the branch and it haven't landed yet, but seems done
<thumper> I think it will be great to get this all landed for 1.18
<dimitern> indubitably
<dimitern> seems mgz have changed something recently (2h ago), so perhaps he's looking into landing it
<rogpeppe> thumper: hiya
<thumper> hi rogpeppe
<rogpeppe> thumper: looking for a review of https://codereview.appspot.com/44350043/ if you have a moment or two
<thumper> sure
 * thumper has a visitor
 * rogpeppe has a beer
<hatch> it's Chrismas time....that means rum and eggnog!
<dimitern> rogpeppe, you've got LGTM on https://codereview.appspot.com/37850043/
<rogpeppe> dimitern: tyvm
<dimitern> ok, time to stop
<dimitern> g'night all
<rogpeppe> dimitern: night night
 * rogpeppe has also reached eod
<rogpeppe> g'night all
<natefinch> rogpeppe, good night
<natefinch> thumper: who do I talk to about upgrading mongo on the bot?  I can't commit my HA stuff until it's upgraded
<thumper> natefinch: sinzui
<sinzui> yes?
<thumper> sinzui: natefinch wants to upgrade mongo on the bot
<thumper> or do you just do CI and not landing?
 * thumper frowns
<sinzui> I don't land, sorry.
<sinzui> thumper, natefinch. I wonder if I can ssh to the machine if I know the IP address.
<thumper> natefinch: perhaps wallyworld_ can help, I've not logged into the bot
<natefinch> thumper, sinzui: jam told me the IP in a hangout like yesterday... but I forgot to write it down ,and now it has flittered into the ether
<sinzui> I can push/tag gobot branches
<natefinch> thumper, well, it's EOD for me anyway. I'll email jam about it and he'll fix me up.
<thumper> kk
<thumper> natefinch: see you around
<natefinch> thumper, see you
<sinzui> wallyworld_, thumper.  I don't understand how to use/document to juju backup plugin.
<thumper> sinzui: neither do I
<wallyworld_> sinzui: i can do that. it was more or less a prototype but can be documented
<wallyworld_> there's also the restore utility which i know little about
<wallyworld_> it may still be wip, not sure
<sinzui> wallyworld_, we can not document it in the 1.17.0 release if you think a 1.17.1 or 1.18.0 is a better time
<wallyworld_> i think that would be better given i suspect the restore utility may not be done fully (but am not sure, i could be wrong)
<sinzui> fab. I will just remove it from the notable section. thank you wallyworld_
<wallyworld_> no-one would care too much i suspect
<bradm> anyone know whats going on with LP#1241674?  we're upgrading to havana with multiple neutron networks, and are pretty interested in the bug
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1241674>
<wallyworld_> bradm: the best person to fix this quickly on the core team is martin. i'm not sure if he has been looking at it, but can catch up with him when he comes online for his SOD
<bradm> wallyworld_: its going to become pretty critical for us next year
<wallyworld_> bradm: how would someone determine which network to use? via an environ config?
<wallyworld_> juju environ that is
<bradm> wallyworld_: aiui each environment has its own network
<wallyworld_> so if we introduced a new config attribute called "network-name" or something?
<bradm> maybe, I'd want to look into it a bit more
<wallyworld_> i can start work on it
<wallyworld_> i'd just need a little more guidance on what we want to do
<bradm> I'm just trying to get my head around what would be required here, the neutron network stuff is new to me
<wallyworld_> me too
<wallyworld_> martin knows about it though :-)
<bradm> I'm fairly sure its deterministic per tenant what network they have
<wallyworld_> i'll see if i can catch up with him
<wallyworld_> so if it's deterministic, we can either specify one, or maybe just choose the first one or something if none is specified?
<bradm> aiui there's a mapping from tenants to networks
<bradm> oh, you can tell nova what net-id to use when you boot
<wallyworld_> so maybe a net-id juju config attribute
<bradm> yeah, if you can't get it progmatically
<wallyworld_> well, even if you could, i think maybe it would be needed to allow the user to specify
<wallyworld_> if there's more than one
<bradm> yeah, since you can have different nics on different networks
<wallyworld_> ok. so we will have this fixed definitely by next year if not sooner. but most people are away next week so getting any changes reviewed and committed may be difficult
<wallyworld_> i'll talk to martin and we'll work something out
<bradm> that's fine, I'm nearly on holidays anyway
<wallyworld_> me too :-D
<bradm> we're just building the next version of prodstack, it'd be nice to know there's a plan for the bug
<wallyworld_> definitely a plan
<wallyworld_> the bug is down for the 1.17 milestone
<wallyworld_> which sorta means we can't do the next release until fixed
<bradm> we kind of need to do multiple networks so we can segregate off things into seperate pools, so we have some control over badwidth
<bradm> bandwidth, even.
<wallyworld_> yep. there's a whole unit of work planned for that sort of stuff
<wallyworld_> will be started in january
<bradm> we're going to end up with 2 different physical router clusters, doing active/passive failover for neutron and firewalls
<bradm> with channel bonding on each to allow the different sections to have the required bandwdith they need
<wallyworld_> sounds good
<bradm> it should be, it'll let us bring more into juju / openstack, since some of our apps use a lot more bandwidth than others
<wallyworld_> and is what customers would be doing
<wallyworld_> so good to get it all dog fooded
<bradm> yup
<bradm> its good to see more redundancy happening in the stack, we'll have more control over hardware etc if we can fail things over
<wallyworld_> yeah
<bradm> wallyworld_: let us know if we can help, we should have a full havana stack with multiple networks early next year, mostly waiting on hardware atm
<wallyworld_> bradm: is there something there now? or only next year?
<bradm> wallyworld_: we have most of the stack now, we're missing ceph, and decent amount of swift storage
<bradm> wallyworld_: and we don't have the 2nd physical router & neutron setup either
<wallyworld_> ok. i'mjust thinking we need something with multiple networks just to test with while we develop the solution for the bug
<wallyworld_> so we don't need a full setup with all the bell and whistles, just something that will fail without the new code and work once we add the necessary fixes
<bradm> didn't james page say there was a cloud like that already?
<bradm> https://bugs.launchpad.net/juju-core/+bug/1241674/comments/5
<_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1241674>
<wallyworld_> ah yes he did
<wallyworld_> i wasn't really familiar with the bug
<wallyworld_> jamespage: is the havana based cloud referenced in the above bug just lyc02 on canonistack?
<bradm> I don't think canonistack has multiple networks
<bradm> or is even using neutron
<wallyworld_> ah ok. i seemed to recall lyc02 was havana but didn't know to what extent it also used neutron etc
<bradm> yeah, its havana, but I don't think its using neutron with openswitch, I'd say that'll be the next upgrade for canonistack
<wallyworld_> ok. i'll get the details mentioned in the bug so us core guys can work on the bug
<bradm> awesome
#juju-dev 2013-12-20
<wallyworld_> thumper: hey. can you look at a simple mp? https://codereview.appspot.com/44420044
<sinzui> ha ha. I am preparing a release and Azure is having network issues.
<wallyworld_> sinzui: is this 1.17?
<sinzui> wallyworld_, I mean azure, not juju.
<wallyworld_> no i mean is the release you are preparing a juju 1.17 release?
<sinzui> CI failed 2166 for azure with networking errors. When I logged into azure, they said they were having networking issues
<wallyworld_> :-(
<sinzui> I am going to replay the tests, but given that azure is wobbling, I may need to wait
<sinzui> wallyworld_, I am going to release 1.17.0 CI loves juju at the moment so I have let every keep landing (I can have a lot of good revisions to choose from).
<wallyworld_> great :-)
<wallyworld_> sinzui: btw, there is a mp for a restore plugin in progress. so backup/restore will definitely be ready for 1.17.1 i think
<sinzui> rock
<wallyworld_> sinzui: i forget who's court the proverbial ball is in - streams.canonical.com still has our test data we did at the sprint. were there plans to get that sorted out for the 1.17 release also?
<sinzui> wallyworld_, yes, Ben is on holiday and didn't want to touch it while other staff were also missing
<wallyworld_> ok, np :-)
<sinzui> wallyworld_, We have the build/release process tested and will set everything on the first week of Jan
<wallyworld_> \o/
<sinzui> wallyworld_, oh, actually...
<sinzui> The lost os images on azure happened when Azure added Japan  regions
<sinzui> I need to add them to the mirror's file
<wallyworld_> ah
<thumper> hi wallyworld_
<wallyworld_> hey
<thumper> wallyworld_: reviewed
<thumper> wallyworld_: just a small thing
<wallyworld_> great thanks
<wallyworld_> thumper: so i hacked up some code for charm version in status - it shows version info for both service and units since i figure units can before out of date separate to service if node is down and service is updated
<thumper> yeah...
<wallyworld_> but i need martin's stuff to land before i can go any further
<thumper> I was thinking about that
<wallyworld_> so i'll park it for now
<thumper> well, mgz is off now
<wallyworld_> :-(
<wallyworld_> too bad status didn't get done
<wallyworld_> thumper: i could propose against trunk as is maybe
<wallyworld_> i would need to clean up my code - i just hacked it together
<thumper> at least we'll get it done for 1.18
<thumper> I'd like to talk through the status before you ran with it
<wallyworld_> sure, next year then :-)
<wallyworld_> or we can talk now
<thumper> we can chat now
<wallyworld_> thumper: i don't understand "otherwise if you get a comment that starts with a space, you return it."
<thumper> do you still have that pastbin?
<wallyworld_> yeah
<thumper> let's hangout
<wallyworld_> https://pastebin.canonical.com/102221/
<thumper> I still have it open too
<wallyworld_> https://plus.google.com/hangouts/_/7ecpi24kekk8g5rnnpd44j64e0
<bradm> https://pastebin.canonical.com/102275/ <- interesting response to a juju destroy-environment
<thumper> bradm: :-(
<bradm> looks like swift is a bit confused with whats in that bucket
<bradm> swift download tells me there's files not found
<bradm> fwiw juju seems to have done the right thing, and blown away my environment, just the swift bucket still exists with some dodgy content
<bradm> interested in any debugging from this?  otherwise I'll just blat the swift bucket
<wallyworld_> bradm: 409 normally means there's content inthe container that's being asked to be deleted. not sure how that happened unless a call to delete a file in the container failed. i wonder if anything was logged?
<wallyworld_> thumper: changes pushed
<thumper> already approved
<bradm> wallyworld_: I can't see anything, and if I rebootstrap, then destroy-environment, it looks clean
<wallyworld_> blame it on santa's elves or something
<bradm> seems as good a reason as any!
<wallyworld_> if it happens more regularly we can look at it
<bradm> definately, I'd hate to file a bug for an unreproducible issue, just wastes everyones time
<wallyworld_> axw: i've landed a change to more robustly ignore empty lines in the auth keys string in juju env config
<axw> wallyworld_: thanks!
<wallyworld_> i meant to do it right the first time but clealr didn't
<axw> no worries
<axw> I mean to do lots of things right the first time but clearly don't ;)
<wallyworld_> don't we all :-)
<axw> thumper: do you have any juju-run things you'd like me to do while you're off? otherwise I have manual-provider destroy-environment, and Windows SSH/bootstrap stuff to work on
<wallyworld_> thumper: also, don't forget to email us the hotel details
<thumper> wallyworld_: ok
<thumper> axw: work on the windows bootstrapping and ssh stuff
<thumper> axw: I'm parking the rest of the juju run client until after the break
<axw> thumper: okey dokey
<thumper> axw: how do I get the long hash for the tip of go.crypto?
<thumper> hg tip just shows the short hash
<axw> thumper: not sure sorry, I've just used "godeps -t" in the past
 * axw looks at the source
<thumper> -t?
<axw> thumper: -t generates the contents of dependencies.tsv
<axw> godeps -t <some package that imports go.crypto/ssh>
<thumper> I don't have godeps installed
<axw> thumper: hg log -l 1 -r . --template "{node} {rev}\n"
<axw> that's what godeps does
<thumper> cheers
<thumper> axw: where is godeps? and is its use documented?
<axw> thumper: go get launchpad.net/godeps
<axw> thumper: there's a bit about it in our README I think
<thumper> ta
<axw> thumper: juju-core/CONTRIBUTING
<axw> right at the bottom
<jamespage> wallyworld_, its not canonistack - jam + mgz have access to it
<rogpeppe> thumper: the -t flag asks for testing dependencies to be included (probably not necessary in your case)
<rogpeppe> thumper: (but was undocumented - i've just fixed that)
<dimitern> thumper, you around?
<dimitern> thumper, I'm thinking of taking over martin's branch about status via the api and landing it
<axw> wallyworld_: am I a bit thick, or is the authorized_keys updater modifying /root/.ssh, rather than ~ubuntu/.ssh?
<axw> wallyworld_: I can't see where the ubuntu user is specified
<rogpeppe> axw: ping
<axw> rogpeppe: pong, sorta. holding my baby, may take a while to respond
<rogpeppe> axw: np
<rogpeppe> axw: just a quick question on dying environments
<rogpeppe> axw: what operations is a dying environment supposed to forbit?
<rogpeppe> forbid, even
<axw> rogpeppe: machine and service creation
<rogpeppe> axw: what about container creation?
<rogpeppe> axw: i.e. nested machines
<axw> rogpeppe: hmm, I think I had intended it to, but now I'm not sure it's necessary
<rogpeppe> axw: i just noticed that there's no check for that, and it'll be awkward to do...
<axw> rogpeppe: since taking down the instances will take out the containers, I think it doesn't matter
<rogpeppe> axw: ok, that's good
<axw> rogpeppe: will it be difficult to retrofit if I think of a reason? ;)
<rogpeppe> axw: not *too* bad - it would just need to go in about three or four different places
<rogpeppe> axw: one other thing: i was wondering about caching the Environment object in the state, so we don't have to fetch it every time we add a machine. is there anything about it that can change?
<axw> ok
<axw> rogpeppe: only life at the moment
<axw> so yeah, that's probably a good idea
<rogpeppe> axw: if it was an object in the state, it would make the retrofitting easier, because we wouldn't need to go through the environment object fetching dance in each place
<axw> rogpeppe: that'll work for now, but maybe not when JAAS comes along
<axw> but of course we can deal with that when it comes
<rogpeppe> axw: i suspect that we'll want to maintain a one-to-one State<->Environment mapping
<rogpeppe> axw: and add a higher level object.
<rogpeppe> axw: or perhaps rename State to Environment
<rogpeppe> axw: otherwise every single method gets a new argument, and that seems wrong
<axw> rogpeppe: yeah, makes sense
<rogpeppe> ah, standup
<dimitern> rogpeppe, jam, others? last standup of the year! get it while it's hot https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
<axw> gotta go - have a nice Christmas all
<rogpeppe> axw: you too
<rogpeppe> axw: have fun!
<dimitern> axw, all the best!
<axw> thanks :)
<rogpeppe> natefinch: what would you think about moving the replicaset to juju-core/replicaset, or perhaps juju-core/utils/replicaset ?
<rogpeppe> natefinch: environs doesn't seem quite right as a place, as it's a building block and doesn't really have any logic related to juju environments
<rogpeppe> lunch
<natefinch> rogpeppe: juju-core/replicaset works.  environs was a suggestion by I forget who.  Ideally I'd just move it out to be a standalone package, but no time etc
<sinzui> rogpeppe, dimitern, Do either of you expect to land anything in the next 2 hours?
<dimitern> sinzui, yes, status using the API
<dimitern> sinzui, I'm proposing it now
<sinzui> sweet. I will wait.
<dimitern> thanks sinzui
<rogpeppe> sinzui: i'm also expecting a couple of branches to land, but the bot seems stalled currently - i've had them approved for the last hour
<dimitern> rogpeppe, I'll look into the bot
<sinzui> rogpeppe, thank you.
<dimitern> rogpeppe, in the mean time, can you take a look at the status CL: https://codereview.appspot.com/38420046
<rogpeppe> dimitern: looknig
<rogpeppe> dimitern: reviewed
<dimitern> rogpeppe, thanks
<dimitern> rogpeppe, mongod on the bot seems to have hung, so I killed it and removed the sockets, now it seems it works again
<rogpeppe> dimitern: ok, thanks
 * rogpeppe should work out how to do that some time
<sinzui> jcsackett, can you take some time to read my propose juju-core 1.17.0 release notes? https://docs.google.com/a/canonical.com/document/d/1-xisuLkhozMm40e4w5M_Nl1l4yzBBxhzrYhj5eGUoas/edit
<dimitern> rogpeppe, I usually check for a lot of /tmp/gocheck-* or /tmp/test-mgo-* dirs, which sometimes take up all the space, then I look at ~/.bash_history to see what the others are doing :) - mainly tail -f ~/tarmac/tarmac.log
<dimitern> rogpeppe, btw, now I can feel what you were saying about waiting forever for lbox to finish - it seems on a weak wireless link it really takes 5m to run, if not more
<rogpeppe> dimitern: i don't actually know how to log in to see what the bot is doing
<rogpeppe> dimitern: or look at its files
<dimitern> rogpeppe, just a sec
<dimitern> rogpeppe, you need to source a file like this (sent you a pm)
<dimitern> rogpeppe, then if you have the nova python client, you can do "nova list" and should see 2 machines, the bot is running on the second one
<dimitern> rogpeppe, and you'll need to setup your canonical sshbang stuff, so you can do ssh 10.55.x.x (whatever the ip is
<rogpeppe> dimitern: what do you mean by "sshbang"?
<natefinch> rogpeppe: https://wiki.canonical.com/InformationInfrastructure/IS/SSHebang
<dimitern> natefinch, rogpeppe, yeah - you need to se
<dimitern> setup chinstrap access, so you can ssh tunnel to canonistack machines
<natefinch> or you can just ssh into chinstrap and ssh from there to the machine
<jcsackett> sinzui: release notes look good.
<sinzui> thank you jcsackett
<dimitern> natefinch, once it's merged it's gone btw
<dimitern> natefinch, you can't re-merge it
<natefinch> dimitern, aww, there's no way to modify it and merge it in again, I have to make a new branch?
<dimitern> natefinch, yes, sorry :)
<natefinch> dimitern, bah
<natefinch> dimitern, at least it's a trivial change
<sinzui> natefinch, dimitern rogpeppe. I just disabled CI auto build so that I can start the builds. CI takes about 30 minutes. I want to start the CI in the next 60 minutes to verify tip is ready for release
<dimitern> sinzui, I'm done with my stuff, the CLI API has all landed
<sinzui> thank you very much dimitern
<rogpeppe> sinzui: you'd better go ahead without my juju-restore then, because that'll take at least 15 minutes to merge
<sinzui> rogpeppe, I can wait a bit. I am ever so hopeful that this release will take less than 4 hours, most of the time being spent waiting for the packages to reach the archives
<natefinch> sinzui: the stuff I've landed isn't actually used yet, so no worries from my end
<sinzui> thank you natefinch
<rogpeppe> sinzui: well, it's approved, and hopefully will land soon
<sinzui> excellent
<dimitern> rogpeppe, ah, Client().Status(nil) is what you need for that build failure
<rogpeppe> dimitern: oh damn, another merge problem
<rogpeppe> approved again
<rogpeppe> right, that's cool. i now have a "watchgobot" script that i can run to tail the tarmac log file
<dimitern> rogpeppe, nice!
<rogpeppe> dimitern: http://paste.ubuntu.com/6606340/
<natefinch> dimitern, rogpeppe: can you check this out https://codereview.appspot.com/34660045 ...you can't tell from the diff, but I did a bzr mv environs/replicaset ./replicaset  (you can tell if you browse the code on the branch: http://bazaar.launchpad.net/~natefinch/juju-core/027-mongoha2/files
<rogpeppe> dimitern: the "gobot" script just runs a command with the env vars you gave to me set
<rogpeppe> natefinch: looking
<rogpeppe> natefinch: LGTM
<rogpeppe> natefinch: thanks
<dimitern> rogpeppe, heh, nice script, too bad it won't work out of the box on bash :)
<rogpeppe> dimitern: oh, sorry
<rogpeppe> dimitern: rc is my default shell scripting language
<dimitern> rogpeppe, np, it's trivial to change it so
<rogpeppe> dimitern: you'll need to change the sed command so it takes the argument that allows extended regexps
<dimitern> rogpeppe, i tend to stay away from bash and any shell scripting language that's not at least python :)
<natefinch> dimitern: ditto.  bash is one step below perl in my book.... and I hate perl
<rogpeppe> dimitern: for trivial stuff that's just calling commands, rc works pretty well
<rogpeppe> dimitern: and is a bunch better than sh
<dimitern> natefinch, oh, perl is somewhere far down on my list, a bit higher than java
<natefinch> seriously, what the hell is this doing?  if(! ~ $#* 0) {
<rogpeppe> natefinch: ! is not
<rogpeppe> natefinch: ~ is the pattern matching operator
<rogpeppe> natefinch: $#var gives the number of elements in a variable (all variables hold lists)
<rogpeppe> natefinch: $* are the arguments
<dimitern> yeah, weird i tell you..
<rogpeppe> if len(os.Args) > 1 {
<dimitern> yep
<dimitern> and looks sooo much better :)
<rogpeppe> dimitern: yeah, that's not a fantastic idiom, although the primitives are simple
<rogpeppe> rc is actually *really* simple
<dimitern> rogpeppe, I got my share of bash (and the like) highly arcane stuff some years back, I was never the same person since :)
<rogpeppe> dimitern: the main problem with bash is the hideous quoting rules
<rogpeppe> dimitern: it's almost impossible to deal well with stuff that has spaces in
<dimitern> rogpeppe, and let's not even get into arrays and fancy substitutions
<rogpeppe> dimitern: ha
<rogpeppe> dimitern: i still use vanilla bourne shell when writing bash
<rogpeppe> dimitern: apart from $( )
<dimitern> that's useful, as is ``
<rogpeppe> dimitern: thing is with bash, it seems that almost noone knows about the crucial role of "$@"
<rogpeppe> sinzui: $() is better than ` `; that's why i use it
<rogpeppe> s/sinzui/dimitern/
<sinzui> rogpeppe, I also agree. I cannot tell backticks from specs of dust om my screen
<rogpeppe> sinzui: merged
<dimitern> rogpeppe, I can show you some CMD batch files I had to write like 10 ago, which make bash look a really sensible language
<rogpeppe> the main reason it's better is that it nests correctly
 * sinzui once scrubbed his screen for 10 minutes, then released the script had a backtick in it
<rogpeppe> dimitern: ha, .bat is utterly braindead
<dimitern> but backticks are so much easier to write, and with proper vi syntax highlighting it's a breeze
<dimitern> rogpeppe, .bat was the precursor to .cmd and the "extensions" winNT introduced
<rogpeppe> dimitern: ah, i don't know about that
<rogpeppe> dimitern: the basic syntax of sh is actually quite nice
<natefinch> I only use bash scripts for putting together commands that I would actually type out on the commandline otherwise. If I need branching or looping, I use a real language. Same for batch scripts on windows
<rogpeppe> dimitern: i'm still happy with the shell i wrote. i will probably port it to unix at some point.
<rogpeppe> sinzui: you can go ahead with the release now if you like, BTW
<dimitern> anyway
<dimitern> i think i'll sign off for this year
<sinzui> rogpeppe, I expect CI to see the new revs in a minute http://162.213.35.54:8080/
<rogpeppe> dimitern: ok
<dimitern> with the warm fuzzy feeling we did all we could :)
<rogpeppe> dimitern: have a great christmas
<sinzui> if not, I will force a build
<rogpeppe> dimitern: and holidays afterwards
<dimitern> thanks!
<rogpeppe> dimitern: thanks for all your work
<dimitern> have great holidays all of you guys!
<dimitern> rogpeppe, cheers, thanks for all the reviews and help ;)
<dimitern> (but remember, I'm coming BACK :)
<rogpeppe> dimitern: np. hope i wasn't too harsh :-)
<dimitern> rogpeppe, it's fine, not to worry :) i appreciate it
<rogpeppe> natefinch: FYI here's something nice someone wrote about my shell: http://debu.gs/entries/inferno-part-1-shell
<natefinch> rogpeppe: pretty cool
<rogpeppe> natefinch: it had one or two warts, but it was actually amazingly powerful for its size
<natefinch> rogpeppe: very cool. When did you write it?
<sinzui> rogpeppe, natefinch 2173 is hated by CI http://162.213.35.54:8080/job/prepare-new-version/540/console
<sinzui> was juju-update-bootstrap moved?
 * sinzui can update packaging rules if so
<rogpeppe> natefinch: the initial version was probably written around '97, but it was developed over a few years
<rogpeppe> sinzui: yeah, juju-update-bootstrap was moved to juju-restore
<rogpeppe> sinzui: sorry, i didn't realise it needed an explicit rule
<rogpeppe> natefinch: the core shell is still only ~2700 lines though
<natefinch> rogpeppe: that's not bad at all
<sinzui> rogpeppe, packaging rules from ubuntu make it explicit. We just inherit it. This is good because we can tell jamespage to review our packaging changes when we release 1.18.0
<rogpeppe> natefinch: it would probably be smaller in Go, although there are some things Go can't do that are kinda fundamental to it
<rogpeppe> natefinch: and in Go you'd have to deal with all the hideous unix process group management
<natefinch> yeah, but if it was written in go, you could call it gosh :)
<natefinch> inferno doesn't even have sh in it... I don't know how it can be considered a valid shell ;)
<rogpeppe> natefinch: :-)
<sinzui> rogpeppe, natefinch: Do either of you have time to review the 1.17.1 inc branch? I want to land it the moment I release 1.17.0. https://codereview.appspot.com/44600044
<natefinch> sinzui, sure
<rogpeppe> sinzui: i'll look too
<natefinch> sinzui, what's with the change in client.go?
<sinzui> natefinch, lbox reported this when I proposed my number changes http://pastebin.ubuntu.com/6606702/
<sinzui> natefinch, I am on trusty which provides golang 1.2, which I think is the reason for the message
<rogpeppe> sinzui: i'd prefer to just delete one of those lines. i said that in the code review, but didn't check that it had been done.
<rogpeppe> sinzui: but tbh i don't mind
<rogpeppe> sinzui: we'll fix it in trunk
<rogpeppe> natefinch, sinzui: trivial review of fix for the above? https://codereview.appspot.com/44620044
<sinzui> rogpeppe, LGTM
<rogpeppe> sinzui: thanks
<sinzui> We are release r2173 as 1.17.0. CI loves it
<sinzui> rogpeppe, do you mind landing your import errors fix before me. I can reconcile conflicts then land mine
<rogpeppe> sinzui: ha, i thought i'd approved it some time ago, but i'd only set the commit message
<sinzui> that is also my secret technique for not accomplishing anything
<nate_finch> rogpeppe: anything you want me to look into in the next couple days? I'll be working on EnsureMongoServer, but if that goes faster than expected, I might have some time.
 * rogpeppe thinks
<rogpeppe> nate_finch: API server address caching, perhaps?
<rogpeppe> nate_finch: essentially you just need to call configstore.EnvironInfo.SetAPIEndpoint at the right time
<nate_finch> rogpeppe hmm, ok
<rogpeppe> nate_finch: you might also want to think about how we might do agent failover.
<rogpeppe> natefinch: it's a little tricky and i'm not sure of the best approach there
<natefinch> rogpeppe: yeah, I can see it being pretty tricky
<rogpeppe> natefinch: i just did a little bit of mongo stats digging - if we deploy a service with one unit, the API server does 170 consecutive round trips to mongo
<natefinch> rogpeppe: dang!  That's um... a lot
<rogpeppe> natefinch: at least they're all round trips to localhost (in the non-HA case anyway)
<natefinch> rogpeppe: right... not the end of the world, still, seems like a lot
<rogpeppe> natefinch: indeed
<rogpeppe> natefinch: takes about 30ms all told
<rogpeppe> natefinch: (but that is on an otherwise empty database)
<rogpeppe> natefinch: sorry, 40ms
<natefinch> rogpeppe: any idea how it scales?
<rogpeppe> natefinch: linearly i imagine
<rogpeppe> natefinch: pretty much
<rogpeppe> natefinch: our database is pretty tiny, even with a large env
<natefinch> rogpeppe: yeah, I was assuming that.  We just don't have that much information to keep in there.  Honestly, barely even need a DB.
<rogpeppe> natefinch: indeed. there would be no problem with holding the whole thing in memory if we wanted to
<rogpeppe> natefinch: i occasionally think about redoing the whole of state with a much simpler in-memory representation and a raft protocol to keep state servers in sync
<rogpeppe> natefinch: in time, that's definitely something we should consider - it would speed things up by a couple orders of magnitude i think
<rogpeppe> natefinch: because the db operations could be juju-specific
<sinzui> we may have a problem with 1.17.0
<sinzui> rogpeppe, natefinch My own upgrades to 1.17.0 results in config errors in to services. I cannot destroy the environments. CI didn't see this/
<rogpeppe> sinzui: darn
<rogpeppe> sinzui: what errors?
<rogpeppe> sinzui: i've really got to go though
<sinzui> rogpeppe, I wont keep you then. I have not released the packages yet. The tools are there and I have 1.17.0 installed using them
<natefinch> rogpeppe: I can work with him on it.  No sense staying late on the friday before vacation week
<natefinch> (any later than it already is over there)
<rogpeppe> natefinch: ok
<sinzui> natefinch, rogpeppe : http://pastebin.ubuntu.com/6607413/
<rogpeppe> sinzui: those aren't errors AFAICS
<rogpeppe> sinzui: it's just warning you about deprecated fields in your configuration
<sinzui> the agent did upgrade, but each service shows config-changed hook failed
<sinzui> This is on aws, hp, azure, and canonistack
<rogpeppe> sinzui: that's probably unrelated to what you pasted
<rogpeppe> sinzui: the paste is about environment config
<rogpeppe> sinzui: a hook is about service config
<sinzui> rogpeppe, that is all that all-machines-log reports for each
<rogpeppe> sinzui: could you paste the entire all-machines.log ?
<rogpeppe> sinzui: or actually
<rogpeppe> sinzui: just the log for a single machine with a failed hook would be better
<rogpeppe> sinzui: the uniter log in particular
<sinzui> this is the all. I will get the unit http://pastebin.ubuntu.com/6607428/
<sinzui> natefinch, rogpeppe, this is the machine-log http://pastebin.ubuntu.com/6607431/
<rogpeppe> sinzui: the machine log won't tell us anything about failed hooks
<natefinch> rogpeppe: required environment variable not set for credentials attribute: User
<rogpeppe> natefinch: where's that from?
<natefinch> rogpeppe: the machine log
<natefinch> http://pastebin.ubuntu.com/6607431/
<rogpeppe> natefinch: oh yes, i see it
<natefinch> seems like there's an environment variable for the openstack user that isn't set
<rogpeppe> natefinch: i wonder how it worked before
<rogpeppe> natefinch: the agents should not rely on env vars
<sinzui> sorry rogpeppe, natefinch I typed too fast and went to the wrong machine. This is better http://pastebin.ubuntu.com/6607451/
<natefinch> rogpeppe: maybe a red herring, then
<sinzui> natefinch, this was an upgrade from 1.16.5 to 1.17.0. I am tempted to take the azure stack down and do a simple deploy with 1.17.0
<rogpeppe> hmm, the error seems to be that config-get couldn't find the charm: "cs:precise/mysql-31"
<natefinch> rogpeppe: yeah, was looking at that
<sinzui> 1.16.5 can destroy the envs. A small plus.
<rogpeppe> oh frick, i know the problem
<rogpeppe> sinzui, natefinch: it's related to dimiter's work on charm uploads
<rogpeppe> i *think* the problem is on this line:
<rogpeppe> 	err := st.charms.Find(D{{"_id", curl}, {"pendingupload", false}}).One(cdoc)
<rogpeppe> in State.Charm
<sinzui> I am going to test a simple 1.17.0 deploy of the samething to aws. If it goes well, I will update the release notes to state upgrade from stable to 1.17.0 are note supported
<natefinch> rogpeppe: why is that wrong?
<rogpeppe> natefinch: sorry, had a call
<rogpeppe> because i think that won't match charm docs with no pendingupload field (the old environment won't have that field)
<rogpeppe> natefinch: because false!=nil
<natefinch> ahh
<rogpeppe> natefinch: i think it should be an easy fix
<natefinch> rogpeppe, yeah
<rogpeppe> natefinch: could you take it forward please - i'm done
<rogpeppe> natefinch: it'd first be worth verifying if that is actually the problem
<rogpeppe> g'night all.
<rogpeppe> sinzui: hope you manage the release...
<sinzui> rogpeppe, It still looks good
<sinzui> natefinch, simple deploys look very good with the new data. Since we don't officially support stable to dev upgrades, I am going to add a disclaimer to not upgrade, it is no supported
<rogpeppe> sinzui: sgtm
<natefinch> sinzui: sounds good.  We should still fix it, though, and like Roger said, it's not hard
<sinzui> natefinch, +1 for a fix. It can go out in 1.17.1
<natefinch> sinzui:  I can get it done for Monday morning if that works?  I'm short on time today.
<sinzui> natefinch, I think I can manage that.
<sinzui> Most of my time is still spent waiting for builders and azure to do something
<rogpeppe> sinzui: BTW this problem will occur upgrading from 1.17.0 to 1.17.1 too; i don't know if that's a problem
<sinzui> rogpeppe, noted
<natefinch> sinzui, rogpeppe: I gotta run, but I'll submit a fix, it's very easy
<sinzui> natefinch, thank you.
<natefinch> er, I'll submit a fix this weekend / early monday morning
#juju-dev 2014-12-15
<waigani_> thanks for the review thumper
<menn0> wallyworld, thumper: joyent fix: http://reviews.vapour.ws/r/633/
<menn0> wallyworld, thumper: I spent a long time trying to make a unit test for this work
<menn0> wallyworld, thumper: but it looks like there's something missing from the fake Joyent API implementation
<wallyworld> menn0: lgtm
<anastasiamac_> menn0: u r a Joyent champion now :D
<menn0> wallyworld: cheers. Just fixing commit message text as it doesn't quite make sense and will then merge.
<menn0> anastasiamac_: oh no you don't... :)
<wallyworld> hey yeah, that gets me off the hook :-D
<anastasiamac_> menn0: kkkk... if u get CI unblocked - then u r  a champion?...
<anastasiamac_> wallyworld: there mayb a room for joyent fan club...
<menn0> anastasiamac_: maybe, but I don't think this is the entire fix because Joyent is consistently failing for master
<menn0> anastasiamac_: I think there might be another problem to fix yet
<menn0> anastasiamac_: looking at that now
<anastasiamac_> menn0: there must b - it would not b xmas without more problems to fix :p
<anastasiamac_> menn0: thnx!
<mattyw> menn0, ping?
<menn0> mattyw: pong!
<thumper> sorry, was drinking coffee and arguing with kids on holiday
<thumper> anastasiamac_: I feel like you type like teenagers text now :-)
<anastasiamac_> thumper: why?
<thumper> 'u' 'r'
<thumper> menn0: I see that wallyworld has reviewed already and I don't need to do anything
<menn0> thumper: correct :)
<thumper> \o/
<anastasiamac_> thumper: i think and type young
<thumper> bwahaha
 * anastasiamac_ considers whether it's worthwhile to be offended
<thumper> no, don't be offende
<thumper> d
<menn0> wallyworld, thumper: the merge job seems to have gotten stuck.
<menn0> wallyworld, thumper: it's been like this for a long time: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1595/console
<thumper> menn0: I'd give it 20 minutes
<wallyworld> i've seen it take a while
<thumper> menn0: how long?
<menn0> thumper: at least half an hour at this point in the tests
<thumper> hmm...
<thumper> well...
<menn0> i'm running the apiserver tests for this branch locally now
<thumper> the test timeout is 20 minutes
<thumper> and there are multiple slow packages there
<thumper> and it buffers the output
<thumper> so it is hard to say
<menn0> thumper: ok, so i'll wait
<thumper> but normally it is done in under 20 minutes for everything...
<thumper> so perhaps it is wedged
<thumper> wallyworld: do you know how to kick it right?
<wallyworld> yes
<wallyworld> i can restart it
<menn0> wallyworld, thumper: the apiserver tests have gotten past that point on my machine already
<wallyworld> menn0: thumper: jon restarted
<wallyworld> job
<menn0> wallyworld: cheers
<anastasiamac_> do i need something special for juju/names?
<anastasiamac_> I am getting http://pastebin.ubuntu.com/9524130/
<thumper> anastasiamac_: shouldn't do, let me check
<thumper> anastasiamac_: pretty sure that access control is for everything under github.com/juju
<thumper> anastasiamac_: nope, you are there
<thumper> anastasiamac_: what is your remote set to?
<anastasiamac_> thumper: i ran git remote add upstream https://github.com/juju/names.git
<anastasiamac_> remote set-url origin git@github.com:anastasiamac/names.git
<thumper> anastasiamac_: have you forked it?
<thumper> on github?
<anastasiamac_> thumper: :D yes
<thumper> only asking because I have forgotten before
<anastasiamac_> thumper: i forked it first
<anastasiamac_> then ran cmds above
<thumper> anastasiamac_: FYI, I would do the following:
<anastasiamac_> i can do pretty much everything - run status, etc... but cannot pull ;(
<thumper> git remote --set-url upstream git@github.com/juju/names.git
<thumper> git remote --set-url --push upstream no-pushing
<thumper> the git wire protocol is much faster than https
<axw> anastasiamac_: dumb question, have you added your public SSH key to GitHub?
<axw> (are you using SSH for juju/juju?)
<anastasiamac_> axw: i must have to commit to juju/juju no?
<axw> there are other transports
<anastasiamac_> axw: dunno... how can i find out what m using for juju/juju
<anastasiamac_> axw: ?
<axw> anastasiamac_: "git remote -vv" in the local repo
<anastasiamac_> axw: fetch and pull for origin and upstream are prefixed with https
<axw> anastasiamac_: right, so you're not using SSH. if you want to use it, then you should add your public key in your user settings on GitHub
<axw> anastasiamac_: https://github.com/settings/ssh
<anastasiamac_> axw: i dont want ssh :)
<anastasiamac_> axw: but m seeing the diff btw how my juju/juju and juju/names are setup..
<anastasiamac_> axw: let me align them with party line
<axw> anastasiamac_: git remote set-url origin https://github.com/anastasiamac/names.git
<thumper> anastasiamac_: why don't you want ssh?
<thumper> ssh is awesome
<axw> if you really don't want SSH... I would use it though, you don't need to keep putting your password in
<anastasiamac_> axw: thnx. i've sorted and will consider ssh :D u r awesome!
<menn0> and we have a new CI blocker....
<menn0> https://bugs.launchpad.net/juju-core/+bug/1402495
<mup> Bug #1402495: Joyent deploys fail in CI <ci> <joyent-provider> <regression> <juju-core:New> <https://launchpad.net/bugs/1402495>
<menn0> with the Joyent routing issue fixed, this CI with Joyent issue remains
<mattyw> folks - is juju/utils a review board project now?
<anastasiamac_> mattyw: it looks like it :-)
<mattyw> anastasiamac_, :) I was sure I saw an old email that said it was, I saw it and went for it :)
<dimitern> morning TheMue
<dimitern> TheMue, 1:1?
<dimitern> fwereade, hey
<dimitern> fwereade, if you're around today, and hopefully feeling better, can I trouble you for a review on http://reviews.vapour.ws/r/611/ please?
<TheMue> morning
<TheMue> dimitern: oh, eh, yes, coming
<perrito666> morning
<fwereade> dimitern, not better, but looking anyway, because it looks completely awesome from the description and I feel bad for not having done it on fri
<dimitern> fwereade, cheers :)
<dimitern> morning perrito666, voidspace
<fwereade> dimitern, that's *awesome*, LGTM with trivials
<fwereade> dimitern, check with TheMue about YamlEquals though
<voidspace> dimitern: morning
<voidspace> perrito666: o/
<dimitern> fwereade, thank you very much!
<voidspace> fwereade: o/
<voidspace> fwereade: sorry you're still unwell
<voidspace> my wife brought a cold into the house - she's had it for more than two weeks
<voidspace> and it's been rumbling on and off with me for a week
<voidspace> not bad, just annoying
<rogpeppe1> fwereade: hiya
<rogpeppe1> anyone know when it's ok to call "unit-get public-address" from a charm hook?
<rogpeppe1> is it supposed to be ok to call it in the install hook for example?
<rogpeppe1> dimitern: ^
<dimitern> rogpeppe1, it's set when the uniter starts (if it's available) so I'd say right away
<rogpeppe1> dimitern: ok, thanks
<dimitern> rogpeppe1, it might not be available if the machine doesn't have an address yet (i.e. still pending/provisioning)
<jam1> hey axw, wallyworld, maybe we should be chatting here instead :)
<wallyworld> maybe
<dimitern> jam1, o/
<jam1> hi dimitern, how's your day been going?
<rogpeppe1> dimitern: thanks
<rogpeppe1> dimitern: one other thing: if you call config-get in an install hook, should you get something sensible?
<dimitern> jam1, not bad, multitasking already :) with goamz migration, ci blockers and addressability stuff..
<dimitern> rogpeppe1, you know what - I was just looking at the code and I can't say I'm 100% sure the install hook will have public-address set
<jam1> rogpeppe1: given you can do "juju deploy âconfig=" why wouldn't you get config in install ?
<dimitern> rogpeppe1, better ask fwereade for sure
<rogpeppe1> jam1: i *think* i'm seeing a null result from config-get in an install hook; i need to check a bit more
<fwereade> rogpeppe1, config-get should always be fine; I *think* unit-get public address should always work but it's possible that state and/or networking changes have made it "" instead of <whatever the private address is>
<rogpeppe1> fwereade: ok, thanks. it's probably my code.
<fwereade> rogpeppe1, sorry I'm not very around today, I'm mostly in bed, will be on a bit later for meetings
<rogpeppe1> fwereade: aw, gbs
<axw> jam1: heya. chatting about what? is there a meeting?
<wallyworld> axw: jam1 was look at storage spec, but the 15.04 "official" one in the master spec list pointed to the old spec, not the newest, latest one
<axw> ok
<dimitern> fwereade, rogpeppe1, unit-get private-address|public-address always triggers unit.Private|PublicAddress() getting called; however looking at the filter/modes/etc. it seems until we know there's an address (i.e. the addresses watcher returned changes) config-change won't be triggered
<fwereade> dimitern, not *quite* true, we always get a config-changed after install, so, ha, yes, it's possible that nothing's set the machine's address by the time it's running a unit
<rogpeppe1> dimitern: the behaviour i *think* i'm seeing (i'm just about the test it) is that config-get is returning a null value even when there's a default value set
<rogpeppe1> dimitern: this is in the install hook
<rogpeppe1> s/the test/to test/
<fwereade> rogpeppe1, that seems odd, for sure, what do you get with --all?
<rogpeppe1> fwereade: not sure yet - i haven't got a hook context to play with
<fwereade> rogpeppe1, juju-run?
<rogpeppe1> fwereade: ok, trying that
<rogpeppe1> fwereade: should this work? juju run --unit identity/0 -- config-get --all
<dimitern> rogpeppe1, why config-get ?
<fwereade> rogpeppe1, can't remember if you use -- or quote the command
<dimitern> rogpeppe1,  it should be unit-get
<rogpeppe1> dimitern: i'm interested in config values here
<dimitern> rogpeppe1, private|public-address is not a config setting, it's a separate thing
<rogpeppe1> dimitern: yeah, i know. i was asking about public address initially, but i think the problem may lie elsewhere
<dimitern> rogpeppe1, ah, ok
<sinzui> dimitern, how goes bug 1397376?
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<dimitern> sinzui, fixing last suggestions from fwereade and setting to land
<sinzui> rock
<dimitern> sinzui, I'm already working on the backport for 1.21 as well
<sinzui> rock
<dimitern> with markdown everywhere how are you supposed to curse politely? s**t becomes s[bold]t[/bold] :) I guess s\*\*t is the way to go
<dimitern> sinzui, should I JFDI it?
<dimitern> Does not match ['fixes-1401130', 'fixes-1400358']; Build rejected, reporting on proposal - both of these are fix committed btw
<sinzui> dimitern, __JFDI__ for master
<dimitern> sinzui, ok
<ackk> hi, could someone please point me to where should I look to get the info shown in "state-server-member-status" from the delta stream?
<perrito666> marcoceppi: I think I just opened the doc for comments, could you try?
<marcoceppi> perrito666: :thumbsup: will circle back in a bit, got other things I need to clear out first
<perrito666> marcoceppi: np jut shout if it still not open when you try again, google docs hates me sometimes
<marcoceppi> perrito666: it's open, thanks!
<dimitern> rogpeppe1, did you just merge http://reviews.vapour.ws/r/636/ into utils?
<dimitern> rogpeppe1, sinzui, this causes the CI bot to fail with: Extant directories unknown:
<dimitern>  golang.org/x/crypto
<sinzui> dimitern, looks like something got imported that wasn't documented
<dimitern> sinzui, that's right - but it's coming from juju/utils
<sinzui> dimitern, I believe the simple fix is to add it to dependencies.tsv.
<sinzui> dimitern, I don't think this is like the cases were conflicting or ambiguous licensing prevent the package from being included. We just need to document it
<dimitern> sinzui, to unblock the bot, yeah
<sinzui> right
<dimitern> sinzui, but we need to make sure this doesn't happen again, agreed?
<dimitern> sinzui, that fits in just perfect with what I wanted to discuss with you guys - bringing juju-core dependencies under the ci bot (or at least the more actively developed ones)
<dimitern> sinzui, which will force the devs to actually care about the CI/release process more - like adding a dependencies.tsv for juju/utils, etc. and making sure it works before just merging changes
<sinzui> dimitern, the check_dependencies phase of building the release tarball ensures no deps that aren't in dependencies.tsv are included. The inclusion assumes we checked the license of the package and pinned it to a version we know is good
<dimitern> sinzui, even simpler fix will be to actually revert rogpeppe1's change to utils and ask him to do it properly :)
<sinzui> dimitern, yep
<dimitern> sinzui, that's totally fine and good we have this check
<rogpeppe1> dimitern: what was the problem with my change to utils?
<dimitern> sinzui, it actually helped to catch this
<dimitern> rogpeppe1, you added a dependency which wasn't mentioned anywhere and caused the build to potentially fail (it didn't due to a precaution on the bot)
<rogpeppe1> dimitern: why should that cause the build to fail?
<rogpeppe1> dimitern: aren't juju deps pinned?
<dimitern> rogpeppe1, because it's not in dependecies.tsv of juju-core
<rogpeppe1> dimitern: but juju-core won't be getting the latest version of utils
<dimitern> rogpeppe1, and the bot verifies all imports are properly listed as deps
<rogpeppe1> dimitern: because dependencies.tsv will mention an earlier version
<dimitern> rogpeppe1, that sounds right... hmm why did it happen then?
<rogpeppe1> dimitern: i don't see why making a change to utils tip could have broken juju-core, unless someone updated juju-core deps improperly
<dimitern> rogpeppe1, can you please work with sinzui to see how this could've happened and how to fix the bot?
<sinzui> dimitern, rogpeppe1 is Juju importing a non-master branch in this case?
<dimitern> I have a pending bugfix which can't land because of that
<rogpeppe1> dimitern: i'm in a standup right now
<rogpeppe1> sinzui: not AFAIK
<dimitern> rogpeppe1, np, later then?
<rogpeppe1> dimitern: possibly, although i'm quite busy
<sinzui> thank you rogpeppe1 , that eliminates the common reason for phantom deps
<rogpeppe1> sinzui: what do you mean by "importing a non-master branch" ?
<sinzui> dimitern, rogpeppe1 : Go checks out the master branch and gets its deps. Even when we ask for a non-master branch which has different deps, Go will leave the unwanted deps behind
<rogpeppe1> sinzui: ah, so that'll be the reason this has broken
<rogpeppe1> sinzui: because tip has dependencies that before-tip doesn't
<sinzui> okay.
<sinzui> rogpeppe1, dimitern 1 fix might be to change the build scripts to remove golang.org/x/crypto. I will consult with mgz_
<rogpeppe1> sinzui: yeah, ISTR some hack we had to get around this kind of problem
<rogpeppe1> sinzui: but i can't remember what the official way to do this was
<sinzui> rogpeppe1, mgz_ pushed a change to a master branch I think. This case is different though.
<rogpeppe1> sinzui: what we do is we don't use go get at all AFAIR
<mgz_> yeah, I can hackit out
<mgz_> we kind of have to use go get in some capacity
<mgz_> godeps doesn't implement branch/clone
<natefinch> why are unwanted dependencies a problem?
<natefinch> I can see missing dependencies, but unwanted should just be garbage on disk that we ignore
<mgz_> natefinch: we package this stuff, and also don't get great feedback from go about what actually goes into the binaries
<mgz_> so, maybe some new random github package we downloaded doesn't actually end up in the binary... but that does need asserting for licence/security raisins
<voidspace> it would be a pain to have to do an emergency security release because of a bug in a package that we're not actually using...
<rogpeppe1> natefinch: it's good to check that we don't have unwanted deps because it's easy to omit deps from dependencies.tsv
<natefinch> rogpeppe1: that's true... but the way to do that should be to check that godeps -f produces the same output as dependencies.tsv ... that could also be what we use to determine the files to package
<rogpeppe1> natefinch: unfortunately it won't
<rogpeppe1> natefinch: because i haven't come up with a nice way of including windows deps in godeps output yet
<rogpeppe1> natefinch: i will, but it's more work that i originally thought
<natefinch> rogpeppe1: oh right... dang
<natefinch> rogpeppe1: I wonder if the answer is just to switch to godep.... vendor the dependencies, then there's no question about keeping things in sync.
<rogpeppe1> natefinch: that may well be a reasonable thing to do
<sinzui> dimitern, could the network fix joyent need a separate change for precise. I see the same kind of log error in cloud-init for precise as last week and the week before
<dimitern> sinzui, the one menno did?
<sinzui> dimitern, yes
<sinzui> r=me mgz_ . Can you merge and deliver it to unblock dimitern
<dimitern> sinzui, unlikely, might be intermittent
<dimitern> sinzui, menno's fix is not precise-specific, but then again if what joyent call a "precise image" is very different from the CPC images..
<sinzui> dimitern, I am going to re-run tests again to capture logs and hope that trusty repeatedly passes
<dimitern> sinzui, +1
<mgz_> sinzui: sure thing
<mgz_> sinzui: done - I only pulled the rev in on the juju-core-slave atm as the update all script barfs on an unknown 10. address for me - doesn't seem we have all of them in the .ssh/config on master somwhow?
<sinzui> :/
<sinzui> mgz_, ssh and pull tip. I need to rethink the ssh/config rules for or private machines
<mgz_> hm, could I run in from the jenkins master isntead of locally?
<voidspace> natefinch: want another puzzle
<voidspace> natefinch: ?
<voidspace> natefinch: given a cidr I need to calculate the last allocatable IP address, knowing that the *last one* is reserved
<voidspace> natefinch: this is what I have: http://pastebin.ubuntu.com/9530758/
<voidspace> natefinch: (includes code to work out lowest allocatable one - the first four are reserved too)
<voidspace> natefinch: I'm sure there must be a better way...
<dimitern> mgz_, \o/ ta!
<tasdomas> a quick question about FormatSmart in juju/cmd - if I pass it a struct, is it supposed to delegate the marshalling to FormatYaml or return an error?
<dimitern> tasdomas, that's an excellent question - I was poking into it earlier today, let me check..
<tasdomas> dimitern, the comments on FormatSmart indicate that it should delegate a struct to FormatYaml
<tasdomas> dimitern, but it seems to me that the default: case in the switch makes that impossible
<dimitern> tasdomas, yes it appears so
<dimitern> tasdomas, you refer to the last 3 empty cases?
<dimitern> tasdomas, and the default as well
<tasdomas> dimitern, https://github.com/juju/cmd/blob/master/output.go#L75
<tasdomas> dimitern, yes
<dimitern> tasdomas, looking at the code invokes a WTF in me
<natefinch> voidspace: not sure I understand exactly what you're trying to do... can you give me an example?
<tasdomas> dimitern, I was trying to use the smart formatter in a side project and passing it a struct returns an error
<dimitern> tasdomas, well.. I wouldn't recommend using this for anything
<tasdomas> dimitern, heh, thanks for the recommendation
<dimitern> tasdomas, it's a (weak) attempt to make the output more pyjuju compatible
<dimitern> tasdomas, but it's neither well tested nor anyone cares too much it seems
<dimitern> tasdomas, I'd even say this deserves a bug report
<tasdomas> dimitern, I see
<voidspace> natefinch: when we get a subnet from ec2 the last ip address is reserved
<tasdomas> dimitern, I'll probably submit a pull request for it
<voidspace> natefinch: given the subnet in CIDR format I need to know what is the highest *allocatable* IP address
<dimitern> tasdomas, that'll be awesome, thanks!
<voidspace> natefinch: so, I take the "zeros" portion of the netmask, turn them to ones and OR it with the start IP address of the CIDR
<voidspace> natefinch: that gives me the last IP address, from which I subtract one to calculate the last *allocatable* IP address
<natefinch> voidspace: ok, so like if you get 123.123.123.0, then 123.123.123.255 is the "reserved" address, and .254 is the last allocatable one?
<natefinch> voidspace: sorry, my networking skills are *really* rusty
<voidspace> natefinch: correct
<voidspace> natefinch: a CIDR (subnet block) is an IP address plus netmask
<voidspace> natefinch: I believe my bit twiddling is correct, just not terribly elegant
<voidspace> natefinch: also going via a float (math.Pow) is pretty awful
<voidspace> natefinch: is there syntax for an integer power operation?
<natefinch> voidspace: math.pow IIRC
<voidspace> natefinch: that's float
<voidspace> natefinch: which I'm using currently
<natefinch> voidspace: just cast back and forth unless you think you'll run off the top of float64
<voidspace> natefinch:    highMask := uint32(math.Pow(2, float64(zeros))) - 1
<voidspace> yuck :-)
<natefinch> yep
<natefinch> somebody might have made a copy of the package for integers
<jw4> OCR PTAL : Fixes Go 1.4 vet error that blocks pre-push hook: (got approval, just looking for senior reviewer sign off) http://reviews.vapour.ws/r/630/
<natefinch> jw4: FYI we shouldn't be building with 1.4.... though if we're at still backwards compatible with 1.2, that's fine, I guess.
<jw4> natefinch: I see - I figured its fine to develop in 1.4 assuming that the CI tests are all running in 1.2.1 or whatever the supported version is
<natefinch> jw4: yeah, like I said, it's fine, but I think it does break some tests.
<jw4> natefinch: Interesting.  I'm pretty sure we found and fixed some tests that were broken by 1.3, which was a good thing.
<natefinch> jw4: it was something about our version of deep equals needing a different implementation in 1.4 or something...  not actually a test failing, but something in our test frameworks not working correctly.  IIRC Rogpeppe was the one who wrote the code
<jw4> natefinch: I see.  I'm guessing we're not moving to 1.4 (or later) until our next LTS version of Ubuntu?
<natefinch> jw4: or until it gets backported to Trusty.  I'm not 100% certainly on all the ins and outs of Ubuntu packaging... but yes, Ubuntu is the limiting factor in one way or another
<jw4> natefinch: cool
<voidspace> are we still blocked?
<jw4> voidspace: yep
<jw4> voidspace: http://goo.gl/4zd1e9 (shortened because the original is so long)
<voidspace> jw4: thanks
<voidspace> jw4: I've saved the bookmark this time :-)
<jw4> lol
<voidspace> right, g'night all
<voidspace> see you tomorrow
<wwitzel3> fwereade: ping
<thumper> sinzui: ci status?
<sinzui> thumper, We think we have a working rev.
<thumper> sinzui: seems that both critical bugs are fix committed
<thumper> \o/
<sinzui> thumper, we are retesting to show that we didn't get lucky
<thumper> kk
<katco> thumper: hey thank you for reviewing my branch
<thumper> katco: np, was a mix of RB and github reviews, as the github diff handles moves much better
<katco> thumper: oh... i didn't even check gh; do i need to look there, or you were just using that as a tool?
<thumper> katco: no, all comments are on rb
<katco> thumper: ah cool
<katco> thumper: thanks for aggregating them for me. i responded to all of your comments. please lmk if you disagree with anything (few questions in there too)
<thumper> kk
<menn0> sinzui: your comments on bug 1401130 indicate that the problem isn't fixed yet. is that right?
<mup> Bug #1401130: Joyent instances sometimes can't communicate via the internal network <ci> <joyent-provider> <regression> <juju-core:Fix Committed by hduran-8> <juju-core 1.21:In Progress by menno.smits> <https://launchpad.net/bugs/1401130>
<sinzui> menn0, don't panic
<sinzui> menn0, The bug has always been about 1.20 and beta4 pass, alpah1 does not. 1.20 was failing about the time of the ci tests.
<sinzui> menn0, perrito666 and i have been doing repetitive deploys with 1.20, beta4, and  alpha1. We have no failures for beta4, 1 failure for 1.20, and *no* failures for alpha1 so far. I and starting the last test to remove the regressions
<perrito666> sinzui: tx
<menn0> sinzui: ok
<menn0> sinzui, perrito666:  has the joyent routing fix been backported to 1.21?
<sinzui> menn0, no, 1.21 never failed the tests
<perrito666> menn0: not that I am aware of it
<sinzui> menn0, I am not against backporting. I want dimiter's backport first though
<menn0> sinzui: the routing fix is tiny and will be trivial to backport
<sinzui> menn0, okay, thank you
<perrito666> +1 to menn0 backporting his fix one cannot always be too sure
<menn0> sinzui: I really do think that it's just luck that 1.21 has been passing
<menn0> sinzui: master hasn't been passing because of that and this other issue
<menn0> sinzui: where the deploy command fails
<sinzui> menn0, menn0 Its been a good streak given the number of bundles and release tests we did during the last two weeks
<menn0> sinzui: indeed. that I can't quite understand given how easily I ran into the problem with 1.21 when testing manually
<menn0> sinzui: I've been meaning to ask... with these deploy tests it looks like the Juju binary is pulled from a deb created elsewhere (I presume another jenkins job)
<menn0> sinzui: how sure can we be that the deb matches the rev we think we're testing?
<sinzui> menn0, if you expand the listing of successes, you can see joyent has been partularly bad recent http://juju-ci.vapour.ws:8080/view/Cloud%20Health/job/test-cloud-joyent/
<sinzui> menn0, The cloud jobs require a binary built by the publishing job. Each job downloads the deb that matches the hosts arch. many machines don't have juju installed. those that do can only have juju stable, and the log of the test would show the wrong version during bootstrap
<sinzui> menn0, you can see that the when destroy-env fails, we fallback to the stable juju to call destroy-environment --force
<menn0> sinzui: ok
<menn0> sinzui: my concern is that the tests pull the "last successful" build for the arch from revision-publish but how does the job know what revision that build was built from and whether it matches what the deploy test thinks it's testing?
<menn0> sinzui: I'm not saying it doesn't work. I would just like to understand how it works :)
<sinzui> meno Those job cannot run of publish-revision fails. CI exits early and the other jobs are all left in pending
<sinzui> menn0, CI has a requirements chain. Jenkin's crap UI corrupts this stanza, which is the configuration of the job
<sinzui> [ci-director]
<sinzui> group-name: tests
<sinzui> requires: publish-revision
<sinzui> failure-threshold: 2
<sinzui> vote: true
<sinzui> tags: subjects=substrate,CPC function=deploy substrate=joyent arch=amd64 series=precise
<menn0> right, got it. so it's ci-director plugin that does the dependencies between jobs. I hadn't noticed that stuff before.
<menn0> sinzui: thanks for the explanation
<rick_h_> thumper: ping
<natefinch> ericsnow, wwitzel3: can you guys update this doc with how things are going?
<wwitzel3> natefinch: what doc?
<natefinch> https://docs.google.com/a/canonical.com/document/d/1eqDC5GwcLor1dpl8Wg3nYZw9xHuIqdxXXJEeIRJ883w/edit
<ericsnow> natefinch: can't edit
<natefinch> ericsnow: reload
<ericsnow> natefinch: updated
<natefinch> ericsnow: thanks.  Obviously feel free to edit bullet points to fit whatever the actual tasks are etc.  Just want that doc to be up to date since The Powers That Be are looking at it (and I just realized I'd never shown it to you and Wayne ;)
<ericsnow> natefinch: got it
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1402826
<sinzui> natefinch, thumper I think CI will bless master, but abentley found a regression when in the new weekly tests we added. We need someone look look into bug 1402826
<mup> Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1402826>
<menn0> sinzui: the joyent routing fix is now backported to 1.21
<thumper> sinzui: hmm...
<menn0> sinzui: should I also backport to 1.20? (will there be more 1.20 releases?)
<thumper> menn0: what do you know about the networker job?
<thumper> JobManageNetworking
<sinzui> menn0, I never want to do a 1.20 release again.
<menn0> thumper: very little
<sinzui> menn0, I hope 1.21 is the new stable soon
<thumper> sinzui: to we expect to be able to have 1.21 talk to 1.18?
<thumper> hmm..
<thumper> how can we work out the version of the server?
<thumper> I suppose we can go "environment get agent-version
<thumper> omg that is hacky
<thumper> but probably necessary
<menn0> thumper: why do you ask about the networker?
<thumper> bug 1402826
<mup> Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1402826>
<thumper> menn0: but it is a different issue
<menn0> thumper: looking at that bug
<menn0> thumper: if the error about JobManageNetworking not existing is returned could the client try again without it?
<thumper> that could work but is also hacky
<menn0> thumper: agreed
<menn0> thumper: but is capability based instead of hardcoding versions
 * thumper nods
<menn0> thumper: either way works though
<menn0> thumper: are you looking at that one?
<thumper> menn0: can you? I'm otp
<menn0> thumper: ok ... another day another CI blocker...
<lazyPower> heyyyyyy thumper
<mbruzek> hello thumper
<lazyPower> where are you guys stashing the lxc downloads these days?
<lazyPower> i have a feeling i've got a cached lxc image, and i've wiped all my templates
<lazyPower> however - watching my process list i only see gzip -d pop up, not the wget
 * thumper hides behind the call he is on
<lazyPower> mmhmmmm
 * lazyPower snaps
<lazyPower> aint nobody got time for that
<mbruzek> thumper: all my machines are in pending and I wiped out /var/lib/juju/containers/*
<mbruzek> thumper: can you ping me after your call
<jose> thumper: hey, I'm having some problems with local, lxc is stuck in pending
<thumper> mbruzek, jose, lazyPower: off the call now and here to attempt to answer your lxc questions
<lazyPower> thumper: you've got brilliant timing
<lazyPower> thumper: ready for the awesomeness? it was UFW
<thumper> UFW?
<lazyPower> yeah UFW managed to block the agent => stateserver communication
<thumper> what is UFW?
<lazyPower> its a firewall
<jose> supposed to be uncomplicated
<lazyPower> the complicated uncomplicated fire wall
<thumper> ah
<lazyPower> so, nothing moved, nothing to blame juju core about
<thumper> oh good
<lazyPower> thumper: what ports would i open in a firewall for the stateserver?
<thumper> lazyPower: the apiserver port
<thumper> and ssh
<thumper> and any port opened by a service deployed to it
<thumper> lazyPower: if you are doing HA then there are probably other state ports needed too
<thumper> lazyPower: in order for the mongo dbs to sync
<lazyPower> thumper: just local, non ha
<lazyPower> 17017 is the default stateserver port correct?
<thumper> I wish I had a week to hack to do what I liked
<thumper> then I'd fix the local provider
<thumper> yes
<jose> 17070*
<lazyPower> youv'e got 2 weeks coming up
<thumper> lazyPower: hahaha
<thumper> nope
<thumper> I have a busy personal project for those
<lazyPower> dont we all :P
<thumper> :)
<lazyPower> i'm going to tackle my basement
<lazyPower> allright, thanks for humoring me thumper all the same
 * jose has left #juju-dev (part)
<menn0> wallyworld, thumper: fix for the current CI blocker. https://github.com/juju/juju/pull/1319
<thumper> menn0: looks good, I think it needs to be in 1.21 too
<thumper> menn0: and thanks
<wallyworld> menn0: i am currently looking - i have a suggestion i'm part way through writing
<menn0> menn0: yep was planning on backporting once the PR for master got the green light. i suspect it won't be a straightforward cherry pick because the machine command been refactored recently.
<menn0> thumper: urgh... ^^^ this was for you.
<menn0> wallyworld: no probs. I will wait.
<thumper> :-)
<wallyworld> thumper: menn0: i wonder, instead of looking at agent version, should we not query the state server for the jobs it has and use that as the determiner?
<menn0> wallyworld: is that really sensible though?
<menn0> wallyworld: just because the state server doesn't have JobManageNetworking doesn't mean the new machine can't
<menn0> wallyworld: (not that I'm completely sure about this)
<wallyworld> not sure, i'd have to check in more detail. i thought that state server would have manage network job
<wallyworld> if it doesn't then suggestion is moot
<wallyworld> versiob check is probably ok
<thumper> wallyworld: we don't have the facility to ask the machine what jobs it has
<wallyworld> i just generically prefer checks based on capability rather thaN VERSION
<thumper> wallyworld: unless you are the machine agent
<thumper> the client doesn't
<thumper> wallyworld: understood
<wallyworld> fair enough, was just thinking out loud
<menn0> wallyworld: I prefer capability based checks too
<wallyworld> my real suggestion was to make the get server version method a base method on EnvCommand
<menn0> wallyworld: but I don't think it works in this case
<wallyworld> np
<menn0> wallyworld: sure, moving the method to EnvCommand probably makes sense
<menn0> wallyworld: you're thinking we'll have more of these things come up?
<wallyworld> ty
<wallyworld> could do
<wallyworld> i think we may well, but of course am not sure
<wallyworld> seems plausible though
<menn0> wallyworld: ok, i'll move it
<wallyworld> thanks, seems like the bestter place for it
<menn0> LOL! bestter
#juju-dev 2014-12-16
<thumper> time to go and make another coffee
<menn0> wallyworld: that's done. it ended being a standalone function in the envcmd package (it doesn't need anything on EnvCommandBase.
<menn0> wallyworld: PTA quick L
<wallyworld> sure, ty
<wallyworld> menn0: thanks, looks good, and i do like where the helper is now located
<menn0> wallyworld: great. merging!
<thumper> \o/
<thumper> anastasiamac_: hello on call reviewer :-) http://reviews.vapour.ws/r/639/
<thumper> rick_h_: that one is for you ^^^
<wallyworld> thumper: sadly anastasia is ill today
<wallyworld> axw: standup?
<thumper> wallyworld: oh no... stuff is going around
<axw> wallyworld: sorry, omw
<thumper> wallyworld: could you take a look?
<thumper> wallyworld: it is very small
<wallyworld> thumper: sure, after standup whivch is now
<thumper> cheers
<wallyworld> menn0: great that that bug is fix committed, now we just gotta wait for CI to be unblocked
<menn0> wallyworld: yep. am backporting to 1.21 now
<wallyworld> thumper: review done
<thumper> wallyworld: cheers
<thumper> wallyworld: valid comments, will fix when I'm not in the middle of another branch :)
<wallyworld> sure :-)
<wallyworld> thumper: i have a tiny one for you when you get a chance http://reviews.vapour.ws/r/640/
<thumper> wallyworld: have you tested it?
<wallyworld> thumper: doing it now on local and ec2
<wallyworld> thumper: i wish we could change the primary target for a bug - i don't think we can, can we?
<thumper> yes
<thumper> like, for ages
<wallyworld> i forget
<wallyworld> i want to target to juju-core as primary
<wallyworld> then i can have targets for 1.22 and 1.21
<wallyworld> maybe i need to delete juju-core first
<wallyworld> and then reassign
<thumper> what do you mean?
<thumper> all bug tasks are considered equal
<thumper> https://bugs.launchpad.net/juju-core/+bug/1328958
<mup> Bug #1328958: Local provider fails when an unrelated /home/ubuntu directory exists <local-provider> <juju-core:In Progress by wallyworld> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1328958>
<wallyworld> thumper: soon that bug, i can't add a 1.21 series
<wallyworld> as the primary target is the distro
<wallyworld> unless i'm stupid, which is a distinct possibility
<thumper> wallyworld: is that what you wanted?
<thumper> wallyworld: look at the bug
<wallyworld> thumper: yes, so how did you change the primary target?
<thumper> you need to get to that bug through the project, personally, I just hacked the url
<wallyworld> ah, yes, you are right
<wallyworld> i forgot that
<rick_h_>   thumper :)
<thumper> menn0: ugh... having to deal with environment specific collections in a non-normal way
<thumper> menn0: which means hoop jumping
<thumper> and likely to clash with outstanding work...
<thumper> fooey
<menn0> menn0: do you want getRawCollection()?
<menn0> thumper: ^^^ (did it again)
<wallyworld> menn0: i was to remove the legacy fields in MachineStatus in api client in master - i think that's ok, rught?
<thumper> menn0: nah, in the end I went with state.ForEnviron so I could use the easy method of getting the info :-)
<menn0> wallyworld: hmmm
<menn0> wallyworld: if we want old clients to continue working those fields have to stay
<wallyworld> maybe we can't if we must retain compatability with 1.20
<menn0> wallyworld: 1.20 should be fine
<wallyworld> but i thought we only needed compatability with 1.28
<menn0> wallyworld: but pre 1.19 won't work
<wallyworld> 1.18
<menn0> wallyworld: exactly
<menn0> wallyworld: a 1.18 client will still look for those fields
<wallyworld> hmmm, yeah, i t will :-(
<wallyworld> damn
<menn0> wallyworld: when I wrote that comment I was under the impression that we could stop worry about compatibility after 2 versions or something
<wallyworld> i'll fix the comment
<menn0> wallyworld: the fields could be removed now that we have API versioning though
<menn0> wallyworld: as suggested by the comment
<wallyworld> hmmm, but the server side call still needs to be there for older clients
<wallyworld> so i'll have to leave the processAgent() logic alone
<wallyworld> which is where i'm currently looking
<menn0> wallyworld: yep. there would need to be 2 versions of the struct and 2 code paths
<wallyworld> might let sleeping dogs lie for now
<mattyw> morning folks
<jam1> axw: wallyworld: greetings
<jam1> thought I'd try to catch you guys before we started for the day
<wallyworld> jam1: hi
<axw> jam1: hiya
<wallyworld> jam1: let us know if you want to chat or whatever, maybe you've already started
<wallyworld> fwereade: meeting?
<jam1> wallyworld: we've started, though we're a bit hit and miss on internet connectivity, you should be seeing updates/responses in the doc
<wallyworld> ok, ty
<wallyworld> axw: ^^^^^
<axw> yep I have been following updates
<axw> thanks
<wallyworld> fwereade: you around for our 1:1?
<TheMue> morning
<dimitern> morning TheMue
<TheMue> dimitern: o/
<axw> wallyworld: did you want to catch up still?
<wallyworld> yeah, give me a couple of minutes
<axw> sure
<wallyworld> axw: ok now, in our 1:1
<axw> brt
<dimitern> fwereade, hey
<dimitern> fwereade, if you can have a look at http://reviews.vapour.ws/r/643/ - it's a backport to 1.21 of the fix for bug 1397376 you approved yesterday
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<perrito666> morning all
<dimitern> perrito666, o/
<perrito666> bug 1402826 seems to be fix committed what is the status tha triggers unlocking + topic change?
<mup> Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Fix Committed by menno.smits> <juju-core 1.21:Fix Committed by menno.smits> <https://launchpad.net/bugs/1402826>
<jam1> perrito666: Fix Released is generally the actual unblock trunk, and it is supposed to only happen after CI actually does a run and sees that the failure isn't present anymore.
<jam1> (AIUI)
<jam1> perrito666: given that http://juju-ci.vapour.ws:8080/job/compatibility-control/ is now happy, maybe we can set it to Fixed ?
<jam1> dimitern: ^^ think you can check into whether trunk is actually unblocked now /
<jam1> ?
<dimitern> jam1, not sure how except by looking at the bugs - and the only one there is fix committed
<anastasiamac_> jam1: dimitern: this seems to think that CI is still blocked http://goo.gl/4zd1e9
<jam1> dimitern: I mean just tracking through that the bug really is fixed (looks like it to me from the linked CI test that is now Blue)
<jam1> anastasiamac_: so trunk *is currently blocked* my point is whether we should unblock it because the thing we said fixed it really did fix it
<dimitern> jam1, I see the same, so it must be some lag
<anastasiamac_> thnx for the link, jw4 :)
<anastasiamac_> jam1: it would be gr8 to unblock CI - it's been a while :)
<dimitern> mgz_, are you around?
<perrito666> jam1: I think the topic thing is auto, isn't it?
<dimitern> perrito666, nope it's not
<dimitern> perrito666, I *did* try to set it via chanserv but it doesn't work like it used to and I get no error; trying to set it directly blows with "you're not a channel operator"
* ChanServ changed the topic of #juju-dev to: The topic for irc://irc.freenode.net:6697/#juju-devÂ is: https://juju.ubuntu.com/Â | On-call reviewer: see calendar | Open critical bugs:
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Report bugs: https://bugs.launchpad.net/juju-core/
<dimitern> there!
<jam1> dimitern: worked for me
<jam1> I used "/msg chanserv help" and "/msg chanserv help topic" to sort it out
<dimitern> yeah, I was doing "topic #juju-core" not #juju-dev :)
<jam1> ah, yeah
<perrito666> mm, merge bot does not thing the same
<jam1> perrito666:
<jam1> so, the way the bot works, (AIUI) is it checks that this launchpad search has no items: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&
<jam1> since we still have the one as FixCommitted, it still rejects it
<jam1> perrito666: so my statement is, if you're confident that bug is fixed, mark it fix released
<perrito666> jam1: ah, I see I always mix those up
<jam1> perrito666: well it did change onece
<perrito666> as more and more kids enter summer vacation period the internet at home worsens
<dimitern> perrito666, would you mind reviewing this http://reviews.vapour.ws/r/643/ - it's a straight backport of a fix for bug 1397376 which was already approved by fwereade and landed on master yesterday
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<perrito666> dimitern: lgtmd but I am not a senior review dude
<dimitern> perrito666, np, thanks anyway :)
<dimitern> TheMue, can you lgtm it as well please? http://reviews.vapour.ws/r/643/
<TheMue> dimitern: *click*
<TheMue> dimitern: done, push it ;)
<dimitern> TheMue, thanks!
<TheMue> yw
<dimitern> oh ffs... this is getting ridiculous ERROR: {"message":"API rate limit exceeded for jujubot.","documentation_url":"https://developer.github.com/v3/#rate-limiting"} Finished: FAILURE
<perrito666> we maxed out our github quota?
<mgz_> hm, is that the landing side or the reviewboard side?
<dimitern> voidspace, maas meeting?
<sinzui> dimitern, what is blocking the backport of the https://bugs.launchpad.net/juju-core/+bug/1397376 to 1.21-beta4?
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1397376>
<perrito666> sinzui: https://github.com/juju/juju/pull/1324
<perrito666> Seems that dimitern got a funky error
<perrito666> <dimitern> oh ffs... this is getting ridiculous ERROR: {"message":"API rate limit exceeded for jujubot.","documentation_url":"https://developer.github.com/v3/#rate-limiting"} Finished: FAILURE
<jw4> sinzui: who has to mark https://bugs.launchpad.net/juju-core/+bug/1402826 as fix released? menn0?
<mup> Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Fix Committed by menno.smits> <juju-core 1.21:Fix Committed by menno.smits> <https://launchpad.net/bugs/1402826>
<sinzui> jw4, anyone who can verify the fix/test passes
<jw4> sinzui: I see
<sinzui> jw4, I will get to this in about 15 minutes. I need to sort out the block on beta4 first
<jw4> sinzui: feeling like a one armed paper hanger?
<sinzui> yes
<dimitern> sinzui, in a meeting, sorry
<sinzui> perrito666, dimitern looks like the job wrongly failed because the test couldn't clean up, not because of juju.
<sinzui> dimitern, perrito666 I will clean up aws, make the job not lie, and send the merge back for merging
<jw4> sinzui: fwiw the failing test http://juju-ci.vapour.ws:8080/job/compatibility-control/859/ is now passing http://juju-ci.vapour.ws:8080/job/compatibility-control/862/
<perrito666> tx sinzui
<sinzui> jw4, that is hard to read. the job tests *many* things. Without reading the data, we don't know which versions were under test
<perrito666> sinzui: do you keep some sort of list of the amount of alcohol owed to you by us?
<jw4> sinzui: cool - I'll quit bugging you now
<mgz_> perrito666: please think of his health
<sinzui> perrito666, no, I suck at drinking
<perrito666> sinzui: most people do, at least when using a straw
<perrito666> mgz_: well I usually pay my teammates debts in beers :p but we can start doing sandwitches and stuff
<dimitern> sinzui, that will be great
<perrito666> gsamfira_: coming?
<perrito666> alexisb: ?
<katco> sinzui: hey lp has https://bugs.launchpad.net/juju-core/+bug/1402826 as fix committed, what's the state of CI?
<mup> Bug #1402826: 1.21 cannot "add-machine lxc" to 1.18.1 <add-machine> <ci> <lxc> <regression> <juju-core:Fix Committed by menno.smits> <juju-core 1.21:Fix Committed by menno.smits> <https://launchpad.net/bugs/1402826>
<katco> /
<sinzui> katco, I need to retest to verify it is fixed. the test is a weekly test based on weekly streams
<katco> sinzui: ah ok.. do you expect that anytime soon?
<sinzui> Yes
<katco> sinzui: you my friend.. rock!
<voidspace> dimitern: sorry, was on lunch
<voidspace> dimitern: didn't know we had one
<dimitern> voidspace, no worries, it was mostly about explaining why we need it :) - I'm preparing an agenda/minutes doc and will share later
<perrito666> ericsnow: wwitzel3 natefinch
<wwitzel3> perrito666: having issues getting hangouts to load
<perrito666> I got kicked from the call first attempt
<wwitzel3> plus.google.com is just timing out for me atm
<sinzui> Sorry ladies and gentlemen, there is congestion in the merge/ci queue. We first need to unblock dimitern, to start testing beta4, then we can remove the block on master. which is also a block on beta4. We need to kick the landing bot to start moving
<perrito666> wwitzel3: you broke google
<dimitern> voidspace, you should've received a link to the maas call agenda doc
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  none
<sinzui> jw4, katco dimitern master is open. Don't all break it at once
<katco> sinzui: :)
<sinzui> dimitern, I see an intermittent test failure in the current merge. we will retest since we can see it passed in previous runs
<jw4> sinzui: haha
<dimitern> \o/ /o\
<dimitern> dimitern, is it TestAddRemoveSet  for mongo/replicaset ?
<voidspace> dimitern: I have, thanks
<voidspace> dimitern: we should have the call in the calendar
<voidspace> dimitern: subnet IP tracking only for aws... the trouble with that is that we need state for tracking
<voidspace> dimitern: and the provider specific stuff doesn't usually have access to state
<dimitern> voidspace, it is on the calendar, but not the red one
<voidspace> dimitern: you mean orange...
<voidspace> dimitern: or whatever colour you pick...
<voidspace> dimitern: if it's not on mine or juju-core I won't have it
<dimitern> voidspace, :) yeah I guess it can be orange-y
<dimitern> voidspace, you do have it on yours though?
<voidspace> dimitern: we could have a "SupportsSensibleIPAllocation" provider method that returns false for aws
<dimitern> voidspace, we need to have a chat some time tomorrow to see how to go about the proposed change
<voidspace> dimitern: and fallback to address picking
<dimitern> voidspace, yeah, that's a possibility
<voidspace> dimitern: I *do* have it in my claendar
<voidspace> dimitern: really sorry
<voidspace> dimitern: I totally missed that :-(
<dimitern> voidspace, not to worry - it's fine :)
<voidspace> dimitern: having two address allocation strategies is a pain
<voidspace> dimitern: we could just not track unavailable ones
<voidspace> dimitern: doesn't matter if we retry  them occassionally
<dimitern> voidspace, that's a good point
<voidspace> dimitern: it's probably better not to track them
<dimitern> voidspace, unfortunatelly, I have to go soon and can't think it through now
<voidspace> dimitern: ok chap
<voidspace> dimitern: see you later/tomorrow
<dimitern> voidspace, but will appreciate your ideas on it :)
<dimitern> voidspace, cheers
<natefinch> ericsnow: sorry, you have time now?
<ericsnow> sure
<ericsnow> wwitzel3: ready? (I'm in moonstone)
<ericsnow> sinzui: wwitzel3 and I are working on a new provider (GCE) and need to know what needs to be done image-wise (i.e. for simplestreams)
<wwitzel3> ericsnow: ok, omw
<ericsnow> sinzui: from what I understand we need some URL where the different images are hosted
<ericsnow> sinzui: and that URL will be on GCE somewhere?
<mgz_> ericsnow: you're probably better off talking to ben howard etc about images for gce?
<sinzui> ericsnow, I don't have any experience
<ericsnow> sinzui: ah, okay
<ericsnow> mgz_: k, thanks
<mgz_> you shouldn't required gce hosted simplestreams to just get started on the provider
<mgz_> you can provide your own image-metadata-url pointing to anywhere
<perrito666> gsamfira_: ping me whenever you are available please
<sinzui> ericsnow, I have no experience with image streams the team in #cloudware know all about it.
<ericsnow> sinzui: yeah, I'm hitting up utlemming (Ben Howard) about it
<ericsnow> sinzui: thanks though
<sinzui> ericsnow, as mgz_ we don't *need* to provide specific streams for a cloud, but it is nice to do. The Juju QA team can create local agent streams once it get credentials to test in the cloud and setup in local storage. if there isn't local storage, we don't need create agent streams
<ericsnow> sinzui: cool.  That would work great.  I'll send you an email just so we can track this better.
<ericsnow> sinzui: also, what do you mean by "local storage"
<ericsnow> sinzui: the equivalent of s3 in AWS?
<sinzui> ericsnow, if the cloud has a storage mechanism like swift, s3, manta, then we can place agents in the cloud for faster delivery
<ericsnow> sinzui: got it :)
<natefinch> fwereade: you around?
<voidspace> g'night all
<perrito666> If any OCR is around http://reviews.vapour.ws/r/645/
<perrito666> if anyone else wants to, also welcome
<menn0> thumper: bug 1403151 might be of interest to you
<mup> Bug #1403151: local provider stops bootstrapping: "Job is already running" <juju-core:New> <https://launchpad.net/bugs/1403151>
<thumper> hmm
<menn0> I sometimes forget how much better modern version control systems are
<menn0> a file I'd changed in my branch had been moved to another directory by someone else
<menn0> yet my change still applied cleanly because git knew how the file had moved
<ericsnow> what is appropriate instance root disk size for a juju machine?
<ericsnow> GCE lets you set whatever disk size you want (as long as the image you use fits in it)
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1403200
<sinzui> natefinch, thumper: is someone about to solve bug 1403200 that block merges and the release of 1.21-beta4
<mup> Bug #1403200: mass upgrades do no complete <ci> <maas-provider> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1403200>
<menn0> sinzui: i've just started looking at the ticket
<menn0> sinzui: the description in the ticket and the console output i'm seeing don't match
<menn0> sinzui: the test appears to give up and destroy the env 2 minutes after starting the upgrade
<menn0> sinzui: can you explain where you're seeing an upgrade still running after 30 mins?
<sinzui> menn0, jog ran his own run separate to ensure we got log
<menn0> sinzui: also - side issue - the test looks like it attempts to capture the logs for after the env has been destroyed and the maas node is turned off
<sinzui> menn0, I think jog can help you get to the machine finfolk machines too
<sinzui> menn0, ! I just reported a bug about that too
<sinzui> Indeed the capture failed, which is why jog ran it himself
<menn0> sinzui: well it seems like the behaviour jog is seeing when running tests manually is not matching what is happening during the actual CI runs
<sinzui> menn0, Our tests exit early because juju client raised an error trying to talk to the server
<sinzui> menn0, if not having an api server is not an error, then juju needs to not exit with an error code
<menn0> sinzui: I don't see that in the console output
<sinzui> not all do that that
<menn0> sinzui: as the upgrade runs it is possible to get a "maintenance in progress" error
<menn0> sinzui: it could be that
<sinzui> this one just timesout after 10 minutes http://juju-ci.vapour.ws:8080/job/maas-upgrade-trusty-amd64/336/console
<menn0> sinzui: it is short-lived
<sinzui> it didn't timeout the previous revision
<sinzui> menn0, jog let the env try to upgrade for 30 minutes
<menn0> sinzui: ok
<menn0> sinzui: i'm not saying there isn't a problem
<sinzui> menn0, I was hoping we could extend the timeout
<menn0> sinzui: for that run (336) I don't see a 10 minute timeout
<menn0> sinzui: it looks like 2 minutes to me
<menn0> 2014-12-16 20:34:14 INFO juju.cmd supercommand.go:329 command finished
<menn0> 1.20.14: 1, 0, 2, dummy-sink/0, dummy-source/0 ....timeout 600.00s juju --show-log destroy-environment maas-upgrade-trusty-amd64 --force -y
<menn0> 2014-12-16 20:36:19 INFO juju.cmd supercommand.go:37 running juju [1.20.14-trusty-amd64 gc]
<menn0> 2014-12-16 20:36:19 INFO juju.provider.common destroy.go:15 destroying environment "maas-upgrade-trusty-amd64"
<menn0> 2014-12-16 20:36:20 INFO juju.cmd supercommand.go:329 command finished
<menn0> 20:34:14 to 20:36:19
<sinzui> menn0, ah right
<sinzui> but the time is set to 20 minutes.
<sinzui> menn0, don't focus on that. We need to focus on the logs that jog attached...
<sinzui> jog join in the conversation, can you get menn0 machines or rerun tests with him to learn why 30 minutes does not complete an ujpgrade
<jog> sinzui, I think the "1, 0, 2, dummy-sink/0, dummy-source/0" output in the above is from our status check, which gets a non-zero exit code and may fail that job at that point
<jog> yup, I ran this on my desktop using a few KVM machines
<sinzui> the copy remote logs is swallowing the error the juju command returned
<jog> we can manually try to reproduce on finfolk so others can get access...
<jog> menn0, I still have the env setup if there is anything you would like me to capture or check
<menn0> jog: I just checked what you've attached to the bug and that look pretty complete thanks
<menn0> jog: can you send me the steps you used to set up the env and run the test as well?
<jog> sure
<menn0> jog: also, where are the logs for machine-1?
<jog> machine-1 was added and removed before I tried I deployed by charms and did the upgrade
<jog> s/I tried I deployed by/I deployed my/
<menn0> jog: ok np
<sinzui> menn0, jog: I just pushed a change to not swallow the command error when we cannot get logs. any reason not to re-run one of the failing jobs?
<menn0> sinzui: please do
<sinzui> jog, I think we fail to get logs because the script tried to use the dns address instead of ip
<jog> sinzui, go ahead I don't think there is anything to capture from there
<sinzui> lets check back in 20 minutes to see where it is http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/maas-upgrade-trusty-amd64/337/console
<menn0> jog: I think it might help because the attempt to capture logs seems to come after the message about the node being shut down
<menn0> jog: are you going to email those extra details or attach to the bug?
<jog> I will attach to the bug
<sinzui> menn0, the nodes were shutdown after logs fails
<sinzui> the unless juju shutthem down
<menn0> jog: looking at the logs from your manual run, the reason the upgrade didn't complete is because it didn't really start
<menn0> jog: machine-0 is "waiting for the other state servers to be ready for upgrade"
<menn0> jog: were there ever any other state servers in this environment?
<menn0> jog: do you still have it up? I might ask you to check some things in the MongoDB soon if it is.
<jog> hmm, there should not have been any other state servers and yes it's still up
<menn0> jog: ok, interesting.
<menn0> jog: let me just figure out a command for you to run.
<menn0> jog: ok, let's do some exploring
<menn0> jog: please run: juju ssh 0
<jog> ok
<menn0> jog: and then once you're in: mongo 127.0.0.1:37017/admin --ssl --username "admin" --password "`sudo grep oldpassword /var/lib/juju/agents/machine-*/agent.conf  | cut -d' ' -f2`"
<menn0> jog you might need to install the mongo command line tools for that to work (you'll get a hint)
<jog> menn0, so I have to log in directly with ssh, since 'juju ssh' rejects the connection 'ERROR login failed - maintenance in progress'
<menn0> jog: of course.
<sinzui> Juju just called upgrade
<menn0> jog: let me know when you're in and running the mongo shell
<jog> menn0, I'm there... had to install the mongo cmd line client first
<menn0> jog: now: use juju
<jog> done
<menn0> jog: then: db.upgradeInfo.find().pretty()
<jog> https://pastebin.canonical.com/122444/
<sinzui> menn0, jog. in the console log we can see after upgrade, status was polled a few times by the dots, then status timed out after 2 minutes because there was nothing to talk too
<sinzui> menn0, Should the state-server not me available for more than two minutes during an upgrade?
 * sinzui prefers to prove the tests are wrong so that he can get a blessed revision
<menn0> the state server should be available but you can expect it to return "maintenance in progress" for a little bit during the upgrade
<menn0> I would have thought 2 minutes would have been long enough though
<menn0> but I don't know how fast this hardware is
<menn0> waiting 5 mins might be better
<menn0> jog: now this: db.machines.find({}, {jobs:1, life:1})
<jog> { "_id" : "3", "jobs" : [  1 ], "life" : 0 }
<jog> { "_id" : "2", "jobs" : [  1 ], "life" : 0 }
<jog> { "_id" : "0", "jobs" : [  2,  1 ], "life" : 0 }
<menn0> jog: and db.instanceData.find({}, {"machineid": 1, "instanceid": 1, "env-uuid":1})
<jog> { "_id" : "2", "instanceid" : "/MAAS/api/1.0/nodes/node-63cfc508-3719-11e4-8b0a-52540018f567/" }
<jog> { "_id" : "3", "instanceid" : "/MAAS/api/1.0/nodes/node-640f98fe-3719-11e4-821a-52540018f567/" }
<jog> { "_id" : "0", "instanceid" : "/MAAS/api/1.0/nodes/node-63cebcda-3719-11e4-821a-52540018f567/" }
<menn0> jog: thanks this is all very helpful
<menn0> jog: let me have a think and a hunt through the code
<jog> np
<thumper> menn0: ideas?
<menn0> jog: so far everything looks correct
<jw4> thumper: trivial typo maybe? http://reviews.vapour.ws/r/646/
<menn0> thumper, jog: it appears that for some reason the state server thinks it had to wait for other state servers to signal they were ready for the upgrade, but there are no other state servers
<thumper> hmm... interesting
<sinzui> the state-server has voices in its head or is so lonely it is thinks it has friends
<sinzui> menn0, I have a 5 minute timeout in place. Do you want me to retest?
<menn0> sinzui: might as well
<jw4> tx waigani
<menn0> jog: can you pls also run: db.stateServers.find({_id: "e"}, {machineids: 1, votingmachineids:1, "env-uuid":1})
<jog> { "_id" : "e", "machineids" : [  "0" ], "votingmachineids" : [  "0" ] }
<menn0> jog: also: db.instanceData.find({"env-uuid": {"$exists": true}}).count()
<jog> 0
<menn0> jog: db.instanceData.find({_id: {"$in": ["0"]}})
<jog> { "_id" : "0", "arch" : "amd64", "cpucores" : NumberLong(1), "instanceid" : "/MAAS/api/1.0/nodes/node-63cebcda-3719-11e4-821a-52540018f567/", "mem" : NumberLong(2048), "tags" : [  "virtual" ], "txn-queue" : [  "5490714b164546420f00000a_1cb1133b",  "5490910816454643c3000002_02253369" ], "txn-revno" : NumberLong(2) }
<menn0> jog: hmm everything looks normal
<menn0> jog: I can't see why the upgrade didn't proceee
<menn0> proceed
<menn0> jog: let me try and repro locally using your instructions.
<menn0> jog: pls leave the env up if you can
<jog> menn0, I've tried with LXCs and don't see the same issue
<menn0> jog: interesting
<jog> sinzui, should we pause the CI jobs and I can use the finfolk MaaS to reproduce?
<sinzui> jog, build-revision is disabled...I already paused it
<jog> sinzui, ok I meant the retry of jobs from Jenkins... I can try manual steps to bring it up so the machines stay around long enough to poke around
<sinzui> jog, that is what I am doing right
<menn0> jog: I haven't used maas before. is there a good guide for getting it working under kvm?
<menn0> jog: i've found several
<jog> menn0, we have a doc the describes how we setup our env but it's not really trivial... sinzui, do you think we can give access to finfolk?
 * jog has a hard stop to pick up kids from school and will be back in about 45 minutes.
<sinzui> jog, menn0 I think IS already gave everyone in canonical access to finfolk
<sinzui> jog, but I don't see menn0  in /home.
<sinzui> menn0, I think you need the ssh rules to get to the machine, as you have cloud-city you have the keys to use the gateway we setup.
<menn0> sinzui: ok, let me try
<sinzui> jog, maybe i should abort this current test of maas upgrade. I think it has been stalled for 15 minutes
<sinzui> menn0, jog: I terminated the job using the -HUP, but that didn't call cleanup. We might have a dirty maas now :(
<ericsnow> wallyworld: you have a few minutes?
<jog> hi menn0, sinzui, I'm back
<menn0> jog: hi again
<menn0> jog: i'm on finfolk now
<menn0> jog: I can repro the problem
<jog> great!
<menn0> jog: just uploading a instrumented version of juju now
<menn0> jog: hopefully the extra logging will tell me something
<menn0> jog, sinzui: so the issue is that the state server doesn't think it's the master!
<menn0> jog, sinzui: I've never seen this before
 * menn0 continues digging
<sinzui> It is a modest state-server
<jog> heh sinzui, I was thinking the same thing
<menn0> when jujud comes up on 1.20 mongo tells the state server it's the master
<menn0> after rebooting into 1.21 mongo tells the state server it's no longer the master
<menn0> yet if I use the shell, mongodb says that the instance on machine-0 is the primary/master
<menn0> so something in juju must be getting it wrong
<menn0> but why only on maas...
<menn0> moar digging
<menn0> sinzui, jog: these tests stopped working for both master and 1.21 when dimiter's fix for bug 1397376 when in
<mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <fallout> <landscape> <maas-provider> <juju-core:Fix Committed by dimitern> <juju-core 1.21:Fix Committed by dimitern> <https://launchpad.net/bugs/1397376>
<menn0> looking at that now
<ericsnow> wallyworld: ping
<katco> ericsnow: i think he is off today
<ericsnow> katco: k, thanks
<katco> ericsnow: np
<jog> menn0, sinzui, and timing of that commit was when we had our MaaS down for upgrading with the CI jobs just getting re-enabled after the weekend :(
<menn0> jog, sinzui: i'm beginning to see how that commit could cause the behaviour we're seeing
<menn0> jog, sinzui: adding more logging
<sinzui> :)
<menn0> jog, sinzui: with this release the isMaster check always returns false on maas
<menn0> jog, sinzui: upgrades not completing is just fallout from that
<jog> :)
#juju-dev 2014-12-17
<menn0> thumper: ping?
<thumper> otp
<menn0> thumper: kk
<katco> anastasiamac_: ping
<thumper> menn0: ok, back but need food
<thumper> whazzup?
 * thumper finds the tag "fallout" amusing
 * thumper needs food badly
<menn0> thumper: I just finished lunch. let me know when you're available
<ericsnow> can anyone tell me if wwitzel3 and I need to implement storage for the new GCE provider?
<ericsnow> my understanding is that we don't
<thumper> menn0: my lunch is cooking but I have a few minutes now
<menn0> thumper: ok
<menn0> thumper: so this maas issue is that since dimiter's big address handling change
<menn0> thumper: no state server thinks it is the master any more
<thumper> hahaha
<thumper> oops
<thumper> why?
<menn0> in mongo.IsMaster
<menn0> the address for the replicaset master is compared against the machine's internal address
<menn0> if they match then IsMaster returns true
<menn0> but they no longer match
<thumper> can we compare across all addreses for the machine?
<menn0> it seems on maas the replicaset master address comes back as the DNS address of the host. e.g. juju-qa-maas-node-29.maas
<menn0> but the "best" internal address that it gets compared against is an IP
<menn0> I have a fix which does just that
<menn0> I just wanted to check that you thought it was a sane idea
<menn0> I guess there's a risk of 2 machines thinking they are master
<thumper> a fix which compares against all?
<menn0> yes
<thumper> it is unlikely to cause two to think they are master will it?
<menn0> if the replicaset master addr comes back as say "localhost" or some machine/link local address
<menn0> and the machine also has that in it's list
<menn0> but I don't think that's likely because I think link local addresses are already being filtered out
 * thumper thinks
<thumper> I say "it may well fix it and doesn't look like it'll hurt, and whoever is up next can back it out and fix another way if they are so inclined"
<thumper> so do it
<menn0> cool
<menn0> i'll make sure dimiter knows what i've done so that he can verify
 * thumper nods
<menn0> there might also be another way to skin this cat that he knows about
 * menn0 thought he might actually be able to commit something today...
<menn0> (that wasn't a CI unblocker)
<waigani> menn0: the mover of blocks
<menn0> my 1 year old son is good at moving blocks
<waigani> must be in the genes
<thumper> ha
<anastasiamac> menn0: take "the mover of blocks", my one would have been "meen0: the unblocker" :)
<menn0> thumper: here's that fix: http://reviews.vapour.ws/r/647/
 * thumper looks
<thumper> the unblockenator
<menn0> unblockenologist
<menn0> thumper: this fix is for 1.21
<menn0> thumper: i'll forward port it once it's in
<thumper> shipit
<anastasiamac> menn0: i think that u r certainly turning unblocking into an art more than a science :-) of course, if u r happy with the title..
<anastasiamac> thumper: menn0: there should be a reward for unblocking CI the most..
<menn0> beer!
<menn0> actually scotch might be more appropriate...
<anastasiamac> menn0: as suprising as it may be, not everyone will be encouraged by beer ...
<anastasiamac> menn0: or scotch
<waigani> menn0 will be
<anastasiamac> menn0: but certainly a start
<thumper> menn0: what sort of scotch?
 * thumper is not a fan
<menn0> thumper: I like less challenging single malts
<menn0> thumper: I don't really go for the really smoky/peaty ones
<thumper> menn0: how is scotch different from whiskey?>
<menn0> thumper: scotch is "scotch whiskey" ... whiskey from Scotland
<thumper> ah
<katco> thumper: hey thank you again for green-lighting that branch. i'll have more things landing in the coming days to get it into shape.
<thumper> katco: ack
<katco> thumper: ?
<katco> thumper: ack as in TCP/IP ack?
<thumper> katco: that is a general positive response "ok, got it"
<thumper> yes
<katco> thumper: ah ok :)
<thumper> sorry, more irc specific geekiness
<katco> thumper: you'll be happy to know that the stderr flag is coming back out now that machine agent is refactored
 * katco enjoys geekiness, just wanted to make sure ;)
 * thumper nods
<thumper> I can hear the girls watching avengers... again...
<anastasiamac> anyone could have a look at https://github.com/juju/names/pull/35?... with a pretty plz?
<anastasiamac> waigani: ^^
<anastasiamac> thumper: i've heard avangers r beta than lion king :)
<jw4> anastasiamac: I'm a little cautious about reusing the validUserPart regex if it just *happens* to co-incide with the charm usage
<jw4> anastasiamac: is that usage semantically correct too?
 * jw4 breaks for supper - sorry :)
<waigani> jw4: it's not exported so not intended for reuse, right? anastasiamac?
<jw4> waigani: I just mean reusing it in charm.go from user.go
 * jw4 leaves for real this time
<anastasiamac> waigani: not intented for re-use outside but m re-using it in names itself
<anastasiamac> waigani: should I not?
<anastasiamac> waigani: if user reg ex changes for whatever reason, i'd like my part to still identify valid user
<waigani> ah right, well, the definition of schema in the code is // schema:~user/series/name-revision
<menn0> ok fixes for the CI blocker merged into 1.21 and master
<menn0> re-enabling the build-revision jenkins job now
<mattyw> morning all
<waigani> anastasiamac: so there would be an issue if the format of the "user" in the schema and the "user" in the validation functions changed. But, I don't see why that would happen, and if the format changes, you'd have problems regardless and given charm.go is in the names package I think it's fine for there to be a package level "user" that it uses
<waigani> anastasiamac: so, LGTM from me.
<anastasiamac> waigani: thnx :-)
<jw4> anastasiamac: and LGTM from me - I didn't know the definition of the schema used the ~user part :)
<anastasiamac> thnx jw4 :) and here I thought u were going to leave for real...
<jw4> lol
<jw4> confession: I'm actually BACK
<jw4> I scarfed
 * thumper looks at anastasiamac's names branch
<thumper> anastasiamac: just a few easy tweaks
<jog> menn0, looks like build revision 2179 has your fix for the MaaS upgrade and is being run through CI now
<menn0> jog: yep
<menn0> jog: i'm fairly confident it'll pass now
<jog> menn0, are you done with finfolk?
<menn0> I am
<jog> I should stop the server that running there, so this revision build can run when it gets to that test
<menn0> only the MAAS server is running now
<menn0> jog: I killed the other machine
<menn0> jog: but please check that everything is in order
<menn0> jog: I've cleaned up what I was using
 * menn0 heads out to get some groceries
<jog> menn0, thanks! and yeah it's just the MaaS server that we shutdown
<jog> menn0, thanks for the quick help on this one!
<anastasiamac> thumper: about separate var blocks...
<anastasiamac> thumper: wanted to group exported vars vs non-exported...
<anastasiamac> thumper: u don't like this grouping?
<anastasiamac> thumper: one var block for all is beta?
<thumper> I don't see why they need to be separated
<thumper> exported vars have comments
<thumper> internal ones don't
<thumper> the comments are enough separation I think
<thumper> oh my god
<thumper> this coffee is good
<thumper> I feel I may need another real soon now
<anastasiamac> thumper: k since u have found a gr8 coffee, I'll put vars in one block...
<thumper> waigani: you can't land stuff until this page: https://bugs.launchpad.net/juju-core/+bugs?field.tag=ci+regression&field.tags_combinator=ALL has no criticals
<thumper> didn't find... made
<waigani> thumper: good to know, I was using a different filter on lp
<thumper> the tags stay there until CI passes, then it removes them
<thumper> that is when master is open for landing again
<jw4> thumper: I thought it was only Critical though?  And not including Fix Released?   I shortened that to: http://goo.gl/4zd1e9
<thumper> jw4: it is, that's why I said no criticals
<jw4> thumper: doh :)
<anastasiamac> thumper: if u made a gr8 coffee, does it mean u r k with me merging my PR into names?
<thumper> jw4: I saved that page, so now I just start typing "regression" and hit enter
<jw4> thumper: nice
<thumper> anastasiamac: do you feel strongly that they should be separate?
<anastasiamac> thumper: not strongly enough :)
<anastasiamac> thumper: they r distinct
<anastasiamac> thumper: whether we r separating them otherwise si a style
<anastasiamac> thumper: I am pendantic and will separate and teeth things apart until I get to nano levels
<thumper> anastasiamac: I'm happy that the local and exported vars are grouped within the var statement
<thumper> but we don't need multiple var statements
<anastasiamac> thumper: excellent! I merge then? :P
<thumper> anastasiamac: are they grouped yet?
 * thumper refreshes
<thumper> sorry hadn't been looking
<anastasiamac> thumper: they r :)
<thumper> line 36 of charm.go
<thumper> they are almost...
<anastasiamac> thumper: ur coffee must b really good! m on it :-)
<thumper> unfortunately my coffee is finished
<thumper> I did consider making a big cup 4 shot one
<thumper> but decided against it
<thumper> perhaps I should have
<waigani> anastasiamac: merge, quick! while you've still got a chance!
<anastasiamac> thumper: should be perfect now but I'll re-order it for mattyw
<mattyw> anastasiamac, waigani sorry - I jumped in at the wrong/ right time :)
<thumper> mattyw: surely URI not URL
<anastasiamac> waigani: m weaning myself off coffee (and onto the coke) so will not b as quick as all these "real coffee" drinkers :D
<thumper> why no coffee?
<thumper> that just seems cruel
<thumper> coffee is so much better for you than coke
<mattyw> thumper, I think so - but isn't the accepted name CharmURL?
<thumper> mattyw: probably
<anastasiamac> thumper: apparently my coffee is not up to wallyworld's standard... so coke it is atm
<thumper> tut-tut
<mattyw> I used to despise decent coffee - it felt like a waste of money
<mattyw> all it took was one trip to Dunedin
<thumper> mattyw: and now you want to buy an espresso machine?
<menn0> jog: thank you for the debugging help
<mattyw> thumper, thinking about it
<mattyw> anastasiamac, I'm basically not too fussed about the name
<jog> menn0, np... the maas upgrade tests should start fairly soon for 2179
<mattyw> anastasiamac, but changing the ordering I think is a small change but very useful
<mattyw> anastasiamac, at least for me :)
<thumper> I was half joking about URI vs URL
<anastasiamac> mattyw: the ordering is a bit of a thing for me, actually..
<anastasiamac> mattyw: i was hoping to group local and exported vars
<anastasiamac> mattyw: m look n and may change in a sec :)
<mattyw> anastasiamac, that makes a lot more sense, to be totally explicit - what confused me was I expected charmStoreSchemaSnippet to be the regex for the whole thing charm url - and then when I read the definition I was suprised
<anastasiamac> mattyw: ic
<mattyw> anastasiamac, ordering based on exported or not makes a lot of sense - I'd be happy with just a comment above local and charm store snippet I think
<mattyw> anastasiamac, although the more I talk about it the more I think it's fine as it is
<anastasiamac> mattyw: let's talk some more than :)
<mattyw> anastasiamac, haha
<anastasiamac> mattyw: well, this area my be confusing
<anastasiamac> mattyw: and I'd like it to b clear from a glance
<anastasiamac> mattyw: there is a block comment above the whole of var block
<mattyw> anastasiamac, ah - I was about to suggest something like that
<anastasiamac> mattyw: explaining what the whole URL (URI ***looking at thumper***) is
<mattyw> anastasiamac, yeah - that's amazing - just land it as is - ignore me :)
<anastasiamac> mattyw: r u sure?
<mattyw> anastasiamac, I'd be tempted to add a comment above validCharmRegEx saying - this is the regex for the whole CharmURL
<mattyw> anastasiamac, but then the actual regex basically says that
<mattyw> anastasiamac, so even that feels redundant
<mattyw> anastasiamac, I'm definitely in bikeshedding territory now though - just land it :)
<anastasiamac> mattyw: k. I'll land as is and might come back to it as needed coz m still planning to head to juju/charm with it before even getting to juju/juju...
 * anastasiamac landed tiny PR 
<mattyw> anastasiamac, tiny PRs are the worst :)
<thumper> :)
<mattyw> waigani, ping?
<waigani> mattyw: pong
<mattyw> waigani, just looking at http://reviews.vapour.ws/r/474/diff/ -> what is OtherState for in storeManagerStateSuite?
<waigani> mattyw: it's the state for another env, I should probably rename it to make that clear
<waigani> mattyw: also that branch is a WIP, I'll be pushing up the latest tomorrow
<mattyw> waigani, that's what I was going to suggest :)
<mattyw> waigani, ok cool
<waigani> mattyw: AND the fam is demanding that I join them for dinner, which I better do unless I want to sleep outside tonight!
<mattyw> waigani, enjoy!
<menn0> jog: the maas upgrade test for 1.21 just passed
<jog> woo hoo!
<jw4> yay
<jw4> how long does it usually wait on the "Attempting to connect to 10.0.30.173:22" line?
<jw4> menn0: can you mark as fix released or does that need to be someone else?
<menn0> jw4: it waits a while.. it's trying to make an API connection as the instance comes up
<jw4> menn0: yeah - it seemed to be several minutes
<menn0> menn0: I think someone from QA is supposed to do it. jog?
<jog> jw4, menn0, in this case it's waiting for MaaS to boot a machine... usually around 10 minutes
<menn0> jw4: that's what I was seeing while manually testing with maas
<jw4> jog: I see
<jw4> menn0: cool - so you were testing your changes on the same hardware that's running the tests?
<menn0> jog: do you know how CI becomes unblocked? does it require a manual step by someone on the QA team or is it automated based on test results?
<jw4> menn0, jog  it also looks like we only have one (or limited) hardware groups for maas?
<jw4> menn0: I think it's automated once the bug is marked Fix Released, but I could be wrong
<menn0> jw4: yeah I was using the host that Jenkins uses for MaaS tests (on KVM)
<jw4> menn0: interesting.  Cool, but surprising
<jog> menn0, I believe fixed-released will unblock
<menn0> jw4: suprising?
<menn0> jog: it's a shame that the "Fix Released" has 2 meanings
<menn0> s/ the//
<menn0> oh well
<jw4> menn0: I guess setting up a maas environment isn't trivial - but it seems like while you were working on finfolk none of the CI tests could run
<jog> err actually fixed-committed
<jw4> jog: I don't think fixed committed will unblock CI?
<jog> jw4, we're working on fixing that... finfolk was upgrade last week, so we can run multiple environments
<menn0> jw4: that's what sinzui told me to do :)  he disabled one of the top level CI jobs
<jw4> jog, menn0 I see
<menn0> jw4: the bug needed fixing and that was the fastest way to get it sorted
<jw4> menn0: well (relatively speaking) it WAS lickety split fast
<menn0> jw4: i'd like to get my machine set up to do MaaS on KVM locally
<jw4> menn0: yeah me too
<menn0> jog: yeah I don't think Fix Committed alone is enough to unblock CI
<jog> it's also possible to downgrade the bug from critical to high and it will unblock
<menn0> jog: it's still blocked now and I marked this ticket as Fix Committed quite some time ago
<menn0> jog: there must be something else to it
<jw4> menn0, jog : I bet if you mark it as fixed released it'll unblock
<jw4> menn0: maas-upgrade-trusty-amd64 looks set to pass momentarily too
<menn0> jw4: I think you're right but is that actually the correct process?
 * jw4 shrugs 
<menn0> woot!
<jw4> that's where I'm lost too
<jog> shall we wait for the second upgrade test to pass... there are two mass tests one for devel (which already passed) and one for stable maas
<jog> the upgrade is actually going on now
<jw4> jog, yeah - the second one is the one I'm willing on as we watch :)
<jw4> woot
<menn0> jog: so when do the maas upgrade tests for master run?
<jog> when a commit is picked up from that branch
<jog> menn0, did you already apply this fix there?
<jog> ah yes it looks like you did
<menn0> jog: yep I did. I merged them one after the other.
<menn0> jog: i'm about to EOD (and I imagine you were supposed to have quite some time ago)
<jog> menn0, it's building now http://juju-ci.vapour.ws:8080/job/build-revision/2180/console
<menn0> jog: ok cool
<jog> nice and we have a blessed build for 1.21
<jog> http://reports.vapour.ws/releases/2179
<menn0> jog: \o/
 * menn0 is EOD
<jw4> FWIW sinzui, mgz_, et. al. - I believe https://bugs.launchpad.net/juju-core/+bug/1403200 has passed all tests and deserves to be marked fix released
<mup> Bug #1403200: maas upgrades do not complete <ci> <maas-provider> <regression> <upgrade-juju> <juju-core:Fix Committed by menno.smits> <juju-core 1.21:Fix Committed by menno.smits> <https://launchpad.net/bugs/1403200>
<mattyw> davecheney, ping?
<mattyw> davecheney, you know what - cancel that and ignore me forever
 * mattyw needs to read docs more carefully
<jam1> morning axw and wallyworld, how are you guys doing?
<jam1> axw	wallyworld sorry, keep getting dc here if you ansnwered
<anastasiamac> jam1: axw is off until Jan, I think
<anastasiamac> jam1: wallyworld is off for the day ;)
<anastasiamac> jam1: wallyworld will b back tomorrow
<anastasiamac> jam1: did u get my last msgs about axw and wallyworld?
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Bug reports: https://bugs.launchpad.net/juju-core/
<dimitern> CI no longer blocked
<dimitern> previously failed PRs re-queued for merging
<jam1> anastasiamac: yes, apparently you didn't get mine:
<jam1> jam1
<jam1> 09:05
<jam1> anastasiamac: thanks, looking at the calendar it looks like both of them are off today
<anastasiamac> jam1: yes, b oth r off today
<anastasiamac> jam1: and ian is back tomorrow :)
<dimitern> menn0, hey are you around?
<menn0> menn0: kinda :)
<dimitern> menn0, :)
<dimitern> menn0, so your fix worked
<dimitern> menn0, thanks for the quick response
<menn0> dimitern: no problems.
<menn0> dimitern: is it the best fix though?
<dimitern> menn0, I don't know about the best, but it's fool-proof at least
<dimitern> menn0, I'll propose a slight fix to change the ordering of addresses returned by maas's instance.Addresses method
<dimitern> menn0, which will make it slightly faster and in your patch the loop will do a single iteration most of the time
 * dimitern needs to step out for a while
<menn0> dimitern: that sounds good
<menn0> dimitern: that loop doesn't get called that often and there's not going to be huge numbers of addresses to check through so I don't think performance is much of an issue
<jam1> hi axw
<axw> jam1: heya
<jam1> mark's in another discussion right now, so I've got some time if you want to give/get feedback on anything
<axw> jam1: I have only just started looking at comments, nothing really controversial
<axw> I really don't like count,size but maybe it's just me
<jam1> man, I wish I could use VIM to edit Google docs :)
<jam1> axw: so what mark really likes is clean, easy to read syntax
<jam1> and he feels that : an x, etc add a lot to how hard it is to read a given string
<axw> jam1: my take on it is that the number doesn't mean anything when you see it first. so then you have to go digging into documentation, rather than it being obvious in the first case (Nx being a fairly universal way of representing a multiplier, I think). but admittedly it doesn't work when you don't have a size
<axw> jam1: glad to see NFS out of scope :)
<axw> jam1: "pool" is just the new term for "source"?
<axw> I don't recall there being talk of pools previously
<mattyw> dimitern, ping?
<dimitern> mattyw, hey
<jam1> axw: pool is being explicitly fleshed out as a way to start passing extra parameters into the system, without overloading the "âstorage" parameter.
<axw> jam1: yeah, just read over that section a bit more. I like it.
<axw> jam1: any general feedback/news before I head off?
<jam1> axw: I think we're pretty happy with what we've gotten to, and I'm just trying to make sure the current doc is consistent
<jam1> axw: we're soliciting feedback at this point (from maas, antes, etc)
<axw> jam1: cool
<axw> alright, I'm going to go have a holiday then ;)
<axw> jam1: thanks, ttyl
<jam1> axw: enjoy
<voidspace> TheMue: dimitern: I'm going to be a few minutes late to standup, sorry
<dimitern> voidspace, ok, np
<TheMue> voidspace: ok
<dimitern> mgz_, hey, do you know when 1.21-beta4 is due?
<jam1> dimitern: I'm pretty sure it was due at least a week ago
<jam1> Our original promise was 1.21 on Nov 15
<jam1> which we are *way* past.
<dimitern> jam1, Oh, I see - well with the api-endpoints fix landed it can be release now
<dimitern> jam1, although during my live testing I discovered an issue fixed on master and not backported to 1.21 which is important
<dimitern> jam1, I'll file a bug for it and have a chat with sinzui should 1.21-beta4 wait for it
<jam1> dimitern: sounds like something that should block, and you've got a couple hours before mgz/sinzui would possibly build a 1.21-beta4 release :)
<jam1> dimitern: I'm happy for you to delegate that backport, but if you've found something serious, we should be serious about it.
<dimitern> jam1, right, now's the time then
<dimitern> jam1, the issue is apt-get retrying logic is faulty - we're calling cmd.CombinedOutput more than once, which errors out after the first call as Stdout is already set
<jam1> dimitern: sounds like a real, but not too hard to fix, bug, rigthH?
<dimitern> jam1, the fix is in juju/utils/apt, so 1.21 needs to (carefully - as there are about a month of changes in utils since) start using a newer utils
<jam1> or we backport to what they are currently using
<jam1> yes, it sucks, but it might be less mental overhead
 * jam1 heads to lunch
<mgz_> dimitern: yeah, beta4 is overdue, we're trying to release it currently - have got a good rev after your fix backport
<dimitern> mgz_, there's an issue I discovered during my live tests - apt-get retry logic is not working
<mgz_> do you have an idea when it regressed?
<dimitern> mgz_, which is already fixed on master, but not backported to 1.21
<dimitern> mgz_, I know as I fixed it in juju/utils/apt, but 1.21 uses an earlier rev of utils
<mgz_> well, certainly backport
<dimitern> mgz_, should we hit the red button until this lands?
<mgz_> but is this a new breakage that wasn't in beta3?
<dimitern> mgz_, let me check
<dimitern> mgz_, it was broken since at least alpha3 (or beta2 - not quite sure; the commit log is ambiguous)
<mgz_> okay, so I think we try to get your fix for this beta, but it's not the end of the world if we don't
<dimitern> mgz_, scratch that - alpha3 is more likely
<dimitern> mgz_, ok, I'll file a bug then and target it
 * dimitern thinks *everyone* should rebase and merge minor commits before they end up in master
<dimitern> or at least be aware they will end up on master and use helpful commit logs - sifting through like 30 commits like "fix dependencies.tsv", "update dependencies.tsv" or "add dependencies of dependencies to dependencies.tsv", are *not* helpful at all to point to *what* changed
<mgz_> thanks dimitern
<dimitern> mgz_, there's a pre-existing bug 1394524 which I now retargeted for 1.21-beta4
<mup> Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <bootstrap> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1394524>
<jw4> ericsnow: ping
<wallyworld> jam1: sorry, was away today but am online for a short time now
<natefinch> fwereade: was there a decision about what to do about exposing zones to charms?  Are we just going to let charms set their zone in their relation data the old fashioned way?
<fwereade> natefinch, ah, sorry
<fwereade> natefinch, we should certainly expose it, but I don't think there's any reason to dump it into relation data by default
<fwereade> natefinch, those that need it can add it
<fwereade> natefinch, and personally I would prefer to expose it via $JUJU_AVAILABILITY_ZONE than by tacking it onto unit-get
<fwereade> natefinch, (and IMO we should not expose lists of zones at this stage -- I'm willing to hear proposals, but the ones I've seen have not been adequate )
<natefinch> fwereade: agree on list of zones. There seemed to be no need for that.
<natefinch> fwereade: how about exposing zone of related units?  I think that was in the proposal too, so you can see what zone your DB is in, for example.
<fwereade> natefinch, strong -1 to that
<fwereade> natefinch, zone-scoped relations would be kinda cool
<fwereade> natefinch, but they also bump up against the yuckiness of local-scoped non-subordinate relations
<fwereade> natefinch, ie they have exactly the same opaque failure modes
<fwereade> natefinch, and we should figure out how to do them *both* right
<fwereade> natefinch, *if* charms want to put that info over their relations, ofc we can't stop them
<fwereade> natefinch, exactly the same in peer rels and pro/req rels
<fwereade> natefinch, but I don't think it's something we want to make into a feature
<natefinch> fwereade: ok
<natefinch> fwereade: that sounds good.
<natefinch> fwereade: so the spec is now - simply expose zone via $JUJU_AVAILABILITY_ZONE and that's it?
<fwereade> natefinch, I think that's the MVP, yes ;)
<natefinch> fwereade: ok :)
<sinzui> natefinch, do you have a minute to review http://reviews.vapour.ws/r/650/
<natefinch> sinzui: ship it!
<sinzui> thank you natefinch
<natefinch> wwitzel3: 1:1 in moonstone?
<ericsnow> jw4: pong?
<jw4> ericsnow: morning :) - Hey I've addressed all your issues on PR 616, with two issues asking for your agreement to drop in favor of a TODO : http://reviews.vapour.ws/r/616/
<jw4> ericsnow: care to take a quick gander and drop or object?
 * ericsnow takes a look
<ericsnow> jw4: thanks so much for addressing my concerns.
<jw4> ericsnow: thanks for raising them :)
<ericsnow> jw4: I'm fine with dropping the first one and while I'm not convinced on the second one I guess I'm okay with dropping it for now too
<ericsnow> jw4: what's the concern with using IsolationSuite
<ericsnow> jw4: it's not like the mongo suite or something :)
<jw4> ericsnow: I think you make a good point in your comments.  I was hesitant to pull in a big suite, but I think you're right - IsolationSuite is okay
<jw4> ericsnow: I'll do that and clean up the pr and ping you again
<ericsnow> jw4: yeah, if you look at the code, it doesn't add much but what it does add is super helpful
<ericsnow> jw4: thanks!
<jw4> ericsnow: thanks too
<ericsnow> jw4: glad to do it
<jw4> gah - I missed the window while CI isn't blocked - teh suk
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1403546
<sinzui> natefinch, can you find someone to look into bug 1403546
<mup> Bug #1403546: cannot get environment config: invalid series vivid <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1403546>
<natefinch> oh FFS
<natefinch> sinzui: the bug description has a typo that makes it hard to understand
<natefinch> "As vivid really in in streams, hosts that don't know about vivid in ubuntu.csv must still work."
<natefinch> should that say "vivid really is in streams"?
<sinzui> natefinch, yes, I will fix it
<natefinch> sinzui: why do we have vivid in streams but not in ubuntu.csv?  ubuntu.csv was how we were going to support new series
<natefinch> wait... I have vivid in ubuntu.csv
<sinzui> natefinch, That data is delivered to hosts in updates. note everyone get series knowledge that the same time
<sinzui> natefinch, since vivid is in devel, we can expect a period of months where we make agents, (Lp did), but the host machine doesn't have the release info yet
<natefinch> this is quite aggravating, since the whole point of using ubuntu.csv was to avoid this problem.  Do you have an idea on how we can fix this?
<sinzui> natefinch, an entry in ubuntu.csv is canonical (in the real sense of the world), and other series for win, osx, centos, or ubuntu must be accepted.
<sinzui> natefinch, ubuntu.csv is really about knowing the dates of when series expire, not about every series that will exist
 * sinzui wonders if the recent failures to build osx clients are the same reason
<natefinch> sinzui: the main problem is translating a random series to an OS
<sinzui> yeah
<sinzui> natefinch, in the case, if we made a agent, then I think juju should accept it, maybe ignore it. I can run vivid container on these machines though, so the user might want to expect to use the unknown series.
<ericsnow> perrito666: standup?
<perrito666> ericsnow: wjy not_
<perrito666> sinzui: Ill take a look
<sinzui> perrito666, thank you
<jam1> fwereade: natefinch: do we have a spec about default-hook ?
<fwereade> jam1, 90% sure natefinch wrote one, will have a quick look
<natefinch> looking
<fwereade> jam1, natefinch: sorry, can't find it
<fwereade> jam1, natefinch: bloody google ;)
<natefinch> jam1, fwereade: I honestly can't remember if one was written...
<natefinch> jam1, fwereade: does anm email thread count?  search for "First customer pain point pull request - default-hook"
<fwereade> natefinch, yeah, that was what I just found
<jam1> natefinch: fwereade: did it land in 1.21? I see it listed in the release notes, but I don't see it in the code yet
<natefinch> jam1, fwereade: from Aug 15
<fwereade> natefinch, afraid it mostly devolved into discussion of something-changed
<natefinch> jam1. fwereade: it did not land... it shouldn't have been in the notes
<natefinch> jam1, fwereade: we decided it required juju-min-version (aka feature flags) first
<natefinch> jam1, fwereade: which moonstone will get to sometime after the holiday break
<alexisb> jam1, why do you ask
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: hey, hi
<voidspace> dimitern: sorry to bother you so late
<voidspace> dimitern: the topic of filling in AllocatableIPHigh and Low for maas
<voidspace> dimitern: I've fixed all the other issues from review
<dimitern> voidspace, np, I have to wait for a meeting anyway :)
<voidspace> dimitern: currently we're using the MaaS networks api call to get subnet info
<dimitern> voidspace, right
<voidspace> dimitern: this *doesn't* include static / dynamic range info
<voidspace> dimitern: http://maas.ubuntu.com/docs/api.html#networks
<voidspace> dimitern: nodegroups does
<dimitern> voidspace, aw ffs..
<dimitern> voidspace, true, so we need to implement that as well
<voidspace> dimitern: so is it ok to use nodegroups?
<voidspace> dimitern: I can pull the info out of a nodegroups call easily enough
<voidspace> dimitern: although we can't filter nodegroups by instance id like we can networks
<dimitern> voidspace, I think we have to use it - that's the only way to get the static range
<voidspace> dimitern: so subnets should lose the instance id paramter
<voidspace> dimitern: ok, so I'll make those changes
<voidspace> dimitern: follow-up branch or on this branch?
<dimitern> voidspace, cheers!
<dimitern> voidspace, follow-up is fine
<voidspace> dimitern: ok
<voidspace> dimitern: so the current branch is ready I think
<voidspace> dimitern: I changed the XXX to a TODO so I could land it
<dimitern> voidspace, let me have a final glance
<voidspace> dimitern: cool
<voidspace> dimitern: XXX -> TODO just landed now
<voidspace> dimitern: I'm going for coffee, bbiab
<dimitern> voidspace, ok
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  1403546 1403596
<sinzui> natefinch, ericsnow sorry, new testing shows an other regression related to cTim for os x 1403596
<sinzui> bug 1403596
<mup> Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1403596>
<jw4> natefinch, sinzui : docker fixed a similar bug here https://github.com/andrewsmedina/docker/commit/8b2a7e35c35f894dca0795a4fde9ec0cfe04ce43
<jw4> natefinch, sinzui looks like it's just separate implementations for darwin vs. others
<sinzui> thank you jw4
<dimitern> voidspace, LGTM +2 very small suggestions
<jw4> sinzui, natefinch I'll look at this bug but I'm not familiar with the code so if anyone else can jump on it that's fine  :)
<wwitzel3> anyone know how the default instance type for a provider is selected?
<natefinch> wwitzel3:  I think we have logic that just picks the least expensive of known options
<voidspace> dimitern: ok
<voidspace> dimitern: my wife has had to take our next door neighbour to hospital, so I'm on babysitting duty
<voidspace> dimitern: I'll finish this later on
<dimitern> voidspace, np, take your time
<jcastro> rick_h_, do you happen to know luca's plan for the new videos page on jujucharms.com?
<rick_h_> jcastro: I know we're supposed to pull them from insights at some point. I've not seen the feed yet
<rick_h_> jcastro: now that's just to pull videos for the community page, I'm not aware of a straight 'videos page'.
<jcastro> right
<jcastro> I know it's generated
<jcastro> afaict the "new videos page" is just a generated feed of videos tagged video in wordpress
<rick_h_> jcastro: it's on the todo with UX/web team next year along with deprecating out the juju.ubuntu.com domain and such. Most of them are out for the holiday already so not managed to move it forward.
<jcastro> yeah I was just wondering where it stood on the list.
<jcastro> like, pre or post-sprint, etc.
<rick_h_> top of the new year list.
<rick_h_> pre sprint
<rick_h_> sprint is 19th and that's for different stuff
<jcastro> not bad, I like how you roll
<rick_h_> I want to kill of juju.ubuntu.com and manage.jujucharms.com (front end) first of next year
<rick_h_> was hoping to have it done pre-break but didn't make it
<jw4> sinzui, natefinch http://reviews.vapour.ws/r/655/
<jw4> fixes ci blocker bug 1403596 ^^
<mup> Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1403596>
<sinzui> thank you very much jw4
<jw4> sinzui: yw
<jw4> OCR PTAL : http://reviews.vapour.ws/r/655/
<perrito666> sinzui: upgrade juju for local is something that takes a lot of time?
<dimitern> ericsnow, perrito666, http://reviews.vapour.ws/r/656/ PTAL - backport the fix for bug 1394524 for 1.21 - it has some changes I'd like to pass by you
<mup> Bug #1394524: juju/utils/apt retrying logic is poorly tested and can fail the second time <bootstrap> <juju-core:Fix Committed by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1394524>
<sinzui> perrito666, no, usually less than 5 minute
<perrito666> mmm, let me wipe all this
<perrito666> sinzui: to replicate I am juju bootstrap --series=precise --upload-tools and then doing an upgrade, I am in the right path_
<perrito666> ?
<perrito666> sinzui: ok, I am not getting a precise series on local :(
<sinzui> perrito666, :( you are doing what i do
<sinzui> perrito666, I don't specify series
<sinzui> since we saw the issue with trusty too on a machine that didn't know about vivid, may be you want to just try trusty
<sinzui> perrito666, oh, I am confused now, since you are working with tip you are running juju from in the tree to upgrade right? isn't juju making the agent to upload?
<perrito666> sinzui: I believe we are both confused here
<perrito666> I am working with master tip, in an utopic machine, which most likely knows of vivid?
<perrito666> sinzui: http://pastebin.ubuntu.com/9553381/
<perrito666> this is what I get from a bootstrap with local
<sinzui> perrito666, That looks right, but since this issue is about upprades, I think you want to bootstrap 20 or 21, then call upgrade. I assume during upgrade that streams is checked
<perrito666> sinzui: makese sense, ill get 21
<sinzui> perrito666, you can remove/change the vivid linne in /usr/share/distro-info/ubuntu.csv
<perrito666> sinzui: that, is easier
<sinzui> perrito666, I learned that trick when we first added trusty and several QA machines didn't know what to do.
<voidspace> right, signing off
<voidspace> g'night all
<perrito666> sinzui: still cant, life hates me
<perrito666> sinzui: does this fail only on local?
<jw4> who is OCR today?
<sinzui> perrito666, might be, I suspected the localhost's dist_info was where vivid was absent
<thumper> perrito666: morning
<thumper> perrito666: how's the vivid blocker?
<perrito666> thumper: morning
<perrito666> thumper: trying to reproduce it with half brain and to patch it without reproducing it with other half
<thumper> works for me
 * perrito666 knows thumper is patting with the foot like someone in line for the mans bathroom
<waigani> yep
<jw4> thumper: the other blocker is just waiting for review: http://reviews.vapour.ws/r/655/
<jw4> thumper: hint hint
<thumper> jw4: yeah... we know
<thumper> and are talking about it
<jw4> :)
<jw4> thumper: fwiw it's essentially the same fix that docker did for a similiar issue in their code
<katco> wallyworld: hey can you ping me when you get on?
<waigani> jw4: reviewed
<jw4> waigani: thanks
<jw4> waigani: updated - reviewboard doesn't quite know what to do with the file added and then removed within the review cycle :)
<waigani> jw4: so there is no unix file any more, right?
<jw4> waigani: correct
<waigani> jw4: lgtm
<jw4> waigani: thanks
<waigani> np
<menn0> jw4: hold the phone!
<thumper> jw4: if you use the filename suffix, you don't need the build directives
<menn0> jw4: what thumper said
<jw4> haha
<menn0> jw4: the build directives currently don't match the filenames
<jw4> menn0, thumper they should?
<menn0> jw4: you don't need them anyway, the filenames create implicit build tags
<thumper> jw4: easier to just not have them
<jw4> thumper, menn0 : kk - reduces chances of inadvertent conflict
<jw4> thumper, menn0 : will remove
<menn0> jw4: at any rate, the current build tags are confusing
<thumper> agreed
<menn0> jw4: would be better to use positives instead of negatives (i.e. +build linux ; +build windows ; +build darwin
<menn0> jw4: but just remove them...
 * menn0 stops talking
<jw4> menn0: makes sense.  I haven't used build tags before - I confess to the cargo cult
<menn0> jw4: here's the docs: http://golang.org/pkg/go/build/#hdr-Build_Constraints
<jw4> menn0: thanks
<tvansteenburgh> hey guys, i need a script that will collect all unit logs if/when a deployment fails (unit goes to error state). anyone have such a thing?
<bodie_> does anyone know why charm master is 8 commits ahead, 153 commits behind charm v4?  I assumed master was tip
<menn0> tvansteenburgh: I don't but Juju's CI tools do parsing of status and log capturing
<menn0> tvansteenburgh: you could steal some bits from there
<menn0> tvansteenburgh: https://launchpad.net/juju-ci-tools
<thumper> jw4: just added an extra shipit
<jw4> thumper: woot
<tvansteenburgh> menn0: thanks!
<thumper> bodie_: no, master is the old one, and v4 new
<thumper> bodie_: some gopkg.in thing that I'm personally not a fan of
<thumper> but there ya go
<bodie_> I see
<bodie_> I don't think it must be that way; gopkg should point to versions as they are tagged in the repo
<menn0> tvansteenburgh: there's certainly a lot more there than you need and it's probably coupled in inconvenient ways but hopefully there's some useful bits
<bodie_> my understanding is that normally you'd have your master ahead of your tagged versions
<thumper> bodie_: gopkg can point to tags or branches
<bodie_> well yes
<jw4> bodie_: and isn't that what you're seeing?"
<thumper> and those in charge of the charm repo decided to use branches
<jw4> bodie_: master is 8 commits ahead of v4?
<jw4> bodie_: oh - i didn't read the rest - 153 behind
<bodie_> it looks to me like master was abandoned in favor of working off v4, but I'm not sure if there's an accepted way we're working with charm.  in the meantime I'm going to work off v4...
<jw4> sounds like v4 should just be merged to master periodically?
<bodie_> *shrug* I'm not sure what the divergence is about; it's possible the extra commits should be part of v4, it's possible they shouldn't
<jw4> no, I meant merging the other way
<jw4> the 153 extra commits in v4 maybe should be merged  into master
<bodie_> maybe there's a reason they were abandoned, I really don't know
<bodie_> I think that was around the time the versioning in charm was being nailed down
<perrito666> thumper: menn0  wanna give me some light? I think I am around the problem but not yet sure
<thumper> sure, what do you need?
<perrito666> I have some knowledge gaps that you might fill :) here is what is going on, according to me:
<perrito666> CI uses 1.20.10.1 to bootstrap a local env
<perrito666> using upload tools
<perrito666> so you have a local env with jujud 1.20.10.1 that, if I am right, is not aware of vivid
<perrito666> the machine though already has vivid in ubuntu.csv
<perrito666> CI triggers an upgrade
<perrito666> something in the upgrade (here is the gap) calls SeriesVersions with "vivid" all blows
<perrito666> If I use tip for this it does not happen
<perrito666> and I am now about to test with the tip of 1.20
<thumper> perrito666: version/supportedseries.go
<thumper> perrito666: vivid is in master, is it in the 1.21 branch?
<thumper> is it in 1.20?
<menn0> perrito666, thumper: just caught up
<perrito666> mmmm in 1.21 is in ubuntuSeries but not in seriesVersions
<perrito666> I wonder if that is right
<jw4> sinzui, mgz_ fix for bug 1403596 is in - not sure which tests need to pass to mark "Fix Released"
<mup> Bug #1403596: OSX build broken by stat.Ctim undefined <ci> <osx> <regression> <juju-core:Fix Committed by waigani> <https://launchpad.net/bugs/1403596>
<thumper> jw4: you don't mark it fix released
<thumper> jw4: also needs to be back ported to 1.21
<jw4> thumper: is that something I can/could do?
<thumper> jw4: yes :-)
<jw4> thumper: just another pr against 1.21 branch?
<thumper> jw4: start with the 1.21 branch
<sinzui> jw4, thumper http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/build-osx-client/ is the test and i am fine with anyone marking the bug for 1.22 fix release when we see a pass with :master:
<thumper> and cherry pick your fix
<sinzui> thumper, the job passes for 1.21.
<thumper> oh
<sinzui> we released with what it built in fact
<jw4> thumper: thanks for the tips !
<thumper> sinzui: oh, just master?
<sinzui> yep
<thumper> jw4: not needed for 1.21 apparently
<menn0> thumper: the OS X issue was only just introduced as part of work on backups
<menn0> thumper: methinks
<jw4> sinzui: cool - does that CI build kick off automatically?
<thumper> perrito666: I'm looking at pr 1216
<sinzui> jw4, it will
<jw4> sinzui: kk
 * jw4 goes to unload groceries for wifey
<thumper> sinzui: re bug 1403546
<mup> Bug #1403546: cannot get environment config: invalid series vivid <ci> <local-provider> <regression> <vivid> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1403546>
<thumper> sinzui: this is an upgrade from what?
<sinzui> 1.20.10 thumper
<thumper> sinzui: I don't think this effects master, but the 1.20 branch
<perrito666> thumper: I did too but if I get it right that only should blow if that is actually runing a vivid
<thumper> the client is trying to upload the tools, but the server goes "vivid what" ?
<sinzui> thumper, you don't have a tie machine, you cannot change the fact that ubuntu only has old jujus
<thumper> perrito666: no...
<perrito666> thumper: that is what I just said :p
<thumper> sinzui: I want a time machine
<perrito666> sinzui: mm, a tie machine, that sounds very useful, especialy in parties
<sinzui> thumper, perrito666 I can put vivid into the ubuntu.csv and run the test again (if ci isn't building again)
<thumper> ...
<thumper> sinzui: you are right, we should be more careful about what we update / upgrade
<thumper> I'm just trying to work out what?
<thumper> sinzui: can you add to the bug report what is in the ubuntu.csv on the server, and the version of the server failing?
<sinzui> thumper, sure, I can also make the trusty machine have 1.20.11 from proposed
<sinzui> ubuntu proposed I mean
<thumper> sinzui: while this is technically a regression, it is not one generated by code, but time
<thumper> well
<thumper> the code that uploads tools has probably changed in the last six months somewhat
<thumper> which is the last time we had to deal with this
<thumper> sinzui: the host is running on which series?
<perrito666> well we actually fixed this
<thumper> sinzui: also, machine-0 log from the server would help
<perrito666>  I know, it sounds like I am saying something idiotic
<perrito666> sinzui: thumper  I just compiled 1.20 tip
<sinzui> thumper, we have a precise host and a trusty host
<perrito666> bootrstraped local with it uploading tools
<perrito666> compiled master tip
<perrito666> upgraded
<perrito666> worked like a charm
<sinzui> and obviously they didn't fail two days ago
<thumper> sinzui: I'm following that error back to the source
<thumper> sinzui: and things don't add up
 * thumper is a little confused
<sinzui> thumper, I just updated the trusty machine to 1.20.11 which is from Ubuntu trusty proposed.
<thumper> sinzui: the error originates from the method LegacyStorage
<thumper> ...
<thumper> I'm reading the wrong code
<thumper> that's why I'm confused
 * sinzui runs with --debug with the version ever Ubuntu user will get in a week
<perrito666> thumper: are you reading master or 1.20?
<thumper> perrito666: I was reading master, hence confusion
<perrito666> at least in master that error is spit by LegacyStorage which is never called in local
<perrito666> yeah, happened to me
<perrito666> I am trying to see if we are doing something new in tools uploading that might trigger this
<perrito666> I am suddenly suspicious of this snippet in master http://pastebin.ubuntu.com/9554502/
<sinzui> surely during upload, streams is checked, and the streams contain vivid, but the machine doesn't know about them. the error is probably in streams code
<perrito666> I am really starting to hate prereqs
<thumper> perrito666: I've found the part in 1.20 I think
<thumper> perrito666: right, the client thinks they are supported but the server doesn't
<perrito666> thumper: which of the 3 parts that yield the exact same error?
<thumper> state/apiserver/tools.go line 172
<perrito666> thumper: the server gets vivid from the uplading client?
<thumper> perrito666: correct
<perrito666> mm, there is a comment from william on the uploading function that says someting like this might happen
<sinzui> thumper, perrito666 looky at the result when I upgraded one of the machines to 1.20,11 http://juju-ci.vapour.ws:8080/job/local-upgrade-trusty-amd64/
<sinzui> a pass
 * perrito666 wonders what is a safe bet solution there
<perrito666> sinzui: off course
<perrito666> https://github.com/juju/juju/blob/juju-1.20.11/version/ubuntu/supportedseries.go
<perrito666> 11 adds vivid
<sinzui> yep so it does
<sinzui> so good news for ubuntu when this version moves from proposed to updates
<thumper> sinzui: so... now what?
<sinzui> thumper, I am not sure this didn't fail 2 days ago before the mad rush to land code
<sinzui> so something changed to break older jujus from upgrading
<thumper> yeah, I can't see what though...
<perrito666> sinzui: I have scanned everything going remotely near versions and nothing seems to have that effect
<perrito666> I see only one way to find out
<sinzui> :/
<thumper> sinzui: are we sure that the versions that were passing before were using the same old 1.20.x version?
<thumper> and not 1.20.11?
 * thumper is reading the previous passing test
<thumper> 1.20.10.1
<thumper> sinzui: you went from having passing test upgrading from 1.20.10.1 to 1.21-beta4
<sinzui> yep
<thumper> to failing tests upgrading from 1.20.10.1 to 1.22-alpha1
<thumper> we don't support 1.20 -> 1.22 upgrades
<sinzui> no
<thumper> so why are you testing them?
<sinzui> remember that jobs test all version that you commit too
<thumper> no I don't remember
<sinzui> thumper, you need to read the side to learn the branch and revision tested
<thumper> why are we running this job when it doesn't make sense?
<sinzui> this is http://juju-ci.vapour.ws:8080/job/local-upgrade-trusty-amd64/666/ == be01edcb
<sinzui> thumper, This ensures the same test passes for all jujus. the input is a the version of juju under test
<thumper> sinzui: sure, this test makes sense for 1.21, but not for 1.22
<thumper> now it fails for 1.22 and it is a problem?
<thumper> I don't get it
<thumper> it seems that 1.21 isn't uploading vivid
<thumper> but 1.22 is
<thumper> 1.20.10 doesn't know about vivid
<thumper> so upgrades to 1.22 (which is unsupported) now fail
<sinzui> thumper, juju removed the rules to control how it hops to a version during upgrade...I believe you removed them when you added alphas to versions
<thumper> we did
<thumper> I have hoped that this would work
<thumper> but this shows that we still have issues
<sinzui> thumper, 1.18 will only let you go to 1.20, 1.20 will do what every you tell it
<thumper> now... we can fix this
<thumper> but I wonder how much it is worth it to fix
<thumper> how far we wish to backport
<thumper> I propose the following idea:
<sinzui> no backport to 1.20...
<sinzui> it is dead to me and we cannot make people use it
<thumper> sure...
<thumper> in which case 1.20 -> 1.22 should not be supported
<sinzui> thumper, IS is using 1.20.10. they plan to hop to 12 then 14
<perrito666> sinzui: that is ok
<thumper> the fix is to have the tools processing not fail on tools it doesn't know about
<thumper> just to drop them on the floor
<perrito666> 14->22 works
<sinzui> yep
<sinzui> I agree
<thumper> sinzui: but that fix can be back ported to 1.21
<thumper> but not 1.20
<thumper> so we can't support jumping versions from 1.20 to 1.22
<thumper> hopefully with this fix in place, we shouldn't hit this next time
<sinzui> thumper, just ensure juju doesn't skip minor version?
<thumper> no... that is not what I'm proposing
<perrito666> thumper: what exactly are you proposing?
<sinzui> perrito666, from ubuntu/canonical's perspective, every host should be accepting updates. We can test the precise host and see if it passes
<sinzui> perrito666, from juju's perspective skipping minor versions is unpredictable, and juju should be taught to say no
<sinzui> perrito666, and juju can also claim the issue is fixed by upgrading to the lastest 1.20...then hoping to 1.22
<perrito666> sinzui: there is the point, when you say "by upgrading" you mean that we advice that and declare this issue solved or you are thinking on something else?
<perrito666> be aware that at this point I have a very interesting headache so be gentle with your answer
<sinzui> perrito666, prove the two work arounds, add them to the bug, then mark the bug as wont fix
<sinzui> perrito666, because the affected users are those with stale ubuntu packages or stale juju packages.
<jw4> sinzui: should 'build-osx-client' have kicked off by now?
<sinzui> perrito666, we do need to prove both conditions. we proved juju.20.11 is fixed
<perrito666> the two workarounds are 1.20.10->1.20.14->1.22 and 1.20.10->1.21->1.22?
<sinzui> jw4, I disabled CI so that we could explore how to fix perrito666's bug
<jw4> sinzui: ah; I see.
<sinzui> perrito666, that is the juju work around.
<sinzui> perrito666, lets take 5 minutes to test the precise machine with a current dist-info-data
<sinzui> then we can let jw4 end his day with a victory
<jw4> sinzui: hehe - I have 5 pending PRs I wanna land before I leave on vacation tomorrow
<perrito666> jw4: I take you are not planning to sleep
<jw4> perrito666: lol
<sinzui> jw4, I leave in 40 minutes
<jw4> sinzui: and code freeze for 1.22 is Friday right?
<sinzui> yep
<jw4> sinzui: it's after 5pm for you right?  Are you leaving for vacation or until tomorrow o_O
<sinzui> jw4, I am just taking day trips
<jw4> sinzui: I see
<sinzui> I don't like leaving my kitchen or internet
<jw4> sinzui: lol - what do you have google fiber or something?
<perrito666> sinzui: interesting I feel like that for my bathroom
<jw4> perrito666: ROFL <--- almost literally
<jw4> brings a whole new perspective to Google Fiber
<sinzui> jw4, I do have fiber from verizon and no cable. just net
<perrito666> aghh how in the universe do I checkout a tag
<perrito666> ?
<jw4> perrito666: git checkout <tag>
<perrito666> thought so but not working
<jw4> perrito666: do you have the tag in your local repo?
<perrito666> jw4: no I was trying to fetch the one in github
<jw4> perrito666: git fetch --all --tags
<sinzui> perrito666, http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/local-upgrade-precise-amd64/
<jw4> --all probably not needed
<jw4> sinzui: I briefly considered moving to Kansas City when they were selected for Google Fiber
<perrito666> sinzui: that is precise
<perrito666> sinzui: I am now trying the 1.20.10 to somthing else jump
<perrito666> sinzui: ok, we have a different problem
<jw4> waigani: thanks for the email!  Hopefully I can find it in gmail again next time.
<perrito666> sinzui: I just upgraded to 1.22 from 1.20.10
 * perrito666 headbuts the desk
<perrito666> I am seriously over my EOD, anyone interested in taking over this?
<perrito666> otherwise Ill have to go be a family person and return later
 * perrito666 eyes thumper
 * jw4 finds it strangely quiet in here suddenly
<alexisb> perrito666, I can make sure it gets handed off, go!
<jw4> run perrito666 run
 * jw4 smiles nervously at alexisb 
<thumper> perrito666: I got this
<alexisb> thank you thumper
<perrito666> thumper: thanks a lot, see you al tomorrow people
<perrito666> thans alexisb too
<perrito666> cheers
<sinzui> jw4, CI has started testing you revision
<jw4> sinzui: tx
<thumper> sinzui: https://github.com/juju/juju/pull/1216/files definitely caused the upgrade failures
<jw4> woot
<waigani> jw4: np, I used the command just before I read your email, so it was fresh in my memory.
<katco> wallyworld: ping, you here yet?
<wallyworld> katco: sorry, been in meetings
<wallyworld> got another one in 5
<katco> wallyworld: oh no worries at all
<wallyworld> but i am free till then
<jw4> sinzui, waigani can we mark 1403596 fix released yet?  It passed the osx ci build
<katco> wallyworld: i was going to ask for some of your time for some peer-programming
<alexisb> wallyworld, feel free to stump on our 1x1 if you need to chat with katco
<sinzui> I just updated the bug jw4
<katco> alexisb: wallyworld: it's just stupid newbie questions. your call :)
<jw4> sinzui: gracias
<wallyworld> katco: did you want to hook up now?
<katco> wallyworld: yeah def.!
<alexisb> :)
<katco> wallyworld: tanazanite?
<wallyworld> sure
<katco> alexisb: ty so much!
<wallyworld> alexisb: i'll ping you in a bit if you will be around
<thumper> ok, lunch time.. bbl
<alexisb> I will be until about 5 (1.5 hours from now) then I am on kiddo duty until our leads call
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs:  None
<sinzui> thumper, this bug might interest you. maybe you want to say it is a documentation issue if there is no fault https://bugs.launchpad.net/juju-core/+bug/1403165
<mup> Bug #1403165: Cannot destroy-environment with 'juju user add' .jenv file <config> <destroy-environment> <regression> <users> <juju-core:Triaged> <https://launchpad.net/bugs/1403165>
<wallyworld> alexisb: ok, if i'm done i'll ping
<thumper> sinzui: ta
<anastasiamac> m trying to test newly checked-out charm.v4 on my machine and m getting http://pastebin.ubuntu.com/9555369/ what m I miss n?
#juju-dev 2014-12-18
<wallyworld> alexisb: free now if you are
<wallyworld> anastasiamac: looks like you need to pull juju/testing etc to get latest versions
<alexisb> wallyworld, ok, brt
<anastasiamac> this elements that the build contains are in charm.v4
<anastasiamac> but it looks like there is a conflict with gopkg.in/charm.v4 vs my github.com/juju/charm.v4?... have no idea how to resolve it
<anastasiamac> wallyworld: ^^
<anastasiamac> i'll try pulling testing though I cannot c if/how it's related..
<wallyworld> anastasiamac: the error indicates that juju/testing is out of date
<anastasiamac> k. thnx ;)
<anastasiamac> wallyworld: pulled testing but the error for charm.v4 is the same..
<katco> wallyworld: SHAM-WOW! http://reviews.vapour.ws/r/658/
<thumper> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1403689
<mup> Bug #1403689: Server should store tools of unknown or unsupported series <upgrade-juju> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1403689>
<wallyworld> thumper: just finished meeting, thanks, will look
<thumper> np
<wwitzel3> ericsnow: ping, in moonstone
<thumper> ok, I'm turning distractions off and going to try to focus for an hour
<thumper> now if only the kids comply...
 * thumper switches music from random to heavy mix
<mattyw> thumper, morning - mind if this kid distracts you for a moment?
 * thumper looks at mattyw
<mattyw> thumper, I made this small change in juju/utils the other day  -  I'm not sure if it belong there - but as it was small I thought - better to ask forgiveness than permission - what do you think? http://reviews.vapour.ws/r/634/
<thumper> seems reasonable
<mattyw> thumper, do I $$merge$$ utils?
<thumper> I don't remember
<thumper> try it and if the bot doesn't say anything
<thumper> manually do it
<mattyw> thumper, thanks for the help - you can go back to <whatever it was you were doing>
<mattyw> thumper, me again - I don't have permission, can you hit merge for me?
<thumper> done
<mattyw> thanks very much
<jog> wallyworld, around?
<wallyworld> jog: in a meeting, can be with you soon
<jog> I'm considering setting bug 1396099 as a blocker on master, please see my latest comment when you're available
<mup> Bug #1396099: AWS/Joyent/manual/maas: juju deploy error "connection is shut down" <api> <ci> <deploy> <ec2-provider> <joyent-provider> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1396099>
<wwitzel3> so in cloud-init.log I see some log lines that read writing /home/ubuntu/.ssh/authorized_keys .. but when I look in the file, the keys don't match my jenv. Any pointers on where to start poking around?
<jw4> jog: can I send you some clickbait, or interesting wired articles or anything?
<jw4> jog: just trying to buy some time before CI gets blocked
<jog> heh heh
<katco> davecheney: hey just reviewing some of your comments
<katco> davecheney: to maybe save you a bit of time: as this is refactoring, i don't want to change any existing code i don't have to touch
<katco> davecheney: e.g.: eitherState (which i agree is a little strange)
<davecheney> katco: if you don't clean it up now
<davecheney> then when ?
<davecheney> refactoring sounds like the perfect time to clean house
<katco> davecheney: i will be making changes to this area for awhile longer
<katco> davecheney: this piece is just so i can land some leadership functional tests
<katco> davecheney: once that's done, i will be circling back and giving this package some more TLC :)
<davecheney> sgtm
<katco> davecheney: i do appreciate your thoughtful reviews
<katco> davecheney: in fact, if you want to call anything out, but not open it as an issue, i'd love that so i can reference it
<mattyw> folks, the latest version of juju/utils contains a call to errors.UserNotFound https://github.com/juju/utils/blob/master/file_unix.go. But that call doesn't exist
<mattyw> I think we should just return err here - what does everyone else think
<menn0> wallyworld, jog: I wonder if that's the new certupdater work. it can lead to the API server being restarted soon after the machine agent starts up.
<jw4> mattyw: is errors.UserNotFound in a later version of juju/utils?
<jw4> mattyw: can we just update
<menn0> s/work/worker/
<jw4> mattyw: otherwise I'm in favor of just returning err too
<menn0> wallyworld, jog: that issue has certainly been happening a lot in CI lately
<jog> yup, it's been a big problem for us lately
<mattyw> jw4, is in the latest version
<mattyw> jw4, you mean the latest version of juju/errors?
<mattyw> jw4, ah yes, it's in the latest version of juju errors - I thought I'd tried that, but apprently not
<jw4> mattyw: I meant the latest version of juju/utils because I misunderstood you - but I'm glad you found it anyway :D
<ericsnow> davecheney: FYI, I've added a set.Ints (http://reviews.vapour.ws/r/659/) and updated the PortSet patch to use it (http://reviews.vapour.ws/r/617/)
<ericsnow> davecheney: thanks for the nudge
<wwitzel3> ericsnow: nothing yet on why authorized_keys doesn't contain our keys
<ericsnow> wwitzel3: :(
<wwitzel3> ericsnow: I did take care of the autoDelete though
<ericsnow> wwitzel3: sweet
<ericsnow> wwitzel3: I'm pretty sure once the connection issue is resolved we'll be bootstrapping on GCE!!!
<wwitzel3> ericsnow: yeah, seems that way .. I'm going to login manually while the attempting to connect loops are running and add the key to authorized_keys and see if that fixes it
<ericsnow> wwitzel3: sneaky :)
<davecheney> ericsnow: ta
<ericsnow> davecheney: it was easier than expected :)
<wwitzel3> ericsnow: yeah, the cloud-init.log file looks good, it appears to update the auth_keys file for both ubuntu and root
<wwitzel3> ericsnow: but our keys never end up in there :(
<ericsnow> wwitzel3: ?!?
<ericsnow> wwitzel3: where does cloud-init get the stuff it's supposed to add?
<wwitzel3> ericsnow: so far, no luck, I've added the keys, but the Attempting to connect is still just hanging.
<wwitzel3> ericsnow: it is from the jenv for gce
<davecheney> thumper: i was trying to sort out my xmas leave
<davecheney> https://sites.google.com/a/canonical.com/operations/people-and-culture/dashboard
<davecheney> this page is now 404
<ericsnow> wwitzel3: oh, right
<davecheney> where is the calendar that tells us what days we need to claim ?
<thumper> hr somehwere
<thumper> waigani: do you have that link somewhere?
<thumper> waigani: you had it the other day
<ericsnow> wwitzel3: what feeds that data to cloud-init on the new instance?
<thumper> waigani: the christmas leave page
<ericsnow> wwitzel3: I have a feeling it's that metadata :(
<wwitzel3> ericsnow: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
<waigani> thumper: https://sites.google.com/a/canonical.com/operations/people-and-culture/general?pli=1
<thumper> davecheney: ^^^
<thumper> waigani: ta
<wwitzel3> ericsnow: it looks like we are connecting successfully, but that error is resulting in a disconnect
<ericsnow> wwitzel3: ah
<wwitzel3> ericsnow: the keys still aren't getting populated correct, but that error is also preventing us from connecting
<wwitzel3> ericsnow: I'm going to keep swing my bat around in this china shop for a while, I'll let you know what i come up with him the morning
<dimitern> ericsnow, hey
<ericsnow> wwitzel3: k
<ericsnow> dimitern: hey
<wallyworld> menn0: jog: sorry, just finished meeting
<dimitern> ericsnow, can you have a quick look at this please? http://reviews.vapour.ws/r/656/
<ericsnow> dimitern: sure
<jog> wallyworld, just trying to decide what to do about bug 1396099
<wallyworld> when juju starts, it will restart the state server api to accommodate newly known machine addresses
<mup> Bug #1396099: AWS/Joyent/manual/maas: juju deploy error "connection is shut down" <api> <ci> <deploy> <ec2-provider> <joyent-provider> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1396099>
<dimitern> ericsnow, thanks
<wallyworld> jog: if the CI scripts immediately connect to the state server api, they could come undone as the state server api will be restarted very shortly after the state server comes up
<wallyworld> this restart is necessary to accommodate a new server certicicate being generated
<wallyworld> the certificate regeneration is needed to allow https connections over the state server IP addresses
<wallyworld> jog: is it plausible to add a small delay to the CI script?
<ericsnow> wallyworld: how long does it go before restarting after coming up?
<jog> wallyworld, yeah that sounds like what's happening, but if we add a sleep to the test script, customer who are also scripting will experience intermittent connection failures.
<bodie_> could use a quick review on https://github.com/juju/charm/pull/81 if anyone has a few moments :)
<wallyworld> ericsnow: as soon as it learns about the state server machine addresses, not sure of the exact time
 * jog is actually testing a sleep now
<bodie_> a worthy Actions schema format
<dimitern> wallyworld, can't we use the upgrade blocker or something to block deployments until api server cert is regenerated?
<wallyworld> dimitern: it's a change listener, the addresses could change anytime
<davecheney> thumper: ta
<dimitern> wallyworld, hmm right
<wallyworld> dimitern: so before this, any htths connection over the state server ip address would fail
<ericsnow> wallyworld: I've see issues with the API client used in backups commands being good for only one request (and then the connection shows up as disconnected), so perhaps that's related
<ericsnow> wallyworld: ah
<wallyworld> ericsnow: the backup client, if run after the state server has fully come up, will not be affected by this
<ericsnow> wallyworld: yeah, that's what I gathered from what you just said :)
<wallyworld> well, by fail, i mean certificate verification would fail
<ericsnow> dimitern: LGTM
<dimitern> ericsnow, cheers
<dimitern> wallyworld, well, the api client could be made more robust I guess
<dimitern> wallyworld, I mean since this happens at every bootstrap the initial connection (or say first 3 attempts) might fail, but shouldn't be logged as errors
<dimitern> wallyworld, and the sleep could be in there, rather than in the ci script
<jw4> ericsnow: thanks for that clarification - copied:= *meta... looked like a pointer assignment to me
<wallyworld> dimitern: the issue is that if it is really quick, a client might grab a connection which is then lost with the restart. we could look at delaying the state server start until after the first address change
<dimitern> wallyworld, that second part sgtm
<wallyworld> i'll raise a bug
<ericsnow> jw4: yep, * != &, but our brains don't handle that so well sometimes :)
<anastasiamac> ericsnow: this should be on a t-shirt :D
<jw4> ericsnow: :-p
<jw4> ericsnow: yours did
<ericsnow> jw4: sure, this time... :)
<jw4> hehe
<wallyworld> jam1: hi, i see you guys did some work on the status spec. i made a couple of v1 compatibility comments near the top. i also see you didn't like "broken", which is to blocked as busy is to waiting
<jam1> wallyworld: so it isn't entirely, we did discuss it a bit
<jam1> specifically, Broken is actually "come look and fix something with *me*"
<jam1> which is what we had as broken
<wallyworld> yes
<wallyworld> just like busy, which is waiting on me
<jam1> (yes, it means you need to relate me to something else, but that distinction vs you need to fix my config isn't very compelling)
<jam1> wallyworld: so still, not exactly
<jam1> sorry, I had a typo
<wallyworld> not just my config, could also be disk spac eetc
<jam1> *blocked* is come look at me
<wallyworld> doesn't matter, we can go with what's there
<wallyworld> i see there's a lot of extra unit states
<jam1> wallyworld: so I would like you to understand how we put the rationale together, I realize in the scale of things the specifics aren't huge, but there was a fair discussion and I was happy with how the mapping worked out.
<wallyworld> i think i disagree that error shouldn't be on agent-state, as just because a hook fails, doesn't mean that the software isn't running, but you guys would have discussed that
<jam1> wallyworld: so one guiding thing there is that we want to move to where we have 1 Juju agent for the machine and all its units
<jam1> not 1 unit-agent per unit
<wallyworld> yes, that's true
<jam1> wallyworld: so you do need a place to say "this unit failed its hook", without saying that all units are dead
<wallyworld> so error is best done on unit then
<wallyworld> fair point
<jam1> wallyworld: IIRC there is *also* error on the agent for compat
<jam1> and then we drop that in favor of "failed"
<jam1> when the agent itself is unresponsive
<wallyworld> yes
<wallyworld> so you agree with my v1 compat comments?
<wallyworld> s/do/do
<wallyworld> s/so/do
<jam1> I haven't gotten to them yet, just chatting with you here
<wallyworld> sure, sorry
<jam1> wallyworld: np. So Mark feels strongly that we can drop pending, because nobody is actually depending on it, but we'll keep Started and Error
<jam1> We don't need Installed, because nothing stayed there very long
<jam1> Down is a fair point, though
<wallyworld> i figured that would be the case for Installed, just wanted to be 10000% sure
<wallyworld> i wasn't sure if we wanted to be really anal about keeping 100% compat
<wallyworld> i think we need to keep Stopped also
<wallyworld> s/need/should
<wallyworld> as we don't know who has scripts that depend on it
<jam1> wallyworld: this is agent-state stopped, right? Are we actually able to depend on it? We can run it by fwereade or someone, but I thought Stopped only existed as long as the Database hadn't cleaned up that unit yet
<jam1> We may need to keep it for the same purpose, though.
<wallyworld> jam1: yes, the current agent-state Stopped
<wallyworld> we might be able to safely drop it, as for Installed, just want to be sure
<bodie_> I'd really like to land this so TheMue can land the changes in master tomorrow: https://github.com/juju/charm/pull/81
<bodie_> it's a pretty simple change which tweaks the way Charm parses actions schemas from yaml
<wwitzel3> so when cloud-init writes the authroized_keys file, where does it get the information it writes in to there from?
<bodie_> s/tomorrow/today
<bodie_> (but a huge usability improvement from the charm author's perspective)
<dimitern> bodie_, looking
<jog> wallyworld, looks like something with 24c1b80d is affecting upgrades across multiple substrates
<bodie_> dimitern, thanks!
<wallyworld> let me look at what the rev is
<wallyworld> jog: this PR https://github.com/juju/juju/pull/1291 ?
<jog> wallyworld, yes
<wallyworld> i have no knowledge of that work, what do the CI logs say is the problem?
<jog> wallyworld, joyent, aws, hp, azure, maas, KVM, ... all timing out after waiting 10 minutes for juju status after the upgrade... so at a minimum the time for an upgrade to complete has increased
<wallyworld> wouldn't surprise me if it's more than that, more likely to be a breakage, the juju state server upgrade and machine log would be helpful
<wwitzel3> so in the cloud-init log I see 014-12-18 05:51:56,497 - util.py[DEBUG]: Writing to /home/ubuntu/.ssh/authorized_keys - wb: [384] 1416 bytes
<wwitzel3> which implies that it is writing the keys, but when I look at that file, there are only the keys from the provider
<wwitzel3> I wonder if Google is overwriting them after we write them ..
<wallyworld> could be, i know nothing about gce
<wwitzel3> hrmm actually I think maybe I am just not writing them to the proper place in the metadata
<jog> wallyworld, I can attach log or if you want to look sooner one instance is under the artifacts here:  http://juju-ci.vapour.ws:8080/job/aws-upgrade-precise-amd64/2176/
<wwitzel3> but then what is cloud-init writing? .. hrmm
<wallyworld> jog: looking
<jog> wallyworld, this looks like the same issue menn0 fixed yesterday " login blocked because upgrade is in progress"
<wallyworld> i wasn't aware of that fix - do the logs look the same or similar?
<wallyworld> i can see a test fix
<wallyworld> the logs sure do have a lot of terminated connections
<jam1> fwereade: ping for where you're at with active/goal
<dimitern> bodie_, reviewed
<bodie_> dimitern, thanks, have been following along making a few changes :)
<bodie_> I really ought to call it a day though
<bodie_> I think most of this should be very straightforward -- can you sync up with TheMue?  I have to get up early to travel in the morning
<bodie_> he offered to pick it up since I'm leaving town
<bodie_> or... expect him to ping you back in there
<jog> wallyworld, this was yesterdays fix https://github.com/mjs/juju/commit/f22f2f07ace804fbce81b66bfe938439a6878a29
<bodie_> or something which works well and makes everyone happy ;)
<dimitern> bodie_, ok, feel free to land this, but I'd like you to address the suggestions in a follow-up if you don't mind?
<dimitern> bodie_, I will sync up with TheMue
<wallyworld> jog: could be related, but doesn't seem like it. i can't see off hand from the logs what the issue is. more detailed investigation is required
<wallyworld> are these upgrade failures intermittent?
<dimitern> wallyworld, I might be able to help there, let me have a look at the logs
<wallyworld> ty :-)
<jog> wallyworld, dimitern nearly all substrates started failing upgrade tests with pull 1291... so not intermittent, rather very consistent
<dimitern> jog, why is the job destroying the environment? http://juju-ci.vapour.ws:8080/job/aws-upgrade-precise-amd64/2175/console after upgrade
 * wallyworld bbiab
<dimitern> jog, this is seems fishy 2014-12-18 03:27:58 INFO juju.provider.common destroy.go:15 destroying environment "aws-upgrade-precise-amd64"
<jog> it waits 10 minutes checking 'juju status' and then gives up and destroys the environment, so the resources are available for the next test
<dimitern> jog, ah, ok
<jog> dimitern, wallyworld, I think we should block on this, it might be harder to figure out if addition code lands
<bodie_> dimitern, that sounds perfect, much appreciated!
<dimitern> jog, looking at the logs so far it seems the upgrade was completed on machine-0, but the upgrade block wasn't lifted
<jam1> fwereade: poke when you're awake
<wwitzel3> man, it got late. We are so close to getting GCE to bootstrap.
<dimitern> wwitzel3, \o/
<bodie_> dimitern, I'm going to go ahead and ship the charm fix, and open a new PR with the requested changes referenced.  I also have a branch for updating tests on master to reflect this stuff
<dimitern> bodie_, sweet, thanks
<dimitern> jog, this is the issue: cannot set agent version for machine 0: not found or dead
<dimitern> jog, and machine-0 is obviously alive and well, so something around env-uuid changes in state recently does not work properly
<bodie_> fwiw, the PR to fix the charm actions parsing in juju master is http://reviews.vapour.ws/r/661/ if anyone fancies having a look
<jog> dimitern, I opened bug https://bugs.launchpad.net/juju-core/+bug/1403738
<mup> Bug #1403738: upgrade tests fail on multiple substrates with revision 24c1b80d <juju-core:Triaged> <https://launchpad.net/bugs/1403738>
<jog> dimitern, do you need anything else from me? If not my day is long over.
<dimitern> jog, can you re-run one of the failing jobs, but using logging-config: <root>=TRACE in envs.yaml ?
<dimitern> jog, with <root>=INFO we're practically loosing all context during the upgrade - all upgrade jobs should run with at least logging-config: <root>=DEBUG
<jog> ok
<jam1> wallyworld: fwereade: we feel pretty good about where the status spec is at (you should have gotten an email). So comments are welcome.
<wallyworld> jam1: ty, will look
<jam1> wallyworld: are you around at all during the break?
<jam1> I feel like it might be good to have a hangout to discuss finer points, but I know everyone is officially not-working
<wallyworld> jam1: sure, i can be available, what time is the break?
<jam1> wallyworld: I mean Holiday break
<jam1> eg, next week
<wallyworld> jam1: oh, right :-) that will be fine too
<wallyworld> maybe one evening my time, afternoon your time, which will be midday for william
<jam1> wallyworld: k, I know I'm out of town from 25-1st, but I'll have Monday/Tues that I'm just relaxing around the house
<wallyworld> ok, maybe aim for monday depending on william's availability?
<wallyworld> fwereade: you free for a catchup in 10?
<dimitern> jog, updated the bug
<wallyworld> jam1: storage phase 1 spec has openstack cinder volumes in scope, yet the in scope providers are listed as maas, local, aws. i thought openstack was out of scope for phase 1
<wallyworld> jam1: you may have missed my message when your connection bounced
<wallyworld> storage phase 1 spec has openstack cinder volumes in scope, yet the in scope providers are listed as maas, local, aws. i thought openstack was out of scope for phase 1
<jam1> wallyworld: thanks for the heads up, the network here likes to stay up for approximately 2min before needing to be resetâ¦
<jam1> I did try to flag that with a comment, can you make sure there is a note if mine didn't go through ?
<wallyworld> sure, will do, just about to be called for dinner, will do it straight after
<TheMue> morning
<voidspace> TheMue: o/
<voidspace> dimitern: ping
<dimitern> voidspace, pong
<voidspace> dimitern: hey, hi
<voidspace> dimitern: davecheney suggests that network.SubnetInfo should use net.IP for the AllocatableIPLow and High
<voidspace> dimitern: what do you think?
<dimitern> voidspace, sgtm
<voidspace> dimitern: we have to convert back to strings where we *use them*
<voidspace> dimitern: in state and on the wire
<voidspace> dimitern: and it doesn't save us validation as constructing an IP doesn't return an error (you have to check for a nil value)
<voidspace> so I'm not sure what it buys, beyond more conversions
<voidspace> dimitern: TheMue: little girl just woken up - neighbour has agreed to babysit (wife out), but I have to set that up
<voidspace> dimitern: TheMue: will take a few minutes, so will be late to standup again... sorry
<TheMue> voi
<TheMue> voidspace: ok
<rogpeppe> is a unit's public-address also supposed to be accessible from within an environment?
<rogpeppe> dimitern: ^
<voidspace> TheMue: dimitern: babysitter here, omw
<dimitern> rogpeppe, you mean like in ec2 automatic public ips ?
<rogpeppe> the question is really: is it reasonable to have a single address for a service endpoint that works both within the environment (from unit to unit) and from outside it?
<dimitern> rogpeppe, short answer - it depends
<rogpeppe> dimitern: i mean the public-address as reported by the unit-get public-address charm tool
<dimitern> rogpeppe, in joyent for example you can, but not in ec2 or openstack (depends on how floating ips are configured)
<rogpeppe> dimitern: i thought it worked ok in ec2 as the public-address resolves correctly whether you're inside or outside the cloud
<voidspace> TheMue: dimitern: struggling to join...
<rogpeppe> dimitern: but perhaps i'm misremembering?
<voidspace> "Trying to join the call. Please wait..."
<rogpeppe> dimitern: i'm more concerned with the intra-environment behaviour here
<dimitern> rogpeppe, you're talking about different things
<rogpeppe> dimitern: as i already know that public-address might not be accessible from outside the env - that's an issue we always need to deal with
<dimitern> rogpeppe, the ec2 instance dns name resolves to internal ip in ec2 or to the public ip outside
<rogpeppe> dimitern: and that's what we report for public-address, right?
<rogpeppe> dimitern: or has that changed?
<rogpeppe> perhaps i should phrase the question like this: can i be sure that a unit can connect to another unit's public-address as well as its private-address?
<rogpeppe> voidspace, dimitern: FWIW, I'm +1 on using net.IP when we know we've got IP addresses
<rogpeppe> voidspace: and net.ParseIP does validate, even though it doesn't return an explicit error
<dimitern> rogpeppe, it depends on the provider
<rogpeppe> dimitern: hmm, that's not great
<dimitern> rogpeppe, in standup now, i'll get back to you in a bit
<rogpeppe> dimitern: ta
<rogpeppe> another network-related question: is it possible for a unit to find out the public address of another unit that it's related to?
<rogpeppe> dimitern, fwereade: ^
<dimitern> rogpeppe, so you can rely on a split horizon dns name to work internally and externally in ec2 and openstack (if so configured)
<dimitern> rogpeppe, not automatically - via relation settings
<rogpeppe> dimitern: and public-address will always return a split-horizon dns name
<rogpeppe> ?
<dimitern> rogpeppe, I wouldn't say always
<rogpeppe> dimitern: ok, so i can't rely on this at all then?
<dimitern> rogpeppe, in juju status - most likely, as unit.PublicAddress - if set by the provider (IIRC some providers were explicitly changed to either return dns name or ip for various reasons)
<rogpeppe> dimitern: my situation is that i have a web service that returns some data to the client which includes the address of another service for the client to connect to.
<rogpeppe> dimitern: i'd like that client to work correctly whether it's inside the environment or outside it
<dimitern> rogpeppe, right
<rogpeppe> dimitern: it currently looks like that's not possible without returning more than one address
<dimitern> rogpeppe, yes
<rogpeppe> dimitern: and that a standard http relation isn't sufficient to find out the public address
<dimitern> rogpeppe, hopefully this will change as more networking model stuff lands
<rogpeppe> dimitern: i'm guessing that it will only change if this specific requirement is on the roadmap
<dimitern> rogpeppe, alternatively, you can use custom networking config inside the charm
<rogpeppe> dimitern: how would that work?
<dimitern> rogpeppe, so your webservice charm returns this info via relation settings?
<rogpeppe> dimitern: no, via http
<dimitern> rogpeppe, ok, so the webservice is not running inside a charm?
<rogpeppe> dimitern: it's part of the http API that it exposes
<rogpeppe> dimitern: yes, it is running inside a charm
<rogpeppe> dimitern: all the services here are running as charms, possibly excluding the client
<dimitern> rogpeppe, and you want to return a single hostname/ip that's usable both internally and externally?
<rogpeppe> dimitern: ideally, yes
<dimitern> rogpeppe, so first, the only way I can think of is to use a split horizon dns name
<rogpeppe> dimitern: but i can't rely on that, right?
<dimitern> rogpeppe, and it needs to be supported either by the cloud itself (like ec2) or by another exposed service running a dns server
<dimitern> rogpeppe, not right now, because the addresses we store in state are not in a single place
<dimitern> rogpeppe, that's why it's unreliable - unit.PublicAddress() returns whatever its assigned machine's Addresses() method returns
<rogpeppe> dimitern: an arbitrary selection, presumably?
<rogpeppe> dimitern: because Addresses can return many addresses
<rogpeppe> dimitern: i think i'll just go with returning several addresses to the client and relying on them to try all of them
<dimitern> rogpeppe, nope
<rogpeppe> dimitern: anything else i think is being unreasonably optimistic/platform-dependent
<dimitern> rogpeppe, since a recent change I made all addresses are consistently ordered - public ips before hostnames, then cloud-local, etc.
<rogpeppe> dimitern: ok, so it's still an arbitrary selection but at least a stable choice, then?
<dimitern> rogpeppe, however the uncertainty still exists, as those addresses are merged from the instance addresses (coming from the provider) and machine ones (as discovered by the net package)
<dimitern> rogpeppe, it is stable yes
<rogpeppe> dimitern: hmm, so that means that IP addresses are always chosen over host names?
<rogpeppe> dimitern: so you'll never get a split-horizon DNS name?
<dimitern> rogpeppe, and provider addresses always shadow machine ones - so if the provider (e.g. like maas) adds dns names in addition to ips in response of calling instance.Addresses() - you'll get those, then machine addrs in a single list, ordered
<dimitern> rogpeppe, effectively, since that change it's even less likely (can only happen if there are only hostnames)
<rogpeppe> dimitern: so i'm right that it'll never return a DNS name when an IP address is available?
<rogpeppe> dimitern: "it" == "unit-get public-address"
<dimitern> rogpeppe, but this can change - preferring ips over hostnames was a requirement for api endpoints, but for intra-environment communication can be different
<rogpeppe> dimitern: in this case, this is about from-the-outside access to the environment
<dimitern> rogpeppe, it depends what ip - if it's public, yes - it will always come before any hostnames; if cloud-local - hostnames come first
<rogpeppe> dimitern: aren't ip addresses less stable than dns names?
<dimitern> rogpeppe, in maas'es case for example we have "vm0.maas" "192.168.10.1" and "127.0.0.1" - hostname will be chosen
<dimitern> rogpeppe, ips are absolute (much more so at least than hostnames that can resolve to anything)
<rogpeppe> dimitern: yeah, but ip addresses can be on short-term lease
<rogpeppe> dimitern: in this case i need a stable address that can be used to contact a service
<dimitern> rogpeppe, that's rarely an issue
<dimitern> rogpeppe, I agree
<dimitern> rogpeppe, and can suggest raising a bug about it :)
<rogpeppe> dimitern: ok
<dimitern> rogpeppe, i.e. have a way to get a hostname if possible for public-address
<rogpeppe> dimitern: it would be quite nice if a unit was able to get the public address of a related unit as well as its priviate address too
<dimitern> rogpeppe, it still can - if the remote unit sets its address into the relation settings
<dimitern> rogpeppe, also, there might not be a public address to get
<rogpeppe> dimitern: also, this means that "unit-get public-address" in ec2 will never return an address that is reachable from within the environment, right?
<dimitern> rogpeppe, e.g. in maas all ips are cloud-local
<rogpeppe> dimitern: that's true. i'm thinking that public-address is provided by default (when available) along with private-address
<dimitern> rogpeppe, that's like this since several months now actually - after DNSName got dropped from Environ
<rogpeppe> dimitern: just to be clear, there's currently no way to obtain the ec2 split-horizon DNS name within juju, right?
<dimitern> rogpeppe, ec2 now only reports ips (public and private)
<dimitern> rogpeppe, there are lots of ways :) - fetching a metadata url from the charm for example
<dimitern> rogpeppe, but not a "usual" way
<rogpeppe> dimitern: yeah, i don't want to write ec2-specific code in my charm
<rogpeppe> dimitern: that kinda loses the point of juju
<dimitern> rogpeppe, i can't recall what was the reasoning behind removing DNSName() from Environ
<dimitern> rogpeppe, true, i'm not suggesting it seriously
<rogpeppe> dimitern: i guess one way forward would be to expose a way to get all a unit's addresses from a unit, (and possibly from a related unit)
<dimitern> rogpeppe, yeah - a client api call "get all unit addresses"
<rogpeppe> dimitern: i'm actually thinking of: unit-get addresses
<dimitern> rogpeppe, which then can be called from a hook tool that does that
<rogpeppe> dimitern: and relation-get addresses
<dimitern> rogpeppe, the address-get hook tool that's on the roadmap for 15.04 will do this
<rogpeppe> dimitern: the client side is another question - the only way to get a unit's address is through status currently, right?
<dimitern> rogpeppe, by default it will return a single address; you can specify -r <rel-id>  -maybe --all as well
<rogpeppe> dimitern: ah, replacing unit-get ?
<dimitern> rogpeppe, yep - unit-get will only live for backwards compatibility but will get dropped and aliased to something else in the mean time (most likely address-get)
<fwereade> mm, heston blumenthal mass-produces a pretty decent christmas cake
<rogpeppe> fwereade: :)
 * rogpeppe has mince pies downstairs
<rogpeppe> dimitern: as it turns out the public IP address also works ok internally in ec2
<dimitern> rogpeppe, nice! :)
<jam2> fwereade: sounds yummy. feeling better today ?
<fwereade> jam2, yeah, more-or-less with it again
<voidspace> dimitern: fancy giving my PR another quick look-over (including string to net.IP change)
<voidspace> dimitern: http://reviews.vapour.ws/r/644/
<dimitern> voidspace, sure thing
<dimitern> voidspace, great, just 1 typo
<dimitern> well, not a typo - more like an omission
<voidspace> dimitern: ok, cool - thanks
<voidspace> dimitern: hmmm... looks like the change to SubnetInfo to use net.IP instead of string is causing a panic
<voidspace> dimitern: ... Panic: runtime error: hash of unhashable type network.SubnetInfo (PC=0x414676)
<voidspace>  
<voidspace> dimitern: investigating
<voidspace> dimitern: hah, jc.SameContents is panicking trying to compare
<dimitern> voidspace, use jc.DeepEquals instead?
<voidspace> dimitern: I presume SameContents is being used to not be order dependent
<voidspace> dimitern: (this is a pre-existing test)
<voidspace> dimitern: I'll try it though
<voidspace> it works
<voidspace> ShipIt!
<dimitern> voidspace, it's used for maps (or was it slices?) but works for gcc-go (ppc) and golang-go
<dimitern> voidspace, \o/
<wwitzel3> ericsnow: bug #1403662 lgtm, so I'm going prepare the commit to backout the hack we have working around it
<wwitzel3> ericsnow: also I still didn't get the ssh issue solved .. even with explictly adding the sshKeys to the GCE metadata.
<wwitzel3> ericsnow: it is like there is a step we are missing
<wwitzel3> ericsnow: ok, so I have the keys being properly uploaded to GCE, now I'm just trying to resolve this "error: Could not load host key: /etc/ssh/ssh_host_ed25519_key"
<wwitzel3> ericsnow: that is the error the juju ssh client keeps disconnecting on
<LinstatSDR> Good morning all.
<wwitzel3> ericsnow: looks like we are running in to this bug https://bugs.launchpad.net/cloud-init/+bug/1382118
<mup> Bug #1382118: Cloud-init doesn't support SSH ed25519 keys <cloud-init:New> <https://launchpad.net/bugs/1382118>
<ericsnow> wwitzel3: looks like you're on to something
<natefinch> well that looks less than promising
<ericsnow> natefinch: it does mean we are nearly done with bootstrapping (I think)
<natefinch> ericsnow: awesome.  Any idea if that bug is going to be a major problem for you guys?
<ericsnow> natefinch: I imagine so but wwitzel3 may have a better idea of it
<wwitzel3> natefinch:I don't know much about cloud-init .. can we send it some a set of custom commands to run for us?
<wwitzel3> natefinch: we either need the sshd_config on the instance to remove the line expecting ed25519 keys or we need to issue a ssh-keygen to create the expected key file.
<natefinch> man I wish we used github for releases.... trying to figure out what code is in what release in launchpad is a huge pain
<perrito666> natefinch: tags dont have the same name as releases in lp?
<natefinch> perrito666: ha, I missed we had tags on juju... it's a separate tab in the list of branches.  Thanks for that.
<ericsnow> fwereade: PTAL: http://reviews.vapour.ws/r/663/
<ericsnow> fwereade: that drops the AZ from unit-get and adds it as an env variable
<ericsnow> fwereade: let me know if that's what you had in mind
<fwereade> ericsnow, catching up wit hthe related code: I'm wondering (1) why we set context.availabilityZone in factory.updateContext, especially given the doc comment on updateContext and (2) why there aren't any tests for it in factory_test.go?
<ericsnow> fwereade: I'll take a look
<ericsnow> fwereade: FWIW, a lot of what I did for availability zones was following the precedent of what I considered to be the similar fields
<fwereade> ericsnow, hmm, what are the untested factory/context bits? I made an effort to fix them -- not saying I *did* catch them all, but I'd like to know so I can fix them ;)
<ericsnow> fwereade: oh, I probably just missed addin the AZ-related tests
<ericsnow> fwereade: if I see something missing I'll let you know :)
<katco> gah, trunk is currently closed?
<katco> the room's title lies!
<fwereade> ericsnow, I don't want to claim particular superiority of the existing code, though: in particular all the tests that directly construct a *HookContext are Bad Tests, and they're only like that because I was [focused on delivering business value elsewhere|too damn lazy] (strike out whichever does not apply)
<katco> we really should modify mup to report CI status.
<natefinch> katco: the only thing that never lies is this page: https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL
<fwereade> ericsnow, (context: I added Factory and moved NewHookContext into export_test.go, but didn't fix all the tests that used it)
 * natefinch has that labeled in his bookmarks toolbar as "CI Blockers"
<katco> it seems like this question comes up CONSTANTLY and from different people
<katco> it's clearly something we need to make more clear somehow
<natefinch> katco: yeah, I don't know enough about launchpad to know if there's some way to create a status page or something
<natefinch> katco: rather than a random filter of existing bugs
<katco> natefinch: there is; i wrote some emacs lisp to interface w/ launchpad
<katco> natefinch: ah, yeah that's probably what it would be: does this query return anything? blocked. no? not blocked.
<ericsnow> fwereade: got it
<katco> and then have mup periodically do that
<katco> and change the room topic
<katco> and maybe announce it
<katco> ~1m or so
<natefinch> please no announcements every minute :)
<katco> no i mean if it changes haha
<katco> "CI IS OPEN AND ALL IS WELL! HEAR YE HEAR YE!"
<fwereade> haha
<katco> ^ this guy gets it!
<natefinch> it would be nice, but not really sufficient, I think.  It's easy to miss stuff in IRC, and you don't see the room title except on login....  I'm much rather have a webpage with a URL I can at least attempt to remember that I can point people to.
<katco> natefinch: +1; but fwiw, the topic is always up for me and i can set notifications on keywords/people
<voidspace> natefinch: if you use xchat you see the room title all the time
<katco> natefinch: but i website would be a great first step. i don't even care if it's blank and the background changes from #00FF00 to #FF0000
<natefinch> Oh, yeah, there it is at the top of the screen...
<katco> and it should probably be hooked into reports.vapour or w/e
<natefinch> it's just like a foot above where I usually look on my IRC window
<voidspace> hah...
<voidspace> natefinch: you remember the question I asked you about netmasks the other day? How to work out the last ip in a subnet.
<voidspace> natefinch: I was taking the number of zeros in the netmask, then OR'ing (2 ** numZeros -1) with the first IP
<voidspace> natefinch: which works
<voidspace> natefinch: but instead you can do 1 << numZeros
<voidspace> natefinch: which gives you the number of IPs in the subnet
<natefinch> voidspace: ahh, bit twiddling
<voidspace> natefinch: and is a bit more elegant (then add that to the first IP)
<voidspace> natefinch: yeah, fun
<natefinch> voidspace: evidently useful for more than CS101 and job interviews ;)
<voidspace> hehe
<voidspace> and crypto
<natefinch> voidspace: well, I guess... though if you're writing your own bit twiddling code for crypto, you're probably doing it wrong.
<voidspace> natefinch: yeah probably
<natefinch> voidspace: but I get your meaning.  Certainly bit twiddling is useful in many circumstances... I was mostly joking :)
<voidspace> natefinch: :-)
<dimitern> ericsnow, hey
<ericsnow> dimitern: what's up?
<dimitern> ericsnow, mattyw asked a question today about which repos are handled by the automatic RB diff creation from PRs
<ericsnow> dimitern: currently just core and utils
<dimitern> ericsnow, and now that I think of it - I wondered as well
<dimitern> ericsnow, ah, ok, thanks
<ericsnow> dimitern: It's been on my todo list to add the rest of the ones that RB knows about
<dimitern> ericsnow, and where is the bot/script that does that live?
<dimitern> s/live//
<dimitern> ericsnow, iirc it's running on some ec2 instance
<ericsnow> dimitern: it's a github webhook (pointing to a RB URL)
<ericsnow> dimitern: oh, the GH bot?  I don't know
<dimitern> ericsnow, ah right
<dimitern> ericsnow, so each repo has a webhook configured?
<dimitern> ericsnow, each := juju and utils I mean
<ericsnow> dimitern: exactly
<dimitern> ericsnow, ok,thanks
<ericsnow> dimitern: np
<alexisb> wwitzel3, you around?
<voidspace> alexisb: o/
<voidspace> alexisb: hey, alexis - just saying hi
<voidspace> alexisb: happy christmas and see you next year :-)
<wwitzel3> alexisb: yes, the bug ended up not being a blocker for gce
<voidspace> wwitzel3: and you Wayne - I'm signing off for the year shortly... have a good holiday
<wwitzel3> voidspace: ahh, have a great one! :)
<katco> voidspace: happy new year!
<voidspace> katco: thanks :-) Have a good break and see you on the other side.
<alexisb> hey there voidspace we havent chatted in like forever
<katco> voidspace: you too! best to you and your family
<alexisb> you must not be on my calendar
<alexisb> howdy and happy holidays to you!
<voidspace> alexisb: I don't think I am...
<voidspace> alexisb: we can sort that out next year :-)
<alexisb> voidspace, I will fix that
<voidspace> coolio
<perrito666> mgosuites are a torture
<wwitzel3> so anyone have any pointers on why the /var/lib/juju folder and nonce.txt would not be being created?
<wwitzel3> when bootstrapping
<hazmat> anybody seen these types of errors out of go 1.4
<hazmat> $ go get -u -v github.com/docker/swarm/...
<hazmat> package github.com/docker/swarm: /home/kapil/src/github.com/docker/swarm is from https://github.com/docker/swarm/, should be from https://github.com/docker/swarm
<voidspace> right, EOY
<voidspace> bye all
<voidspace> have a great holiday and new year, and see you there...
<wwitzel3> ericsnow: I'm going to grab some food, but I'll leave my session up
<ericsnow> wwitzel3: k
<ericsnow> wwitzel3: ping me when you're back
<ericsnow> perrito666: so it looks like restore has to be all committed by Jan 9...
<perrito666> ericsnow: so it seems
<ericsnow> perrito666: or we'll need to disable backups in 1.22 like we did in 1.21
<perrito666> we are getting there if CI has enough non locked time
<ericsnow> perrito666: :)
<ericsnow> if anyone has a few minutes to spare, I could use a review on http://reviews.vapour.ws/r/659/
<ericsnow> it's a basically a copy of utils/set.Strings with s/String/Int/ :)
<natefinch> ericsnow: ship it!
<ericsnow> natefinch: thanks
<natefinch> ericsnow: I had looked at it before but forgot to hit the ship it button
<wwitzel3> ericsnow: back
<ericsnow> brt
<wwitzel3> during bootstrap what is responsible for creating the /var/lib/juju on the instance?
<wwitzel3> right now, during ssh, when we login, there is no /var/lib/juju/nonce.txt file
<wwitzel3> in fact, there is no /var/lib/juju folder at all
<wwitzel3> the finish bootstrap command expects that nonce.txt file
<ericsnow> (on GCE)
<wwitzel3> so that is why GCE is failing atm
<natefinch> wwitzel3: cloud init makes it
<katco> is there a good, clear example of using suites to set up a full juju stack? i'm getting nil-reference exceptions and it's not exactly clear to me why
<perrito666> katco: mm?
<natefinch> There's the dummy provider, but proceed with caution... there be dragons
<katco> perrito666: so you know how we chain suites in tests?
<perrito666> katco: I have no clue
<katco> perrito666: i am probably wording it poorly
<natefinch> embed this suite in that suite etc etc
<katco> yeah
<perrito666> natefinch: I might have let you a review in priv
<natefinch> katco: I think it's the JujuConnSuite
<katco> natefinch: what is?
<natefinch> katco: the suite that gives you a bootstrapped env
<natefinch> katco: /home/nate/src/github.com/juju/juju/juju/testing/conn.go
<katco> natefinch: ah ironically that's where the panic happens :p
<thumper> hello folks
<perrito666> thumper: morning mate
<thumper> katco: what is your error?
<katco> natefinch: it's the confluence of using that package with another suite i think
<waigani> thumper: http://reviews.vapour.ws/r/627/
<perrito666> natefinch: btw, if we have blocking bugs the topic might benefit from that info
<waigani> thumper: and follow up branch http://reviews.vapour.ws/r/657/
<perrito666> waigani: I answered one question on one of your reviews
<thumper> natefinch: is anyone on your team dealing with https://bugs.launchpad.net/juju-core/+bug/1396099 ?
<mup> Bug #1396099: AWS/Joyent/HP/manual/maas: juju deploy error "connection is shut down" <api> <ci> <deploy> <ec2-provider> <joyent-provider> <manual-provider> <regression> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1396099>
<thumper> I don't always trust the assignee
<perrito666> thumper: btw, thanks for taking over yesterday
<waigani> perrito666: which review?
<waigani> perrito666: got it
<perrito666> http://reviews.vapour.ws/r/645/diff/#http://reviews.vapour.ws/r/645/diff/#
<thumper> perrito666: that's fine
<perrito666> waigani:  that, but only once
 * perrito666 lends his computer a second to his mother in law to look up the recipe of a sweet chrismas bread and is profusely ... criticized... for having the kb layout US
<waigani> hehe
<waigani> perrito666: where are the tests for the Restore func?
<perrito666> waigani: not yet pushed, sadly when I click fixed it sumits immediately instead of remaining in my draft
<perrito666> waigani: but you added a ?
<perrito666> which is not very clear
<waigani> perrito666: sorry about that , I dropped it
<katco> thumper: so i'm trying to use the cmd/jujud/agent/testing/agent.go suite, and if i use that alone i get errors with various workers trying to operate on my host's real fs
<katco> thumper: and then the test just keeps trying to dial the state server which apparently didn't come up
<katco> thumper: so i tried to bring in juju/juju/testing, and that gives me a nil reference exception (hold)
<thumper> katco: do you have the code handy?
<katco> thumper: do you feel like doing a peer coding session?
<thumper> could do...
<katco> thumper: it's not pushed up anywhere yet
<thumper> ok
<perrito666> waigani: no problem I was curious if that actually was a way to say wtf
<perrito666> ericsnow: my mind is a bit clouded, the cool upload is already landed right?
<ericsnow> perrito666: right
<perrito666> tx man
<menn0> wallyworld: ping?
<perrito666> ah wallyworld ping me with relative low priority when you have a moment
<ericsnow> where does nonce.txt get written to the new instance during bootstrap?
<natefinch> ericsnow: it gets added to the stuff cloud init does
<ericsnow> natefinch: but where?
<natefinch> ericsnow: github.com/juju/juju/environs/cloudinit/cloudinit_ubuntu.go#105
<ericsnow> natefinch: that doesn't write anything to the new host though, right?
<ericsnow> natefinch: doesn't that happen in cloudinit/sshinit/configure.go?
<natefinch> ericsnow: yeah, it adds a line to cloud init... github.com/juju/juju/cloudinit/options.go#374
<ericsnow> natefinch: right
<perrito666> hey people heads up https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
<ericsnow> natefinch: is there an initial /var/lib/juju/nonce.txt included in the cloud images?
<natefinch> ericsnow: no clue
<ericsnow> natefinch: :(
<wallyworld> perrito666: hi
<perrito666> wallyworld: hi
<perrito666> wallyworld: ill privmsg you
<menn0> hmmm.... I think I've found another upgrade regression that's unrelated to what I'm looking at
<wallyworld> menn0: hi
<menn0> wallyworld: hi
<menn0> wallyworld: i think I figured out what i was going to ask you
<wallyworld> ask away
<menn0> wallyworld: but i'm about to ask you to review a fix to one of the CI blockers
<wallyworld> sure
<menn0> wallyworld: it's a bit of a reorg of the apiworker in the machine agent
 * katco looks at menn0 nervously
<wallyworld> is this the upgrade bug with uuid?
<menn0> yep
<alexisb> menn0, travel approved
<menn0> wallyworld: but that change has exposed a "bug" in the machine agent
<menn0> alexisb: thanks
<menn0> wallyworld: the container setup code was running during upgrades
<wallyworld> menn0: so we are roomies, thumper will be jealous
<wallyworld> ah, container setup code should run after upgrades shouldn't it
<menn0> thumper has nothing to worry about. you're all his :-p
<wallyworld> \o/
<menn0> wallyworld: yep
<menn0> wallyworld: give me a few minutes and you can see what i've done. it's not completely straightforward to fix this.
<wallyworld> i guess till now the container setup didn't really matter when it ran so we got away with it
<menn0> wallyworld: well kinda,
<menn0> wallyworld: there was always a lurking bug there
<wallyworld> yeah
<wallyworld> i men it was luck nothing broke till now
<wallyworld> mean
<menn0> wallyworld: if the machines collection migration happened at about the same time as the container setup it could have blown up anyway
<menn0> wallyworld: it's just much more likely now
<wallyworld> menn0: one thing also that needs doing is to delay the api worker start up until after the first address change has come in
<wallyworld> to allow the server cert to be regenerated
<wallyworld> with the machine ip addresses
<wallyworld> thus avoiding a restart after any clients that manage to connect realy, really quickly
<menn0> wallyworld: yeah, the other CI problem
<wallyworld> oh, they raised a blocker for that?
<wallyworld> wtf
<wallyworld> sigh
<wallyworld> that will not be an issue in practice
<wallyworld> i wish blockers we added to the juju-dev topic
<wallyworld> so we could see them
<menn0> wallyworld: they are but it seems to be a manual process
<menn0> wallyworld: a bot should do it
<wallyworld> yes
<menn0> wallyworld: here's that fix https://github.com/juju/juju/pull/1343
<wallyworld> menn0: ta, in ameeting will look soon
<menn0> thumper: can you look at https://github.com/juju/juju/pull/1343 pls? wallyworld is probably best placed to review this but he's in a meeting but I'd like to get this CI blocker fixed.
<thumper> menn0: ack
<thumper> menn0: Ship It!
<menn0> thumper: ta
<stokachu> when did juju rename its ssh keys to juju_id_rsa?
<stokachu> or has it always been like that
<wallyworld> menn0: change looks good, thanks for fixing
<menn0> wallyworld: great
<wallyworld> stokachu: i'm not 100% sure, i thought it was always like that
<menn0> wallyworld, thumper: thanks for the reviews
<stokachu> wallyworld: ok cool
<menn0> wallyworld: this API server restart issue is affecting my personal test scripts too :)
<menn0> wallyworld: it'll probably bite anyone who has scripted deployments
<wallyworld> i'm about to relocate, will look at it as soon as i'm online again ain about 20 mins
<stokachu> i wonder, if using JUJU_HOME causes the sshkeys to be renamed
 * thumper sighs
<thumper> I need to take the dog to the vet
<thumper> bbl
<stokachu> though i can't find anywhere in the code where juju_id_rsa is referenced
<perrito666> mm, making a function take a variadic argument does not imply I get a slice of that type right?
<katco> perrito666: the argument is used as a slice, but you are not guaranteed its length is > 0
<perrito666> but, is it a slice?
<katco> yes
<katco> well... you mean like down at the AST level?
<katco> like if you used reflection would it be a slice?
<perrito666> katco: like I want to append it to a [][]string :)
<perrito666> katco: exactly
<katco> oh, yep. it's a slice :)
<perrito666> so I have a slice of string slices and I append the variadic arg to it (tests)
<perrito666> but when I try to DeepEqual each of the slices I get an error about the capacity
<katco> i am not sure how go constructs the capacity under the covers for variadic parameters
<katco> my guess is that it matches the number of parameters passed in exactly?
<katco> but it's almost certainly constant, so i'd allocate your test values with whatever capacity it says go has provided
<perrito666> katco: It seems that it expects the subslices to have been properly allocated
<perrito666> so I have to make them and then fill them with the contents of the variadic arg
<katco> perrito666: deep equals?
<perrito666> it does not support dirrect assignation
<perrito666> katco: yup
<katco> i guess that makes sense
<perrito666> I would expect go to have that kind of information for those slices
<perrito666> katco: https://github.com/juju/juju/pull/1326/files#diff-32f2baace5b89ccd33a7a5a4c0619b3bR67
<perrito666> I end up having to do that
<perrito666> If anybody want to take a second look at  http://reviews.vapour.ws/r/645/ Ill be thankful
<katco> perrito666: that code makes send to me. what is unintuitive about it?
<perrito666> katco: well it makes a string slice and copies a string slice
<perrito666> but I am most likely de-referencing some pointers there which might be what was breaking my code
<katco> oh, so if you just do a mgoArgs = append(mgoArgs, mongoRestoreArgs...) it complains?
<perrito666> I have not tried, if you look closely I dont want to append the elements of mongoRestoreArgs but the slice itself
<katco> perrito666: oh i think i see what you meant
<katco> perrito666: the variadic slice didn't have the correct capacity
<perrito666> katco: exactly, which is odd
<katco> perrito666: i think there is a way to size it down... hm
<perrito666> katco: well what I end up doing is clear so I will leave it that way
<katco> perrito666: maybe make the new slice, and then do a copy?
<katco> to elide the for loop?
<perrito666> I somehow fear copy will blow in a similar way?
<katco> perrito666: http://stackoverflow.com/questions/12768744/re-slicing-slices-in-golang
<katco> perrito666: well if it's truly the capacity that's erroring out deepequals, as long as your destination slice is the correct capacity i think it should be fine
<katco> looks like even better is this: mongoRestoreArgs = mongoRestoreArgs[0:]
<perrito666> katco: I might give it a try
 * perrito666 tries
<katco> perrito666: should give you a slice ref with the correct cap. if not, try mongoRestoreArgs[0:len(mongoRestoreArgs)]
<katco> with a nice comment :)
<perrito666> katco: blows
<katco> perrito666: both?
<perrito666> katco: yup (I used a new variable because I find reassignation is a bit ugly)
#juju-dev 2014-12-19
<katco> perrito666: i think i see what's going on
<katco> perrito666: http://play.golang.org/p/VzqUYG-D2y
<katco> perrito666: the capacity fluctuates depending on how far into the slice you start your window, so you pretty much have to create a new slice and copy into it
<perrito666> it might be looking into the capacity and trying to get as many objects instead of lenght objects
<perrito666> man, I lova play.golang so much
<katco> hehe
<katco> it is nice
<perrito666> love*
<perrito666> its like a playable pastebin
<katco> :)
<katco> sandboxed too
<katco> i think rob pike did an interesting write-up on it somewhere
<katco> or maybe it was russ cox
<wwitzel3> wallyworld: got it figured out, the user-data needed to be base64 encoded to be properly stored on GCE
<wwitzel3> wallyworld: but the cloudinit script doesn't expect it to be base64 encoded (afaict), so that is the issue.
<wallyworld> wwitzel3: it's been a while since i looked, isn't is base64 encoded for all providers?
<wwitzel3> wallyworld: it is, but that is actually handled in the provider libraries for most, not in juju
<wwitzel3> wallyworld: go's gce library doesn't enforce how you insert metadata like go amz
<wallyworld> so we should update the gce provider then
<wwitzel3> sorry, api libraries, no the providers
<wallyworld> i guess we don't have access to api lib
<wwitzel3> but yes, we updated the provider to base64 encode
<wwitzel3> but cloud-config is still nil, so we are looking at the cloudinit GCE datastore to see if it does indeed deal with the user-data being base64
<wwitzel3> wallyworld: so we are on the right path, thanks for letting me bug you earlier :)
<wallyworld> np, i didn't help much
<wwitzel3> I'm used to that when I talk to you
<wwitzel3> ;D
<katco> wwitzel3: no one disrespects a tanzanite team member without disrespecting all of us! ;)
<wwitzel3> katco: haha, I'll remember that for next time
<perrito666> ok, being 9:20 pm I feel I should EOD cheers all
<katco> perrito666: tc
<katco> perrito666: i'll see you tomorrow yeah?
<perrito666> indeed
<katco> ok, then no happy holidays for you yet :)
<perrito666> heh ah true down under people are in their friday
<katco> if i'm getting this error: juju.worker exited "environ-provisioner": no state server machines with addresses found
<katco> but i have created a machine with the factory and job of JobManageEnviron, what am i doing wrong?
<menn0_> wallyworld: I get this in any unit after upgrading from 1.20 to 1.22
<menn0_> exited "uniter": failed to initialize uniter for "unit-mediawiki-0": cannot initialize hook commands in "1.22-alpha1.1-trusty-amd64": symlink 1.22-alpha1.1-trusty-amd64/jujud 1.22-alpha1.1-trusty-amd64/action-fail: no such file or directory
<menn0_> haven't we seen that before?
<thumper> yes
<thumper> yes we have
<thumper> menn0: hangout?
<thumper> menn0: the 1.20 upgrade worker creates a relative symlink
<thumper> I think the fix I did for 1.21 didn't get landed in master because "we didn't support 1.20 -> 1.22 upgrades"
<thumper> new code expects absolute
<thumper> the 1.21 upgrade worker makes an absolute symlink
<menn0> thumper: sorry, just saw this
<menn0> thumper: standup channel?
<thumper> ack
 * thumper turns off distractions...
<thumper> if people super need me, text
<menn0> wallyworld: are you looking at bug 1396099?
<mup> Bug #1396099: AWS/Joyent/HP/manual/maas: juju deploy error "connection is shut down" <api> <ci> <deploy> <ec2-provider> <joyent-provider> <manual-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1396099>
<wallyworld> menn0: yes, but been in meetings for the past 2 hours
<wallyworld> partly done, but i'm not happy with the soluton
<wallyworld> as we can get address changes at any time
<wallyworld> and there's potential for at least 2 restarts as the state server comes up
<menn0> wallyworld: is there a way to avoid restarting the API server and just have the new cert be used for new connections?
<wallyworld> that's what i need to dig into
<wallyworld> when i first looked, it didn't seem plausible
<wallyworld> but i will have to look a bit harder
<menn0> wallyworld: that would be slickest solution (but I can see how it might be hard/impossible)
<wallyworld> yes, agreed. i did initially want to do that but since it appeared hard, it was easier to restart
<wallyworld> i didn't think it would matter
<wallyworld> as there would only be a very short window when the state server comes up
<menn0> wallyworld: turns out computers are pretty fast :-p
<wallyworld> menn0: scripting, yes
<menn0> wallyworld: that's what I mean
<wallyworld> i didn't think we'd be polling state server to jump in and grab a connection
<menn0> wallyworld: I don't think anything is polling
<menn0> wallyworld: as soon as the bootstrap command returns the tests (and my script) attempt to deploy a charm
<menn0> wallyworld: and that's often the same time the API server gets restarted
<wwitzel3> so if I want to make a change to the cloudinit DataSourceGCE python, is there an easy way to test that with Juju?
<thumper> ok, I have given up on getting this done today
<wallyworld> menn0: yeah, sorry, i didn't mean polling in the strictly literal sense, just a client that connected immediately after the state server comes up.
<thumper> however, I do have it to the state where I just need the tests
<wallyworld> still in meeting s o i haven't looked anymore yet
<thumper> and break it in half
<thumper> found that I have some state methods needed
<thumper> so I can land them independantly
<katco> thumper: sorry, he's all mine!
<thumper> he who?
<katco> thumper: ian
<thumper> katco: he's all yours, with my blessing
 * thumper ditches him while he has the opportunity
<thumper> no backsies
<katco> thumper: i thought you'd be more jealous
<katco> rofl
<thumper> happy holidays everyone
<thumper> I'll be back Jan 5th
<katco> thumper: happy holidays
<wwitzel3> see ya thumper, have a good one
<katco> thumper: be safe, have fun
<thumper> I foresee much hacking in the next two weeks
<thumper> and none of it in go
<thumper> python, javascript and C#
<thumper> laters
<katco> nice
<katco> anastasiamac: oh and i sincerely apologize for monopolizing ian's time. sorry about that
<katco> ok off to bed... tc and happy holidays to all of those for whom it is friday!
<menn0> katco: thanks... have a good break
<katco> menn0: you too good sir!
<menn0> wallyworld: I think I see a way to swap out certificates on the fly
<menn0> wallyworld: if you look at the implementation of the listener returned by tls.NewListener
<menn0> wallyworld: you can see that the config (which contains the cert) is passed to Server for each inbound connection
<menn0> wallyworld: so if you can change the cert in the config, new connections will use the new cert
<menn0> wallyworld: of course the config is kept private so we'd have to implement our own tls listener
<menn0> wallyworld: but that's trivial (it's tiny) and the part that does the hard work (Server) is public
<wallyworld> menn0: yep, i came to the same conclusion, but haven't been able to finish implementing because i've been ina meeting all day
<wallyworld> will complete the fix tonight
<wallyworld> i was wary of changing the tls config on the fly
<wallyworld> but on reading the tsl code in the std lib i think it will be ok
<wallyworld> it still feels a bit dirty, but hopfully will work
<menn0> wallyworld: there's a bit of restructuring to do to make the api server accessible to the certupdater isn't there?
<wallyworld> yes, but i'm part way through doing it
<anastasiamac> katco: np :) i got the whole 15 min of his time :)
<menn0> wallyworld: also, you'll probably need a mutex to protect updates to the config
<wallyworld> probably yes
<wallyworld> although i'm thinking of using a channel
<menn0> wallyworld: and I'd be tempted to take copies of the config so that existing connections keep their previous config
<wallyworld> there's only one server though
<wallyworld> the cert is only ever augmented with new addresses
<wallyworld> so i should just be able to replace on the fly
<menn0> wallyworld: there's one server but each time a connection is accepted a new Server instance is created and it gets a pointer to the config
<wallyworld> really?
<menn0> yep
<menn0> have a look at crypto/tls/tls.go in the stdlib
<wallyworld> the worker (which is the server) is run and then stays running
<menn0> the listener.Accept method
<wallyworld> it shouldn't matter as a new cert will accepts connections made previosuly
<menn0> wallyworld: you're probably right
<wallyworld> as we are just adding to the address list
<menn0> wallyworld: if that's the only change made to the cert
<wallyworld> that's the only change
<menn0> wallyworld: and the cert probably doesn't even get looked at once the connection is set up
<wallyworld> i can always iterate if we find an issue
<wallyworld> yes, that's my understanding
<wallyworld> i gotta run to relocate, will finish the fix tonight now that all my meetings are done
<menn0> wallyworld: I am still worried about what happens if the cert gets accessed (for a new connection) just as it's being updated
<wallyworld> me too, i have to think it through
<menn0> wallyworld: b/c I think the handling of connection happens in it's own goroutine
<menn0> wallyworld: np
<menn0> wallyworld: have a great xmas
<menn0> wallyworld: i'm about done
<wallyworld> menn0: you too, thanks for thinking through this issue with me, good that we converged on a similar approach
<wallyworld> have a good break
<menn0> wallyworld: yep that is a good sign
<menn0> wallyworld: (or we're both equally stupid)
<wallyworld> lol, well maybe
<menn0> wallyworld: it was fun to think about
<wallyworld> i will do it and test and see how it works
<wallyworld> i just wish i had more time today out of meetings to actually do the fix
<wallyworld> anyway, gotta run, be back later
<menn0> wallyworld: cool, speak later
<fwereade> davecheney, was just looking at state/multiwatcher, and wondering what RelationUnitsChange was doing in there?
<perrito666> morning all
<TheMue> morning perrito666
<frankban> fwereade: is there already a plan for importing the jenv files generated by "juju user add" to the environments directory of the juju home? perhaps something like "juju user import pat/to/jenv"? I am asking because we added support for using jenv files without a corresponding entry in environments.yaml in quickstart and that would complete the story.
<frankban> path/to/jenv even
<fwereade> frankban, yes, that's the heart of it, but I think we're calling it `juju connect`
<fwereade> frankban, thumper will have a better idea of when we can expect that than I do, though
<wwitzel3> fwereade: you know who I should talk to about a cloud-init question? smoser is out already
<fwereade> wwitzel3, hmm, not really :(
<wwitzel3> fwereade: dang, ok, thanks :)
<fwereade> wwitzel3, possibly gsamfira_ might know about it, what with cloudbase-init?
<wwitzel3> fwereade: ok, cool. I'm trying to figure out why my stored user-data on GCE isn't unpacking in to cloud-config
<fwereade> wwitzel3, sorry, nothing really springs to mind
<wwitzel3> fwereade: it is probably my fault, I think I might need package some headers with the base64 blob
<wwitzel3> fwereade: I will probably talk you throughout this process, you can ignore me, or just make unattentive bu supportive comments
<wwitzel3> talk at you that is
<fwereade> wwitzel3, have you tried dephlogisticating the grommets?
<fwereade> (sorry)
<fwereade> (talk away :))
<wwitzel3> fwereade: haha, no, that's perfect
<wwitzel3> fwereade: at least you weren't on the hangout with me yesterday, after doing nothing but hitting my desk and swearing for 5 minutes I told ericsnow "I should probably take a break"
<fwereade> wwitzel3, ouch
<wwitzel3> fwereade: but, when I came back, in like 5 minutes, I sovled the problem
<fwereade> wwitzel3, yeah, tuning those things is tricky though
<fwereade> wwitzel3, give up too early and the frustration just comes right back when you return
<fwereade> wwitzel3, wish I could tell what the optimal take-a-break moments are
<wwitzel3> fwereade: in my experience, you have to go until you break mentally *lolcry* .. that is how your brain resets and lets you look at the problem from a different view.
<wwitzel3> fwereade: or add booze ;)
<fwereade> wwitzel3, haha, yeah
<perrito666> for me the trigger is when the thought "this cant be done" arises
<wwitzel3> ericsnow: so looking at ec2's userdata, we send it up Base64 encoded, but it is stores decoded.
<wwitzel3> ericsnow: so I feel I've done proper due diligence in that we are doing the right thing in the GCE provider.
<wwitzel3> ericsnow: We need to update DataSourceGCE.py to b64decode the incoming raw user data from GCE.
<wallyworld> fwereade: hi, i have a fix for the CI blocker, would love it if you could take a look
<wallyworld> http://reviews.vapour.ws/r/667/
<wallyworld> perrito666: i didn't get a chance to look at the pr you mentioned sorry, spent all day in meetings and then had to fix a CI blocker
<perrito666> wallyworld: dont worry man
<TheMue> wallyworld: lgtm
<wallyworld> TheMue: awesome, tyvm
<TheMue> wallyworld: yw, nice solution. only stumble first over the call of processCertChanges and the go statement afterwards, but then I saw that it starts an anonymous goroutine too
<wallyworld> yes, sorry if it was unclear
<TheMue> wallyworld: it's fine, I like it
<fwereade> wallyworld, I'm not totally in love with the stop chan, wouldn't a tomb be a bit nicer?
<wallyworld> guess so, seemed like overkill
<wallyworld> the stop chan concept is use delsewhere
<hazmat> rogpeppe, if you could switch your examples to not being the store charm, it would be nice to send that email to the public list
<aznashwan1> perrito666: are you by any chance talking about the failing test when you set /utils to the latest commit?
<perrito666> aznashwan1: I currently have no clue what you are talking about
<fwereade> wallyworld, yeah, I know, but it's generally vulnerable to panic when double-closed, where tomb is fine with double-killing
<rogpeppe> hazmat: yeah
<aznashwan1> perrito666: because I ran into that on my latest PR and fixed it
<rogpeppe> hazmat: i need a decent example
<wallyworld> fwereade: fair point, i was assuming that listener close would only be done once
<wallyworld> fwereade: can i land to unblock and follow up? the listener is not closed during the normal operation of the state server
<aznashwan1> perrito666: there was a commit in /utils which changed a message and a test failed in core because of it, thus preventing you to get up to date
<fwereade> wallyworld, yeah, you're probably right, but that feels to me like exactly the sort of invariant that it's easy to break accidentally
<fwereade> wallyworld, yeah go for it
<wallyworld> ok, ta. i need to tweak the lxc cache. so i'll fix in that branch
<aznashwan1> perrito666: nothing major, just an ErrorMatches failing because an error was slightly modified, but it's solved now, and my latest PR will have utils set to its current HEAD
<dimitern> aznashwan1, that's *exactly* why we need to get utils and other subrepos under CI integration tests with core
<aznashwan1> dimitern: you make a very good point, /utils needing this most of all the others...
<dimitern> aznashwan1, we're discussing it and I'll push for it to happen sooner rather than later
<aznashwan1> dimitern: that would be awesome and I wish you the best of luck towards it :D
<dimitern> aznashwan1, thanks :)
<perrito666> natefinch: coming?
<TheMue> wallyworld: seen, the changeCertListener.Close() panics
<TheMue> wallyworld: ?
<natefinch> wallyworld: need someone to pick up that PR and try to push it through?
<natefinch> mgz_: looks like CI says no space left on device.... want to show me how to fix it so I can do it myself later?
<mgz_> you mean the gating job?
<natefinch> mgz_: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1691/console
<mgz_> that tends to just be a symptom of having got a bad instance on aws
<natefinch> mgz_: interesting
<mgz_> I don't think there's anything to do but wait for a bit, then try relanding later
<natefinch> mgz_: kk
<mgz_> it may also be the branch is bad
<mgz_> first panic is "runtime error: close of nil channel"
<natefinch> hmm
<natefinch> which is the cause and which is the effect?  That's the question.
<mgz_> it's possible panics are going to a drive on the instance without much room
<mgz_> which would be why we see it sometimes
<mgz_> (aart from the known we got a crummy instance thing)
<mgz_> does go dump itself somewhere by default during tests?
<natefinch> what do you mean dump itself?
<mgz_> stick anything on disk
<mgz_> a la segfault
<natefinch> mgz_: nope, the panic output is all you get
<katco> so it sounds like we're still working on getting CI unblocked?
<natefinch> katco: alas, yes
<katco> natefinch: Shower Thought: You and your wife might create a new human before we create the next version of Juju.
<natefinch> katco: haha yep
<perrito666> katco: they will, next version of juju is due jan 9
<katco> perrito666: :)
<natefinch> mgz_: I think I see the bug in wallyworld's code.  I'll fix it and see if I can repropose.
<mgz_> natefinch: ace
<natefinch> mgz_: he was closing a channel he never gave a value, which is why it was "close of a nil channel"
<katco> natefinch: that's not an error is it?
<natefinch> katco: sorry, when I say "never gave a value", I mean, he never initialized it to a valid channel
<katco> natefinch: ah gotcha, sorry
<natefinch> hmm... so my wife is having some contractions, not at all sure it's labor, but it's something.  Can someone else pick this up?  I made a comment at the bottom of the PR: https://github.com/juju/juju/pull/1346
<katco> good luck natefinch
<natefinch> thanks... might be nothing, she's had them before, but I probably shouldn't be on the computer ;)
<katco> :)
<katco> someone will take care of it, go go
<katco> mgz_: so catching up: will the tests fail on my machine for this bug?
<mgz_> katco: I expect the first panic to happen for you, the following fallout is mongo dependent, so may all be different
<katco> boy this was a catastrophic failure lol
 * katco is scrolling through the jenkins log
<mgz_> katco: yeah, the only bit you really need to care about is the first panic
<katco> yeah trying to figure out what the heck package failed first... looks like api?
<mgz_> the rest is pretty much just mongo falling over due to poor test isolation, which apparently also fills up our allocated /tmp space
<mgz_> yeah, api
<mgz_> the pr is 1346
<wwitzel3> ericsnow: https://bugs.launchpad.net/cloud-init/+bug/1404311
<mup> Bug #1404311: gce metadata api doesn't properly stream binary data <cloud-init:New> <https://launchpad.net/bugs/1404311>
<ericsnow> wwitzel3: nice!
<katco> mgz_: blindly trying nate's suggestion
<ericsnow> wwitzel3: you posting that to #cloud-init?
<katco> mgz_: found a few other issues. net.Serve closes the listener so we were also double-closing the channel, also our changeCertListener methods were operating on copies of the struct which meant they were locking copies of mutexes
<katco> mgz_: api package tests look like they're succeeding; i'll submit a pr after that to let CI run the full suite
<perrito666> I have a gramatical issue on my code
<katco> mgz_: PR incoming.
<alexisb> alrighty all, today is the last day before our holiday shutdown.  Please feel free to start you celebrations early once you get to a good stopping point on what you are working on
<alexisb> and enjoy your time off with family and friends!
<katco> alexisb: thank you!
<ericsnow> alexisb: you too
<katco> alexisb: happy holidays to you and your family :)
<alexisb> I am very much looking forward to the great work we will be doing in 2015
<alexisb> it will be an exciting year!
<TheMue> alexisb: thanks, also happy holidays to you and your family
<TheMue> katco: you added line 162 in apiserver.go based on nates diagnosis?
<katco> TheMue: correct
<TheMue> katco: ok, then lgtm, seen the other parts earlier
<katco> TheMue: as well as a few other things. look like a test in cmd/jujud/agent needs to be updated as well
<katco> TheMue: ty
<TheMue> katco: yw
<katco> TheMue: so you might be more familiar with these changes. i need to pass a channel in cmd/jujud/agent/upgrade_test.go:493: not enough arguments in call to a.apiserverWorkerStarter
<katco> TheMue: it doesn't look to me like the test cares, so i was just going to pass in a channel and do nothing with it.
<TheMue> katco: looking
<katco> mgz_: i'm in the process of fixing this, but why does it look like the CI run has frozen? http://juju-ci.vapour.ws:8080/job/github-merge-juju/1693/console
<TheMue> katco: machine.go line 798 the method defined in line 838 is used, the channel created one line before
<katco> TheMue: hm i see that. but the test that needed updating didn't look like it was trying to test cert upgrades at all, right?
<katco> TheMue: so we don't really care if certs are changed, right?
<TheMue> katco: we already cared before, by stoping and restarting the apiserver
<TheMue> katco: the test for this isn't changed, but the way how it is realized, now w/o a restart
<katco> TheMue: i'm sorry, i'm not understanding. i'm looking at TestLoginsDuringUpgrade in upgrade_test.go. I don't see any API server restarts in there?
<katco> TheMue: and i'm completely missing why a test for logging in during an upgrade would be concerned with cert changes?
<TheMue> katco: the important change is here: http://reviews.vapour.ws/r/667/diff/# machine.go line 802
<TheMue> katco: but I have to admit I don't know where it has been tested so far
<TheMue> katco: the old version does the restart, the new one signals the cert change, so that the listener reacts
<mgz_> katco: looks like one hang test, probably the reason for no output for ages
<TheMue> katco: that's in apiserver.go line 102, where the goroutine is started
<katco> TheMue: i'm still not understanding what all of that has to do with this test though? the test is not compiling because it doesn't have enough arguments anymore, and as far as i can tell it doesn't need to receive anything on this channel to test what it's trying to
<TheMue> katco: ah, I see, sorry, yes. This test hasn't been changed or the local change of wallyworld hasn't been checked in. so you have to change the test, sorry.
<katco> TheMue: oh no worries. i just was missing what you were trying to communicate :)
<TheMue> katco: no, you absolutely have been right, I missed the point regarding the test
<katco> TheMue: so my original question is: can you see any reason not to just pass it a channel and then not do anything with that channel? trying that, the tests hang
<katco> TheMue: trying to figure out why...
<TheMue> katco: if you only pass in a channel and nobody listens a sending will block the system
<katco> TheMue: i created a buffered channel
<katco> make(<-chan params.StateServingInfo, 1)
<TheMue> katco: ok, then I would have to digg deeper too
<katco> TheMue: but conceptually, you don't see ignoring that channel as an issue?
<TheMue> katco: based on the title of this tests it's focussing the login during upgrade, no cert change
<TheMue> katco: so yes, this shouldn't be an issue here
<katco> TheMue: great, ty... i'll continue trying to figure out why the test hands with a buffered channel =/
<TheMue> katco: I'm lurking here into the channel a bit longer, so feel free to ping me
<katco> TheMue: thanks, i appreciate it :)
<TheMue> katco: yw
<katco> TheMue: if i end up not talking with you again, happy holidays!
<TheMue> katco: thanks. also to you happy holidays.
<katco> TheMue: ty!
<katco> found the issue
<katco> deleted the closing of the stop channel from the wrong place. re-running api tests now
<katco> any CI people around? if this fix works, i'd like to open the trunk
<katco> mgz_: ^
<mgz_> katco: go for it
<katco> mgz_: i didn't realize i could open the trunk. how do i do that?
 * perrito666 is back from 2 hs without internet nor power... gotta love summer
<katco> wb perrito666
<mgz_> katco: you wait for the rev to get through gating, then go through the rest of the jobs (can track on jenkins or the report site), then mark bug as fix released when the revision is blessed
<perrito666> ericsnow: ping
<perrito666> katco: tx
<katco> mgz_: oh cool. i don't think i've ever done that.
<ericsnow> perrito666: hey
<katco> mgz_: will you be around if i have questions? or is anyone else familiar with this process?
<katco> i don't know what reports to look at. i'm guessing 1.22-alpha1 for a bless?
<katco> oh i need to backport this to 1.21 don't i.
<katco> for beta 5?
<perrito666> I tried to make a nap during the blackout but was recruited by my wife -> https://twitter.com/majomalnis/status/546021647632052225 you have no idea how hard is to make those with >30C
<katco> perrito666: yum :)
<katco> well, the bug is only marked for 1.22, so i guess i don't have to backport this
<perrito666> katco: oh, they are tasteless :p until you add the white stuff
<katco> perrito666: are they sugar cookies?
<perrito666> katco: no, animal cookies actually
<perrito666> they must be glaced to have some taste
<katco> perrito666: i don't think i know what that is lol
<perrito666> really? I thought they where fairly common its an english recipe
<perrito666> small animal shaped cookies
<katco> ohhh
<katco> like animal crackers perhaps?
<perrito666> http://books.google.com.ar/books?id=OlIOxYU2YWsC&pg=PT73&source=gbs_toc_r&cad=3#v=onepage&q&f=false
 * perrito666 shares the source code :p
<katco> haha
<TheMue> so, working with red wine surely is no good base for proper code. ;) working day is over. i wish you all a merry christmas and a happy new year. see you all freshly charged in the new year. o/
<perrito666> TheMue: likewise, enjoy that wine
<katco> TheMue: tc! happy holidays!
<perrito666> ok, attempt n 19831287319238 to finish today's work without being interrupted
 * katco is trying to figure out where a test is hanging, and go test is not giving me any output
<bodie_> I'm trying to figure out how to get a state testing unit's charm URL
<perrito666> ericsnow: still here?
<ericsnow> perrito666: yep
<perrito666> metadata know about series?
<bodie_> it seems that the testing unit doesn't have the charm URL in its doc, but I'm not sure how to get that where it needs to go.  I'm using state.AddCustomCharm
<perrito666> ericsnow: ?
<ericsnow> hey
<katco> is anyone familiar with the dummy provider?
<ericsnow> katco: other than that we use it in our tests, sorry no
<katco> bleh
<katco> why is -gocheck.vv not scrolling output for me. it's making it impossible to diagnose this
<perrito666> katco: the other day nate said that I should also -check.v=true to get that working
<katco> perrito666: sweet let me try that
<katco> nothing =|
<katco> go test github.com/juju/juju/cmd/jujud/agent/... -check.v=true -check.vv=true -gocheck.f=TestManageEnvironV
<katco> (note that i modified the name of that test to include a V to differentiate between other tests)
<natefinch> katco: I see things are going as well now as when I left earlier
<katco> natefinch: hey welcome back
<katco> natefinch: i fixed some things but there is a test hanging somewhere and i can't get any output from go test so i can put tracers in
<katco> natefinch: if i pepper in panics, i can figure out what's hanging, but c.Log, fmt.Println, doesn't show anything. and no amount of v's coerce gocheck into giving me anything.
<natefinch> katco: I think you need to give it test.v before anything shows
<katco> natefinch: yeah i did
<natefinch> hmm
<katco> natefinch: here are the changes: https://github.com/katco-/juju/commit/9e7758f27625a139ee8f8c87827278c2f8b18559
<katco> natefinch: and something is hanging in MachineSuite in cmd/jujud/agent/machine_test.go; i think it's TestManageEnviron
<katco> natefinch: i'm toying with the idea of landing my refactoring changes, because it makes it cleaner to get a machineagent which may help this problem along
<katco> natefinch: b/c right now it appears (???) to be hanging on a newAgent
<natefinch> hmm the agent tests pass for me on your branch
<katco> http://juju-ci.vapour.ws:8080/job/github-merge-juju/1694/console
<katco> i'll submit again in the off chance it was a fluke, but i can't get them to pass on my machine now
<natefinch> katco: your comment says net.Server was closing the stop channel already?   I don't see how that's possible
<katco> natefinch: where did i see that...
<katco> natefinch: http://golang.org/pkg/net/#Conn
<katco> natefinch: https://github.com/katco-/juju/commit/9e7758f27625a139ee8f8c87827278c2f8b18559#diff-19f910c28876da8a8d94937e102b2ebeR96
<natefinch> katco: yeah but that doesn't close the stop channel, which is what kills that goroutine.  It'll just stick around forever... but I think the close of the channel should be there.
<bodie_> code freeze is today, yes?
<bodie_> I had a branch which fwereade requested in rather strong terms to be in the release
<bodie_> it seems there might have been a miscommunication with TheMue, I was traveling yesterday and thought we were in sync to get it landed
<bodie_> https://github.com/juju/juju/pull/1341
<katco> natefinch: sorry trying to remember my reasoning. with that in there, we definitely get a double close error
<bodie_> this is important to me if it's still possible to land -- it's merely a few testing changes to master and the inclusion of a new charm version which includes a MUCH cleaner ux for Actions
<natefinch> katco: it's probably the Close() method on changeCertListener getting called more than once.
 * bodie_ nudges natefinch in the hopes of getting a pair of in-crowd eyes on this...
<katco> natefinch: tomb was calling it, and then i though the listener
<natefinch> katco: but right now nothing is going to be closing the channel
<katco> bodie_: trunk is blocked on this bug =/
<natefinch> and unfortunately I have to run....
<bodie_> gotya, does that mean this can't land before freeze or what should I expect?
<bodie_> or who should I talk to?
<natefinch> bodie_: no idea.  If we want it in, it'll get im/
<natefinch> in
<katco> bodie_: i've been trying my best to open trunk, don't know if i'll succeed. i'm running into issues
<bodie_> okey doke
<natefinch> bodie_: I've never met a code freeze that wasn't more of a slushy
<bodie_> the addition of pressure lowers the freezing point of code :P
<natefinch> lol exactly
<natefinch> ok gotta run before I get divorced
<bodie_> lol XD
<bodie_> katco, lmk if I can pitch in anywhere -- I'm with my family, but if it's crucial I'm sure I can squeeze in a couple of hours
<katco> bodie_: will do... reevaluating what nate said
<katco> bodie_: do you know what to do when CI runs out of space?
<katco> mgz_: ^^ on the off chance you're still on
<perrito666> ohh cmooon again?
<perrito666> CI was out of space this AM
<katco> =/
<mgz_> katco: if you mean the landing job, see the log
<katco> perrito666: what fixes it?
<mgz_> it's an ephemeral image just for the tests
<mgz_> it doesn't run out of space unless the instance happens to be bad, or the tests fail horribly enough to fill /tmp
<mgz_> *instance
<katco> mgz_: ah ok. so then a fresh tests gets a new image?
<perrito666> well that was failing this am already
<mgz_> katco: yes
<katco> mgz_: ok that makes sense
<katco> mgz_: ty :)
<mgz_> perrito666: the same branch has been failing
<mgz_> land anything else it's almost certainly fine
 * katco is hoping she finally has it fixed, running tests locally again atm
<bodie_> mgz_, I made a tweak to charm which fwereade was really keen on, and opened a PR to fix testing in master
<bodie_> mgz_, I thought TheMue and I were in sync to get it landed yesterday, but I think we had a misunderstanding since I landed the charm changes but not the ones in juju core
<bodie_> mgz_, I'm wondering how I should make sure this is in 1.22 since it's a user-facing issue we really want to get in
<bodie_> I don't know who to talk to or what to do about this and it's making my skin crawl.. :S
<katco> bodie_: i'm submitting another test run. the test is hanging on my machine, but there's no reason not to try it while i fiddle with things. if you want to help out, you can try testing cmd/jujud/agent/... and find out where it's hanging
<katco> bodie_: sorry on this PR: https://github.com/juju/juju/pull/1347
<katco> bodie_: i cannot for the life of me get gocheck to feed me verbose output.
<bodie_> sure, let me give that a spin.  can I get a quick glance over RB 661?  it's really quite trivial
<katco> bodie_: sure
<perrito666> ok fine gentlemen and ladies, EOD
<katco> bodie_: not exactly sure what i'm looking at. does the new version of charm change the outfile key to snapshot?
<perrito666> have all a nice end of year and overall holidays whatever you belief is
<katco> perrito666: happy holidays, tc
<bodie_> katco, basically it just reduces the boilerplate for actions.yaml
<bodie_> katco, the change to do it is already landed in charm; this just updates master for the required testing changes
<katco> bodie_: seems benign. lgtm
<bodie_> ^_^
<mgz_> bodie_: does it have an associated bug on launchpad?
<katco> bodie_: especially since it is tweaking the tests
<mgz_> bodie_: if so, target it to the milestone, otherwise you can file a bug to go along with maybe
<bodie_> that sounds like a good option
<bodie_> thanks mgz_
<bodie_> there's not a bug
<katco> mgz_: ty for being so helpful past your EOD the last day of the year
<mgz_> :)
<bodie_> indeed
<fwereade> katco, driveby: `go test <whatever> -test.v -gocheck.vv` should give you enough?
<katco> fwereade: ty, but this gives me nothing until the process times out: go test -v github.com/juju/juju/cmd/jujud/agent/... -check.v=true -check.vv=true
<katco> bodie_: are you experiencing the same issue with the test hanging?
 * bodie_ hails fwereade -- https://bugs.launchpad.net/juju-core/+bug/1404397
<mup> Bug #1404397: charm actions.yaml simplification breaks master tests <actions> <charm> <juju-core:New> <https://launchpad.net/bugs/1404397>
<bodie_> katco, just taking a crack at it after opening the bug
<katco> bodie_: no worries, thank you
<bodie_> katco, go version?
<bodie_> I don't suppose it makes a difference since CI isn't taking it
<katco> bodie_: 1.3.3
<katco> bodie_: i made 1 change since i resubmitted; we'll see if this latest version works out
 * katco sighs
<katco> the CI test is now failing in api/watcher
<bodie_> O.o
<katco> that seems fairly random to me
<katco> it timed out
<bodie_> katco, fetching but not seeing your change
<katco> it's an ammendment
<bodie_> ah
<bodie_> katco, api/watcher/... passes for me on your branch
<bodie_> let's see what happens when I do a whole-hog juju test
<katco> bodie_: i also resubmitted the job. again.
<katco> bodie_: it hadn't failed in those places yet. provider/dummy also failed
<katco> bodie_: which is currently hung, but with the output i couldn't get from cmd/jujud/agent
<katco> either i really didn't get enough sleep last night or this is all fairly random
<bodie_> you just haven't sacrificed to the loa recently
<katco> lol
<bodie_> fwiw, my laptop is just about exactly as fast as the CI server....
<katco> lol
<katco> if this fails i'm going to EOD. i was on very late last night and i don't think i'll solve this
<bodie_> so, on that note, my anemic laptop is well past api/watcher
<katco> and CI is still on the package after api/watcher
<bodie_> oh and there we go.  something blew up
<katco> i think it's going to time out
<bodie_> test ran too long on mine.
<bodie_> :/
<bodie_> I'll give it a whack on the digitalocean 8-core instance
<katco> where did you time-out?
<bodie_> still running, but here's the output so far
<bodie_> not sure why it's still running come to think of it
<bodie_> looks like apiserver, but not really obvious where or why
<bodie_> http://paste.ubuntu.com/9574300/
<katco> that's where CI is going to hang. there's a bug for sure. it's where the changes are centered
<katco> yup CI has failed
<bodie_> katco, my hunch is that whatever was supposed to release the semaphore hold didn't
<bodie_> that might be obvious
<katco> it's definitely something along those lines
<katco> i am too fried to debug threading atm -.-
<katco> so i'm going to EOD. sorry i couldn't get trunk unblocked
<bodie_> it seems there are many goroutines which were in a semacquire state at time of death
<bodie_> take care :) and merry christmas / happy festivus
<katco> happy solstice in my case :)
<katco> but happy holidays to you
<bodie_> perhaps it would be useful in debugging to keep track somehow of who has the lock
<bodie_> I see only three goroutines which were killed while waiting for lock in apiserver.(*changeCertListener).Close
<bodie_> which traces to http://golang.org/src/sync/mutex.go line 66
<bodie_> fwiw
<bodie_> but that's not where the problem is; that's merely the symptom
<bodie_> whoever had the lock perhaps was waiting on io
<bodie_> and there are an enormous number of IO Wait-ing goroutines
<bodie_> perhaps the cert was never sent
<bodie_> I sense a perturbance in jujud/agent/upgrade_test.go line newApiserverWorker line 493 (nil channel)
<bodie_> katco ^ hope that helps
<bodie_> but I'm not certain what the intent is
<bodie_> EOD/holiday for me, take care all!
 * bodie_ would like someone to vet bug 1404397 since it's a big Actions usability improvement
<mup> Bug #1404397: charm actions.yaml simplification breaks master tests <actions> <charm> <juju-core:New for binary132> <https://launchpad.net/bugs/1404397>
#juju-dev 2014-12-20
<katco> wallyworld___: ping
<wallyworld___> hi
<katco> wallyworld___: hey thanks for trying to land that change. sorry we couldn't get it fixed
<katco> wallyworld___: i saw that the changeCertListener methods were operating on copies of the structs, which means the mutexes in the struct won't work
<wallyworld___> no problem, it is shit i didn't get it fixed properly. i'm landing now but bot keeps fsiling on a couple of dumb tests
<katco> doh
<wallyworld___> i'll check the struct issue, thanks
<wallyworld___> hmmm, you're right. bullocks, i'll fix
<wallyworld___> sigh
<katco> you're almost there! :)
<wallyworld___> if the bot passes, yes
<katco> i know the feeling
<katco> to prove it to myself: http://play.golang.org/p/By4lI7Du_9
<katco> and then correct: http://play.golang.org/p/tNgAoKznSC
<katco> that's a sneaky bug.
<wallyworld___> yeah, i meant to use a pointer but clearly my stupid fingers didn't type the *
<wallyworld___> good pickup
<wallyworld___> hopefully bot will pass this time, we'll see
 * katco crosses fingers
<katco> alright i'm off to bed
<katco> happy holidays!
<wallyworld___> you too, thans again
<ericsnow> wallyworld___: you are my hero
<wallyworld___> oh?
<ericsnow> the test you just fixed :)
<wallyworld___> well, it was originally my crappy assumption that led to the issue, so i had better fix it
<ericsnow> regardless, I'm glad you stuck with it!
<wallyworld___> yeah, hated to see it hanging aound
<ericsnow> so you waiting for other CI tests to run before marking if fix released?
#juju-dev 2015-12-14
<mwhudson> omg i submitted a PR to juju!
<mwhudson> https://github.com/juju/juju/pull/3958
<rick_h_> mwhudson: whoa!
<rick_h_> :)
<dimitern> voidspace, dooferlad, frobware, o/ morning
<frobware> dimitern, morning
<voidspace> dimitern: frobware: dooferlad: o/ morning
<voidspace> dimitern: dooferlad: welcome back :-)
<dimitern> cheers :)
<dimitern> dooferlad, I was looking at your WIP branch - you should get all 3 endpoints bound - 1 explicitly, 2 implicitly to @default
<dimitern> dooferlad, I suspect there's something around adding the charm (and/or metadata)
<dimitern> there are other examples in the same test package - have you tried using s.UploadCharm ?\
<frobware> dimitern, can we chat about /e/n/i after standup?
<dimitern> frobware, sure
<dimitern> frobware, I've realized some time after I sent the last mail to you, that we can use the interfaces list of the node, right after creating it (or even earlier, if there are bindings passed to acquire) to get which NICs are active and create bridges for them only, eliminating the guesswork
<frobware> hmm
<frobware> dimitern, I had some concerns about our bridge the world approach.
<frobware> dimitern, isn't it too late by then though? this is happening in cloud init
<dimitern> frobware, hmm. that's right
<dimitern> frobware, but at the time acquire returns (maybe with verbose=1 as well), we should get all the information we need about the interfaces maas knows about that node
<voidspace> dimitern: stdup
<dimitern> voidspace, omw
<voidspace> dimitern: cool
<mup> Bug #1525868 opened: Uniter state file empty after node crash <juju-core:New> <https://launchpad.net/bugs/1525868>
<frobware> dimitern, can we have a quick HO re: address allocation
<dimitern> frobware, sure, just give me ~10m to finish this test?
<frobware> dimitern, ok; ping when convenient.
<frobware> dimitern, which can be longer than 10m ... :)
<dimitern> frobware, will do, sorry I've *almost* nailed the critical bug - finishing the last unit & live tests, so I can get over with it
<frobware> dimitern, sure - don't rush.
<dimitern> frobware, ok, HO?
<dimitern> frobware, I'm in the standup one - join when you can
<frobware> dimitern, omw
<dimitern> virtuous-lettuce-juju-machine-0-kvm-2.maas-19 is better than juju-machine-0-kvm-2-00249376-2c6a-4243-8c39-7d88008ee3c8.maas-19
<mup> Bug #1525959 opened: juju 1.25 Alpha2 deploy fails with our existing bundles  <oil> <juju-core:New> <https://launchpad.net/bugs/1525959>
<frobware> dimitern, ping - you still about?
<dimitern> frobware, yep
<frobware> dimitern, should aliases, whose underlying device is now bridged be "juju-br-eth0:1" or remain as "eth0:1"?
<frobware> dimitern, it's really a naming issue only
<dimitern> frobware, I think it should be fine to leave them alone
<frobware> dimitern, http://pastebin.ubuntu.com/14007098/
<dimitern> they don't work very well with curtin anyway - I don't think we need to care about aliases now
<dimitern> frobware, that looks good to me
<frobware> dimitern, you sure? That's what we currently do but I think we should drop the alias
<voidspace> dimitern: ERROR juju.worker runner.go:226 exited "discoverspaces": unknown object type "DiscoverSpaces"
<frobware> dimitern, drop the "juju-br" prefix from the alias
<voidspace> dimitern: this looks to me like the DiscoverSpaces facade is not registered properly
<dimitern> frobware, so long you have it already and if it works (after the 120s cloud-init-nonet delay..) let's keep them
<voidspace> unfortunately I tore down the environment before properly looking at the logs
<voidspace> re-bootstrapping *grrr*
<dimitern> voidspace, heh, yeah - check init() funcs in apiserver - that's where it happens usually
<voidspace> dimitern: yeah, init is there
<dimitern> voidspace, hmm.. is the version v0 or v1 ?
<voidspace> dimitern: it was 0, I just bumped it to 1 but not pushed yet
<voidspace> would that make a difference?
<voidspace> it should be 1 for a new facade, right?
<dimitern> frobware, I don't mind the prefix, the important thing is whether it works :)
<dimitern> voidspace, all new facades should be v1 when introduced
<voidspace> yeah, I doubt that's the problem though...
<dimitern> voidspace, that was decided at some point, but might be irrelevant
<mup> Bug #1525959 changed: juju 1.26 Alpha2 deploy fails with our existing bundles <bundles> <oil> <juju-core:Won't Fix> <https://launchpad.net/bugs/1525959>
<voidspace> logs don't have any more useful information, will have to actually work out the problem...
<dimitern> voidspace, check if the api/ side is calling the correct method and facade name
<voidspace> facade name is correct
<voidspace> will add more logging in the worker
<dimitern> voidspace, alternatively, might be a permission thing?
<voidspace> dimitern: could be, although I would expect (hope?) for a different error message
<voidspace> adding logging to see
<mup> Bug #1525959 opened: juju 1.26 Alpha2 deploy fails with our existing bundles <bundles> <oil> <juju-core:Won't Fix> <https://launchpad.net/bugs/1525959>
<mup> Bug #1525959 changed: juju 1.26 Alpha2 deploy fails with our existing bundles <bundles> <oil> <juju-core:Won't Fix> <https://launchpad.net/bugs/1525959>
<mup> Bug #1526003 opened: Data race in undertaker <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1526003>
<mup> Bug #1526063 opened: TestNoContextWithLock <ci> <intermittent-failure> <test-failure> <juju-core:New> <juju-core maas-spaces:New> <https://launchpad.net/bugs/1526063>
<mup> Bug #1526072 opened: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted <oil> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1526072>
<mup> Bug #1526072 changed: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted <oil> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1526072>
<mup> Bug #1526072 opened: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted <oil> <juju-core:New> <juju-deployer:New> <https://launchpad.net/bugs/1526072>
#juju-dev 2015-12-15
<mwhudson> anastasiamac: could you look at https://github.com/juju/juju/pull/3961 (it's not getting into reviewboard for some reason)
<cmars> anastasiamac, thanks!
<anastasiamac> mwhudson: of course \o/
<mwhudson> anastasiamac: thanks
<anastasiamac> mwhudson: lgtm :D
<mwhudson> anastasiamac: thanks. how do i merge it? :-)
<anastasiamac> mwhudson: i believe that there is a bot on this repo... have u tried $$merge$$?
<mwhudson> no, let's find out
<anastasiamac> k
<perrito666> hey good morning
<anastasiamac> perrito666: hi o/
<anastasiamac> how is sunshine coast?
<perrito666> nice and sunny
<anastasiamac> aeesome \o/
<anastasiamac> i hope hot too - m removing all long-sleeve stuff from suitecase :D
<wallyworld> cherylj: i think it's a one line, fix, http://reviews.vapour.ws/r/3386/
<cherylj> wallyworld: lgtm.  Let's hope that's it :)
<wallyworld> cherylj: i think it is jusdging by the error
<wallyworld> cherylj: the cutover for alpha2, that's in a few hours?
<cherylj> yeah, no.  I don't think we're going to get an alpha1 out this week.
<wallyworld> cherylj: works well for me then - i have a couple of series in metadata fixes i want to do later today
<cherylj> heh, sounds good :)
<wallyworld> about about to leave for sprint, will do them later tonight
<cherylj> have a safe trip, wallyworld :)
<wallyworld> cherylj: will do, it's only a 2 hours drive :-)
<wallyworld> not a 16 hour flight :-)
<cherylj> ha, nice
<anastasiamac> cherylj: and i will b driving - so wallyworld will be safe \o/
<anastasiamac> :D
<dimitern> frobware, hey, sorry I missed our 1:1
<frobware> dimitern, np
<voidspace> dimitern: Error handling subnets "Default space" is not a valid tag
<voidspace> dimitern: that's  great!!
<dimitern> voidspace, you should upgrade your maas :)
<voidspace> dimitern: lots of problems with rc3
<voidspace> staying with rc2 was deliberate
<voidspace> dimitern: think it's worth upgrading?
<voidspace> dimitern: frobware has had various issues with the upgrade (node addresses and leases)
<dimitern> voidspace, since rc2 or thereabouts spaces are now called "space-0" and fabrics like "fabric-0"
<voidspace> dimitern: anyway, I'll just add name translation
<voidspace> dimitern: facade registration worked
<dimitern> voidspace, is "Default space" the name or the description?
<voidspace> dimitern: name
<dimitern> voidspace, I'd first try renaming that to "space-0"
<dimitern> voidspace, it used to be forbidden to change the default space's name
<dimitern> voidspace, if you can change it with $ maas <profile> space update 0 name=space-0
<voidspace> dimitern: yeah, I did that - now I get "foozle" is not a valid tag, so there's obviously more I need to do in my code
<voidspace> ("foozle" was the random name I picked)
<voidspace> ah, maybe I'm using space name on subnets when I should be using tags
<dimitern> voidspace, yeah - that was what we talked about yesterday I think - space tags are "space-<name>" and should be used instead of space name in api params (except for creating a new one I guess - except to check for dupes)
<frobware> dimitern, can we sync?
<dimitern> frobware, sure - standup HO?
<frobware> yep
<mup> Bug #1526296 opened: deploy charm with --series --force doesn't reject invalid OS <juju-core:Triaged> <https://launchpad.net/bugs/1526296>
<mup> Bug #1526296 changed: deploy charm with --series --force doesn't reject invalid OS <juju-core:Triaged> <https://launchpad.net/bugs/1526296>
<mup> Bug #1526296 opened: deploy charm with --series --force doesn't reject invalid OS <juju-core:Triaged> <https://launchpad.net/bugs/1526296>
<abentley> cherylj: Good morning.  Bug #1526063 has only been observed in the maas-spaces branch.  I meant to mark it incomplete for master, since we don't have evidence that it's there.
<mup> Bug #1526063: TestNoContextWithLock <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core maas-spaces:Triaged> <https://launchpad.net/bugs/1526063>
<abentley> cherylj: But if we do mark it high in master, we have been assigning it to a milestone also.
<voidspace> dimitern: what's the correct way to create a tag - first check it's valid and then call New*Tag ?
<dimitern> voidspace, it depends on what New*Tag() does, but most of them IIRC call IsValid*Tag() and panic if it's not
<voidspace> dimitern: right, that's why to check if valid first
<dimitern> voidspace, so it's better to check before calling it
<voidspace> dimitern: if *not* that, then what?
<voidspace> so that is the correct way
<voidspace> thanks
<dimitern> voidspace, where are you getting the name from?
<voidspace> dimitern: subnet.CIDR and space.ProviderId
<voidspace> (I've got past the tag probl
<voidspace> oops
<cherylj> abentley: I marked it as triaged for both, as both seem to have the same code
<dimitern> voidspace, so ProviderId can be anything, so but you're not validating it anyway, right?
<voidspace> dimitern: I'm doing a simple transform first in my current code
<dimitern> voidspace, as for the CIDR, if it's invalid and you want to convert it to a subnet tag, then it's an error
<voidspace> sure
<voidspace> it's the actual mechanics of creating the tag I was asking about
<voidspace> currently I have a panic on the apiserver when trying to list spaces - nil pointer dereference
<dimitern> voidspace, hmm does it say where?
<voidspace> calling space.ProviderId()
<voidspace> in reflect/value.go from ProviderId()
<voidspace> which is new
<voidspace> interesting
<voidspace> if a field is "omitempty" in a doc then will accessing it get you a nil pointer dereference?
<voidspace> I just assumed that for a string, omitempty would default to an empty string
<mup> Bug #1517258 changed: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1517258>
<voidspace> dimitern: ah, spaceShim doesn't have a ProviderId
<voidspace> I think that's it
<mup> Bug #1517258 opened: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1517258>
<voidspace> that makes more sense
<dimitern> voidspace, right :) missed that one
<mup> Bug #1517258 changed: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1517258>
<dimitern> dooferlad, you've got a review
<dooferlad> dimitern: thanks!
<mup> Bug #1517258 opened: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1517258>
<mup> Bug #1517258 changed: juju 1.24.7 precise: container failed to start and was destroyed <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1517258>
<voidspace> dimitern: you didn't miss it, ProviderId is new
<voidspace> dimitern: I didn't realise it would need to be added to spaceShim as well
<voidspace> re-bootstrapping now
<frobware> dimitern, you about for 10-15 mins after the OS call?
<dimitern> voidspace, heh I meant you added that recently to AddSpace et al, right? :)
<dimitern> frobware, sounds good
<frobware> dimitern, as a heads-up just trying to add to the release notes for the AWS support post 15.10
<dimitern> frobware, ah, nice
<dimitern> frobware, I though I already added something about it in Juju 1.25.0 Release Notes doc
<frobware> dimitern, it's the stuff we've done since then, mostly bug fixes IIRC
<dimitern> frobware, +1
<voidspace> dimitern: space imported on bootstrap!
<dimitern> voidspace, awesome!! \o/
<dimitern> voidspace, so as soon as my other branch lands, they should be usable in constrains right after bootstrap
<voidspace> dimitern: hmm... but not the subnets
<voidspace> dammit
<voidspace> ok, next step of debugging
<dimitern> voidspace, ah :)
<dooferlad> dimitern: replied to review - just a query about your comment about the comment...
<cherylj> hey dimitern, are you still working on bug 1525280?
<mup> Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged by dimitern> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1525280>
<katco> cherylj: did you already bump the min version blueprint to a2?
<cherylj> katco: yes, let me re-generate the tracking page
<katco> cherylj: ty for doing that
<dimitern> dooferlad, cheers - replied
<dimitern> cherylj, hey, I'm still sorting out a few issues and testing but it will be ready today
<cherylj> awesome, thanks dimitern
<frobware> dimitern, if you would like a tester for your change I can help
<dimitern> frobware, I'll push the changes during the OS call
<dimitern> frobware, it will be good to get a second verification
<dimitern> voidspace, openstack call?
<voidspace> dimitern: omw
<natefinch> katco: you said no retrospective this friday, right/
<katco> natefinch: yeah i'm going to cancel
<natefinch> katco: ok, cool, just making sure.
<katco> natefinch: you still need to show up for work though :)
<natefinch> katco: awww man
<voidspace> dimitern: hmm... just had a thought, I bet adding a subnet with a spaceTag isn't sufficient to associate it with that space is it
<voidspace> I bet I need to do more...
<voidspace> hmmm... no, that's not the root problem - subnet list is also empty even though it found the subnets from the provider and called AddSubnet
<voidspace> I wasn't checking the result error field in the first cut though - I've added that now
<voidspace> so at least I should see an error if one occurs
<voidspace> dimitern: error creating subnet SubnetTag and SubnetProviderId cannot be both set
<voidspace> dimitern: so that's straightforward
<dimitern> voidspace, ah :)
<dimitern> voidspace, yeah - use the provider id
<voidspace> dimitern: ok
<voidspace> dimitern: which means we don't use the CIDR at all creating the subnet
<dimitern> voidspace, we do on AWS
<dimitern> as an alternative to using provider id
<dimitern> voidspace, the idea is, if you have provider-id, you can uniquely identify the subnet, whereas with just a CIDR it might be ambiguous (depending on how it's specified)
<voidspace> dimitern: next issue is in the maas provider itself
<voidspace> dimitern: exited "discoverspaces": error creating subnet cannot get provider subnets: instance "" not found
<voidspace> dimitern: that's new code, so obviously needs some work
<voidspace> (the new subnets code)
<voidspace> on the apiserver side
<voidspace> it's an interesting journey :-)
<dimitern> voidspace, dooferlad, frobware, please have a look http://reviews.vapour.ws/r/3388/ - fixed the critical bug 1525280
<mup> Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged by dimitern> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1525280>
<dimitern> voidspace, I've fixed that in my other branch btw
<mgz> dimitern: this is address allocation only right?
<dimitern> voidspace, have a look please - one more thing to do and will set it to land: https://github.com/juju/juju/pull/3921
<dimitern> mgz, nope
<dimitern> mgz, it's the default behavior now
<dimitern> mgz, but I tried not to break the addressable containers as well
<mgz> dimitern: sorry, should have been clearer, this is only an issue when we have explict address allocation on, as in 1.25 or 1.24 with flah?
<dimitern> mgz, ah, well.. that's a good question
<dimitern> mgz, I think it's fine with the flag still
<dimitern> mgz, but just doing a quick test now on 1.25+1.9rc4+address-allocation
<voidspace> dimitern: EOD, but I can look later tonight
<dimitern> voidspace, cheers, if you can I'll appreciate it
<voidspace> dimitern: yep
<voidspace> dimitern: ah, I thought empty instance id already worked!
<voidspace> dimitern: I thought I'd done that, my fault then :-)
<frobware> dimitern, should I expect a different name. I see: instance-id: juju-machine-0-lxc-0
<dimitern> frobware, in status it will be the same, but if you check the node details on the web UI, you should see a section about containers and VMs and it will be there with the unique hostname
<katco> natefinch: wwitzel3: have you had a chance to review ericsnow 's patch? http://reviews.vapour.ws/r/3375/
<natefinch> katco: almost done with mine
<dimitern> mgz, it's good that I checked, as it turned out I did break the addressable containers unintentionally; fortunately it's quite easy to fix
<frobware> dimitern, mgz: we need (developer-centric) automation in this area. Too much manual testing... :(
<katco> natefinch: also, is your patch ready to be reviewed?
<katco> natefinch: or still a wip?
<frobware> dimitern, in the new year we should have a spike on automation
<natefinch> katco: it is ready to be reviewed
<katco> natefinch: sweet tal
<frobware> dimitern, its says "fixed" for me.  fixed-kitten-juju-machine-0-lxc-0.maas :)
<dimitern> frobware, awesome, isn't it? :)
<frobware> dimitern, want me to sanity test with multiple nics or shouldn't it matter?
<dimitern> frobware, it might matter, the more tests the better - but don't feel obliged
<frobware> dimitern, looking again at your revised patch
<dimitern> frobware, cheers - pure luck I got that on the first attempt (a second test triggered it after a few attempts)
<katco> natefinch: review up. should have some things to address
<natefinch> katco: cool, thanks.
<frobware> dimitern, how come allocate-address worked without requiring a pointer before?
<dimitern> frobware, :) long story - it basically expected to get a concrete address to try allocating
<dimitern> frobware, so it didn't need to return anything but an error
<frobware> yuck
<frobware> dimitern, I could do this in the review but figured we might go quicker here: splitting host on '.'  what happens for some-host.qacdo.maas?
<dimitern> frobware, it will work as funny-joke-juju-machine-1-lxc-1.qacdo.maas"
<dimitern> frobware, hmm.. but I think I check if the parts are exactly 2 - good point!
<frobware> dimitern, right
<frobware> dimitern, line 1405 I think is the issue, not necessarily the split
<dimitern> frobware, yep, good catch
<frobware> dimitern, Is vs IS - is the plan to fix them up as we find them?
<frobware> dimitern, correction: Id vs ID
<dimitern> frobware, that's a can of worms right there :) the consensus seems to point towards ID recently though
<frobware> dimitern, fwiw - for me it would be better to do this in a different PR - less to review
<dimitern> frobware, agreed - these are just a few drive-by fixes
<wwitzel3> ericsnow: looking at your patch now
<wwitzel3> katco: ^
<dimitern> dooferlad, fwiw the merge bot doesn't take kindly $$c o m m e n t s$$ with spaces apparently
<frobware> dimitern, why did so many of the IP addrs get bumped?  2.1 => 2.2, for example.
<natefinch> katco, ericsnow, wwitzel3:  Forgot to mention this mornnig - I'll be in an out tomorrow.  My wife had a  dentist appointment rescheduled which is screwing up a good part of the afternoon.
<dimitern> frobware, because tests were simpler before and didn't care about the default gateway, and assumed all networks of a node have .1 IPs
<natefinch> katco, ericsnow, wwitzel3: should be good for the morning, though.
<frobware> dimitern, ha. makes sense. thx.
<frobware> dimitern, subtle though.
<dimitern> frobware, yeah :)
<natefinch> gotta take off a  little early, but will be back later tonight
<dimitern> and the maas-spaces live test with even more complex constraints works!
<frobware> dimitern, great!
<ericsnow> katco, natefinch-afk, wwitzel3: could you also take a look at https://github.com/juju/charm/pull/184
<katco> ericsnow: sure
<ericsnow> katco, natefinch-afk: I've addressed all review comments except for the one about the CharmStore interface
<ericsnow> katco: regarding that one, did you have any alternatives to recommend?
<katco> ericsnow: i'd have to look at the interface again
<katco> ericsnow: one sec
<katco> ericsnow: maybe like ResourceLister?
<katco> ericsnow: if we stick with nouns, i agree CharmStore is fine
<katco> ericsnow: and also it's not really a huge deal :)
<ericsnow> katco: I was going to say that we are going to add a bunch of other methods, but actually that's not true
<ericsnow> katco: so I'm fine with doing the normal Go interface name thing
<katco> ericsnow: well and if we do, i would suggest we pass in multiple interfaces that are grouped by functionality
<wallyworld> cherylj: that fix did the trick for 1.25 \o/ so I assume you're looking to release real soon now?
<cherylj> wallyworld: for 1.25.2, yes.  We're just waiting on dimitern's fix for bug 1525280
<mup> Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged> <juju-core 1.25:In Progress by dimitern> <https://launchpad.net/bugs/1525280>
<wallyworld> awesome, will be good to see that fixed
<alexisb> wallyworld, thanks for the quick fix on the windows issue yesterday
<wallyworld> sure, np
<alexisb> wallyworld, how is the beach? :)
<wallyworld> terrible :-(
<blahdeblah> Yeah - surf is a bit small at the moment
<alexisb> are you trying to make me feel better
<wallyworld> i have a horrbile photo i'm going to share with you soon
<alexisb> punk
<blahdeblah> I could barely catch a wave at all this morning
<wallyworld> blahdeblah: where are you based?
<blahdeblah> wallyworld: Sunshine Coast
<wallyworld> blahdeblah: ah, we're sprinting at moolooabah
<blahdeblah> nice
<wallyworld> we're having a chrosmas party on the weekend
<wallyworld> want to come?
<blahdeblah> When is it?
<wallyworld> sat night?
<wallyworld> haven't locked it in yet
<blahdeblah> Will have to check with the social director, but sounds good.
<wallyworld> ok, let me know asap if you can as places along the esplanade fill up real quick atm
<blahdeblah> will do
<wallyworld> and yes, waves are a bit small :-)
<blahdeblah> mooloolaba will always be small, but even the open beaches are small this week
<wallyworld> indeed
<blahdeblah> Not that it will stop me having a go. ;-)
<wallyworld> me either
#juju-dev 2015-12-16
<mwhudson> wallyworld: spice bar is pretty nice
<wallyworld> mwhudson: i think i saw that, along the esplanade?
<mwhudson> yeah, at the north end of the main drag iirc
<mwhudson> not cheap, mind
<wallyworld> cool, will check it out, there's a lot of choices, but everything closes at 9 or 9:30
<blahdeblah> That's because we have to get up early to get out while the surfing's good
<wallyworld> true, i woke up today at 5:30 and was sorely tempted
 * blahdeblah was up at 4:50 today for a run
<mwhudson> australia outside of the capital cities is bascially a wasteland, right?
<mwhudson> :-)
<wallyworld> pretty much :-)
<blahdeblah> mwhudson: If you like nightclubs and doof doof music, yes
<mwhudson> i actually really liked mooloolaba
<mwhudson> (we holidayed there a year and a bit ago)
 * blahdeblah prefers more active passtimes like surfing, running, fishing
<mwhudson> i also sprinted there with the bzr team but that was years ago now
<wallyworld> mwhudson: that was with ian clatworthy?
<menn0> sinzui, mgz, cherylj: the current merge run appears to be wedged running get_ami.py
<sinzui> menn0: I can help
<menn0> sinzui: thank you
<sinzui> menn0: killed and requeued. I don't think anyone needs to twiddle the mp that was stalled
<blahdeblah> wallyworld: social director approval received - sign me up! :-)
<wallyworld> blahdeblah: awesome, to make it easier for us at the sprint, i'm just going to find a place along moolooabah esplanade that can accommodate the numbers
<blahdeblah> no worries - you know where to find me
<wallyworld> there's an italian place i'll ask today
<wallyworld> indded i do
<mwhudson> wallyworld: yes
<wallyworld> mwhudson: yeah, that would have been when ian was sick and couldn't travel :-(
<mwhudson> yep
<wallyworld> around 2007 maybe
<rick_h_> how goes wallyworld
<mwhudson> 2009 i think
<wallyworld> rick_h_: living the dream
<rick_h_> wallyworld: wheeeee :)
<mwhudson> 2007 was before i moved to the southern hemisphere :-)
<wallyworld> lol, wheeee indeed
<wallyworld> mwhudson: ah yeah, 2009 sounds right
<perrito666> axw_: could you take a look at http://reviews.vapour.ws/r/3392/ ?
<menn0> waigani: I think your merge is wedged. it's been running for 45 mins when they normally take about 20 mins
<waigani> really? shit :/
<waigani> menn0: the console output is moving ...
<menn0> waigani: never mind. it just finished with a failure. I mixed up my times. it was about 20 mins.
<waigani> menn0: the one before panicked with no reachable servers. Maybe you're referring to that one?
<menn0> waigani: I was looking at multiple jobs at the same time and must have mixed up the time stamps
<menn0> sorry for the confusions
<waigani> menn0: ah right. np. I'll just merge that one again as it doesn't look like it was me.
<waigani> menn0: unless you want to get something in?
<waigani> menn0: happy to merge mine after ;)
<menn0> waigani: mine's merging now. your failure is the occasional mongodb segfault we sometimes see. I've had that today as well.
<menn0> webscale
<waigani> lol
<wallyworld> axw_: http://reviews.vapour.ws/r/3395/
<voidspace> dimitern: I see your branch landed
<voidspace> dimitern: $$suckerpunch$$ !
<frobware> dooferlad, ping. I'm back.
<dimitern> voidspace, hey, yeah :) finally - just replied to your mail as well
<voidspace> dimitern: the PR you landed on maas-spaces doesn't pass the pre-push checks by the  way
<voidspace> dimitern: or at least I had a bug after I rebased which I had to fix
<dooferlad> frobware: not quite ready
<voidspace> I haven't seen the email yet
<voidspace> dimitern: just grabbing coffee and I'll see it
<frobware> dooferlad, ok
<dimitern> voidspace, oh? what issues are you seeing?
<voidspace> dimitern: line 1824 of provider/maas/environ.go
<voidspace> dimitern: two extra parameters to the Debugf call but only one %v
<voidspace> dimitern: next issue: error creating subnet Zones cannot be discovered from the provider and must be set
<dooferlad> frobware: ok, lets try now. The people I am trying to call are engaged.
<frobware> dooferlad, "but your call is important to us"
<dimitern> voidspace, oops sorry :/ I should've run go vet
<dimitern> voidspace, that's known - for now the workaround is to pass the default zone explicitly
<voidspace> ok
<voidspace> dimitern: don't you have the pre-push checks set for git?
<voidspace> dimitern: I have them set, but if I need to push code that doesn't pass you can just use --no-verify
<dimitern> voidspace, but I guess the better solution will be to just not require a zone for maas subnets (they're orthogonal)
<voidspace> dimitern: yep
<voidspace> dimitern: what do I use for the default zone?
<dimitern> voidspace, it used to be a pain on the old laptop as everything (or so it seems) was so slow, so I didn't use the pre-push scripts
<voidspace> heh
<dimitern> voidspace, well, maas provider does support AvailabilityZones() already
<voidspace> yeah, which is why I'm surpised by this error
<dimitern> voidspace, just doesn't provide subnet-to-zone(s) mapping, like we have in ec2
<voidspace> ah
<voidspace> is there an example of code setting the default zone I can look at
<dimitern> this was mostly needed for ec2, to populate SubnetsToZones and use zone+subnetID when distributing units of a service across zones, when spaces constraints are given
<voidspace> dimitern: what do I pass for the default zone?
<dimitern> well, you *could* just hard code it to "default" I guess, but ultimately what I think is needed is just to make AllZones() in apiserver/subnets work with MAAS
<voidspace> dimitern: right, thanks
<dimitern> voidspace, looking at the code, the subnets facade tries to get all zones from state first, then the provider and caches them
<voidspace> dimitern: right, that's your code :-)
<voidspace> dimitern: you mean that call might be failing?
<voidspace> I don't have any zones set on my maas
<dimitern> voidspace, :) yeah, unhelpfully complicated, but I see a simple solution
<dimitern> voidspace, you always have at least 1 zone - "default" (cannot be deleted)
<voidspace> dimitern: I've hardcoded default for now and am trying it
<voidspace> but to land in production the zones need to be right I think
<dimitern> voidspace, I think all that's needed (and should work with providers like maas and openstack, which don't constrain subnets to specific zones)...
<dimitern> voidspace, ...is just to assume "all zones were explicitly given for each subnet we're about to add" i.e. as if $ juju subnet add CIDR space zone1 zone2 zone3 ... was called
<voidspace> dimitern: we can talk about it later
<voidspace> dimitern: with that change subnets import too
<dimitern> voidspace, and we get the already-cached list of zones and pass them instead of subnetInfo.AvailabilityZones as a first argument of validateZones in addOneSubnet (when the former is empty)
<voidspace> \o/
<voidspace> dimitern: so put each subnet in all zones?
<dimitern> s/former/subnetInfo.AZs/
<voidspace> cool
<voidspace> dimitern: if you try my branch now it might work for you... :-)
<voidspace> if not you can tell me what fails
<dimitern> voidspace, yeah, because that's what it comes down to - since provider does not impose specific constraints which zones a subnet can span, any subnet can span all zones, and it's up to juju to decide which exactly (i.e. we impose the constraint in order to be able to do unit distribution)
<voidspace> dimitern: I have to go now, back in a bit
<dimitern> voidspace, well do, cheers
<voidspace> still a fair bit to do in the branch (tests!) but the happy path works...
<dimitern> \o/
<dimitern> dooferlad, voidspace frobware, otp will join in 3m
<dooferlad> dimitern: nobody here at the moment anyway...
<voidspace> back
<frobware> voidspace, how did it go?
<voidspace> frobware: hah, very cute
<voidspace> lovely, a bit cute overdose for me but still lovely
<voidspace> Irina did some of the actions, not sure she actually sang though
<dimitern> frobware, so it turned out it the existing code already worked with subdomain.domain.tld sort of hostnames coming from MAAS
<dimitern> frobware, but adding a few tests proves it and acts also as documentation/examples
<dimitern> frobware, and it did work because SplitN(s, ".", 2) does exactly what it says on the godoc -> return up to 2 elements, second one always containing the unsplitted remainder of s
<frobware> dimitern, good to know. sorry for the noise. :)
<dimitern> frobware, np :) I wasn't sure off hand, so better check
<dimitern> voidspace, I just verified the tip of your maas-spaces-networking-api3 branch works perfectly on my 1.9RC4 maas - spaces & subnets imported as expected. deployment with spaces constraints works!
<dimitern> I only commented a few lines in my test script - http://paste.ubuntu.com/14048778/
 * dimitern \o/ it's coming together now! :)
<frobware> dimitern, could you put "~/Documents/spaces-demo/spaces-demo-bundle-simplified.yaml
<frobware> watch juju status --format tabular
<frobware> " in the pastebin?
<frobware> dimitern, excusing my bad cut&paste
<dimitern> frobware, sure - http://paste.ubuntu.com/14048794/
<frobware> dimitern, thx
<dimitern> here's some more: $ juju status (http://paste.ubuntu.com/14048801/); $ juju space list (http://paste.ubuntu.com/14048803/)
<voidspace> dimitern: awesome!!!
<voidspace> dimitern: as I work on it I'll try and keep that branch in a useable state
<dimitern> voidspace, tyvm
<dimitern> voidspace, trying a similar script + bundle might help with that fwiw
<voidspace> dimitern: right, I only have two spaces and two subnets in this setup
<voidspace> dimitern: so I'll have to put together a simple bundle
<frobware> dimitern, standup HO?
<dimitern> frobware, omw - 2m
<dimitern> dooferlad, ping
<dimitern> dooferlad, whenever you're ready we try pairing on the uniter api
<frobware> dooferlad, voidspace: can somebody drive-by http://reviews.vapour.ws/r/3388/
<frobware> dooferlad, voidspace, dimitern: I did some light testing on maas 1.8 and 1.9 and saw the new node names in the UI
<frobware> dooferlad, voidspace: this needs to land today so taking a look would be appreciated.
<dimitern> frobware, great! thanks for confirming
<frobware> dimitern, did you try 1.7 at all?
<dimitern> frobware, no, I didn't - we should at least check it once I guess; it shouldn't matter as 1.7 doesn't have devices api and none of that code around hostnames will be used
<frobware> dimitern, "failed to prepare container "0/lxc/0" network config: failed to allocate an address for "0/lxc/0": address allocation not supported"
<frobware> dimitern, that's from 1.7
<dimitern> frobware, where do you see that?
<frobware> dimitern, let's HO
<dimitern> if it's just in the logs, that's fine for 1.7 - no regression at least
<frobware> dimitern, OK
<dimitern> frobware, I'd be worried if it caused the provisioning to fail
<dimitern> frobware, it's not worthy of a HO I think ,but I can join if you like
<frobware> dimitern, agreed
<frobware> dimitern, so my sanity test on 1.7 was add-machine lxc:0 and I can juju ssh 0/lxc/0
<dimitern> frobware, and status shows the container as "started" ?
<frobware> dimitern, yep
<dimitern> frobware, it's fine then - it works (not worse than before)
<dooferlad> dimitern: you have a review
<dooferlad> dimitern: sorry that I didn't get back to you earlier. Today has been like a slapstick comedy, but without the comedy. At this moment in time things aren't falling apart, which is nice.
<dimitern> dooferlad, thanks!
<dimitern> dooferlad, it's ok - do you think you can get on with the uniter api task?
<dooferlad> dimitern: I need a bit of guidance, but once I have that, yes.
<dooferlad> dimitern: are you free to jump in c9.io and a hangout?
<dimitern> dooferlad, sure, just give me 2m and I'll join the standup HO
<dooferlad> dimitern: see you in https://plus.google.com/hangouts/_/canonical.com/juju-sapphire in a moment then
<dimitern> dooferlad, omw
<dimitern> dooferlad, i'm in
<frobware> dimitern, heh - I can't land the script change only as this will bust containers. :(
<dimitern> frobware, why?
<frobware> dimitern, previously we did something like: eth0 -> juju-br0
<frobware> dimitern, so we effectively replace everthing up until digit
<frobware> dimitern, which is great until you get to bonds. for bonds we end up with: bond0 -> juju-br0, which can clash with eth0 -> juju-br0
<frobware> dimitern, so I made it a prefix, giving us: juju-br-eth0, juju-br-bond0, et al.
<frobware> dimitern, however. the container stuff is absolutely demanding juju-br0.
<frobware> dimitern, as it stands that is. once we have the complete change flushed through this wouldn't be a problem.
<dimitern> frobware, yeah, that sounds right
<dimitern> frobware, so why not take the rare chance of doing it the right way this time (just in maas-spaces) first?
<frobware> dimitern, so we could land the script change but if you had a bond0 expect containers to break.
<dimitern> frobware, well, if this is the only drawback if we land the improved script into 1.25, and master
<frobware> dimitern, yes - if in maas-spaces you use a bond0 ... well sorry... wip.
<dimitern> frobware, I still think it's fine - it's not like we *used* to work with bonds + juju-br0 and now we regressed
<frobware> dimitern, so we're saying let's just land the script, it will get some exposure and we can move on with the bigger change for interface_set, et al. yes?
<frobware> dimitern, there's no way the script should go beyond maas-spaces at this point.
<dimitern> frobware, I think since the script is strictly better and simpler, even without handling bonds properly, we should land it, while continuing to iterate over it in maas-spaces to make it solid
<dimitern> maas-spaces will end up in master eventually, but we'll have more time to improve the script there first
<katco> natefinch: wwitzel3: ericsnow: forgot to mention, i'm going to close out the iteration this friday in terms of points, so make sure to get any cards you want included moved across to done before EOD friday.
<wwitzel3> katco: well I want all of them included ..
<wwitzel3> katco: so I'll move all of them, lol
<katco> wwitzel3: =|
<katco> wwitzel3: you wound me, sir.
<dooferlad> dimitern: is there a right way to call the NetworkerAPI from the uniter API? With that we just create a names.MachineTag and call (n *NetworkerAPI) MachineNetworkConfig...
<dimitern> dooferlad, why would you do that?
<dooferlad> dimitern: to avoid writing the same function again.
<dimitern> dooferlad, hmm I see where you're going
<dooferlad> dimitern: or we just do it client side - generate the machine tag there and call the networker API.
<dooferlad> dimitern: that would probably make more sense
<dimitern> dooferlad, but please do it separately, as 1) the networker is not working for a long time now, and 2) I'm seriously considering to remove it in maas-spaces
<dooferlad> dimitern: ah, OK
<dooferlad> dimitern: copy and paste time then :-)
<dimitern> dooferlad, yeah - that's only due to time constraints though (and because of 2) above) - there are ways to reuse code safely across facades and in other cases I'd have suggested it :)
<dooferlad> dimitern: changes so far: https://github.com/juju/juju/compare/maas-spaces...dooferlad:uniter-network-config?expand=1
<dimitern> dooferlad, cheers, looking
<dooferlad> dimitern: back in a bit. Let me know if you think this is the right direction.
<dimitern> dooferlad, looks mostly fine - please add a test in api/uniter and apiserver/uniter for NetworkConfig and I think it's ready for revew
<dimitern> review even
<dooferlad> dimitern: OK. May not get to it tonight, but will get it done ASAP.
<dooferlad> dimitern: thanks for taking a look.
<dimitern> dooferlad, cheers - will have a look tomorrow
 * dimitern whew... after 4 hour long battle with state -  now not only the build succeeds, but only the expected 2 tests out of 1240 fail! getting closer..
<frobware> dimitern, should eth1.3 be bridged? http://pastebin.ubuntu.com/14053466/
<dimitern> frobware, it looks like it's not up, is it?
<frobware> dimitern, correction, look at this one: http://pastebin.ubuntu.com/14053499/
<frobware> dimitern, so the raw dev is no up, but the vlan is.
<dimitern> frobware, both look like they should be up
<dimitern> frobware, they are both "auto eth..."
<frobware> dimitern, so my notion of active is based on: self.is_active = self.method == "dhcp" or self.method == "static"
<frobware> dimitern, maybe that's simply wrong.
<frobware> dimitern, or not enough. maybe it should take into account the auto stanza.
<dimitern> frobware, it all depends on how ifup treats these cases
<dimitern> frobware, I'd expect anything without "auto" to be down
<frobware> dimitern, given our machine generated /e/n/i - what would change to make eth1 ^^ get an IP address?
<frobware> dimitern, in the previous example
<frobware> dimitern, if I had 10 of eth$N, each manual, would we expect 10 bridges?
<frobware> dimitern, I only really ran into this because I forgot to assign an IP addr in the UI for eth1.
<dimitern> frobware, didn't we decide to make bridges only on the physical NICs which are up and leave any VLAN NICs - so that traffic for vlans will get tagged but still end up on the bridge ?
<frobware> dimitern, I think the issue is determining what constitutes 'up'.  I'm beginning to think it should be based on the presence of auto.
<frobware> dimitern, the experiment we did yesterday we bridged vlans.
<frobware> dimitern,  I still think we should do that.
<dimitern> frobware, yeah - also it's the simplest approach
<frobware> dimitern, for now I'm going to treat the presence of 'auto' as an active interface.
<frobware> dimitern, if you just had 'iface eth20 inet manual' then that can never be up so is there any point in creating a bridge?
<frobware> dimitern, it's the vlan case that is confusing though.
<frobware> dimitern, the raw device need not have an IP address but the vlan can. in those cases should the raw device have its own bridge?
<dimitern> frobware, let me think..
<dimitern> frobware, so w.r.t. VLANs, even if their raw device is not "auto" or even up, if the vlan device is itself "auto", IIRC that *will* bring the parent up as well
<frobware> dimitern, it will, but if it is 'manual' it won't (obviously!) have an IP address.
<dimitern> frobware, that sounds correct, but I'd suggest doing a quick experiment to verify
<frobware> dimitern, and if it is 'manual' then have no bridge for 'eth1', but we would have a bridge for eth1.789
<dimitern> frobware, with iface eth0 inet manual (no auto eth0), and auto eth0.42, iface eth0.42 inet static
<frobware> dimitern, you'll get juju-br-eth0.42 (i.e., bridged)
<dimitern> frobware, I don't think that last is correct though
<dimitern> frobware, it all depends on if no-auto + manual and no address, coupled with auto+static vlan on top of it actually works
<frobware> dimitern, so going back to http://pastebin.ubuntu.com/14053499/
<frobware> dimitern, we would not create a bridge for eth1.3
<dimitern> frobware, I think this is correct
<frobware> dimitern, right now if this is not correct, then change eth1 from manual to dhcp/static
<dimitern> frobware, I've just tried here with auto ethX, iface ethX inet manual; auto ethX.42; iface ethX.42 inet static; address 10.42.10.0/24; vlan-raw-device ethX; vlan_id 42
<dimitern> frobware, I think it will be much easier in maas-spaces
<frobware> dimitern, because? this is in maas-spaces. I was just doing some testing before submitting a PR for the script
<voidspace> dimitern: hmm... I thought (like you) that new facade versions should start at 1
<dimitern> frobware, as right after acquire node + bindings we get all NICs we asked for and we'll know we need a bridge for *each* one
<voidspace> dimitern: however, there is a test that they should start at zero (TestFacadeVersionsMatchServerVersions)
<voidspace> dimitern: so I'm setting it to 0
<dimitern> voidspace, that test seems wrong
<voidspace> dimitern: it passes for everything else...
<dimitern> voidspace, are you sure it's not about facade version before login?
<frobware> dimitern, going back to "each one". If you forgot to make eth1 dhcp/static then what we are currently saying is you would not get a bridge for eth1.789 - is that right?
<voidspace> dimitern: it tests that the version number for each facade is the len of the different versions -1
<voidspace> dimitern: i.e. if there is only one version it must be zero
<voidspace> dimitern: starting some at 1 would require special casing them all in the test
<dimitern> frobware, ideally we should detect misconfigured interfaces early and report it
<voidspace> dimitern: gp/afacadeversions_test.go
<dimitern> frobware, but for now let's assume the network config on the maas node is as expected (in maas-spaces)
<frobware> dimitern, ok - let's settle on if the underlying raw device is 'auto' but 'manual' any vlans of that will not be bridged. OK?
<dimitern> voidspace, where?
<dimitern> frobware, I can live with that :)
<voidspace> dimitern: gp/afacadeversions_test.go
<frobware> dimitern, It's trivial to fix either way. was just testing... :)
<voidspace> dimitern: TestFacadeVersionsMatchServerVersions
<dimitern> voidspace, that sounds like it expects api/ and apiserver/ facades to match, not that all facades need to start from 0
<dimitern> voidspace, e.g. api.FacadeVersions["Spaces"] is only at V1
<dimitern> voidspace, apiserver/cleaner is another example (of a agent facade, inlike Subnets) also only with V1
<voidspace> dimitern: ah
<voidspace> dimitern: my misunderstanding then
<dimitern> voidspace, check if you're using RegisterStandardFacade in discoverspaces init()
<dimitern> *not* RegisterFacade instead
<voidspace> dimitern: hah, I was using 0 :-)
<voidspace> dimitern: uhm, sorry about that
<dimitern> :) np
<voidspace> dimitern: go on holiday...
<dimitern> I know a lot of our tests are bad, but at least we should try to grant them some chance to actually fail for the right reasons :D
<voidspace> :-p
<frobware> dooferlad, voidspace, dimitern: if you have the time - http://reviews.vapour.ws/r/3398/
<mup> Bug #1526926 opened: Controllers cannot be destroyed or killed <ci> <destroy-controller> <kill-controller> <juju-core:Incomplete> <juju-core controller-rename:Triaged> <https://launchpad.net/bugs/1526926>
<dimitern> frobware, will have a look in a moment
<frobware> dimitern, thanks. off-hand, do you know if it is possible for the cloudinit config to add a file to the node. I was just looking and it seems that might be so. it woud be better if our script was added as a file (somewhere) so that we don't see the output in the run cmds from cloudinit-
<dimitern> frobware, yes - there's a AddBootFiles() which does that
<frobware> dimitern, aha.
<dimitern> frobware, your PR looks nice, but I'd like to do a quick test with it and a few configs I found to cause issues; focusing on the demo reqs
<dimitern> all state tests pass!
<dimitern> I'm proposing what I have so far as WIP
<voidspace> frobware: EOD
<voidspace> frobware: can look tomorrow if it's still needed
<voidspace> g'night all
<wallyworld> frankban: urulama: mothing new from this end, still working on final branch to enable add-relation (writing tests). will be landed by your SOD
<urulama> wallyworld: kk
<wallyworld> urulama: frankban: have a good evening and we'll catch up in several hours
<frankban> wallyworld: sounds good, on the JS side I have a branch in review with the impl of the mega-watcher remote service consumer and the CrossModelRelations.ServiceOffers API call: https://github.com/juju/juju-gui/pull/1091 will ping Jeff later for review. hopefully that stuff would look familiar to you
<urulama> wallyworld: ok. jeff and huw have some tasks on GUI anyway, and frankban made things available in case you finish before we get up.
<wallyworld> frankban: awesome, ty, will take a look
<frankban> wallyworld: ty, have a good day!
<wallyworld> frankban: can jeff etc review that branch? or does someone else need to look too?
<frankban> wallyworld: yes Jeff and Huw are definitely I'd like to review that branch
<frankban> are definitely the ones
<wallyworld> ok, will do, thanks for doing it :-)
<urulama> wallyworld: and in case something is not working, please check it with them, so that we can isolate where things get wrong. you'll love JS :)
<urulama> (and appreciate golang a bunch more later)
<wallyworld> urulama: oh, i have done a lot of js on the past on launchpad :-)
<urulama> perfect then :)
<wallyworld> been a few years :-)
<wallyworld> was all in yui
<wallyworld> which is now dead
<frankban> wallyworld: the GUI has still some YUI bits, but we are gradually moving away
<wallyworld> to React I hear
<frankban> yes
<wallyworld> cherylj: i'll finish release notes first thing this morning within an hour or so, didn't quite get finished yesterday with everything else
<cherylj> thanks, wallyworld
<alexisb> is there someone around that can help point me in the right direction regarding details of the status command implementation ?
<perrito666> I might, then again, I might not
<alexisb> heya perrito666 !
 * perrito666 is the cheshire cat
<alexisb> :)
<perrito666> how can I help you suffer status?
<alexisb> do you mind jumping on a hangout with me, it would be faster I think
<alexisb> I just need some help navigating the waters
<perrito666> alexisb: sure, gimme a sec
<menn0> fairly easy review anyone? http://reviews.vapour.ws/r/3404/diff/
#juju-dev 2015-12-17
<mup> Bug #1527020 opened: cannot build trusty ppc64el juju <ppc64el> <regression-update> <juju-core:Triaged> <gccgo-go (Ubuntu):New> <https://launchpad.net/bugs/1527020>
<menn0> wallyworld: I know you're sprinting but any chance you could have a quick look at this one: http://reviews.vapour.ws/r/3404/
<wallyworld> menn0: sure, looking
<menn0> wallyworld: thank you
<menn0> wallyworld: sorry to bug you at the sprint. there's not many ppl around today.
<wallyworld> all good
<wallyworld> menn0: lgtm, seems mechanical, justa question about what closes st now
<menn0> wallyworld: it's closed by the caller
<wallyworld> rightio
<menn0> wallyworld: it probably should never have been closed there
<menn0> wallyworld: just read the actual comment, rather than assuming I knew what you were talking about. that's a different thing. just replied.
<menn0> wallyworld: thanks for the review
<wallyworld> sure, np
 * natefinch picks up the horse and gives it one more kick for good measure.
<perrito666> natefinch: ??
<natefinch> perrito666: see email
<perrito666> uh, flamewar, nice
<perrito666> btw, found the hat?
<natefinch> no.. I'm going to call the hotel again tomorrow... but I think it's probably just gone.  boo.
<perrito666> natefinch: I would say plane or train?
<natefinch> perrito666: possibly plane, though I know I didn't wear it that day,  it might have been sitting in my coat pocket the whole time, only to fall out when I used the coat as a pillow on the plane.
<perrito666> axw: wallyworld could any of you take a look at http://reviews.vapour.ws/r/3392/ ?
<natefinch> dammit gofmt is sad
<natefinch> stupidest reason for a CI build to fail :/
<perrito666> natefinch: you are insensible man, why dont you care about gofmt feelings?
<natefinch> the fix is deterministic.... the CI bot should just fix it for me.
<wallyworld> urulama: final branch to enable add resources will land soon, maybe a couple of hours, still making a few changes before landing
<urulama_> cool!
<mup> Bug #1527068 opened: maas 1.8 static ips not released <ci> <destroy-environment> <maas-provider> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1527068>
<blahdeblah> Did someone say earlier that joyent was unhappy?
<jam> blahdeblah: our internal cloud health checks seem to say that Joyent is Green (it had 1 red overnight)
<jam> hmmm.... maybe I'm reading the chart wrong
<jam> it looks like today is on the left, and time goes backwards to the right
<jam> so Joyent has been on-and-off lately
<jam> wwitzel3: katco: ericsnow: (natefinch) I have a question about the recent "create juju upload command" patch if anyone is around
<blahdeblah> jam: Thanks; looks like it might be one particular instance; I've contacted support about it
<frankban> wallyworld: hey, how is it going?
<wallyworld> frankban: living the dream. finishing final branch to enable add-relation to work
<wallyworld> will land soon
<frankban> wallyworld: \o/
<urulama> :D
<wallyworld> final tests to fix, then :shipit:
<frankban> great
<dimitern> frobware, ping
<dimitern> frobware, your 2 PRs look almost the same - did you mean to close the earlier one?
<frobware> dimitern, nope
<frobware> dimitern, I'll resubmit the second once the first has landed as it is dependent on the first and might need some agreement on where we put the file
<dimitern> frobware, I see, ok
<voidspace> dooferlad: dimitern: frobware: so now all unit tests pass, except one lxdclient test that also fails for me on upstream/master
<voidspace> dooferlad: dimitern: frobware: I'll create a PR to land my branch on maas-spaces and then do fixes/tests as a new PR
<voidspace> dooferlad: dimitern: frobware: ok?
<frobware> voidspace, sounds good to me
<voidspace> ok
<dooferlad> voidspace: +1
<frobware> voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3398/
<frobware> dimitern, if you could do some verification against your VLAN setup that would be great
<dimitern> frobware, looking
<dimitern> voidspace, sorry I missed your question earlier - that sgtm
<voidspace> great
<wallyworld> axw: i had to add an option to alias the offered service (on the todo list but needed now to support testing in a single env)
<wallyworld> changes pushed
<wallyworld> issue showed up in feature test
<voidspace> dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3409/
<axw> wallyworld: okey dokey, looking
<dimitern> voidspace, looking in a bit
<voidspace> dimitern: don't look too closely...
<frobware> voidspace, looking
<dimitern> voidspace, why did you need to embed *common.EnvironWatcher ?
<voidspace> dimitern: to have access to the environ
<voidspace> dimitern: we get it through the environwatcher
<voidspace> dimitern: which means the api/apiserver need access to EnvironConfig api methods
<dimitern> voidspace, from the client-side api proxy?
<voidspace> dimitern: that's api/common
<dimitern> voidspace, in the apiserver side you have *state.State, so you can call EnvironConfig
<voidspace> dimitern: it's the api side of that interface
<axw> wallyworld, reviewed
<dimitern> voidspace, I don't think we need EnvironWatcher anymore
<voidspace> dimitern: the environwatcher waits for the environ to be available and keeps it updated
<voidspace> dimitern: it calls state.EnvironConfig
<voidspace> dimitern: on the apiserver using EnvironWatcher exposes the api methods needed by the api side
<dimitern> voidspace, I know what it used to do :) but the need to wait is long gone - there's always an environ config to read
<voidspace> dimitern: so if we didn't use it I'd need to manually expose those methods
<voidspace> dimitern: we want the provider in the worker, so we still need access to the EnvironConfig
<voidspace> dimitern: so I can manually add that api method to the client and server if that's a better approach
<voidspace> I'll add an XXX for that
<dimitern> voidspace, I'd suggest the simpler approach like we used for the addresser
<voidspace> dimitern: the addresser doesn't use the provider
<dimitern> voidspace, ok to do it later - will add comments; basically if you expose SupportsDiscovery or something on the apiserver.DiscoverSpaces facade you don't need EnvironWatcher at all
<voidspace> it delegates everything to the apiserver
<voidspace> dimitern: we also need to list the spaces and subnets from the provider
<voidspace> dimitern: in the discussion before we started this we said that the worker would have access to the provider and use the api for the state calls
<voidspace> dimitern: so we can move provider access to the apiserver, it's just not the approach we decided at the start
<dimitern> voidspace, yeah, ok
<dimitern> voidspace, we'll iterate on that later
<dimitern> voidspace, reviewed; on to frobware's now
<voidspace> dimitern: thanks
<axw> wallyworld, are you still going downstairs for hangout?
<wallyworld> yep
<axw> ok, will come down soonish
<frobware> dimitern, dooferlad, voidspace, mpontillo: Chrome Version 47.0.2526.106 seems to work in MAAS today - I apt-get updated and got <- version and it behaves differently (correctly!) for the dropdowns.
<voidspace> yay
<frobware> voidspace, auto discovered space from your branch: http://pastebin.ubuntu.com/14072670/  whoop whoop! \o/
<voidspace> frobware: great!
<frobware> voidspace, the unit test failure you mentioned - is this it? http://pastebin.ubuntu.com/14072770/
<voidspace> frobware: no
<voidspace> frobware: mine isn't a panic
<voidspace> frobware: it's in a lxdclient test, lxcbr0 not found
<voidspace> hmm... I wonder if I even have lxc installed...
<voidspace> I do
<frobware> voidspace, my build was with go1.2. Just trying again with 1.4.2
<voidspace> frobware: with 1.2 you won't get the lxd stuff anyway
<frobware> voidspace, sure, but more concerned about the panic now
<voidspace> frobware: right
<voidspace> frobware: heh
<voidspace> looking to see what test that is
<voidspace> frobware: is that my branch?
<voidspace> the panic is in imagmetadata, so I assume it's a test for that - I can't specifically see the test though
<voidspace> make sure you have done a godeps invocation, sure you have but that *could* be the cause
<frobware> voidspace, my rebuild-juju alias always does go deps
<frobware> voidspace, same panic with 1.4.2
<voidspace> frobware: which branch is this?
<frobware> voidspace, maas-spaces-networking-api3
<voidspace> frobware: weird
<voidspace> frobware: and which test is it?
<frobware> voidspace, yup
<voidspace> nil pointer dereferences can usually be resolved
<voidspace> dimitern: frobware: I've fixed the import order issues and added a TODO for getting rid of EnvironWatcher
<voidspace> I'm going to hit $$merge$$
<voidspace> frobware: we'll see if it panics for CI
<voidspace> it doesn't panic for me
<frobware> ack
<dimitern> voidspace, cheers
<frobware> voidspace, so maas-spaces passes for me
<voidspace> frobware: ah, cool
<voidspace> spurious then
<frobware> voidspace, no... your branch does. :)
<voidspace> frobware: oh, damn
<voidspace> other way round...
<voidspace> frobware: what test is it that panics?
<frobware> voidspace, bah humbug
<voidspace> (asking again as the first two times the question got lost... ;-)
<frobware> voidspace http://pastebin.ubuntu.com/14073072/
<frobware> voidspace, just checking again.
<voidspace> frobware: that doesn't show the test
<voidspace> I don't think
<voidspace> there are no test files in that part of the panic
<frobware> voidspace, I'm testing in .../cmd/jujud
<voidspace> so one of the sub-packages there
<voidspace> ah, I get a panic running it on its own
<voidspace> I didn't in a full test run
<voidspace> not sure yet if its the *same* panic
<voidspace> in cmd/jujud/agent
<voidspace> frobware: yep, looks the same
<voidspace> I'm looking into it
<frobware> voidspace, thanks. the test seems to take an entirety for me. just .../cmd/jujud/agent
<frobware> voidspace, so you don't see that testing with `make check`/
<voidspace> I don't do make check
<voidspace> I do go test ./...
<voidspace> frobware: looks like this is the test TestNewEnvironmentStartsNewWorkers in machine_test.go
<voidspace> I'm on it anyway
<frobware> voidspace, I see it with go test ./...  Weird.
<frobware> voidspace, and make check
<voidspace> frobware: the panic happens in a weird place, don't understand yet
<voidspace> there is a discoverspaces worker, but the panic is opening the environ
<voidspace> using the dummy environ
<voidspace> ah, I have an idea.
<voidspace> frobware: I've changed the dummy provider to return false for SupportsSpaceDiscovery
<voidspace> when I come to write worker tests I'll make that configurable
<voidspace> but for the general case it should be false
<voidspace> I bet that was the problem
<voidspace> although it showed up in a weird place
<voidspace> we'll see anyway - running the test now
<voidspace> nope, still panics
<voidspace> there's something not configured right
 * frobware steps out for some lunch
<jam> dimitern: frobware: ping
<mgz> no dooferlad today?
<frobware> jam: pong
<frobware> mgz, was around earlier
<jam> hi frobware, I'm chatting about networks with Mark, and he was hoping for some updates to where we're at
<dooferlad> mgz: I am here...
<jam> do you have 10 min to join us?
<frobware> sure
<jam> frobware: https://plus.google.com/hangouts/_/canonical.com/juju-core-spec
<mgz> dooferlad: ah, you were quiet. did you need some changes to provider/maas to go with your gomaasapi changes?
<mgz> I get some test failures if I bump the dep
<dooferlad> mgz: yea, voidspace made some changes to that bit of code.
<dooferlad> mgz: I didn't intentionally break anything though.
<mgz> can I cherrypick that to master? 's on maas-spaces I guess?
<dooferlad> I guess so. I am not particularly familiar with what needs to come across.
 * dooferlad will be back in 5
<wallyworld> urulama: frankban_ : sorry about delay. code landed. this should work: juju deploy wordpress && juju deploy mysql && juju offer mysql local:/u/me/hosted-mysql && juju add-relation wordpress local:/u/me/hosted-mysql
<wallyworld> not fully tested live
<urulama> wallyworld: cool
<frankban_> wallyworld: I'll test it now, thanks!
<wallyworld> frankban_: i might be asleep, but ping back if there's an issue. should be easy to resolve anything
<frankban_> wallyworld: sure, go relax and good night
<wallyworld> frankban_: local url optional but needed in this case due to single environment. the service name in url needs to be different to locallly deployed mysql service name
<wallyworld> so there's no name clash
<frankban_> ack
<wallyworld> will work on proper multi-env support for initial deploy maybe tomorrow
<dooferlad> dimitern: I need some help with testing this uniter stuff when you have a moment.
<mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
<mup> Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003
<mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
<mup> Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003
<mup> Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003
<dimitern> dooferlad, hey, sorry got distracted with testing - sure, HO?
<dooferlad> yep
<dimitern> dooferlad, I'll join the standup one in 2m
<dooferlad> dimitern: sounds good
<dimitern> dooferlad, i'm in
<natefinch> ericsnow, wwitzel3: did I miss the shortest standup ever?
<frobware> dimitern, did you find any issues with the bridge script?
<frobware> voidspace, did you find out what the issues was?
<ericsnow> natefinch: moonstone
<voidspace> frobware: not yet, more logging
<voidspace> frobware: seems like an impossible bug (uninitialised member of Config struct)
<voidspace> :qa
<voidspace> damn, wrong window
<voidspace> frobware: found it
<voidspace> frobware: that test uses an environment that needs to explicitly setup singular workers
<voidspace> so I needed to add the discoverspaces worker to a list of workers to start
<voidspace> frobware: pushing now
<frobware> voidspace, great. but there's a queue forming. :)
<voidspace> hah
<mgz> review please, blue team: http://reviews.vapour.ws/r/3413
<cherylj> Could I also get a review?  http://reviews.vapour.ws/r/3399/
<cherylj> small change, will enable us to actually test controller-rename :)
<mgz> cherylj: swapsies
<cherylj> mgz :)  Is there a reason you added in the "SetVersionJSON" calls in environ_whitebox_test.go?
<voidspace> cherylj: I think I added those
<voidspace> cherylj: the new default in gomaasapi included stuff we didn't want on by default
<mgz> cherylj: see the second commit message, the tests assume a lack of devices support in the maas test server
<mgz> and the latest rev of gomaasapi which gets pulled in with this move adds that capability flag
<voidspace> mgz: ah, you're cherrypicking my changes
<mgz> voidspace: I actually reinvented, there wasn't a clear commit to pick
<cherylj> mgz, does the commit in dependencies.tsv need to be the commit of the merge?
<cherylj> ex:  f342599c61c3303e707660701430297f229cdf6c, rather than what you have?
<cherylj> (I've always done it that way and I don't know if it makes a difference)
<mgz> cherylj: technically no, but it should be, I'll change that
<frobware> voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3414/
<BrunoR> I pushed a new charm to launchpad about an hour ago, it shows up in 'charm list' but juju deploy cs:~my-lp-user/trusty/<charm-name> yields only an 'cannot resolve charm url' error
<voidspace> frobware: looking
<natefinch> BrunoR: it can take a few hours for the charm to show up in the charm store.  This is a limitation of the current architecture, but one that we have fixes for already in the pipeline.
<voidspace> natefinch: ping
<natefinch> voidspace: yo
<voidspace> natefinch: it seems to me (you may disagree) that several of your recent emails to juju-core would have been better on the public list
<voidspace> natefinch: any reason to keep them private?
<natefinch> voidspace: I was trying to keep them limited in audience to avoid bikeshedding, and because they dealt with coding standards that may not apply to other teams.
<natefinch> voidspace: I almost sent the last one to juju-dev....
<BrunoR> natefinch: ok, thanks
<voidspace> natefinch: I couldn't see anything that needed to be private, and I think "public by default" is a better policy
<natefinch> voidspace: I wasn't trying to be private, I was trying to avoid starting a flamewar with people who aren't actually on the team
<voidspace> natefinch: heh :-)
<voidspace> none of seemed particularly inflammatory
<voidspace> natefinch: I worry that we'll drift into private by default
<voidspace> natefinch: before we had that list I think you'd have been happy sending them to juju-dev, which is probably a good test
<natefinch> voidspace: happy is a strong word
<voidspace> natefinch: you're a happy person :-)
<natefinch> voidspace: as for not being inflammatory, I think you underestimate the average developers' capacity to argue about coding standards :)
<voidspace> natefinch: juju-dev is hardly a hotbed for that, but I stand to be proven wrong...
<voidspace> I'm sure I will be
<voidspace> frobware: LGTM
<voidspace> dooferlad: frobware: dimitern: my branch has landed
<dooferlad> voidspace: Yay!
<frobware> voidspace, thedac is going to try it later; will see if it discovers his lab. ;)
<voidspace> dooferlad: so maas-spaces is now *officially* screwed with untested code and TODOs... \o/
<voidspace> frobware: cool!
<voidspace> frobware: there's lots of reasons why it might not work, but they should *all* be easy fixes
<voidspace> should work though
<voidspace> the happy path is pretty good
<frobware> voidspace, I think it's important we plant a stick in the ground
<dimitern> voidspace, awesome!
<voidspace> frobware: cool
<dimitern> voidspace, and more of that screwy stuff is coming
<dimitern> :)
 * dimitern steps out for ~30m
<voidspace> dooferlad: are you off tomorrow? I don't recall
<dooferlad> voidspace: yes
<voidspace> dooferlad: enjoy your break!
<voidspace> see you on the other side
<dooferlad> voidspace: thanks! Have a great Christmas!
<natefinch> ericsnow: btw, the juju upload PR did land
<ericsnow> natefinch: sweet
<mup> Bug #1522948 changed: ensure-availability on rackspace spawns endless machines <ci> <ensure-availability> <ha> <rackspace-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1522948>
<dimitern> frobware, pig
<dimitern> ping :) sorry
<mgz> dimitern: how rude :P
<dimitern> frobware, I'm testing your script - it appears to work, however I'm hitting the 15 character limit on the device name - instead of "juju-br-eth0.250" I get "juju-br-eth0.25"
<dimitern> mgz, hey there
<dimitern> mgz, you know moving gomaasapi now wasn't a great idea :P
<dimitern> mgz, was it necessary for something else?
<mgz> dimitern: I did mention this last week.
<mgz> dimitern: I really don't mind where it lives, thought the long term cunning plan was to redo it entirely
<dimitern> mgz, yeah, it's better on github, just doing it now introduced some churn with our maas-spaces feature and today I've seen import paths have changed (e.g. more merging to resolve)
<frobware> dimitern, ooh. that could be really bad.
<dimitern> frobware, yeah - the others worked though - no noticeable delay
<frobware> dimitern, great. but if you had vlans 25 and 250 that would be bad, no?
<frobware> dimitern, I can follow up with making the prefix 'br-'
<dimitern> frobware, I guess a simple "juju-" vs "juju-br-" prefix will give us enough space up to "juju-eth0.4094"
<dimitern> frobware, or even "br-" yeah
<frobware> dimitern, we can annotate /e/n/i with a comment to say '# rendered by add-juju-bridge'
<frobware> dimitern, maybe that could be our sentinel.
<frobware> dimitern, if we didn't want to remove the script after it has run
<dimitern> frobware, oh definitely
<dimitern> frobware, I'd say "rendered by github.com/juju/juju/provider/maas/add-juju-bridge.py" ?
<frobware> dimitern, so I have the run-once-only change up for review: http://reviews.vapour.ws/r/3414/
<frobware> dimitern, I can work those changes in there now. It just depends on how critical this is vis-a-vis getting it laced through to the LXC configs
<dimitern> frobware, or something like that; also I'll do a quick test now using "juju-" instead of "juju-br-" while reviewing your code
<dimitern> frobware, also: scrolling up the console I can still see the full script being dumped
<frobware> dimitern, that change hasn't landed. it is that review ^
<frobware> dimitern, unless you've pulled that branch explicitly... ?
<dimitern> frobware, nope, I saw that on maas-spaces tip
<frobware> dimitern, maas-spaces doesn't have that change. i did it separately.
<dimitern> frobware, I guess it's due to cloudcfg.AddScripts("set -xe", runcmd) we do in newCloudiintConfig
<frobware> dimitern, you need this http://reviews.vapour.ws/r/3414/ in addition to the tip of maas-spaces
<frobware> dimitern, that PR -- which hides the output -- is the review
<dimitern> frobware, ok, I'll try "juju-" on 3414 then
<frobware> dimitern, ack
<frobware> dimitern, or 'br-'
<frobware> dimitern, cut our losses as 'bond123' will probably blow it at some point. ;)
<frobware> dimitern, or should that be bond007
<dimitern> :)
<dimitern> you can't have it all in 2 weeks hehe
<mup> Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
<mup> Bug #1527349 changed: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
<mup> Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 <juju-core:Triaged> <https://launchpad.net/bugs/1527349>
<dimitern> frobware, reviewed
<frobware> dimitern, ty
<frobware> dimitern, becoming complicated? It's gone from a couple of lines of sed to ... ?
<dimitern> frobware, what's that?
<frobware> dimitern, I was just chuckling at one of your comments
<dimitern> frobware, ah, well - I mean there's now a makefile, etc.
<frobware> dimitern, becoming its own monster.
<dimitern> :)
<dimitern> frobware, btw the test worked with "juju-" - http://paste.ubuntu.com/14076709/
<frobware> dimitern, bridge-hydra is what I should have called it
<dimitern> :D
<frobware> dimitern, one thing I discovered this wee is 'ip -d' -- try it as 'ip -d link show up'
<frobware> dimitern, shows you kind of dev. ie., tun, bridge, vlan, etc.
<dimitern> frobware, interesting - a bit more readable even
<frobware> dimitern, I hesitated at putting that in because I couldn't see the option in the man page and wasn't sure how well it worked across all series.
<frobware> dimitern, presumably the script output went away from your node boostrap
<dimitern> frobware, yeah it did
<dimitern> frobware, however, I've just realized spaces weren't discovered
<frobware> dimitern, :(
<dimitern> frobware, it your branch before voidspace's change have landed?
<frobware> dimitern, discovery is at the tip of maas-spaces
<dimitern> frobware, yeah, I'm trying to figure out why
<frobware> dimitern, you mentioned something earlier today about 'disable... :true' because of vlans / bridge?  Am I recalling this correctly?
<dimitern> frobware, git log shows your maas-spaces is behind the main repo
<frobware> dimitern, my github branch - not in use
<frobware> dimitern, I need to clean up.
<frobware> dimitern, though I left that there because of the rebase troubles.
<dimitern> frobware, well, please double check if you need a fresh fetch from upstream maas-spaces tip and rebase
<dimitern> frobware, as the parent of the tip of your branch's commit is the one before voidspace's last one
<frobware> dimitern, ah, yes. for that branch I know because I pushed it last night.
<dimitern> frobware, ok :) I got worried for a moment
<frobware> dimitern, the branch you're talking about is "maas-spaces-add-bridge-script-using-AddBootTextFile" not in fact "maas-spaces", correct?
<dimitern> frobware, yeah
<frobware> dimitern, you had me worried
<mgz> okay, it's third-beer-o'clock, which is a very good time to leave irc
<voidspace> g'night all
<dooferlad> dimitern, frobware: Firstly, go to bed. Secondly, http://reviews.vapour.ws/r/3415/ is the NetworkConfig API call for your review.
<natefinch> dooferlad: so.... you're telling them to go to bed, but then asking them to review your code? :)
<dooferlad> natefinch: just trying to encourage a healty attitude to it being the evening while blowing my own trumpet.
<natefinch> dooferlad: haha, fair enough
<dimitern> dooferlad, great, thanks!
<frobware> dooferlad, Can't. I'm in bed. :-p
<natefinch> ericsnow: reviewing your resources in state patch
<ericsnow> natefinch: thanks
<mup> Bug #1525531 changed: precise upgrades fail in 1.25 and master <ci> <manual-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1525531>
<menn0> anyone able to take a look at this one? : http://reviews.vapour.ws/r/3410/
<menn0> I need to land this in order to progress
<dimitern> menn0, reviewed
<menn0> dimitern: thank you!
<alexisb> dimitern, I am beginning to think you dont sleep
<ericsnow> axw: ping
<axw> ericsnow, pong
<ericsnow> axw: are there any examples of how to use PutForEnvironmentRequest (from the blobstore code)?
<axw> ericsnow, not that I can think of. I think it was meant to be used by resources
<axw> ericsnow, wallyworld ^^
<wallyworld> ericsnow: it's not used yet. it is to allow the case where a user proves owenrship of a file and hence creates a reference to it without having to upload
<ericsnow> wallyworld: I was hoping to use the ref-counting for resources (i.e. to de-dupe the stored blobs to save space)
<ericsnow> wallyworld: the whole ownership thing is irrelevant to me
<wallyworld> ericsnow: du-dupe happens automatically anyway
<ericsnow> wallyworld: ah!  including the ref-counting semantics?
<wallyworld> ericsnow: and it's not ownership as such
<wallyworld> it's saying i want to upload this file, i have a checksum, so if there's already the same file uploaded, don't do it again
<wallyworld> that doesn't have to be a uman
<wallyworld> human
<wallyworld> and yes, ref counting is done
<wallyworld> from memory
<wallyworld> it's been ages since i looked at the code
<wallyworld> but it should all just work
<wallyworld> ericsnow: are you guys using all the resource manager stuff i did when we started working on resources?
<ericsnow> wallyworld: I don't think so
<wallyworld> :-(
<ericsnow> wallyworld: where is it?
<wallyworld> i gave all that info across
<wallyworld> in a feature branch
<wallyworld> resources i think
<wallyworld> i had http endpoints to upload and stream out resources from state
<ericsnow> wallyworld: I was under the impression that the spec had changed so significantly that it made sense to start over
<wallyworld> nope, not that bit
<ericsnow> wallyworld: cool, we'll take a look
<wallyworld> you still need to store and retrieve resources from state
<ericsnow> wwitzel3: ^^^
<ericsnow> wallyworld: that's what I'm working on right now
<wallyworld> and the work i did provided the http endpoints for that, just like we use for charms and tools
<wallyworld> and backups
<wallyworld> so a lot of the core boilerplate for what you need
<wallyworld> to get blobs into and out of state
<wallyworld> it was all wip but i think close to functional, been a while
<wallyworld> it could also be used for store
<ericsnow> wallyworld: cool, I'm taking a look
<wallyworld> ericsnow: ok, more than happy to talk / hangout if needed
<wallyworld> hopefully what's there will save you guys a lot of work
<ericsnow> wallyworld: I may take you up on that at some point soon
<wallyworld> not all will be relvant now
<ericsnow> wallyworld: the bulk of the work lies in patches against the charm store
<ericsnow> (since the spec is much simpler now)
<wallyworld> cool :-)
#juju-dev 2015-12-18
<perrito666> wallyworld: did you send me the pic?
<natefinch> probably a bad sign that I'm the only one in the team meeting at 1 past the hour
<perrito666> lol
<voidspace> dimitern: seems to work
<dimitern> voidspace, sweet!
<voidspace> dimitern: rebooting state server doesn't cause worker to die
<voidspace> dimitern: I'll confirm by repeating it with maas-spaces tip to check that I *do* see the error there
<voidspace> dimitern: pretty sure I will
<dimitern> voidspace, I'd leave it running for a while and check for "restarting in 3s"
<voidspace> dimitern: then I'll PR
<voidspace> dimitern: ok
<voidspace> frobware: dimitern: http://reviews.vapour.ws/r/3419/
<voidspace> frobware: dimitern: confirmed the issue happens on tip and not on my branch
<voidspace> frobware: dimitern: leaving a long running juju environment to double-confirm
<voidspace> will re-check debug-log before merging
<dimitern> voidspace, cheers, having a look shortly
<BrunoR> does amulet proides support for juju storage?
<BrunoR> s/proides/provides/
<dimitern> voidspace, LGTM
<voidspace> dimitern: thanks
<mup> Bug #1527595 opened: leader-set doesn't preserve newlines <juju-core:New> <https://launchpad.net/bugs/1527595>
<rick_h_> ericsnow: ping got a sec to chat?
<ericsnow> rick_h_: sure
<wwitzel3> ericsnow: just got off the phone with rick_h_ , we have some things we need to chat about during standup when natefinch is back online
<ericsnow> wwitzel3: k
<natefinch> any the old irc on the tablet trick. classic.
<natefinch> s/any/ahh
<natefinch> sigh
<natefinch> anyone have the Canonical irc info handy? it has changed since the last time I had to do this
<natefinch> wwitzel3 or ericsnow?
<wwitzel3> natefinch: not handy ;) looking now
<mgz_> natefinch: you need personal info from enigma
<mgz_> natefinch: read wiki.canonical.com/StayingInTouch/IRC
<natefinch> mgz_ - that sounds very cold war-ish
<natefinch> ahh yes, irc-credentials.zip, my tablet loves that
<mgz_> natefinch: you can just read the zip
<mgz_> the password is transcribable
 * natefinch looks for an app to open zip files on android
<natefinch> oh yes, thanks for zipping a 100 byte text file
<dimitern> voidspace, frobware, please have a look http://reviews.vapour.ws/r/3420/
<frobware> dimitern, looking
<voidspace> dimitern: will look in a bit if frobware doesn't review it
<dimitern> cheers
<mup> Bug #1527681 opened: azure provider does not appear to be opening ports <juju-core:New> <https://launchpad.net/bugs/1527681>
<mup> Bug #1130038 changed: tools download for upgrade should retry on error <docs> <reliability> <retry> <upgrade-juju> <juju-core:Fix Released> <https://launchpad.net/bugs/1130038>
<mup> Bug #1494848 changed: 1.24+ cannot upgrade in canonistack <canonistack> <ci> <openstack-provider> <streams> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1494848>
<mup> Bug # changed: 1483492, 1497229, 1516036, 1519061, 1519144, 1519149, 1521446, 1525529
<cory_fu> I am finding JUJU_REMOTE_UNIT is set to an empty string during the -relation-broken hook, leaving me no way to tell with whom I have lost the relation.  Is this expected behavior?  This seems very wrong and is leaving me unable to properly clean up after the removed unit
<tvansteenburgh> cory_fu: i dunno if that's expected or not, but you could do your cleanup in -relation-departed instead
<tvansteenburgh> cory_fu: once -broken fires, the relation no longer exists. that may be why the remote-unit is no longer defined
<cory_fu> tvansteenburgh: Yet all the other vars are, so... inconsistency.  :/
<cory_fu> tvansteenburgh: What I was expecting was that I could set a state during -relation-departed and then follow-up on it in -relation-broken.  However, because remote_unit is no longer available, I can no longer tell for whom I set the previous state
<cory_fu> I'm not sure I see the point of -broken in that case.  We can't do any clean-up during it because we have no idea who it's running for
<cory_fu> tvansteenburgh: Hrm.  In fact, -broken can't be used at all with reactive because of this
<mup> Bug # changed: 1403655, 1459033, 1489215, 1497098, 1497807, 1497829, 1506680, 1511138, 1512371, 1513492, 1513982, 1516498, 1516891, 1517743, 1517744, 1519027, 1519097, 1519145, 1520199, 1521354, 1522001, 1522861, 1523693, 1524135, 1524527, 1526296
<mup> Bug # opened: 1403655, 1459033, 1489215, 1497098, 1497807, 1497829, 1506680, 1511138, 1512371, 1513492, 1513982, 1516498, 1516891, 1517743, 1517744, 1519027, 1519097, 1519145, 1520199, 1521354, 1522001, 1522861, 1523693, 1524135, 1524527, 1526296
<mup> Bug # changed: 1403655, 1459033, 1489215, 1497098, 1497807, 1497829, 1506680, 1511138, 1512371, 1513492, 1513982, 1516498, 1516891, 1517743, 1517744, 1519027, 1519097, 1519145, 1520199, 1521354, 1522001, 1522861, 1523693, 1524135, 1524527, 1526296
#juju-dev 2015-12-19
<cherylj> frobware: if you happen to be around, I have a maas env set up for 1.25.0 (doesn't hit the problem) and 1.25.2 (hits this container problem every time) if you want to compare anything
#juju-dev 2015-12-20
<frobware> cherylj: I plan to take another look at the bug in hour from now; I'm interested in your setup that hits the problem every time as I still find it is intermittent for me.
<thumper> menn0: seems that RB isn't picking it up for some reason https://github.com/juju/juju/pull/4003
<menn0> thumper: looking
<thumper> menn0: I noticed the import ordering in the client auth test file
<thumper> but I'll wait for any other comments
<menn0> thumper: done. looks good. just a couple of little things.
<thumper> ok, ta
<menn0> thumper: later down the track I think we might want to be able switch to read-only mode for existing API connections, but that's not for this PR
<thumper> right
#juju-dev 2016-12-19
<redir> good good
<babbageclunk> Anyone around for a review? https://github.com/juju/juju/pull/6731
<perrito666> Morning
<perrito666> Babbageclunk still need that review?
<perrito666> brb errands
<hoenir> could someone please review my patch ? https://github.com/juju/juju/pull/6523
<rick_h> macgreagoir: can you peek at ^ and try to get natefinch or katco to second when they're around?
<macgreagoir> rick_h: ack
<aisrael> Does juju 2 support the use of lxc copy (cloning a base container)?
<natefinch> aisrael: I don't think so.  Our philosophy was to let lxd maange everything itself
<aisrael> natefinch: Ok. Here's the scenario: I'm looking to see if the base ubuntu image used when launching machines can be customized, i.e., pre-installing packages that will be needed, setting up proxy detection, etc. The goal is to get a faster start-up time for local development.
<natefinch> aisrael: so, I believe you can fool juju/lxd by making an image called ubuntu-xenial  (or whatever series) and then fix that up to be what you want
<aisrael> natefinch: Ok, awesome, let me give that a try. Thanks!
<natefinch> aisrael: also, for local development, manual provider is even faster and easier.  There's no machine startup and you can prepopulate easily.
<aisrael> natefinch: manual instead of lxd provider? Hmm
<natefinch> aisrael: yeah.  You can still use lxd to spin up the machine (if you want), but then just use it as a manual machine.
<aisrael> natefinch: That's an interesting approach. I'd be interested in benchmarking the two for comparison.
<natefinch> aisrael: I'd love to see benchmarks.
<deanman> aisrael, If you manage to fool juju to use a local lxc image please give a shout. I did try the other day to copy an existing image and giving it alias like ubuntu-xenial but somehow i failed.
<aisrael> deanman: will do!
<frobware> natefinch: ping
<babbageclunk> perrito666: thanks for the review! it was a bit lonely here yesterday.
<babbageclunk> perrito666: Also, we didn't get to have that discussion about squashing commits at the sprint. We should! I think you're right, not being able to bisect is a problem.
<perrito666> babbageclunk: sorry I left early
<perrito666> babbageclunk: of course I am right, that usually is the case :p
<babbageclunk> perrito666: :)
<perrito666> mm, I believe I found a rather ugly bug in our logic
<babbageclunk> perrito666: oh dear
<babbageclunk> perrito666: do you know anything about macaroons and authentication? I've been bumping my head on a bug but it might be something obvious to someone more familiar with it.
<petevg> Hi, everyone. I'm running into an interesting issue while testing matrix: the landscape bundle in the store deploys successfully when deployed w/ the command line client, but it fails when deployed via the gui, or by python-libjuju (the latter is used in the mtarix).
<petevg> Specifically, the config changed hook in haproxy fails, with a KeyError getting the "services"
<petevg> *getting "services" from the config.
<petevg> In the bundle.yaml, "services" is an empty string. Does anyone know if the command line client does anything special with falsey config values?
<petevg> Possibly something that the gui and python-libjuju should replicate?
<natefinch> babbageclunk: I know a tiny bit about macaroons
<perrito666> babbageclunk: nope, but we can try to think together
<babbageclunk> perrito666, natefinch: yay thanks! I'm working on bug 1650451
<mup> Bug #1650451: Migration silently  fails when performed by a newley registered and granted super user <juju:New> <https://launchpad.net/bugs/1650451>
<babbageclunk> What seems to be happening is that there are normal API requests to the target controller that succeed (so must have the right macaroons)...
<babbageclunk> And then the websocket connection to the logtransfer endpoint fails with "cannot get discharge: interaction not possible"
<natefinch> do the previous actions need superuser creds?
<natefinch> I wonder if it's just a timing issue
<babbageclunk> natefinch: yeah, everything on the migrationtarget facade requires superuser
<babbageclunk> natefinch: maybe? It happens reliably though.
<babbageclunk> natefinch: I think thumper had to fix something in the connection to the target api for a similar scenario (maybe the same test). But I haven't been able to find his change, and he's on holiday. I might ping him on alternative channels to see if he can give me a quick pointer.
<natefinch> babbageclunk: so, the last login I see before migration starts starts here: 22016-12-16 01:44:21 TRACE juju.rpc.jsoncodec codec.go:120 <- {"request-id":1,
<natefinch> that's the response to the login, which returns some data, which seems relevant: "controller-access":"superuser","model-access":""
<natefinch> I wonder if the lack of model access is a problem.  It would be interesting to see if that access field is different in a case where the user is a superuser to start
<natefinch> I would expect that controller superuser access would just override needing model access, but I don't know for sure
<babbageclunk> natefinch: yeah, that makes sense - it should work in the case where the user doesn't have model access, but maybe the auth in logtransfer isn't getting that right.
<natefinch> I gotta run to make dinner, but I'll be back on later.
<babbageclunk> natefinch: ok, thanks!
<mup> Bug #1651260 opened: landscape bundle error when deployed via gui (KeyError in config changed hook in haproxy charm) <juju-core:New> <https://launchpad.net/bugs/1651260>
<babbageclunk> perrito666: ok, what about bug 1650251
<mup> Bug #1650251: Model migrations fail if cloud names don't match <model-migration> <juju:New> <https://launchpad.net/bugs/1650251>
<perrito666> babbageclunk: cannot open the bug for lack of bw
<perrito666> bootstrapping a vmware machine is very bw intensive
<perrito666> bbl when this is finished and I dont have 3 seconds of lag for each time I hit enter
<babbageclunk> perrito666: no worries - I was about to type my findings and current thinking to you, but then realised I should put them on the bug instead of in irc
<redir> perrito666: babbageclunk are we doing standup?
<babbageclunk> redir: I thought we weren't but I can!
 * redir shrugs it's on my calendar still. but that might just be mine
<perrito666> I also thought we werent
<perrito666> also, I have been uploading a vmware image for the past 50 mins and it would seem it will take another 50 mins
<perrito666> so no chance I can do a video call
#juju-dev 2016-12-20
<perrito666> Redir no one cancelled it it would be us 3 do you guys need anything or would like to discuss anything? If so I am perfectly fine with doing it but will have to wait a bit :p still uploading
<redir> perrito666: babbageclunk and I caught up for ~15 minutes compared notes...
<perrito666> Cool
<perrito666> Just ping me
<perrito666> I actually am ircing from the phone with let :p
<redir> I've got a new error. That's progress right
<perrito666> Yes it is
<redir> "hostname": ["Node with this Hostname already exists."]}
<redir> helpfule
<perrito666> Mm while doing what?
<redir> start a kvm instance
<redir> here juju.provisioner kvm-broker.go:73 failed to prepare container "0/kvm/1" network config:
<redir> digging around in state.prepareorgetcontainerinterfaceinfo
 * redir eods
<redir> got to go to dinner
<blahdeblah> anyone know when 1.25.9 will be released to the stable PPA?
<blahdeblah> It's showing as released to centos & windows & tarballs, but xenial PPA is still on 1.25.8
<blahdeblah> http://ppa.launchpad.net/juju/stable/ubuntu/pool/main/j/juju-core/ is showing nothing later than 1.25.6!
<babbageclunk> Does anyone feel like doing a review? https://github.com/juju/juju/pull/6735
<blahdeblah> Does anyone feel like publishing 1.25.9 to the PPA? :-)
<jam> babbageclunk: I made a comment on https://github.com/juju/juju/pull/6735#pullrequestreview-13765367
<perrito666> jam: babbageclunk might be sleeping
<bdx> hello all
<bdx> I'm experiencing really high controller memory usage for a very small environment, is there a preferred method of gathering controller metrics when submitting other than just manually grabbing things?
<bdx> possibly a tool that gathers all the important metrics in one swoop
<redir> bdx: try this https://github.com/juju/juju/wiki/pprof-facility
<redir> bdx: though you might also check mongod and see how much memory that is using
<babbageclunk> jam: thanks! looking now
<babbageclunk> rogpeppe: ping?
<babbageclunk> jam: you're probably not still around, but I replied to your comment, thanks!
<frobware> redir, babbageclunk: easy review ... https://github.com/juju/juju/pull/6737
<babbageclunk> frobware: yay, looking!
<babbageclunk> frobware: LVGTM
<frobware> muchas gracias
<babbageclunk> frobware: de nada
<babbageclunk> frobware: do you mean $$merge$$?
<frobware> babbageclunk: ah, crap.
<frobware> babbageclunk: oh, well. getting late. :./
<babbageclunk> frobware: don't worry, it's just a machine!
<frobware> babbageclunk: it'll pass on !!build!!, then fail on $$merge$$ :-D
<babbageclunk> frobware: true that
<babbageclunk> frobware: you can do them in parallel, you know
<redir> $$build$$
<redir> !!merge!!
<redir> oh, dear
 * babbageclunk chuckles
<babbageclunk> I always do !!chittychitty!! anyway.
<redir> babbageclunk: I almost responded with a !!trulyscruptious!! once. But decided against it
<redir> scrumptious even
<babbageclunk> redir: that's the best
<redir> yeah that and grow the roses
<redir> not that I know the names of the songs, I just remember them
<redir> sooo close on the kvm bits
<redir> just two problems eluding me
<redir> Ok maybe just one problems
<redir> Ok maybe just one problem
<bdx> redis: thanks for the pprof link
<bdx> redir:^
<bdx> redir: it looks like I have a mongo process thats been hanging around for > 3hrs, and using > 30% of my memory
<bdx> another thats been hanging out for > 1 hr, and using > 15% mem
<perrito666> Morning redir and Babbageclunk
<redir> morning perrito666
<babbageclunk> morning perrito666
<babbageclunk> I mean, evening.
 * perrito666 is queuing in the supermarket
<redir> bdx mongo can appear to be using much more memory than it really is
<babbageclunk> natefinch: ping?
<natefinch> babbageclunk: howdy
<perrito666> Hey finch did not realize you where here :)
<babbageclunk> natefinch: did you get anywhere with that migration status bug?
<natefinch> babbageclunk: totally forgot about it.  I'll work on it tonight.
<babbageclunk> natefinch: thanks!
<perrito666> Lol all of us are waiting for that one
 * natefinch puts it in the kanban this time
<perrito666> Is sinzui off for the rest of the week?
<natefinch> so I've heard
<natefinch> babbageclunk: was there a bug link for that issue?
<redir> bdx: see the mongo docs https://goo.gl/u6wFYP
<babbageclunk> natefinch: sorry, here you go: https://bugs.launchpad.net/juju/+bug/1650425
<mup> Bug #1650425: migration: migrating back gives "target prechecks failed: model is being migrated out of target controller" <juju:New> <https://launchpad.net/bugs/1650425>
<babbageclunk> frobware: other way around - check build failed and merge build passed!
<frobware> babbageclunk: I'll take it!
<frobware> babbageclunk: "that's the way I like it... " - sing along!
<veebers> perrito666: yep, sinzui is off until next year :-0
<veebers> err :-)
<perrito666> redir: babbageclunk want to do a quick hangout to sync?
<redir> sure
<babbageclunk> perrito666: yup
<perrito666> standup ho?
<redir> blew jeans?
<redir> HO?
<redir> brt grabbing water
<babbageclunk> i'm there already
<perrito666> bluejeans
<perrito666> sorry
<perrito666> I would really appreaciate a review of https://github.com/juju/juju/pull/6738
#juju-dev 2016-12-21
<babbageclunk> perrito666: review'd! (for what it's worth!)
<redir> jam yt?
<jam> redir: hello
<redir> got a minute?
<redir> I've got an issue troubleshooting kvm in kvm on vmaas replacing uvtool for managing kvm in juju
<redir> perrito666 thought you might have some ideas
<redir> jam ^
<jam> redir: give me a couple mins to get this test compiling and I'll be there
<jam> hangout?
<redir> np
<redir> holler
<redir> yes
<redir> hangout
<redir> jam were you asking for a hangout?
<redir> yes you were
<redir> jam https://hangouts.google.com/hangouts/_/canonical.com/jam
<jam> redir: well, I can chat with you however you would like
<jam> but a hangout seems easiest
<jam> brt
<redir> np
<rogpeppe> babbageclunk: pong
<voidspace> who os Trent Lloyd
<voidspace> *is ?
<voidspace> Ah, a Canonical guy
<voidspace> Just reading what is perhaps the best written bug report I've ever seen :-)
<voidspace> a bug report that fully understands and explains the problem as far as I can tell
<voidspace> a thing of beauty :-)
<perrito666> lol, link
<voidspace> perrito666: https://bugs.launchpad.net/juju/+bug/1631254
<mup> Bug #1631254: [2.0rc3] lxd containers do not autostart <rteam> <juju:In Progress by mfoord> <https://launchpad.net/bugs/1631254>
<perrito666> voidspace: beautiful report indeed
<voidspace> jam: did you settle on skipping the test for now?
<jam> voidspace: so I have a test which has an ExpectedFailure and then skips
<voidspace> jam: cool
<jam> well, it has an Assert then a skip
<jam> I don't know if gocheck supports Expected Failure
<voidspace> jam: ah, skip on fail
<voidspace> jam: same effect...
 * jam still likes UnitTest a lot more
<voidspace> jam: the Java one?
<jam> voidspace: the python one
<voidspace> jam: the Python one still needs an enormous overhaul
<jam> voidspace: well, lots of stuff layered on it that Bazaar used.
<voidspace> jam: it could be entirely rearchitected - I began that
<voidspace> jam: right
<jam> lifeless was really big on unit testing, so we had quite a bit of helpers
<jam> subunit integration, ability to run just this subset of tests, etc.
<voidspace> jam: yep, he's prodidigious and highly intelligent
<voidspace> jam: he had a preference for complex apis andd over-engineering IMO
<voidspace> jam: his code was always obviously capable, but never quite to my tastes ;-)
<voidspace> jam: what I started for unittest became nose2 - which some people still use but I fear has become abandonware
<voidspace> jam: a lot of the APIs in that came out of discussion with lifeless though
<voidspace> jam: I was working on a fully event based way of integrating with (customising and extending) unittest instead of via subclassing
<jam> voidspace: python definitely plays a lot of games around how magic vs how explici
<voidspace> jam: it was interesting, I would have loved to have completed it - but then life happened
<voidspace> jam: yep, constant tension
<voidspace> jam: I love the guiding principle of "simple things should be simple, complex things should be possible"
<voidspace> jam: so I like to design the API and UX around *the most commmon obvious beginning* way to use it
<voidspace> jam: and then ensure that extending beyond that is possible and as intuitive (i.e. not a jarring jump) from there
<voidspace> similar I guess to the principle of least surprise
<voidspace> from Ruby
<voidspace> but they definitely jump into the magic-auto-configuration everywhere
<voidspace> the major change I wanted to make to what I did in unittest, on the good advice of Holger Krekel, was to have a test context where *all* the state for the current test run lived (including configuration) and then pass that context through everywhere - no global state
<voidspace> so I got as far as breaking everything to begin making that change
<voidspace> and that's where I left it...
<voidspace> like much in life, incomplete and broken ;-)
<rick_h> I always tell folks "start writing the code you want to be writing to get this done, then we'll go write the stuff that makes that possible" :) (re: most common beginning"
<jam> rick_h: do you know when sinzui is going to be around?
<rick_h> jam: no, I don't. He's normally getting online from now through the next hour in a normal work day
<jam> rick_h: I realized a bit late (today) that really all our stuff should probably be targeting the 2.1 branch, so I've updated the stuff I've landed so far, and the stuff I've proposed.
<jam> rick_h: so I think all my stuff is up for review, and frobware is doing the integration with his patches as we speak
<jam> (testing the integration on his MAAS setup.)
<rick_h> jam: k, would it be better to ask sinzui to test tomorrow?
<jam> rick_h: I'm pretty confident about my "restricted NIC" work, as we already landed that in develop. I'm fairly confident about the followup
<jam> rick_h: but the dynamic bridging hasn't been tested in anger mixed with my stuff.
<jam> (its what frobware is doing onw)
<rick_h> jam: ok, so can we email him, cc myself/torsten a binary to test with and any notes?
<rick_h> jam: once the bits land together
<jam> rick_h: the big thing is it feels like I should really be around as curtis is working on it/testing it, and I don't know how to make that happen.
<rick_h> jam: rgr, well let's try async and see if we can make it work.
<rick_h> jam: honestly I think it's good QA to have him play, find things, note them and do it without us over his shoulder
<rick_h> jam: at least in the efforts we've been trying to do to date. We declare what we think things should do and let them verify and find ways to break it.
<frobware> rick_h: I'm happy to be around later in my day; there's no point (should it happen) getting stuck/broken in the first 5 minutes.
<rick_h> frobware: can you kick things off with an email to sinzui then when the bits are ready please?
<frobware> rick_h: bits? so a branch or a juju tarball? any indication what they are expecting?
<rick_h> frobware: no, I think they'd start with develop, but if we have a preference we should email and indicate our preference.
<rick_h> frobware: be a tarball, branch, etc
<jam> frobware: rick_h: I'm putting together an email, just still writing it.
<frobware> rick_h: so the integration branch I'm using is not in develop (yet) - need more work
<jam> frobware: right, but its based off develop, not 2.1
<frobware> jam, rick_h: correct
<jam> frobware: rick_h: I have patches for all of my stuff up for review, and a second set of patches against 2.1 up for review.
<jam> frobware: I told Curtis about your integration branch as the place-to-work-from for now
<jam> I probably left off that it isn't 2.1
<jam> all the files that I've worked in are identical between 2.1 and develop, so just doing "diff + patch" works very well.
<jam> rick_h: email sent (you are CCd)
<jam> catch y'all later. You can Hangout me directly if you need something urgently.
<frobware> jam: that's good news. I guess not much generally happng helps here.
<frobware> jam: ty
<redir> morning
<perrito666> redir: your morning starts a lot like my afternoon
<redir> :)
<perrito666> bbl relocation
<redir> anyone know what else uses the $paths.DataDir/containers/juju-id-n/cloud-init data?
<babbageclunk> rogpeppe: sorry, only saw this now - was going to ask you about a bug involving macaroons and websocket connections (for log streams)
<babbageclunk> rogpeppe: I think I've sorted it out but if you're around and not busy/off to bed soon it might be worth confirming with you?
<babbageclunk> jam: did you see my response to your comment on https://github.com/juju/juju/pull/6735
<redir> ssh
<babbageclunk> perrito666, redir: anyone know how I can construct fully-discharged macaroons for a test I'm struggling to write?
<perrito666> babbageclunk: no clue at all
<redir> babbageclunk: I'd start here https://github.com/go-macaroon/macaroon/blob/v1/macaroon_test.go
<babbageclunk> perrito666:
<babbageclunk> :(
<babbageclunk> redir: ooh! I'll look at that thanks
<perrito666> seems redir is more helpful than I
<redir> yay things don't work on trusty
<babbageclunk> perrito666: you've been helpful before - in my tally he's only a *tiny* bit ahead
<perrito666> :p
<perrito666> k redir babbageclunk I think Ill call it a day :)
<perrito666> if you need me email me and ill be back
<perrito666> </terminator>
<babbageclunk> perrito666: night!
<redir> no standup :o perrito666 knows what I've been doing today
<redir> have a good night
<babbageclunk> redir: ok - my plaintive cry above is basically my status - found the solution to the macaroon problem I had, struggling to test it.
<redir> I can finally show some working kvm bits and no one is around to see. sigh
<redir> good luck with the macaroon tests
<redir> they sort of work the opposite of how I want them to
#juju-dev 2016-12-22
 * redir eods
<babbageclunk> If anyone's around and feels like a review: https://github.com/juju/juju/pull/6742
<rogpeppe> babbageclunk: you only missed me by 17 minutes that time!
<ashipika> can somebody please tell me what i need to do to resolve this: 15:40:42 ERROR cmd supercommand.go:458 failed to bootstrap model: cannot start bootstrap instance: Missing parent 'lxdbr0' for nic 'eth0'
<mup> Bug #1488245 opened: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <landscape> <lxc> <oil> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1488245>
<babbageclunk> redir, perrito666: around? Can I get reviews? https://github.com/juju/juju/pull/6742
<redir> babbageclunk: I'll look in a minute
<babbageclunk> and https://github.com/juju/juju/pull/6735
<redir> almost ready for a trade:)
<babbageclunk> redir: thanks!
<babbageclunk> uh oh
<babbageclunk> natefinch: did you get anywhere with bug 1650425?
<mup> Bug #1650425: migration: migrating back gives "target prechecks failed: model is being migrated out of target controller" <juju:New> <https://launchpad.net/bugs/1650425>
<perrito666> babbageclunk: looking
<babbageclunk> perrito666: Thanks!
<perrito666> babbageclunk: regarding the cloud name one I share jam's concern
<babbageclunk> perrito666: ok - I didn't quite understand his but I haven't been able to discuss with him yet. I'll read your comment.
<perrito666> I didnt add one, I think the orderly thing to do is to make Name a part of cloud
<perrito666> sadly you are out of jam until next year I believe unless he is still around
<perrito666> bbl, pre-christmas errands
<babbageclunk> perrito666: ok - I can certainly add it to Cloud.
<babbageclunk> perrito666: But we wouldn't want to add it in clouds.yaml, right?
<babbageclunk> oops, he's gone out
<babbageclunk> redir: perrito666 approved the other one (thanks perrito666!) and really I need to talk about the other one with jam to work out what to do so stand down
<redir> ok
<redir> thanks
<babbageclunk> redir: phew that means I don't have to do yours ;)
<redir> hey now
<redir> you might be the only poor soul left
<babbageclunk> i kid!
<redir> I have 2 tests -- in a provisioner package --  that I know of that fail. I need to fix those and then I'm ready for a looksee
<perrito666> Redir back pass me your pr
<redir> perrito666: 2 tests left to fix I think
<redir> then I'll make a pr
<perrito666> Babbageclunk not to clouds.yaml only to that Struct, otherwise you might want to take out the name deciding logic and then put together an Argos strict
<natefinch> babbageclunk: I had to take yesterday off because of a sick kid.  Working on that one now. THought I had it fixed, but still seeing problems
<redir> hopefully in the next hour or so
<babbageclunk> natefinch: cool, thanks. Hope the kid's all better!
<babbageclunk> perrito666: ok, makes sense. Hmm, what's an Argos struct?
<perrito666> It's args when auto corrected by my phone
<babbageclunk> perrito666: I'll add it and see how it looks.
<perrito666> redir: I  am still here if you need a review
<TheMue> perrito666: Heya
<perrito666> heya TheMue what are you doing around here?
<TheMue> perrito666: reactivated my irc bouncer and still having juju in my channel list
<TheMue> perrito666: that's fine, keeping contact
<perrito666> heh nice
<TheMue> yep
<TheMue> currently working a bit on my couchdb client
<babbageclunk> perrito666: you and jam were right, it's much nicer.
<babbageclunk> (with Cloud.Name)
<redir> perrito666: running the full test suite and doing QA then making a PR
<redir> perrito666: babbageclunk https://github.com/juju/juju/pull/6748
<redir> since you're bored
<babbageclunk> redir: yay! looking
<redir> I expect I have one or two more tests that I need to fix, but they pass here because I have libvirt installed
<babbageclunk> redir: holy crap, just noticed the line count.
<redir> babbageclunk: there's a really big test data file.
<redir> so that is pretty misleading
<babbageclunk> redir: does the test file all need to be there?
<redir> shoot me if I ever really try to add that many lines of new code in one PR
<redir> babbageclunk: it is a signed file:/
<redir> so kind of or we can't test simplestreams parses a valid signed file
<redir> and that is much bigger than the tools streams
<babbageclunk> redir: there's no way to hack in a key of our own so we could use a fake signed file?
<redir> the key is alread in our code.
<redir> I mean that could all change, but that would be beyond adding image downloads parsing, which is what was done to pull images to replace uvtool
<redir> maybe compressing it and having the test server uncompress it for the test would make it smaller if that is a concern. I guess it depends on what the issue is.
<redir> it's a bunch of lines but it isn't that big in size since it's just text
<babbageclunk> redir: yeah, fair enough.
<babbageclunk> redir: do I need to do anything to my vmaas KVMs to allow nested kvms inside? I'm getting an error following the QA steps.
<redir> yeah
<redir> HO?
<redir> prolly easiest
<babbageclunk> ok - in standup?
<redir> https://hangouts.google.com/hangouts/_/canonical.com/babbageclunk
#juju-dev 2016-12-23
<redir> so we now require 3.5 GB ram for a controller?
<babbageclunk> hey redir, I get this error making a kvm on a trusty node:
<redir> :(
<babbageclunk> 2016-12-23 00:52:59 DEBUG juju.container.kvm run.go:21 output: error: Failed to define domain from /var/lib/juju/containers/juju-862251-1-kvm-3/juju-862251-1-kvm-3.xml
<babbageclunk> error: unknown OS type hvm
<babbageclunk> What should I send you?
<redir> what version of libvirt?
<babbageclunk> probs that xml file.
<redir> libvirt-bin
<redir> sure
<babbageclunk> um, on the trusty machine?
<redir> yes
<babbageclunk> 1.2.2-0ubuntu13.1.17
<redir> hmmm
<babbageclunk> redir: xml file: http://paste.ubuntu.com/23670985/
<redir> So I think that happens if kvm kernel mods aren't loaded o
<redir> which is installed by qemu-kvm I believe
<babbageclunk> I can check whether that's installed on the machine
<redir> k
<babbageclunk> redir: 2.0.0+dfsg-2ubuntu1.30
<redir> also if it is kvm in kvm check if host-passthrough is really set
<babbageclunk> I checked that
<babbageclunk> it is
<redir> what's lsmod | grep kvm say?
<babbageclunk> ha, I was just copying that from a serverfault article!
<babbageclunk> kvm_intel             143187  0
<babbageclunk> kvm                   455843  1 kvm_intel
<redir> google rules
<babbageclunk> vmx turned on
<babbageclunk> I guess not suprising, since the other machine works.
<redir> is trusty the base os or on one of the vms in vmaas?
<redir> and what kind of cpu?
<babbageclunk> on the vm in vmaas
<babbageclunk> cpu - not sure
<babbageclunk> what's the best way to find out?
<redir> first look at virsh capabilities
<redir> $ virsh capabilities
<redir> can you send or pastebin that?
<babbageclunk> It says SandyBridge - sure, pastebinning.
<babbageclunk> oh - do you want that run on the vmaas node, or the host?
<redir> hmmm
<redir> maybe both
<redir> but prolly the one that is failing
<babbageclunk> Ok, this is from the vmaas node that's failing: http://paste.ubuntu.com/23671042/
<babbageclunk> redir: this is from the node that works: http://paste.ubuntu.com/23671045/
<babbageclunk> This from the host machine: http://paste.ubuntu.com/23671048/
<redir> ok
<babbageclunk> Hmm - that's weird - the failing one is v different. Maybe the host-passthrough didn't stick.
<babbageclunk> I'll shut the machine down and set it more firmly
<redir> can you log into the failing node and try manually installing qemu-kvm and let me look at the others
<babbageclunk> redir: reprovisioning the machine now.
<redir> sorry neighbors stopped by
<redir> let me look at others made no sense
<redir> I think that error is related to not having qemu-kvm installed or loaded
<redir> which would make sense if pass-through didn't work or apt-get failed to install qemu-kvm for some reason
<redir> I dont' know what happens if the package manager in juju fails to install a package
<babbageclunk> on the reprovisioned node virsh capabilities now says Haswell-noTSX
<babbageclunk> oh no, hang on - forgot the --series xenial.
<redir> whelp merging in the stuff from develop seems to break things anyhow
<redir> I'm was a bit behind
<redir> had to resolve a couple conflicts but it seems that there's some issue with bridge and spaces
<redir> I suppose I'll have to hit up frobware and jam when they are around
<babbageclunk> bums
<babbageclunk> sorry, I mean I forgot --series trusty. I think my brain's already gone on holiday.
<babbageclunk> rerereprovisioning now
<redir> yeah, they are failing with  juju.provisioner failed to prepare container "1/kvm/0" network config: unable to find host bridge for spaces [] for container "1/kvm/0"
<redir> so it only worked until I merged in develop
<redir> :)
<redir> :|
<deanman> Hey, anyone seen this before `message: 'hook failed: "cni-relation-changed" for flannel:cni'` on canonical-kube LXD deployment ?
<voidspace> jam: ping
<perrito666> voidspace: today is saturday for jam so you lost him until next year I presume
<voidspace> perrito666: yeah, I remembered after I pinged. Thanks.
<voidspace> perrito666: but hey, we have each other, so all is not lost ;-)
<jam> voidspace: perrito666: I don't pretend to be around, but I guess I can't hide either.
<voidspace> jam: none of us can hide, not for long anyway...
<voidspace> jam: :-)
<voidspace> jam: anyway, I "made a decision" and am just seeing if it works - you can comment on the review when it gets there
<voidspace> jam: anyway, happy holidays and see you on the other side
<perrito666> Jam is this an actual holiday for you are just dragged by the shutdown?
<jam> voidspace: thanks, you too
<jam> perrito666: We have some stuff we're trying to get done for 2.1, so I'm half-around trying to shepherd it through.
<perrito666> I see but my question was in the cultural side
<perrito666> Is it some form of holiday where you are?
 * perrito666 is under the impression most cultures celebrate something around this time of the year
<perrito666> redir: your patch violates the 500 lines or less by about 30000 lines :p
<redir> perrito666: in reality it is about 2000 lines maybe even less
<redir> perrito666: and the first two commits have been reviewed once.
<perrito666> I am reviewing the whole thing redir
<perrito666> so far like a lot what I see
<perrito666> point me to the relevant commit if you want
<perrito666> brb lunch
<redir> perrito the whole thing is good:)
<redir> it needs it since it is over 500 lines
<redir> jam frobware voidspace just a bug in your ear https://github.com/juju/juju/pull/6748#issuecomment-268935865
<redir> maybe it will register something
<perrito666> redir: I sent several changes  but apart from those LGTM
<perrito666> also, your code is usually so clean that it makes me all warm and fuzzy inside
<redir> perrito666: aw shucks:)
<redir> and thanks for taking on the big PR, I appreciate it
<perrito666> np, as I said, interesting read
<voidspace> redir: I've only just twigged that you're reed... !!
<redir> reed-er
<redir> reed was taken...
<voidspace> redir: heh
<voidspace> redir: anyway o/ happy christmas :-)
<redir> you too voidspace and HNY!
<perrito666> I thought I was the only one left
<voidspace> perrito666: I think I've verified my fix works, but I haven't written a test and I need to scour the code to check for unintentional semantic changes
<voidspace> perrito666: it would be nice to get a PR tonight, it's not 8pm yet
<voidspace> perrito666: but I might not make it
<perrito666> k I am heading out early, happy holidays to all
<redir> later perrito666 Feliz Ano Nuevo
 * redir steps AFK for a bit.
#juju-dev 2016-12-24
 * redir goes eoy shortly
#juju-dev 2017-12-19
<babbageclunk> anastasiamac: Could you take a look at https://github.com/juju/juju/pull/8242 if you get a chance?
 * anastasiamac looking
<babbageclunk> thanks!
 * babbageclunk goes for a run
<babbageclunk> anastasiamac: thanks for the review - not sure what happened with the build, there aren't any failures in the output, it just dies at the end.
<babbageclunk> anastasiamac: I'll ask John to have a look at it too
<anastasiamac> babbageclunk: nws - thnx for doing the work :D
<babbageclunk> jam: could you take a look at https://github.com/juju/juju/pull/8242 when you have a moment?
<jam> babbageclunk: are we sure that we want this behavior?
<jam> I'm happy to have it be something that can be enabled
<jam> but omitting things because *we* have chosen that they aren't interesting doesn't sound like the right behavior.
<jam> having better ways to filter the content seems a better fix
<rogpeppe1> anyone know if there's an API call that lets a client find out what access rights a user has on a model?
<jam> rogpeppe: ListModelsWithSummaries and ModelInfo I believe both have the user's access rights to the model as part of it.
<rogpeppe> jam: but nothing that just gets rights for an individual user? (the results from either of those calls could be large)
<rogpeppe> jam: all i need to do is set permissions for a user to a given level, but the grant call doesn't make that easy...
<jam> rogpeppe: ModelInfo would be the information on just one model, but I don't particularly know of such an API>
<jam> and you're right it also includes stuff like what machines, etc.
<Soumaya> Hi all ..
<Soumaya> We are integrating a Vepc testcase on OPNFV with juju as orchestrator ..
<Soumaya> But we are facing some issue related to bootstrap .... Bootstrap is failing with the following error message .....
<Soumaya> ERROR fetching hosted model spaces: adding subnet "169.254.192.0/18": subnet "169.254.192.0/18" already exists
<Soumaya> How we can resolve this issue ..
<Soumaya> is there any mailing list for juju-dev so that i can send detail log for more detail view..
<rick_h> Soumaya: definitely: I'd email: https://lists.ubuntu.com/mailman/listinfo/juju
<rick_h> Soumaya: make sure to sign up first so it doesn't get stuck in the moderator queue
<rick_h> Soumaya: as it's the last week before holiday shut down folks are starting to disappear but hopefully can get you some info turned around
<rick_h> wpk: any hints on what to look at? ^
<rick_h> Soumaya: what substrate is this? an openstack?
<Soumaya> yes on openstack ..
<Soumaya> OPNFV POD ...
<Soumaya> Actually we are stuck in bootstrap ...
<Soumaya> @rick_h thanks for information
<wpk> rick_h: that should be fixed in new Juju (2.3), we're now ignoring link-local autoallocated addresses
<rick_h> wpk: oic, if soumaya comes back I'll let him/her konw
<hml> babbageclunk: ping
<babbageclunk> hml: hey
<hml> babbageclunk: do you have time for an HO?
<babbageclunk> sure!
<babbageclunk> in standup?
<hml> babbageclunk: sounds good
<babbageclunk> I win!
<hml> babbageclunk: if you have a minute: https://github.com/juju/juju/pull/8244
<babbageclunk> hml: sorry, was at Ada's end of year concert, was adorable.
<babbageclunk> looking now
<hml> babbageclunk: no worries - thx
<babbageclunk> hml: looks like you have a test failure
<hml> babbageclunk: checking
<hml> babbageclunk: i forgot to add a new file.  :-/
<babbageclunk> hml: classic :)
<blahdeblah> But not as classic as "Never argue with a Sicilian when death is on the line".
<babbageclunk> ha, I love that movie - Alice can quote long stretches of it.
<hml> blahdeblah: ha!
<hml> carl elwes wrote a book about making that movie.  lots of input from the others
<blahdeblah> Yeah - never gets old.  I'll probably watch it 100 times in my life and still be laughing the same at the 100th time.
<hml> true
<babbageclunk> the book's great too
#juju-dev 2017-12-20
<babbageclunk> oops
#juju-dev 2017-12-21
<hml> babbageclunk: the controller reboot did the trick  :-)
<babbageclunk> nice
<lastp901> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEocgnhpvakb: tvanst
<lastp901> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEljqxtfat: coreycb beisner anthonyf stokachu bdx admcleod tinwood tvansteenburg
<lastp901> âââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEalhfyn: ejat ryebot ubot9 alexisb beisner tvanst
<lastp901> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEyamoyyjcy: alexlist mthaddon jw4 seyeongkim akhavr ryebot
<lastp901> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEplaqg: bdx chaology aisrael seyeongkim veebers dpb1 alexli
<lastp901> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEcbsraf: dpb1 mup seyeongkim
<lastp901> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEgabejop: seyeongkim beisner tasdomas arosales marlinc jam blahdeblah admcleod jillr nottrobin tvansteenburgh
<lastp901> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEfdhuqeayq: jog coreycb babbageclunk ubot9 chrome0 arosales mbarnett anastasiamac beisner dpb1 anthonyf hazmat aisrael
<lastp901> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEzqlzzbtkqt: stokachu tvanste
<lastp901> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEolsyeqki: ryebot pjdc babbageclunk veebers jillr dpb1 akhavr aluria blahdeblah iatrou admcleod gsamfira Maky
<lastp901> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEtdczvv: tvansteenburgh1 axin
<lastp901> ââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEsncsvfkqvm: dpb1 stokachu aisrael alex
<lastp901> âââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEcgnvtbma: beisner iatrou ubuntulog2 menn0 blahde
<lastp901> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEngaepkkiy: aisrael blahdeblah ryebot iatrou anastasiamac ejat vern bdx mthaddon axino nottrobin akhavr alexisb Spads j
<lastp901> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEanrawtut: iatrou a
<blahdeblah> jam: and here ^
<ryebot> jam: ^
<lastp901> âââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEkskjzn: jam kwmonroe Makyo admcleod blahdeblah a
<lastp901> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEfjidp: coreycb mbarnett iatrou nottrobin pjdc beisner waigani jillr Makyo marlinc rharper` tasdomas aisrael akhavr bab
<ryebot> ah thanks
<lastp901> âââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEqpsgo: jam tasdomas junaidali meetingology arosales seyeongkim Makyo
<lastp901> ââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEjlrda: seyeongkim alexlist tinwood ubot9 Spads waigani meetingology anthonyf coreycb marlinc aisrael vern admcleod axi
<lastp901> âââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEeuuodepdet: jog mthaddon ejat blahdeblah meetingology anastasiamac r
<lastp901> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEptmakmtgqe: veeber
<lastp901> âââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEmiihtekdjc: jam seyeongkim w
<lastp901> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODElvbdwmqqc: admcleod ejat chaology tasdomas mbarnett ryebot Odd_Bloke jog alexlist kwmonroe tvansteenburgh1 a
<lastp901> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEvcbaxoqa: Spads ch
<lastp901> ââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEtbejvd: chaology dpb1 tinwood waigani
<lastp901> âââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEoerkhxp: jw4 babbageclunk jam aluria mup ryebot anastasiamac anthonyf chrome0 coreycb junaidali waigani axw
<lastp901> ââââââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEoikanekjc: marlinc
<lastp901> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEscpxy: junaidali jam beisner seyeongkim chrome0 nottrobin stokachu alexisb hig
<lastp901> ââââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEfouiq: meetingology tinwood mbarnett mthaddon menn0 jog ja
<lastp901> ââââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEtxjgdgylet: seyeongkim kwmonroe chaology Makyo ejat kjackal_bot jog aisrael mb
<lastp901> âââââââââââââ https://beta.companieshouse.gov.uk/company/10308021/filing-history christel sold freenode to Private Internet Access Andrew Lee WHO ALSO OWNS SNOONET AND IS MOVING FREENODE TO THAT SERVER (NEXT MONTH) AND CLOSING DOWN OPEN SOURCE ROOMS PLEASE COMPLAIN IN CHAN FREENODEcacczg: admcleod rharper` iatrou junaidali ubuntulog2 coreycb higgins` pjdc babbageclunk
