Difference between revisions of "Network/Lib/Meetings"
Paul Michali (talk | contribs) (→Open Discussion) |
Paul Michali (talk | contribs) (→Open Discussion) |
||
| Line 14: | Line 14: | ||
* 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. | * 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] 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] | + | * [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] https://review.openstack.org/ | + | * [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] | + | * [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] 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. | ||
Revision as of 18:12, 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
- Welcome
- 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. 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] 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] 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.
