[00:27] <davecheney> lucky(~) % juju status
[00:27] <davecheney> WARNING discarding API open error: <nil>
[00:27] <davecheney> wut ?
[00:35] <davecheney> wallyworld_: http://paste.ubuntu.com/6789000/
[00:35] <davecheney> i cannot bootstrap
[00:35] <davecheney> what is going on ?
[00:43] <thumper> ?!
[00:43] <thumper> davecheney: wallyworld_ is not back from lunch yet
[00:44] <thumper> davecheney: that is a shitty error
[00:44] <thumper> should file a bug about that
[00:51] <davecheney> looks like it's sending back a 404 error
[00:51] <davecheney> <hr /> smells of the apache 502 page
[00:51] <davecheney> or something
[00:51] <davecheney> what is the URL it tries to hit ?
[00:54] <davecheney> oh, hang on
[00:54] <davecheney> i didn't use --upload tools
[00:54] <thumper> haha
[00:54] <thumper> still a shitty error
[00:55] <davecheney> << PEBKAC
[00:56] <davecheney> Attempting to connect to ec2-54-253-211-44.ap-southeast-2.compute.amazonaws.com:22
[00:56] <davecheney> Attempting to connect to ip-10-249-43-61.ap-southeast-2.compute.internal:22
[00:56] <davecheney> Attempting to connect to 54.253.211.44:22
[00:56] <davecheney> ^uh, the second will *NEVER* work
[00:56] <davecheney> Attempting to connect to 10.249.43.61:22
[00:56] <davecheney> in fact, it could work
[00:56] <davecheney> but connect you to something totally unexpected
[00:58] <wallyworld_> davecheney: that xml error thing is fixed in trunk - there was some old s3 bucket code still lurking in the system
[01:00] <davecheney> cool
[01:02] <wallyworld_> thumper: when you are bored or need a change from swearing at your keyboard https://codereview.appspot.com/54740043/
[01:54] <axw> davecheney: bootstrap doesn't know which IP is the right one. it checks each one that the provider tells you about, and verifies the machine connected to is the one it started
[01:55] <axw> depending on the provider, and where you're bootstrapping from, you may indeed want the private IP
[01:55] <axw> (think bootstrapping canonistack from within canonistack)
[02:17] <davecheney> true, but 10/0 may not be remote on your network
[02:17] <davecheney> imagine what happened if a provider gave out 192.168/16 addresses
[02:17] <davecheney> that is used by most modems
[02:18] <davecheney> sorry, private networks
[02:21] <axw> davecheney: we verify the identity of the machine by confirming the nonce. so the random machine you get would (a) have to have your SSH public key in ~ubuntu/authorized_keys and (b) have the random nonce generated in a specific location
[02:21] <davecheney> sure, but if juju connets to the private address, say 10.x.x.x
[02:21] <davecheney> and it gets refused
[02:22] <davecheney> or more specifically, authn failed
[02:22] <davecheney> will it try the public address ?
[02:22] <axw> yes
[02:22] <axw> it tries them all in parallel
[02:23] <axw> it blows that we need to check them all, but it covers all scenarios with zero user intervention
[02:23] <davecheney> ok
[02:23] <davecheney> ok
[02:23] <davecheney> cool
[02:23] <davecheney> how is the land of hobbits ?
[02:24] <axw> :)  nice and cool
[02:24] <axw> better than the ~35 degrees back in Perth
[04:35] <davecheney> http://paste.ubuntu.com/6789743/
[04:35] <davecheney> ^ can anyone confirm this gocheck breakage ?
[05:44] <wallyworld_> waigani: https://pastebin.canonical.com/103270/
[05:45] <wallyworld_> waigani: https://pastebin.canonical.com/103271/
[08:32] <dimitern> rogpeppe, I have a bunch of reviews up, if you can take a look at some of them? https://codereview.appspot.com/54620043/ https://codereview.appspot.com/54630043/ https://codereview.appspot.com/54640043/https://codereview.appspot.com/54650043/
[08:33] <rogpeppe> dimitern: will do
[08:33] <dimitern> mgz, jam, others? ^^
[10:08] <dimitern> rogpeppe, review poke
[10:09] <rogpeppe> dimitern: sorry, i've been trying to get tests passing cleanly before starting on reviews. hopefully not much more now.
[10:10] <dimitern> rogpeppe, ok
[10:11] <eagles0513875> morning dimitern :)
[10:12] <dimitern> eagles0513875, morning man :)
[10:12] <eagles0513875> dimitern: :) good news btw on start up the environment i setup on the local provider also came up
[10:12] <eagles0513875> but im not sure if i should be worried about one thing
[10:12] <eagles0513875> dimitern: im seeing this when i do juju status instance-state: missing
[10:12] <dimitern> good news then
[10:13] <dimitern> hmm .. i'm not sure the local provider supports instance-state
[10:13] <dimitern> it's a cloud specific value that describes what state the vm is in (i.e. "building", "rebooting", "running")
[10:14] <dimitern> rogpeppe, and this is the last bit https://codereview.appspot.com/52550045/ (6/6)
[10:14] <eagles0513875> dimitern: i think it does this for the local provider as well
[10:16] <dimitern> eagles0513875, maybe it's a bug then - can you look for similar existing bugs and file one if none exists please?
[10:17] <eagles0513875> dimitern: i do know if i setup a new deployment it does show the pending etc
[10:17] <eagles0513875> but what i find interesting is that it doesnt seem to preserver or boot up any previous instances on the local provider after reboot
[10:18] <eagles0513875> fwereade: any idea about the above that im noticing?
[10:18] <jam> eagles0513875: you should be able to use "sudo lxc-ls --fancy" and see what instances have been set up on your machine
[10:19] <eagles0513875> let me try that
[10:19] <jam> eagles0513875: what series are you on ? (Precise, Saucy, T, etc) ?
[10:19] <jam> and then you can try "apt-cache madison lxc"
[10:19] <eagles0513875> ok well the laptop im testing out the local provider is 13.10
[10:19] <eagles0513875> the instances are precise
[10:20] <eagles0513875> ok the main bootstrapped environment is showing up and that is it
[10:20] <eagles0513875> let me pastebin
[10:20] <eagles0513875> http://paste.ubuntu.com/6790813/ jam dimitern
[10:21] <jam> eagles0513875: I don't think instance-state: missing means something is wrong, as dimitern mentioned, I'm pretty sure it is empty for local instances today
[10:22] <eagles0513875> isnt 1 an instance of something i might have had setup?
[10:22] <eagles0513875> i did have an instance of the juju-gui there yesterday
[10:22] <eagles0513875> which i probably forgot to destroy before shutting down
[10:26] <eagles0513875> how can you start an instance?
[10:32] <dimitern> eagles0513875, by deploying something or using add-machine
[10:32] <eagles0513875> dimitern: ok lets say the host power cycles for some reason
[10:32] <eagles0513875> how can you bring up the instances you would have had deployed there.
[10:33] <eagles0513875> thats what happened i shut down my laptop http://paste.ubuntu.com/6790874/ this paste is after a new boot strap so for sure I had something deployed
[10:33] <eagles0513875> i think this is one serious flaw potentially in juju unless things are handled differently then what im thinking
[10:35] <dimitern> eagles0513875, i'm not well versed with the local provider, but if you can wait until late in the evening, you might ask thumper, when he's around, or perhaps better, send a question on the juju-dev mailing list
[10:35] <eagles0513875> where do i subscribe :)
[10:36] <dimitern> https://lists.ubuntu.com/mailman/listinfo/juju-dev
[10:36] <eagles0513875> thank you :)
[10:36] <dimitern> np :)
[10:45] <jam> fwereade: mgz: standup ?
[10:46]  * fwereade stands up
[10:46] <eagles0513875> fwereade: :P you is in trouble :p
[10:47] <jam> mgz: poke?
[10:47] <eagles0513875> fwereade: i think i found a very interesting use case this morning after running a test with the local provider that could be a big flaw with juju as it stands right now or im just not aware of the features
[10:47]  * eagles0513875 pokes jam with a stick and it slides right through him/her
[10:54] <eagles0513875> dimitern: hope my thinking above isnt too outside the box
[10:54] <mgz> jam: wandered off, here now
[10:55] <eagles0513875> mgz: thats what happens when you leave jam out for too long lol it becomes a big sticky puddle :p
[10:57] <dimitern> eagles0513875, filing bugs or juju-dev discussions are most beneficial - for the record, etc.
[10:57]  * eagles0513875 goes into lurking mode.
[11:17] <dimitern> rogpeppe, updated https://codereview.appspot.com/54620043/ as suggested
[11:23] <rogpeppe> dimitern: the only config.Config field that is secret is admin-secret, and that's not required
[11:24] <rogpeppe> dimitern: putting "not available" in secret attributes just seems like asking for trouble
[11:42] <dimitern> rogpeppe, please confirm with fwereade about this behavior
[11:43] <fwereade> dimitern, rogpeppe, ehhhhhh just a mo
[11:43] <rogpeppe> fwereade: could you explain the reasoning behind filling out secret attributes with "not available" rather than deleting them?
[11:44] <fwereade> rogpeppe, the provisioner's all fucked up, and expects an environ config even if it's just a container provisioner
[11:45] <rogpeppe> fwereade: but what if the environ config expects an integer-valued secret attribute?
[11:45] <fwereade> rogpeppe, it doesn't
[11:45] <fwereade> rogpeppe, we changed the interface
[11:45] <fwereade> rogpeppe, strings only
[11:45] <rogpeppe> fwereade: the environment config can't contain anything except strings?
[11:45] <fwereade> rogpeppe, justthe secrets
[11:46] <rogpeppe> fwereade: ah. i didn't see that. where's it documented?
[11:46] <fwereade> rogpeppe, EnvironProvider.SecretAttrs
[11:47] <fwereade> rogpeppe, dimitern: it would ofc be best to unfuck the provisioner rather than further promoting that hack
[11:47] <rogpeppe> fwereade: and this is just to work around the provisioner bug
[11:47] <rogpeppe> ?
[11:47] <dimitern> fwereade, yes, hence the bug 1231384
[11:47] <_mup_> Bug #1231384: Provisioner API's EnvironConfig() shouldn't allow non-manager nodes to call it <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1231384>
[11:48] <fwereade> dimitern, rogpeppe: OMG NO WAI it looks like someone may have done that
[11:48]  * fwereade looks more closely
[11:49] <rogpeppe> fwereade: given that the bug is in the provisioner, i'd be much happier if the workaround-hack was in the provisioner too
[11:49] <dimitern> rogpeppe, it is in the provisioner api
[11:49] <rogpeppe> fwereade: rather than corrupting core interfaces for no good reason
[11:49] <rogpeppe> dimitern: the bug is in the provisioner agent code
[11:50] <rogpeppe> dimitern: which could easily add the required dummy secret attributes itself
[11:50] <dimitern> rogpeppe, yes, but without some less than trivial refactoring, it can't be fixed
[11:50] <fwereade> rogpeppe, dimitern: take a look at the provisioner, I don't think the container provisioner uses it any more
[11:50] <rogpeppe> dimitern: sure it can. but even better if the container provisioner doesn't do it
[11:51] <dimitern> fwereade, I can see it uses it on line 173 in provisioner.go
[11:51] <dimitern> fwereade, ah, that's just the env. provisioner
[11:51] <fwereade> dimitern, yeah
[11:51] <dimitern> fwereade, cool! so we can get rid of the masking and mark the bug fix committed
[11:52] <fwereade> dimitern, I think we can
[11:52] <fwereade> dimitern, test it live please though -- you have access to a MAAS, right?
[11:52] <dimitern> fwereade, i don't think i do
[11:52] <dimitern> fwereade, even if i do, i've never used it
[11:52] <dimitern> for live testing
[11:53] <dimitern> perhaps natefinch can help with that?
[11:54] <dimitern> fwereade, why maas exactly?
[11:55] <fwereade> dimitern, that has containers that work
[11:59] <dimitern> fwereade, so ec2/canonistack won't do?
[11:59] <fwereade> dimitern, I think probably not for verifying that container provisioners really really work properly
[12:00] <dimitern> fwereade, i'd appreciate any pointers on how to connect to maas and test it
[12:01] <fwereade> dimitern, yeah, I'm trying to find the email
[12:01] <dimitern> fwereade, I'll follow the wiki and ask on #is
[12:11] <dimitern> fwereade, it seems i'm not a member of any of the groups that have access to maas (iom-maas or qa-lab)
[12:19] <dimitern> fwereade, it seems I can't use the maas lab - it's booked for the next few weeks
[13:09] <TheMue> o/ <= I'm looking for help with API and authentication
[13:10] <dimitern> TheMue, hey, what do you need?
[13:10] <TheMue> my debug-log command get's a "permission denied"
[13:10] <dimitern> TheMue, that's the client api
[13:11] <dimitern> TheMue, run it with --show-log and --debug and paste the output?
[13:11] <TheMue> dimitern: I'm using juju.NewAPIClientFromName und client has a method for calling my facade
[13:11] <TheMue> dimitern: ok, will do
[13:11] <TheMue> dimitern: tia
[13:11] <dimitern> TheMue, pasting some code can also help to see what you're trying to do
[13:12] <TheMue> dimitern: will put it all together, just have to bootstrap
[13:13] <dimitern> TheMue, ta
[13:16] <dimitern> rogpeppe1, hey
[13:17] <rogpeppe1> dimitern: yo
[13:17] <dimitern> rogpeppe1, since live testing  on maas of whether bug 1231384 is fixed
[13:17] <rogpeppe1> dimitern: sorry, i've been afk for a while 'cos a friend came around
[13:17] <_mup_> Bug #1231384: Provisioner API's EnvironConfig() shouldn't allow non-manager nodes to call it <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1231384>
[13:17] <dimitern> rogpeppe1, let's live with it for now, so I can land the firewaller api
[13:18] <rogpeppe1> dimitern: are you saying that the bug isn't fixed?
[13:18] <dimitern> rogpeppe1, once it's available, I'll look into it and remove the code as suggested, after successful live testing
[13:18] <rogpeppe1> dimitern: or that you don't know?
[13:18] <dimitern> rogpeppe1, i can't confirm it won't work for real without the workaround
[13:19] <dimitern> s/won't/will/
[13:19] <rogpeppe1> dimitern: isn't it easy to test by live testing in ec2?
[13:20] <dimitern> rogpeppe1, ec2 does not use container provisioner apparently
[13:20] <dimitern> rogpeppe1, only maas does
[13:20] <rogpeppe1> dimitern: ah, of course.
[13:21] <rogpeppe1> dimitern: i suppose another way would be to run the container provisioner tests and check that the EnvironConfig API call is never made
[13:21] <dimitern> rogpeppe1, it doesn't beat live testing
[13:25] <TheMue> dimitern: log does not tell very much: http://paste.ubuntu.com/6791555/ , the implementation so far at https://codereview.appspot.com/44540043/ (the predecessor branch in review by fwereade)
[13:26] <rogpeppe1> dimitern: tbh i think a code inspection is good enough here. it's easy to verify that EnvironConfig is only called in an environProvisioner, and that NewEnvironProvisioner is only called if the machine has JobManageEnviron
[13:26] <rogpeppe1> dimitern: if that's not the case, it's not *too* bad.
[13:26] <rogpeppe1> dimitern: if it breaks trunk, just blame me :-)
[13:27] <dimitern> rogpeppe1, how about backwards compatibility?
[13:27] <dimitern> rogpeppe1, removing EnvironConfig() from the provisioner facade is a breaking change, and needs workarounds for 1.16
[13:29] <rogpeppe1> dimitern: that's a reasonable point.
[13:30] <dimitern> rogpeppe1, see - all the more reasons to dedicate a cl + time on it alone
[13:31] <rogpeppe1> dimitern: yeah - perhaps just put a comment saying "delete when 1.16 compatibility no longer required"
[13:31] <dimitern> rogpeppe1, sure
[13:59] <dimitern> rogpeppe1, updated https://codereview.appspot.com/54620043/ again - should be good to land now?
[13:59] <dimitern> TheMue, sorry, back to you
[14:00] <dimitern> TheMue, in DebugLogCommand.Init you need to call NewAPIClientFromName in Run(), not Init
[14:01] <dimitern> s/in Debug../looking at Debug../
[14:01] <dimitern> TheMue, see the other commands for examples
[14:03] <TheMue> dimitern: that's all? would be great. thx, I'll try
[14:03] <rogpeppe1> dimitern: LGTM
[14:03] <dimitern> TheMue, well, that bit is fishy, but might be something else
[14:03] <dimitern> rogpeppe1, ta!
[14:04] <dimitern> rogpeppe1, did you look at the others?
[14:04] <rogpeppe1> dimitern: am on them
[14:09] <TheMue> dimitern: the fishy one showed at least a first step of success http://paste.ubuntu.com/6791768/
[14:09] <TheMue> dimitern: but still no connection
[14:09] <TheMue> eh
[14:09] <TheMue> no permission
[14:11] <dimitern> TheMue, does any other command work?
[14:13] <dimitern> TheMue, I see the problem
[14:13] <dimitern> TheMue, https://codereview.appspot.com/44540043/diff/140001/state/apiserver/debugger/debugger.go - in NewDebuggerAPI you're checking for AuthEnvironManager
[14:13] <dimitern> TheMue, that's not how it should be for a client api (it's used for the agent api only)
[14:14] <TheMue> dimitern: ic
[14:14] <dimitern> TheMue, the whole facade is written as if it's an agent api facade
[14:15] <TheMue> dimitern: yeah, only tried to follow what I found ;) but seems I didn't got the intention behind it (client and agent)
[14:16] <dimitern> TheMue, look at apiserver/client/client.go - you need AuthClient() in the Debugger(id string) call
[14:18] <TheMue> dimitern: hmm, don't have AuthClient() there, only AuthClient() bool in apiserver/root.go
[14:20] <dimitern> TheMue, the root is an authorizer
[14:24] <TheMue> dimitern: the debugger API is intended to be used from the CLI and the UI. we call both "client" opposite to "agent" for the agents on the machines?
[14:29] <TheMue> dimitern: I've got my standup now, but your hints already showed the way
[14:29] <TheMue> dimitern: maybe I'll come back with more questions later
[14:29] <TheMue> dimitern: thx so far
[14:41] <dimitern> TheMue, np
[14:46] <rogpeppe1> dimitern: all reviewed, i think
[14:47] <dimitern> rogpeppe1, tyvm
[14:47] <dimitern> rogpeppe1, except the firewaller api itself?
[14:47] <rogpeppe1> dimitern: ah, which one is that?
[14:47] <dimitern> rogpeppe1, https://codereview.appspot.com/52550045/
[14:48] <rogpeppe1> dimitern: ah, you didn't mention that in the list you pasted this morning...
[14:48] <rogpeppe1> dimitern: looking
[14:48] <dimitern> rogpeppe1, that's the last one
[14:48] <dimitern> rogpeppe1, ta
[14:56] <rogpeppe1> dimitern: i've got a meeting in 5 minutes - don't think i'll have done it before then, i'm afraid
[14:57] <dimitern> rogpeppe1, it's ok - later perhaps?
[14:57] <rogpeppe1> dimitern: yes
[15:05] <TheMue> dimitern: step by step, calling the command seems to work now, but it looks I'm using the watcher wrong. do we have an example of using the watcher from the client side?
[15:06] <dimitern> TheMue, only the AllWatcher is used by the client api so far
[15:09] <TheMue> dimitern: ok, will look how it is done there
[15:52]  * fwereade away early, cath's birthday
[15:53] <mgz> have fun!
[16:05] <TheMue> fwereade: enjoy and congrats from me
[16:42] <gary_poster> sinzui: hi.  will 1.17.1 be made from trunk?  specifically, will it have the AddLocalCharm method http://bazaar.launchpad.net/~go-bot/juju-core/trunk/revision/2155 from dimiter?
[16:42] <sinzui> gary_poster, yes it will
[16:42] <gary_poster> awesome thanks sinzui
[16:52] <rogpeppe1> dimitern: reviewed
[16:52] <dimitern> rogpeppe1, thanks
[17:45] <jamespage> sinzui, will the 1.17.1 release include using juju-mongodb on trusty+ ?
[18:35] <sinzui> jamespage, It can. I can make that change  and start testing ittoday
[19:06] <jamespage> sinzui, please
[19:07] <sinzui> jamespage, ack
[19:09] <natefinch> interesting, if I leave saturday night for London, I can get a direct flight for $500 less than a 1 stop flight leaving sunday morning at 5am.  Seems like a no brainer.
[19:09] <natefinch> man, flight prices are wacky
[19:15] <rogpeppe1> natefinch, fwereade, mgz: review anyone? https://codereview.appspot.com/55150043
[19:15] <rogpeppe1> EnsureAvailability finally :-)
[19:18] <natefinch> rogpeppe1: nice!  I'll check it out.
[19:18] <rogpeppe1> natefinch: thanks!
[19:55] <wallyworld> fwereade: you around?
[21:48] <lazypower> Does a variable exist indicating which node is the dying node? eg unit['status'] = dying?
[22:03] <axw> waigani: https://juju.ubuntu.com/docs/tools-charm-tools.html
[22:23] <dpb1> any trick to get relation-get --help text?  I get env variables not defined,  when I try to run it.
[22:32] <fwereade> wallyworld, hey, I need to be a bit brief, but I *am* herefor now
[22:33] <wallyworld> fwereade: we were only looking to see if you wanted to join in azure or upgrade discussion
[22:34] <wallyworld> up to you. but we do need to start talking even if you are not available. we were going to talk about azure this afternoon since you were not around earlier
[22:35] <fwereade> wallyworld, I don't think I've really got time for a deep discussion, I'm afraid :(
[22:35] <wallyworld> np. we were pinging you cause you asked us to :-)
[22:35] <fwereade> wallyworld, re azure my gut wants to jam availability sets in as placement directives, but I'mnot sure if we can make that fly
[22:36] <fwereade> wallyworld, and I'd really appreciate an update of what you all discussed when you've discussed it
[22:36] <wallyworld> i think it needs to support auto generated as well / instead of
[22:36] <fwereade> wallyworld, yeah
[22:36] <wallyworld> ie each service is placed in it's own availability set
[22:36] <fwereade> wallyworld, that's fine until we want density
[22:37] <wallyworld> we can tweak it once density is considered
[22:37] <fwereade> wallyworld, and don't forget HA, juju itself needs one
[22:37] <wallyworld> have a config for auto
[22:37] <wallyworld> yeah
[22:37] <fwereade> wallyworld, cheers
[22:37] <wallyworld> we'll keep you in the loop
[22:37] <wallyworld> i'm thinking the avail set name would be mysql-<env uuid>
[22:38] <wallyworld> config for auto avail sets would default to true, would be turned off for density perhaps
[22:38] <wallyworld> or even no option, and if density directives used, don't do auto
[22:39] <fwereade> wallyworld, hard to switch over though
[22:39] <fwereade> wallyworld, anyway I must return to my other life
[22:39] <fwereade> wallyworld, cheers
[22:39] <wallyworld> sure, see ya
[22:39] <wallyworld> what, you have a life?
[22:40] <fwereade> ;p
[22:56] <marcoceppi> fwereade: are you around?
[23:54] <marcoceppi> thumper: hey, just installed juju-core from source, boostraping local provider, but it's using 1.17.0 tools, --upload-tools doesnt' seem to work, how can I get 1.17.1 tools for local from compiled juju?