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
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
