Re: Request to support to work with Juju
Hello, are you using the local provider? If so it can take several minutes to seed the initial download of the cloud image. You can find if the image was downloaded by checking /var/cache/lxc/cloud-* where * is precise, trusty, or the series you're trying to deploy. Images are downloaded only when you first attempt to deploy and then cached in that directory. Once cached it will attempt to build a LXC template (`sudo lxc-ls --fancy` should produce output with something like juju-trusty-lxc-template) if you don't see anything in the cache directory, or in the lxc-ls output, or you do, or you're not using local provider, let us know. Also, the version of juju you're using may also help us identify issues you're having. Thanks, Marco Ceppi On Thu, Apr 30, 2015 at 3:52 AM dinesh.senap...@wipro.com wrote: Hi, I have been working on Juju for last 2 weeks. There are some blockages while working on it like: 1.In *juju bootstrap. *It is *not downloading the disc image* itself. But when I check juju status, it is showing machine-0 (started state). 2.And when I try to *deploy any service*, it adding the charm but the new instance is staying in *pending state* forever and it is not *creating the template*. Kindly help me figure out the way to solve the above problems. Thanks and Regards, Dinesh Kumar Senapaty, Wipro Technologies. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Request to support to work with Juju
Hi, I have been working on Juju for last 2 weeks. There are some blockages while working on it like: 1.In juju bootstrap. It is not downloading the disc image itself. But when I check juju status, it is showing machine-0 (started state). 2.And when I try to deploy any service, it adding the charm but the new instance is staying in pending state forever and it is not creating the template. Kindly help me figure out the way to solve the above problems. Thanks and Regards, Dinesh Kumar Senapaty, Wipro Technologies. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
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 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 nate.fi...@canonical.com 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 ian.bo...@canonical.com 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?
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 nate.fi...@canonical.com 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 nate.fi...@canonical.com 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 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 nate.fi...@canonical.com 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/04/15 21:04, roger peppe wrote: On 30 April 2015 at 11:55, Ian Booth ian.bo...@canonical.com 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: your-project-id private-key: your-private-key client-email: your-client-email client-id: your-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/project-id/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/project-id/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/project-name/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 backup 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 on server backup id To obtain a list of the
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 cur...@canonical.com 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: your-project-id private-key: your-private-key client-email: your-client-email client-id: your-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/project-id/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/project-id/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/project-name/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 backup file Which will
