[03:52] <wallyworld> kelvinliu: small azure PR if you have time https://github.com/juju/juju/pull/11965
[04:03] <kelvinliu> wallyworld:  lgtm ty
[04:04] <wallyworld> gr8 ty
[06:40] <flxfoo> Hi all,
[06:40] <flxfoo> Quick questions
[06:40] <flxfoo> About controller and amazon
[06:41] <flxfoo> when stopping an instance, amazon release public ip. So if I have a juju client trying to connect with a (re)started controller , it can not reach it as public ip changed.
[06:41] <flxfoo> how do you guys deal with that?
[06:42] <flxfoo> I can change .local/share/juju/controllers.yaml file, but if so, is there any side effect due to the change of the controller public ip?
[06:43] <flxfoo> (I sniffed that juju instances communicate with controller through the public ip and private ip)
[06:44] <flxfoo> sumarized question would be: does controller public ip changes impact anything else like models or instances?
[06:52] <wallyworld> flxfoo: if the controller has been set up in a HA cluster, the IP addresses of the controllers are used to configure the mongo replicaset. for a single controller, changing the IP in controllers.yaml should be ok. for HA controllers, I think the new IP address would get shared with the other controllers when it restarts so will hopefully be ok in that case too
[06:54] <flxfoo> wallyworld:thanks, the controller is not under HA.
[06:54] <flxfoo> wallyworld:let's say just one controller...
[06:54] <wallyworld> should be ok then
[06:55] <flxfoo> wallyworld:a quick one (on top)
[06:56] <flxfoo> it is possible to use Elastic IP amazon product, and that IP would not then change. Is there a way to set that IP when bootstrapping a controller?
[06:56] <flxfoo> (I am pretty sure it is not) I did not find any kind of setting in bottstrap constraint related to that (in aws mode)
[09:35] <achilleasa> manadart: small PR https://github.com/juju/charm/pull/315
[10:15] <achilleasa> manadart: I wonder whether the (expose-to-spaces and expose-to-cidrs) parameters should only be allowed to be specified via an overlay...
[10:15] <achilleasa> the exposed-endpoints one is fine to include in a generic bundle
[10:15] <achilleasa> but spaces are deployment-specific, right?
[11:17] <icey> any ideas why, on juju 2.8.1, I'd have models get stuck destroying: 'zaza-ad0927e3d0a7*  serverstack/serverstack  openstack  destroying         0      -  admin   38 minutes ago'?
[11:17] <icey> it sesms fairly reliable for me, and if I create another model, no resources from that model will be deletable
[11:49] <achilleasa> manadart: followup PR to charm https://github.com/juju/charm/pull/316
[12:20] <achilleasa> manadart: another small one, this time for bundlechanges https://github.com/juju/bundlechanges/pull/66
[12:41] <achilleasa> manadart: is this ok or do we need more tests? https://github.com/juju/bundlechanges/pull/66/commits/1f1bf821bf24d7909faf36aff648f87a9aafe129
[12:44] <manadart> achilleasa: Good to go, I think.
[12:45] <achilleasa> I think I may need to do the same for pylibjuju so I created a card so as not to forget and will check with Simon when he's back
[14:22] <jam> morning all
[15:40] <pmatulis> is there any reason why i should not use --force with destroy-model ?
=== tamas_erdei is now known as terdei
[20:49] <jam> @pmatulis, generally we don't recommend --force by default, as it allows us to bypass certain checks and may leave things behind like security rules/storage/etc.
[20:49] <jam> I don't know the specifics, but usually --force says "if I get a failure trying to cleanup a resource, keep tearing down the rest"
[22:46] <pmatulis> jam, alright