[00:04] <wallyworld> rick_h_: there are two tech debt bugs you moved to beta16, they are really not urgent, i'd like to move them back eg 1577589
[00:37] <mup> Bug #1442149 changed: UniterSuite.TestUniterUpgradeConflicts fails <ci> <intermittent-failure> <test-failure> <juju-core:Invalid> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1442149>
[00:48] <rick_h_> wallyworld: ok i think you meam ones marked as adsigned and were theybin progress?
[00:48] <rick_h_> wallyworld: ok with moving them, just wanted to checknon reality vsnbug info
[00:49] <wallyworld> vsn?
[00:49] <rick_h_> vs bug info
[00:50] <rick_h_> darn phone typing ftw
[00:50] <wallyworld> np :-) yeah, will be nice to get the affect methods sorted, but not this week
[00:56] <anastasiamac> wallyworld: so moving to beta17 and re-assigning from Horacio :D
[00:56] <wallyworld> no,
[00:57] <wallyworld> horatio still needs to fix at some point
[00:57] <wallyworld> and not necessarily for beta17
[00:57] <wallyworld> moved back to 2.0.0 for now
[00:58] <anastasiamac> tyvm
[01:50] <redir> I need a hobby to do while waiting for test runs
[01:54] <anastasiamac> redir: picking up and fixing a bug could b a very relaxing hobby :D
[01:58] <redir> anastasiamac: but I can't run the tests while working on a different branch.
[01:59] <redir> and my other computer is running gostress on that race,  unsuccsessfully
[02:02] <thumper> Unable to fetch Juju GUI info: error fetching simplestreams metadata: cannot read product data, invalid URL "https://streams.canonical.com/juju/gui/streams/v1/com.canonical.streams-released-gui.sjson" not found
[02:02] <thumper> wat?
[02:03] <thumper> do we care?
[02:03] <thumper> I feel we should
[02:03] <anastasiamac> thumper: we should as we can browse to it..
[02:03] <anastasiamac> thumper: what are u running? how are u hitting it?
[02:04] <thumper> http://pastebin.ubuntu.com/23063199/
[02:05]  * thumper is tapping fingers while reproducing issue
[02:05] <thumper> well, hopefully QAing that I've fixed it
[02:06] <anastasiamac> thumper: if there is no bug, I'd say it ^^ should be
[02:07] <anastasiamac> thumper: and u can navigate to this URL, right? it's not like u do not have internet access...
[02:08] <redir> what's internet access
[02:08] <redir> ?
[02:09] <thumper> wallyworld: ping
[02:09] <wallyworld> wot
[02:09] <thumper> chat?
[02:09] <wallyworld> sure
[02:17] <redir> wallyworld: this bud's for you http://reviews.vapour.ws/r/5454/
[02:18] <wallyworld> redir: thanks, will look soon
[02:18] <redir> wallyworld: ^ it's the dummy provider region stuff. If you approve I'll come back and merge for a fresh start tomorrow.
[02:18] <redir> bbiab
[02:18] <wallyworld> ok
[02:44] <natefinch> wallyworld: can you help me debug my custom simplestreams setup for agent tools?  I'm trying to deploy a windows binary on azure but it keeps saying no tools found even though it really should be finding them, and I can't tell from the logs why it's not finding them.
[02:45] <wallyworld> i'm sorta tied up trying to fix a CI issue, debug output lists the steps it goes through along the way, does that not help?
[02:46] <wallyworld> you can also check what gets into state as that iis where the tools come from
[02:46] <wallyworld> when you use metadata-source
[02:46] <wallyworld> using metadata-source is supposed to grab the tools and save in state
[02:46] <wallyworld> and from there, no simplestreams is used
[02:47] <wallyworld> as the controller will search state and see the tools in there
[02:47] <natefinch> wallyworld: not enough..  it finds the index2.json in my s3 bucket, finds the list of candidates... one of which looks like it should match, and then the next thing it logs is trying the default simplestreams source
[02:47] <natefinch> wallyworld: I think there's a bug filed about metadata source not working, unless that's been fixed
[02:47] <wallyworld> you can add debug to the match function
[02:47] <wallyworld> see why there's no match
[02:48] <anastasiamac> natefinch: metadata-source is not fixed.. in progress
[02:48] <natefinch> anastasiamac: cool
[02:48] <wallyworld> probs the easiest is to add extra debug to the match function to print for each candidate why the match failed
[02:48] <wallyworld> it's probably related to dev vs non-dev
[02:48] <natefinch> wallyworld: yeah, I'll do that. Thanks
[02:49] <wallyworld> that stuff really needs to die (the old dev paradigm)
[02:49] <wallyworld> odd version = dev stuff
[02:49] <wallyworld> it's all obsolete now
[02:49] <natefinch> I'm certainly more than happy to never have to deal with simplestreams again :)  generate metadata is *also* broken, so I had to actually hack the metadata by hand.
[02:50] <wallyworld> natefinch: and if the debug is useful, leave it in there for the next poor f*cker who has to deal with this
[02:50] <natefinch> wallyworld: haha yeah
[02:50] <wallyworld> what's broken with egenrate?
[02:50] <natefinch> wallyworld: only generates for 1.x versions or something... lemme find the bug
[02:51] <natefinch> https://launchpad.net/bugs/1613858
[02:51] <wallyworld> that tools hasn't been updated in so long
[02:51] <natefinch> heh, I guess mup doesn't like that format - https://bugs.launchpad.net/juju-core/+bug/1613858
[02:51] <wallyworld> not surprised it's out of date
[02:51] <natefinch> or mup's broken
[02:52] <natefinch> I was just lamenting that all I really want is juju upload-tools win2012r2 amd64 /path/to/jujud.exe
[02:53] <natefinch> we always get so fancy, and what I really want is the simplest thing that can possibly work
[03:14] <wallyworld> natefinch: we can add that command now that tools are stored in state, it was never possible before. but no one has gotten around to it
[03:14] <wallyworld> it's been one of those friday afternoon things
[03:15] <wallyworld> maybe you have an itch you'd like to scratch :-)
[03:18] <natefinch> wallyworld: like I've been rolling in poison ivy
[03:18] <wallyworld> lol
[03:22] <axw> thumper: is migration supposed to handle unprovisioned machines?
[03:22] <thumper> no
[03:22] <thumper> the prechecks will fail
[03:22] <thumper> at this stage
[03:22] <axw> okey dokey
[03:22]  * thumper taking kiddo to hockey
[03:22] <thumper> back later
[04:00] <natefinch> wallyworld: if you use upload-tools, we don't look in simplestreams at all, do we?
[04:00] <wallyworld> correct, but upload tools now deeted
[04:00] <wallyworld> deleted
[04:00] <wallyworld> and so we do look
[04:00] <natefinch> heh
[04:01] <natefinch> I should pull master evidently
[04:01] <wallyworld> and if none fund, we upload
[04:02] <natefinch> I really miss being able to just tell juju what to, rather than hoping it'll do what I want it to do :/
[04:03] <natefinch> It still seems like making the same mistake we made with ensure-HA, where we'd do the "right thing" but then users couldn't tell what the command would do before they ran it.
[04:15] <natefinch> wallyworld: so... if I build from current master... it always uses upload-tools?
[04:18] <natefinch> (looks like yes, from the logs)
[04:18] <natefinch> still does the nasty "add a build number of .1" though, I see.  ick.
[04:25] <wallyworld> that's expected and required
[04:25] <wallyworld> so we can tell what has been custom uploaded
[04:26] <wallyworld> so when people say they have an issue we know if it is stock or not
[04:27] <natefinch> there's a lot of ways to record that we've custom uploaded without changing the version number itself.  Maybe the version number is the most visible... just annoyed I have to go modify my streams metadata to make the version .1 (I presume juju will only accept exact matches to what is on the controller)
[04:33] <natefinch> wallyworld: do you know why this if statement is there? https://github.com/juju/juju/blob/master/environs/simplestreams/simplestreams.go#L457   seems to prevent us from logging the simplestreams error unless it's one specific kind
[04:34] <natefinch> wallyworld: for example, it prevented me from seeing the json unmarshal error from my simplestreams data
[04:36] <wallyworld> not sure anymore, i think it was because there we all sorts of reasons why tools search could fail (external to juju) and we didn't care about the specifics - if one path failed, the next would be tried
[04:36] <wallyworld> anything from unauthorised http to url not being there etc etc
[04:36] <wallyworld> also stale streams data that wasn't cleaned up
[04:37] <natefinch> all of that seems like useful information... if the user has set a streams url, they probably expect it to be used.
[04:37] <wallyworld> sometimes, but not always
[04:37] <wallyworld> they could only have a subset of data there and expect fallback to official sources
[04:38] <wallyworld> the output was waaaay noisy with all the "expected" errors
[04:38] <wallyworld> and so i think people wanted it to be quiet
[04:38] <natefinch> maybe we can put back the general error logging in trace?
[04:38] <wallyworld> sure
[04:38] <wallyworld> if there's a need for it, i have no opinion either way
[04:39] <wallyworld> i was happy enough with lots of output
[04:39] <wallyworld> but when people bootsrapped with --debug they complained
[04:40] <wallyworld> especially since we had up to 4 datasources wach with json and sjson
[04:40] <wallyworld> and index and index2
[04:40] <natefinch> yeah, I agreed with them at the time, but when things break, it's nice having the output.  It's hard to know when it's an expected error and when it's not
[04:41] <wallyworld> yeah, i guess it hasn't been an issue because setting up the streams has all been upstream from us
[04:41] <wallyworld> done by the Qa guys
[04:41] <natefinch> yep
[04:43] <wallyworld> as you say, not till you roll around in the poison ivy that you start to itch :-D
[04:43] <natefinch> haha yep
[04:43] <wallyworld> did you finf your issue?
[04:43] <wallyworld> in thw matching?
[04:44] <natefinch> yeah, some invisible unicode character in the end of my tools.json was making it fail unmarshaling
[04:44] <wallyworld> ah
[04:45] <natefinch> we'll see what happens when I try again with it fixwed
[04:45] <natefinch> this is like the 8th problem I've fixed
[04:46] <natefinch> I think always logging that error message will help a lot though.
[04:47] <natefinch> holy crap I think it worked
[04:48] <redir> trumpets blare
[04:48] <redir> angels sing
[04:48] <redir> first growth bordeaux rains from the sky
[04:49] <natefinch> I've been trying to get ci to run with my windows tools for literally 16 hours of active work time
[04:50]  * redir fails to generate a good relativity joke
[04:51] <redir> wallyworld: http://reviews.vapour.ws/r/5454/ has a shipit button that is calling your name:)
[04:52] <wallyworld> ooh, let me look
[04:54] <wallyworld> redir: +1 from me, we can debate the name next pr
[04:55] <redir> wallyworld: works for me.
[04:56] <wallyworld> natefinch: you would be a good person to review the doc page for adding your own tools then :-)
[04:57] <wallyworld> https://jujucharms.com/docs/1.25/howto-privatecloud
[05:08] <wallyworld> axw: care to do a very small review to fix a CI regression http://reviews.vapour.ws/r/5456/ ?
[05:09] <axw> sure
[05:10] <axw> natefinch: what are you doing with windows agents? I wrote a plugin for cross-compiling/building and uploading agents, might be useful...
[05:13] <veebers> wallyworld, axw: Who's best to ask about grant revoke? I'm debugging the user grant/revoke test. I see a user removed but the user still remains in the list-shares output. (but is gone from list-users output)
[05:13] <veebers> That might be a bug?
[05:13] <wallyworld> sounds like it, i think there's a bug already raised
[05:13] <wallyworld> https://bugs.launchpad.net/juju-core/+bug/1613444
[05:13] <mup> Bug #1613444: Remove-user doesn't remove user from list-shares <ci> <list-shares> <regression> <revoke> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1613444>
[05:14] <axw> wallyworld: reviewed
[05:14] <wallyworld> ta
[05:14] <veebers> wallyworld: ah thanks missed that bug
[05:15] <wallyworld> no wuckers
[05:16]  * veebers googles wuckers
[05:16] <veebers> hah, love it
[05:18] <veebers> wallyworld: ok one more concern, if I do something like: "juju add-model new-model2 && juju destroy-model new-model2 -y" new-model2 stays around in list-models output. I would say this is a bug even if it's pretty odd to create then immediately destroy the model
[05:18] <veebers> oh also, I cannot destroy the model now :-\ it's not found when I try
[05:19] <wallyworld> veebers: surely as a kiwi you'd know what "wuckers" means? :-D
[05:20] <wallyworld> it takes a finite time for the model to be cleaned up
[05:20] <veebers> wallyworld: hah never heard the shorthand wuckers, def heard the long form
[05:21] <wallyworld> perhaps we can improve the experience there
[05:21] <wallyworld> there may be a bug already, not sure tbh
[05:21] <veebers> wallyworld: it's been 4+ minutes and the model still appears in list-models
[05:21] <veebers> (this is local lxd)
[05:21] <wallyworld> i'd need to check - i think list-models just looks at local yaml file
[05:21] <wallyworld> well, it used to
[05:22] <wallyworld> worth a bug so we can investigate
[05:22] <wallyworld> if there's not already one there
[05:22] <veebers> I'll have a look see if I can find one
[05:26] <veebers> axw: as an aside I think you can this one now right? https://bugs.launchpad.net/juju-core/+bug/1605710
[05:26] <mup> Bug #1605710: Fix and reland axw/cli-model-owner <ci> <grant> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1605710>
[05:26] <axw> veebers: yup, thanks
[05:32] <veebers> wallyworld: fyi I filed 1613960
[05:32] <wallyworld> ok, ta
[05:35]  * thumper-afk headdesks
[05:35] <thumper-afk> oh
[05:35] <thumper-afk> didn't change back
[05:35] <thumper> wallyworld: bumping up against romulus dependencies
[05:35] <thumper> with the command formatter branch
[05:35] <wallyworld> \o/
[05:36] <wallyworld> details?
[05:36] <thumper> it specifies command formatters
[05:36] <thumper> and I've changed them :)
[05:36] <wallyworld> ah
[05:37] <wallyworld> patches accepted :-D
[05:39] <thumper> bah humbug
[05:41] <mup> Bug #1605710 changed: Fix and reland axw/cli-model-owner <ci> <grant> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1605710>
[05:41] <mup> Bug #1613960 opened: list-models can show a model that was supposed to have been deleted <juju-core:New> <https://launchpad.net/bugs/1613960>
[05:41] <wallyworld> thumper: the default yaml marshaller does append a new line, but weren't we stripping it off for a reason, so as not to append an extra one in our output?
[05:42] <thumper> no, no good reason at all
[05:42] <wallyworld> why change the existing output behaviour just to add colour?
[05:42] <thumper> this isn't
[05:42] <thumper> this is standardising on the formatters
[05:42] <wallyworld> ok
[05:42] <thumper> why not output what it is?
[05:42] <thumper> if it is new lines
[05:42] <thumper> output the damn new lines
[05:42] <thumper> it won't change any of our output
[05:43] <thumper> because we don't marshall strings by themselves
[05:43] <thumper> because that's dumb
[05:43] <thumper> it is attempting to be smart of the hell of it
[05:43] <thumper> when there is no good reason
[05:43] <wallyworld> and yet a newline is appended to json
[05:44] <thumper> because it doesn't append a new line to the end
[05:44] <thumper> the formatters make sure it finishes with a new lien
[05:44] <thumper> lien
[05:44]  * thumper headdesks
[05:44] <thumper> line
 why not output what it is?
[05:44] <wallyworld> :-P
[05:44]  * thumper slaps wallyworld
[05:44] <wallyworld> lol
[05:45] <wallyworld> don't you hate it when your own words come back and slap you on the arse
[05:46] <wallyworld> i gave it a ship it, but just make sure you don't f*ck up anything
[05:46] <thumper> we add a new line to the end of the json so your next prompt doesn't end up at the end of the json line
[05:46] <wallyworld> exactly
[05:46] <wallyworld> but
[05:46] <wallyworld> wouldn't stripping the yaml \n have cuased the same issue?
[05:47] <wallyworld> so maybe we are adding a \n somewhere else
[05:47] <wallyworld> and now for json we'll get 2
[05:47] <wallyworld> i may be wrong, just a guess based on what the code used to do
[05:48] <wallyworld> it would have been stripping the \n for a reason
[05:48] <wallyworld> i bet we add a \n in juju
[05:49] <wallyworld> i reckon you need to try it out before landing to confirm one way or the other
[05:52] <thumper> wallyworld: for you :) http://reviews.vapour.ws/r/5457/
[05:52] <thumper> no
[05:52] <thumper> you don't get it
[05:52] <thumper> if you want to chat we can
[05:52] <thumper> but you are missing something
[05:53] <wallyworld> it's ok, i trust you
[05:53] <wallyworld> almost
[05:53] <thumper> :)
[05:53] <thumper> let's just say "I won't fuck it up" (probably)
[05:54] <thumper> but now, it's dinner time
[05:55] <thumper> so I'll look tomorrow morning
[05:55] <thumper> laters
[05:55] <axw> TIL: there's (fairly minimal) Go bindings for OpenStack in their tree: http://git.openstack.org/cgit/openstack/golang-client/
[05:57] <wallyworld> axw: maybe we can hope to kill off goose for xmas dinner at some point :-)
[05:57] <axw> wallyworld: that would be nice
[07:40] <ejat> jamespage: are u there
[08:11] <mup> Bug #1613992 opened: 1.25.6 "ERROR juju.worker.uniter.filter filter.go:137 tomb: dying" <juju-core:New> <https://launchpad.net/bugs/1613992>
[08:38] <wallyworld> axw: did you get a chance to look at the manual provider issue?
[08:41] <axw> wallyworld: nope, been looking at the azure one all day
[08:41] <wallyworld> np
[08:57] <voidspace> as usual uninstalling maas and trying to reinstall completely fecked the VM
[08:57] <voidspace> starting again from scratch
[08:59] <babbageclunk> voidspace: :(
[08:59] <voidspace> babbageclunk: :-)
[08:59] <voidspace> babbageclunk: hey, hi
[08:59] <babbageclunk> voidspace: Maybe snapshot before installing?
[08:59] <voidspace> babbageclunk: yeah, good plan
[09:00] <voidspace> babbageclunk: wotcha working on?
[09:00] <babbageclunk> voidspace: the worker to release container addresses. Hopefully the last bit!
[09:01] <voidspace> babbageclunk: ah, cool
[09:01] <voidspace> babbageclunk: I'm on a 1.25 backport of network stuff (the bridge scripts), so installing maas 1.9
[09:01] <voidspace> babbageclunk: I had to go back and read up how to configure a maas 1.25 environment too, it's that long since I've done it...
[09:03] <babbageclunk> voidspace: Oh, I just got pointed at this too: https://bugs.launchpad.net/juju-core/+bug/1605653
[09:03] <mup> Bug #1605653: backup-restore failed creating collection EOF <backup-restore> <ci> <regression> <xenial> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1605653>
[09:03] <babbageclunk> voidspace: do you know whether failures are automatically added to these pages? http://reports.vapour.ws/releases/issue/57922732749a5624aac9f7b8
[09:03] <voidspace> babbageclunk: anything to do with backup and restore is horrible
[09:04] <voidspace> babbageclunk: I believe so, if the error matcher finds them
[09:04] <babbageclunk> voidspace: 'cause if it's automatic then it looks like this failure hasn't happened for 3 weeks.
[09:05] <voidspace> babbageclunk: right
[09:05] <voidspace> babbageclunk: maybe it got fixed by accident :-)
[09:05] <babbageclunk> voidspace: yeah, that's what I'm thinking. Kind of annoying.
[09:06] <babbageclunk> voidspace: but good I guess!
[09:06] <voidspace> :-)
[09:17] <mup> Bug #1614010 opened: juju register: cannot register a user when controller already exists <juju-core:New> <https://launchpad.net/bugs/1614010>
[09:29] <voidspace> right, cloned trusty vm with correct /e/n/i and just before maas install
[09:39] <voidspace> frobware: ping
[09:44] <frankban> wallyworld: hey, with current tip, Login no longer includes ModelManager in the facade list
[09:45] <wallyworld> hmmm, ok
[09:45] <wallyworld> frankban: could that be rogpeppe's latest change to separate controller and model logins?
[09:46] <rogpeppe> frankban: are you logging in to a model?
[09:46] <frankban> rogpeppe: yes
[09:46] <rogpeppe> frankban: in that case, ModelManager is not available
[09:46] <rogpeppe> frankban: ModelManager is now only available to a controller-only API connection
[09:46] <rogpeppe> frankban: along with the other controller-only facades
[09:47] <rogpeppe> frankban: i sent an email to the group about this
[09:48] <frankban> rogpeppe: so, in order to get current model info (like default series, name, provider type) the GUI now needs to use the connection to the controller, right?
[09:49] <rogpeppe> frankban: that's right
[09:49] <frankban> rogpeppe: it's a bit weird that you cannot get info on the currently connected model from the model connection itself
[09:50] <rogpeppe> frankban: because the model info contains things like the model name which can be different between the controller and in the sub-controller
[09:50] <rogpeppe> frankban: tbh it might only be the name that's problematic
[09:53] <rogpeppe> frankban: would it be OK if ModelInfo was provided on another (non-controller-specific) facade and didn't provide the model name?
[09:53] <rogpeppe> frankban: i mean, presumably we already know the name, right?
[09:55] <frankban> rogpeppe: why should the GUI know the name? anyway, that should be ok
[09:56] <rogpeppe> frankban: because how else does it know how to connect to the model?
[09:56] <frankban> rogpeppe: a model is a websocket URL
[09:57] <rogpeppe> frankban: how do you get that URL?
[09:57] <frankban> rogpeppe: it is provided by either the charm or juju itself in gijoe
[09:58] <frankban> rogpeppe: in the dynamically generated GUI config.js
[09:58] <frankban> rogpeppe: are there any other facades no longer available on the model?
[09:58] <rogpeppe> frankban: so how do you know where to get config.js from?
[09:59] <rogpeppe> frankban: the group email mentioned them:  AllModelWatcher Cloud Controller MigrationTarget ModelManager UserManager
[10:00] <frankban> rogpeppe: ok so the GUI only uses ModelManager in this list
[10:01] <frankban> rogpeppe: would it be doable to reintroduce that in the models, just to give the GUI time to implement the double connection?
[10:01] <rogpeppe> frankban: could you just avoid using the latest juju-core for the time being?
[10:02] <frankban> rogpeppe: I guess those changes will be released friday on the new beta, so I am worried we don;t have enough time
[10:04] <rogpeppe> frankban: i'd prefer to implement ModelInfo on a different facade instead
[10:04] <rogpeppe> frankban: at least then we'd be going in the right direction
[10:09] <frankban> rogpeppe: ModelInfo on another facade solves some problems (even if we need the model name as well). not sure it gives time sufficient time to have a working GUI on next beta (no ListModels, CreateModel etc.). let's discuss this later with Jeff and Uros
[10:10] <dimitern> menn0, katco, babbageclunk: I'd appreciate a review on http://reviews.vapour.ws/r/5449/, it's quite short
[10:11] <frankban> rogpeppe: anyway, ModelInfo on a model facade sounds good to me, as it means we don't have to share model data between the two websocket connections
[10:11] <dimitern> frobware: ^^
[10:11] <rogpeppe> frankban: yeah
[10:13] <babbageclunk> dimitern: looking
[10:14] <dimitern> babbageclunk: ta!
[10:19] <babbageclunk> dimitern: LGTM!
[10:19] <dimitern> babbageclunk: thanks!
[10:19] <dimitern> voidspace: hey, did you manage to get your maas setup going?
[10:22] <dimitern> voidspace: if so, could I ask you to QA my fix on your maas?
[10:26]  * frobware is dismayed that all the individal QA efforts for commits don't get captured into tests that can be repeated ad nauseum.
[10:54] <rogpeppe> frobware: i think the point is that QA efforts are a bit random
[10:54] <rogpeppe> frobware: you play with the new thing
[10:55] <rogpeppe> frobware: if all the individual QA efforts were captured into tests, our test suite would run for weeks
[10:55] <frobware> rogpeppe: but after you do the same thing for a while you have to question why your're doing it again.
[10:55] <frobware> rogpeppe: that's fine. they don't have to run all the time. you could have one job a week that runs them all.
[10:56] <rogpeppe> frobware: that's what our CI tests are essentially
[10:56] <frobware> rogpeppe: it's the endless setup/teardown cost for humans that I think is a problem
[10:57] <rogpeppe> frobware: if you find yourself repeating the same thing, there's nothing stopping us scripting something
[10:57] <rogpeppe> frobware: the reason for the QA thing is that everyone was always just relying on the test suite to find problems, and loads of problems slipped through the net because noone thought to actually use the thing in practice
[10:57] <frobware> rogpeppe: agreed. but in reality it seems more like... "i'll just stop what I'm doing, quickly (ha!) test this thing, then move on"
[10:58] <frobware> rogpeppe: 90%+ of what I do is manual testing. this seems wrong.
[10:59] <rogpeppe> frobware: that seems a bit surprising. the test suite takes 30 minutes by itself to run, right?
[10:59] <frobware> rogpeppe: the test suite doesn't test real networking.
[10:59] <frobware> rogpeppe: it's too perfectly fictious.
[10:59] <rogpeppe> frobware: so how would you suggest that the tests *did* test real networking?
[11:00] <rogpeppe> frobware: QA is not intended to be a substitute for automated tests
[11:00] <rogpeppe> frobware: it's just a smoke-test thing
[11:00] <frobware> rogpeppe: we turn /some/ of the QA tests into running those manual steps. Sure, there's a boatload of infra to get to that point but until we address that we'll continue with the manual effort.
[11:01] <rogpeppe> frobware: if you're spending 90% of your time doing manual QA, there's something wrong
[11:01] <frobware> rogpeppe: ^^ :)
[11:02] <rogpeppe> frobware: i can't parse the sentence "we turn /some/ of the QA tests into running those manual steps"
[11:03] <frobware> rogpeppe: so I initially said "all" whereas that's not necessarily useful or practical. The "some" is me being more pragmatic.
[11:04] <rogpeppe> frobware: i still don't understand
[11:04] <rogpeppe> you want to turn some of the QA tests into manual steps?
[11:04] <rogpeppe> frobware: they already are manual steps, right?
[11:05] <frobware> rogpeppe: ah, I see.... my fault.
[11:05] <frobware> rogpeppe: how do we capture those manual steps into an automated test/script/whatever?
[11:05] <rogpeppe> frobware: right
[11:06] <rogpeppe> frobware: i think there's a lot to be said for coming up with a set of tools that (say) makes QAing (and possibly automated testing) networking stuff easier
[11:06] <rogpeppe> frobware: i think this is probably a particular issue for networking tests
[11:06] <frobware> rogpeppe: yep. I want to automatically provision three nodes, where two nodes have one bonded nic.... and so on.
[11:07] <rogpeppe> frobware: exactly
[11:07] <frobware> rogpeppe: this is where my 90% time comes from. by the time I've done that the next thing I move onto is a variation on that, hence the setup/tear down/setup cost.
[11:07] <rogpeppe> frobware: do the usual thing: imagine how you'd like to specify your usual range of QA scenarios in an ideal world, then think how that might be done
[11:08] <rogpeppe> frobware: i.e. think devops :)
[11:08] <frobware> rogpeppe: you mean like this? https://circleci.com/blog/its-the-future/ :-D
[11:09] <rogpeppe> frobware: precisely :)
[11:09] <frobware> rogpeppe: made me chuckle
[11:10] <rogpeppe> anyone want a straightforward review? this allows Ping to work on controller-only API connections: http://reviews.vapour.ws/r/5458/)
[11:10] <voidspace> dimitern: yes, I have maas 1.9 and 2.0 setup
[11:11] <voidspace> dimitern: I'm reluctant to screw with my maas 1.9 setup (only one node on it currently) until I've finished this testing though
[11:11] <voidspace> dimitern: send me the branch and the QA steps
[11:11] <dimitern> voidspace: it's easy to revert
[11:11] <voidspace> dimitern: I'm not worried about juju
[11:12] <dimitern> voidspace: it's all in the PR desc: http://reviews.vapour.ws/r/5449/ and the branch is lp-1612624-ipv6-mongod
[11:12] <voidspace> dimitern: I'm taking a lunch break and can look after that
[11:12] <voidspace> dimitern: ok
[11:12] <dimitern> voidspace: thanks!
[11:12] <voidspace> dimitern: ok to test on maas 2?
[11:13] <dimitern> voidspace: shouldn't matter, 1.9 or 2.0
[11:13] <voidspace> dimitern: ok, cool
[11:16] <dimitern> strictly speaking, maas is not even needed - there should be a way to test it on lxd, assuming the kernel args can somehow be passed to the container via cloud-init
[11:59] <mup> Bug #1614065 opened: Unable to attach storage, storage not found <juju-core:New> <https://launchpad.net/bugs/1614065>
[12:03] <dimitern> another tiny review anyone? http://reviews.vapour.ws/r/5459/
[12:04] <mgz> is it really better to do
[12:04] <mgz> var (
[12:04] <mgz>   a uint64
[12:05] <mgz>   b error
[12:05] <mgz> )
[12:05] <mgz> rather than just have two var lines?
[12:05] <dimitern> it's a matter of taste I guess
[12:06] <mgz> err at least could be one scope in
[12:06] <dimitern> var ( longVarHere evenLongerType\nandAnotherLongVar map[string]interface{}\n )
[12:06] <mgz> dimitern: my only realy question is if 0 is the right no-backing-inode value
[12:07] <mgz> I guess it's safely invalid?
[12:07] <dimitern> mgz: it's the zero value of the underlying type we're parsing the value into
[12:08] <dimitern> mgz: also this: http://stackoverflow.com/questions/2099121/why-do-inode-numbers-start-from-1-and-not-0 :)
[12:08] <mgz> dimitern: that's what I wanted to know, thanks
[12:09] <dimitern> mgz: but good question ;)
[12:09] <mgz> dimitern: shipit
[12:09] <dimitern> mgz: awesome! did you try QAing it?
[12:10] <mgz> dimitern: nope, but I certainly can now
[12:10] <dimitern> it took me longer to write the QA steps than the fix :D
[12:10] <dimitern> mgz: if you can, even better!
[12:11] <mgz> hm, I lost my remote dimitern alias
[12:11] <dimitern> (I suspect the steps should work, but haven't actually tried them myself - with the exact commands I mean)
[12:11] <anastasiamac> mgz: have u seen bug 1613864? I'd really appreciate if you could comment there :)
[12:11] <mup> Bug #1613864: Missing "juju-2"/"juju2" command. <landscape> <juju-core:New> <https://launchpad.net/bugs/1613864>
[12:11] <mup> Bug #1614065 changed: Unable to attach storage, storage not found <juju-core:New> <https://launchpad.net/bugs/1614065>
[12:11] <dimitern> anastasiamac: only as a title - will have a look in a bit
[12:12] <anastasiamac> dimitern: i think it may b packaging related and was hoping mgz would know \o/ I've seen his name on a couple similar ones :D
[12:13] <mgz> anastasiamac: that bug does describe reality
[12:13] <anastasiamac> mgz: all bugs do :D
[12:13] <mgz> anastasiamac: it's what was decided back in the discussions before xenial release - I think my first version had all the aliases?
[12:14] <mgz> I'd need to look at email threads again to remember the reasoning, but generally we don't like too many names for the same thing
[12:14] <mup> Bug #1614065 opened: Unable to attach storage, storage not found <juju-core:New> <https://launchpad.net/bugs/1614065>
[12:14] <mup> Bug #1614072 opened: storage minimum size and default size are conflated <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1614072>
[12:15] <anastasiamac> mgz: i agree.. plz comment on it (when u get chance) that the behavior & observation is expected. it'll give us grounds to mark as 'won't fix'.. unless we need to fix?...
[12:16] <mgz> it's not an unreasonable request
[12:17] <mgz> dimitern: git checkout HEAD doesn't do what you want
[12:17] <mgz> otherwise the steps are okay
[12:18] <mgz> dimitern: qa okay, http://paste.ubuntu.com/23064328
[12:19] <dimitern> mgz: thanks! I'll update the second git checkout step
[12:44] <rogpeppe> i'm needing a second review of this please - does anyone have a moment to have a look? http://reviews.vapour.ws/r/5458/
[12:47] <dimitern> anastasiamac: bug 1613864 - seems like a packaging issue, but natefinch might know if to fix it we need to change cmd/juju's main funcs
[12:47] <anastasiamac> dimitern: thnx. i have also asked mgz :)
[12:47] <dimitern> rogpeppe: I was about to, but the QA steps were unclear
[12:47] <dimitern> rogpeppe: how to make a controller-only api connection
[12:48] <anastasiamac> dimitern: i'll reach out to nate during my day tomorrow -he seems to be doing a few late nights :)
[12:48] <dimitern> anastasiamac: +1
[12:48] <rogpeppe> dimitern: well, you could review it and leave the QA to someone else
[12:48] <rogpeppe> dimitern: you make a websocket connection to the juju API at the path /api
[12:48] <rogpeppe> dimitern: i'm afraid i can't think of any other way to QA this
[12:48] <dimitern> rogpeppe: with what? curl? :)
[12:49] <rogpeppe> dimitern: probably by writing a custom Go program to do it
[12:49] <rogpeppe> dimitern: i think that frankban can QA it more easily
[12:49] <dimitern> rogpeppe: see - if you can't describe with a few steps, who could QA it apart from you? :)
[12:49] <rogpeppe> dimitern: as the GUI makes long-lived connections to the controller-only API
[12:50] <rogpeppe> dimitern: i did describe it :)
[12:50] <dimitern> rogpeppe: ah, well - if that works, it should be easy
[12:50] <rogpeppe> dimitern: i just didn't write the code to do it
[12:51] <rogpeppe> dimitern: it's a pity that it's hard to open an API connection from Go. lots of boilerplate required. i think i might write a little package to make it easier.
[12:51] <dimitern> rogpeppe: is a controller long identified by the controller uuid as username/tag?
[12:52] <rogpeppe> dimitern: "controller long" ?
[12:52] <dimitern> rogpeppe: sorry, login
[12:52] <rogpeppe> dimitern: no, it's identified by the websocket URL being /api rather than /model/:modeluuid/api
[12:54] <dimitern> rogpeppe: ok, I'll leave it to frankban to QA then (ideally with a comment how he did it)
[12:54] <rogpeppe> dimitern: thanks
[12:57] <frankban> rogpeppe: I can QA it very quickly with a python script
[12:57] <rogpeppe> frankban: cool
[12:58] <frankban> rogpeppe: a comment on how I did it would be just "I wrote a Python script"
[12:58] <rogpeppe> frankban: i guess you could include the script :)
[12:59] <frankban> rogpeppe: well, I have a little library that allows me to run arbitrary ws calls, so it's not really a single file script
[13:01] <voidspace> dimitern: testing your branch now
[13:01] <voidspace> dimitern: well, starting to
[13:01] <frankban> rogpeppe: I'll try to make it a standalone
[13:01] <dimitern> rogpeppe: reviewed
[13:02] <dimitern> frankban: well, pasting the script will help anyone that has to repro it later ;)
[13:02] <dimitern> voidspace: great!
[13:11] <voidspace> dimitern: frobware: with my backport of the bridge script fixes to 1.25, the following is the /e/n/i generated on the bootstrap node
[13:12] <voidspace> dimitern: frobware: http://pastebin.ubuntu.com/23063945/
[13:12] <dimitern> voidspace: looking
[13:12] <voidspace> dimitern: frobware: this is a machine with two bonded NICs and a vlan
[13:12] <voidspace> dimitern: frobware: it looks good to me
[13:13] <voidspace> dimitern: frobware: maas 1.9 didn't pick up the vlan though - I had to add it as an interface to the controller, so it appears as "untagged"
[13:13] <voidspace> dimitern: frobware: which is concerning :-/
[13:13] <dimitern> voidspace: the backport of https://github.com/juju/juju/pull/5791 ?
[13:14] <voidspace> dimitern: yes
[13:14] <voidspace> dimitern: although basically I pulled in *all* the changes
[13:14] <dimitern> voidspace: 1.25 only bridges the default route interface
[13:14] <rogpeppe> dimitern: i'm not sure that it's worth defining a type for those constants - they're only used in an error message
[13:14] <dimitern> voidspace: so that's as I'd expect it to look I think
[13:14] <voidspace> dimitern: cool
[13:15] <voidspace> dimitern: once I've done your tests (bootstrapping now) I'll add a  new node and do a deploy as a sanity check
[13:15] <rogpeppe> dimitern: restrictedRoot could be used for other purposes too - there's no particular need to enumerate the possible strings, i think
[13:16] <natefinch> morning all
[13:16] <voidspace> natefinch: o/
[13:16] <natefinch> dimitern, anastasiamac, mgz: seems like you guys have that juju2 bug under control?
[13:16] <rogpeppe> dimitern: it's not like we actually check against the values of connType or anything
[13:16] <dimitern> rogpeppe: would it be too much trouble though? :)
[13:16] <rogpeppe> dimitern: i think it gives the wrong impression
[13:17] <dimitern> voidspace: that's ok, but if you managed to bootstrap with ip6.disabled=1 you've QA-ed it already :)
[13:17] <rogpeppe> dimitern: like those names are important somehow
[13:17] <rogpeppe> dimitern: but we don't define constants for all the strings we pass to fmt.Println
[13:17] <voidspace> dimitern: I'm bootstrapping now
[13:17] <dimitern> natefinch: o/ well kinda - it's worth double checking no code changes will be needed
[13:17] <voidspace> dimitern: ah, complete
[13:17] <rogpeppe> dimitern: so i don't really see why it's worth doing here
[13:18] <dimitern> rogpeppe: well.. ok
[13:18] <rogpeppe> dimitern: let alone exporting this trivial implementation detail
[13:18] <voidspace> dimitern: to be fair I want to see it fail with master too - to ensure it's actually making a difference
[13:18] <dimitern> rogpeppe: they don't have to be exported
[13:18] <dimitern> rogpeppe: but I don't want to argue :) I'll drop the issue
[13:19] <rogpeppe> dimitern: would you prefer it if we passed in the whole message to print?
[13:19] <dimitern> voidspace: ah, right
[13:19] <rogpeppe> s/print/use in the error/
[13:19] <voidspace> dimitern: just reverted to master and bootstrapping with the setting still in place
[13:19] <dimitern> rogpeppe: not really
[13:19] <dimitern> voidspace: +1
[13:20] <rogpeppe> dimitern: i think it's worth defining constants when the values actually matter to something
[13:21] <dimitern> rogpeppe: it my mind having a const you can jump to or autocomplete is worth the time you'll otherwise spend grepping for a string literal, and sifting through lots of possibly unrelated hits
[13:22] <rogpeppe> dimitern: i don't understand. these values are used in exactly one place.
[13:22] <dimitern> rogpeppe: ok, forget about it :)
[13:22] <frankban> rogpeppe: is the Pinger included in controller facades?
[13:23] <rogpeppe> frankban: that's what http://reviews.vapour.ws/r/5458 is fixing
[13:23] <dimitern> rogpeppe: in this case, I tend to agree with you - if it was used in more than one place, then it'll be different
[13:23] <rogpeppe> dimitern: thanks
[13:24] <frankban> rogpeppe: it's not listed in the facades after login
[13:24] <rogpeppe> frankban: hmm, it should be
[13:24] <frankban> rogpeppe: http://pastebin.ubuntu.com/23064485/
[13:25] <rogpeppe> frankban: that's having bootstrapped with this branch?
[13:25] <frankban> rogpeppe: yes, I can try again
[13:25] <rogpeppe> frankban: let me just check the code again
[13:26] <rogpeppe> frankban: ah!
[13:27] <rogpeppe> frankban: ok, my fault
[13:27] <frankban> useful QA for the win
[13:27] <rogpeppe> frankban: it allows the call but i didn't change the isControllerFacade function
[13:27] <frankban> yes, that was my impression
[13:27] <rogpeppe> frankban: i thought i was doing a better thing there :)
[13:27] <rogpeppe> frankban: +1
[13:30] <frankban> rogpeppe: seems updated now right
[13:30] <frankban> ?
[13:31] <voidspace> dimitern: I can confirm that I can bootstrap with your branch, but not with master, with the disable ipv6 flag in place
[13:31] <rogpeppe> frankban: no, not yet - i'm just running some tests
[13:31] <dimitern> voidspace: thanks for confirming!
[13:31] <frankban> rogpeppe: ok ping me
[13:32] <voidspace> rick_h_: 1:1 ?
[13:32] <rick_h_> voidspace: sorry, omw
[13:35] <rogpeppe> frankban: updated now
[13:47] <rogpeppe> frankban: please ping me when you've QA'd and I'll start the branch landing
[13:52] <frankban> rogpeppe: sure on call now
[13:52] <rogpeppe> frankban: ok
[13:53] <rogpeppe> dimitern: FWIW i've just pushed up a "convenience API" package to hopefully make it easier to make ad-hoc connections to the juju API: github.com/rogpeppe/misc/jujuconn
[13:53] <rogpeppe> dimitern: i haven't actually run the code yet though :)
[13:54] <rogpeppe> dimitern: as i'm on a train so can't bootstrap a juju instance to play with
[13:54] <dimitern> rogpeppe: awesome! thank you, I'll have a look and try it
[14:00] <rick_h_> voidspace natefinch  ping for standup
[14:00] <rick_h_> dimitern: ^
[14:06] <voidspace> rick_h_: sorry
[14:07] <frankban> rogpeppe: bootstrapping again
[14:07] <rogpeppe> frankban: ta
[14:09] <natefinch> sinzui, mgz: how do I rdp to an azure machine started by CI? There's a "connect" button that gives me RDP info, but my rdp client doesn't ever connect... not sure if I need to open a port on the vm or vpn in somewhere or something
[14:09] <dimitern> voidspace: please link your PR to the card
[14:09] <sinzui> natefinch: no idea. we have never done that
[14:09] <voidspace> dimitern: kk
[14:10] <mgz> natefinch: I've never done it with azure, only our maas where we can supply our rdp cert to maas
[14:11] <dimitern> voidspace: in the "Add External Link" section, first field, please
[14:11] <frankban> rogpeppe, dimitern: QA ok, published instructions at http://reviews.vapour.ws/r/5458/
[14:12] <voidspace> dimitern: ah, ok
[14:12] <dimitern> :) it'll become second nature very soon, not trying to be a kanban nazi
[14:12] <voidspace> dimitern: done
[14:12] <dimitern> frankban: awesome! thanks for sharing
[14:12] <rogpeppe> frankban: ta!
[14:13] <rogpeppe> frankban: have you destroyed the controller already?
[14:13] <frankban> rogpeppe: no
[14:13] <rogpeppe> frankban: perhaps you could test this program for me (one mo as i write it :-])
[14:14] <dimitern> voidspace: ta!
[14:16] <rogpeppe> frankban: http://paste.ubuntu.com/23064622/
[14:16] <rogpeppe> frankban: (you'll need to go get the jujuconn package)
[14:16] <rogpeppe> frankban: it assumes that it's the current controller
[14:18] <frankban> rogpeppe: http://paste.ubuntu.com/23064626/
[14:18] <rogpeppe> frankban: awesome!
[14:18] <rogpeppe> frankban: thanks
[14:18] <rogpeppe> frankban: always nice when code works first time
[14:18] <rogpeppe> frankban: i wonder if you've got an old controller going that you can check to see if it fails...
[14:26] <dimitern> voidspace: I'm QA-ing your fix now on maas 1.9 and a node with a bond and 3 vlans
[14:28] <babbageclunk> dimitern: stupid question - how do I bootstrap with trace logging?
[14:29] <dimitern> babbageclunk: I don't think you can easily do that
[14:30] <babbageclunk> dimitern: :(
[14:30] <dimitern> babbageclunk: passing --debug to bootstrap gives you debug logging, while setting logging-config='<root>=TRACE' inside the bootstrap config will give you trace logging *later*
[14:30] <dimitern> babbageclunk: there was a way though.. let me try to remember
[14:31] <babbageclunk> dimitern: Hmm - actually logging-config='<root>=TRACE' might do it.
[14:31] <babbageclunk> dimitern: I mean, might do what I want
[14:32] <dimitern> babbageclunk: try exporting both JUJU_LOGGING_CONFIG and JUJU_STARTUP_LOGGING_CONFIG (to '<root>=TRACE') before running bootstrap
[14:32] <dimitern> babbageclunk: that's what I found gives you the most verbose initial logging
[14:33] <dimitern> lazyPower has a nice gist about it actually :) https://gist.github.com/chuckbutler/753ff6b88e2220b7a10a
[14:40] <babbageclunk> dimitern: my problem was happening late enough that just the logging-config was enough, thanks! I just couldn't find or remember the exact syntax.
[14:42] <dimitern> voidspace: LGTM + QA OK
[14:42] <dimitern> babbageclunk: nice ;)
[14:53] <babbageclunk> dimitern: The API requests from my worker are failing with `unknown object type "MachineUpdater"`. Is there another place I need to register my facade? I've added it to allfacades and have a RegisterStandardFacade call.
[14:54] <dimitern> babbageclunk: yes, let me have a look where it was
[14:54] <dimitern> babbageclunk: api/facadeversions.go and apiserver/allfacades.go need updating
[14:56] <natefinch> two line log output change anyone? http://reviews.vapour.ws/r/5461/
[14:57] <babbageclunk> dimitern: facadeversions!
[14:57] <dimitern> natefinch: LGTM, thanks for this - I remember doing something similar some time ago to debug simplestreams
[14:57] <babbageclunk> dimitern: Thanks
[14:58] <natefinch> dimitern: yeah... I realized when I saw that if statement, that we were throwing away everything *except* the expected errors.  Would have saved me hours of debugging if I'd seen the json unmarshal error for my simlpestreams data
[14:58] <natefinch> dimitern: thanks for the review
[14:59] <dimitern> :)
[15:54]  * rick_h_ goes for lunchables
[16:19] <redir> morning
[16:30] <mup> Bug #1614161 opened: Juju does not remember controller after register <ci> <jujuqa> <register> <regression> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1614161>
[16:32] <perrito666> redir: morning
[16:43] <redir> is it morning there too perrito666 ?
[16:43] <redir> I think you're like an hour off from me
[16:45] <perrito666> its 13:45
[16:49] <babbageclunk> Is it legit to add a method to an api facade without bumping the version number?
[16:49] <perrito666> no more
[16:51] <babbageclunk> perrito666: :( So I guess I need to learn how to bump versions tomorrow!
[16:58] <redir> or like 4
[18:13] <natefinch> anyone seen this error? 2016-08-17 15:00:25 ERROR juju.worker.diskmanager lsblk.go:116 error checking if "fd0" is in use: open /dev/fd0: no such device or address
[18:13] <perrito666> talk about user friendly: error: The requested backend 'zfs' isn't available on your system (missing tools).
[18:14] <perrito666> natefinch: something is reading your floppy disk
[18:14] <perrito666> :p
[18:14] <natefinch> perrito666: ahh, a less well known feature of azure VMs, I guess.
[18:59] <natefinch> sinzui: do we run the windows CI tests on maas/windows?  or just azure/windows?
[18:59] <sinzui> natefinch: we do have the tests for maas 1.9. I think they are only running for 1.25 since juju 2 supports azure with window
[19:01] <natefinch> sinzui: ok, just checking.  I can't for the life of me get RDP to work to an azure VM
[19:01] <sinzui> :(
[19:01] <natefinch> to be fair, I can't even ping the IP address
[19:02] <perrito666> natefinch: I am not sure windows will answer ping
[19:02] <perrito666> in a default config
[19:02] <natefinch> windows does answer ping... at least by default. no idea how azure's vms might handle it though
[19:03] <perrito666> natefinch: windows server?
[19:03] <natefinch> feh, dunno.  I think they'd be silly to turn it off.
[19:07] <rick_h_> natefinch: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-connect-logon/ anyone have portal access for the instance?
[19:08] <rick_h_> natefinch: that states you need to get a generated .rdp file with the ports/etc needed to talk to a specific instance: Clicking Connect creates and downloads a Remote Desktop Protocol file (.rdp file). Click Open to use this file.
[19:09] <natefinch> rick_h_: yeah, done that. The rdp file is just an IP address... which doesn't work for our VMs.  I'm trying to start a VM manually on azure (using the portal UI) to see if maybe something we're doing with the network is disabling RDP.
[19:11] <natefinch> rick_h_: yeah, I can connect to RDP from a manually created instance no problem
[19:20]  * rick_h_ grabs the boy from summer camp, biab
[19:30] <natefinch> mup: help
[19:30] <mup> natefinch: Run "help <cmdname>" for details on: bug, contrib, echo, help, infer, issue, login, poke, register, run, sendraw, sms
[19:31] <natefinch> bug 1614230
[19:31] <mup> Bug #1614230: can't remote desktop into windows machines created by juju  <windows> <juju-core:New> <https://launchpad.net/bugs/1614230>
[19:31] <natefinch> ahh good, mup was borken last night, glad it's back
[19:38] <natefinch> when in doubt... reboot
[19:39] <natefinch> perrito666: for the record, I can't ping the machine I brought up manually, even though RDP works (obviously ping != rdp, but still, good to know)
[19:42] <mup> Bug #1614230 opened: can't remote desktop into windows machines created by juju  <windows> <juju-core:New> <https://launchpad.net/bugs/1614230>
[19:43] <katco> does anyone have an opinion on whether it's reasonable for functions to open new API roots? shouldn't that be something that's passed in?
[19:54] <mup> Bug #1614239 opened: bootstrap-timeout ignored in --config <landscape> <juju-core:New> <https://launchpad.net/bugs/1614239>
[20:01] <natefinch> katco: I don't really know what you mean by opening an API root
[20:02] <katco> natefinch: https://github.com/juju/juju/blob/master/cmd/juju/application/deploy.go#L435
[20:02] <katco> natefinch: this, but like... at all levels of the call-stack
[20:02] <katco> natefinch: i.e. deploying bundles creates a new api root, deploying charms, resources and then anything else, etc.
[20:02] <katco> natefinch: it seems like we should just be opening 1 root at the top of the call graph and passing it through
[20:02] <natefinch> katco: I have no idea what that function actually does
[20:03] <katco> natefinch: but i'm not sure if we need to keep reopening it for some reason
[20:03] <natefinch> katco: probably copy pasta
[20:03] <mup> Bug #1614239 changed: bootstrap-timeout ignored in --config <landscape> <juju-core:New> <https://launchpad.net/bugs/1614239>
[20:03] <katco> natefinch: it's basically this: https://github.com/juju/juju/blob/master/api/interface.go#L156
[20:03] <katco> natefinch: returning that, i mean
[20:04] <natefinch> it seems like passing in an api.Connection is purely superior....
[20:04] <katco> natefinch: that's what i thought, but... the juju codebase does weird stuff sometimes and it's not always clear why
[20:06] <natefinch> katco: my guess is that probably most things that currently call NewAPIRoot, should be taking some subset of api.Connection, since that interface is clearly way too big
[20:06] <katco> natefinch: yeah, that's exactly where i'm headed
[20:06] <natefinch> lol // This first block of methods is pretty close to a sane Connection interface.
[20:06] <katco> natefinch: but first, need to change everything so it's not constructing new connections all over the place
[20:07] <katco> natefinch: all of this so i can write an actual unit test
[20:07] <natefinch> heh
[20:10] <natefinch> I just had a brilliant idea... I can cross compile test binaries from my linux desktop and fling them onto a windows machine to run.
[20:10] <natefinch> so I don't have to set up a dev environment on a windows machine just to run some tests
[20:11] <katco> +1
[20:12] <mup> Bug #1614239 opened: bootstrap-timeout ignored in --config <landscape> <juju-core:New> <https://launchpad.net/bugs/1614239>
[20:15] <thumper> cmars: ping
[20:15] <cmars> thumper, pong
[20:16] <thumper> cmars: I have a branch that modifies the signature of cmd Formatters, and I need to tweak romulus
[20:16] <thumper> but I notice that juju master is behind romulus master by 32 commits
[20:16] <thumper> is there anything that would break if we moved to latest?
[20:17] <cmars> thumper, only one way to find out
[20:17] <thumper> heh
[20:17] <thumper> ok
[20:17] <thumper> I'll just keep sloging forwards
[20:17] <cmars> thumper, i'd be happy to move juju/romulus/cmd/... commands over to cmd/juju/romulus or something
[20:18] <cmars> thumper, the coupling across these projects on juju/juju/cmd has been thorny
[20:18] <cmars> thumper, thoughts?
[20:18] <thumper> sounds good
[20:18] <thumper> but please wait until I'm done :)
[20:18] <cmars> thumper, ok!
[20:19] <cmars> thumper, in some cases, because of this coupling, it's difficult to land changes into juju/romulus with the bot
[20:19] <thumper> ah...
[20:19] <thumper> poos
[20:19] <cmars> thumper, because romulus lands based on tests against a revision of juju
[20:19] <thumper> yeah
[20:19] <thumper> fark
[20:19] <cmars> thumper, in those cases, ping me and i'll run the tests and just push teh green button
[20:19] <thumper> cmars: are you ok if I move the commands ?
[20:20] <cmars> thumper, sure, definitely
[20:20] <thumper> because I'll be messing with those
[20:20] <thumper> ok
[20:20]  * thumper adds to the list
[20:57] <mup> Bug #1614256 opened: TestClaimExpire fails with "leadership claim denied" <ci> <jujuqa> <leadership> <test-failure> <unit-tests> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1614256>
[20:59] <natefinch> rick_h_: FYI, figured out how to get in via RDP, needed to edit the security group the VM was a part of
[20:59] <rick_h_> natefinch: gotcha
[21:00]  * natefinch sups
[21:15] <mup> Bug #1346597 changed: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:Invalid> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1346597>
[21:15] <mup> Bug #1575895 changed: juju loses apt-http/s-proxy information if a model is deleted and a new one created <add-model> <juju-release-support> <landscape> <rc1> <usability> <juju-core:Invalid> <https://launchpad.net/bugs/1575895>
[21:43] <mup> Bug #1574963 changed: juju2 lxd launch hostname reverse lookup inconsistent <landscape> <cloud-images:New> <juju-core:Triaged> <cloud-init (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574963>
[22:24] <redir> wallyworld: available for badgering?
[22:24] <wallyworld> ferreting perhaps?
[22:24] <redir> general rodentry
[22:24] <wallyworld> now you're talking
[22:24] <redir> standup HO?
[22:24] <wallyworld> standup ho?
[22:25] <redir> hangout
[22:25] <redir> in stand-up hangout?
[22:35] <thumper> cmars: https://github.com/juju/romulus/pull/61
[22:40] <cmars> thumper, ok, cool. do you have the corresponding juju/juju branch for this yet?
[22:40] <thumper> working on it
[22:40] <thumper> I'll land in order
[22:40] <thumper> ffs
[22:40] <thumper> I don't want to say this
[22:41] <thumper> but wallyworld was right
[22:44] <wallyworld> yay!!!!!!!
[22:45] <anastasiamac> now u've done it, thumper \o/
[22:48] <wallyworld> must. not. say. I TOLD YOU SO :-D :-D
[22:52] <thumper> cmars: updated romulus branch for test depds
[22:52] <cmars> thumper, thx
[22:55] <thumper> damn it
[22:55]  * thumper headdesks
[23:15] <thumper> cmars: I'm making a dedicated branch for the romulus commands
[23:16] <cmars> thumper, sounds good
[23:26] <thumper> cmars: can you give a +1 to the romulus branch?
[23:26] <thumper> I'll need to refer to the new hash
[23:26] <cmars> thumper, ah, right. sure thing
[23:27] <cmars> thumper, go ahead and try $$merge$$
[23:27] <thumper> ta
[23:33] <thumper> cmars: https://github.com/juju/juju/pull/6017
[23:34] <thumper> cmars: it is very boring :)
[23:36] <cmars> thumper, looks good.. i'd like to do some QA on this branch, shouldn't take too long
[23:38] <menn0> thumper: happy fun times!!! http://reviews.vapour.ws/r/5465/
[23:38] <thumper> cmars: ok
[23:39] <redir> mmm so bootstrapping a controller in aws/us-west-1 then adding a model in us-east-1 should there be anything alive in us-east-1?
[23:42] <thumper> menn0: shpiit
[23:42] <thumper> or shipit
[23:42] <natefinch> anastasiamac: invalidating my bugs, eh?
[23:43] <thumper> cmars: are you just testing that the commands are still there?
[23:43] <thumper> cmars: what exactly are you QAing?
[23:44] <redir> wallyworld: doesn't seem that creating a new model in another region actually creates anything in that region.
[23:44] <redir> wallyworld: so asking the model for it's current region might not do what we want.
[23:45] <wallyworld> i haven't tried myself yet
[23:47] <anastasiamac> natefinch: according to axw, there is a config u need to do on ur environment ;)
[23:48] <natefinch> anastasiamac: he said "use juju run" which is not really valid, since that means if juju is broken, you can't access the machine to figure out why juju is broken
[23:50] <axw> natefinch: that was how you can do it now, not what I'm saying is the ideal way
[23:50] <anastasiamac> natefinch: feel free to triage it differently.. first step is juju-independent tho :)
[23:50] <axw> it's not invalid tho
[23:50] <axw> I think we should make it easier/better
[23:51] <axw> not sure what to do about the password
[23:51] <natefinch> axw: good point about the password.  not sure.  wasn't there a spec somewhere about keeping secrets in juju?
[23:52] <axw> natefinch: jam replied to a thread on the list about secrets, I don't know about a spec
[23:52] <axw> redir: I need to go help with kids, if there's an issue with --region could you let me know how to repro and I'll look into it?
[23:53] <menn0> wallyworld, thumper, axw: I'm thinking about proposing this: http://paste.ubuntu.com/23065898/
[23:54] <menn0> wallyworld, thumper, axw: is this ok or would you prefer these were kept as debug/trace
[23:54] <axw> menn0: perhaps tracef, errorf is dumb tho
[23:54] <thumper> menn0: is it ever useful?
[23:54] <thumper> tracef
[23:54] <thumper> I agree with axw
[23:55] <menn0> thumper: the only one that could be useful to keep is the on in destroyHostOps
[23:55] <menn0> IMO
[23:55] <menn0> i'll just make them trace