<div dir="ltr">Hi all<div><br></div><div><br></div><div>Great discussion in this thread. I sense there are two issues here:<br><br>1. The <a href="https://github.com/juju-solutions/charms.reactive/issues/137">transactional nature of charms.reactive and Juju needs to be explained better</a>. 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 <a href="https://github.com/juju-solutions/charms.reactive/pull/123">the Endpoint PR</a>.</div><div>2. <a href="https://github.com/juju-solutions/charms.reactive/issues/138">Idempotency is hard, not commonly understood outside of config mgmt community and charms.reactive isn't helping.</a> 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).</div><div><br></div><div>Please create more issues if I've missed something, and add your comments to the issues.</div><div><br></div><div><br></div><div><br></div><div>Kind regards</div><div>Merlijn</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-05 20:50 GMT+02:00 fengxia <span dir="ltr"><<a href="mailto:fxia1@lenovo.com" target="_blank">fxia1@lenovo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <p>" An assumption is being made that the state changes get
      committed<br>
      immediately, but these changes are actually transactional and<br>
      following the same transactional behaviour as the Juju hook<br>
      environment [1]."</p>
    </span><p>To chip in my experience as 6-month into learning charms and
      writing a few simple charms.</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p>3. idempotent</p>
    <p>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"? <br>
    </p>
    <p>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.</p>
    <p>Best,</p>
    <p>Feng<br>
    </p><div><div class="h5">
    <p><br>
    </p>
    <p><br>
    </p>
    <br>
    <div class="m_-218968879808101888moz-cite-prefix">On 10/04/2017 08:59 AM, Marco Ceppi
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">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.
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>* state is being renamed to flag in the next major version
          of reactive.<br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr">On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson
              <<a href="mailto:mike.wilson@canonical.com" target="_blank">mike.wilson@canonical.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">So as a new charm writer coming to Juju I
                would first do this:
                <div>
                  <div style="color:rgb(33,33,33)"><br>
                  </div>
                  <div style="color:rgb(33,33,33)">def get_ready():<br>
                  </div>
                  <div style="color:rgb(33,33,33)">    func0()</div>
                  <div style="color:rgb(33,33,33)">    func1_fails()</div>
                  <div style="color:rgb(33,33,33)"><br>
                  </div>
                  <div style="color:rgb(33,33,33)">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.</div>
                  <div style="color:rgb(33,33,33)"><br>
                  </div>
                  <div style="color:rgb(33,33,33)">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.</div>
                  <div style="color:rgb(33,33,33)"><br>
                  </div>
                  <div style="color:rgb(33,33,33)">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.</div>
                  <div style="color:rgb(33,33,33)">
                    <div><br>
                    </div>
                  </div>
                </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr">On Wed, Oct 4, 2017 at 6:34 AM Stuart
                  Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>>
                  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4
                  October 2017 at 00:51, Mike Wilson <<a href="mailto:mike.wilson@canonical.com" target="_blank">mike.wilson@canonical.com</a>>
                  wrote:<br>
                  > So the best practice here is to touch a file and
                  test for the existence of<br>
                  > that file before running
                  must_be_called_exactly_once()?<br>
                  ><br>
                  > I think part of the issue here is that without
                  knowing the extent of the<br>
                  > hook it is hard to enforce idempotency as a charm
                  writer. It's easy to look<br>
                  > at the code above and say that is it idempotent
                  since the init function is<br>
                  > wrapped in a when_not and the initialized state
                  is set at the bottom of<br>
                  > init.<br>
                  <br>
                  Individual handlers should be idempotent, so it
                  doesn't matter about<br>
                  the extent of the hook, or even if the chained
                  handlers being triggers<br>
                  are running in the same hook. Assume your handlers get
                  called multiple<br>
                  times, because they may be. Yes, it looks idempotent
                  but it isn't. An<br>
                  assumption is being made that the state changes get
                  committed<br>
                  immediately, but these changes are actually
                  transactional and<br>
                  following the same transactional behaviour as the Juju
                  hook<br>
                  environment [1]. I think this can certainly be
                  explained better in the<br>
                  docs, but I can't think of a way to stop this being an
                  easy error to<br>
                  make.<br>
                  <br>
                  [1] spot the DBA<br>
                  <br>
                  --<br>
                  Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>><br>
                </blockquote>
              </div>
              --<br>
              Juju mailing list<br>
              <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
              Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju</a><br>
            </blockquote>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_-218968879808101888mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
    </div></div><span class="HOEnZb"><font color="#888888"><pre class="m_-218968879808101888moz-signature" cols="72">-- 
Feng Xia

Advisory Engineer
Datacenter Group (DCG), Lenovo US
8000 Development Dr, Morrisiville, NC 27509
W: <a class="m_-218968879808101888moz-txt-link-freetext" href="http://www.lenovo.com" target="_blank">http://www.lenovo.com</a></pre>
  </font></span></div>

<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div>