> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
