charm-helpers 0.9.1
Hello everyone! Ahead of the charmer summit we've released 0.9.1 (and 0.9.0) of charm-helpers. We typically don't announce these changes but I wanted to highlight a few of the new features as well as place a caveat for those who may have built a charm during a 40 minute window. # Highlights - charmhelpers.core.hookenv add support for application_version_set This is a new hook-tool added in an earlier 2.0 beta that allows you to set the version of the application running. It takes a single parameter, a string, that's meant to represent the app version - charmhelpers.core.host and charmhelpers.core.kernel are now supported on Ubuntu and CentOS charms. Big shout out to Denis Buliga from Cloudbase for landing this support. - Lots of smaller fixes to OpenStack and Storage plugins # Downside If you've managed to get `charmhelpers-0.9.0.tar.gz` in your wheelhouse directory for your built charm, you will need to run charm build again. There was a problem in the setup.py for the project which excluded a few packages. The project's been updated from distutils to setuptools and future proofed against this problem. Thanks, Marco Ceppi -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Juju GUI 2.1.12 released
The next version of the Juju GUI has been released! This release includes a number of fixes which bring it back in line with the recent changes in the Juju 2 betas which re-enables the ability to switch models from the GUI which was temporarily removed in the previous release. Other improvements include: - Bundles now use "applications" top level key instead of "services". - Use a different WebSocket connection for the model and controller. - Create New Model button moved into the user profile. - Deploying bundles with lxc placements automatically convert to lxd. - Multi-series subordinates now have their series locked to the series of the first related parent application. - (Fix) Local charms now deploy without issuing error about charm location. - (Fix) When relating to subordinates, invalid targets are now faded. To upgrade your existing models to use this version of the GUI: Juju 2 beta: - Download the *.bz2 from https://github.com/juju/juju-gui/releases/tag/2.1.12 - Run `juju upgrade-gui /path/to/bz2` - Run `juju gui --show-credentials` Juju 1: - juju upgrade-charm juju-gui We welcome any feedback you may have on the GUI, you can chat with us in #juju on irc.freenode.net or you can file issues here: https://github.com/juju/juju-gui/issues -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Deploying Xenial charms in LXD? Read this
On Thu, Sep 8, 2016 at 9:23 PM Marco Ceppi wrote: > Hey everyone, > > An issue was identified late yesterday for those deploying Xenial charms > to either the LXD provider or LXD instances in a cloud. > > The symptoms for this manifest as the LXD machine running is in a running > state (and has an IP address assigned) but the agent does not start. This > leaves the workload permanently stuck in a "Waiting for agent to > initialize" state. This problem originates from a problem in cloud-init and > systemd, being triggered by an update to the snapd package for xenial. > FYI this is not LXD-specific. I've just now seen the same thing happen on Azure. Thanks to James Beedy, from the community, for posting this workaround > which appears to be working consistently for the moment: > > juju set-model-config enable-os-refresh-update=false > juju set-model-config enable-os-upgrade=false > > > This should bypass the section of the cloud-init process that's causing > the hang at the moment. For those interested in tracking the bugs I believe > these are the two related ones for this problem: > > - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229 > - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692 > > I'll make sure to post an update when this has been resolved. > > Thanks, > Marco Ceppi > -- > canonical-juju mailing list > canonical-j...@lists.canonical.com > Modify settings or unsubscribe at: > https://lists.canonical.com/mailman/listinfo/canonical-juju > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Deploying Xenial charms in LXD? Read this
Hey everyone, An issue was identified late yesterday for those deploying Xenial charms to either the LXD provider or LXD instances in a cloud. The symptoms for this manifest as the LXD machine running is in a running state (and has an IP address assigned) but the agent does not start. This leaves the workload permanently stuck in a "Waiting for agent to initialize" state. This problem originates from a problem in cloud-init and systemd, being triggered by an update to the snapd package for xenial. Thanks to James Beedy, from the community, for posting this workaround which appears to be working consistently for the moment: juju set-model-config enable-os-refresh-update=false juju set-model-config enable-os-upgrade=false This should bypass the section of the cloud-init process that's causing the hang at the moment. For those interested in tracking the bugs I believe these are the two related ones for this problem: - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229 - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692 I'll make sure to post an update when this has been resolved. Thanks, Marco Ceppi -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Latest new about Juju master branch - upload-tools obsoleted
The use-agent option is planned. It just needs to be discussed a little more widely to make sure it's the most tasteful way to approach the problem. Also, following on from Nate's email, juju bootstrap does state very clearly what it is doing and from where the jujud agent comes etc. Of course, if you run --debug that info can get lost in a wall of text, but it is there, and is quite clear under normal circumstances. On 08/09/16 22:42, Casey Marshall wrote: > I discovered another trick that works: set the streams and urls to invalid > values in your bootstrap config. This will force Juju to use an already > compiled jujud in your $PATH. For example, bootstrap --config with: > > image-metadata-url: http://localhost > image-stream: nope > agent-metadata-url: http://localhost > agent-stream: nope > > I'd be happier if I could get this effect with a --use-agent=/path/to/jujud > option, but this works. > > On Wed, Sep 7, 2016 at 9:28 PM, Nate Finch wrote: > >> Just a note, because it wasn't clear to me - there are a couple cases >> where the automatic upload tools won't do what you want, if you use a >> version of juju you built locally. >> >> If you're not a developer or someone who builds juju from source, it's >> safe to ignore this email. >> >> *1. If the version of juju you're building is available in streams and you >> *want* to upload, you have to use --build-agent, because by default we >> won't upload. * >> This happens if you're purposely building an old release, or if QA just >> released a new build and you haven't pulled yet and/or master hasn't been >> updated with a new version number. --build-agent works like the old >> upload-tools, except it always rebuilds jujud, even if there's an existing >> jujud binary. >> >> *2. If you're building a version of the code that is not available in >> streams, and you *don't* want to upload, you must use >> --agent-version=.* >> This can happen if you want to deploy a known-good server version, but >> only have a dev client around. I use this to make sure I can reproduce >> bugs before testing my fixes. --agent-version works basically like the old >> default (non-upload) behavior, except you have to explicitly specify a juju >> version that exists in streams to deploy (e.g. --agent-version=2.0-beta17) >> >> >> Note that if you want to be *sure* that juju bootstrap always does what >> you expect it to, IMO you should always use either --build-agent (to >> upload) or --agent-version (to not upload), depending on your intent. The >> behavior of the bare juju bootstrap can change without warning (from >> uploading to not uploading) if a new version of jujud is pushed to streams >> that matches what you're building locally (which happens every time a new >> build is pushed to streams, until master is updated and you git pull and >> rebuild), and that can be really confusing if you are expecting your >> changes to be uploaded, and they're not. It also changes behavior if you >> switch from master (which always uploads) to a release tag (which never >> uploads), which while predictable, can be easy to forget. >> >> Related note, beta18 (which is in current master) and later versions of >> the client can't bootstrap with --agent-version 2.0-beta17 or earlier, due >> to a breaking change (you'll get an error about mismatching UUIDs). This >> type of breakage is rare, and generally should only happen during betas (or >> pre-beta), but it impacts us right now, so... yeah. >> >> -Nate >> >> >> >> -- >> canonical-juju mailing list >> canonical-j...@lists.canonical.com >> Modify settings or unsubscribe at: https://lists.canonical.com/ >> mailman/listinfo/canonical-juju >> >> > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Latest new about Juju master branch - upload-tools obsoleted
I discovered another trick that works: set the streams and urls to invalid values in your bootstrap config. This will force Juju to use an already compiled jujud in your $PATH. For example, bootstrap --config with: image-metadata-url: http://localhost image-stream: nope agent-metadata-url: http://localhost agent-stream: nope I'd be happier if I could get this effect with a --use-agent=/path/to/jujud option, but this works. On Wed, Sep 7, 2016 at 9:28 PM, Nate Finch wrote: > Just a note, because it wasn't clear to me - there are a couple cases > where the automatic upload tools won't do what you want, if you use a > version of juju you built locally. > > If you're not a developer or someone who builds juju from source, it's > safe to ignore this email. > > *1. If the version of juju you're building is available in streams and you > *want* to upload, you have to use --build-agent, because by default we > won't upload. * > This happens if you're purposely building an old release, or if QA just > released a new build and you haven't pulled yet and/or master hasn't been > updated with a new version number. --build-agent works like the old > upload-tools, except it always rebuilds jujud, even if there's an existing > jujud binary. > > *2. If you're building a version of the code that is not available in > streams, and you *don't* want to upload, you must use > --agent-version=.* > This can happen if you want to deploy a known-good server version, but > only have a dev client around. I use this to make sure I can reproduce > bugs before testing my fixes. --agent-version works basically like the old > default (non-upload) behavior, except you have to explicitly specify a juju > version that exists in streams to deploy (e.g. --agent-version=2.0-beta17) > > > Note that if you want to be *sure* that juju bootstrap always does what > you expect it to, IMO you should always use either --build-agent (to > upload) or --agent-version (to not upload), depending on your intent. The > behavior of the bare juju bootstrap can change without warning (from > uploading to not uploading) if a new version of jujud is pushed to streams > that matches what you're building locally (which happens every time a new > build is pushed to streams, until master is updated and you git pull and > rebuild), and that can be really confusing if you are expecting your > changes to be uploaded, and they're not. It also changes behavior if you > switch from master (which always uploads) to a release tag (which never > uploads), which while predictable, can be easy to forget. > > Related note, beta18 (which is in current master) and later versions of > the client can't bootstrap with --agent-version 2.0-beta17 or earlier, due > to a breaking change (you'll get an error about mismatching UUIDs). This > type of breakage is rare, and generally should only happen during betas (or > pre-beta), but it impacts us right now, so... yeah. > > -Nate > > > > -- > canonical-juju mailing list > canonical-j...@lists.canonical.com > Modify settings or unsubscribe at: https://lists.canonical.com/ > mailman/listinfo/canonical-juju > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
