Re: Charm layer index now on GitHub

2017-09-08 Thread Cory Johns 
Keep in mind that the charm-build update is really more housekeeping to
allow us to retire the old interfaces.juju.solutions domain entirely.  All
charm builds should now be using the new repo.  But of course testing of
that change is more than welcome.

On Fri, Sep 8, 2017 at 3:00 PM, Marco Ceppi 
wrote:

> This seems to have landed in candidate already, for those wanting to test
> on something other than edge.
>
> sudo snap refresh charm --channel candidate
>
> On Fri, Sep 8, 2017 at 2:59 PM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> 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
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm layer index now on GitHub

2017-09-08 Thread Marco Ceppi 
This seems to have landed in candidate already, for those wanting to test
on something other than edge.

sudo snap refresh charm --channel candidate

On Fri, Sep 8, 2017 at 2:59 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm layer index now on GitHub

2017-09-08 Thread 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

2017-09-08 Thread Rick Harding 
+1 awesome work folks.

On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
>
> 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/mailman/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
>
-- 
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

2017-09-08 Thread 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

Charm snap is now strictly confined

2017-09-08 Thread Cory Johns 
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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Charm layer index now on GitHub

2017-09-08 Thread Cory Johns 
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

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

2017-09-08 Thread 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

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

2017-09-08 Thread Sandor Zeestraten 
Hey Burton,

Where can I find the docs on these new bundle options (include-file and
include-base64) and the --bundle-config option?

Have a nice weekend
--
Sandor Zeestraten

On Fri, Sep 8, 2017 at 9: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

We are excited to announce the release of Juju 2.2.3!

2017-09-08 Thread Burton Swan 
## 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