Open Stack

Hi Neutrinos,

For those of you who couldn't join in person, please find a few notes below
to capture some of the highlights of the event.

I would like to thank everyone one who helped me put this report together,
and everyone who helped make this mid-cycle a fruitful one.

I would also like to thank IBM, and the individual organizers who made
everything go smoothly.

Feel free to reach out if something is unclear, incorrect or incomplete.

Cheers,
Armando

~~~~~~~

We touched on these topics (as initially proposed on
https://etherpad.openstack.org/p/neutron-mitaka-midcycle)

   - Neutron-lib: discussed strategy for taking base DB model and context
   code into neutron-lib and getting rid of common-db-mixin. More to
   follow/baking in
   - Routed-networks
      - Develpment started as per specification
      https://review.openstack.org/#/c/225384/. In particular:
      - Client patches
         - Segment extension
         - segments / host mapping
         - Troubleshooting
      - A number of proposals have been made over time, armax intends to
      push back on them all and invite the team to pause and think
about this as
      two separate problems, which are at two different level of
      abstractions/complexity. Neutron, like an automobile, needs a dashboard
      whose warning lights provide feedback to the operator; only once this is
      available, well understood and well documented, remedy actions and
      effective tools in the toolbox can be implemented/used when digging under
      the bonnet. We clearly have an inexistent or an inadequate dashboard so
      far; figuring out what this dashboard looks like should be the first step
      to improve operability of Neuton deployments. More to follow on
pending RFE
      bug.
         - https://bugs.launchpad.net/neutron/+bug/1507499
         - Some preliminary notes available at:
         https://etherpad.openstack.org/p/neutron-troubleshooting
         - Usability and stability fixes:
      - MTU cleanups: Implemented all MTU changes in Nova and Neutron
      required to fix the interface MTU setting mismatches identified
by Matt and
      Sean. Deprecated the old network device mtu option in Nova and Neutron.
      Started working on a patch to address an issue when tunnels are used over
      IPv6 endpoints since the additional 20 byte overhead is not accounted for.
         - https://bugs.launchpad.net/neutron/+bug/1542108
         - https://bugs.launchpad.net/neutron/+bug/1542475
         - https://review.openstack.org/#/c/283798/
         - https://review.openstack.org/#/c/285532/
         - https://review.openstack.org/#/c/284818/
         - https://review.openstack.org/#/c/283790/
         - https://review.openstack.org/#/c/284814/
      - L3 HA: Worked out some race conditions in L3 HA when the server is
      receiving lots of router creates/deletes for the same tenant and
pushed two
      patches to fix them.
         - https://review.openstack.org/#/c/282876/14
         - Reduce IP consumptions for router gateway ports (both DVR and
      non). carl_baldwin to put up model proposal, haleyb to follow up
with code.
   - CI jobs cleanup
      - Assaf and armax had a chat about the -plus job and the current
      marching order is:
      - keep the API job as is; in the medium term they would like to adopt
         the same approach taken by the functional job to streamline
the setup (e.g.
         setting up Keystone and Neutron only); this way they can cut
back on the
         time to feedback as far as API tests go.
         - continue to use the -plus job to run scenario tests, that
         requires the setup of an end-to-end cloud (Nova, Glance,
Keystone, Neutron,
         et al).
         - Keeping the two jobs separate should help better tolerate,
         identify and isolate potential intermittent failures induced
by scenario
         tests, by keeping the api job stable and on both check and gate queues.
         - Continue the de-fork effort
            - https://review.openstack.org/#/c/280427/
            - https://review.openstack.org/#/c/285116/
         - Nova integration aspects
      - Continued the conversation on get-me-a-network, thanks to Matt
      Riedemann for kickstarting the nova side of the effort
         - Nova spec: https://review.openstack.org/#/c/283206/
         - Neutron blueprint dashboard:
         https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
         - Documentation: https://review.openstack.org/#/c/283133/
         - Provide validation api to reduce amount of api calls to make
         between nova/neutron:
            - https://review.openstack.org/#/c/283849/
            - https://review.openstack.org/#/c/284307/
            -  Made progress on Nova live migration with DVR patches,
         including removing a flaky tempest test from the gate when neutron is
         enabled.
         - Talked about cells v2 and what Neutron can do, if at all, to
         adopt the same architecture. mlavalle to track nova
development and put
         notes together.
      - OpenStack client transition plan
      - Richard and armax sat down to finalize transition plan and chose
      deprecation/development strategies from Newton onwards
         - https://review.openstack.org/#/c/282555/
         - https://etherpad.openstack.org/p/osc-neutron-support
         - https://bugs.launchpad.net/neutron/+bug/1521291
         - OVN and OVS integration
      - How to deal with destination MAC that OVN does not recognize
      - discussion on current and future work for OVN features and scale
      - discussion on how routed network models and FIPs fit in OVN
      deployments
      - API docs and docs in general
      - Sam-I-Am evangelized the importance of docs and we all listened and
      nodded in awe
      -  DNS integration chapter for networking Guide
      - Catching up on transition plan to adopt swagger
   - Stadium: discussed pros and cons of approaches for structuring
   networking projects in openstack governance; arnax to respin
   https://review.openstack.org/#/c/281628/ for updates.

We didn't cover everything as planned, but that's the beauty of reality
shows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160226/703b8e19/attachment.html>