| || |
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? |+|
* [https://review.openstack.org/#/c// ]. to .
|−|* 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. |+|
we if we neutron-/we of neutron-lib of that to a get into lib. , to .
|−|* 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. | |
Revision as of 16:07, 7 July 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
- Looking for feedback on the high-level approach for a public python API generation tool as in 338571. NB: code is not ready for review, just looking to understand if the current approach is worth honing further.
- Have we put any thought into what impacts it would have if we released neutron-lib more frequently/continuously? For example suppose we did releases of neutron-lib every 2 weeks (for sake of argument); what implications would that have to our process and consumers? With our current release process there's a large latency when trying to get function into lib. While I understand the merits of this approach, it "seems" to impact adoption/consumption.