[00:11] thumper: thanks for looking. i pushed some changes and replied to comments [01:03] burton-aus: standup? [02:43] wallyworld, axw_ - quick API design question? This API method returns a params.ErrorResults with any collected mismatches it finds. Should it return (params.ErrorResults, error)? Or just jam any incidental errors it hits into the ErrorResults? [02:43] thumper: the machiner updates observed network config, but that's as observed on the machine. the details won't include provider IDs. so I think there's still work to be done [02:43] babbageclunk: if it's an overall failure unrelated to a specific parameter, it should return an error besides the ErrorResult IMO [02:43] babbageclunk: if the mechanics of getting the error results struct fails, you return a normal error for that [02:43] Ok [02:44] the error results struct is just another api call result [02:44] all api calls should return an error along with their results [02:45] Cool - that's what I have now, it just felt slightly odd to return (list of errors, error). I guess the migrationmaster worker will do different things for the different values thought. [02:46] Kind of like expected-errors, unexpected error. [02:46] Thanks [02:49] wallyworld, axw_: And the client method, should that return ([]params.Error, error) or ([]error, error)? I guess the former, since that includes more information. [02:49] babbageclunk: ideally params should never escape the api layers, but they do :-( [02:49] babbageclunk: does it? a *params.Error is an error [02:50] often OneError() is used to collasce [02:50] or CombineErrors() if more then one [02:51] wallyworld: Hmm - CombineErrors sounds like what I want [02:51] could be [03:42] axw_: here's a trivial juju/names PR to add "_" to cloud tags https://github.com/juju/names/pull/81 [03:44] wallyworld: lgtm [03:44] ta [03:48] veebers: looks like a CI script breakage? http://juju-ci.vapour.ws:8080/blue/organizations/jenkins/github-merge-juju-names/detail/github-merge-juju-names/46/pipeline [03:58] * veebers looks [04:01] wallyworld: hah, that job hasn't run for 3 months before now. Looks like things have changed from underneath it. I'm looking now [04:01] ta [04:05] wallyworld: fixed and re-ran [04:05] great ty [04:23] axw_: here's a trivial PR to pull in the names dep https://github.com/juju/juju/pull/7736 [07:13] wallyworld, axw_, anastasiamac: any of you folks still around? I'm trying to work out how juju decides what image id to use when I tell it "juju model-config image-stream=daily"; it's currently picking the wrong one. [07:15] blahdeblah: yes, I'm around. which provider? [07:15] openstack [07:16] axw_: It's giving me this fun status output: https://pastebin.canonical.com/195832/ and the image id doesn't exist. [07:19] blahdeblah: AFAICT, image-stream only affects the public cloud image metadata [07:19] blahdeblah: I think you're supposed to change image-metadata-url for private clouds, if you want different images [07:19] axw_: I've never had to do that previously [07:20] i.e. this has worked before on this cloud with this image-stream [07:20] which suggests my juju controller is failing to get the correct image list for some reason [07:22] blahdeblah: sorry, I don't know then, it'll require a deep dive. please file a bug and so forth. anastasiamac may be able to provide assistance more readily - she's been in that area more recently [07:23] No worries - thanks [07:23] I'll keep digging and file a bug if I can't bend it to my will [07:48] blahdeblah: the image look up code has not changed in a long time. i would suspect that the json files on the canonistack swift container have been changed or are aout of date [07:50] wallyworld: How can I tell which URL juju is trying to hit for that? [07:50] (nothing in machine-0 log that I can see) [07:50] use --debug when bootstrapping should print it i think [07:50] you need debug to see it [07:51] but I'm not bootstrapping, I'm just adding a model [07:51] turn on debug then [07:51] on the add-model, or something else? [07:51] actually, the problem doesn't appear until I deploy [07:52] no, on the controller. juju model-config logging-config="=DEBUG;" [07:52] or something like that [07:52] OK - thankss [07:52] on the controller model [07:52] i *think* that will produce the output you need [07:52] it should print the swift url it looks at [07:53] you can also list the keystone catalog using the openstack CLI [07:53] that will also have the swift container used [11:17] wallyworld, axw_ : when you have a chance (no rush): https://github.com/juju/juju/pull/7738 [11:18] ok [11:19] menn0: i'll do a proper look first thing tomorrow [11:19] wallyworld: thanks. I wasn't expecting a review tonight :) [11:19] :-) a bit tired tonight [14:01] rogpeppe1: is there support for private charms in the charm store? [14:02] natefinch: yes [14:02] awesome [14:02] natefinch: well, of course they're not *totally* private 'cos the charmstore gets to see them unencrypted [14:02] natefinch: but i suspect that's good enough for what you need [14:03] I think that's probably fine, as long as no one outside of charm store admins can see them [14:04] We're looking into using Juju at Mattel [14:05] 'cause Terraform and nomad just turn into thousands of lines of bash masquerading as declarative config [14:23] rogpeppe1: is there a good local development story on Mac? [14:23] natefinch: development of what? [14:24] rogpeppe1: local deploy, a la lxd on linux [14:24] natefinch: good question. i'm not sure, as i don't have a mac. might need to use a local vm, i guess. [14:24] hmm [14:25] natefinch: give it a go