Difference between revisions of "Network/Lib/Meetings"
(→Open Discussion) |
(→Open Discussion) |
||
Line 15: | Line 15: | ||
* As per [https://review.openstack.org/#/c/333500/ 333500] we need to devise a hacking check policy/process moving forward. How to manage breakages/dependencies with consumers who use our checks.factory()? Should we add gate-neutron-pep8 to our gate to help detect when/if we break neutron pep8? | * As per [https://review.openstack.org/#/c/333500/ 333500] we need to devise a hacking check policy/process moving forward. How to manage breakages/dependencies with consumers who use our checks.factory()? Should we add gate-neutron-pep8 to our gate to help detect when/if we break neutron pep8? | ||
* From our [http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-06-27.log.html neutron meeting] we should likely select a new target project to deliver as part of our newton work since lbaas now has a spin-off. | * From our [http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-06-27.log.html neutron meeting] we should likely select a new target project to deliver as part of our newton work since lbaas now has a spin-off. | ||
− | |||
* Do we really want to run with the [https://review.openstack.org/#/c/333017/ forbid eventlet patch] as it seems we may be a bit early on this train? | * Do we really want to run with the [https://review.openstack.org/#/c/333017/ forbid eventlet patch] as it seems we may be a bit early on this train? | ||
* I'm going to try and kick the tires a bit more on neutron-lib callbacks. In particular I'm thinking of proposing a backwards compatible change in neutron that can use OVO. The thought is to get neutron on-board with a new callback API that can support OVO, then get that support into neutron-lib, etc. For example [https://review.openstack.org/#/c/279734/ 279734] that Paul did, but no longer has bandwidth to drive. | * I'm going to try and kick the tires a bit more on neutron-lib callbacks. In particular I'm thinking of proposing a backwards compatible change in neutron that can use OVO. The thought is to get neutron on-board with a new callback API that can support OVO, then get that support into neutron-lib, etc. For example [https://review.openstack.org/#/c/279734/ 279734] that Paul did, but no longer has bandwidth to drive. |
Revision as of 17:26, 29 June 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
- None this week
Current Work Items
- Using the lib in neutron - https://review.openstack.org/#/c/268232/
- Moving base db gunk - https://review.openstack.org/#/c/267214/
Open Discussion
[boden]
- As per 333500 we need to devise a hacking check policy/process moving forward. How to manage breakages/dependencies with consumers who use our checks.factory()? Should we add gate-neutron-pep8 to our gate to help detect when/if we break neutron pep8?
- From our neutron meeting we should likely select a new target project to deliver as part of our newton work since lbaas now has a spin-off.
- Do we really want to run with the forbid eventlet patch as it seems we may be a bit early on this train?
- I'm going to try and kick the tires a bit more on neutron-lib callbacks. In particular I'm thinking of proposing a backwards compatible change in neutron that can use OVO. The thought is to get neutron on-board with a new callback API that can support OVO, then get that support into neutron-lib, etc. For example 279734 that Paul did, but no longer has bandwidth to drive.