Juju 2.3 release train starting

[Tim Penhey]

Hi folks,

We are gearing up to release Juju 2.3. Juju 2.3 brings two headline
features:
 * Cross model relations - the ability to relate applications in
different models
 * Persistent storage - storage can outlive the unit or model it was
created for.

The team will be releasing 2.3-beta1 tomorrow, and we will be releasing
a beta every week until we hit the release candidate.

We do know that there will be at least a beta2 as we are still finishing
off a few features.

Good things are coming.

Cheers,
Tim

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

Juju 2.3 release train starting

[Tim Penhey]

Hi folks,

We are gearing up to release Juju 2.3. Juju 2.3 brings two headline
features:
 * Cross model relations - the ability to relate applications in
different models
 * Persistent storage - storage can outlive the unit or model it was
created for.

The team will be releasing 2.3-beta1 tomorrow, and we will be releasing
a beta every week until we hit the release candidate.

We do know that there will be at least a beta2 as we are still finishing
off a few features.

Good things are coming.

Cheers,
Tim

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

Charm Tools distribution channels and versions

[Sandor Zeestraten]

Hey folks,

I'm having a bit of a hard time figuring out which distribution of
charm-tools I can/should use and how they are versioned in order to keep
track of bugfixes.

As far as I understand, the snaps are preferred over the packages in the
Juju PPA and PyPI falls somewhere in between?

The snap channels all refer to 2.2 which makes it a bit difficult to tell
which are which (see below), yet they all display charm 2.2.2 and
charm-tools 2.1.2 when running "charm version". I'm sure I'm missing
something obvious but how do I keep track of what is in each snap build?

Finally, we're using bundletester for running tests which pulls inn
charm-tools from PyPI which seems to have 2.2.0 as the latest version. Does
PyPI still get new charm-tools releases? If not, what's the recommended
workflow for those running bundletester?

P.S. The page on PyPI still refers to installing charm-tools from the Juju
PPA which probably should be fixed.


$ snap info charm
name:  charm
summary:   "charm and charm-tools"
publisher: charms
contact:   juju@lists.ubuntu.com
description: |
  charmstore-client and charm-tools
snap-id: 2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt
commands:
  - charm
tracking:stable
installed:   2.2 (17) 102MB -
refreshed:   2017-07-31 18:40:23 + UTC
channels:
  stable:2.2 (17) 102MB -
  candidate: 2.2 (23) 102MB -
  beta:  ↑
  edge:  2.2 (37) 102MB -


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

Re: set_state not setting the state immediately

[Mike Wilson]

So the best practice here is to touch a file and test for the existence of
that file before running must_be_called_exactly_once()?

I think part of the issue here is that without knowing the extent of the
hook it is hard to enforce idempotency as a charm writer. It's easy to look
at the code above and say that is it idempotent since the init function is
wrapped in a when_not and the initialized state is set at the bottom of
init.

On Tue, Oct 3, 2017 at 1:43 PM Alex Kavanagh 
wrote:

> Hi there
>
>
>
> On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com> wrote:
>
>> Hi,
>>
>> It seems the reactive framework is flushing the states at the end of hook
>> execution. This may surprise charm authors. Consider the following code:
>>
>> @when_not("initialized")
>> def init():
>> must_be_called_exactly_once()
>> set_state("initialized")
>>
>> @when("initialized")
>> @when_not("ready")
>> def get_ready():
>> this_call_fails()
>> set_state("ready")
>>
>> As a charm author I would expect the "initialized" state set right after
>> the must_be_called_exactly_once() is called. However, the framework is not
>> persisting the "initialized" state at that point, and it moves on to
>> trigger the get_ready(). Since this_call_fails() happens on
>> the  get_ready() method I would expect the "initialized" state to be set
>> when the failure is resolved.
>>
>>
> Yup, that can catch you out.  As Stuart says, it's because either a hook
> competes 'fully' or not at all, and so it rolls back (or rather doesn't
> commit) the kv() store.  So anything you put in kv() (from
> charmhelpers.core.unitdata) also won't get committed.   Also, if you flush
> kv() yourself you'll mess with charms.reactive.
>
> In this situation, I tend to use a file as a sentinel to flag that I've
> really done something only once.  Alternatively, one could use
> charmhelpers.core.unitdata.Storage() directly and thus flush a separate
> Storage() back to the 'disk'.
>
>
>
> --
> 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 mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: set_state not setting the state immediately

[Alex Kavanagh]

Hi there



On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi,
>
> It seems the reactive framework is flushing the states at the end of hook
> execution. This may surprise charm authors. Consider the following code:
>
> @when_not("initialized")
> def init():
> must_be_called_exactly_once()
> set_state("initialized")
>
> @when("initialized")
> @when_not("ready")
> def get_ready():
> this_call_fails()
> set_state("ready")
>
> As a charm author I would expect the "initialized" state set right after
> the must_be_called_exactly_once() is called. However, the framework is not
> persisting the "initialized" state at that point, and it moves on to
> trigger the get_ready(). Since this_call_fails() happens on
> the  get_ready() method I would expect the "initialized" state to be set
> when the failure is resolved.
>
>
Yup, that can catch you out.  As Stuart says, it's because either a hook
competes 'fully' or not at all, and so it rolls back (or rather doesn't
commit) the kv() store.  So anything you put in kv() (from
charmhelpers.core.unitdata) also won't get committed.   Also, if you flush
kv() yourself you'll mess with charms.reactive.

In this situation, I tend to use a file as a sentinel to flag that I've
really done something only once.  Alternatively, one could use
charmhelpers.core.unitdata.Storage() directly and thus flush a separate
Storage() back to the 'disk'.



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

intro to speaking juju, the show and blog

[Rick Harding]

Last week we did an intro to the terminology used in Juju during the Juju
Show [1]. I've gotten up the blog post [2] to go with it now. Please check
it out and let me know if you find it useful for introducing folks to Juju.

Thanks

Rick

1: https://www.youtube.com/watch?v=_yMx129uhYc
2: https://insights.ubuntu.com/2017/10/03/learning-to-speak-juju/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: set_state not setting the state immediately

[Stuart Bishop]

On 3 October 2017 at 19:34, Konstantinos Tsakalozos
 wrote:
> Hi,
>
> It seems the reactive framework is flushing the states at the end of hook
> execution. This may surprise charm authors. Consider the following code:
>
> @when_not("initialized")
> def init():
> must_be_called_exactly_once()
> set_state("initialized")
>
> @when("initialized")
> @when_not("ready")
> def get_ready():
> this_call_fails()
> set_state("ready")
>
> As a charm author I would expect the "initialized" state set right after the
> must_be_called_exactly_once() is called. However, the framework is not
> persisting the "initialized" state at that point, and it moves on to trigger
> the get_ready(). Since this_call_fails() happens on the  get_ready() method
> I would expect the "initialized" state to be set when the failure is
> resolved.

The reason the charm state needs to be rolled back on hook failure is
that the changes made to the Juju environment get rolled back on hook
failure. If must_be_called_exactly_once() set a property on a relation
for example, then that change is rolled back by Juju when
this_call_fails() puts the unit into an error state. If init() was not
rerun, then that relation change would never happen (because the charm
thinks it has been made). This is one reason why handlers need to be
idempotent.

-- 
Stuart Bishop 

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

set_state not setting the state immediately

[Konstantinos Tsakalozos]

Hi,

It seems the reactive framework is flushing the states at the end of hook
execution. This may surprise charm authors. Consider the following code:

@when_not("initialized")
def init():
must_be_called_exactly_once()
set_state("initialized")

@when("initialized")
@when_not("ready")
def get_ready():
this_call_fails()
set_state("ready")

As a charm author I would expect the "initialized" state set right after
the must_be_called_exactly_once() is called. However, the framework is not
persisting the "initialized" state at that point, and it moves on to
trigger the get_ready(). Since this_call_fails() happens on
the  get_ready() method I would expect the "initialized" state to be set
when the failure is resolved.

The reason why the states are not set right away is that the entire hook is
tried after resolving the error. However, since hooks are hidden from the
charm author it is not clear when a hook starts and when it finishes. Also,
the set_state's behaviour of not immediately setting the state is
counter-intuitive.

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