Jump to: navigation, search

Difference between revisions of "Network/Lib/Meetings"

(Open Discussion)
(26 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Meeting time: The neutron-lib sub-Team ([[Neutron-Lib]]) holds public meetings on Wednesdays at 1730 UTC in the #openstack-meeting-4 channel on Freednode. Everyone is encouraged to attend.'''
'''Meetings have been cancelled and made part of the weekly Neutron meetings until further notices
=== Announcements / Reminders ===
* Cancellation annoucement : http://lists.openstack.org/pipermail/openstack-dev/2016-November/107008.html
* Welcome
* Neutron Meetings: http://eavesdrop.openstack.org/#Neutron_Team_Meeting
* Wiki - https://wiki.openstack.org/wiki/Neutron/Lib
=== Current Work Items ===
* Finalize callbacks interface - https://review.openstack.org/#/c/253661/
* Do we hate pylint? - https://review.openstack.org/#/c/255682/
* db modules - what moves, what changes?
=== Open Discussion ===
* https://review.openstack.org/252155 is adding new common constants to neutron. IMO these should now be added to neutron-lib directly and and any code that needs the constants should import neutron-lib. Otherwise we end up adding to neutron then moving to neutron-lib, possibly with debtcollector overhead.
* [pc_m] Would like to discuss how we can mark the status of modules in the library for users. Should we (continue to use) the scheme of naming the directory/module with a leading underscore? I'm wondering if a better way would be to use a devref doc that indicates a module's status (experimental, released, deprecated). Then, once a module has been verified/tested by clients, we can do a simple doc change.
* [pc_m] created https://review.openstack.org/263786 to skip running tests, if a doc only change. Infra folks have +2ed and are waiting for liaison to review.
* [pc_m] https://review.openstack.org/259053 has API validators and converters code for neutron-lib. Show should I roll out this change to neutron? Do I use the module in neutron with a new commit, revise 242219 to include use of the module, or create a commit dependent on 242219 with use of the module?  Just trying to make sure I understand the strategy we want to use (especially in light of potential conflicting commits being made to neutron).
* [pc_m] For the callbacks, I'm thinking that the simple way to handle the concern of using keyword arguments, is to do like the Requests package and use a 'params' (dict) argument to hold all the callback specific arguments. Thoughts?
* [pc_m] Do we have a list of open items to work on (I'm available to take on another item)?
* [pc_m] Currently, IIRC, 242219 fails a few tests. Do we know why? Can they be resolved? It may be good to note somewhere, the issue with the tests, so that, as we add more capabilities to neutron-lib, if we see failures other than expected failures, we know that there are additional problems to address.

Latest revision as of 18:03, 9 November 2016

Meetings have been cancelled and made part of the weekly Neutron meetings until further notices