Jump to: navigation, search

Difference between revisions of "Network/Lib/Meetings"

(Open Discussion)
m (Open Discussion)
Line 20: Line 20:
 
* [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? Doug suggested Kevin and Henry weigh in on my proposal, which is in https://review.openstack.org/#/c/265997/. Also, I started a thread on how to roll this out - http://lists.openstack.org/pipermail/openstack-dev/2016-January/083964.html
 
* [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? Doug suggested Kevin and Henry weigh in on my proposal, which is in https://review.openstack.org/#/c/265997/. Also, I started a thread on how to roll this out - http://lists.openstack.org/pipermail/openstack-dev/2016-January/083964.html
  
* [pc_m] Do we have a list of open items to work on (I'm available to take on another item)? Doug suggested UTs, as there is duplication with Neutron and some tests that can move.
+
* [pc_m] Do we have a list of open items to work on (I'm available to take on another item)? Doug suggested looking at *aaS UTs, and see what can be duplicated from Neutron, what can go into neutron-lib, etc.
  
 
* [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. I'll try to figure out what it broken there.
 
* [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. I'll try to figure out what it broken there.

Revision as of 18:22, 13 January 2016

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. Doug suggested marking with _ prefix, if in progress or need to iterate on item.
  • [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). Doug confirmed I should create a commit based on 242219 that uses the feature.
  • [pc_m] Do we have a list of open items to work on (I'm available to take on another item)? Doug suggested looking at *aaS UTs, and see what can be duplicated from Neutron, what can go into neutron-lib, etc.
  • [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. I'll try to figure out what it broken there.