Re: set_state not setting the state immediately

Thank you both. It is clear now. On Fri, Nov 10, 2017 at 6:14 PM, Stuart Bishop wrote: > On 10 November 2017 at 21:54, Konstantinos Tsakalozos > wrote: > >> Even if it is not correct, the behaviour of the bash reactive is what >> the

Re: set_state not setting the state immediately

On 10 November 2017 at 21:54, Konstantinos Tsakalozos wrote: > Even if it is not correct, the behaviour of the bash reactive is what > the naive ( :) ) developer expects. Can you give me a concrete example > of what can go wrong with the approach the bash reactive >

Re: set_state not setting the state immediately

Hi again, This behaviour is not consistent between the python and bash reactive implementation. Seems the setting of states occurs at the end of each method invocation in bash, and at the end of hook invocation in the python implementation. Even if it is not correct, the behaviour of the bash

Re: set_state not setting the state immediately

2017-10-31 14:39 GMT+01:00 fengxia : we have been using Ansible (called from charm) for executions. > - Would you recommend this approach to new users? - Do you have examples of such Charms? - Do you have docs detailing the ansible-Juju integration? - What can we

Re: set_state not setting the state immediately

Merlijn, Nice summary of these issues. Especially for the #2, we have been using Ansible (called from charm) for executions. I think there are 3 points here: 1. confg mgt has solved idempotency, great! 2. many organizations have accumulated an asset of recipes using these config tools

Re: set_state not setting the state immediately

Hi all Great discussion in this thread. I sense there are two issues here: 1. The transactional nature of charms.reactive and Juju needs to be explained better . We can't change the transactional nature from the charms.reactive side

Re: set_state not setting the state immediately

" An assumption is being made that the state changes get committed immediately, but these changes are actually transactional and following the same transactional behaviour as the Juju hook environment [1]." To chip in my experience as 6-month into learning charms and writing a few simple

Re: set_state not setting the state immediately

These sound like good steps to me. I would just encourage us to look at the worst examples of charms people have written or questions that are common and attempt to defend against that sort of thing. People invent things out of perceived necessity and if we can find those and provide solutions I

Re: set_state not setting the state immediately

So, I've not actually checked the logs in a while, but if visibility is an issue, it seems reasonable that the reactive framework should print in the log that X flags are being reset due to hook failure. Things like set_flag_immediate has farther reaching consequences than simply stating that

Re: set_state not setting the state immediately

So as a new charm writer coming to Juju I would first do this: def get_ready(): func0() func1_fails() Then I would, hopefully, test and notice issues. I would investigate and see that I needed to be idempotent. My next attempt would be to wrap those functions inside state checks with

Re: set_state not setting the state immediately

On 4 October 2017 at 00:51, Mike Wilson wrote: > 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

Re: set_state not setting the state immediately

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

Re: set_state not setting the state immediately

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

Re: set_state not setting the state immediately

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(): >

set_state not setting the state immediately

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