Re: previously valid amazon environment now invalid?
I would say the exact opposite. We *cannot* sacrifice the usability and reliability of the product for all our future users just to keep a few current users from having to update their scripts ever. I am sure there will come a day when we decide that there is a change that makes the client significantly better (safer/easier/more reliable), which warrants breaking CLI compatibility. We did this with destroy-environment fairly recently. It was far too easy to destroy the wrong environment by accident if you ran destroy-environment and weren't switched to the environment you thought you were in, so we changed the command to require you to type in the environment name. If someone needs 1.18 CLI compatibility, they can use 1.18. It's that simple. We're maintaining API compatibility for just this reason. If they don't want the binary to change, they shouldn't update it (or should just rename it to juju-1.18 or something). We shouldn't break the CLI willy-nilly, but given sufficient reason, it can, and should change, IMO. I suppose in theory we could have a compatiblity mode where you set JUJU_118_COMPAT and the CLI functions just like 1.18, but given the fact that they can just use 1.18, that seems like a lot of effort for little benefit. On Apr 29, 2015 6:29 PM, "Michael Hudson-Doyle" < michael.hud...@canonical.com> wrote: > On 30 April 2015 at 07:40, Nate Finch wrote: > > We have done it before. As Roger said, there is/was a convention to do a > > three step process to deprecate old command line functionality. > > > > There's a big difference between what the command line looks like, and > > keeping compatibility with 1.18. We might want to preserve both, but > > they're not the same thing. > > I would say that they are the same thing. > > > For example, a 1.25 client that renames --constraints as --require is > still > > compatible with 1.18, as long as it can read the environments.yaml, jenv, > > and communicate with the 1.18 server correctly. > > No. Remember that new juju versions go in their entirety into > -updates of the LTS release, which is enabled by default. We *cannot* > *cannot* *cannot* break the scripts of people who just install trusty > off the usb stick and let software updater do its thing. > > There is another path here, which would be to backport bugfixes only > into -updates. That would be a different kind of pain and someone > (not me) made the assessment that the pain of maintaining 100% > compatibility with the version that was included with the first LTS > release would be less than the pain of making targeted backports (and > although it wasn't me, I think they were probably right). > > (I guess a third option would be some kind of "trusty compatibility > mode" that is activated by looking at lsb-release or something but > that also sounds horrible). > > > I would not say that, by most people's assessment, "compatibility with > 1.18" > > is the same as "compatibility with bash scripts that scripted against a > 1.18 > > client". > > Er. I'm pretty sure IS would disagree. > > Cheers, > mwh > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
I don't want to bore on and on about this, but one thing. On 30 April 2015 at 22:06, Nate Finch wrote: > If someone needs 1.18 CLI compatibility, they can use 1.18. It's that > simple. It's not that simple to do that though, as long as new versions of juju go into trusty-updates. You'd have to pin the version or do apt/preferences junk to prefer trusty over trusty-updates for juju-core or something. I'm not even sure, and I'm much more familiar with this sort of thing than it makes sense to assume our users are. Cheers, mwh -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
cp juju juju-1.18 On Thu, Apr 30, 2015 at 6:29 AM, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > I don't want to bore on and on about this, but one thing. > > On 30 April 2015 at 22:06, Nate Finch wrote: > > If someone needs 1.18 CLI compatibility, they can use 1.18. It's that > > simple. > > It's not that simple to do that though, as long as new versions of > juju go into trusty-updates. You'd have to pin the version or do > apt/preferences junk to prefer trusty over trusty-updates for > juju-core or something. I'm not even sure, and I'm much more familiar > with this sort of thing than it makes sense to assume our users are. > > Cheers, > mwh > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
At the Nuremberg sprint, I saw a demo of juju status that produced tabular format by default. I'm guessing that this issue means that can never actually be enabled. Although... it could be done backwardly compatibly (with a required environment variable or configuration file setting) and perhaps that shows the way forward here. We could allow a user to change a setting that enables backwardly incompatible features (such as removing environment fallback or producing tabular format status). That doesn't help with the code cruft issue though. On 30 April 2015 at 11:29, Michael Hudson-Doyle wrote: > I don't want to bore on and on about this, but one thing. > > On 30 April 2015 at 22:06, Nate Finch wrote: >> If someone needs 1.18 CLI compatibility, they can use 1.18. It's that >> simple. > > It's not that simple to do that though, as long as new versions of > juju go into trusty-updates. You'd have to pin the version or do > apt/preferences junk to prefer trusty over trusty-updates for > juju-core or something. I'm not even sure, and I'm much more familiar > with this sort of thing than it makes sense to assume our users are. > > Cheers, > mwh > > -- > 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
Re: previously valid amazon environment now invalid?
Right now, the default tabular output is behind a feature flag because it's experimental. We still need to decide how to allow users to have that output by default without the feature flag, but also without breaking 1.18 script compatibility. The best option IMO for this case is an env variable on the user's client machine since the change is a client only one and I don't want to pollute the CLI with --v2 type cruft and introduce yet another thing to support in the future. On 30/04/15 20:46, roger peppe wrote: > At the Nuremberg sprint, I saw a demo of juju status that produced > tabular format > by default. I'm guessing that this issue means that can never actually be > enabled. > > Although... it could be done backwardly compatibly (with a required > environment > variable or configuration file setting) and perhaps that shows the way forward > here. We could allow a user to change a setting that enables backwardly > incompatible features (such as removing environment fallback or > producing tabular format status). That doesn't help with the code cruft issue > though. > > > On 30 April 2015 at 11:29, Michael Hudson-Doyle > wrote: >> I don't want to bore on and on about this, but one thing. >> >> On 30 April 2015 at 22:06, Nate Finch wrote: >>> If someone needs 1.18 CLI compatibility, they can use 1.18. It's that >>> simple. >> >> It's not that simple to do that though, as long as new versions of >> juju go into trusty-updates. You'd have to pin the version or do >> apt/preferences junk to prefer trusty over trusty-updates for >> juju-core or something. I'm not even sure, and I'm much more familiar >> with this sort of thing than it makes sense to assume our users are. >> >> Cheers, >> mwh >> >> -- >> 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
Re: previously valid amazon environment now invalid?
On 30 April 2015 at 11:55, Ian Booth wrote: > Right now, the default tabular output is behind a feature flag because it's > experimental. We still need to decide how to allow users to have that output > by > default without the feature flag, but also without breaking 1.18 script > compatibility. The best option IMO for this case is an env variable on the > user's client machine since the change is a client only one and I don't want > to > pollute the CLI with --v2 type cruft and introduce yet another thing to > support > in the future. The danger here is that we end up with 100 environment variables, each tweaking some aspect of the Juju client's behaviour, and that debugging becomes hard because every user has some uniquely different combination of settings. Perhaps a single environment variable, say JUJU_COMPAT, defining the oldest version required for backward compatibility, might work here? The default value would be whatever is the oldest version that we currently support. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
On 30/04/15 21:04, roger peppe wrote: > On 30 April 2015 at 11:55, Ian Booth wrote: >> Right now, the default tabular output is behind a feature flag because it's >> experimental. We still need to decide how to allow users to have that output >> by >> default without the feature flag, but also without breaking 1.18 script >> compatibility. The best option IMO for this case is an env variable on the >> user's client machine since the change is a client only one and I don't want >> to >> pollute the CLI with --v2 type cruft and introduce yet another thing to >> support >> in the future. > > The danger here is that we end up with 100 environment variables, each > tweaking some aspect of the Juju client's behaviour, and that > debugging becomes hard because every user has some > uniquely different combination of settings. > > Perhaps a single environment variable, say JUJU_COMPAT, > defining the oldest version required for backward compatibility, > might work here? The default value would be whatever > is the oldest version that we currently support. > Agreed. That's what I was alluding to with the --v2 arg example. When Juju 2.0 ships we can turn on the new behaviour by default. Until then, people should have an easy way to choose the new behaviour if they want to use it. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: previously valid amazon environment now invalid?
On Thu, 30 Apr 2015, Nate Finch wrote: > If someone needs 1.18 CLI compatibility, they can use 1.18. It's that > simple. We're maintaining API compatibility for just this reason. If they > don't want the binary to change, they shouldn't update it (or should just > rename it to juju-1.18 or something). > > We shouldn't break the CLI willy-nilly, but given sufficient reason, it > can, and should change, IMO. This is something we should really think long/hard about. Users running trusty expect an LTS release to be safe to upgrade to. As long as Juju versions are backported to LTS releases Juju has the responsibility of being repeatable to those LTS users and their deployment and management scripts. It sucks, but it's the cost of getting the newer releases into the LTS product. That being said, the cli is an API. It's the user facing API. Users don't care about how the internals between the client and server work, as long as the client is working for them. APIs can have new endpoints added without issue as there's no risk to breakage of the API usage. I think if we look at the CLI as an API and treat backward incompatible changes as 'needs a version bump' then it'll help identity the points where we need to look at some sort of way to do 'compatibility mode' or such. Rick -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Juju stable 1.23.2 is released
# juju-core 1.23.2 A new stable release of Juju, juju-core 1.23.2, is now available. This release replaces version 1.22.1. ## Getting Juju juju-core 1.23.2 is available for vivid and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Windows and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/1.23.2 ## Notable Changes * New Support for Google Compute Engine (GCE) * Support for systemd (and Vivid) * New Style Restore * Improved Proxy Support for Restrictive Networks * New Charm Actions * New blocks and Messages. * Experimental: Service Leader Elections * Experimental: Addressable LXC Containers and KVM Instances on AWS and MAAS ### New Support for Google Compute Engine (GCE) A new provider has been added that supports hosting a Juju environment in GCE. This feature leverages the support for Ubuntu cloud-images that GCE added late 2014. It uses Google's GCE API to interact with your account there. API authentication credentials, as well as other config options, must be added to your environments.yaml file before running 'juju bootstrap'. The different options are described below. The basic config options in your environments.yaml will look like this: my-gce: type: gce project-id: private-key: client-email: client-id: The values in angle brackets need to be replaced with your GCE information. 'project-id' must identify a GCE project that already exists before you run "juju bootstrap". This means creating a new one through the developer console (https://console.developers.google.com/project) before bootstrapping Juju. To make it easier to quickly identify in your GCE console, we recommend that the name start with 'juju-' and that it include the environment name you are planning to use. You could also use an existing project but we recommend against that if possible. Using a new project will make it easier for you to manage the environment's resources as well as to track the environment's cost and resource usage. 'private-key', 'client-email', and 'client-id' are your GCE OAuth credentials. These details are associated with the 'service account' of the GCE project you will use for your Juju environment. For each GCE project, a service account is set up automatically when you create your project. Juju uses that service account to connect to the GCE API and does so with the proper authentication scope. After you have created the project go to the following URL to get the credentials to use in environments.yaml: If you extracted the 'private-key' by hand from the GCE project json, change "\u003d" to "=". https://console.developers.google.com/project//apiui/credential For more information please refer to https://developers.google.com/accounts/docs/OAuth2ServiceAccount#creatinganaccount and https://developers.google.com/accounts/docs/OAuth2#serviceaccount. If the project's service account has any permissions problems go to the following page to fix them: https://console.developers.google.com/project//permissions The GCE API should already be activated for the project. It it isn't, go to the following URL in your console: https://console.developers.google.com/project//apiui/api Also see step 2 on https://cloud.google.com/compute/docs/api/how-tos/authorization. The following config options in your environments.yaml file are optional: region - (default us-central1) The location to place the environment. image-endpoint - (default https://www.googleapis.com) This is where Juju will look for disk images when provisioning a new instance on GCE. All Juju 1.23 provider capabilities are available for GCE except for networking. ### Support for systemd (and Vivid) In addition to upstart, Juju now supports Ubuntu hosts using systemd as their init system. Support for systemd allows Juju to run on Ubuntu 15.04 (Vivid Vervet), which is the first Ubuntu release to boot with systemd. This means you can bootstrap Juju on a Vivid host. Note that the charm store (jujucharms.com) only support LTS releases. You can develop and test vivid charms in a local charm repository. ### New Style Restore You can now restore a backup with the new 'backups restore' command, which is more reliable and fast. New restore supports backups generated with the deprecated Juju backup plugin and with the recently added 'juju backups create' command. You can restore from a local backup file like so: juju backups restore [-b] --file Which will optionally bootstrap a new state server, upload a backup file and restore it. The -b option will fail if there is a running state server. You can also restore from a backup stored on the state-server: juju backups restore --id To obtain a list of the existing backups in the state-server you can use: juju backups list ### Improved Proxy Support for Restrictive Net
Re: Juju stable 1.23.2 is released
\o/ Thanks for the hard work on this. I can't wait to give all these new features a spin. -Antonio On Thu, Apr 30, 2015 at 8:41 PM, Curtis Hovey-Canonical wrote: > # juju-core 1.23.2 > > A new stable release of Juju, juju-core 1.23.2, is now available. > This release replaces version 1.22.1. > > > ## Getting Juju > > juju-core 1.23.2 is available for vivid and backported to earlier > series in the following PPA: > > https://launchpad.net/~juju/+archive/stable > > Windows and OS X users will find installers at: > > https://launchpad.net/juju-core/+milestone/1.23.2 > > > ## Notable Changes > > * New Support for Google Compute Engine (GCE) > * Support for systemd (and Vivid) > * New Style Restore > * Improved Proxy Support for Restrictive Networks > * New Charm Actions > * New blocks and Messages. > * Experimental: Service Leader Elections > * Experimental: Addressable LXC Containers and KVM Instances on AWS and MAAS > > > ### New Support for Google Compute Engine (GCE) > > A new provider has been added that supports hosting a Juju environment > in GCE. This feature leverages the support for Ubuntu cloud-images that > GCE added late 2014. It uses Google's GCE API to interact with your > account there. API authentication credentials, as well as other config > options, must be added to your environments.yaml file before running > 'juju bootstrap'. The different options are described below. > > The basic config options in your environments.yaml will look like this: > > my-gce: > type: gce > project-id: > private-key: > client-email: > client-id: > > The values in angle brackets need to be replaced with your GCE > information. > > 'project-id' must identify a GCE project that already exists before you > run "juju bootstrap". This means creating a new one through the > developer console (https://console.developers.google.com/project) before > bootstrapping Juju. To make it easier to quickly identify in your GCE > console, we recommend that the name start with 'juju-' and that it > include the environment name you are planning to use. You could also > use an existing project but we recommend against that if possible. > Using a new project will make it easier for you to manage the > environment's resources as well as to track the environment's cost and > resource usage. > > 'private-key', 'client-email', and 'client-id' are your GCE OAuth > credentials. These details are associated with the 'service account' of > the GCE project you will use for your Juju environment. For each GCE > project, a service account is set up automatically when you create > your project. Juju uses that service account to connect to the GCE API > and does so with the proper authentication scope. After you have > created the project go to the following URL to get the > credentials to use in environments.yaml: > > If you extracted the 'private-key' by hand from the GCE project json, > change "\u003d" to "=". > > > https://console.developers.google.com/project//apiui/credential > > For more information please refer to > > > https://developers.google.com/accounts/docs/OAuth2ServiceAccount#creatinganaccount > and https://developers.google.com/accounts/docs/OAuth2#serviceaccount. > > If the project's service account has any permissions problems go to the > following page to fix them: > > https://console.developers.google.com/project//permissions > > The GCE API should already be activated for the project. It it isn't, > go to the following URL in your console: > > https://console.developers.google.com/project//apiui/api > > Also see step 2 on > > https://cloud.google.com/compute/docs/api/how-tos/authorization. > > The following config options in your environments.yaml file are > optional: > > region - (default us-central1) The location to place the >environment. > image-endpoint - (default https://www.googleapis.com) This is >where Juju will look for disk images when provisioning a >new instance on GCE. > > All Juju 1.23 provider capabilities are available for GCE except for > networking. > > > ### Support for systemd (and Vivid) > > In addition to upstart, Juju now supports Ubuntu hosts using systemd as > their init system. > > Support for systemd allows Juju to run on Ubuntu 15.04 (Vivid Vervet), > which is the first Ubuntu release to boot with systemd. This means you > can bootstrap Juju on a Vivid host. Note that the charm store > (jujucharms.com) only support LTS releases. You can develop and test > vivid charms in a local charm repository. > > > ### New Style Restore > > You can now restore a backup with the new 'backups restore' command, > which is more reliable and fast. New restore supports backups generated > with the deprecated Juju backup plugin and with the recently added 'juju > backups create' command. You can restore from a local backup file like > so: > > juju backups restore [-b] --file >