<tt><font size=2>Zane Bitter <zbitter@redhat.com> wrote on 10/16/2013
10:30:44 AM:<br>
<br>
> On 16/10/13 15:58, Mike Spreitzer wrote:<br>
> ...<br>
> > Thanks for a great short sharp answer.  In that light, I
see a concern.<br>
> >   Once a workflow has been generated, the system has lost
the ability to<br>
> > adapt to changes in either model.  In a highly concurrent
and dynamic<br>
> > environment, that could be problematic.<br>
> <br>
> I think you're referring to the fact if reality diverges from the
model <br>
> we have no way to bring it back in line (and even when doing an update,
<br>
> things can and usually will go wrong if Heat's idea of the existing
<br>
> template does not reflect reality any more). If so, then I agree that
we <br>
> are weak in this area. You're obviously aware of <br>
> </font></tt><a href=http://summit.openstack.org/cfp/details/95><tt><font size=2>http://summit.openstack.org/cfp/details/95</font></tt></a><tt><font size=2>
so it is definitely on the radar.<br>
</font></tt>
<br><tt><font size=2>Actually, I am thinking of both of the two models
you mentioned.  We are only in the midst of implementing an even newer
design (heat based), but for my group's old code we have a revised design
in which the infrastructure orchestrator can react to being overtaken by
later updates to the model we call "target state" (origin source
is client) as well as concurrent updates to the model we call "observed
state" (origin source is hardware/hypervisor).  I haven't yet
decided what to recommend to the heat community, so I'm just mentioning
the issue as a possible concern.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>