Jump to: navigation, search

Difference between revisions of "Network/Lib/Meetings"

(Open Discussion)
Line 13: Line 13:
  
 
[boden]
 
[boden]
* 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?
+
* Looking for feedback on the high-level approach for a public python API generation tool as in [https://review.openstack.org/#/c/338571/ 338571]. NB: code is not ready for review, just looking to understand if the current approach is worth honing further.
* 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.
+
* 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.
* 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

  • None this week

Current Work Items

Open Discussion

[boden]

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