Zane Bitter <[email protected]> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
