On Tue, Nov 19, 2013 at 8:43 PM, Tim Penhey <tim.pen...@canonical.com> wrote: > It was my understanding that the api server needs to be at least as > advanced as any client. > > This means that a 1.18 server should be able to support a 1.16.x client. > > However we don't support 1.18 clients on a 1.16.x server. > > Does this change your thinking?
Newer clients with older servers is going to happen. How will devops upgrade their production deployments? A. Nominate one deployment machine to go to 1.18. From another machine use juju 1.16 to call upgrade-juju. Run juju status on both machines to watch agent switch to the next version, or if they fail, intervene with the appropriate client? Scripting this is awkward (the kindest thing I can say). B. We package co-installable juju clients. The deployment machine installs juju1.16 and juju1.18. Devops and scripts take care to specify the client version? Devops remove the unused clients when they remember. I am not sure how this would work with Windows. I am certain it wont work with OS X because homebrew only builds the most recent stable release. Our current promise is that you can always upgrade to the next version. I think we need to ensure this case works from 16 and 18 clients. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
