Upgrading multiseries Charm

[Merlijn Sebrechts]

Hi


I'm having trouble upgrading a multiseries charm.


merlijn@travers:~$ juju status
ModelController  Cloud/Region  Version
merlijntest  sojobo  tengumaas 2.0.1

App  Version  Status  Scale  CharmStore   Rev  OS  Notes
openvpn   active  1  openvpn  jujucharms4  ubuntu

UnitWorkload  Agent  Machine  Public address   PortsMessage
openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready

Machine  StateDNS  Inst id  Series  AZ
10   started  193.190.127.152  4y3h7y   xenial  default

merlijn@travers:~$ juju upgrade-charm openvpn --path
$JUJU_REPOSITORY/builds/openvpn
Added charm "local:trusty/openvpn-16" to the model.
ERROR cannot upgrade application "openvpn" to charm
"local:trusty/openvpn-16": cannot change an application's series


Metadata.yaml:

"series": ["trusty", "xenial"]


I have no idea why he thinks I want to upgrade to trusty...



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

Juju 2.0.2 is here!

[Nicholas Skaggs]

A new stable release of Juju, 2.0.2, is here!

## What's new?

This release contains bugfixes for MAAS and openstack, including fixing 
nova support.


## New to juju 2?

https://jujucharms.com/docs/2.0/introducing-2

## How do I get it?

If you are running Ubuntu, you can get it from the juju stable ppa:

sudo add-apt-repository ppa:juju/stable
sudo apt update; sudo apt install juju-2.0

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0.2

 ## What else is in it?

* #1636648 cinder fails with badRequest... "Invalid input for 
field/attribute device"

* #1638304 Juju 2.0.1 is not able to bootstrap with nova
* #1638706 environSuite.TestBootstrapInstanceConstraints fails on 
rare archs and series

* #1640282 upgrade-juju: manual-provider no matching tools available
* #1557726 Restore fails on some openstacks like prodstack
* #1636919 MAAS machine selected with space in violation of constraint
* #1636969 [1.9] Multiple negative spaces constraints given and 
rejected by MAAS
* #1637595 allWatcherStateSuite.TestRemoveRemoteApplication waiting 
for remote connection


## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
juju@lists.ubuntu.com  and join us on 
#juju on freenode. We would love to hear

your feedback and usage of juju.


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

Re: Upgrading multiseries Charm

[Rick Harding]

Trusty is listed first. Order counts for the series list.

On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts 
wrote:

> Hi
>
>
> I'm having trouble upgrading a multiseries charm.
>
>
> merlijn@travers:~$ juju status
> ModelController  Cloud/Region  Version
> merlijntest  sojobo  tengumaas 2.0.1
>
> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
> openvpn   active  1  openvpn  jujucharms4  ubuntu
>
> UnitWorkload  Agent  Machine  Public address   PortsMessage
> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>
> Machine  StateDNS  Inst id  Series  AZ
> 10   started  193.190.127.152  4y3h7y   xenial  default
>
> merlijn@travers:~$ juju upgrade-charm openvpn --path
> $JUJU_REPOSITORY/builds/openvpn
> Added charm "local:trusty/openvpn-16" to the model.
> ERROR cannot upgrade application "openvpn" to charm
> "local:trusty/openvpn-16": cannot change an application's series
>
>
> Metadata.yaml:
>
> "series": ["trusty", "xenial"]
>
>
> I have no idea why he thinks I want to upgrade to trusty...
>
>
>
> Kind regards
> Merlijn
> --
> 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

Re: Upgrading multiseries Charm

[Tom Barber]

eh? you've lost me entirety

On 8 Dec 2016 19:20, "Rick Harding"  wrote:

> Trusty is listed first. Order counts for the series list.
>
> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi
>>
>>
>> I'm having trouble upgrading a multiseries charm.
>>
>>
>> merlijn@travers:~$ juju status
>> ModelController  Cloud/Region  Version
>> merlijntest  sojobo  tengumaas 2.0.1
>>
>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>
>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>
>> Machine  StateDNS  Inst id  Series  AZ
>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>
>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>> $JUJU_REPOSITORY/builds/openvpn
>> Added charm "local:trusty/openvpn-16" to the model.
>> ERROR cannot upgrade application "openvpn" to charm
>> "local:trusty/openvpn-16": cannot change an application's series
>>
>>
>> Metadata.yaml:
>>
>> "series": ["trusty", "xenial"]
>>
>>
>> I have no idea why he thinks I want to upgrade to trusty...
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upgrading multiseries Charm

[Merlijn Sebrechts]

That seems like strange behavior. I would expect that the following for
multiseries charms:

- For upgrading, use the series of the deployed application. If that series
is not supported by the "new" charm, throw an error. The error can be
overridden with `--force-series`. (as stated in the help docs.)
- For deploying, use the `default-series` (This is NOT the case, and this
is definitely a bug according to the docs
.)


In general, for multiseries charms, the following order seems the most
logical to me:
Application to upgrade > default-series > order of series in metadata.yaml


Also note that it's not possible to specify a series manually with
`upgrade-charm`. The command doesn't recognize the `--series` flag.

2016-12-08 14:20 GMT-05:00 Rick Harding :

> Trusty is listed first. Order counts for the series list.
>
> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi
>>
>>
>> I'm having trouble upgrading a multiseries charm.
>>
>>
>> merlijn@travers:~$ juju status
>> ModelController  Cloud/Region  Version
>> merlijntest  sojobo  tengumaas 2.0.1
>>
>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>
>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>
>> Machine  StateDNS  Inst id  Series  AZ
>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>
>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>> $JUJU_REPOSITORY/builds/openvpn
>> Added charm "local:trusty/openvpn-16" to the model.
>> ERROR cannot upgrade application "openvpn" to charm
>> "local:trusty/openvpn-16": cannot change an application's series
>>
>>
>> Metadata.yaml:
>>
>> "series": ["trusty", "xenial"]
>>
>>
>> I have no idea why he thinks I want to upgrade to trusty...
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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

Re: Upgrading multiseries Charm

[Rick Harding]

Oops sorry. It's what I get for replying while out. So the series in
metadata.yaml is ordered by preferred series. However, you're completely
correct that upgrade should not be attempting to upgrade across series with
an upgrade charm. We'll look into this and file a bug as soon as we
replicate.

On Thu, Dec 8, 2016, 8:37 PM Merlijn Sebrechts 
wrote:

> That seems like strange behavior. I would expect that the following for
> multiseries charms:
>
> - For upgrading, use the series of the deployed application. If that
> series is not supported by the "new" charm, throw an error. The error can
> be overridden with `--force-series`. (as stated in the help docs.)
> - For deploying, use the `default-series` (This is NOT the case, and this
> is definitely a bug according to the docs
> .)
>
>
> In general, for multiseries charms, the following order seems the most
> logical to me:
> Application to upgrade > default-series > order of series in metadata.yaml
>
>
> Also note that it's not possible to specify a series manually with
> `upgrade-charm`. The command doesn't recognize the `--series` flag.
>
> 2016-12-08 14:20 GMT-05:00 Rick Harding :
>
> Trusty is listed first. Order counts for the series list.
>
> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
> Hi
>
>
> I'm having trouble upgrading a multiseries charm.
>
>
> merlijn@travers:~$ juju status
> ModelController  Cloud/Region  Version
> merlijntest  sojobo  tengumaas 2.0.1
>
> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
> openvpn   active  1  openvpn  jujucharms4  ubuntu
>
> UnitWorkload  Agent  Machine  Public address   PortsMessage
> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>
> Machine  StateDNS  Inst id  Series  AZ
> 10   started  193.190.127.152  4y3h7y   xenial  default
>
> merlijn@travers:~$ juju upgrade-charm openvpn --path
> $JUJU_REPOSITORY/builds/openvpn
> Added charm "local:trusty/openvpn-16" to the model.
> ERROR cannot upgrade application "openvpn" to charm
> "local:trusty/openvpn-16": cannot change an application's series
>
>
> Metadata.yaml:
>
> "series": ["trusty", "xenial"]
>
>
> I have no idea why he thinks I want to upgrade to trusty...
>
>
>
> Kind regards
> Merlijn
> --
> 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

Re: Upgrading multiseries Charm

[Merlijn Sebrechts]

Ok.

And what about deployment of a multiseries charm? It seems to me that it
should use the `default-series` of the model if the charm supports it. The
order in `metadata.yaml` should only be used as a last resort..

2016-12-08 14:41 GMT-05:00 Rick Harding :

> Oops sorry. It's what I get for replying while out. So the series in
> metadata.yaml is ordered by preferred series. However, you're completely
> correct that upgrade should not be attempting to upgrade across series with
> an upgrade charm. We'll look into this and file a bug as soon as we
> replicate.
>
> On Thu, Dec 8, 2016, 8:37 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> That seems like strange behavior. I would expect that the following for
>> multiseries charms:
>>
>> - For upgrading, use the series of the deployed application. If that
>> series is not supported by the "new" charm, throw an error. The error can
>> be overridden with `--force-series`. (as stated in the help docs.)
>> - For deploying, use the `default-series` (This is NOT the case, and this
>> is definitely a bug according to the docs
>> .)
>>
>>
>> In general, for multiseries charms, the following order seems the most
>> logical to me:
>> Application to upgrade > default-series > order of series in metadata.yaml
>>
>>
>> Also note that it's not possible to specify a series manually with
>> `upgrade-charm`. The command doesn't recognize the `--series` flag.
>>
>> 2016-12-08 14:20 GMT-05:00 Rick Harding :
>>
>> Trusty is listed first. Order counts for the series list.
>>
>> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>> Hi
>>
>>
>> I'm having trouble upgrading a multiseries charm.
>>
>>
>> merlijn@travers:~$ juju status
>> ModelController  Cloud/Region  Version
>> merlijntest  sojobo  tengumaas 2.0.1
>>
>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>
>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>
>> Machine  StateDNS  Inst id  Series  AZ
>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>
>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>> $JUJU_REPOSITORY/builds/openvpn
>> Added charm "local:trusty/openvpn-16" to the model.
>> ERROR cannot upgrade application "openvpn" to charm
>> "local:trusty/openvpn-16": cannot change an application's series
>>
>>
>> Metadata.yaml:
>>
>> "series": ["trusty", "xenial"]
>>
>>
>> I have no idea why he thinks I want to upgrade to trusty...
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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

Re: Upgrading multiseries Charm

[Tom Barber]

I have to say, I update local multiseries charms all the time and do see
that, so its certainly a bit odd.

On Thu, Dec 8, 2016 at 7:46 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Ok.
>
> And what about deployment of a multiseries charm? It seems to me that it
> should use the `default-series` of the model if the charm supports it. The
> order in `metadata.yaml` should only be used as a last resort..
>
> 2016-12-08 14:41 GMT-05:00 Rick Harding :
>
>> Oops sorry. It's what I get for replying while out. So the series in
>> metadata.yaml is ordered by preferred series. However, you're completely
>> correct that upgrade should not be attempting to upgrade across series with
>> an upgrade charm. We'll look into this and file a bug as soon as we
>> replicate.
>>
>> On Thu, Dec 8, 2016, 8:37 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> That seems like strange behavior. I would expect that the following for
>>> multiseries charms:
>>>
>>> - For upgrading, use the series of the deployed application. If that
>>> series is not supported by the "new" charm, throw an error. The error can
>>> be overridden with `--force-series`. (as stated in the help docs.)
>>> - For deploying, use the `default-series` (This is NOT the case, and this
>>> is definitely a bug according to the docs
>>> .)
>>>
>>>
>>> In general, for multiseries charms, the following order seems the most
>>> logical to me:
>>> Application to upgrade > default-series > order of series in
>>> metadata.yaml
>>>
>>>
>>> Also note that it's not possible to specify a series manually with
>>> `upgrade-charm`. The command doesn't recognize the `--series` flag.
>>>
>>> 2016-12-08 14:20 GMT-05:00 Rick Harding :
>>>
>>> Trusty is listed first. Order counts for the series list.
>>>
>>> On Thu, Dec 8, 2016, 6:25 PM Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>>
>>> I'm having trouble upgrading a multiseries charm.
>>>
>>>
>>> merlijn@travers:~$ juju status
>>> ModelController  Cloud/Region  Version
>>> merlijntest  sojobo  tengumaas 2.0.1
>>>
>>> App  Version  Status  Scale  CharmStore   Rev  OS  Notes
>>> openvpn   active  1  openvpn  jujucharms4  ubuntu
>>>
>>> UnitWorkload  Agent  Machine  Public address   PortsMessage
>>> openvpn/1*  activeidle   10   193.190.127.152  443/tcp  Ready
>>>
>>> Machine  StateDNS  Inst id  Series  AZ
>>> 10   started  193.190.127.152  4y3h7y   xenial  default
>>>
>>> merlijn@travers:~$ juju upgrade-charm openvpn --path
>>> $JUJU_REPOSITORY/builds/openvpn
>>> Added charm "local:trusty/openvpn-16" to the model.
>>> ERROR cannot upgrade application "openvpn" to charm
>>> "local:trusty/openvpn-16": cannot change an application's series
>>>
>>>
>>> Metadata.yaml:
>>>
>>> "series": ["trusty", "xenial"]
>>>
>>>
>>> I have no idea why he thinks I want to upgrade to trusty...
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

GB: +44(0)5603641316
US: +18448141689
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

What's with all the test talk? (aka, give me CI already)

[Kevin Monroe]

Hi Juju!

>From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author Workflows
[3], you'd think December was the month we all remembered the importance of
software testing.  There are oodles of test tools for charms/bundles, and
if you know about all of them, you're probably putting out thoughtful,
well-tested charms (thanks stub!).

One thing that we've found missing is a nice charm CI/CD system that
leverages these tools to automatically give developers confidence in their
code and handle the release cycle from a source repo to the charm store,
soup to nuts.  Wouldn't it be nice if you could commit a charm update to
github and automatically have Cloud Weather Report kick off Jenkins jobs on
all your clouds, which in turn called Bundletester to handle deployment,
which in turn called Amulet and Matrix to run specific tests?  Taking it a
step further, it'd be nice if that system could automatically push
charms/bundles to your edge channel (if their tests pass), and if you tag
source with a release tag, build/test/release it to your stable channel.

This kind of system is what the Big Software team has been working on
recently, and we're open to feedback!  Our goal is to deliver a system (as
a bundle) that answers the question, "how should I do CI/CD for my charms
and bundles?"  We're also working on a variation that includes the Review
Queue -- it will eventually become the brains behind
https://review.jujucharms.com and will be available for anyone wanting a
CI/CD + Source Review system in-house.

If you're interested, development is happening at
https://github.com/juju-solutions/bundle-cwr-ci.  Have a look at the readme
for more details and let us know what you think.  The bundle yaml files are
currently deployable, buy I have a nasty habit of committing straight to
master, so bear with us as development is moving fast at the moment.  Watch
this space for updates on our progress.

[0] - https://lists.ubuntu.com/archives/juju/2016-December/008260.html
[1] - https://lists.ubuntu.com/archives/juju/2016-December/008287.html
[2] - https://lists.ubuntu.com/archives/juju/2016-December/008288.html
[3] - https://lists.ubuntu.com/archives/juju/2016-December/008302.html

Thanks!
--
Kevin Monroe
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What's with all the test talk? (aka, give me CI already)

[Merlijn Sebrechts]

This is awesome!

>  I have a nasty habit of committing straight to master, so bear with us as 
> development is moving fast at the moment.

If only you could have a CI system to test your bundles automatically... ;)

2016-12-08 19:36 GMT-05:00, Kevin Monroe :
> Hi Juju!
>
> From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author Workflows
> [3], you'd think December was the month we all remembered the importance of
> software testing.  There are oodles of test tools for charms/bundles, and
> if you know about all of them, you're probably putting out thoughtful,
> well-tested charms (thanks stub!).
>
> One thing that we've found missing is a nice charm CI/CD system that
> leverages these tools to automatically give developers confidence in their
> code and handle the release cycle from a source repo to the charm store,
> soup to nuts.  Wouldn't it be nice if you could commit a charm update to
> github and automatically have Cloud Weather Report kick off Jenkins jobs on
> all your clouds, which in turn called Bundletester to handle deployment,
> which in turn called Amulet and Matrix to run specific tests?  Taking it a
> step further, it'd be nice if that system could automatically push
> charms/bundles to your edge channel (if their tests pass), and if you tag
> source with a release tag, build/test/release it to your stable channel.
>
> This kind of system is what the Big Software team has been working on
> recently, and we're open to feedback!  Our goal is to deliver a system (as
> a bundle) that answers the question, "how should I do CI/CD for my charms
> and bundles?"  We're also working on a variation that includes the Review
> Queue -- it will eventually become the brains behind
> https://review.jujucharms.com and will be available for anyone wanting a
> CI/CD + Source Review system in-house.
>
> If you're interested, development is happening at
> https://github.com/juju-solutions/bundle-cwr-ci.  Have a look at the readme
> for more details and let us know what you think.  The bundle yaml files are
> currently deployable, buy I have a nasty habit of committing straight to
> master, so bear with us as development is moving fast at the moment.  Watch
> this space for updates on our progress.
>
> [0] - https://lists.ubuntu.com/archives/juju/2016-December/008260.html
> [1] - https://lists.ubuntu.com/archives/juju/2016-December/008287.html
> [2] - https://lists.ubuntu.com/archives/juju/2016-December/008288.html
> [3] - https://lists.ubuntu.com/archives/juju/2016-December/008302.html
>
> Thanks!
> --
> Kevin Monroe
>

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

Best way to put images in a Charm's readme?

[Merlijn Sebrechts]

Hi all


I have this beautiful picture tutorial in the README of my openvpn charm.
The images are stored as part of the Charm. This looks great on github
,
where relative urls work. But this is completely broken in the charm store
.

What's the best way to include pictures in a Charm's readme?



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

Re: Hooking into `charm build` to download Puppet dependencies

[Merlijn Sebrechts]

Hi


So, I've managed to get this working. However, not exactly the way I want
it. My charm is made like this:

layer:openvpn
layer:puppet
layer:basic


layer:openvpn provides a Puppetfile that says which dependencies need to be
downloaded by the tactic., This works if I put the tactic in layer:openvpn.
This doesn't work if I put the tactic in layer:puppet because then the
tactic will run before the Puppetfile (from layer:openvpn) is added to the
destination charm.

Downloading puppet dependencies seems to be the responsibility of the
puppet layer. I'd like to be able to put the tactic in there so that layers
using layer:puppet only need to provide the puppetfile and layer:puppet
will take care of the rest. Is there a way for me to specify that a tactic
needs to be run after all other files have been added to the destination
charm?, or is there another way I can solve this issue?

Current implementation:
https://github.com/IBCNServices/tengu-charms/tree/openvpn/charms/layers/openvpn/tactics



Kind regards
Merlijn

2016-11-25 6:56 GMT-05:00 Marco Ceppi :

> That we don't have. Best to check then raise an exception if an external
> dependency does not exist (with a nice error message)
>
> On Fri, Nov 25, 2016, 4:42 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Wow, that looks really cool!
>>
>> Any best-practices of how the dependencies of a tactic should be
>> installed?
>>
>> 2016-11-25 1:19 GMT+01:00 Marco Ceppi :
>>
>> charm build uses tactics during compilation to process files and tasks.
>> These tactics are pluggable, which allows you to create custom tactics in
>> your layer for things like you've desctibed. We have an example of this in
>> the Kubernetes charms, where a custom layer tactic is used to seed static
>> template files at charm build time:
>>
>> Here's the layer.yaml: https://github.com/juju-solutions/kubernetes/
>> pull/84/files#diff-b8894e717eb49b702f8d267d084635c0
>> And here's the tactic: https://github.com/juju-solutions/kubernetes/
>> pull/84/files#diff-7bface8b28f9d781a51d0e302cef9245R74
>>
>> This one is a little more complicated, since it can also be used as a
>> standalone script, which is why there's a bunch of additional code for
>> handling commandline parsing, the "UpdateAddonsTactic" class is the meat of
>> what you're looking for.
>>
>> Marco
>>
>> On Thu, Nov 24, 2016 at 12:02 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>> Hi all
>>
>>
>> Is it possible to hook a tool like librarian-puppet
>>  into the `charm build`
>> process so I can download Puppet dependencies at build time and ship them
>> with a Charm?
>>
>>
>>
>> Kind regards
>> Merlijn
>> --
>> 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

Re: Best way to put images in a Charm's readme?

[Junaid Ali]

Merlijin,
It seems that readme in charm store expects images to be in
https://jujucharms.com/u///files/documentation/. I'm
also not sure how to add that.

Thanks,
- Junaid

On Fri, Dec 9, 2016 at 8:06 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> I have this beautiful picture tutorial in the README of my openvpn charm.
> The images are stored as part of the Charm. This looks great on github
> ,
> where relative urls work. But this is completely broken in the charm store
> .
>
> What's the best way to include pictures in a Charm's readme?
>
>
>
> Kind regards
> Merlijn
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Best way to put images in a Charm's readme?

[Junaid Ali]

Merlijin,
In your readme.md, can you specify URL for the images like L17 in this
readme

file? It will work in your case.

Thanks,
- Junaid

On Fri, Dec 9, 2016 at 12:01 PM, Junaid Ali  wrote:

> Merlijin,
> It seems that readme in charm store expects images to be in
> https://jujucharms.com/u///files/documentation/.
> I'm also not sure how to add that.
>
> Thanks,
> - Junaid
>
> On Fri, Dec 9, 2016 at 8:06 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> I have this beautiful picture tutorial in the README of my openvpn charm.
>> The images are stored as part of the Charm. This looks great on github
>> ,
>> where relative urls work. But this is completely broken in the charm
>> store .
>>
>> What's the best way to include pictures in a Charm's readme?
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju