Re: API compatibility policy and practices between juju versions
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
Re: API compatibility policy and practices between juju versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-20 20:15, Curtis Hovey-Canonical wrote: 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. Yes. I think that is one of the primary caveats for the we don't guarantee all cross version compatibility is that we *do* guarantee upgrade works. (It is the one blocker for making a .ODD release into a .EVEN, which has delayed 1.14 and 1.16, IIRC) John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKM4h8ACgkQJdeBCYSNAAN7lACguV6SMOTXennV++0Q27HLNGJN JisAnj+Kmh52B0v7IBWtYqsiCbLklTlY =BuMc -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
API compatibility policy and practices between juju versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Arbash Meinel wrote: I think that is one of the primary caveats for the we don't guarantee all cross version compatibility is that we *do* guarantee upgrade works. I think we should also support status, so that 1. You can determine when an upgrade has gone wrong 2. When an upgrade goes wrong, you know the IP address of the affected machine, so that you can SSH into it. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKND8YACgkQ0F+nu1YWqI01OgCfVr0Z4IDlccjuZ6uhJwxPJDCj LFYAn2fRRF+JffQFgROJMVDuD/XRhCdI =BoYX -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: API compatibility policy and practices between juju versions
I think that is a fair point. Especially right now when we haven't quite nailed getting provider secrets on first connect. John =:- On Nov 20, 2013 11:39 PM, Aaron Bentley aaron.bent...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Arbash Meinel wrote: I think that is one of the primary caveats for the we don't guarantee all cross version compatibility is that we *do* guarantee upgrade works. I think we should also support status, so that 1. You can determine when an upgrade has gone wrong 2. When an upgrade goes wrong, you know the IP address of the affected machine, so that you can SSH into it. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKND8YACgkQ0F+nu1YWqI01OgCfVr0Z4IDlccjuZ6uhJwxPJDCj LFYAn2fRRF+JffQFgROJMVDuD/XRhCdI =BoYX -END PGP SIGNATURE- -- 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
API compatibility policy and practices between juju versions
I am not sure if I am leading a discussion or just stating that we have a problem that I don't believe can be ever solved. We abandoned the release of 1.16.4 because we found it was incompatible with 1.16.3 https://bugs.launchpad.net/juju-core/+bug/1252469 API incompatability: ERROR no such request DestroyMachines on Client I now believe this bug is in the same class of problem: https://bugs.launchpad.net/juju-core/+bug/1250154 ERROR no such request EnvironmentGet on Client I suspect both bugs also mean that 1.18.x will be incompatible with 1.16.x 1. I think Juju selects the latest version at the patch-level because they are always cli/api compatible between clients and servers. We *require* 100% api/cli compatibility. This is the first bug. 2. I believe enterprises like our own IS will stagger minor upgrades. Over a period of weeks, 1.18.0 will be used with 1.16.3 and they require api/cli compatibility. This is bug two. Enforcing point 1 is tremendously hard. We would have an ever growing matrix of tests for the juju client-server combinations + a test for every patch landed to verify that the user can accomplish the task. We don't have the staff to do this. We are taking risks with each patch release. We are not enforcing point 2 at all. CI has found some bugs because it nominally acts like devops when it runs upgrade tests. Even when the upgrade fails, we attempt to scp the logs from the failing machine just like a devop would. Speaking for CI, we would never want a feature removed in a single release. The feature needs to be deprecated so that we. like all IS departments, have time adjust scripts as we transition from one version to the next. I think deprecated-for-one-release is hard. in the case of API every where, I think that means that we add api, but fallback to cli so that things like scp and terminate-machine always work across versions. The old way of doing something is removed after one minor release. I personally think a non-matching tools on bootstrap/depoy is crack. At least warn that the client and server do not match. I think we can promise status and upgrade-juju works between versions, allowing the devops to do the upgrade. The aborted 1.16.4 can do that, so I helped others build their own package and setup the private cloud to use just the version so that they could switch everything to the version that works best for them. -- 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
