Re: Juju charm hook vs. state
Hi
On Fri, Apr 14, 2017 at 8:19 PM, fengxia wrote:
> I'm learning charm development and confused about state vs. hook.
>
Welcome to charm authoring!
So, as you're probably starting to work out, hooks and states are different
things. I'll try to explain the difference.
Hooks:
At it's simplest, a hook is an executable in the 'hooks' directory of a
charm. The Juju agent that looks after the unit calls the 'hook'
executable at certain points during the lifetime of the charm. i.e. start,
install, config-changed, update-status, etc.
The hook executable can be a bash script, a python script or even (and
don't do this!) a compiled C binary. Anything that can be an executable
can be a hook.
States:
This is a concept that is associated only with the charms.reactive library.
i.e. you can write charms in Python without the charms.reactive library.
It isn't suggested that you do, because charms.reactive really, really
helps to simplify and ease the writing of charms.
Conceptually, I guess these are a bit harder to grab hold of. A state is
an indicator that a charm author (or interface author) sets when some
condition/state has been achieved. i.e. the software under control has
been installed, or a relation (interface in charms.reactive terminology)
has been connected, etc. This state is remembered between invocations of
the charm code.
Putting it together:
For any of the charm code to run (at all), Juju calls a hook executable in
the hooks directory.
For a charms.reactive charm, any of the hooks (usually) results in the same
charm code being loaded. Thus, from the perspective of a charms.reactive
based charm, all hooks are treated the same.
The charms.reactive library does support hooks (using a the @hook
decorator) and these are run before any reactive handlers (@when,
@when_not). The named hook decorator (@hook('update-status')) is run
according to the actual hook executable (in the hooks directory) that Juju
called. Then the conditions described by the reactive handlers (@when...)
are evaluated and any that are 'true' are executed. This continues until
no more handlers' conditions are true.
So, it's important to remember that for a charms.reactive type charm, any
and every hook that Juju calls could result in any of the reactive handlers
being called depending on the states that the charm has previous set (or
its interfaces).
So, on to your questions:
>
> I used @when_not("state.0") to mark the very first function that gets
> executed. In document it also says "install" hook will be the first to
> execute. Tried @hooks.hook("install") but it just failed at charm
> installation.
>
Okay, so with reactive handlers there is no 'first' function. Any handler
that has conditions that evaluate to 'true' will be run, and the ordering
should be considered arbitrary.
The named hook (if a @hook is used) will execute before reactive handlers.
>
> So what is the right way to determine the "entry" point in a charm? I mean
> the first function block that will be executed. I'm thinking to use chained
> state from that point on to guide execution process. Is this the right
> approach?
So the very first time a reactive charm is executed there will be no states
set. It's recommended to avoid using @hook decorators unless absolutely
necessary. Luckily, installation of the underlying software doesn't need
hooks!
The normal way is to to use a @when_not('installed') condition on the
handler that will either do, or at least kick off the installation, and
then set it when the installation is complete. Remember that every
reactive handler should be idempotent for the state conditions that it
handles.
So:
@when_not('installed')
def install_software():
... install the software ...
set_state('installed')
i.e. you are on the right approach!
Hope that this helps.
All the best
Alex.
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
--
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Juju charm hook vs. state
I'm learning charm development and confused about state vs. hook.
I used @when_not("state.0") to mark the very first function that gets
executed. In document it also says "install" hook will be the first to
execute. Tried @hooks.hook("install") but it just failed at charm
installation.
So what is the right way to determine the "entry" point in a charm? I
mean the first function block that will be executed. I'm thinking to use
chained state from that point on to guide execution process. Is this the
right approach?
--
Feng xia
Engineer
Lenovo USA
Phone: 5088011794
fx...@lenovo.com
Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Check out the openvpn charm form the tengu team
> I think that Chuck was looking to have a relation available. In this way you could tunnel traffic from an application across the VPN perhaps? In the world of cross model relations, it might enable folks to wire traffic across clouds/DC in some interesting ways. This is precisely what I was looking for. One easy example I thought of, is you could say deploy an SDN on the OpenVPN charm, and it would then inherit that SDN topology as an accessible network. This would aid in secure access to applications without requiring an ingress declaration in kubernetes for example. Sort of like an intranet running in the cloud, that's only available if you're participating in the network segment, but also has implications when debugging applications without having ssh access. You connect up to the VPN and start the network debug session. It would be a more robust solution than the current implementation of 'kubectl proxy'. This isn't new, and there's a few early solutions in the kubernetes community that leverage different VPN services. I think the idea of having it available across the board to any Juju deployment makes it slightly more powerful in that it lives on your infra level, not as a workload in the k8s stack. But that's just a preference. Great work on the charm Tengu team :) On Fri, Apr 14, 2017 at 8:56 AM Rick Harding wrote: > The delivery of the config files is interesting. There's nothing planning > in the gui at the moment for this. It's kind of an inverse "resources" idea > where you are building artifacts in the charm that you want clients to be > able to get access to. It's an interesting concept. It's a bit like actions > that generate a backup file or the like. The action can build the backup > and tell you where on disk it is, but then you need to juju scp it down. I > wonder if there's a specific action type that generates artifacts and then > there's a followup plugin/helper that automates the juju scp step for you > in a some nice way. > > I think that Chuck was looking to have a relation available. In this way > you could tunnel traffic from an application across the VPN perhaps? In the > world of cross model relations it might enable folks to wire traffic across > clouds/DC in some interesting ways. > > > > On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Thanks for the post! >> >> >> I'd really like to integrate this Charm more with JaaS. I'd like to give >> JaaS users the ability to download the client config files from the Juju >> GUI. Any idea if that's something that's being worked on? >> >> @chuck: I just watched the Juju show, what was the feature you were >> talking about? >> >> >> >> Kind regards >> Merlijn >> >> 2017-04-13 16:35 GMT+02:00 Rick Harding : >> >>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the >>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does >>> some great work using metrics in Juju to output operational data. Running >>> juju metrics --all will show you how many clients are connected on each >>> unit. If you're a charmer, it might give you some new ideas for exposing >>> internal data in a really nice standard way. >>> >>> I just wanted to highlight it as something really useful for folks if >>> you've ever found yourself wishing you had a VPN around somewhere. >>> >>> 1: >>> http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket >>> 2: https://jujucharms.com/openvpn/ >>> >>> Rick >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> -- Juju Charmer Canonical Group Ltd. Ubuntu - Linux for human beings | www.ubuntu.com conjure-up canonical-kubernetes | jujucharms.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] ibm-was-nd-dm, ibm-was-nd-node, autoscaler, spectrum-scale-client
Yesterday, Cory, Kevin and I took a trip through the review queue. Here's what we did: April 13, 2017: Cory, Kevin, Pete - Ibm-was-nd-dm - https://review.jujucharms.com/reviews/68?revision=153 - Charm code review looks good, with a minor exception: - We submitted an MP to fix an incorrect repo key in layer.yaml: - https://code.launchpad.net/~kwmonroe/charms/xenial/layer-ibm-was-nd-dm/repo-key/+merge/322541 - We could not find WAS ND v9 installer resources and asked the author to provide access to those. - -1 for now; we’ll revisit once we get required resources. - Ibm-was-nd-node - https://review.jujucharms.com/reviews/69?revision=154 - Similar MP as above for incorrect repo key, and a minor test fix: - https://code.launchpad.net/~kwmonroe/charms/xenial/layer-ibm-was-nd-node/repo-key/+merge/322546 - As with WAS ND DM, this is -1 for now until we get required resources. - autoscaler - https://review.jujucharms.com/reviews/96 - Comments from previous review were addressed and the update has been released as cs:charmscaler-2 - spectrum-scale-client - https://review.jujucharms.com/reviews/78 - Brickftp files updated. I ran into errors when following the README’s instructions on validating the install, however. Thanks for all the hard work putting these charms together in the first place! ~ PeteVG -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Check out the openvpn charm form the tengu team
On Fri, Apr 14, 2017, 10:26 Merlijn Sebrechts wrote: > 2017-04-14 16:10 GMT+02:00 Marco Ceppi : > >> I'd like to point you both to this idea, which is one that was born from >> the same problem Kubernetes has: >> https://bugs.launchpad.net/juju/+bug/1670838. The idea is actions should >> be able to both send and receive files. >> > > +1 > > One thing to consider here is that actions always have to be triggered > from the operator side. It would also be nice if the charm cloud > periodically push a backup to the controller without the operator having to > call an action. > I agree, something that could be done as part of update-status, almost like the ability for a charm to execute an action on itself of charms it's related to. As actions are exposed in the GUI this could help address the above problem >> as well. >> > > > From what I know, actions aren't yet supported in the GUI: > https://github.com/juju/juju-gui/issues/2185 > Sorry, meant to be "In the future, as actions are exposed in the GUI" On Fri, Apr 14, 2017 at 10:07 AM Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >>> Yes, "inverse resources" is what I'm thinking about. Another use-case >>> for this would be to download backups and exports from the Charm. The >>> Kubernetes Charms could also benefit from this since they create a config >>> file that an operator has to download to connect to the Kubernetes cluster. >>> >>> `juju scp` solves this issue for the most part but >>> >>>1. it isn't available from the GUI >>>2. and the files disappear when the node goes down. >>> >>> >>> 2017-04-14 15:55 GMT+02:00 Rick Harding : >>> The delivery of the config files is interesting. There's nothing planning in the gui at the moment for this. It's kind of an inverse "resources" idea where you are building artifacts in the charm that you want clients to be able to get access to. It's an interesting concept. It's a bit like actions that generate a backup file or the like. The action can build the backup and tell you where on disk it is, but then you need to juju scp it down. I wonder if there's a specific action type that generates artifacts and then there's a followup plugin/helper that automates the juju scp step for you in a some nice way. I think that Chuck was looking to have a relation available. In this way you could tunnel traffic from an application across the VPN perhaps? In the world of cross model relations it might enable folks to wire traffic across clouds/DC in some interesting ways. On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Thanks for the post! > > > I'd really like to integrate this Charm more with JaaS. I'd like to > give JaaS users the ability to download the client config files from the > Juju GUI. Any idea if that's something that's being worked on? > > @chuck: I just watched the Juju show, what was the feature you were > talking about? > > > > Kind regards > Merlijn > > 2017-04-13 16:35 GMT+02:00 Rick Harding : > >> I wrote up a quick blog post [1] as I was tinkering with VPNs and the >> OpenVPN charm [2] from the Tengu team is really nice and easy. It also >> does >> some great work using metrics in Juju to output operational data. Running >> juju metrics --all will show you how many clients are connected on each >> unit. If you're a charmer, it might give you some new ideas for exposing >> internal data in a really nice standard way. >> >> I just wanted to highlight it as something really useful for folks if >> you've ever found yourself wishing you had a VPN around somewhere. >> >> 1: >> http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket >> 2: https://jujucharms.com/openvpn/ >> >> Rick >> >> -- >> 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: Check out the openvpn charm form the tengu team
2017-04-14 16:10 GMT+02:00 Marco Ceppi : > I'd like to point you both to this idea, which is one that was born from > the same problem Kubernetes has: https://bugs.launchpad.ne > t/juju/+bug/1670838. The idea is actions should be able to both send and > receive files. > +1 One thing to consider here is that actions always have to be triggered from the operator side. It would also be nice if the charm cloud periodically push a backup to the controller without the operator having to call an action. > As actions are exposed in the GUI this could help address the above > problem as well. > >From what I know, actions aren't yet supported in the GUI: https://github.com/juju/juju-gui/issues/2185 > > On Fri, Apr 14, 2017 at 10:07 AM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Yes, "inverse resources" is what I'm thinking about. Another use-case for >> this would be to download backups and exports from the Charm. The >> Kubernetes Charms could also benefit from this since they create a config >> file that an operator has to download to connect to the Kubernetes cluster. >> >> `juju scp` solves this issue for the most part but >> >>1. it isn't available from the GUI >>2. and the files disappear when the node goes down. >> >> >> 2017-04-14 15:55 GMT+02:00 Rick Harding : >> >>> The delivery of the config files is interesting. There's nothing >>> planning in the gui at the moment for this. It's kind of an inverse >>> "resources" idea where you are building artifacts in the charm that you >>> want clients to be able to get access to. It's an interesting concept. It's >>> a bit like actions that generate a backup file or the like. The action can >>> build the backup and tell you where on disk it is, but then you need to >>> juju scp it down. I wonder if there's a specific action type that generates >>> artifacts and then there's a followup plugin/helper that automates the juju >>> scp step for you in a some nice way. >>> >>> I think that Chuck was looking to have a relation available. In this way >>> you could tunnel traffic from an application across the VPN perhaps? In the >>> world of cross model relations it might enable folks to wire traffic across >>> clouds/DC in some interesting ways. >>> >>> >>> >>> On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < >>> merlijn.sebrec...@gmail.com> wrote: >>> Thanks for the post! I'd really like to integrate this Charm more with JaaS. I'd like to give JaaS users the ability to download the client config files from the Juju GUI. Any idea if that's something that's being worked on? @chuck: I just watched the Juju show, what was the feature you were talking about? Kind regards Merlijn 2017-04-13 16:35 GMT+02:00 Rick Harding : > I wrote up a quick blog post [1] as I was tinkering with VPNs and the > OpenVPN charm [2] from the Tengu team is really nice and easy. It also > does > some great work using metrics in Juju to output operational data. Running > juju metrics --all will show you how many clients are connected on each > unit. If you're a charmer, it might give you some new ideas for exposing > internal data in a really nice standard way. > > I just wanted to highlight it as something really useful for folks if > you've ever found yourself wishing you had a VPN around somewhere. > > 1: http://mitechie.com/blog/2017/4/12/three-reasons-you-need > -to-keep-a-vpn-in-your-pocket > 2: https://jujucharms.com/openvpn/ > > Rick > > -- > 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/mailm >> an/listinfo/juju >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Multi-series charm authors: new functionality for comparing ubuntu versions
On Thu, Apr 13, 2017 at 10:13 PM, Colin Watson wrote: > On Thu, Apr 13, 2017 at 09:15:08PM +0100, Alex Kavanagh wrote: > > So instead of: > > > > if ubuntu_version > 'trusty': > > > > We do: > > > > cmp_version = CompareHostReleases(ubuntu_version) > > if cmp_version > 'trusty': > > > > This version of the code checks that ubuntu_version and 'trusty' strings > > are known releases and makes it easy to fix existing code. >, <, >=< <=, > > ==, != are all supported. > > I have déjà vu: I did exactly the same thing in lp:ubuntu-cdimage in > 2012. :-) I agree that this style makes things pretty nice for calling > code. > > The one problem I've had with it is that every so often somebody looks > at a bit of code and says "hey, isn't this going to break after 17.04?" > and then I have to explain that it's actually magically OK, which as > problems go is not really a bad one to have. > Good to know that I'm not totally going out on a limb with this approach! There was some criticism of leaving is as >, <, etc., the alternatives just seemed really clunky. There is the downside that people could miss it, but there wasn't a reasonable way of stopping people just using a regular string comparison. Thanks for the feedback / confirmation! > > -- > Colin Watson [cjwat...@ubuntu.com] > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > -- Alex Kavanagh - Software Engineer Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Check out the openvpn charm form the tengu team
I'd like to point you both to this idea, which is one that was born from the same problem Kubernetes has: https://bugs.launchpad.net/juju/+bug/1670838. The idea is actions should be able to both send and receive files. As actions are exposed in the GUI this could help address the above problem as well. On Fri, Apr 14, 2017 at 10:07 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Yes, "inverse resources" is what I'm thinking about. Another use-case for > this would be to download backups and exports from the Charm. The > Kubernetes Charms could also benefit from this since they create a config > file that an operator has to download to connect to the Kubernetes cluster. > > `juju scp` solves this issue for the most part but > >1. it isn't available from the GUI >2. and the files disappear when the node goes down. > > > 2017-04-14 15:55 GMT+02:00 Rick Harding : > >> The delivery of the config files is interesting. There's nothing planning >> in the gui at the moment for this. It's kind of an inverse "resources" idea >> where you are building artifacts in the charm that you want clients to be >> able to get access to. It's an interesting concept. It's a bit like actions >> that generate a backup file or the like. The action can build the backup >> and tell you where on disk it is, but then you need to juju scp it down. I >> wonder if there's a specific action type that generates artifacts and then >> there's a followup plugin/helper that automates the juju scp step for you >> in a some nice way. >> >> I think that Chuck was looking to have a relation available. In this way >> you could tunnel traffic from an application across the VPN perhaps? In the >> world of cross model relations it might enable folks to wire traffic across >> clouds/DC in some interesting ways. >> >> >> >> On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >>> Thanks for the post! >>> >>> >>> I'd really like to integrate this Charm more with JaaS. I'd like to give >>> JaaS users the ability to download the client config files from the Juju >>> GUI. Any idea if that's something that's being worked on? >>> >>> @chuck: I just watched the Juju show, what was the feature you were >>> talking about? >>> >>> >>> >>> Kind regards >>> Merlijn >>> >>> 2017-04-13 16:35 GMT+02:00 Rick Harding : >>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the OpenVPN charm [2] from the Tengu team is really nice and easy. It also does some great work using metrics in Juju to output operational data. Running juju metrics --all will show you how many clients are connected on each unit. If you're a charmer, it might give you some new ideas for exposing internal data in a really nice standard way. I just wanted to highlight it as something really useful for folks if you've ever found yourself wishing you had a VPN around somewhere. 1: http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket 2: https://jujucharms.com/openvpn/ Rick -- 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: Check out the openvpn charm form the tengu team
Yes, "inverse resources" is what I'm thinking about. Another use-case for this would be to download backups and exports from the Charm. The Kubernetes Charms could also benefit from this since they create a config file that an operator has to download to connect to the Kubernetes cluster. `juju scp` solves this issue for the most part but 1. it isn't available from the GUI 2. and the files disappear when the node goes down. 2017-04-14 15:55 GMT+02:00 Rick Harding : > The delivery of the config files is interesting. There's nothing planning > in the gui at the moment for this. It's kind of an inverse "resources" idea > where you are building artifacts in the charm that you want clients to be > able to get access to. It's an interesting concept. It's a bit like actions > that generate a backup file or the like. The action can build the backup > and tell you where on disk it is, but then you need to juju scp it down. I > wonder if there's a specific action type that generates artifacts and then > there's a followup plugin/helper that automates the juju scp step for you > in a some nice way. > > I think that Chuck was looking to have a relation available. In this way > you could tunnel traffic from an application across the VPN perhaps? In the > world of cross model relations it might enable folks to wire traffic across > clouds/DC in some interesting ways. > > > > On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < > merlijn.sebrec...@gmail.com> wrote: > >> Thanks for the post! >> >> >> I'd really like to integrate this Charm more with JaaS. I'd like to give >> JaaS users the ability to download the client config files from the Juju >> GUI. Any idea if that's something that's being worked on? >> >> @chuck: I just watched the Juju show, what was the feature you were >> talking about? >> >> >> >> Kind regards >> Merlijn >> >> 2017-04-13 16:35 GMT+02:00 Rick Harding : >> >>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the >>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does >>> some great work using metrics in Juju to output operational data. Running >>> juju metrics --all will show you how many clients are connected on each >>> unit. If you're a charmer, it might give you some new ideas for exposing >>> internal data in a really nice standard way. >>> >>> I just wanted to highlight it as something really useful for folks if >>> you've ever found yourself wishing you had a VPN around somewhere. >>> >>> 1: http://mitechie.com/blog/2017/4/12/three-reasons-you- >>> need-to-keep-a-vpn-in-your-pocket >>> 2: https://jujucharms.com/openvpn/ >>> >>> Rick >>> >>> -- >>> 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: Check out the openvpn charm form the tengu team
The delivery of the config files is interesting. There's nothing planning in the gui at the moment for this. It's kind of an inverse "resources" idea where you are building artifacts in the charm that you want clients to be able to get access to. It's an interesting concept. It's a bit like actions that generate a backup file or the like. The action can build the backup and tell you where on disk it is, but then you need to juju scp it down. I wonder if there's a specific action type that generates artifacts and then there's a followup plugin/helper that automates the juju scp step for you in a some nice way. I think that Chuck was looking to have a relation available. In this way you could tunnel traffic from an application across the VPN perhaps? In the world of cross model relations it might enable folks to wire traffic across clouds/DC in some interesting ways. On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Thanks for the post! > > > I'd really like to integrate this Charm more with JaaS. I'd like to give > JaaS users the ability to download the client config files from the Juju > GUI. Any idea if that's something that's being worked on? > > @chuck: I just watched the Juju show, what was the feature you were > talking about? > > > > Kind regards > Merlijn > > 2017-04-13 16:35 GMT+02:00 Rick Harding : > >> I wrote up a quick blog post [1] as I was tinkering with VPNs and the >> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does >> some great work using metrics in Juju to output operational data. Running >> juju metrics --all will show you how many clients are connected on each >> unit. If you're a charmer, it might give you some new ideas for exposing >> internal data in a really nice standard way. >> >> I just wanted to highlight it as something really useful for folks if >> you've ever found yourself wishing you had a VPN around somewhere. >> >> 1: >> http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket >> 2: https://jujucharms.com/openvpn/ >> >> Rick >> >> -- >> 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: Check out the openvpn charm form the tengu team
Thanks for the post! I'd really like to integrate this Charm more with JaaS. I'd like to give JaaS users the ability to download the client config files from the Juju GUI. Any idea if that's something that's being worked on? @chuck: I just watched the Juju show, what was the feature you were talking about? Kind regards Merlijn 2017-04-13 16:35 GMT+02:00 Rick Harding : > I wrote up a quick blog post [1] as I was tinkering with VPNs and the > OpenVPN charm [2] from the Tengu team is really nice and easy. It also does > some great work using metrics in Juju to output operational data. Running > juju metrics --all will show you how many clients are connected on each > unit. If you're a charmer, it might give you some new ideas for exposing > internal data in a really nice standard way. > > I just wanted to highlight it as something really useful for folks if > you've ever found yourself wishing you had a VPN around somewhere. > > 1: http://mitechie.com/blog/2017/4/12/three-reasons-you- > need-to-keep-a-vpn-in-your-pocket > 2: https://jujucharms.com/openvpn/ > > Rick > > -- > 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
A small & simple utility charm: unattended
Hi all, I have a few test environments where I need to leave machines running for days or weeks at a time, and they're not important enough to use up Landscape or Canonical live patching licence slots, but I don't want to leave them open to the Internet with possible security vulnerabilities. So I created a little charm called unattended, which configures unattended-upgrades and configures it to automatically reboot the system. It shows important information in juju status so you can be reminded about pending reboots or required security patches. Here are some examples of what you might see in juju status when using it: http://pastebin.ubuntu.com/24379952/ http://pastebin.ubuntu.com/24379971/ This is designed to be a small, simple subordinate charm which you can add to your deployments with minimal overhead; it doesn't use reactive, and a lot of it is written in bash. It can be found at https://github.com/paulgear/charm-unattended and https://code.launchpad.net/charm-unattended/ Just to reiterate, the unattended charm AUTOMATICALLY REBOOTS the juju unit BY DEFAULT, if unattended-upgrades decides it is necessary. (This is configurable.) Feedback, questions, MPs, etc. welcome. -- Regards, Paul Gear Site Reliability Engineer Canonical - Information Systems signature.asc Description: OpenPGP digital signature -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
