[openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

Ian Wells ijw.ubuntu at cack.org.uk
Thu Sep 1 20:53:47 UTC 2016


On 1 September 2016 at 06:52, Ken Giusti <kgiusti at gmail.com> wrote:

> On Wed, Aug 31, 2016 at 3:30 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:
>
> > I have opinions about other patterns we could use, but I don't want to
push

> > my solutions here, I want to see if this is really as much of a problem
> as
> > it looks and if people concur with my summary above.  However, the right
> > approach is most definitely to create a new and more fitting set of oslo
> > interfaces for communication patterns, and then to encourage people to
> move
> > to the new ones from the old.  (Whether RabbitMQ is involved is neither
> here
> > nor there, as this is really a question of Oslo APIs, not their
> > implementation.)
> >
>
> Hmmmmmm... maybe.   Message bus technology is varied, and so is it's
> behavior.  There are brokerless, point-to-point backends supported by
> oslo.messaging [1],[2] which will exhibit different
> capabilities/behaviors from the traditional broker-based
> store-and-forward backend (e.g. message acking end-to-end vs to the
> intermediary).
>

The important thing is that you shouldn't have to look behind the curtain.
We can offer APIs that are driven by the implementation (designed for test,
and trivial to implement correctly given handy open source projects we know
and trust) and the choice of design will therefore be dependent on the
backend mechanisms we consider for use to implement the API.  APIs are
always a point of negotiation between what the caller needs and what can be
implemented in a practical amount of time.  But *I do not care* whether
you're using rabbits or carrier pigeons just so long as what you have
documented that the API promises me is actually true.  I *do not expect* to
have to read RabbitMQ ior AMQP documentation to work out what behaviour I
should expect for my messaging.  And its behaviour should be consistent if
I have a choice of messaging backends.

> All the more reason to have explicit delivery guarantees and well
> understood failure scenarios defined by the API.

And on this point we totally agree.

I think the point of an API is to subdivide who carries which
responsibilities - the caller for handling exceptional cases and the
implementer for having predictable behaviour.  Documentation is the means
of agreement.

Sorry to state basic good practice - I'm sure we do all accept that this is
good behaviour - but with a component that's this central to what we do and
so frequently used by so many people I think it's worth reiterating.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160901/a85a6e36/attachment.html>


More information about the OpenStack-dev mailing list