set_state not setting the state immediately

fengxia fxia1 at lenovo.com
Tue Oct 31 13:39:06 UTC 2017


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 (puppet, chef, ansible, and so on)s. Being able to re-use 
them makes transition and adoption within these orgs easier.
3. Betting on technology. Puppet, chef, ansible all have/had their days. 
New things will inevitably emerge. Having two in the stack, though 
inefficient, mitigate risk. This is just sad reality.

Using an analogy. A charm is like a cooked dish prepared by a wonderful 
chef, tastes great, but few can do that at home yet. I have awed many by 
showing them how easy it is to deploy an Openstack with a click of 
button using Juju GUI. But ppl fear things they don't understand. Config 
mgt tools are like giving you a set of cooking utensils and a recipe 
book, you can follow the book, or be an iron chef yourself, and 
surprisingly, many believe they have that talent to be the iron chef, 
though over optimistically often ~~




On 10/30/2017 11:56 AM, Merlijn Sebrechts wrote:
> 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 
> <https://github.com/juju-solutions/charms.reactive/issues/137>. We 
> can't change the transactional nature from the charms.reactive side 
> since this is a Juju core feature, but we can provide a lot better 
> docs and change function names to better match their actual behavior. 
> This is already discussed for relationships as part of the Endpoint PR 
> <https://github.com/juju-solutions/charms.reactive/pull/123>.
> 2. Idempotency is hard, not commonly understood outside of config mgmt 
> community and charms.reactive isn't helping. 
> <https://github.com/juju-solutions/charms.reactive/issues/138> Idempotency 
> is a solved issue in config mgmt tools. I don't think it's the job of 
> Juju and charms.reactive to provide ways to do this because we operate 
> on a higher level (service orchestration, not config mgmt). What we 
> should to is make it easier to use charms.reactive together with 
> config mgmt tools like Puppet and Chef. This will keep us from 
> reinventing the wheel and will provide a number of additional benefits 
> (such as being able to leverage existing Puppet scripts and quicker 
> charms).
>
> Please create more issues if I've missed something, and add your 
> comments to the issues.
>
>
>
> Kind regards
> Merlijn
>
> 2017-10-05 20:50 GMT+02:00 fengxia <fxia1 at lenovo.com 
> <mailto:fxia1 at lenovo.com>>:
>
>     " 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 charms.
>
>     1. The "transactional" nature of Juju hook needs better explained.
>     To be honest I have no idea what this means, and what implication
>     it has to a charm writer. Any reference would be helpful.
>
>     2. I like Mike Wilson's approach to provide a list of
>     "set_state_xxx" functions so new writer can better guess what this
>     function will do. Further, a different name calls for further
>     study why they are different, thus learning important concept of
>     whatever Juju thinks charm writer needs to understand.
>
>     Otherwise, I will expect "set_state" will set that state/flag
>     asap. If there is a scanning cycle (which I heard there is some
>     kind of 5-min cycle, which document has not sufficiently made it
>     clear to a writer either), charm writer needs to have better doc
>     to learn what it means for design. I came from embedded system
>     world in which a timer loop is common. It calls for a different
>     thinking than user space script user. I think such implication
>     should be emphasized more.
>
>     3. idempotent
>
>     Again, this is a concept me (or many new writer) will fail to
>     grasp. Looking at "apt install" as example, my reaction was that
>     the package manager is taking care of "doing nothing" if called
>     multiple times. But how this translate to my system in which charm
>     is expected to "do something"? Does it mean I need a gatekeeper
>     like the package manager so to guard these "multiple calls"?
>
>     Again, this feels like a work around because "set_state" will call
>     the same function block multiple times, which is unintuitive to
>     writer -- when I set a state, the action for that state is
>     executed once, not over and over again until I turn it off.
>     Further, even "remove_state" doesn't take effect immediately, so
>     it feels arbitrary how many cycles a block of code is executed.
>     This is a design pattern I'm afraid many are not familiar with, so
>     some tutorial examples will be much appreciated.
>
>     Best,
>
>     Feng
>
>
>
>
>     On 10/04/2017 08:59 AM, Marco Ceppi wrote:
>>     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 flags only get set
>>     on success of a hook run.
>>
>>     I know there are further reaching initiatives to alleviate this
>>     by decoupling the reactive state engine from the juju hooks
>>     system. In this case each successive loop of the reactive runtime
>>     could better snapshot state and make failures more granular.
>>
>>     * state is being renamed to flag in the next major version of
>>     reactive.
>>
>>     On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson
>>     <mike.wilson at canonical.com <mailto:mike.wilson at canonical.com>> wrote:
>>
>>         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 sets after they complete. This would also fail and now
>>         the charm creator is left with nothing in the api that can
>>         help. They are now off to their own devices to start doing
>>         random things to attempt to make this work the way they want
>>         it to work. Hopefully, the solution is as straight-forward as
>>         touching random files, but we just never know.
>>
>>         I would expect the name of set_state to be something like
>>         set_state_on_success and I would further expect some sort of
>>         immediate state thing like set_state or set_state_immediate.
>>         This would give the user the tools we know that they need in
>>         order to create bug-free charms.
>>
>>         Now to compound that confusion, we have the issue of a hook
>>         can call multiple functions inside the charm code and if any
>>         of those functions have something that fails the whole thing
>>         is unwrapped. I understand from a Juju perspective why this
>>         is the case, but as a user, I would be completely taken by
>>         surprise here. The only real fix here is documentation so
>>         that we can set expectations, but people will most likely
>>         look at examples instead of documentation. This means that we
>>         need to make sure to call out any potential issues like this
>>         in the example charms we release.
>>
>>
>>         On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop
>>         <stuart.bishop at canonical.com
>>         <mailto:stuart.bishop at canonical.com>> wrote:
>>
>>             On 4 October 2017 at 00:51, Mike Wilson
>>             <mike.wilson at canonical.com
>>             <mailto:mike.wilson at canonical.com>> 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 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.
>>
>>             Individual handlers should be idempotent, so it doesn't
>>             matter about
>>             the extent of the hook, or even if the chained handlers
>>             being triggers
>>             are running in the same hook. Assume your handlers get
>>             called multiple
>>             times, because they may be. Yes, it looks idempotent but
>>             it isn't. 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]. I think this can certainly be explained
>>             better in the
>>             docs, but I can't think of a way to stop this being an
>>             easy error to
>>             make.
>>
>>             [1] spot the DBA
>>
>>             --
>>             Stuart Bishop <stuart.bishop at canonical.com
>>             <mailto:stuart.bishop at canonical.com>>
>>
>>         --
>>         Juju mailing list
>>         Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>>         Modify settings or unsubscribe at:
>>         https://lists.ubuntu.com/mailman/listinfo/juju
>>         <https://lists.ubuntu.com/mailman/listinfo/juju>
>>
>>
>>
>
>     -- 
>     Feng Xia
>
>     Advisory Engineer
>     Datacenter Group (DCG), Lenovo US
>     8000 Development Dr, Morrisiville, NC 27509
>     W:http://www.lenovo.com
>
>
>     --
>     Juju mailing list
>     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju
>     <https://lists.ubuntu.com/mailman/listinfo/juju>
>
>

-- 
Feng Xia

Advisory Engineer
Datacenter Group (DCG), Lenovo US
8000 Development Dr, Morrisiville, NC 27509
W: http://www.lenovo.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20171031/907a9f0f/attachment.html>


More information about the Juju mailing list