Jump to: navigation, search

Network/Lib/Meetings

Revision as of 12:08, 6 January 2016 by Paul Michali (talk | contribs) (Open Discussion)

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.

Announcements / Reminders

Current Work Items

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] 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.