On Mon, Mar 27, 2017 at 3:31 PM, Dmitrii Shcherbakov < dmitrii.shcherba...@canonical.com> wrote:
> 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. > The one caveat here is that in 2.1.2+ if you used a 'default' binding (juju deploy --bind foo) then all new endpoints for a charm will also be bound into whatever the default was for that application. That is currently correct. We have been discussing it, and how we want to concretely model the evolution of spaces over time. One of the particular points of concern is whether we would ever want to allow multiple units of the same application to be configured differently. For example: $ juju deploy app --constraints mem=4G $ juju set-constraints app mem=2G $ juju add-unit app You'll now have 2 units, where they have different expected memory. However, we feel that supporting that for bindings would be a net negative, because it complicates the *user's* mental model of where everything exists. An other applications that relate to the app need more complex thoughts when it comes to "am I able to talk to all of the units?". Complications like that are what led to us not implementing rebinding from the beginning. Our current plan is to have some sort of "rebind an endpoint" command (name-to-be-determined juju set-binding, juju rebind, etc). This would include a sanity check that all of the units that are currently deployed have access to the space that you are requesting. eg: juju deploy app --bind foo --constraints spaces=baz juju rebind app blah=baz Would be allowed, because all units of "app" must be in both "foo" and "baz" spaces. We should also support "--bind" as a parameter to "juju upgrade-charm", since the set of endpoints that we know about can be changing, and you should be able to specify values for the new entries, rather than inherit the default and then need to be updated. The caveat is that if all units don't have access to the new space, then we should fail. Which would still let you "remove units not in the space I want" (which may be all of them), "rebind", "add-units back to however many I want". The other complexity that I know is lurking around the corner is that as soon as we have the ability to rebind, people are going to want to do: juju add-machine --constraints spaces=foo,bar juju deploy app --bind foo --to lxd:0 juju rebind app bar Which will require us to change the network bindings of a running container. Which is ultimately something I think we want, but will also likely not be in the first implementation of rebind. (For anything like an SDN we should be able to rebind to whatever spaces that machine can have access to, rather than what spaces it is currently connected to.) > 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? > It has certainly been discussed, we're just not there yet. John =:-> > > > Any feedback is appreciated - thanks in advance. > > Best Regards, > Dmitrii Shcherbakov > > Field Software Engineer > IRC (freenode): Dmitrii-Sh > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
