Open Stack

> This is, I believe, sufficient to solve our entire problem.
> Specifically, we have no need for an indirection API that rebroadcasts
> messages that are too new (since that can't happen with pinning) and no
> need for Versioned Objects in the RPC layer. (Versioned objects for the
> DB are still critical, and we are very much better off for all the hard
> work that Michal and others have put into them. Thanks!)

So all your calls have simple types for all the arguments? Meaning,
everything looks like this:

  do_thing(uuid, 'foo', 'bar', 123)

and not:

  do_thing(uuid, params, data, dict_of_stuff)

?

If you have the latter, then just doing RPC versioning is a mirage. Nova
has had basic RPC versioning forever, but we didn't get actual upgrade
ability until we tightened the screws on what we're actually sending
over the wire. Just versioning the signatures of the calls doesn't help
you if you're sending complex data structures (such as our Instance)
over the wire.

If you think that the object facade is necessary for insulating you from
DB changes, I feel pretty confident that you need it for the RPC side
for the same reason. Unless you're going to unpack everything from the
object into primitive call arguments and ensure that nobody ever changes
one. If you pull things out of the DB and send them over the wire, then
the DB schema affects your RPC API.

> The nature of Heat's RPC API is that it is effectively user-facing - the
> heat-api process is essentially a thin proxy between ReST and RPC. We
> already have a translation layer between the internal representation(s)
> of objects and the user-facing representation, in the form of
> heat.engine.api, and the RPC API is firmly on the user-facing side. The
> requirements for the content of these messages are actually much
> stricter than anything we need for RPC API stability, since they need to
> remain compatible not just with heat-api but with heatclient - and we
> have *zero* control over when that gets upgraded. Despite that, we've
> managed quite nicely for ~3 years without breaking changes afaik.

I'm not sure how you evolve the internals without affecting the REST
side if you don't have a translation layer. If you do, then the RPC API
changes independently from the REST API.

Anyway, I don't really know anything about the internals of heat, and am
completely willing to believe that it's fundamentally different in some
way that makes it immune to the problems something like Nova has trying
to make this work. I'm not sure I'm convinced of that so far, but that's
fine :)

--Dan