Network Space Binding Changes After Deployment or Upgrades

[Dmitrii Shcherbakov]

Hi everybody,

As far as I can see, there is no way to change a network space binding or
add a new one after a charm has been deployed.

What I encountered is a situation where you either want to add a new
endpoint (and bind it to a space) after a charm upgrade or modify an
existing one. With the current approach this is not possible without a full
redeployment of an application (remove-application -> deploy & bind ->
add-unit).

However, for deployments with large uptime requirements this is not a
feasible solution.

My view of the problem:

   - Juju doesn't know how a charm code have used binding information
   during a deployment;
   - Juju can expose an event which should be handled in the charm code;
   - There is a distinction between "binding-changed" and "upgrade" events
   as the latter may include binding changes but needs a mechanism to learn
   which bindings have changed.

--
Only the deployment-related code has handling of bindings:
https://github.com/juju/juju/blob/master/cmd/juju/application/deploy.go#L615
https://github.com/juju/juju/blob/staging/cmd/juju/application/bundle.go#L382
<https://github.com/juju/juju/blob/master/cmd/juju/application/deploy.go#L615>

Nothing about bindings here:
https://github.com/juju/juju/blob/master/cmd/juju/application/upgradecharm.go
---

I realize that this is a complex feature and will require code on the charm
side but I think it is important as it makes deployments less rigid and
more update-friendly.

Has it been discussed before?

Any feedback is appreciated - thanks in advance.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170327/6d51be14/attachment.html>