[openstack-dev] [all] Treating notifications as a contract
Matt Dietz
matt.dietz at rackspace.com
Thu Jul 10 21:43:24 UTC 2014
-----Original Message-----
From: Eoghan Glynn <eglynn at redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Thursday, July 10, 2014 at 3:30 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [all] Treating notifications as a contract
>
>
>> 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?
Yessir :-)
>
>> 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.
Sorry, I’ve been away and hadn’t read the entire thread yet. Didn’t mean
to rehash an existing point.
>
>Cheers,
>Eoghan
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list