<div dir="ltr"><div>As we discussed how the Juju network model was going to map network spaces into IP addresses for charms, the Openstack charmers noted that it wasn't sufficient to just provide networking configuration for existing relations. There were several places where the Openstack charms needed a way to expose a workload onto the network, but whose configuration information was already well handled by the existing relations. They liked being able to move the mapping of subnets,etc from being just config in a charm into being pieces that system operators could map at deploy time.</div><div><br></div><div>The best solution that we've come up with is to add a new section to charm metadata.yaml. At a similar level to provides/requires/tags we'd add a field for "extra-bindings". Entries in this list end up being available for "juju deploy charm --bind <binding>=<net-space>", but don't have the same set of charm hooks that will be fired for their lifecycle.</div><div><br></div><div>We're pretty happy with what we've come up with after a fair amount of trying out different possibilities. We'd like to open it up to a bit wider discussion in case there are use cases that we didn't realize we missed. (We certainly know about a few cases that we are intentionally not supporting with this, in an effort to preserve compatibility and simplicity.)</div><div><br></div><div>If you're interested in this space, let us know what you think,</div><div><a href=" https://docs.google.com/document/d/1pKORpWSitOk7C_HMNBaO36-Ht1b3lT86bOWTy9jPMDQ/edit?usp=sharing">Juju Extra Network Bindings</a><br></div><div><br></div><div>Thanks,</div><div>John</div><div>=:-></div><div><br></div><div>PS> For James Page and other's that have already looked at this document, can you give it a once over. I pulled out some of the alternatives to make it more focused, and want to make sure that I haven't lost cohesion in the final draft.</div></div>