[01:51] <babbageclunk> timClicks: could you review this plz? https://github.com/juju/juju/pull/10524
[03:52] <anastasiamac> a review plz   https://github.com/juju/juju/pull/10526
[03:58] <anastasiamac> wallyworld: ^^
[04:40] <hpidcock> review plz https://github.com/juju/juju/pull/10527
[05:06] <thumper> wallyworld: https://bugs.launchpad.net/bugs/1839970 could use a comment
[05:06] <mup> Bug #1839970: Unpredictable behaviour selecting Unit public IP address <juju:New> <https://launchpad.net/bugs/1839970>
[05:06] <wallyworld> ok
[05:06] <wallyworld> hpidcock: looking
[05:10] <wallyworld> hpidcock: why not filter out the manual provider for kuku
[05:11] <hpidcock> wallyworld: yeah good point, I was just considering that you should always be able to bootstrap manually
[05:11] <hpidcock> I'll make the change
[05:12] <wallyworld> awesome
[05:13] <wallyworld> thumper: i don't have an answer off the top of my head for that network question, will have to go code diving
[05:13] <thumper> it may be the public address shown in status
[05:15] <wallyworld> there's logic used to categorise and select the "best" default public address
[05:15] <wallyworld> somewhere
[05:17] <wallyworld> hpidcock: another option is to always have manual *except* when just k8s provider is specified
[05:18] <wallyworld> what's there will work though
[05:26] <thumper> wallyworld: bug 1813025 was assigned to you back in jan
[05:26] <mup> Bug #1813025: new pods do not run due to rbac issues? <juju:New for wallyworld> <https://launchpad.net/bugs/1813025>
[05:27] <thumper> can you triage the bug?
[09:20] <achilleasa> stickupkid: about that bundlechanges API call for the python bits... did we version it when we landed the cmr changes? I certainly haven't done so for the channel stuff... so I don't have a clean way to decide whether I need to skip the channel integration test or not
[09:26] <stickupkid> achilleasa, so no, pythonlib is actually a head of juju CLI in this regard, but it should be fine
[09:31] <stickupkid> CR anyone? https://github.com/juju/cmd/pull/67
[09:31] <achilleasa> stickupkid: looking ^^^
[09:31] <stickupkid> it's a nice and simple one
[09:35] <achilleasa> stickupkid: quick question: how would the error on L629 be printed out?
[09:36] <stickupkid> achilleasa, same as previous `super normal`
[09:36] <achilleasa> but what about the "unrecognized command: " prefix?
[09:36] <stickupkid> ah, d'ho
[09:36] <stickupkid> will fix that now
[09:38] <stickupkid> achilleasa, updated
[09:40] <achilleasa> stickupkid: approved
[09:41] <stickupkid> achilleasa, ta
[10:23] <stickupkid> achilleasa, considering you did the previous PR check, mind if you do this one https://github.com/juju/juju/pull/10522
[10:24] <achilleasa> stickupkid: sure thing
[11:54] <achilleasa> stickupkid: can you take a look at https://github.com/juju/python-libjuju/pull/340 ?
[12:32] <rick_h> stickupkid:  if you get a sec can you peek at https://discourse.jujucharms.com/t/lxd-woes/1928 please?
[13:59] <stickupkid> achilleasa, which version of python are you using?
[13:59] <stickupkid> achilleasa, i'm wondering why the type definitions https://github.com/juju/python-libjuju/pull/340/files#diff-66da3249a52dcd990fa827c60a5360caL665
[14:00] <stickupkid> are missing
[14:03] <achilleasa> stickupkid: 3.6.7
[16:08] <stickupkid> who wants a horrid code review ? https://github.com/juju/juju/pull/10529
[16:10] <rick_h> stickupkid:  I'd like to poke several people on those please
[16:10] <stickupkid> rick_h, sending an email
[16:10] <rick_h> stickupkid:  can you setup a juju-crew list and ask folks to go through
[16:10] <rick_h> stickupkid:  +1
[16:19] <magicaltrout> hello folks
[16:20] <magicaltrout> anyone got any clue how this openstack-ingration charm is supposed to work?
[16:20] <magicaltrout> or its requirements
[16:38] <pmatulis> magicaltrout, that integrator charm in particular or integrator charms in general?
[16:38] <magicaltrout> the openstack one pmatulis
[16:39] <magicaltrout> i can't get it to work, so i'm trying to find out if its still how you do things
[16:39] <magicaltrout> or if its retired and i'm just reading old docs
[16:41] <pmatulis> magicaltrout, afaik, integrator charms are the way to go. what is not working? there should be something in the juju logs
[16:42] <magicaltrout> i documented it here pmatulis https://discourse.jujucharms.com/t/what-are-the-requirements-for-this-openstack-integrator-charm/1932/2
[16:43] <magicaltrout> cause when i test the examples they seem to generally just be broken
[16:51] <pmatulis> magicaltrout, ohh. first issue looks like a storage class simply does not exist. so maybe something else you need to do (not openstack-itself related). i don't know about the 2nd issue
[16:51] <rick_h> magicaltrout:  it's definitely not deprecated. We use it for CDK setup on OpenStack and we're doing that for customers/etc.
[16:52] <rick_h> magicaltrout:  sounds like assumptions/etc that might need love. I'd suggest filing bugs (don't I always...) but it should be alive/well.
[16:58] <magicaltrout> thanks rick_h pmatulis i'll dig more then. I don't know what it tries to do for loadbalancing i'll look at the code as itrs not dead
[16:58] <magicaltrout> didn't want to go down a rabbit hole to be told there's a better/newer way :0
[16:58] <rick_h> magicaltrout:  :) what? That never happens :P
[16:59] <magicaltrout> hello pinocchio!
[16:59] <rick_h> magicaltrout:  one of these days we should chat. long time no catch up
[17:01] <rick_h> magicaltrout:  I'm not seeing anything in the charm doing loadbalancing
[17:01] <magicaltrout> indeed rick_h ! I'm in the process of exfiltrating from 4 months of chaos and getting back to doing some charming stuff and upgrading the data charms.
[17:01] <rick_h> magicaltrout:  and the charm readme just as kubectl notes vs anything charm/config
[17:01] <magicaltrout> it just sets up kubernetes for the external loadbalancer
[17:01] <rick_h> magicaltrout:  nice, congrats on getting through the tunnel
[17:02] <magicaltrout> but i'm not entirely sure what its complaining about
[17:02] <magicaltrout> as far as I can tell I filled in the details correctly, so I'm assuming something isn't configured on the openstack side
[20:24] <dannf> i'm trying to use juju as a testing backend for different ubuntu releases - unfortunately i'm finding that i can't e.g. test 19.04 because no tools are available. is there a workaround for that?
[20:25] <timClicks> dannf: you can force which series you're deploying
[20:25] <dannf> timClicks: yeah, i can force it, and that appears to override charm restrictions, but then i get:
[20:25] <dannf> Machine  State  DNS  Inst id  Series  AZ  Message
[20:25] <dannf> 0        down        pending  disco       no matching agent binaries available
[20:26] <timClicks> hrm that's strange .... just a second, I'll check something
[20:27] <timClicks> dannf: which juju version are you running?
[20:27] <dannf> 2.3.7-xenial-amd64
[20:27]  * thumper cringes
[20:27] <dannf> should i switch to the snap?
[20:27] <thumper> dannf: can you use the juju snap?
[20:27] <thumper> yeah
[20:28]  * dannf honestly thought i was using the snap until you asked :)
[20:28]  * timClicks is glad I did
[20:28] <timClicks> (ask about the version, anyway!)
[23:16] <babbageclunk> timClicks: did you work out what was happening with the extendDisks failing? I've got the cleanup sorted. (Getting the tests right was the fiddly bit as usual.)
[23:21] <babbageclunk> timClicks: well, that and my machine forgetting it could boot to linux
[23:40] <timClicks> babbageclunk: no, I wasn't able to diagnose what the issue was
[23:41] <babbageclunk> timClicks: can you take a look at this anyway? https://github.com/juju/juju/pull/10530
[23:41] <timClicks> oh sure :)
[23:42] <babbageclunk> timClicks: I'm just testing it out now - will try reproducing the thing you saw anyway