| wallyworld | thumper: thanks for looking. i pushed some changes and replied to comments | 00:11 |
|---|---|---|
| axw_ | burton-aus: standup? | 01:03 |
| 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:43 |
| 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:44 |
| 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:45 |
| babbageclunk | Kind of like expected-errors, unexpected error. | 02:46 |
| babbageclunk | Thanks | 02:46 |
| 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:49 |
| wallyworld | often OneError() is used to collasce | 02:50 |
| wallyworld | or CombineErrors() if more then one | 02:50 |
| babbageclunk | wallyworld: Hmm - CombineErrors sounds like what I want | 02:51 |
| wallyworld | could be | 02:51 |
| wallyworld | axw_: here's a trivial juju/names PR to add "_" to cloud tags https://github.com/juju/names/pull/81 | 03:42 |
| axw_ | wallyworld: lgtm | 03:44 |
| wallyworld | ta | 03:44 |
| 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:48 |
| * veebers looks | 03:58 | |
| 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:01 |
| veebers | wallyworld: fixed and re-ran | 04:05 |
| wallyworld | great ty | 04:05 |
| wallyworld | axw_: here's a trivial PR to pull in the names dep https://github.com/juju/juju/pull/7736 | 04:23 |
| 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:13 |
| axw_ | blahdeblah: yes, I'm around. which provider? | 07:15 |
| blahdeblah | openstack | 07:15 |
| blahdeblah | axw_: It's giving me this fun status output: https://pastebin.canonical.com/195832/ and the image id doesn't exist. | 07:16 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| wallyworld | you can also list the keystone catalog using the openstack CLI | 07:53 |
| wallyworld | that will also have the swift container used | 07:53 |
| menn0 | wallyworld, axw_ : when you have a chance (no rush): https://github.com/juju/juju/pull/7738 | 11:17 |
| wallyworld | ok | 11:18 |
| 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 | 11:19 |
| natefinch | rogpeppe1: is there support for private charms in the charm store? | 14:01 |
| 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:02 |
| natefinch | I think that's probably fine, as long as no one outside of charm store admins can see them | 14:03 |
| natefinch | We're looking into using Juju at Mattel | 14:04 |
| natefinch | 'cause Terraform and nomad just turn into thousands of lines of bash masquerading as declarative config | 14:05 |
| natefinch | rogpeppe1: is there a good local development story on Mac? | 14:23 |
| rogpeppe1 | natefinch: development of what? | 14:23 |
| 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:24 |
| rogpeppe1 | natefinch: give it a go | 14:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!