httpbakery .Client overly restrictive on body - io.ReaderSeeker

Hi folks, I came across this recently while looking at sending tools and charms between two controllers. The local storage interface gives us an io.ReaderCloser. Unfortunately, we can't give that to the http client for the POST method as it needs an io.ReaderSeeker. I'd like to challenge the

Re: admin is dead, long live $USER

I think I did remove some of that code, because it wasn't being used and wasn't clear why it was there. Easy enough to put back in. Cheers, Andrew On Mon, Mar 7, 2016 at 8:40 AM Tim Penhey wrote: > Ah yeah... it is mostly coming back to me now. > > I actually have a

Re: Juju 2.0 and local charm deployment

So to clarify what we'll do. We'll support the same syntax in bundle files as we do for deploy. Deploys charm store charms: $ juju deploy cs:wordpress $ juju deploy wordpress Deploys a local charm from a directory: $ juju deploy ./charms/wordpress $ juju deploy ./wordpress So below deploys a

Re: Juju stable 1.25.4 is proposed for release

WOOT! Thank you to the teams for pushing hard to get this out! On Tue, Mar 8, 2016 at 2:17 PM, Curtis Hovey-Canonical wrote: > # juju-core 1.25.4 > > A new proposed stable release of Juju, juju-core 1.25.4, is now available. > This release may replace version 1.25.3 on

Juju stable 1.25.4 is proposed for release

# juju-core 1.25.4 A new proposed stable release of Juju, juju-core 1.25.4, is now available. This release may replace version 1.25.3 on Tuesday March 15. ## Getting Juju juju-core 1.25.4 is available for Xenial and backported to earlier series in the following PPA:

Re: Juju 2.0 and local charm deployment

Long term we want to have a pattern when the bundle is a directory with local charms in a directory next to the bundles.yaml file. We could not do this cleanly before the multi-series charms that are just getting out the door. I think that bundles with local charms will be suboptimal until we can