[00:00] if the service for the image metadata is setup and named per the docs - it will be found automagically by juju based on the naming. [00:00] hml: product-stream [00:01] and the service type is product-streams? [00:01] hml: yes [00:01] did the debug output list the URL juju was trying it? [00:02] you might need to list it as: http://10.0.8.52:80/swift/v1/simplestreams/images [00:02] if that’s how you set it up [00:03] hml: image-metadata-url: invalid URL "http://10.0.8.52:80/swift/v1/streams/v1/index.json" not found [00:03] can you download from the list I just listed? [00:04] if so , you can update your endpoint. [00:04] juju will add the streams/v1/index.json to the end itself [00:11] hml: http://10.0.8.52/swift/v1/simplestreams is giving me 200 OK [00:12] sounds like you just need to update the endpoint service url and/or the url given on the CLI [00:13] hml: yup, that was it :) [00:14] hml: of course, im missing correct instance type now :) [00:14] hml: anyway, thank you very much [00:15] schkovich: you’re welcome. [00:16] my openstack-novalxd is using the m1.medium instance type for the controller fwiw, and m1.small for a unit currently [00:17] hml: i did not create all flavours eg m1.medium is missing [00:17] hml: should be simple but it's 2am on my side of the globe. time to go to bed. i will continue tomorrow. :) [00:18] schkovich: sounds good :-) [00:18] hml: it's so easier when there is someone to discuss the problem with :) thanks once again [01:17] babbageclunk: thanks for the review. did I miss anything in the standup? [01:54] babbageclunk: https://github.com/juju/juju/pull/7646 === arosales_ is now known as arosales === coreycb_ is now known as coreycb [02:23] axw: sorry, was out - no, nothing much [06:40] hi core team.. any chance i could get a review of https://github.com/juju/juju/pull/7642 ? [08:13] ashipika: i'm just reviewing something else. i'll do yours next. [08:14] menn0: tyvm [08:47] ashipika: done [13:29] i've got a PR for a change to testing/checkers that will undoubtedly break juju tests (but in a good way, i'd suggest). https://github.com/juju/testing/pull/129 === rogpeppe1 is now known as rogpeppe === kjackal_ is now known as kjackal [17:21] crunchywelch: welcome - here’s the wiki link: https://github.com/juju/juju/wiki/Implementing-environment-providers [17:23] aaay, thanks! o/ [22:44] axw: I'm looking at PR 7649 now [23:49] babbageclunk: muchas gracias [23:53] axw: It looks good, except I'm confused by destroy methods with don't-destroy parameters. [23:54] any parameter on anything that says "don't do X" should be burned with fire [23:55] babbageclunk: you mean "juju remove-storage --no-destroy" ? [23:55] blahdeblah: happy to hear alternative suggestions to ^^ [23:56] axw: Pretty sure there's a bug about that which says that destroying should be non-default. :-) [23:56] blahdeblah: AFAIK there's only a bug that says destroying an application/unit shouldn't destroy the storage, and that's the case now [23:57] Ah, that might be the one I was thinking of. [23:58] axw: No, I'm fine with `remove-storage --no-destroy` - it's the methods internally that are called DestroyX but have a parameter that means that they don't destroy the x. [23:58] babbageclunk: ok. probably the API method, I'll check the review [23:58] I was referring more to the general case where code does X by default and then someone puts in an option to toggle the behaviour, and calls it "disable_X" which defaults to false rather than "enable_X" and defaulting to true. It just makes the logic more complex for the user to understand. [23:58] axw: I'd rather they were named in the same way as the command - RemoveX with an argument that says whether to also destroy. [23:59] babbageclunk: hmm I guess I'm OK with that. the main reason it's not Remote, is because of the distinction between Destroy and Remove in state