> The original implementation of the notification system was never intended > to be the *final* implementation. I think we all identified the need for > versioning several years ago. As for backwards compatibility, I think the > version field itself, in whatever form it takes, should be optional. If > not provided, it can be assumed the body of the notification is freeform.
Fair point. > Adding fields is easy. Removal of fields should only occur after we can > comfortably say that all services are only consuming the new field and > we¹ve left sufficient time for deprecating the old ones. Put on the deprecation path, then eventually bump the version when the old field finally goes away, right? > In some capacity, I think PubSubHubBub has a lot to offer here. The > publisher has to be able to provide a list of feeds it¹s authoritative > for, which I think is sufficient for discovery. I think PSHB itself is bit > heavy weight for what we need (and has some scaling problems) but I think > the concept itself is very useful for us. Note to self: learn more about PSHB. > >> 4. external discoverability of which event types a service is consuming > > > >Isn't this what the topic queues are for? Consumers should only > >subscribe to the topics they're interested in > > I¹m not sure I understand the value of this one. A service consumes what > it consumes. If we¹ve versioned correctly, as mentioned above, why does it > matter? Yes, as I said in other responses on this thread, the potential usefulness of that is rapidly receding in my mind. Cheers, Eoghan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
