Open Stack

On 20/11/13 20:09, Mike Spreitzer wrote:
> Zane Bitter <zbitter at 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.