[openstack-dev] [Neutron] neutron-lib report from the summit

Henry Gessau HenryG at gessau.net
Tue May 3 23:46:03 UTC 2016

At the Newton summit in Austin we held a session on the next steps for
neutron-lib. Here is a report on what was discussed at the session.


Progress so far
The package is on PyPI and sub-projects should be using it now.

Only the very obvious and easy items have been added to neutron-lib:
  - Common constants
  - Common exceptions
  - Attribute converters and validators
  - Common hacking checks, including one to aid decoupling (N530)

Adding database and DB model support
We are leaning towards a common pattern for interacting with neutron resources
using oslo versioned objects (OVOs). The OVO work in neutron core needs to
mature a bit before we start moving it to neutron-lib.

Some basic DB utility methods will be added to allow sub-projects to add and
update their own tables.

Architecture decisions
  - Should there be more than one library, with smaller pieces?
  - Decide what is useful before just trying to do  everything.
  - Decide on Callbacks: OVO integration, or something else?
  - OVOs are new in neutron core, which means they are inherently unstable
    (undergoing changes) and buggy. The goal is for neutron-lib to contain
    stable and proven code, yet OVOs are permeating many of the things we
    want in neutron-lib. How do we reconcile this?

We need to write API documentation. Contributions are welcome.
We need to expand the devref with details on how to use the lib, how to add
things, how to work on dependent code without being blocked, etc.

Work planned for Newton (and beyond)
  - DB common utils (for operations not requiring OVO)
  - DB common framework with OVO integration
  - DB alembic migration interface
  - RPC common framework and utilities
  - Finalize Callbacks
  - Context support
  - Policy support
  - Config support, on top of oslo.config?
  - Agent common utils/framework?
  - Extensions common utils/framework?

We should try to determine the priority of these planned items.

We should have a Release Cadence strategy. We can decide on publishing a
release at each weekly meeting, or have a regular cadence, or have a process
similar to oslo libraries.

More information about the OpenStack-dev mailing list