[01:06] <kelvinliu> wallyworld: jujuqabot/jujud-operator:2.8-beta1.3113  image pull failed
[01:06] <kelvinliu> wallyworld: ho?
[01:47] <kelvinliu> wallyworld: https://github.com/juju/juju/pull/11084 got his pr to fix CaaS bootstrap on develop, +1 plz
[04:12] <wallyworld> kelvinliu: am in meeting but i will ping soon to talk about the build num PR
[04:13] <kelvinliu> wallyworld: yep, gonna grab some food, back in ~15mins
[04:27] <kelvinliu> wallyworld: im back, ping me when ur ready.
[05:07] <wallyworld> kelvinliu: free now?
[05:08] <kelvinliu> yes
[05:08] <wallyworld> ok, am in standup
[10:26] <stickupkid> manadart, https://github.com/juju/python-libjuju/pull/381
[10:30] <manadart> stickupkid: Done. I have uncovered a an issue with CMR and the allwatcher, which is affecting the model cache :(
[10:30] <stickupkid> manadart, YESSS! ho?
[10:35] <manadart> stickupkid: Yep.
[12:52] <stickupkid> rick_h, this will unblock pylibjuju for future jujus https://github.com/juju/python-libjuju/pull/382
[13:15] <icey> is it just me or does Juju not create security group rules for IPv6 when you open_port something? I don't see an option to do IPv6 either
[13:15] <icey> (on OpenStack)
[13:16] <rick_h> icey:  ipv6 and juju :( we don't officially support it honestly
[13:17] <hml> icey: it should, i remember seeing the code
[13:17] <hml> icey: but also what rick_h  said
[13:17] <icey> rick_h: color me sad; if there's IPv6 on the network, Juju shows that in the status, but opening the port doesn't seem to actually create the security group rule for it :-/
[13:18] <hml> icey: it could be that the security groups are created for ipv6 when a juju unit is created, but it doesn’t follow thru the open_port code
[13:19] <icey> hml: yeah - I see the egress rule created for 0.0.0.0/0 and ::/0, but the open_port ingress rule is only created for ipv4
[13:19] <icey> oh well, call it wishlist :)
[16:23] <nammn_de> manadart: are my thouhts correct? For finding all the bindings in that space I would do the following:  get all endpointsbindings, look at each binding map (inverse) and see whether the space is used. or do we have an easier/faster way given the database layout
[16:32] <manadart> nammn_de: That's how I understand it. achilleasa has been all up in that and might know an alternative.
[16:35]  * achilleasa thinks
[16:35] <achilleasa> nammn_de: is that for an application?
[16:36] <manadart> achilleasa: Yes.
[16:40] <achilleasa> nammn_de: I think the easiest approach is to create one of these: https://github.com/juju/juju/blob/develop/state/endpoint_bindings.go#L499 and then iterate the returned map from Map (for spaceIDs) or MapWithSpaceNames
[16:42] <achilleasa> (just pass nil as the last arg of the ctor to get what's in the DB)
[16:53] <nammn_de> achilleasa: great, thanks! Yeah was looking at the code you send before that. Was planning to do that similiarily
=== hml_ is now known as hml
=== sfeole is now known as sfeole_away
[18:16] <nammn_de> manadart achilleasa: can i always deduce the application name from the endpointbinding _id? e.g. "32fee8a8-650b-46ed-8664-4d91d99f4b7c:a#haproxy" -> haproxy this would reduce the queries i need to make
[18:19] <hml> nammn_de: https://github.com/juju/juju/blob/develop/state/endpoint_bindings.go#L272  so, yes
[18:20] <nammn_de> hml: great, thanks!
[18:20] <hml> nammn_de: but that’s not necessariily the best way to go
[18:20] <hml> nammn_de: usually there’s a better way than looking at a doc id
[18:21] <nammn_de> hml: my current approach to list all the applicationbindings using a space was the following: `get all endpoints  from collection` -> `check whether binding to that space exists` -> if yes ->  deduce application name
[18:22] <nammn_de> couldn't think of a shorter way to get all applications running with a space binding
[18:24] <hml> nammn_de: all endpoint bindings have a space.  even if it’s just the default
[18:24] <hml> nammn_de: depends on what you mean by “running”
[18:24] <hml> explicitly using?
[18:24] <nammn_de> hml: yeahh I meant by searching for a specific space
[18:24] <nammn_de> e.g. show-space
[18:24] <nammn_de> shows all applications bindings using that space
[18:25] <nammn_de> show-space db-space, should show all applications which have endpoints bound to db-space
[18:25] <nammn_de> so show-space _default(or alpha?) should show all, if nothing bind yet, i think
[18:27] <hml> nammn_de: bbiab, i have a phone call
[18:28] <nammn_de> hml: sure, thanks :)
[18:32] <hml> nammn_de: back phone call moved.
[18:32] <nammn_de> hml: we can HO quick
[18:32] <nammn_de> maybe more clear
[18:32] <hml> nammn_de: looks like there isn’t a clean way to do that query.
[18:33] <hml> nammn_de:  sure - daily?
[18:33] <nammn_de> hml: comming
[18:53] <roadmr> do newer jujus support ipv6?
[21:30] <evhan> Hi folks, I'm writing a bundle but juju isn't liking my YAML, saying that the "bundle overlay file used deprecated 'services' key, this is not valid for bundle overlay files". I've just tried again with `applications` and that seems to have worked. Is this the right fix?
[21:31] <rick_h> evhan:  yea, services were renamed to applications back in juju 2.0 and I think overlays came along and nudge folks in the right path
[21:31] <evhan> Cool, ty.
[21:43] <roadmr> do newer jujus support ipv6? 🤔
[21:44] <rick_h> roadmr:  it supports it by ignoring it basically. It's not fully supported tbh. If the machines come up with it we make sure not to go boom
[21:44] <rick_h> roadmr:  what are you trying to do?
[21:44] <roadmr> using juju on a network with ipv6 only? :)
[21:44] <rick_h> roadmr:  I think icey was asking about firewall support earlier today so curious if it's the same issue or something else?
[21:45] <rick_h> yea...not sure that's ever been done
[21:45] <roadmr> rick_h: something else - I think simpoir's home network (and all his configuration) are ipv6 and he was trying to use juju with lxd provider and got a "juju doesn't ipv6"
[21:45] <rick_h> at one point we had a customer driving it as a use case but then they didn't need it and it never got on the roadmap
[21:45] <rick_h> yea
[21:45] <roadmr> rick_h: no big deal tbh, mostly a "just curious, will it work?" kind of question :)
[21:46] <rick_h> no sorry, always wanted to get that going
[21:49] <roadmr> no problem :)
[21:50] <roadmr> at least I'm happy that the anarchy situation got resolved, apparently one of the controllers was reset and leaders were elected everywhere
[21:59] <babbageclunk> roadmr: sorry I didn't think to check the snapshots until after you'd blown away the model!
[21:59] <roadmr> babbageclunk: hehe no problem!
[21:59] <roadmr> fwiw we never redeployed - we got held up by the controller troubles, but when one of them was reset trying to solve that, leaders magically appeared
[22:03] <babbageclunk> roadmr: ah, yeah, that would do it too. It seems like the cause was unit 1816 still running (for some unknown reason). But if the controller went down, it wouldn't have been able to log back in, and might have removed itself from systemd. Would be worth checking the unit files on your machines?
[22:27] <roadmr> sure, I can check with verterok tomorrow