[04:27] tlm: PR approved [13:28] Hi, could someone tell me where is network-get config stored, I've got a odd bug in ovn-chassis where complaing no network config found for binding data, I can see all interfaces in LXD are correct, there is a communication in other charms like nova-compute, never seen this one [16:27] mirek186: does it look like this: https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1710930. potentially same bug different charm [16:27] Bug #1710930: ERROR no network config found for binding "public" with enforce-ssl=true [16:31] mirek186: you might want to try #openstack-charms [19:21] hml: Thanks, it does but it turns out mapping between MAAS spaces and Juju got mixed up, I've changed one VLAN while few machines were alrady deployed. Sorted now. [19:21] mirek186: good news [19:56] hml: I've open a but anyway saying Juju should be able to check for correct network spaces on MAAS before deployment, it should not allow you to deploy into a container or host which hasn't got a correct space, but it does allow if it is a subordinate charm, that's how it all started. [19:58] mirek186: rgr [19:58] but doesn't the subordinate charm's space come from the principle charm space? [20:02] mirek186: i know juju does checking along the lines of what you’ve mentioned, it’ll be interesting to see where the problem lies. as pmatulis is asking, i’m not sure how the subordinates spaces are determined and verified [20:27] pmautils the principal charm hasn't got this space defined as a binding, it's ovn-chassie, nova-compute pair [20:28] The only way I found to allow ovn-chassis use overlay for DATA binding is to define overlay network on host where nova-compute is deployed then ovn-chassis as a subordinate charm deployed in container has access to it [20:29] But if overlay subnet dosn't exists on host but is required for subordinate it won't complain, at least it dosn't in mine