Open Stack

Zane Bitter <zbitter at redhat.com> wrote on 10/16/2013 10:30:44 AM:

> On 16/10/13 15:58, Mike Spreitzer wrote:
> ...
> > Thanks for a great short sharp answer.  In that light, I see a 
concern.
> >   Once a workflow has been generated, the system has lost the ability 
to
> > adapt to changes in either model.  In a highly concurrent and dynamic
> > environment, that could be problematic.
> 
> I think you're referring to the fact if reality diverges from the model 
> we have no way to bring it back in line (and even when doing an update, 
> things can and usually will go wrong if Heat's idea of the existing 
> template does not reflect reality any more). If so, then I agree that we 

> are weak in this area. You're obviously aware of 
> http://summit.openstack.org/cfp/details/95 so it is definitely on the 
radar.

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.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/92329adb/attachment.html>