[00:52] <wallyworld> anastasiamac: why did you tag 1612645 as a blocker?
[00:53] <anastasiamac> wallyworld: for 1.25 not master
[00:54] <wallyworld> ok
[00:54] <anastasiamac> wallyworld: it's not a critical on master so should not block it
[00:54] <wallyworld> we haven't really considered adding a new region being a blocker before
[00:55] <wallyworld> there's plenty of other regions to choose from in the interim
[00:55] <wallyworld> i guess it's 1.25 so it doesn't matter so much
[00:57] <anastasiamac> wallyworld: i've added based on comments
[00:58] <anastasiamac> wallyworld: and precedence is not a great driver when we strive to improve :D
[00:59] <axw> menn0: which HO?
[00:59] <wallyworld> i guess my definition of what a blocker is is different
[00:59] <menn0> axw: good question. let's use the standup one
[01:00] <menn0> wallyworld: standup hangout?
[01:16] <anastasiamac> wallyworld: plz get a chance to review https://github.com/juju/juju/pull/5869
[01:16] <thumper-dogwalk> menn0: all done chatting?
[01:17] <menn0> thumper: yep
[01:17] <thumper> anything problematic?
[01:17] <wallyworld> ok
[01:18] <menn0> thumper: nope all good actually - I'm removing work from the MM completion doc as the way the config stuff was done works well with MM
[01:19] <thumper> coolio
[01:40] <wallyworld> anastasiamac: one thing to add to tech debt sprint - finish complete removal of env storage, including http://reviews.vapour.ws/r/4303/
[01:47] <anastasiamac> wallyworld: pleaae bug it up and add `tech-debt` tag. the plan is to tackle that list
[01:47] <axw> wallyworld: FYI I've just verified that destroy-controller ends up cleaning juju from a workload machine
[01:47] <axw> with my change
[01:47] <wallyworld> axw: awesome thanks
[01:47] <wallyworld> anastasiamac: there may be a bug already, i'll try and find it
[01:48] <anastasiamac> wallyworld: \o/ even better
[01:49] <axw> wallyworld anastasiamac: if there's any chance that the MAAS provider could be updated to use tags instead of storage at the same time that would be great
[01:49] <wallyworld> axw: i think maas 2.0 can do that but not 1.9 :-(
[01:49] <axw> probably out of scope though
[01:50] <anastasiamac> axw: ^^ would b awesome to bug it up and tag as 'tech-debt' :D altho, I m not sure what our stance is with maas 1.9.. probably criticals only too?..
[01:50] <axw> wallyworld: we can keep it for just 1.9
[01:50] <wallyworld> that is true. in that case, we should do it
[01:50] <axw> anastasiamac: yeah not sure if there's a bug, will have a look
[01:50] <wallyworld> now that we have 2 provider implementations
[01:51] <axw> anastasiamac: covered by this I think: https://bugs.launchpad.net/juju-core/+bug/1611267
[01:51] <mup> Bug #1611267: maas:  kill-controller should take down known hosted models <juju-core:Triaged> <https://launchpad.net/bugs/1611267>
[01:51] <anastasiamac> axw: k. i'll a tech-debt card
[01:51] <anastasiamac> tag*
[01:52] <axw> anastasiamac: I've  just tagged it
[01:52] <anastasiamac> axw: u r awesome
[01:53] <anastasiamac> axw: of course, u'd b even more awesomer (!) if u joined the sprint that would fix it :D
[01:53] <axw> anastasiamac: is it going to be in Perth? ;p
[01:54] <anastasiamac> axw: :) dunno yet. i need to talk to HR/sprint org admins... unlikely tho :)
[01:54] <anastasiamac> axw: if it was, do i have ur word, u'd join?
[01:54] <axw> anastasiamac: tongue is in cheek, nobody wants to go to perth
[01:55] <anastasiamac> axw: i can think of at least couple of ppl who'd b keen and several others are not attached to a location :) so everything is possible...
[01:56] <axw> oh true, forgot about andy :p
[01:56] <anastasiamac> axw: :) that's one of these ppl \o/
[02:34] <axw> wallyworld: the more I dive into azure auth, I don't think we're going to be able to automatically generate creds. AFAICS, authentication with username/password must be interactive
[02:34] <wallyworld> awesome :-(
[02:34] <axw> wallyworld: that would be OK for bootstrap, but not for adding creds afterwards
[02:34] <axw> because you might not have custom azure code in the client
[02:35] <axw> wallyworld: I think the best we're going to be able to do for now is a separate plugin/tool
[02:35] <wallyworld> we'll need to identify the gaps and talk to the ms guys maybe
[02:35] <axw> yep
[02:35] <wallyworld> stop gap would be good, that can probably happen next week
[02:51] <blahdeblah> quick Q: juju 1.x has "api-endpoint" and "api-info" - juju 2.x doesn't.  How should a client program work out the correct API endpoint of the controller under 2.x?
[02:52] <blahdeblah> anastasiamac: ^ That's the root cause of the issue we were talking about earlier
[02:53] <anastasiamac> blahdeblah: tvm! thumper:wallyworld:axw:menn0: ^^
[02:54] <blahdeblah> anastasiamac: My issue with juju-deployer on 2.x, that is.  I don't think this is going to help you prioritise or fix any bugs. :-)
[02:55] <wallyworld> juju list-controllers
[02:55] <axw> blahdeblah: "juju show-controller" contains the list of addresses
[02:55] <axw> the first one in the list is the most recently used
[02:56] <anastasiamac> blahdeblah: i figured ;)
[02:56] <blahdeblah> axw: where "most recently used" == the one that juju switch will say is selected?
[02:57] <wallyworld> juju switch pertains to controller/model. most recently used refers to the api endpoints for a given controller
[02:58] <wallyworld> controller cluster
[02:58] <wallyworld> in an HA setup, there's more than one endpoint to choose from, they are rotated
[02:59] <blahdeblah> What about if you've got multiple client processes locally hitting multiple juju envs on different controllers?  Is there a way to reliably determine from the CLI which API endpoint you should hit for env X?
[03:01] <wallyworld> juju show-model will get the controller uuid
[03:01] <wallyworld> from there you can get the endpoints
[03:01] <wallyworld> not sure if there's a better way, would need to look into it
[03:04] <blahdeblah> wallyworld: that will do for now
[03:04] <blahdeblah> show-controller gives the uuid, so they can be compared
[03:04] <wallyworld> blahdeblah: it could be with the 2.x rework stuff has got harder in some areas, so would be good to know those pain points
[03:04] <wallyworld> raise a bug if you want it tracked etc
[03:05] <blahdeblah> wallyworld: yeah - that's the point of what I'm doing today; try to find where the gaps are in getting us ready for 2.x
[03:05] <wallyworld> hope you don't find too many :-)
[03:05] <blahdeblah> wallyworld: well, the big one is juju-deployer
[03:06] <wallyworld> i thought folks had been using that ok with the recent api changes to it
[03:06] <blahdeblah> well, I could be doing it wrong
[03:06] <wallyworld> i'm only going on hearsay, i've not used it
[03:06] <blahdeblah> I've just pulled down the trunk version of that + python-jujuclient, and it's definitely not working out of the box
[03:07] <wallyworld> there was an email to the list recently i think about it all being updated
[03:07] <wallyworld> not sure now though
[03:07]  * blahdeblah goes to find it
[03:07] <blahdeblah> Anyway, context for all of this is that in the conversations anastasiamac and I have been having, it has become evident that we'll need to have a 2.x story if we want our non-critical bugs fixed; so that's what I'm deep-diving into today.
[03:47] <menn0> thumper: https://github.com/juju/juju/pull/5992 pls
[04:09] <mup> Bug #1613150 opened: migrationmaster continually restarts once a model has migrated back to a controller <juju-core:New for menno.smits> <https://launchpad.net/bugs/1613150>
[04:18] <mup> Bug #1613150 changed: migrationmaster continually restarts once a model has migrated back to a controller <juju-core:New for menno.smits> <https://launchpad.net/bugs/1613150>
[04:24] <mup> Bug #1613150 opened: migrationmaster continually restarts once a model has migrated back to a controller <juju-core:New for menno.smits> <https://launchpad.net/bugs/1613150>
[04:36] <menn0> thumper: I was surprised to find the user access constants in core/description too
[04:36] <thumper> :(
[04:36] <blahdeblah> Do you folks have any API-level doc for juju2?  I'm waist-deep in the python-jujuclient code, and all I can work out is that its getting refusals from the API server based on the parameters its constructing.  But I have no idea what those should be.
[04:36] <menn0> thumper: i think someone is misunderstanding what core/description is for
[04:36] <thumper> yeah
[04:37] <thumper> blahdeblah: which call?
[04:37] <blahdeblah> thumper: login
[04:38] <thumper> which params do you have questions about?
[04:38] <thumper> I'm not clear on the macaroon stuff
[04:40] <blahdeblah> thumper: All of them?  I suppose I should just read the source and find out where the error is originating and infer back from there, but go is almost as unreadable as lisp to me...
[04:40] <blahdeblah> thumper: Here's what's happening: https://pastebin.canonical.com/163111/
[04:40] <blahdeblah> Line 8 is the params its sending on the RPC call
[04:40] <blahdeblah> I hacked it to remove the password, because the Canonistack controller doesn't seem to want one.
[04:41] <blahdeblah> But it gives the same response with or without a password
[04:41] <thumper> blahdeblah: you need to prefix "user-" to the auth-tag
[04:41] <thumper> it is expecting a stringified tag,
[04:41] <blahdeblah> hang on - I just realised that
[04:41] <thumper> and user tags all need "user-"
[04:42] <blahdeblah> and I had fixed it, but not pushed the code to my live copy
[04:42]  * blahdeblah tries again
[04:42] <blahdeblah> OK - here's the result this time: https://pastebin.canonical.com/163112/
[04:44] <blahdeblah> thumper: and if I include 'credentials' (which is None), I get the same result
[04:47] <blahdeblah> I really wonder whether this is due to the Canonistack controller running a hacked authentication package. <-- wallyworld, any thoughts?
[04:48] <thumper> blahdeblah: it'll be expecting some creds now
[04:48] <thumper> not sure about the macaroon bits...
[04:48] <blahdeblah> What are "the macaroon bits"?
[04:48] <thumper> password?
[04:49] <thumper> opaque credentials with magic HMAC chaining
[04:49] <blahdeblah> there's no password in ~/.local/share/juju/accounts.yaml
[04:49] <wallyworld> blahdeblah: i think you need to juju login
[04:50] <blahdeblah> So all of this was just another missing step? :-(
[04:50] <blahdeblah> wallyworld: where username == launchpad username?  Or launchpad email address?
[04:51] <blahdeblah> ERROR already logged in
[04:51] <wallyworld> hmmm, not sure in that case
[04:51] <wallyworld> uros will be online in  a couple of hours
[04:53] <blahdeblah> hmmm - pretty sure there was a login step actually, and it worked, because when I log out it removes the accounts.yaml entry for that controller
[04:54] <wallyworld> that seems correct
[04:56] <blahdeblah> OK, I might wait for Uros
[04:56] <blahdeblah> thanks
[04:58] <wallyworld> yeah, sorry, he'll know straight away what's wrong
[04:59] <veebers> Hmm, If I've added a user with permission 'write' and attempt to add a model and get this error, what might I be doing wrong? cmd supercommand.go:458 permission denied (unauthorized access)
[05:00] <veebers> I"m confident that it's passing --config authorized-keys="..."
[05:22] <veebers> menn0: Would you have any insight? ^^ user with write perms should be able to add a model right?
[05:23] <menn0> veebers: writer perms on the controller model?
[05:25] <veebers> menn0: hmm, I believe so, let me check the test code.
[05:25] <wallyworld> veebers: write only pertains to models
[05:26] <wallyworld> you need addmodel permission on controller to add models
[05:26] <wallyworld> controller permissions are login, addmodel, superuser
[05:26] <wallyworld> if that's ot in the release notes we'll need to fix them
[05:27] <veebers> wallyworld: ah ok, seems I'm going off old information (I'm resurrecting some old code of mine)
[05:28] <wallyworld> axw: if you had time, here's a small tweak to fix upgrade-juju http://reviews.vapour.ws/r/5433/ (main change was a few lines, but then tests...)
[05:28] <veebers> wallyworld: so this makes sense? juju add-user myusername --models testmode,controller --acl 'addmodel' -c controllername
[05:28] <veebers> err, testmode -> testmodel. Or does addmodel only pertain to controller and that will error?
[05:32] <wallyworld> veebers: i thin --models have been removed
[05:32] <wallyworld> and -acl is replaced by a positional arg
[05:32] <wallyworld> check the release notes
[05:34] <veebers> wallyworld: ack, will do. juju add-user --help lists --models as an arg btw
[05:34] <wallyworld> looks like another case of cli help out of date
[05:35] <wallyworld> assuming my memory has not failed me
[05:35] <veebers> wallyworld: which is the most up to date release notes? https://jujucharms.com/docs/devel/temp-release-notes or https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit# (or some third option)?
[05:36] <wallyworld> https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit
[05:36] <veebers> sweet cheers
[05:36] <wallyworld> i don't know about the jujucharms ones, not looked at them
[05:37] <axw> wallyworld: reviewed
[05:37] <wallyworld> ta
[05:40] <veebers> ugh, I'm really confused now. Trying to add-user with addmodel gives me: error: invalid model access permission "addmodel"
[05:40]  * veebers re-reads release notes incase he missed something
[05:42] <veebers> wallyworld: I can't see mention of any of "login, addmodel, superuser" in the release notes, perhaps like you say they need updating. Or perhaps that part hasn't landed yet (as per error I'm seeing)
[05:42] <wallyworld> veebers: it's in master, are you running from source?
[05:43] <veebers> wallyworld: I am, I pulled and rebuilt this morning. I'll re-pull now to confirm
[05:44] <wallyworld> veebers: i tested last week and it seemd to work ok
[05:44] <wallyworld> i used grant
[05:45] <wallyworld> after adding a user
[05:45] <veebers> wallyworld: hmm right, might be what I'm doing wrong (I'm trying to use add-user). Thanks I'll try that
[05:49] <wallyworld> veebers: i juest checked the code - adduser still has the --models but it shouldn't i don't think, i 'll need to check the spec. and you can only specify model permissions, not controller (by design). i think the model permssions are going away too, but i'll need to check to be sure
[05:49] <wallyworld> so add-user becomes just that - adds a user
[05:49] <wallyworld> then use grant afterwards
[05:51] <veebers> wallyworld: makes sense. When you do check can you confirm re: add-user changes (and using grant) as that'll need a change in the CI tests etc.
[05:52] <wallyworld> using grant will not change - that's the supported use case, give me a few minutes to check for the other bits
[05:58] <wallyworld> veebers: https://docs.google.com/document/d/15zwHWctS7WhNIzLNIeG_ly6udIVt_8wRlZTLFqJF-zY
[05:59] <wallyworld> axw: those 2 things fixed, ok to ship?
[06:00] <axw> wallyworld: ship it
[06:00] <wallyworld> ta
[06:01] <wallyworld> veebers: i added a card to our board to fix the add-user help text etc
[06:05] <veebers> wallyworld: sweet thanks
[06:05] <wallyworld> veebers: everything is now positional arguments, and if you leave off model, it assumes a controller permission
[06:07] <veebers> wallyworld: ack. I'll touchbase with my team to make sure this is known. It's possible it's just me thats out of date
[06:12] <rogpeppe1> menn0-afk: thanks for the review comments
[06:14] <rogpeppe> wallyworld: hiya
[06:14] <wallyworld> hi
[06:14] <rogpeppe> wallyworld: apparently i need approval from the tech board for this PR to land. any idea what the procedure is for that? http://reviews.vapour.ws/r/5428
[06:17] <wallyworld> rogpeppe: the PR seems like a reasonable goal to me. pop an email to john, menno, andrew, william just to highlight you want them to check it
[06:17] <rogpeppe> wallyworld: thanks.
[06:21] <wallyworld> rogpeppe: maybe cc juju-dev so everyone can see the discussion?
[06:21] <rogpeppe> wallyworld: ok
[06:21] <rogpeppe> wallyworld: but that means i have to write a much longer email... :)
[06:21] <rogpeppe> wallyworld: and not quite so frivolous :)
[06:21] <wallyworld> whatever works for you then :-) don't want to block
[06:22] <wallyworld> axw: we'll never want to make an api call to get more than just the defaut cloud tag? seems reasonable to return relevant details. maybe a CLI command may want that info to display?
[06:24] <axw> wallyworld: maybe, but we don't have a need for it now, so I don't want to guess how it should look any more. as it is, we can get hte default cloud name, and then the details of that cloud
[06:24] <axw> wallyworld: really I think we should be shuffling the cloud's Regions so that the default one (i.e. the controller's region) is at the front
[06:24] <axw> then we'd have all we need
[06:25] <rogpeppe> wallyworld: tbh it's kinda trivial; i think it's probably not worth the noise on juju-dev
[06:25] <axw> rogpeppe: probably should've emailed just you and frankban about that one
[06:25] <wallyworld> axw: agree with regions i think. i worry though about designing a chatty diestibuted api. gotta run to school picku, bbiab
[06:26] <rogpeppe> axw: have you actually done DestroyModels or are you waiting for me to do it?
[06:26] <axw> rogpeppe: I've done it, merging now
[06:26] <rogpeppe> axw: awesome, thanks!
[06:26] <axw> rogpeppe: https://github.com/juju/juju/pull/5991
[06:27] <axw> rogpeppe: I'm looking at creds now
[06:27] <rogpeppe> axw: if you have a moment or three, it would be great if you could take a look at http://reviews.vapour.ws/r/5428
[06:27] <axw> rogpeppe: ok
[06:41] <axw> rogpeppe: LGTM, please answer katco's issues - QA in particular is the big one
[06:41] <rogpeppe> axw: yeah
[06:42] <rogpeppe> axw: and i know for a fact that QA in one instance will fail - just working on fixing that nowq
[06:42] <rogpeppe> axw: 'cos the command-line tests don't actually test against the real API
[06:42] <rogpeppe> axw: for DestroyModel
[06:43] <rogpeppe> axw: the fix will require your DestroyModels that's being tested
[06:43] <axw> rogpeppe: indeed, we should probably have a featuretest
[06:44] <rogpeppe> axw: that's better than just making the command-line test use the actual API?
[06:44] <axw> rogpeppe: that's the way we're going, yeah. at least one "happy path" test in featuretest, the rest are unit tests
[06:46] <rogpeppe> axw: ok
[06:47] <rogpeppe> axw: i worry that that's not really enough (is one "happy path" good enough to actually determine that all the variations work?), but fair enough
[06:52] <axw> rogpeppe: I think your message before indicates you are, but can you confirm that you're happy with this? http://reviews.vapour.ws/r/5435/diff/#
[06:52] <rogpeppe> axw: looking
[06:54] <rogpeppe> axw: looks fine to me
[06:55] <axw> rogpeppe: ta
[06:55] <rogpeppe> axw: glad to see the back of a bulk API call :)
[06:55] <axw> shh :)
[06:55]  * rogpeppe still thinks that the bulk API call thing has been the biggest waste of time ever
[06:56] <axw> rogpeppe: for the creds issue, I'm thinking of doing this: introducing a credential tag which includes owner, cloud, and cred name. then I'll have the Cloud.Credentials method return the set of credential tags that a user has access to (possibly still with a cloud filter)
[06:57] <axw> rogpeppe: then I'll update CreateModel to take a credential tag
[07:00] <rogpeppe> axw: that seems reasonable to me i think
[07:00] <rogpeppe> axw: CreateModel already takes a CloudCredential field
[07:00] <rogpeppe> axw: i'm wondering what the best ordering of owner, cloud and cred name is
[07:01] <rogpeppe> axw: maybe it should be cloud/owner/cred-name
[07:02] <axw> rogpeppe: I'm not sure. I had started on owner/cloud/cred, but *shrug*
[07:02] <axw> rogpeppe: bbs, school pickup
[07:02] <rogpeppe> axw: k
[07:02] <rogpeppe> axw: are there any existing precedents
[07:03] <rogpeppe> ?
[07:16] <blahdeblah> So is there any way to get juju 2.x to tell me where the problem is in my bundle that it's saying is invalid?
[07:26] <frankban|afk> in
[07:26] <frankban> morning al
[07:26] <frankban> all
[07:31] <rogpeppe> axw: good point about ControllerTag - i didn't know about that
[07:32] <rogpeppe> axw: i think probably the API should be changed to use that
[07:40] <menn0> rogpeppe: no worries
[07:43] <menn0> wallyworld: I'm seeing uploadSuite.TestMockBuildTools failing consistently on my machine but only under Go 1.7 (and in CI it seems)
[07:43] <menn0> wallyworld: looks to be related to your recent changes
[07:44] <wallyworld> menn0: axw mentioned there could be a checksum different between 1.6 and 1.7
[07:44] <wallyworld> so maybe if the algorithm is different our test values need to be changed
[07:45] <menn0> wallyworld: the checksum and length are different
[07:45] <wallyworld> awesome, so we have a 1.6 vs 1.7 issue
[07:45] <menn0> the tools size is 132 under Go 1.7 and 127 under 1.6
[07:46] <rogpeppe> menn0: do you know if the controller tag UUID is different from the controller model tag's UUID, by any chance?
[07:46] <menn0> wallyworld: which probably makes sense if it's being built with a different Go version right?
[07:46] <wallyworld> yeah. can you send me the test failure?
[07:46] <wallyworld> rogpeppe: they are supposed to be but not yet IIRC
[07:47] <menn0> rogpeppe: AFAIK, they're always the same, but I think there was talk of making them different. wallyworld or axw might remember?
[07:47] <wallyworld> we need to fix that
[07:47] <wallyworld> on the todo list
[07:47] <wallyworld> test changes will suck
[07:47] <rogpeppe> menn0: ah, ok, that's good to know
[07:47] <rogpeppe> menn0: i guess the login API should return a controller tag not a model tag for the controller then
[07:48] <menn0> rogpeppe: yes, that seems right
[07:48] <menn0> wallyworld: here's the test failure: http://paste.ubuntu.com/23057634/
[07:49] <menn0> wallyworld: it also appears to have failed for me during a CI merge run ... although there's no details of the actual failure.
[07:49] <menn0> http://juju-ci.vapour.ws:8080/job/github-merge-juju/8759/artifact/artifacts/trusty-out.log
[07:49] <menn0> this is why I started looking
[07:50] <menn0> that code has zero to do with the change I'm making
[07:50] <wallyworld> menn0: i see that one intermittently even on 1.6, NFI
[07:50] <wallyworld> you can go to environs/sync and no errors
[07:50] <menn0> wallyworld: perhaps the compiler output isn't completely predictable?
[07:50] <wallyworld> run tests from a level higher using ./... and intermittent
[07:51] <menn0> wallyworld: well it's failing for me consistently under 1.7. not sure if it's the same issue or not though.
[07:51] <wallyworld> menn0: i think that mock build tools test is bogus anywat
[07:51] <wallyworld> i have no idea why we are relying on specific compiler behaviour
[07:52] <wallyworld> surely the test can be rewritten
[07:52] <menn0> wallyworld: yeah, seems dumb
[07:52] <wallyworld> i'll try and look tomorrow
[07:55] <menn0> wallyworld: so that test doesn't actually compile anything. it just creates a tarball with a fake jujud in it.
[07:55] <menn0> wallyworld: so it's not compiler specific
[07:56] <menn0> wallyworld: I bet the tar or gzip implementation has changed in 1.7 though
[07:56] <wallyworld> yeah, something has changed
[07:56] <menn0> wallyworld: the test shouldn't be comparing the size or hash ... that's bogus
[07:56] <wallyworld> +100000
[07:57] <axw> rogpeppe: no precedent that's relevant AFAIK
[07:57] <menn0> wallyworld: what it /could/ do is extract the contents and make sure it's as expected. that is 100% predictable.
[07:57] <wallyworld> agreed
[07:57] <wallyworld> that's what it should have done
[07:57] <rogpeppe> axw: i guess my inclination is to keep user and name together as they're together in other places too
[07:57] <menn0> wallyworld: I'll tackle it now if you like.
[07:58] <menn0> wallyworld:  easy fix
[07:58] <rogpeppe> axw: so user/name/cloud or cloud/user/name but not user/cloud/name
[07:58] <axw> rogpeppe: sure, sounds fine to me
[07:58] <wallyworld> menn0: if you want, ok, thanks, i'm just tidying up some other stuff, sorry
[07:58] <menn0> wallyworld: np, I've got it
[07:59] <axw> rogpeppe: I think I'll go for cloud/user/name. on the CLI, I'll make it so you can refer to credentials when adding a model with either "name" (short hand for current-user/name), or user/name
[07:59] <axw> rogpeppe: (and the code will tack on the cloud name when crafting the tag)
[08:00] <rogpeppe> axw: is that in the API or just on the command line?
[08:07] <mup> Bug #1613200 opened: TestMockBuildTools fails intermittently under Go 1.6 and always under 1.7 <juju-core:New for menno.smits> <https://launchpad.net/bugs/1613200>
[08:08] <rogpeppe> wallyworld, axw: speaking of tests failing under different Go versions, apiserver/provisioner tests fail under Go tip
[08:09] <wallyworld> yeah, that's been the case for a while :-(
[08:09] <rogpeppe> wallyworld: *sigh*
[08:09]  * rogpeppe goes off to fix it
[08:10] <wallyworld> hasn't been a huge issue since most are still running go 1.6
[08:10] <rogpeppe> wallyworld: i think it's very useful to be able to run tip
[08:10] <wallyworld> those running tip can scratch their own itch :-)
[08:10] <rogpeppe> wallyworld: because it means we can proactively get fixes into Go before they actually break us later
[08:10] <wallyworld> true
[08:11] <rogpeppe> wallyworld: and usually the test failures under tip point to smelly tests rather than bad Go changes
[08:24] <rogpeppe> wallyworld: ha, in apiserver/provisioner, one of the failing tests (TestProvisioningInfoWithStorage) passes in Go 1.6 when run as part of the whole test suite but not when run on its own
[08:25] <rogpeppe> wallyworld: the failure is because of image metadata - do you think there might be a mock failure or something?
[08:26] <rogpeppe> wallyworld: it looks like it's actually managing to get real image metadata from the network
[08:29] <anastasiamac> rogpeppe: it should b mocked out \o/ please open a bug and tag it with `tech-debt`
[08:30] <menn0> wallyworld, anastasiamac: fix for TestMockBuildTools - http://reviews.vapour.ws/r/5436/
[08:31] <menn0> wallyworld, anastasiamac: no rush. I'm about to EOD. feel free to merge if you're happy with it.
[08:43] <axw> wallyworld rogpeppe: https://github.com/juju/names/pull/70 -- PTAL if you have a moment
[08:52] <rogpeppe> axw: reviewed
[08:52] <axw> rogpeppe: ta
[08:55] <babbageclunk> dimitern: no fwereade still :(
[08:57] <rogpeppe> wallyworld: yeah, that test is definitely dialing out to 91.189.88.141
[08:57] <rogpeppe> anyone know what mechanism is supposed to stop test code from dialing out to the ubuntu cloud images server?
[08:59] <wallyworld> rogpeppe: sorry, was having dinner. john found te same root cause a while back. i think tge issue is that patching the DefaultImaheURL to "" fails
[08:59] <rogpeppe> wallyworld: ok, thanks
[09:00] <rogpeppe> wallyworld: DefaultImageURL doesn't seem to exist as a word in the juju sources
[09:01] <wallyworld> it's something like that, i can look
[09:01] <rogpeppe> wallyworld: do you mean DefaultUbuntuBaseURL ?
[09:01] <wallyworld> probs, let me check
[09:01] <wallyworld> that and also DefaultJujuBaseURL
[09:02] <wallyworld> rogpeppe: there's also this function PatchOfficialDataSources()
[09:06] <rogpeppe> wallyworld: well, it looks like withoutControllerSuite doesn't call that function
[09:06] <wallyworld> joy
[09:06] <rogpeppe> wallyworld: i don't understand why it only fails sometimes though
[09:07] <wallyworld> me either, but i haven't looked too deeply into it
[09:14] <frobware> babbageclunk: ping - can we sync/HO?
[09:14] <babbageclunk> frobware: sure
[09:14] <babbageclunk> frobware: where?
[09:15] <babbageclunk> frobware: just in core?
[09:15] <frobware> ok
[09:51] <rogpeppe> wallyworld: ok, i've uncovered the root of the issue - our "prevent outgoing calls" hack doesn't work under Go 1.7: https://play.golang.org/p/P4L5nQTsBp
[09:51] <rogpeppe> wallyworld: that program prints "ok" which it shouldn't
[09:57] <wallyworld> actually, that rings a bell from when john looked at it
[09:57] <wallyworld> obviously no one has looked into how to fix
[09:59] <rogpeppe> wallyworld: it's quite easy to fix
[09:59] <wallyworld> awesome
[09:59] <rogpeppe> wallyworld: in Go 1.7 and later, DialContext overrides Dial
[10:00] <rogpeppe> wallyworld: and DialContext is set in DefaultTransport by defailt
[10:00] <rogpeppe> wallyworld: so we're setting Dial but DialContext is overriding it
[10:00] <wallyworld> ah, i see, makes sense
[10:00] <rogpeppe> wallyworld: so we need to set DialContext too
[10:01] <wallyworld> maybe i should try Go 1.7, i guess there's a PPA somewhere
[10:08] <frobware> dimitern: ping - can we sync?
[10:09] <dimitern> frobware: hey, welcome back :) sure - standup HO?
[10:09] <frobware> yep
[10:53] <mwhudson> wallyworld: ppa:gophers/archive!
[10:53] <rogpeppe> wallyworld, axw, dimitern: here's a fix for the broken-in-go1.7 outgoing-connection-checking logic: https://github.com/juju/utils/pull/233
[10:57] <rogpeppe> i'm thinking that it might be better to make that logic panic when trying to access an external address
[10:58] <rogpeppe> rather than just returning an error
[11:21] <rogpeppe> mwhudson: fancy a little review that might even be a tad enlightening (i found out something i didn't know) https://github.com/juju/utils/pull/233
[11:21] <rogpeppe> ?
[11:22] <rogpeppe> mgz, katco, mattyw, dooferlad: ^
[11:24] <mgz> rogpeppe: sure
[11:24] <rogpeppe> mgz: ta!
[11:26] <mattyw> rogpeppe, can't see anything wrong with that, lgtm
[11:27] <rogpeppe> mattyw: tyvm
[11:31] <mgz> rogpeppe: change makes sense to me, my only real complaint is neither the implementions of the install... functions nor their call sites actually say they're about preventing test outbound network access
[11:32] <rogpeppe> mgz: yeah, i've just added a comment
[11:32] <mgz> with that then go ahead
[11:33] <dimitern> rogpeppe: ship it!
[11:33] <rogpeppe> mgz, dimitern, wallyworld: thanks
[11:34] <wallyworld> rogpeppe: np. ensure you add testing notes as per new review policy
[11:35] <wallyworld> thanks fir biting the bullet and fixing
[11:36] <rogpeppe> wallyworld: for such a simple low level fix, i think that requiring a QA from the top level of Juju is overkill tbh
[11:36] <wallyworld> rogpeppe: really? changing how http works could break everything. and it is the new policy for core
[11:36] <rogpeppe> wallyworld: i'll certainly QA when this version of utils gets incorporated as a dependency into juju-core
[11:37] <wallyworld> oh right
[11:37] <wallyworld> it's utils, sorry
[11:37] <wallyworld> yeah, when core deps get updated, test then
[11:37] <wallyworld> jumped the gun sorry
[11:37] <rogpeppe> wallyworld: np
[12:05] <mup> Bug #1613262 opened: simplestreams: error message can hide real error <juju-core:New> <https://launchpad.net/bugs/1613262>
[12:11] <mup> Bug #1613262 changed: simplestreams: error message can hide real error <juju-core:New> <https://launchpad.net/bugs/1613262>
[12:26] <mup> Bug #1613262 opened: simplestreams: error message can hide real error <juju-core:New> <https://launchpad.net/bugs/1613262>
[12:26] <dimitern> rick_h_: ping
[12:28] <rick_h_> dimitern: pong
[12:29] <dimitern> rick_h_: hey, frobware and me would like to have a chat re future work/planning/breakdown - when will be a good time for you? it shouldn't take more than ~20m
[12:29] <rick_h_> dimitern: any time, welcome back frobware
[12:30] <rick_h_> dimitern: frobware let me know when works for you and will join in the standup room?
[12:30] <dimitern> rick_h_, frobware: top of the hour? i.e. in ~30m?
[12:31] <rick_h_> dimitern: wfm
[12:31] <dimitern> rick_h_: ok, cheers
[12:33] <dimitern> frobware: ^^
[12:49] <frobware> dimitern, rick_h_: yep good for me
[12:54] <rogpeppe> i've updated http://reviews.vapour.ws/r/5428/ with QA instructions (wasn't quite sure where I should have put them). if someone could QA it for me, that would be great.
[13:27] <frobware> rick_h_: if you time to jump back in before standup that would be useful
[13:34] <rick_h_> frobware: sure thing, I'm back sorry
[13:52] <frobware> rick_h_, dimitern: the google part of the net has disappeared for me
[13:52] <rick_h_> frobware: google knows all, you were thinking bad thoughts :P
[14:01] <rick_h_> voidspace: ping for standup
[14:02] <voidspace> rick_h_: omw
[14:13] <natefinch> sinzui, mgz: seems like we still have a windows error in CI.  I think I need to do a run with --keep-env, but the scripts don't support that yet.  I tried looking for where I should put support for that, but it's a little twisty. Give me a hint where to look?
[14:17] <mgz> natefinch: the failing test seems like just a standard deploy job? so we can add --keep-env there fine?
[14:17] <sinzui> natefinch: all CI scripts support --keep-env
[14:18] <mgz> natefinch: do you want us to kick off a run with that?
[14:20] <natefinch> mgz, sinzui: oh, sorry, looking at notes it was constraints, but I don't need that anymore
[14:21] <sinzui> natefinch: yeah, contraints remain a gap. Which do you need?
[14:25] <natefinch> sinzui: it's ok. it was only as a workaround for the azure thing that andrew already fixed.  So I should be all set now
[14:25] <rick_h_> frobware: one other thing for your "welcome back" is that dimitern looked at this lxd spec but would be good if you also gave it a look over this week: https://canonical.leankit.com/Boards/View/122969419/123761889
[14:41] <mup> Bug #1613300 opened: github.com/juju/juju/environs/sync fails with little info <centos> <ci> <jujuqa> <test-failure> <juju-core:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1613300>
[14:43] <rick_h_> dimitern: what came of: https://bugs.launchpad.net/juju-core/+bug/1612624 last week?
[14:43] <mup> Bug #1612624: Bootstrap fail on MAAS if ipv6 is disabled <juju-core:Triaged> <https://launchpad.net/bugs/1612624>
[14:44] <dimitern> rick_h_: I haven't had time to look into that
[14:44] <rick_h_> dimitern: ok
[14:45] <dimitern> rick_h_: I could try later today
[14:45] <rick_h_> dimitern: all good, I was just reviewing bugs and recalled we had the conversation of simplifying that work
[14:45] <rick_h_> dimitern: so wanted to see what came after that discussoin we had.
[14:45] <rick_h_> dimitern: hold off and wrap up WIP before we move forward there.
[14:46] <dimitern> rick_h_: frobware and I discussed a few ways to detect ipv6 being enabled or not and if not - don't pass --ipv6 to mongod
[14:47] <dimitern> rick_h_: but couldn't get as far as a wip fix for it
[14:47] <rick_h_> dimitern: all good, ty for the update
[14:50] <mup> Bug #1613311 opened: show-log and list-models disagree after migration <ci> <intermittent-failure> <jujuqa> <model-migration> <juju-core:Triaged> <https://launchpad.net/bugs/1613311>
[14:51] <frobware> rick_h_: apologies for dropping out - have plumber here and needed somebody to stop the flow...
[14:52] <rick_h_> frobware: :) all good
[14:55] <frobware> rick_h_: there's less water now :)
[14:55] <rick_h_> frobware: as long as it's less out of the pipes, and more in the pipes, seems like a net win to me
[14:55] <frobware> rick_h_: houses - just like s/w
[15:00] <frobware> rick_h_: I took a look over LXD spec - looks good
[15:04] <redir> morning
[15:04] <natefinch> if someone could review https://github.com/juju/jsonschema/pull/1  it would be a big help
[15:05] <frobware> voidspace: ping - scripts, what were the issues?
[15:06] <voidspace> frobware: the scripts have various dependencies - python libraries and system libraries
[15:06] <voidspace> frobware: and they're not detailed anywhere
[15:06] <voidspace> frobware: so I had to work them out
[15:06] <frobware> voidspace: that's outrageous! :-D
[15:06] <voidspace> frobware: e.g. xmlstarlet
[15:07] <voidspace> frobware: so run, fail, work out why it failed and what package provides the missing bit, repeat...
[15:07] <voidspace> frobware: :-)
[15:07] <frobware> voidspace: let me add a prerequisites.sh
[15:07] <voidspace> frobware: cool
[15:07] <voidspace> frobware: I have an empty vm I was just about to re-start the procedure so I could work out what they were again
[15:08] <frobware> voidspace: did this not work?
[15:08] <frobware> type -p xmlstarlet > /dev/null || die "please install xmlstarlet(1)"
[15:08] <voidspace> frobware: I didn't see that message
[15:08] <frobware> hmm
[15:08] <voidspace> frobware: I saw one telling me to *reinstall* xmlstarlet
[15:08] <voidspace> frobware: that was just the first missing dependecy - there were about four I think
[15:08] <frobware> voidspace: must come from something else
[15:09] <voidspace> frobware: it was just add-node I was using
[15:09] <frobware> voidspace: that 'type -p' is in add-node
[15:09] <voidspace> frobware: *really* useful
[15:09] <voidspace> frobware: so thanks
[15:09] <voidspace> frobware: it failed at commissioning, but probably because I don't have power types set up
[15:09] <frobware> voidspace: we need (MUST!) do more of this
[15:09] <voidspace> frobware: but I can do that manually
[15:10] <voidspace> frobware: rick_h_ said move it to github.com/juju so we can maintain it collectively
[15:10] <voidspace> frobware: and I agree
[15:10] <frobware> voidspace: sometimes I do see commisionning fail, but I believe that's a maas issue
[15:11] <voidspace> frobware: I don't care about that anyway - creating the vm and enlisting is cool enough
[15:11] <mup> Bug #1613311 opened: show-status and list-models disagree after migration <ci> <intermittent-failure> <jujuqa> <model-migration> <juju-core:Triaged> <https://launchpad.net/bugs/1613311>
[15:12] <frobware> voidspace: I need to fix a small issue with remove-node, so will look at this now
[15:12] <voidspace> frobware: ok
[15:12] <voidspace> frobware: past 6pm here, dinner time
[15:13] <voidspace> frobware: I'll be on later though
[15:13] <voidspace> frobware: want to finish this actions stuff
[15:13] <frobware> voidspace: sure
[15:14] <natefinch> mgz, sinzui: you guys seen this before, when destroying an azure env? ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: Failure sending request for Service Principal 10f015aa-8519-47cf-bd76-d60b1b06ba7d: StatusCode=0 -- Original Error: http: nil Request.URL
[15:34]  * rick_h_ gets his taco on
[15:48] <dimitern> frobware: I'll need to skip the networking call btw
[16:04] <rogpeppe> katco: any chance of a "shipit" on http://reviews.vapour.ws/r/5428/ ?
[16:04] <rogpeppe> katco: i added some QA steps, got it approved by tech board, QA'd it myself
[16:05] <rogpeppe> katco: and it's in the way of a couple of other branches now
[16:08] <rogpeppe> ... or anyone else... voidspace? mgz? dooferlad?
[16:11] <mgz> rogpeppe: are the open issues actually all addressed/responded to now?
[16:12] <rogpeppe> mgz: all except the ones i replied to to say i didn't think they were worth doing, yes
[16:19] <mgz> rogpeppe: code changes look good to me, I don't fully get the implications of changing the return signature of ModelTag or adding a new /api alias
[16:19] <mgz> presumably both are safe/sane enough?
[16:19] <rogpeppe> mgz: thanks
[16:21] <mgz> you have a +1 from me, and a minor comment shipit from the other martin
[16:25] <rogpeppe> mgz: ta!
[17:00] <natefinch> mgz, sinzui: --keep-env doesn't seem to actually keep the environment?  does that just keep the machines around?
[17:01] <sinzui> natefinch: --keep-env means don't call kill-controller at the end of the script. It exits after collecting logs
[17:01] <natefinch> sinzui: hmm weird
[17:02] <natefinch> sinzui: so the controller should show up if I do JUJU_DATE=./cloud-city juju controllers, right?
[17:02] <natefinch> (obv JUJU_DATA)
[17:03] <mgz> natefinch: that's the bit I'm not sure is correct right now
[17:03] <mgz> I think our poking of code around config/creds might have confused somethig
[17:03] <rogpeppe> mgz: when a 'bot merge fails now, where do we go to find the test failure output?
[17:04] <natefinch> mgz: ok... I don't seem to have a controllers.yaml in cloud-city
[17:04] <rogpeppe> mgz: (it used to be in the console output but no longer)
[17:04] <mgz> because last time I wanted to do something similar I couldn't see the controller of a running env outside the script
[17:04] <mgz> rogpeppe: you need to look at the artifacts, linked from one level up on the job page
[17:04] <natefinch> mgz: to be fair, it did throw an exception during log collections because ./logs didn't exist :/
[17:04] <rogpeppe> mgz: ah!
[17:05] <mgz> natefinch: it probably should not have actually called kill-controller though? that should be apparent from the log
[17:05] <sinzui> natefinch: not exactly the controller is JUJU_DATA=cloud-city/jes-homes/<name-from-commandline>
[17:05] <mgz> rogpeppe: generally trusty-out.log for test failures
[17:06] <natefinch> sinzui: ahh, that's the problem
[17:06] <mgz> rogpeppe: well, that's interesting: juju/juju/environs/sync a test failed, but there's no output for the failure
[17:06] <rogpeppe> mgz: yes
[17:06] <rogpeppe> mgz: i was just writing that to you
[17:07] <natefinch> mgz, sinzui: works like a charm, thanks
[17:07] <rick_h_> mgz: rogpeppe there's a bug on that filed this morning
[17:07] <mgz> can you repo locally by just running that package?
[17:07] <mgz> rick_h_: ah
[17:07] <rick_h_> mgz: rogpeppe https://bugs.launchpad.net/juju-core/+bug/1613300
[17:07] <mup> Bug #1613300: github.com/juju/juju/environs/sync fails with little info <centos> <ci> <jujuqa> <test-failure> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1613300>
[17:08] <mgz> rogpeppe: so, it's master, not new with you
[17:08] <rogpeppe> mgz: i guess i should just $$merge$$ again
[17:10] <mgz> rogpeppe: well, ideally not, but I guess seeing how intermittent it is caan also be interesting
[17:10] <rogpeppe> mgz: i can't get it to fail on my machine
[17:11] <natefinch> ug... user admin@local is really confusing when it refers to a remote controller
[17:14] <rogpeppe> natefinch: ha ha
[17:15] <rogpeppe> natefinch: maybe the command line clients should rewrite admin@local to admin@$controllername
[17:19] <natefinch> rogpeppe: that would be helpful I think....  I saw this:
[17:19] <natefinch>  juju switch controller
[17:19] <natefinch> nate-win-debug:admin@local/nate-win-debug -> nate-win-debug:admin@local/controller
[17:20] <natefinch> and I thought for a minute I'd switched to a different controller, since it say "admin@local/controller at the end
[17:20] <rogpeppe> natefinch: well that's the problem with the name of the controller model
[17:21] <rogpeppe> natefinch: i still think that name is an endless source of problems
[17:21] <natefinch> rogpeppe: I agree... using the same name for two different things is asking for trouble
[17:21] <natefinch> but the same goes for "local" :)
[17:21] <rogpeppe> natefinch: if it had been nate-win-debug:admin@local/admin, it wouldn't have been as much of a problem, i think
[17:22] <rogpeppe> natefinch: well, @local names are always relative to the controller they're in
[17:22] <natefinch> rogpeppe: local means on my machine
[17:22] <natefinch> rogpeppe: we may not be using it that way, but that's what it means to most people
[17:22] <rogpeppe> natefinch: and mhilton points out to me that we really can't add arbitrary @domains
[17:23] <rogpeppe> natefinch: maybe it should be admin@3ecffebe-c248-41a2-893c-f67df84ec6bf :)
[17:23] <natefinch> rogpeppe: I don't even really understand why there's an @ at all.  Aren't all users defined in the namespace of the controller they're on?
[17:23] <rogpeppe> natefinch: no
[17:23] <rogpeppe> natefinch: external users are not
[17:26] <rogpeppe> natefinch: the @ is optional
[17:26] <rogpeppe> natefinch: tbh, as per a discussion in juju-dev some time ago, i'd really like to get rid of the whole special-case name "local" completely
[17:27] <natefinch> me too... I'd love to drop the @ entirely for users local to the controller
[17:27] <rogpeppe> natefinch: then any name without an @ is treated relative to whereever it's used
[17:27] <rick_h_> rogpeppe: yes, we've agreed that it needs to go away, just don't think it's been removed through and through yet
[17:27] <rogpeppe> natefinch: and that simplifies the names logic too
[17:27] <rogpeppe> rick_h_: really? cool!
[17:28] <rogpeppe> rick_h_: that would simplify a bunch of stuff on lots of places
[17:28] <rogpeppe> s/on/in/
[17:28] <natefinch> rick_h_: that helps a lot... optional input is nice, but if we always still output it, it's even more confusing, because now I've input "nate" and juju replies with "nate@local"
[17:28] <rick_h_> rogpeppe: yea, and it's not a case of 'by default users shouldn't need to mentally grok wtf is local' since to them there's no other option.
[17:28] <rick_h_> natefinch: right
[17:28] <natefinch> well, awesome :)
[17:48] <natefinch>  sinzui, mgz: I keep getting "no matching tools" when trying to run the deploy CI test on windows... what am I doing wrong?
[17:49] <natefinch> I'm running this command: JUJU_HOME=./cloud-city JUJU_REPOSITORY=./repository ./juju-ci-tools/deploy_job.py parallel-azure-arm $GOPATH/bin/juju ./logs nate-win-debug --series win2012r2 --keep-env
[17:49] <sinzui> natefinch: you might is in a bad position
[17:50] <natefinch> am I getting screwed by the new auto-upload-tools?
[17:50] <sinzui> natefinch: you need streams to provide two different agents
[17:50] <mgz> natefinch: do you need to be testing your exact binary?
[17:50] <sinzui> natefinch: I don't think so in this case since --upload-tools will fail the same ways
[17:50] <mgz> if not, you can probably use our streams
[17:51] <mgz> otherwise, you're going to need to build some windows tools and make streams
[17:51] <rick_h_> natefinch: --upload-tools is still there today?
[17:52] <sinzui> natefinch: If you can use the streams that CI is building then use the current revision add this to your command: --agent-stream=revision-build-4254
[17:53] <natefinch> sinzui: is there a way to say "just use the latest stream"?
[17:53] <natefinch> sinzui: I think I can use streams, if they've been built since andrew made his azure storage fix
[17:53] <sinzui> natefinch: no, there is no way to detect the latest testing stream
[17:53] <sinzui> natefinch: but you can see a stream for *weeks*
[17:54] <sinzui> natefinch: I tend to use the version that matches master at the start of my day: http://reports.vapour.ws/releases
[17:54] <natefinch> sinzui: but what I want 99% of the time is whatever is the latest stream, since that may have fixes I need
[17:54] <sinzui> natefinch: right. You can check that page to see which version is available
[17:54] <rogpeppe> here's a small PR that removes some API server cruft from the code: https://github.com/juju/juju/pull/5997
[17:58] <natefinch> mgz: how hard is it to make my own stream?  making my own jujud.exe is trivial, at least
[17:58] <mgz> natefinch: it's pretty trivial, I believe abentley has some tools to make it less painful as well.
[17:59] <natefinch> mgz: those two statements seem to be at odds with each other ;)
[18:00] <mgz> it's easy to do and easy to do wrong :)
[18:01] <natefinch> can I just do sync tools or something?  I just want to tell juju "here's a couple different tools, please use them" :/
[18:01] <natefinch> except not sync tools, obv
[18:02] <mgz> yerp nope.
[18:02] <natefinch> we really seem to work hard to make things difficult for ourselves
[18:02] <mgz> juju metadata generate-tools does get you most of the way though.
[18:03] <sinzui> natefinch: I sent uyou a scipt that makes streams from you local jujuds
[18:07] <sinzui> natefinch: pull lp:juju-ci-tools and look at streams-from-local.bash which you can pass jujus and jujud.exe to
[18:09] <natefinch> sinzui, mgz: should I be using series win2012hvr2?  I've been using win2012r2
[18:12] <sinzui> natefinch: does azure have that? We use it in our maas, but but in azure because I could find tht image
[18:12] <natefinch> sinzui: I have no idea what azure has
[18:14] <natefinch> sinzui: I honestly can't even tell what azure has when looking at their list of VMs to create
[18:15] <sinzui> natefinch: no, you can't :(. We installed the azure python sdk to write a script to query that was available
[18:15] <natefinch> not sure what "Windows Server 2012 R2 Datacenter" maps to in our list of series names
[18:15] <natefinch> well I'm glad it's not just me
[18:16] <sinzui> natefinch: win2012r2 did with with juju om july 6
[18:16] <sinzui> natefinch: I am still looking for some sample streams that show the available series
[18:25] <natefinch> sinzui: that streams-from-local.bash gives me line 68: unexpected EOF while looking for matching `"'
[18:25] <sinzui> :(
[18:25]  * sinzui looks
[18:26] <natefinch> sinzui: WIN_JUJUD=${3"-}
[18:27] <sinzui> thank you name
[18:27] <natefinch> I presume that's wrong, although it may be a bashism I don't understand
[18:27] <sinzui> thank you natefinch
[18:27]  * natefinch gets the feeling he's being addressed by a bot
[18:27] <sinzui> natefinch: bash is not pleasant
[18:28] <sinzui> natefinch: oh, we need to also add the other win series too
[18:28] <sinzui> natefinch: I used this with the maas. I will fix the quote and add the other win series
[18:34] <sinzui> natefinch: pull lp:juju-ci-tools. I added win2012r2 and replaced " with :
[18:37] <natefinch> sinzui: thanks
[18:43] <natefinch> sinzui:  I've never made my own streams before.  after running the streams-from-local script, do I just bootstrap with --metadata-source, or is there more I need to do?
[18:44] <sinzui> natefinch: --metadata-source worked last time I used (when I wrote the script).
[18:45] <natefinch> gah, of course --metadata-source doesn't work with the ci script :/    I'm sorta surprised we don't just pass any unrecognized flags to bootstrap... seems like that would be the right thing to do most of the time
[18:52] <natefinch> mgz, sinzui: to add support for a new arg, do I just add another add_argument call to deploy_job_parse_args?
[18:56] <sinzui> natefinch: probably not. Most args ar needed by all scripts. utility.py add_basic_testing_arguments() fif the arge is for a general juju or test case. If the arg is specific to a single test, then the script can get it.
[19:20] <natefinch> sinzui: ok, so how do I get the flag to actually be passed to bootstrap?  I added it to add_basic_testing_arguments ... but not exactly sure what to put as the action
[19:23] <sinzui> natefinch: you will need to update BootstrapManager in deploy_stack.py. You probaly need the arg passed down to booted_contex()
[19:24] <sinzui> natefinch: which arg to you need
[19:26] <natefinch> sinzui: metadata-source
[19:27] <sinzui> abentley:  we need the new juju bugs reported to discuss them on the release call
[19:27] <sinzui> :/
[19:27]  * rick_h_ goes to get the boy from summer camp
[19:28] <abentley> sinzui: I reported bug #1613300 and bug #1613311.  Is that what you're asking?
[19:29] <mup> Bug #1613300: github.com/juju/juju/environs/sync fails with little info <centos> <ci> <intermittent-failure> <jujuqa> <test-failure> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1613300>
[19:29] <mup> Bug #1613311: show-status and list-models disagree after migration <ci> <intermittent-failure> <jujuqa> <model-migration> <juju-core:Triaged> <https://launchpad.net/bugs/1613311>
[19:31] <sinzui> natefinch: I would consider a cheat to to get moving. you could change EnvJujuClient.bootstrap() to append the extra arg. You need to do that to add full support. Just added enough to get yourself unblocked. You cna push your change up for yourself to complete or maybe the qa team. I am sure we will want comprehensive support in the future
[19:33] <natefinch> man I miss static typing
[19:33] <natefinch> is args a string or a list?
[19:36] <natefinch> answer: neither, it's a tuple :/
[19:36] <natefinch> sigh
[20:18] <katco> rick_h_: ping
[20:19] <rick_h_> katco: pong
[20:20] <katco> rick_h_: got a sec? i have a usability error message q
[20:20] <rick_h_> katco: otp atm, will ping when off
[20:20] <katco> rick_h_: np, ta
[20:29] <rick_h_> katco: meet you in standup room when you're free
[20:30] <katco> rick_h_: omw
[20:33] <mup> Bug #1613429 opened: introspectionSuite.SetUpTest failure <intermittent-failure> <test-failure> <testing> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1613429>
[20:37] <natefinch> sinzui: I can't get metadata-source to work... I just always get no tools available, even though I have win2012hvr2 in my local streams stuff
[20:37] <sinzui> :/
[20:37] <sinzui> natefinch: is metadata-source broken?
[20:39] <sinzui> natefinch: you can push the streams to people.canonica.com then set image-metadata-url. I did this earlier this year (http://people.canonical.com/~curtis/images)
[20:40] <natefinch> sinzui: I'm not sure.  I don't know enough about how it is supposed to work.  Definitely there seems to be a lack of logging around it.  Just saying "no tools available" is kind of useless for debugging.
[20:40] <sinzui> natefinch: yeah. that's below average.
[20:41] <veebers> natefinch, sinzui: is it possible that might be related to the changes wallyworld did for the upload-tools/build-agent stuff?
[20:43] <natefinch> I think streams data is a separate path, but it's possible this is an unintended side effect
[20:43] <sinzui> veebers: I don't think so since CI isn't seeing failures yet. Juju is very bad at letting developers test mixed os/arch. the new feature is actively ignoring that we must support windows, centos, and 3 other archs
[20:44] <veebers> sinzui: ack. I ask because he is double checking something for me based on his recent changes :-)
[20:45] <sinzui> veebers: I removed --upload-tools when I woke so we know deployments without streams continue to work.
[20:46] <sinzui> natefinch: You hit bug 1591488
[20:46] <mup> Bug #1591488: Unable to bootstrap with --metadata-source <cpe-sa> <juju-core:In Progress by anastasia-macmood> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1591488>
[20:47] <natefinch> fffffffff
[20:50] <veebers> sinzui: huh I should have checked trunk changes more closely :-\ You already fixed this bug before I came across it: https://bugs.launchpad.net/juju-ci-tools/+bug/1613192
[20:50] <mup> Bug #1613192: EnvJujuClient.grant() passes invalid argument <juju-ci-tools:New> <https://launchpad.net/bugs/1613192>
[20:52] <natefinch> sinzui: well, I guess I have to do the image-metadata-url thing
[20:54] <sinzui> natefinch: just add image-metadata-url to the env in environments.yaml. It will be added to config.yaml for bootstrap
[20:55] <natefinch> sinzui: cool... do you have a link to instructions on how to get stuff up to people.canonical.com?
[20:59] <natefinch> gotta run, back later
[21:00] <rick_h_> natefinch-afk: you can just use dropbox and get a url for it, or use the s3 file web UX to upload and get a generated url for it.
[21:00] <rick_h_> natefinch-afk: don't let people.canonical.com hold you up, unblock
[21:00] <rick_h_> natefinch-afk: shoot, upload the file into a pastebin and direct link to the raw url path
[21:02] <anastasiamac> wallyworld: thumper: could u joun bug scrub?
[21:02] <anastasiamac> join*
[21:03] <wallyworld> it's not on my calendar, url?
[21:03] <mup> Bug #1613444 opened: Remove-user doesn't remove user from list-shares <juju-core:New> <https://launchpad.net/bugs/1613444>
[21:04] <thumper> nor mine
[21:05] <anastasiamac> wallyworld: thumper: https://hangouts.google.com/hangouts/_/canonical.com/bug-scrub?authuser=0
[21:10] <voidspace> axw: ping
[21:12] <voidspace> thumper: ping
[21:12] <thumper> voidspace: hey, in a call right now
[21:12] <thumper> voidspace: is this about the actions review?
[21:12] <voidspace> thumper: hey, cool
[21:12] <thumper> because I didn't finish it, sorry
[21:12] <voidspace> thumper: sort of - I'm working on QA steps and failing to do a basic migration
[21:12] <thumper> ah...
[21:12] <voidspace> thumper: I'll email you what I'm trying to do and you can correct my bad syntax
[21:12] <voidspace> because...
[21:13] <thumper> hmm... where's menno?
[21:13] <voidspace> $ juju help migrate
[21:13] <voidspace> ERROR unknown command or topic for migrate
[21:13] <thumper> ah
[21:13] <thumper> you need the feature flag
[21:13] <voidspace> ah, I did for the migrate command - but not for the help
[21:14] <voidspace> thumper: I'll bother menn0
[21:14] <thumper> menn0: hey, can you help voidspace with a migration?
[21:14] <thumper> cheers
[21:14] <voidspace> ta
[21:14] <menn0> voidspace: yep, what's up?
[21:14] <voidspace> menn0: hang on, I'll create a pastebin
[21:15] <voidspace> menn0: my thoughts for QA steps for action migration was that it would look something like this:
[21:15] <voidspace> menn0: http://pastebin.ubuntu.com/23059562/
[21:16] <voidspace> menn0: however the migration step of this seems to not (visibly) do anything
[21:16] <voidspace> menn0: so I've obviously got something wrong
[21:16] <menn0> voidspace: the QA steps look sensible to me
[21:17] <voidspace> menn0: after running the migration there is no git unit in B
[21:17] <voidspace> menn0: nor any visible sign of anything happening
[21:17] <menn0> voidspace: it might be worth checking `JUJU_DEV_FEATURE_FLAGS=developer-mode juju dump-model` on the model before and after the migration to see if the action data is being included
[21:17] <voidspace> menn0: ah, ok
[21:18] <menn0> voidspace: did the model actually make it across?
[21:18] <voidspace> menn0: however, I'm not yet convinced a migration is actually happening
[21:18] <voidspace> menn0: ah, of course
[21:18] <voidspace> I'm in B:default
[21:18] <voidspace> thanks
[21:18] <voidspace> not looking at the new model
[21:18] <menn0> voidspace: I see the problem
[21:19] <menn0> voidspace: you're trying to migrate "default" across but there's already a default on the other side
[21:19] <menn0> voidspace: the migration will have aborted because of that
[21:19] <voidspace> menn0: ok, will fix this
[21:19] <menn0> voidspace: to see try something like: juju debug-log -m A:controller --replay -T | grep migrationmaster
[21:20] <menn0> voidspace: if you remove "default" from B and then retry the migration you should have better luck
[21:20] <voidspace> menn0: yep, exactly that
[21:20] <voidspace> menn0: or just add a new model, deploy to that and migrate that
[21:20] <menn0> voidspace: that's what I normally would do
[21:20] <menn0> voidspace: but given you already have it set up as default you could just delete default first
[21:25] <voidspace> menn0: ok, so I can confirm that actions are not migrated on master - now to try it with my branch :-D
[21:25] <voidspace> menn0: thanks for the help
[21:25] <menn0> voidspace: no problems
[21:26] <menn0> voidspace: migrations will support renaming of the model during migrations at some point
[21:26] <voidspace> cool
[21:26] <menn0> voidspace: it'll also fail in a more obvious way for these kinds of early checks (i.e. before the `juju migrate` command returns)
[21:26] <voidspace> menn0: that will really help
[21:50] <voidspace> menn0: and after much futzing (required merging master in) I can confirm that actions are migrated by my branch
[21:50] <voidspace> menn0: will add the successful QA steps to RB
[21:52] <voidspace> and bedtime
[21:52] <voidspace> g'night all o/
[21:55] <menn0> voidspace: good night
[21:57] <mup> Bug #1613459 opened: MainSuite.TestFirstRun2xFrom1xNotUbuntu forbidden (on closed network) <ci> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1613459>
[22:02]  * rick_h_ goes to make the fam dinner, night all
[22:02] <thumper> wallyworld: what was the final thoughts on the blocker?
[22:02] <wallyworld> thumper: i'm going to remove it
[22:03] <thumper> menn0: ^^
[22:03] <wallyworld> done
[22:04] <menn0> wallyworld: ty, this didn't seem like blocker material to me either
[22:04] <wallyworld> agreed
[22:17] <menn0> redir: can you show me how you added the config to the cloud? I just tried that (via a new lxd cloud called "local") and none of the config made it the the bootstrapped host
[22:18] <redir> menn0: so far I've been doing it with aws since i am working on something that requires regions. but lemme make sure it works with lxd too
[22:20] <redir> menn0: so I have this file stored where I won't delete it: http://paste.ubuntu.com/23059827 (you only care about lxdtest)
[22:21] <redir> and I add it with juju add-cloud lxdtest ~/Sync/juju/2.0/development-config.yaml
[22:21] <redir> menn0: and I can see that the lxd controller is using squid-deb-proxy
[22:22] <menn0> redir: that's essentially what I did but none of those options made it into the bootstrapped models
[22:22] <menn0> redir: I must have missed something
[22:23] <menn0> redir: I see the problem -- "juju add-cloud" ignored all the extra options
[22:23] <menn0> redir: looks like I have to edit them into clouds.yaml directly
[22:23] <redir> menn0: I just imported them
[22:23] <redir> if you already have a config then you need --replace maybe
[22:24] <redir> also maybe local is overloaded
[22:24] <redir> menn0: ^
[22:24] <menn0> redir: it was definitely a new cloud
[22:24] <menn0> redir: I'll try a different name
[22:25] <menn0> redir: nope
[22:25]  * redir blinks
[22:25] <menn0> redir: add-cloud just ignores the extra bits
[22:25] <menn0> I end up with a cloud with just one field "type: lxd"
[22:26] <redir> menn0: juju model-defaults no-proxy
[22:26] <redir> ATTRIBUTE  DEFAULT  CONTROLLER
[22:26] <redir> no-proxy   -        https://lxd-no-regions
[22:26] <menn0> redir: very strange ... so you used "juju add-cloud" as well?
[22:26] <redir> strange
[22:27] <redir> yes
[22:27] <redir> whenever I edit I edit in the non-volatile location and --replace
[22:27] <redir> do you have only one cloud?
[22:27] <redir> menn0: ^
[22:28] <menn0> redir: yes... there's one cloud in clouds.yaml
[22:30] <redir> menn0: very strange, indeed
[22:31] <redir> menn0: FWIW, I am at ed24813 with a couple commits on top.
[22:40] <menn0> redir: I'm a little behind you then (last updated late yesterday)
[22:41] <menn0> redir: I'll fiddle with this a bit more later
[22:41] <menn0> redir: thanks for your help
[22:41] <redir> some help:)
[22:41] <menn0> redir: I certainly think having this config in the cloud config is the way to go
[22:41] <redir> I'll update the wiki next week.
[22:43] <redir> wfm in AWS too (sans apt proxy)
[22:43]  * redir looks to see if wallyworld is in meetings
[22:43] <wallyworld> not right now
[22:43] <redir> wallyworld: looks ripe for interruption
[22:44] <wallyworld> almost, give me a minute
[22:44] <redir> got a few minutes for some model-config ?s
[22:44] <redir> k
[22:46] <katco> wallyworld: change pushed
[22:46] <wallyworld> ta
[22:46] <katco> wallyworld: ty
[22:57] <mup> Bug #1605756 changed: [ juju2 beta11 ] system show up in juju status as pending but there is no attempt to deploy in maas <oil> <oil-2.0> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1605756>
[22:58] <menn0> wallyworld: so this test I fixed last night isn't the same thing that's causing the mysterious failures in environs/sync
[22:58] <menn0> wallyworld: I was just bitten by it again
[22:58] <menn0> wallyworld: it's happening a lot
[22:58] <menn0> wallyworld: any ideas?
[22:59] <wallyworld> menn0: otp, give me a sec
[23:15] <mwhudson> er are you all in some different standup to me?
[23:33] <mup> Bug #1613476 opened: juju cli commands should be logged by juju <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1613476>
[23:47] <wallyworld> redir: did you want to talk some more?
[23:48] <wallyworld> or you all good?
[23:48] <redir> wallyworld: yeah was mid thought
[23:48] <redir> still in standup
[23:49] <wallyworld> redir: gogle crashed, one sec
[23:49] <redir> np