[00:00] <perrito666> sinzui: btw, most likely I will be trying to fix restore failing from good connections issue :)
[00:09] <arosales> wallyworld_: I got the limits lifted on Joyent if you want to give it another try, when you have time.
[00:10] <wallyworld_> arosales: otp, sec
[00:10] <arosales> wallyworld_: ack
[00:15] <wallyworld_> arosales: thanks for that. curtis ran into the same issue originally as well but the CI tests were wteaked to deploy into lxc containers instead of a new instance and it all looks good :-)
[00:16] <arosales> wallyworld_: yup that was on two different accounts too so I am checking with Joyent if we need to include that in our instructions of if the could lift that globally to at least 10 instances or something reasonable like that
[00:16] <wallyworld_> sure
[00:17] <arosales> wallyworld_: would be nice to get confirmation you can add-unit or deploy more than 1 service (without colocating)
[00:17] <arosales> incase I need to ping Joyent again
[00:17] <wallyworld_> ok, i'll try it out as soon as i can today
[00:19] <arosales> wallyworld_: ack and no rush just wanted to let you know before I grabbed some dinner
[00:19] <arosales> wallyworld_: and again thanks for getting that landed wouldn't have happend with out you chipping in
[00:19] <wallyworld_> np, that's what we're here for
[00:35] <davechen1y> waigani: thanks for lookin into that issue
[00:35] <davechen1y> is the problem that the code is tryin to consume the body without checking the status code ?
[00:36] <waigani> yep, just writing something up now
[00:36] <davechen1y> kk
[01:20] <davechen1y> https://bugs.launchpad.net/bugs/1301663
[01:20] <_mup_> Bug #1301663: cmd/juju: panic during bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1301663>
[01:27] <waigani> davechen1y: lboxing..
[01:28] <davechen1y> waigani: right o
[01:28] <davechen1y> on da phone
[01:28] <waigani> ha, can't lbox because of proxies
[01:48] <stokachu> anyone tested juju 1.17.7 on trusty with kvm in local provider?
[01:48] <stokachu> i can get it to bootstrap but when i deploy none of the vms are being created
[01:48] <waigani> davechen1y: https://codereview.appspot.com/83310044
[01:50] <stokachu> oh interesting looks like im getting a connection refused over the websocket connection
[01:50] <stokachu> lemme fix that first
[01:51] <stokachu> so it just takes a minute to get the connection and then fails with : http://paste.ubuntu.com/7196827/
[01:53] <stokachu> seems to just repeat that warning about no instances found
[01:54] <stokachu> lxc also seems to work just fine
[02:13] <thumper> stokachu: yes, kinda
[02:13] <thumper> stokachu: I tested kvm with saucy when I did it
[02:13] <thumper> but not trusty yet
[02:29] <davechen1y> thumper: i'm very concernred at the number of unchecked interface conversions in watcher/watcher.go ~400
[02:29] <davechen1y> lots of shit to go wrong there
[02:30] <davechen1y> i have a stack trace from hazmat that is very worrying
[02:30] <thumper> that certainly is a lot of conversions
[02:30] <davechen1y> i'd like to remove all the v, _ 's
[02:31] <davechen1y> this code behaves as if the conversion cannot fail
[02:31] <davechen1y> so we should assert that by not using the two arg version
[02:31] <davechen1y> for example
[02:31] <davechen1y>                         dr, _ := c.Value.(bson.D)
[02:32] <davechen1y> if this isn't a bson D, then what the fuck is it ?
[02:33] <thumper> and this is just one more reason why I like generics :P
[02:33] <thumper> however...
[02:33] <thumper> I agree, blind type assertions are wrong
[02:33] <davechen1y> there are a few cases in the codebase where they make sense
[02:34] <davechen1y> but I don't think this is one
[02:35]  * davechen1y logs issues
[02:36] <davechen1y> what the complete fuck
[02:36] <davechen1y> ... value *errors.errorString = &errors.errorString{s:"cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units"} ("cannot assign unit \"s0/0\" to machine 1: machine \"1\" cannot host units")
[02:39] <axw> wallyworld_: did your unit address changes get into the 1.18 branch?
[02:40] <axw> wallyworld_: just about to add a comment to #1259908
[02:40] <_mup_> Bug #1259908: juju status of units report private address (172.x.x.x) instead of public fqdn <add-unit> <addressability> <ip> <juju-core> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1259908>
[02:40] <wallyworld_> axw: the ones aligned with jyent provider, yes
[02:40] <axw> right, they had to - thanks
[02:40] <wallyworld_> so the uniter doesn't set unit address on start up anymore
[02:40] <axw> yup
[02:47] <thumper> davechen1y: have you played much with web sockets?
[02:47] <thumper> davechen1y: I'm trying to work out how to write a test that needs to read from a web socket
[02:48] <davechen1y> thumper: i haven't
[02:48] <davechen1y> not at all
[02:48] <davechen1y> sorry
[02:48] <thumper> np
[02:48] <thumper> I'll keep poking with a stick from a distance
[02:49] <hazmat> thumper, do you need to talk websocket to it?
[02:50] <hazmat> thumper, its start of as http 1.1.. then does an immediate upgrade.
[02:50] <hazmat> off
[02:50] <thumper> yes, I think I do, as this is how debug-log is streamed back to the client from the api
[02:51] <davechen1y> yup, that is about all I know
[02:51] <hazmat> thumper, just using an existing websocket client and setup the server on a high socket for test... its separate from the api server afaicr.
[02:51] <thumper> no...
[02:52] <thumper> it is part of the apiserver
[02:52] <thumper> but I have it working so far
[02:52] <thumper> at least tests for the error conditions are good
[02:52] <thumper> perhaps I just make a client like the client would :-)
[02:52] <hazmat> cool
[02:52]  * thumper goes to read more code
[03:14] <waigani> davechen1y: the proxy nuke lines were not meant to be there sorry, taken out now: https://codereview.appspot.com/83310044
[03:15] <davechen1y> waigani: thanks
[03:15] <davechen1y> waigani: let me test it
[03:15] <davechen1y> does anyone else have time for a review ?
[03:24] <axw> davechen1y: I can probably spare some time, what needs reviewing?
[03:24] <davechen1y> https://codereview.appspot.com/83310044
[03:24] <davechen1y> looks pretty staight forward
[03:28] <davechen1y> waigani: LGTM, passes for me
[03:28] <davechen1y> thank you
[03:28] <waigani> sweeeet :)
[03:28] <axw> waigani: please fix Body.Close before landing
[03:28] <axw> waigani: I added a comment
[03:28] <waigani> axw: yep, will do
[03:29] <axw> ta
[03:29] <davechen1y> axw: thanks, good catch
[03:44] <waigani> axw: moved Body.Close to above if, logged the body (debug level), checked log and test on ppc.
[03:44] <waigani> shall I push to lp, or do you want another lbox?
[03:44] <waigani> axw: ^
[03:44] <davechen1y> waigani: lbox propose
[03:45] <waigani> okay
[03:45] <axw> waigani: thanks
[03:45] <waigani> just give lbox half an hour ...
[03:48] <davechen1y> :)
[03:49] <waigani> axw: davechen1y: https://codereview.appspot.com/83310044
[03:51] <axw> shipit
[03:51] <waigani> :D
[03:51] <davechen1y> hodl up
[03:51] <davechen1y> one more thing
[03:53] <axw> yeah, good point about Errorf
[03:53] <axw> waigani: ^^ dontshipit
[03:53] <waigani> haha
[03:54] <waigani> I had my finger on the button
[03:55] <waigani> davechen1y: oh nice. That looks a lot better!
[03:55] <davechen1y> http://paste.ubuntu.com/7197095/
[03:55] <davechen1y> umm, this is bad
[03:56] <waigani> I'll just push that last one to lp right davechen1y?
[03:57] <davechen1y> waigani: lbox propose
[03:58] <waigani> oh shit, I missed the log as error, sorry hang on
[04:00]  * thumper goes to make dinner
[04:00] <thumper> back later tonight for meeting
[04:01] <thumper> hoping to catch rogpeppe before meeting to talk about testing websockets
[04:01] <waigani> my girl just got off the ice so I'm going to have to disappear
[04:01] <waigani> back later tonight
[04:02] <waigani> davechen1y: https://codereview.appspot.com/83310044
[04:03] <davechen1y> ok
[04:04] <waigani> davechen1y: just taking off skates etc so I can ship it if I get an lgtm from you
[04:04] <davechen1y> waigani: i'll review in a sec
[04:04] <davechen1y> i'll mark the review as approved and make sure the bot lands it
[04:05] <waigani> davechen1y: great. Thank you.
[04:12] <davechen1y> oh crap, the joyent test take > 10 minutes
[04:12] <davechen1y> and get killed by the watchdog
[04:14] <wallyworld_> davechen1y: what's the issue with stripping the jujud binary? i didn't add that bit in, just curious
[04:14] <davechen1y> striping go binaries breaks them
[04:15] <davechen1y> we don't strip them in the release build
[04:15] <davechen1y> but I found a place in environs/tools where building local tools it still strips
[04:15] <wallyworld_> yeah. i guess it still works somewhat cause i think that's what upload tools uses
[04:15] <wallyworld_> and people have been running ok with that
[04:15] <davechen1y> wallyworld_: only on amd64
[04:16] <wallyworld_> ah
[04:16] <davechen1y> it really really doens't work for arm
[04:16] <wallyworld_> rightio
[04:16] <wallyworld_> i've assigned it to me to fix
[04:16] <davechen1y> i've already got a fix
[04:16] <davechen1y> will propose in a sec
[04:16] <davechen1y> just running tests
[04:16] <wallyworld_> mark the bug as in progress then!!
[04:16] <davechen1y> ffs
[04:16] <davechen1y> i only just logged it
[04:16] <davechen1y> hold your horsees
[04:17] <wallyworld_> i was trying to be hepful :-P
[04:17] <davechen1y> i know
[04:17]  * davechen1y pats wallyworld_ in a fatherly way
[04:17] <wallyworld_> i saw a few bugs, all raised by you and thought you may need some extra hands on deck :-)
[04:18] <davechen1y> good thinking
[04:18] <davechen1y> wallyworld_: if you have time
[04:18] <davechen1y> i'm really getting nowhere with the simplestreams problems
[04:18] <davechen1y> juju doesn't even build on 386
[04:18] <davechen1y> sorry, i mean the tests don't pass on 386
[04:18] <wallyworld_> which one?
[04:18] <davechen1y> so there is a lot of fixture data
[04:19] <davechen1y> wallyworld_: http://paste.ubuntu.com/7197153/
[04:19] <davechen1y> i'm sorry i can't get better reports
[04:19] <davechen1y> it takes fucking forever to run these tests
[04:19] <wallyworld_> these tests are running inside a 386 vm?
[04:20] <davechen1y> wallyworld_: http://cloud-images.ubuntu.com/releases/14.04/beta-2/
[04:20] <davechen1y> cloud images, just push the button
[04:21] <wallyworld_> oooh. nice
[04:21] <davechen1y> yeah
[04:21] <davechen1y> really nice
[04:21] <davechen1y> need a ubuntu image
[04:21] <davechen1y> push the button
[04:21] <wallyworld_> ok, i have a wip branch i need to get done but i can look at the tests after that
[04:22] <davechen1y> ok
[04:22] <davechen1y> thanks
[05:38] <davechen1y> axw: got a sec ?
[05:39] <axw> davechen1y: yup?
[05:55] <davechen1y> afk for a bit
[06:06] <fwereade> gaah it just took me *far* too long that filepath.Walk does not follow symlinks
[06:06] <fwereade> s/long/long to realise/
[06:08] <axw> fwereade: heh :( been there
[06:55] <rogpeppe> thumper: i'm here if you want me
[06:56] <rogpeppe> fwereade: did you want it to?
[07:17] <fwereade> rogpeppe, I wouldn't usually, but I was passing it a symlink unawares and totally baffled as to why it wasn't walking any further :)
[07:17] <rogpeppe> fwereade: ah...
[07:18] <fwereade> davecheney, ping
[07:18] <rogpeppe> fwereade: early morning amusing reading, BTW, if you hadn't seen it: https://www.usenix.org/system/files/1403_02-08_mickens.pdf
[07:19] <fwereade> rogpeppe, I like that guy's stuff, don't think I've seen that one, thanks :)
[07:19] <rogpeppe> fwereade: me too, and me too
[07:21] <axw> fwereade: do you want to do any final review before I land this? (grouping is not enabled until azure-mode lands)    -- https://codereview.appspot.com/73910043
[07:22] <fwereade> axw, I'll do a quick pass now, if you haven't heard from me in 20 mins don't let me block you
[07:22] <axw> fwereade: okay, thanks
[07:22] <rogpeppe> "So, yes, it would be great if fixing your browser involved actions that were not semantically equivalent to voodoo. But, on the bright side, things could always be worse. For example, it would definitely be horrible if your browser’s scripting lan- guage combined the prototype-based inheritance of Self, a quasi-functional aspect borrowed from LISP, a structured syntax adapted from C, and an aggressively asynchronous I/O model that
[07:22] <rogpeppe> requires elaborate callback chains that span multiple generations of hard-working Americans. OH NO I’VE JUST DESCRIBED JAVASCRIPT. What an unpleasant turn of events! People were begging for a combination of Self, LISP, and C in the same way that the denizens of Middle Earth were begging Saruman to breed Orcs and men to make Uruk-hai."
[07:24] <axw> fwereade: main change after merging is that it now uses DistributionGroup and takes the cloud-service name from the first instance.Id belonging to Azure, whereas the old code would use labels based on principal units
[07:26] <axw> rogpeppe: he's hilarious. I wish more people wrote like him; I might learn more :)
[07:26] <rogpeppe> axw: +1
[07:31] <fwereade> axw, LGTM
[07:32] <axw> fwereade: thanks
[07:59] <axw> fwereade: do you want https://codereview.appspot.com/81340043/ in before I enable azure? bear in mind that azure-mode will not allow add-machine or --to
[08:00] <axw> *enable azure-mode
[08:00] <axw> fwereade: btw, availability-sets-enabled is a bit wordy, do you think we should actually call it azure-mode?
[08:01] <fwereade> axw, sorry, I'm hitting dangling pointers in my brain
[08:01] <axw> no worries :)
[08:01] <axw> it's a bit twisty
[08:03] <fwereade> axw, so, that CL appears to lack tests a bit
[08:03] <axw> fwereade: yeah, it was just a WIP to get your thoughts
[08:04] <axw> I meant, do you want me to flesh it out and continue on with it before calling azure done. This one really is about ec2 and others where you would be allowed to add-machine and --to
[08:04] <fwereade> axw, so AFAICT they won't interact -- unless azure-mode allows for assignment to clean/empty machines, but IIRC it doesn't
[08:04] <axw> right
[08:05] <axw> fwereade: you made a comment on the DistributionGroup CL: "LGTM. Taking DG into account when choosing pre-existing instances is not
[08:05] <axw> in scope for this CL, but please make sure it's on your list of
[08:05] <axw> necessary-features-before-done-done."
[08:05] <fwereade> axw, ok, I think we should get that in, because we want to enable service distribution in the other providers: once we have the interface in place, it becomes a "simple" matter of adding bugs for individual providers
[08:06] <axw> fwereade: agreed, but can I go ahead and land the remaining azure stuff first?
[08:06] <fwereade> axw, certainly
[08:06] <axw> cool
[08:06] <fwereade> axw, sorry slow to catch up :)
[08:06] <axw> no problemo
[08:31] <voidspace> morning all
[08:32] <fwereade> frankban, can I get your +1 on https://code.launchpad.net/~wallyworld/juju-core/watcher-address-issues/+merge/213968 please?
[08:32] <fwereade> frankban, (or not ofc ;))
[08:33] <frankban> fwereade: sure, looking and qaing it
[08:38] <frankban> fwereade: does the comment at line 8-9 reflect reality?
[08:39] <fwereade> frankban, wait, yeah, I think that's crack
[08:39] <fwereade> wallyworld_, ^ -- what about instancepoller?
[08:40] <fwereade> wallyworld_, it doesn't workin the local provider but it should do everywhere else
[08:42] <voidspace> rebooting
[09:05] <frankban> fwereade: commented on the MP
[09:09] <vladk> dimitern: I have a problem with MAAS on VirtualBox
[09:09] <vladk> LXC from MAAS node can not get IP address from DHCP on MAAS cluster controller, because DHCP Request is sent w/o 'broadcast' flag and unicast DHCP Offer is not delivered inside of VirtualBox.
[09:09] <vladk> May be the problem related to VirtualBox, but I suggest to run DHCPD on MAAS with 'always-broadcast' option.
[09:09] <vladk> Does it make sense?
[09:10] <dimitern> vladk, I have very little knowledge of setting up dhcp internals and details - it seems you might be on a right track there
[09:11] <jam> vladk: #maas would be the place to bring it up, I think
[09:13] <vladk> dimitern: LXC container inside MAAS choose their MACs automatically and may even have different MACs on each lxc-start.
[09:13] <vladk> I offer to add some option to 'juju add-machine' to specify either MAC of LXC container or CIDR+GW.
[09:14] <fwereade> vladk, dimitern: I really don't want MAC addresses leaking into the UI, but I'm just fine with uspicking one and sticking to it
[09:14] <fwereade> s/uspicking/us picking/
[09:18] <vladk> dimitern, but in this case it will be impossible to have a predictable external IP address bound to LXC
[09:24] <mattyw> fwereade, rogpeppe quick question for one of you (sorry if I'm repeating - I got disconnected soon after asking the first time so I don't think I got through)...
[09:24] <thumper> rogpeppe: got time for a hangout? I need help
[09:25] <mattyw> I've started a branch for getting the current user set as the service owner when juju deploy is called. The wip mp is here: https://codereview.appspot.com/83060049/. I've added a test: https://codereview.appspot.com/83060049/patch/1/10004 but what I should do in the test is actually change the current user (as defined in the .jenv file) but I couldn't work out how to do it
[09:25] <rogpeppe> thumper: sure
[09:25] <thumper> rogpeppe: thanks https://plus.google.com/hangouts/_/7acpj31hohv230rlfvf7d3jqec?hl=en
[09:25] <rogpeppe> mattyw: are you around for a while?
[09:25] <mattyw> rogpeppe, I am yes - no hurry
[09:26] <rogpeppe> mattyw: cool, will answer after talking with thumper
[09:27] <fwereade> mattyw, I don't think that owner should be in the args over the API -- it's implicit in the connection
[09:28] <mattyw> fwereade, I guessed that would be the case but I couldn't see it
[09:28] <fwereade> mattyw, I think you just need to get the current tag off the auth object and pass that through
[09:28] <mattyw> infact - idiot - of course it is
[09:28] <mattyw> will do
[09:28] <fwereade> mattyw, it may not currently be exposed but it's definitely there
[09:28] <fwereade> mattyw, cheers
[09:28] <mattyw> sorry - should have seen that
[09:28] <mattyw> and how should I switch the current env in the tests?
[09:29] <fwereade> mattyw, that should then leave cmd/juju and state/api untouched, I think
[09:29] <fwereade> mattyw, so long as the apiserver tests check that it works with a different connected user, I don't think yu need to touch those other packages at all
[09:30] <mattyw> ok
[09:34] <axw> fwereade: we can haz HA azure now - all merged
[09:35] <fwereade> axw, w00t!
[09:35] <vladk> dimitern: is any way in MAAS api to understand what MAC address is of PRIMARY interface. you may suggest the first one, but if I remove and recreate the first MAC, it become the last one
[09:35]  * axw tests that it works once more to be sure
[09:38] <fwereade> axw, much appreciated :)
[09:39] <jam> fwereade: can I have an ear for a sec?
[09:39]  * fwereade listens
[09:39] <jam> fwereade: arm vs armhf
[09:39] <jam> the tool building process is generating simplestreams with armhf and tarballs with armhf in them
[09:39] <jam> but AFAICT the binaries inside them have "arm"
[09:39] <fwereade> jam, yeah, I pinged davecheney, I don't understand his objection to calling it armhf inside juju
[09:40] <jam> fwereade: all *I* care about is that they are consistent, and I feel it is easier to fix juju-core at this stage than fixing stuff outside of juju-core
[09:40] <jam> if only because we have a patch :)
[09:40] <fwereade> jam, and (from my perspective at least) it's a hell of a lot easier to fix juju than to fix the tool-building
[09:40] <fwereade> jam, yeah
[09:40] <fwereade> jam great minds ;)
[09:41] <fwereade> davechen1y, davecheney: ping again?
[09:45] <axw> uh oh, spaghetti oh. I broke something
[09:48] <fwereade> axw, change your name to max power and try again
[09:48] <wwitzel3> lol
[09:50] <davechen1y> fwereade: ack
[09:52] <dimitern> vladk, maas doesn't enforce ordering of macs - what you enter is what you can use to link to networks
[09:54] <jam> fwereade: I'm thinking we need james' patch to land on the 1.18 branch as well, right?
[09:54] <jam> frankban: I believe LXC has an empty scope because we can't tell whether it is public or private.
[09:55] <jam> It is just the address we got from eth0
[09:55] <jam> on Clouds that is actually a private address
[09:55] <jam> for LXC it is probably the "most public address we can get"
[09:55] <jam> though still since it is on LXCBR0 it is probably a private address.
[09:56] <mgz> there's no real public at all for the local provider, and lxc on other clouds will give you a machine-local address from that
[09:56] <frankban> jam: yeah, I am just concerned about client logic. From the client perspective, an internal eth0 address of an LXC in a local env could be also be considered "public", meaning reachable.
[09:56] <jam> mgz: well for MaaS it is a public-ish address, but for where we end up with EC2 it would be private.
[09:57] <mgz> right, maas is special
[09:57] <jam> frankban: so I'm pretty sure it means "we need to do more coding to parameterize this on where the LXC is running"
[09:57] <jam> which is... Is it worth it for now?
[09:57] <frankban> jam: I just want to make sure the logic I described in the bug is what must be implemented by clients
[09:57] <fwereade> davechen1y, what's the objection to calling it armhf inside juju? it feels like the cleanest way to get consistency
[09:58] <wallyworld_> fwereade: sorry, was at soccer, missed your ping
[09:58] <fwereade> wallyworld_, I forget what it was about now ;p
[09:58] <wallyworld_> goo :-)
[09:58] <wallyworld_> good
[09:58] <fwereade> wallyworld_, oh, yeah, instancepoller
[09:59] <fwereade> sorry brb
[09:59] <jam> wallyworld_: so there is a bug that frankban noticed, and the question about what to do with "unknown" networks.
[10:00] <jam> (appending to a list that we preseed with length)
[10:00] <jam> trivially fixed with "addresses = ... 0, len(merged))"
[10:00] <axw> fwereade: quick one when you have a moment https://codereview.appspot.com/83940043
[10:00] <wallyworld_> fwereade: ok, i'll look. btu all i'm doing is exposing the exisitng address getters on unit
[10:00] <jam> mgz: I think frankban's logic for "use the first public address, otherwise fall back to the first unknown address" is the logic we're going to have to go with for now.
[10:00] <jam> it will still be wrong in the ec2 case
[10:00] <wallyworld_> so if they're wrong then it's also wrong elsewhere
[10:01] <jam> but hopefully by then we can do the "oh private address X maps back to public address Y" and shove that in the information for the container
[10:01] <jam> which means the logic will still be correct.
[10:01] <jam> wallyworld_: the other code didn't do "make"
[10:01] <dimitern> fwereade, jam, rogpeppe, meeting?
[10:01] <axw> fwereade: integration testing fail - actually works with this change
[10:01] <frankban> jam: why  is it wrong in the ec2 case?
[10:01] <jam> it just started with the nil slice and appended to it.
[10:02] <jam> frankban: because if you have an LXC on EC2 it can *only* ever see its machine private addres.
[10:02] <jam> you have to go back to the provider
[10:02] <jam> and lookup "what is the actual public address assigned to the outer machine that matches the private address inside the LXC"
[10:02] <wallyworld_> jam: i needed to return an empty slice rather than a nil slice cause that's what the mega watchr wants
[10:02] <jam> wallyworld_: that is fine, the problem is that you do "make([]foo, len(merged)" and then append
[10:02] <jam> just change that to
[10:03] <jam> make([]foo, 0, len(merged))
[10:03] <jam> I have to switch machines,
[10:03] <wallyworld_> oh ok
[10:04] <frankban> jam: so, is it ok to use the logic I described in the bug (public + fallback)?  Do you think that work for all providers?
[10:06] <jam1> frankban: that works as well as we can do right now
[10:06] <jam1> when we fix EC2 to know about how to do that mapping, we can put a public address for those LXC containers
[10:07] <jam1> and have it continue to work
[10:08] <frankban> jam1: ok, so, when that branch lands, we can go ahead with quickstart and the GUI, using that logic to retrieve the reachable address
[10:08] <frankban> jam1: sounds ok?
[10:08] <jam1> frankban: sgtm
[10:16] <fwereade> hazmat, do you have the paste that davecheney linked with the casts in the watcher code?
[10:16] <hazmat> fwereade, i don't..   i  have the tracebacks..
[10:17] <fwereade> hazmat, sorry, it was that to which I referred
[10:18] <hazmat> fwereade, here's the watcher one.. http://pastebin.ubuntu.com/7198067/
[10:18] <hazmat> i'll forward the rest via emial
[10:33] <perrito666> good thing I am not joining near a major release.. ah, wait :|
[10:33] <perrito666> :p
[11:06] <stokachu> thumper: yea saucy works with kvm
[11:14] <jam1> fwereade: I looked at https://codereview.appspot.com/81110043/ (manifestDeployer)
[11:15] <jam1> it seems ok, though the SetAbortWait is confusing for me.
[11:16] <fwereade> jam1, I tried to make it clear, but clearly failed
[11:16] <jam1> fwereade: well, I sort of understand what it is doing, but it took a bit because the function has side effects *and* returns an object.
[11:16] <jam1> It also wasn't clear why we needed it.
[11:17] <jam1> fwereade: is that just part of the interface?
[11:17] <jam1> it seems like without the wait form, the other function can't return at all.
[11:17] <jam1> ah, it just always ignored abort before
[11:18] <fwereade> jam1, it's really just a way of checking that the abort chan is passed through to the bundle reader
[11:18] <fwereade> jam1, better ways of doing it greatly appreciated :)
[11:18] <jam1> fwereade: sure, I actually see the side effect, but it isn't very straight forward
[11:18] <jam1> so *if* you called SetWaitAbort
[11:18] <jam1> then we will wait on <-abort
[11:18] <fwereade> jam1, because it certainly felt unhelpfully convoluted to me
[11:18] <jam1> otherwise we just always fall through with the <br.waitAbort because it is a closed channel
[11:19] <fwereade> jam, yeah, exactly
[11:19] <jam1> doing the "create one and close it" looks strange.
[11:19] <jam1> I'll propose something
[11:19] <fwereade> jam1, cool, thanks
[11:26] <voidspace> rogpeppe: you there? the hangout is awfully quiet :-)
[11:26] <jam1> fwereade: suggestion sent
[11:26] <jam1> you certainly don't have to pick it up, and it is more verbose
[11:26] <jam1> but I feel it is a bit easier to read
[11:26] <jam1> voidspace: I'm sorry, you're not allowed to go on vacation, ever.
[11:26] <voidspace> jam1: ah, ok - that must be a new policy...
[11:27] <jam1> voidspace: certainly not to something so seedy as a place to Con people with Pie
[11:27] <voidspace> jam1: what about if I promise to proselatyse Juju?
[11:27] <voidspace> (forgive the spelling)
[11:27] <natefinch> If I'm going to be conned, I hope I get pie
[11:27] <jam1> voidspace: approved!
[11:27] <voidspace> jam1: thanks :-)
[11:27]  * natefinch brings fork to pycon, is disappointed.
[11:28] <voidspace> natefinch: silly man :-)
[11:28] <jam1> natefinch: should have brought a spork
[11:28] <jam1> fwereade: is there actually anything blocking https://code.launchpad.net/~fwereade/juju-core/filetesting-package/+merge/212811 other than rogpeppe didn't actually give it an LGTM ?
[11:29] <jam1> it looks like you did all of his suggestions.
[11:29] <voidspace> so yesterday, whilst attempting to print, I discovered that Ubuntu has a keyboard shortcut for "change my resolution, futz with my screen layout and disable the mouse"
[11:29] <voidspace> *really* useful
[11:29] <rogpeppe> ah, i had a couple of draft comments
[11:29] <voidspace> all you have to do is press <Super-P> instead of <Ctrl-P>
[11:31] <wwitzel3> there will be enough juju people at pycon that we could do an openspace
[11:31] <wwitzel3> though the last thing I need is one more thing to coordinate
[11:31] <jam1> voidspace: mess-with-displays enough that Pidgin can't find its window anymore :)
[11:32] <wwitzel3> maybe tvansteenburgh will do it :)
[11:32] <jam1> voidspace: apparently it is "detect displays" which changes it from separate to mirrored
[11:32] <jam1> so if you have different sized screens (as I do) it gets messed up
[11:32] <voidspace> nice
[11:32] <jam1> it also messes up the "my second screen is on the left"
[11:32] <jam1> settings
[11:32] <jam1> http://askubuntu.com/questions/20113/how-to-stop-mod4-p-from-switching-the-display and http://askubuntu.com/questions/68463/how-to-disable-global-super-p-shortcut
[11:32] <jam1> voidspace: you're not the only one that dislikes it
[11:32] <voidspace> yeah, apparently it's a *feature*
[11:33] <voidspace> I'm actually impressed with trusty multi monitor support in general though
[11:33] <jam1> I'm guessing this is "I connected to a Projector, help!"
[11:33] <natefinch> wow, yeah, that's terrible
[11:33] <voidspace> "just works" (mostly)
[11:33] <natefinch> it would be fine if it just toggled from mirror display to <whatever I had set before>
[11:33] <jam1> so having a command sequence to switch to Mirrored displays isn't that uncommon
[11:33] <jam1> it used to always be a Fn key on laptops
[11:34] <natefinch> it's just forgetting what I had set up before
[11:34] <jam1> natefinch: yeah, not remembering the previous setting is a bit bad.
[11:34] <jam1> natefinch: I take it you tried it as well
[11:34] <jam1> It remembered I only wanted 1 task bar
[11:34] <jam1> but it swapped my displays left to right again
[11:34] <natefinch> someone says "hey I did this and it messed everything up" and I have to try it.  Masochistic I guess
[11:34] <jam1> and made my right-hand screen the primary
[11:34] <wwitzel3> natefinch: lol
[11:35] <jam1> natefinch: something about the fuck-up made it so 3 of my windows so far are just *gone*
[11:35] <jam1> I'm guessing they ended up in massively negative offsets
[11:35] <natefinch> the only major thing I see wrong is that my laptop thinks it's on the left of my other two screens rather than the right. but maybe that's just because my settings were already close to what it just resets them to
[11:35] <jam1> but I can't grab them to move them back on the screen
[11:35] <wwitzel3> it seems like every other display setting change results in a Keep/Revert dialog. super-p should do the same
[11:35] <natefinch> jam1: that happens to me all the time for no apparent reason
[11:36] <jam1> on Windows you could meta-something to get the menu drop down and select move and then arrow key them
[11:36] <natefinch> jam1: hah, yeah, I am well versed in that manuever
[11:36] <voidspace> :-)
[11:36] <voidspace> sorry guys
[11:36] <natefinch> right-click, select move, tap an arrow key, then it sticks to the mouse so you can move it on screen.
[11:36] <natefinch> obvious, really
[11:37] <jam1> natefinch: If I Alt+Tab Unity shows me that it still knows what the window looks like, but no indication that it knows where the fuck it is :)
[11:37] <jam1> natefinch: you can Meta key to get it as well
[11:37] <jam1> Meta, release, M
[11:38] <jam1> natefinch: and clicking on the dashboard shows that the windows are *really* far to the right of my right-hand screen
[11:38] <jam1> because they "swoosh" into center view
[11:38] <jam1> but still no way to move them :(
[11:38] <voidspace> fortunately when I did it the screen with the launcher was still visible so I could run the displays app to restore things
[11:38] <wwitzel3> jam1: Alt+F7 then the arrow keys after selecting them with Alt+Tab
[11:38] <natefinch> voidspace: not your fault jam and I are idiots :)
[11:39] <voidspace> natefinch: I'm very sorry, but I'm finding it hard not to laugh
[11:39] <natefinch> jam1: ubuntu just had a "serious error" when I went into the display settings to move my monitor back
[11:39] <jam1> wwitzel3: so Alt+F7 binds the mouse to move them
[11:39] <jam1> but they are so far off the screen I have to move it 2 times :)
[11:39] <wwitzel3> hah
[11:39] <jam1> natefinch: it works, but it doesn't have the "first move brings it back onto the screen"
[11:40] <jam1> that the Windows arrow did
[11:40] <jam1> wwitzel3: bringing the mouse to an edge causes the snap-to-edge which at least brings it back
[11:41] <wwitzel3> jam1: well, that's something at least :)
[11:41] <natefinch> jam1: thanks for the alt-f7 thing, that'll help the next time I mysteriously lose a window
[11:42] <natefinch> now if I could only get the workspace switching hotkeys to work
[11:42] <jam1> wwitzel3: and when you move it off the snap to, it remembers its original size
[11:42] <jam1> so it actually works pretty well
[11:42] <wwitzel3> oh, nice, yeah
[11:42] <jam1> natefinch: ctrl+alt+arrow doesn't work? (I didn't reenable it myself)
[11:43] <natefinch> jam1: nope.  No matter what I bind the action to, hitting that hotkey doesn't do anything
[11:44] <natefinch> jam1: all the workspacey hotkeys do nothing for me for some reason
[11:44] <jam1> natefinch: you know about the Enable Workspaces in Appearance, right?
[11:44] <natefinch> and yes I have workspaces enabled (and the button works to show the workspaces and stuff)
[11:44] <natefinch> :)
[11:45] <jam1> I tested it, and Ctrl+Alt+Arrows is working for me, sorry
[11:45]  * natefinch shrugs
[11:45] <natefinch> never had workspaces before, so I don't miss them, just feel like it could be useful for context switching
[11:46] <jam1> natefinch: on my laptop, I used it for "email on this wkspace, coding on another"
[11:46] <jam1> but with dual monitors, that is just right and left monitor
[11:46] <wwitzel3> yeah I tend to only use them when I am stuck on one monitor
[11:47] <wwitzel3> voidspace just has a monitor for each application, makes things simple
[11:47] <natefinch> yeah, definitely would be useful for when I'm stuck on one monitor... just might be nice to have work stuff on this workspace, and non-work stuff on another workspace, instead of playing terminal roulette
[11:48] <natefinch> terminal roulette sounds a lot more dire than it is
[11:49] <fwereade> jam, re filetesting, don't think so
[11:49] <jam1> natefinch: you shouldn't be doing non work stuff, clearly
[11:49] <wwitzel3> natefinch: depends on the command? .. I'm not above copying and pasting a sudo command from the internet
[11:50] <natefinch> lol
[11:50] <wwitzel3> in fact, just the other day I copy and pasted one that was wgetting and executing a shell script ...
[11:50] <voidspace> hah
[11:50] <wwitzel3> sure np, why not
[11:50] <jam1> fwereade: sure. if you *want* I can give it another review, but whatever seems the best way to get you unstuck
[11:50] <natefinch> wwitzel3: mostly it's "switch to terminal, damn, wrong history, switch to another terminal... what was I even doing here?  switch to another terminal... wait, maybe the first one was right"
[11:50] <wwitzel3> it was on my raspberrypi though, so not as bad as it sounds
[11:51] <jam1> natefinch: http://unix.stackexchange.com/questions/1288/preserve-bash-history-in-multiple-terminal-windows
[11:51] <jam1> shopt -s histappend
[11:51] <jam1> Its in my .bashrc
[11:52] <natefinch> I don't know that I Want that. I like separate histories... I don't want actions I do in one munging the history in another.... I like being able to switch to a terminal, hit up enter and redo the last thing it did (often go build or go test in the correct directory), while still being able to futz with stuff in another terminal
[11:53] <wwitzel3> yeah, I use that as well so that i have access to my history across all my tmux panes/windows
[11:53] <natefinch> It's just when I forget which was which that is the problem :)
[11:59] <jam> my big "which window" right now is that I started using gmail web interface instead of Thunderbird
[11:59] <jam> so now when I alt Tab  Ihave to figure out which of these 5 windows looks like a mail program
[11:59] <natefinch> haha yeah, that is a drawback.
[12:00] <jam> natefinch: I tried using the "Install this as an App" but that seems to start it in a non-standard browser, and it doesn't work very well
[12:00] <natefinch> natefinch: I was just going to suggest that.  It should still be chrome, just without the URL bar
[12:00] <natefinch> talking to myself evidently
[12:00] <wwitzel3> lol
[12:02] <natefinch> jam: works ok for me.  *shrug*  It is nice that it then gets the gmail icon (even if it is a grossly blown-up version of the favicon)
[12:03] <jam> well, I did it from Firefox
[12:03] <wwitzel3> natefinch: I use Chrome users, so the install as app thing gets a little wonky for me.
[12:04] <natefinch> jam: ahh, yeah, that's probably the problem.  I have no idea what firefox does.  Chrome works nicely though.  Maybe that's a fix, too, just run mail in chrome and everything else in firefox
[12:04] <natefinch> wwitzel3: ahh, yeah, I can see that being a problem
[12:04] <jam> natefinch: yeah, I was just trying that out
[12:05] <wallyworld_> fwereade: jam:  i tested juju-gui with my branch under review and it correctly shows the unit public ip addresses when using local provider
[12:11] <frankban> wallyworld_: yes, I tested it here too, the lxc addresses are correctly included both in the unit and machine info. FWIW I approved the branch
[12:12] <frankban> wallyworld_: thank you for working on that
[12:12] <wallyworld_> frankban: yeah,saw that thanks
[12:12] <wallyworld_> just wanted be sure sure i tested it before landing
[12:22]  * fwereade cheers at wallyworld_ and frankban
[12:22] <fwereade> jam, I'd absolutely accept another review, especially if it comes with an lgtm ;)
[12:28] <jam> natefinch: ah, now I remember. the webapp thing works, but then it acts like a mobile app, where double clicking zooms on various parts of the screen, and the font is clearly "rescaled" (changing the size of the window changes the size of the font, rather than rewrapping the elements)
[12:29] <jam> so it works ~ok at full screen, but still acts a bit different
[12:31] <natefinch> jam: weird.  chrome's is much better, just a separate browser window sans address bar with a different icon.  Otherwise works just like a normal browser window.
[12:31] <jam> natefinch: I'm pretty sure the web app thing is Trusty's webapp which is based on Chrome
[12:31] <jam> As the menu items for what will be prompted is in Chrome settings, and not Firefox's
[12:31] <natefinch> huh
[12:32] <jam> natefinch: the window title is "Ubuntu Web Browser"
[12:32] <natefinch> wacky
[12:34] <jam> natefinch: http://discourse.ubuntu.com/t/theres-a-ubuntu-browser-in-trusty/1594/7 "Ubuntu browser will be used for webapps"
[12:34] <jam> Oxide is a library that allows you to embed a Chromium-powered webview in QML applications.
[12:35] <natefinch> interesting
[12:36] <jam> natefinch: are you on Trusty?
[12:36] <vladk> dimitern, sorry for delay. I'm ready for hangout. I prepared a doc with my thoughts: https://docs.google.com/a/canonical.com/document/d/1Fq1JKyuN8PlAeXdt98DN8Wy-WRgrXg-cHmuCqIeO9g0/edit#
[12:36] <natefinch> jam: yep
[12:37] <jam> hm. anyway, it works better in Chrome and makes it easier to Alt Tab, good enough :)
[12:37] <natefinch> jam:  are you using tools-> create application shortcut, or something else?
[12:37] <natefinch> (in chrome)
[12:43] <dimitern> vladk, go ahead and join with mgz and perrito666, i'll come shortly
[12:44]  * perrito666 feels summoned
[12:44] <dimitern> perrito666, :) vladk wanted to have a quick chat about what he discovered for maas+vlans
[12:45] <mgz> dimitern: where at?
[12:45] <perrito666> ah cool, hold until I make the magic "go to the computer where hangout works" dance :p
[12:45] <perrito666> our usual channel?
[12:46] <vladk> perrito666: it's busy
[12:46] <dimitern> vladk, will you create a hangout and send links to me, mgz and perrito666 please?
[12:48] <vladk> https://plus.google.com/hangouts/_/76cpim0b0s5qihkhpi9vh8qlso
[12:48] <vladk> perrito666, dimitern, mgz: https://plus.google.com/hangouts/_/76cpim0b0s5qihkhpi9vh8qlso
[12:49] <voidspace> lunch
[12:49]  * voidspace lurches
[12:49] <mgz> can one of you invite my g+ account to that, there's an option in the tools to the right
[12:49] <mgz> *left
[12:50] <perrito666> mgz: I just had to mail me the link :p
[12:51] <perrito666> vladk: dimitern says I dont have access to that videocall
[12:51] <perrito666> (It says it in spanish, but error in english must be pretty much the same"
[12:52] <dimitern> perrito666, mgz, I invited you both
[12:52] <mgz> dimitern: ta
[12:52] <jam> mgz, dimitern: can one of you give a quick summary of where you guys are at?
[12:52] <mgz> jam: overall, or right now?
[12:53] <jam> mgz: just a "this is what we've gotten up to and what we're on next". the same summary that you'd give at a regular standup
[12:54] <mgz> horacio is doing error report on --to with incompatible networks
[12:54] <mgz> I'm going to start on add-machine --network  params
[12:55] <mgz> dimitern is doing the cloudinit vlan bits
[12:55] <dimitern> jam, i'm finishing off state changes to add networks and NICs for machines
[12:55] <perrito666> jam: I am doing what mgz said and also trying to tie up the restore issue (finally it actually was caused by a too good connection to the server)
[12:56] <jam> perrito666: technically caused by a race condition :)
[12:56] <perrito666> jam: yes :) just very hard/impossible to reproduce in south america
[12:57] <perrito666> so I am replicating my env in an aws machine so I can find the race condition
[13:07] <bodie_> morning all
[13:17] <rogpeppe> bodie_: hiya
[13:25] <rogpeppe> ha ha ha! that's quite funny. i was wondering why my singular worker logic wasn't working, expecting all kinds of mongo weirdities, but instead just found that i wasn't actually *using* the singular worker wrapper at all
[13:26] <bodie_> I try to live by this adage: "It's always a layer 0 problem"...
[13:26] <rogpeppe> bodie_: except when it isn't...
[13:26] <bodie_> right, ha!
[13:27] <bodie_> just, i always find myself spending hours trying to work out something that just doesn't seem right, and then something's literally wired wrong, or i'm being dumb in some way
[13:27] <bodie_> on that note
[13:27] <rogpeppe> bodie_: yeah, assumption is the mother of all fuck ups
[13:27] <bodie_> I'm trying to understand what Command's SetFlags method is exactly for
[13:28] <rogpeppe> bodie_: it's so that common flags can be added without the command knowing about it
[13:28] <bodie_> I see that it's defined in cmd/environmentcommand.go and then each command adds to it
[13:28] <bodie_> ok
[13:28] <rogpeppe> bodie_: with the flag parsing logic defined outside of each command
[13:31] <dimitern> perrito666, http://paste.ubuntu.com/7198669/
[13:31] <perrito666> dimitern: tx
[13:33] <bodie_> oh, actual environment variables, rogpeppe?
[13:33] <rogpeppe> bodie_: no, command-line arguments
[13:33] <bodie_> ok, that's what I thought...
[13:35] <rogpeppe> bodie_: our documentation on cmd.Command should really be better, but it is at least a start
[13:35] <bodie_> okay, I think that's what I was looking for but not finding
[13:46] <wwitzel3> natefinch: ping
[14:00] <rogpeppe> wwitzel3: i haven't seen anything so far
[14:01] <wwitzel3> rogpeppe: http://paste.ubuntu.com/7198781/
[14:09] <natefinch> wwitzel3: here now
[14:09] <wwitzel3> natefinch: hey, rogpeppe helped me out :)
[14:09] <natefinch> sweet
[14:19] <sinzui> jam, fwereade Can I retartget bug 1301663 to 1.19.0.
[14:19] <_mup_> Bug #1301663: cmd/juju: panic during bootstrap <juju-core:Triaged> <https://launchpad.net/bugs/1301663>
[14:20] <mattyw> rogpeppe, ping?
[14:20] <rogpeppe> mattyw: ah, you're right to ping me, sorry
[14:20] <mattyw> (shouldn't take long)
[14:20] <mattyw> am I?
[14:20] <mattyw> can you see into the future or something?
[14:21] <mattyw> I want to get at the current user for a state - which I believe is st.info.Tag
[14:21] <fwereade> sinzui, yes, let's
[14:22] <mattyw> there doesn't seem to be a way of getting it out of state - can/should I write a GetTag which does return st.info.Tag?
[14:22] <rogpeppe> mattyw: well, you asked me a question earlier & i said i'd get back to you...
[14:22] <hazmat> the azure stuff.. that implies/means the provisioner knows the workloads its deploying now when allocating machines as well?
[14:22] <mattyw> rogpeppe, ah yes - I forgot
[14:23] <fwereade> mattyw, rogpeppe: can't we get it off the auth object?
[14:23] <fwereade> mattyw, rogpeppe: we might need to add a method to expose it, but it should be right there in the api
[14:23] <rogpeppe> mattyw: which state are we talking about here?
[14:23] <fwereade> mattyw, rogpeppe: I don't think we should be thinking about the user for a *state* at all
[14:24] <rogpeppe> fwereade: +1
[14:24] <rogpeppe> fwereade: unless we're talking about api.State
[14:24] <rogpeppe> mattyw: you can get it from st.auth.Tag()
[14:25] <rogpeppe> mattyw: and possibly st.auth.AuthEntity.(*state.User), if it must be a user
[14:25] <rogpeppe> mattyw: actually, i probably mean st.auth.AuthEntity().Tag() and st.auth.AuthEntity().(*state.User)
[14:26] <rogpeppe> mattyw: although i still haven't actually looked at the code, so that's probably wrong too
[14:26] <rogpeppe> :-)
[14:26] <mattyw> rogpeppe, are we talking about state from apiclient?
[14:26] <rogpeppe> mattyw: no
[14:27] <rogpeppe> mattyw: i'm not sure what code you're wanting to test here...
[14:27] <jam> sinzui: looks like just-a-bug to me, so not critical for 1.18
[14:27] <fwereade> mattyw, rogpeppe: it's setting the user that creates a service
[14:28] <sinzui> thank you jame and fwereade
[14:28] <rogpeppe> mattyw: could you explain in a bit more detail what you're trying to do, please?
[14:29] <mattyw> rogpeppe, sure - quick hangout?
[14:29] <rogpeppe> mattyw: sure
[14:29] <sinzui> jam, fwereade I will propose the version change to 1.18.0 in the next hour. When bug 1285410 is fixed and tested by CI, I will start the release.
[14:29] <_mup_> Bug #1285410: juju names arm arch 'arm' internally, but 'armhf' in tools <armhf> <armhf-hwe> <constraints> <server-hwe> <juju-core:In Progress by jason-hobbs> <juju-core 1.18:In Progress by jameinel> <https://launchpad.net/bugs/1285410>
[14:30] <fwereade> sinzui, awesome... but, jam, didn't we have a bunch of failures in the patch for that?
[14:30] <fwereade> jam, or did you fix them already? :)
[14:32] <jam> sinzui: fwereade: yes, there were test failures from jhobbs's patch
[14:32] <jam> I did not get a chance to fix them
[14:32] <jam> I backported his patch, but since we have failures, I can't land it.
[14:32] <jam> hopefully jhobbs will be on soon to address them
[14:32] <sinzui> thank you jam
[14:50] <wwitzel3> rogpeppe: http://bazaar.launchpad.net/~wwitzel3/juju-core/030-saveapiaddresses/revision/2523
[14:59] <sinzui> natefinch, wwitzel3 Do you have a minute to review https://codereview.appspot.com/84090043
[15:06] <natefinch> sinzui: LGTM (and wwitzel3 - I was too slow)
[15:07] <wwitzel3> natefinch: after discussing with rogpeppe some more, we can propose 030 as is. The new code itself is asserted by the TestMachineAgentRunsAPIAddressUpdaterWorker test.
[15:08] <natefinch> wwitzel3: ok
[15:14] <dimitern> fwereade, mgz, perrito666, I'd appreciate a review on the state networking model changes for machines: https://codereview.appspot.com/83070047
[15:14]  * fwereade looks
[15:16] <fwereade> dimitern, surely the exclude bit of LinkedNetworks is meaningless?
[15:17] <fwereade> dimitern, oh ok, LinkedNetworks is the requested, not the actual?
[15:18] <fwereade> dimitern, that would make sense with include/exclude, but the name feels a bit odd
[15:24] <mattyw> fwereade, rogpeppe if one of you could take a look at this I'd appreciate it https://codereview.appspot.com/83060049
[15:26] <dimitern> fwereade, yeah, LinkedNetworks comes from the service
[15:26] <natefinch> wwitzel3: is there anything I need to pull from your branch?
[15:26] <dimitern> fwereade, i chose that because the collection name is "linkednetworks"
[15:46] <wwitzel3> natefinch: no, I reverted everthing I did :/
[15:46] <wwitzel3> natefinch: so there is absolutely nothing to show for my effort
[15:46] <wwitzel3> natefinch: to fair what I did just eneded up being a duplicate of what Andrew already did
[15:46] <wwitzel3> natefinch: I just noticed it too late
[15:47] <natefinch> rogpeppe: do we need to merge anything into my version of the branch for the config changes?
[16:03] <natefinch> voidspace: is your config stuff landed on trunk?
[16:20] <voidspace> natefinch: yes
[16:21] <natefinch> voidspace: cool
[16:26] <natefinch> bzr merge lp:juju-core ..... 12 conflicts encountered.    *sigh*
[16:28] <rogpeppe> natefinch: trunk has everything you need to merge...
[16:28] <natefinch> rogpeppe: yeah, doing that now..... where did agent/agent.go  go?
[16:28] <rogpeppe> natefinch: i can work with you to resolve the conflicts if you like - i think i know what kinds of thing need to be done
[16:28] <rogpeppe> natefinch: agent/agent.go is still there AFAIK
[16:29] <natefinch> rogpeppe: weird, yeah, I retried the conflict and it showed up.... bzr bug or something
[16:30] <voidspace> rogpeppe: for Conn.Ping (for singular workers to ping the master) where should I get the address
[16:30] <natefinch> rogpeppe: actually the conflicts are pretty easy... most of them seem to be for me to just take what's on trunk
[16:30] <voidspace> rogpeppe: I notice that State (which has the IsMaster call) has a private addr
[16:30] <voidspace> rogpeppe: "addr is the address used to connect to the API server."
[16:31] <rogpeppe> voidspace: i don't think you need an address for the Ping
[16:31] <voidspace> rogpeppe: doesn't it need to ping *somewhere*?
[16:31] <rogpeppe> natefinch: the main thing that you need to do is write out the data from the StateServingInfo into files for mongo to use, rather than creating them in cloudinit
[16:31] <rogpeppe> natefinch: but perhaps you've done that already
[16:32] <rogpeppe> voidspace: it should call state.Session().Ping
[16:32] <voidspace> ah...
[16:32] <voidspace> rogpeppe: fair enough :-)
[16:33] <natefinch> rogpeppe: mostly.  I think it'll be obvious where we need to change things, since stateserving info is replacing some of the info we were using
[16:34] <natefinch> it's times like these when I thank the development gods for a good three way merge tool (in my case, Beyond Compare)
[16:36] <natefinch> hey! someone got labix.org in my stdlib includes!
[16:37] <natefinch> hm.... should we be grouping github.com/juju stuff with launchpad.net/juju-core stuff?
[16:39] <fwereade> natefinch, IMO github.com/juju is separate from github.com/juju/core (juju-core? I forget what we decided)
[16:41] <natefinch> fwereade: that seems logical, since there may be stuff under github.com/juju that isn't necesarily core stuff, whereas /juju/core definitely is core stuff.
[16:42]  * natefinch expels github.com/juju/loggo to the external packages section
[17:04] <rogpeppe> rebooting now. this machine is unusable
[17:13] <voidspace> natefinch: got a minute?
[17:13] <natefinch> voidspace: sure
[17:27] <voidspace> ok, folks
[17:27] <voidspace> G'night all
[17:27] <voidspace> EOD
[17:33] <sinzui> natefinch, or anyone with gobot and version knowledge. The lander hates my branch that updates the 1.18 branch to 1.18.0 https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053
[17:34] <natefinch> sinzui: looking
[17:35] <natefinch> sinzui: sorta looks like the tmp directory is messed up again
[17:37] <natefinch> sinzui: I don't actually know how to get onto the bot to poke at it... but usually it's the tmp directory filling up, and since there's a bunch of stuff in /tmp that seems to be missing, that would be my guess
[17:38] <sinzui> natefinch, thank you
[17:53] <rogpeppe> i've just upgraded my machine and it's now trashed
[17:54] <natefinch> trashed how?
[17:54] <rogpeppe> am currently using a terminal-emulation-based irc client
[17:54] <wwitzel3> rogpeppe: me too
[17:54] <rogpeppe> natefinch: no windows appear
[17:54] <wwitzel3> well not the trashed part
[17:54] <natefinch> windows are for the weak
[17:54] <rogpeppe> natefinch: i can't appear to do anything at all
[17:54] <wwitzel3> but I used a terminal client ;)
[17:54] <rogpeppe> i guess i can just go back to the vi dark ages
[17:55] <natefinch> heh
[17:55] <wwitzel3> have you tried Super+P ?
[17:55] <rogpeppe> but no web browser might be a bit of a problem
[17:55] <rogpeppe> ha ha bloody ha
[17:55] <rogpeppe> i get the top menu bar ok
[17:56] <natefinch> too good for lynx, rog?
[17:56] <wwitzel3> rogpeppe: can you get your dmesg and syslog pasted somewhere some how?
[17:56] <wwitzel3> .. maybe with curl to paste.ubuntu.com , the fields are poster, content, format
[17:57] <rogpeppe> with suspend/shutdown on the tool menu, calendar on the time menu, but i still see the Guest Session and Remote Login graphics on the screen, tho they don't react
[17:58] <rogpeppe>  /var/log/dmesg.log ?
[17:58] <wwitzel3> rogpeppe: yeah, that's good to see if any hardware failed to initalize
[17:59] <rogpeppe> wwitzel3: paste.ubuntu.com/7199828
[18:00] <rogpeppe> wwitzel3: paste.ubuntu.com/7199830
[18:01] <rogpeppe> wwitzel3: all the hardware *seems* like it's working ok
[18:01] <wwitzel3> rogpeppe: yeah, I don't see any of the obvious errors of failing to load a specific video module or anything of that nature that has caused me similar issues before
[18:02] <wwitzel3> rogpeppe: you could always try doing an update/upgrade from the command line and see if some new configuration files get written that fix your problem.
[18:02] <natefinch> honestly, when my machine blows up, I just reboot until it works again.... so far it hasn't failed me, though sometimes it has taken a couple reboots to get there
[18:02] <rogpeppe> the video seems to work ok
[18:02] <wwitzel3> like I say, when you have a problem, add more variables
[18:02] <rogpeppe> even the second monitor is working (kinda - it shows the terminal, duplicated)
[18:03] <wwitzel3> hrmm
[18:03] <rogpeppe> i will try rebooting a third time, i guess
[18:03] <wwitzel3> rogpeppe: unplug everything and reboot
[18:03] <rogpeppe> wwitzel3: if in doubt...
[18:03] <wwitzel3> rogpeppe: and then readd the devices after you're up
[18:03] <rogpeppe> wwitzel3: read the devices?
[18:04] <natefinch> re-add
[18:04] <rogpeppe> wwitzel3: i'm afraid my linux device-fu is fairly non-existent.
[18:04] <rogpeppe> wwitzel3: do you mean doing some mknods?
[18:05] <wwitzel3> rogpeppe: no no, I mean any physical things plugged in to your laptop .. USB, HDMI/DVI
[18:05] <wwitzel3> rogpeppe: reboot with just the laptop, that works for me sometimes when my display gets all wonky
[18:05] <rogpeppe> wwitzel3: ah, physical... usb + rgb out + headphones + wired ethernet
[18:06] <wwitzel3> rogpeppe: yep
[18:06] <rogpeppe> ok, i'll give it a go. see you the other side.
[18:08] <rogpeppe> wwitzel3: fail
[18:08] <rogpeppe> frick
[18:09] <natefinch> time to reinstall
[18:09] <rogpeppe> i wonder if "failed to spawn atd main process" is something to do with the problem
[18:11] <natefinch> rogpeppe: can you talk to IS?  It's sorta their job, right?
[18:12] <jhobbs> trying to run tests on lp:juju-core and I see this everytime http://paste.ubuntu.com/7199854/. any ideas what's going on?
[18:15] <natefinch> jhobbs: interesting
[18:17] <natefinch> jhobbs: oddly, it's a log line dereferencing some data the rest of the function doesn't even use
[18:19] <jhobbs> natefinch: the logger.debugf("started mongod... line ?
[18:20] <rogpeppe> i have no idea how to approach solving this problem
[18:20] <jhobbs> natefinch: if i comment that out it changes quite a bit but still fails: http://paste.ubuntu.com/7199919/
[18:22] <natefinch> jhobbs: that's the line.... that second panic is.... weird
[18:23] <jcastro> Can we get someone to reconsider priority on https://bugs.launchpad.net/juju-core/+bug/1233497
[18:29] <natefinch> jcastro: I'll bring it up with jam and fwereade.  It does seem like it would be good to fix, and probably not too too hard.
[18:30] <jhobbs> natefinch: blah, i just had to install mongodb-server
[18:30] <jhobbs> natefinch: thanks
[18:31] <natefinch> jhobbs: oh, huh.... well we should probably have a better error message than that
[18:31] <jhobbs> i agree :)
[18:32] <natefinch> ..... or you know, like any message at all would be nice
[18:58] <bac> hi bodie_, i'm trying to bootstrap a joyent env for the first time.  i'm using the latest 1.18 (r2257).  i'm getting this failure: http://paste.ubuntu.com/7199773/  -- any ideas?
[19:01] <ValDuare> hi guys - im on a manual provision setup here - I cant destroy-machine 2   just goes to life: dead
[19:01] <ValDuare> someone said try remove-machine 2   but no effect
[19:01] <ValDuare> is this a bug I should report
[19:01] <bodie_> bac: I'm pretty new here, and I've never worked with Joyent.  but it looks like you might have a malformed environment file.
[19:02] <bodie_> perhaps someone else has something to add.
[19:02] <natefinch> ValDuare: remove-machine and destroy-machine are the same thing, just aliases.  try destroy-machine 2 --force
[19:03] <fwereade> ValDuare, is the machine running or has it been shut down?
[19:03] <ValDuare> it is running
[19:04] <fwereade> ValDuare, hmm, can you pastebin /var/log/juju/machine-2.log from that machine?
[19:04] <ValDuare> ok
[19:05] <fwereade> bac, would you try removing (or just moving?) ~/.juju/environments/joyent.yaml and trying again? might not help, but might help to eliminate some possibilities
[19:06] <bac> fwereade: i have done that and get the same error
[19:06] <bac> fwereade: at first i thought my ssh key might be too long as i created a 4096 bit key.  re-did with a 2048 bit and got the same error.
[19:07] <fwereade> jcastro, will you still be on when thumper gets online? I think his debug-log work will eliminate that problem, but it might be good to check (and make sure he knows to mark it fixed)
[19:07] <jcastro> ack, I'll ambush him
[19:08] <ValDuare> http://pastebin.com/p7n9iFk0
[19:08] <fwereade> bac, I *think* that is complaining about the joyent keyfile, not the ssh key
[19:08] <bac> fwereade: i don't know what the joyent keyfile is
[19:09] <bac> is it not trying to create a bucket to put the upload-tools?
[19:11] <fwereade> ValDuare, so it *looks* like the machine agent should have stopped running -- is that correct?
[19:11] <ValDuare> yes juju status says it is
[19:11] <ValDuare> is stopped
[19:12] <ValDuare> agent-state: stopped
[19:12] <fwereade> ValDuare, if that's the case, you can safely destroy-machine --force -- but we'd really appreciate a bug report there, because I'm pretty sure it should also have told the API server to remove it
[19:12] <ValDuare> ok
[19:13] <fwereade> mgz, I don't suppose your joyent experience can be applied to bac's problem above?
[19:13] <ValDuare> juju destroy-machine 2 --force has no effect
[19:13] <fwereade> ValDuare, it might take a couple of seconds to do the cleanups, but if it's still around after say 10s there's something wrong
[19:14] <ValDuare> ok
[19:14] <bac> fwereade: i may have my 'algorithm' setting wrong.  it is an rsa key with DEK-Info: AES-128-CBC.  do you know how i should specify the algorithm for that setting?
[19:15] <ValDuare> still there after 10s
[19:16]  * fwereade is being called for supper with some impatience
[19:17]  * fwereade will bbiab
[19:17] <fwereade> ValDuare, a bug report with that log, and status output, would be awesome
[19:17] <ValDuare> ok
[19:19] <fwereade> bac, will you still be around in a couple of hours? wallyworld_ is your best hope for a quick solution there, I think
[19:20] <bac> fwereade: i will.
[19:20]  * fwereade really bbiab now
[19:57] <stokachu> is it worth creating a bug about destroy-environment requires <provider> even if only one is listed in the environments.yaml?
[19:58] <stokachu> for example, this is my environments file: http://paste.ubuntu.com/7200308/
[20:01] <natefinch> stokachu: I don't think the inconsistency is worth saving the typing
[20:02] <natefinch> stokachu: destroy environment is intentionally wordy because it is very destructive
[20:02] <stokachu> natefinch: cool thats what i kinda figured, glad i ran it by you first
[20:03] <natefinch> stokachu: it's ok, it was somewhat controversial... but if it saves one person from destroying their production environment by accident, it's probably worth it
[20:04] <stokachu> definitely
[20:21] <fwereade> natefinch, are you around for a bit? I need to get some sleep -- can I ask you to shepherd jhobbs' branch through to 1.18, or to hand over to someone in NZ?
[20:22] <natefinch> fwereade: I'm here, but only for another half hour or so.  But I'll do what I can and try to hand off
[20:22] <fwereade> natefinch, awesome, tyvm
[20:23]  * fwereade away
[20:25] <natefinch> jhobbs: what's going on?
[20:25] <jhobbs> natefinch: https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014
[20:26] <jhobbs> natefinch: everything is passing tests now, not sure what to do next
[20:29] <jhobbs> natefinch: sinzui is helping; i need to get a mp for 1.18
[20:29] <natefinch> jhobbs: do you have lbox?
[20:29] <jhobbs> lbox propose -cr --for=lp:juju-core/1.18
[20:29] <jhobbs> yeah
[20:29] <natefinch> right, yes, do that :)
[20:32] <thumper> jcastro: o/
[20:33] <jcastro> hey so debug-logs for local, would be really nice
[20:33] <natefinch> ...and so the lion, after patiently lying in wait for its prey, pounces.
[20:36] <jcastro> we're doing a bunch of local development lately and it's becoming really annoying to not have that
[20:36] <thumper> jcastro: yeah, on it
[20:37] <thumper> jcastro: so... anything else, or just complaining about missing features ;-)
[20:37] <sinzui> jcastro, I admire your talking technique, but it need improvement. I think dimitern was given the feature
[20:38] <thumper> sinzui: I'm working on debug-log
[20:38] <thumper> sinzui: dimitern is working on vlan
[20:39] <sinzui> thumper, do you have access to kick gobot? I think it is ill
[20:39] <jcastro> thumper, no I just wanted to say that before we didn't  think it was important, but lately we're noticing that it's more important to us than before
[20:39] <jcastro> sorry I am typing with one hand, on a call, but want to talk to thumper at the same time. :)
[20:39] <thumper> jcastro: ack
[20:39] <thumper> heh
[20:39] <thumper> sinzui: yeah...
[20:40] <jhobbs> natefinch: https://code.launchpad.net/~jason-hobbs/juju-core/1.18/+merge/214115
[20:40] <thumper> sinzui: I have a shell alias 'gobot' that ssh's to the machine
[20:40] <jhobbs> natefinch: it asked me to authenticate on google, i didn't know what to do there, so it failed to send the patch set to codereview
[20:40] <sinzui> thumper, https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053 is a trivial change, but the same tests fail
[20:41] <thumper> sinzui: hmm... v strange
[20:43] <natefinch> jhobbs: the easiest thing to do is use your regular google credentials (assuming you have them)  like your gmail credentials.  Sometimes canonical creds work, but often not
[20:43] <natefinch> jhobbs: do you have google credentials?
[20:43] <jhobbs> natefinch: yeah
[20:44] <jhobbs> natefinch: should i run that again then, with my google credentials?
[20:44] <natefinch> do you use 2 factor auth?  that complicates things - you'd need an application-specific password (that's what I have to do)
[20:44] <jhobbs> not on my private account
[20:44] <natefinch> ok, then yeah, just re run it and use your home account info
[20:44] <jhobbs> k cool
[20:45] <natefinch> the account you use doesn't really matter as long as we can tell it's you.  I used my home account because I couldn't get my canonical creds to work
[20:45] <jhobbs> yeah it should be pretty clear
[20:46] <jhobbs> first.last, email should be listed on launchpad too
[20:46] <natefinch> that's all mine is too
[20:47] <natefinch> it's not like you need to prove it's you, just like, if it was<EMAIL_ADDRESS>people might get confused
[20:47] <natefinch> sweet
[20:48] <thumper> sinzui: nfi why that is failing
[20:48] <jhobbs> guess you saw it, but https://codereview.appspot.com/84210043/
[20:48] <thumper> sinzui: sorry, perhaps wallyworld_ could help when he starts
[20:48] <sinzui> thank you thumper
[20:49] <natefinch> jhobbs: yeah, got the email
[20:51] <natefinch> jhobbs: ok, I gave it the LGTM, so now you go to the merge proposal on launchpad, add a commit message (copying the change description is fine) and then set the status to approved
[20:51] <natefinch> and the bot takes care of the rest
[20:52] <jhobbs> ok cool, i can't set it to approved though - not an option for me
[20:52] <jhobbs> ditto for the original MP for trunk
[20:53] <natefinch> huh weird, must be some permission issue.  I can do it
[20:53] <jhobbs> thanks
[20:53] <natefinch> welcome
[20:53] <jhobbs> can you mark the trunk one approved too please? https://code.launchpad.net/~jason-hobbs/juju-core/fix-armhf/+merge/212014
[20:54] <natefinch> done
[20:55] <jhobbs> awesome!
[20:55] <natefinch> unfortunately, there's no notification when your branch gets picked up by the bot, only when it finishes, so it can take a while, since it has to merge it into the branch and run the tests.  But there should be an email in 20-ish minutes saying if it worked or not (which it should, assuming the tests pass and there's no conflicts)
[20:55] <perrito666> sinzui: rest of the world, if you would be so kind to review this shamefully short patch https://codereview.appspot.com/82280045
[20:56] <jhobbs> natefinch: ok cool, i'll keep an eye out
[20:56] <natefinch> perrito666: LGTM'd
[20:57] <perrito666> tx natefinch
[21:00] <natefinch> EOD, night all
[21:00] <perrito666> natefinch: nites
[21:12] <sinzui> thumper, is no-proxy a string (not a yaml list)? eg no-proxy: localhost,<IP_ADDRESS>
[21:12] <ValDuare> https://bugs.launchpad.net/juju-core/+bug/1302132
[21:12] <_mup_> Bug #1302132: manual provisioning destroy-machine fails - stuck at life: dead <juju-core:New> <https://launchpad.net/bugs/1302132>
[21:12] <thumper> sinzui: correct, a string
[21:12] <sinzui> thumper, fab.  I am writing a doc for it
[21:12] <thumper> kk
[21:12] <thumper> thanks
[22:38] <sinzui> wallyworld, Do you have super powers to beat gobot into submission. It has rejected jhobbs and my branches repeatedly. My branch just changes the version to 1.18.0
[22:42] <davechen1y> morning juju
[22:42] <davechen1y> such that it is
[22:43] <perrito666> davechen1y: yay one of those mornings at 19:43 :p
[22:43] <davechen1y> perrito666: every day mate, every day
[22:43] <perrito666> does anyone knows of a setup for go that prints build errors in color?
[22:49]  * thumper rages at his own stupidity
[22:49]  * thumper leaves in disgust
[23:11] <davechen1y> waigani: morning
[23:11] <davechen1y> how's today looking ?
[23:35] <davechen1y> http://paste.ubuntu.com/7201087/
[23:36] <davechen1y> slowly getting there
[23:47] <davechen1y> hazmat: ping