On 20/11/13 20:09, Mike Spreitzer wrote:
Zane Bitter <zbit...@redhat.com> wrote on 11/15/2013 05:59:06 PM:
> On 15/11/13 22:17, Keith Bray wrote:
> > The way I view 2 vs. 4 is that 2 is more complicated and you don't gain
> > any benefit of availability. If, in 2, your global heat endpoint
is down,
> > you can't update the whole stack. You have to work around it by
talking
> > to Heat (or the individual service endpoints) in the region that is
still
> > alive.
>
> Not really, you still have the templates for all of the nested stacks
> that are in the remaining region(s). You can manipulate those directly
> and not risk getting things out of sync when the Heat master comes back.
>
> If you really want a global stack, you can recreate it in a different
> region and adopt the remaining parts.
If there were no dynamic data flowing between regions then the story
would be this simple. But we have not forbidden output from one
regional template to be used in the input to another. Maybe we should?
That would rule out some situations where a user can write something
that looks valid but will simply not work (e.g., communicate cross
region via wait condition). That would only leave the problem of how
the client keeps track of the outputs.
You're completely correct of course, there will be a bunch of stuff like
that which appears to be possible but actually doesn't work. One
advantage of (2) is that the boundary is at least defined, whereas with
(4) stuff that doesn't work just looks like any other template. (Wait
conditions split across templates don't actually work now, so in that
sense this makes it no worse ;)
I don't think we want to prohibit it though, because there's a lot of
stuff that is legitimate to pass (any data that isn't region-scoped,
like public IP addresses).
Maybe one day we'll be able to build in some fancy logic to figure out
what is valid and what is not.
OTOH, the more we restrict what can be done, the less useful this really
is.
Yes, and if we restrict passing any data, it's probably not going to be
useful at all.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
