Re: support for local resources in bundles?

[Rick Harding]

No, currently it does not. It's on the 17.04 roadmap to add that support.

The bundle does support resources, but as revisions from the charmstore so
that you can build a bundle that's not just the latest published charm
revision/resource revision set.

On Tue, Dec 13, 2016 at 6:09 PM Kevin Monroe 
wrote:

> I've got a bundle.yaml that defines a local charm, e.g.:
>
> ...
>   mycharm:
> charm: "/home/ubuntu/charms/builds/mycharm"
> num_units: 1
> ...
>
> Does the bundle spec allow for attaching resources to mycharm?  If so, can
> the resource be local?
>
> Thanks!
> -Kevin
> --
> 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: Bug 1642609: new model config defaults

[Aaron Bentley]

On 2016-12-07 03:37 PM, Michael Foord wrote:
> I am strongly of the opinion that at the very least a newly created
> model should be capable of deploying workloads, which means that at
> least a subset of model-config options should be propagated by default
> to new models. This means at least, agent-stream, agent-metadata-url,
> proxy settings etc.

Options that pertain to network activity by the controller should be
retained across models, i.e. agent-metadata-url.

A controller can create models in a different cloud/region, so options
pertaining to network activity by other agents should be associated with
the cloud or region, not the controller.  e.g. proxy settings.

Aaron



signature.asc
Description: OpenPGP digital signature
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

support for local resources in bundles?

[Kevin Monroe]

I've got a bundle.yaml that defines a local charm, e.g.:

...
  mycharm:
charm: "/home/ubuntu/charms/builds/mycharm"
num_units: 1
...

Does the bundle spec allow for attaching resources to mycharm?  If so, can
the resource be local?

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

Juju Show #2 Wed Dec 14th

[Rick Harding]

Come join us as we host the next Juju Show live stream tomorrow. We'll be
going over the latest in community news, demoing the new developments in
tools for charming, and getting a demonstration of the new model migration
feature coming in Juju 2.1.

When: Nov 30th, at 19:00 GMT, 2:00pm EST
Where: https://www.youtube.com/watch?v=FwLEMa7XE64
How to participate: Hang out in the #juju Freenode IRC channel

Join us in the IRC channel to ask questions, get a link to the hangout to
join the live stream, or just to listen in on the latest news.

Make sure to subscribe to the Juju Youtube channel so you never miss any of
the happenings in and around Juju!

https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

See you there!

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

Juju Show #2 Wed Dec 14th

[Rick Harding]

Come join us as we host the next Juju Show live stream tomorrow. We'll be
going over the latest in community news, demoing the new developments in
tools for charming, and getting a demonstration of the new model migration
feature coming in Juju 2.1.

When: Nov 30th, at 19:00 GMT, 2:00pm EST
Where: https://www.youtube.com/watch?v=FwLEMa7XE64
How to participate: Hang out in the #juju Freenode IRC channel

Join us in the IRC channel to ask questions, get a link to the hangout to
join the live stream, or just to listen in on the latest news.

Make sure to subscribe to the Juju Youtube channel so you never miss any of
the happenings in and around Juju!

https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw

See you there!

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

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

[Cory Johns]

To put the Puppetfile contents in layers.yaml would mean that your tactic
would need to process layer.yaml and would need to be a subclass of the
existing LayerYAML tactic and ensure that all of the existing functionality
would be invoked.  Additionally, I suspect that the custom tactic would
still get overridden by the default LayerYAML tactic on the higher layers,
since the custom tactics are not carried forward.  I think this is going to
require fixes to charm-tools regardless, unfortunately.

In addition to enabling custom tactics to handle files in higher layers,
perhaps we should consider an official API for handling layer options at
build time rather than just run time?  It seems like it might be useful in
other aspects as well, and custom tactics might be a bit heavy for that
specific use-case.

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

> This is the Puppetfile:
> https://github.com/IBCNServices/tengu-charms/blob/openvpn/charms/layers/
> openvpn/files/puppet/Puppetfile
>
> I use the Puppetfile since that's the way that most modules define their
> dependencies. I'd like to have a puppet layer that requires the least
> amount of porting/adapting of existing puppet scripts. Users that have
> existing puppet scripts just drop in their Puppetfile and that's it.
> Puppetfiles can become a lot more complex than this; also defining
> dependencies from github etc.
>
> That said using options has the advantage that multiple layers can provide
> multiple puppetfiles since arrays are merged instead of not overwritten.
> The best way to go might be to have a 'puppetfile' layer option that's an
> array of all the lines in the puppetfile. The order of lines in the
> puppetfile is important. Is the order of elements in an array retained?
>
> To be clear, will switching to options allow me to put the tactic in
> layer:puppet?
>
> The openvpn puppet module already takes care of generating certificates,
> that's why I'm not using the easy-rsa charm. The charm is mostly done, I
> just need finish the tests before I can submit it to the (new) review
> queue. If you're interested you can test-drive it yourself:
> cs:~tengu-bot/openvpn.
>
>
> Op vrijdag 9 december 2016 heeft Marco Ceppi 
> het volgende geschreven:
> > There's a couple of things to unpack here.
> >
> > On Thu, Dec 8, 2016 at 10:18 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
> >>
> >> 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.
> >
> > This is problematic, as i think tactics only run on the given layer (if
> I recall correctly). I'd stray from having a separate Puppetfile and
> instead including it in the layer.yaml under
> > options:
> >   puppet:
> > modules:
> >   - Entry
> >   - Entry
> > We're going to be deprecating wheelhouse.txt in the same fashion.
> Looking at your OpenVPN layer, I don't really see where the Puppetfile
> lies? (I was curious it's format).
> > Also, we have an EasyRSA charm, from the OpenVPN project, if you were
> looking to charm that, we've got you covered.
> >>
> >> 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?
> >
> > I'm not entirely sure, I'll prod Ben or Cory to weigh in as they know a
> lot more about tactics. If there truly isn't a way, I'll work to get a
> patch where tactics are processed continually. I think a puppet "base"
> layer is actually a pretty good approach to this, and you seem to be on the
> right path.
> >
> >>
> >> 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 

Leadership Election Tools

[Matthew Williams]

Hey Folks,

Let's say I'm a charm author that wants to test leadership election in my
charm. Are there any tools available that will let me force leadership
election in juju so that I can test how my charm handles it? I was looking
at the docs here: https://jujucharms.com/docs/stable/developer-leadership
but couldn't see anything

Cheers

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

A new supported stable release of Juju, 1.25.9, is here!

[Curtis Hovey-Canonical]

A new supported stable release of Juju, 1.25.9, is here!


## Notable Changes

* Juju did not correctly remove OpenStack security groups
  https://bugs.launchpad.net/bugs/1625624

* Corrected a memory leak that caused instability
  https://bugs.launchpad.net/bugs/1645729


## How do I get it?

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

sudo add-apt-repository ppa:juju/1.25
sudo apt-get update; sudo apt-get install juju-core

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

https://launchpad.net/juju-core/+milestone/1.25.9


## 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.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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

Re: Immutable configuration best practices for charms

[Stuart Bishop]

On 13 December 2016 at 03:01, Sandor Zeestraten  wrote:


> How are you all dealing with immutable configurations when charming?
>

For now, the best approach I could come up with is to detect the change
(hookenv.config().previous('foo') helps here), and put the unit into a
blocked state until the operator switches the configuration back. Assuming
you are writing a reactive charm, the trick is that this needs to happen
*before* your handlers kick in, and to sys.exit(0) after putting the unit
into a blocked state.

https://git.launchpad.net/postgresql-charm/tree/reactive/postgresql/preflight.py
has the code I use to handle immutable configuration and other config
validation, and uses
https://git.launchpad.net/postgresql-charm/tree/lib/preflight.py to inject
the code early in reactive charm startup (I have an open PR in github to
add a similar builtin feature to reactive)

(Long term, I'm sure we will get richer features. There will always be some
cases where charm code needs to run to validate configration, so maybe some
sort of exit status the config-changed hook can return. Immutable is
simpler than generic validation though, and could probably just be declared
in config.yaml)

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