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
What's coming for Juju in 14.04
Hi everyone, Though we have UDS sessions on Juju and charms all week I think it's appropriate to share this one video as it covers the roadmap for Juju for this cycle. You can fast forward to 2:00 minute to get right to it: - http://www.youtube.com/watch?v=ZjzImjEinB8feature=sharet=2m -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- 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
