[openstack-dev] [neutron][neutron-lib] Proposal for callback mechanism migration
Paul Michali
pc at michali.net
Wed Jan 13 11:49:01 UTC 2016
Reposted: as I had a typo in subject line that affected filtering of
message...
I wanted to float two ideas related to the neutron callback mechanism that
is being moved to neutron-lib.
1) API
The current API uses kwargs as a way for the notifier to pass information
to the subscribers listening (callbacks). One issue with this, is that the
actual keyword arguments used, could clash with the positional argument
names.
To address this, I'm proposing that we do the same as is done in the
Requests package to pass a payload to the get() method, where a 'params'
positional argument is used to hold a dict with the arguments to be passed
to the callback.
I've pushed a commit to neutron-lib for review
https://review.openstack.org/265997. Please provide your comments on that
as a proposed solution.
2) Migrating callbacks in neutron to use neutron-lib
I was thinking that the following plan (A) could work, as a way to migrate
to using the callback mechanism in neutron-lib:
1. In neutron, where callback notifications are performed, add a
duplicate notification to the neutron-lib callback notification.
2. In each client repo, change the subscription to subscribe to the
neutron-lib version of the resource/event tuple. At this time, the clients
could be altered to use the new 'params' positional argument
3. Once all the client repos have been updated, remove the old
notification calls from neutron, the callback code, and callback UTs.
An alternative proposal (B), *may* be to:
1. Change the notification wrapper method in registry.py to call both
the existing callback notify() and the one in neutron_lib. For the latter,
the kwargs would need to be stored in the params dict.
2. This and next step are the same as in proposal (A).
I think plan A gives more flexibility in converting kwargs into a param
dict, at the expense of more of a change impact (32 places/9 files).
Looking forward to community feedback on this...
Regards,
Paul Michali (pc_m)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160113/9d01fc14/attachment.html>
More information about the OpenStack-dev
mailing list