Re: Charm layer index now on GitHub

[Tim Van Steenburgh]

Fantastic, this is a great change - well done!

On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns  wrote:

> Greetings,
>
> Today we migrated the index of base and interface layers used to build
> charms over to the GitHub repository https://github.com/juju/layer-index.
> Hosting the index in GitHub provides better discoverability for layers, a
> better workflow for contributing layers, including more accountability for
> changes, and both more flexibility and more visibility with community
> contributions.  It also reduces our maintenance overhead and removes a
> point of failure.
>
> The change should be seamless to the build process, and the existing
> http://interfaces.juju.solutions/ site now redirects to the new repo.  An
> updated charm-build command is now in the edge channel which points
> directly to the new index, and the old site will eventually be taken down
> once that reaches the stable channel and some time has passed.
>
> I’m now happy to say, PRs welcome!
>
> --
> 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: Charm snap is now strictly confined

[Tim Van Steenburgh]

On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:

> good effort devs!
>

+1, thanks Cory.


>
> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>
>> Greetings,
>>
>> I just wanted to make a quick announcement that the charm snap is now
>> strictly confined on the stable channel (rev 17).  This fixes issues like
>> https://github.com/juju/charm-tools/issues/339 and
>> https://github.com/juju/charm-tools/issues/319 and prevents similar
>> issues from cropping up in the future.
>>
>> In general, this change should be pretty much transparent, with the one
>> caveat being that you can only build charms from under your HOME directory.
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: We are excited to announce the release of Juju 2.2.3!

[Tim Van Steenburgh]

The new bundle stuff is very useful, thanks Juju devs!

On Fri, Sep 8, 2017 at 3:43 AM, Burton Swan 
wrote:

> ## New and Improved
>
> * The remove-machine command has a --keep-instance flag which allows the
> cloud instance to be left running when the machine is removed from the Juju
> model
>
> * Bundles can now reference local resources by specifying a relative path
> (as can already be done for local charms).
>
> * Values in local bundles for options and annotations can now specify a
> file to be read for the specified value. This is to support charm options
> where the value is some structured content, such as a configuration file.
> For binary external files, such as binary certificates, there is an option
> to base64 encode the contents of the file so it can be used as a string
> value. The referenced file can include the path to the file. The file
> location is relative to the bundle file location. e.g.:
>
> applications:
> my-app:
> charm: some-charm
> options:
> config: include-file://my-config.yaml
> cert: include-base64://my-cert.crt
>
> * There is a new option for deploying bundles: --bundle-config. This
> configuration file needs to be a YAML file, and currently only supports
> applications as a top level key. The format of the applications is the same
> as applications section in the bundle. Any values specified for an
> application in the bundle-config file override those values defined in the
> bundle, with the exception of the map type values, where the maps are
> merged with preference given to the bundle-config. The purpose of this to
> allow the use of a common bundle definition, and have model specific
> configuration kept in a separate file. Option and annotation values
> specified in the bundle-config file can also use the include-file:// and
> include-base64:// directives mentioned above for local bundles. Paths
> specified are relative to the bundle-config file.
>
>
> For a list of all bugs fixed in this release, see
> https://launchpad.net/juju/+milestone/2.2.3
>
> ## How can I get it?
>
> The best way to get your hands on this release of Juju is to install it as
> a snap package (see https://snapcraft.io for more info on snaps).
>
>  snap install juju --classic
>
> Other packages are available for a variety of platforms. Please see the
> online documentation at https://jujucharms.com/docs/
> stable/reference-install
>
> Those subscribed to a snap channel should be automatically upgraded. If
> you’re using the ppa/homebrew, you should see an upgrade available.
>
> For highlights of this release, please see the documentation at
> https://jujucharms.com/docs/2.2/whats-new
>
> --
> 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

[ANN] Updated Python Juju Client

[Tim Van Steenburgh]

Hi everyone,

We've been working on a new python client for Juju. It's still in
development,
but we wanted to share the first bits to illicit feedback:
https://github.com/juju/python-libjuju

Features of this library include:

 * fully asynchronous - uses asyncio and async/await features of python 3.5
 * websocket-level bindings are programmatically generated (indirectly)
from the
   Juju golang code, ensuring full api coverage
 * provides an OO layer which encapsulates much of the websocket api and
   provides familiar nouns and verbs (e.g. Model.deploy(),
Application.add_unit(),
   etc.)

Caveats:

 * Juju 2+ only. Juju 1 support may be added in the future.
 * Requires Python 3.5+
 * Currently async-only. A synchronous wrapper will be provided in the
future.

If you want to try it out, take a look at the examples/ directory.
https://github.com/juju/python-libjuju/blob/master/examples/unitrun.py is a
fairly simple one that deploys a unit, runs a command on that unit, waits
for
and prints the results, then exits.

Any and all comments, questions, and contributions are welcomed.

Thanks,

Tim
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev