[00:11] <wallyworld> thumper: thanks for looking. i pushed some changes and replied to comments
[01:03] <axw_> burton-aus: standup?
[02:43] <babbageclunk> 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] <axw_> 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] <axw_> babbageclunk: if it's an overall failure unrelated to a specific parameter, it should return an error besides the ErrorResult IMO
[02:43] <wallyworld> babbageclunk: if the mechanics of getting the error results struct fails, you return a normal error for that
[02:43] <babbageclunk> Ok
[02:44] <wallyworld> the error results struct is just another api call result
[02:44] <wallyworld> all api calls should return an error along with their results
[02:45] <babbageclunk> 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] <babbageclunk> Kind of like expected-errors, unexpected error.
[02:46] <babbageclunk> Thanks
[02:49] <babbageclunk> 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] <wallyworld> babbageclunk: ideally params should never escape the api layers, but they do :-(
[02:49] <axw_> babbageclunk: does it? a *params.Error is an error
[02:50] <wallyworld> often OneError() is used to collasce
[02:50] <wallyworld> or CombineErrors() if more then one
[02:51] <babbageclunk> wallyworld: Hmm - CombineErrors sounds like what I want
[02:51] <wallyworld> could be
[03:42] <wallyworld> axw_: here's a trivial juju/names PR to add "_" to cloud tags https://github.com/juju/names/pull/81
[03:44] <axw_> wallyworld: lgtm
[03:44] <wallyworld> ta
[03:48] <wallyworld> 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] <veebers> 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] <wallyworld> ta
[04:05] <veebers> wallyworld: fixed and re-ran
[04:05] <wallyworld> great ty
[04:23] <wallyworld> axw_: here's a trivial PR to pull in the names dep https://github.com/juju/juju/pull/7736
[07:13] <blahdeblah> 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] <axw_> blahdeblah: yes, I'm around. which provider?
[07:15] <blahdeblah> openstack
[07:16] <blahdeblah> axw_: It's giving me this fun status output: https://pastebin.canonical.com/195832/ and the image id doesn't exist.
[07:19] <axw_> blahdeblah: AFAICT, image-stream only affects the public cloud image metadata
[07:19] <axw_> blahdeblah: I think you're supposed to change image-metadata-url for private clouds, if you want different images
[07:19] <blahdeblah> axw_: I've never had to do that previously
[07:20] <blahdeblah> i.e. this has worked before on this cloud with this image-stream
[07:20] <blahdeblah> which suggests my juju controller is failing to get the correct image list for some reason
[07:22] <axw_> 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] <blahdeblah> No worries - thanks
[07:23] <blahdeblah> I'll keep digging and file a bug if I can't bend it to my will
[07:48] <wallyworld> 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] <blahdeblah> wallyworld: How can I tell which URL juju is trying to hit for that?
[07:50] <blahdeblah> (nothing in machine-0 log that I can see)
[07:50] <wallyworld> use --debug when bootstrapping should print it i think
[07:50] <wallyworld> you need debug to see it
[07:51] <blahdeblah> but I'm not bootstrapping, I'm just adding a model
[07:51] <wallyworld> turn on debug then
[07:51] <blahdeblah> on the add-model, or something else?
[07:51] <blahdeblah> actually, the problem doesn't appear until I deploy
[07:52] <wallyworld> no, on the controller. juju model-config logging-config="<root>=DEBUG;"
[07:52] <wallyworld> or something like that
[07:52] <blahdeblah> OK - thankss
[07:52] <wallyworld> on the controller model
[07:52] <wallyworld> i *think* that will produce the output you need
[07:52] <wallyworld> it should print the swift url it looks at
[07:53] <wallyworld> you can also list the keystone catalog using the openstack CLI
[07:53] <wallyworld> that will also have the swift container used
[11:17] <menn0> wallyworld, axw_ : when you have a chance (no rush): https://github.com/juju/juju/pull/7738
[11:18] <wallyworld> ok
[11:19] <wallyworld> menn0: i'll do a proper look first thing tomorrow
[11:19] <menn0> wallyworld: thanks. I wasn't expecting a review tonight :)
[11:19] <wallyworld> :-) a bit tired tonight
[14:01] <natefinch> rogpeppe1: is there support for private charms in the charm store?
[14:02] <rogpeppe1> natefinch: yes
[14:02] <natefinch> awesome
[14:02] <rogpeppe1> natefinch: well, of course they're not *totally* private 'cos the charmstore gets to see them unencrypted
[14:02] <rogpeppe1> natefinch: but i suspect that's good enough for what you need
[14:03] <natefinch> I think that's probably fine, as long as no one outside of charm store admins can see them
[14:04] <natefinch> We're looking into using Juju at Mattel
[14:05] <natefinch> 'cause Terraform and nomad just turn into thousands of lines of bash masquerading as declarative config
[14:23] <natefinch> rogpeppe1: is there a good local development story on Mac?
[14:23] <rogpeppe1> natefinch: development of what?
[14:24] <natefinch> rogpeppe1: local deploy, a la lxd on linux
[14:24] <rogpeppe1> 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] <natefinch> hmm
[14:25] <rogpeppe1> natefinch: give it a go