Extra Network Bindings for Charms

[John Meinel]

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.

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.

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.)

If you're interested in this space, let us know what you think,
Juju Extra Network Bindings
<https://docs.google.com/document/d/1pKORpWSitOk7C_HMNBaO36-Ht1b3lT86bOWTy9jPMDQ/edit?usp=sharing>

Thanks,
John
=:->

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160301/1a5392c4/attachment.html>