Open Stack

Fellow Octavians,

We covered a lot of ground during this PTG, met a number of new folks, and
got a lot of valuable feedback. I'll do my best to summarize here what was
discussed.

   1. Metrics
      1. It would be nice to expose metrics for pools/members, though we
      would like to get a better understanding of the requirements / use-cases.
      2. We should publish metrics using some mechanism (plugin/driver).
         1. The default would be "database" and would handle the existing
         API-exposed metrics.
         2. Additional drivers would be loaded in parallel, and might
         include Monasca/Ceilometer/Prometheus drivers.
      3. We will switch our metrics internally to use a delta system
      instead of absolute values from HAProxy. This will allow us to
publish in a
      more sane way in the future. This would not change the way metrics are
      exposed in the existing API.
   2. Notifications
      1. We will need to create a spec and gather community feedback.
      2. Initial observation indicates the need for two general paths,
      which will most likely have their own driver systems:
         1. provisioning_status changes (including all create/update/delete
         events)
         2. operating_status changes (member up/down, etc)
      3. We would provide the entire object in the notification, similar to
      what other services do.
      4. Most likely the default driver(s) would use oslo.notify.
   3. Availability Zone Support (Multi-Zone Fault Tolerance)
      1. Make at least a story for tracking this, if it doesn't already
      exist.
      2. Allow a single LB to have amphorae in multiple zones.
      3. Existing patch: https://review.opendev.org/#/c/558962/
   4. Availability Zone Support (Compute AZ Awareness)
      1. Make at least a story for tracking this, if it doesn't already
      exist.
      2. Allow placing LBs in specific zones:
         1. When zones are geographically separated, LBs should exist in
         the same zone as the members they support
         2. When zones are logically separated (like PCI compliance zones,
         etc), users may need to place them specifically.
      3. A new parameter  `availability_zone` will be added to the LB
      create API. It will allow the user to select which Octavia AZ to use.
      4. A new API section will be added for creating/configuring/listing
      Octavia AZs. This will allow a linkage between Compute AZs and Amphora
      Management Network, along with other possible options in the
future. Admins
      can create/update, and users can list zones.
      5. Update clients to support this, including further polluting the
      `openstack availability zone list` command to include `--loadbalancers`
      zones.
   5. Python 2 EOL
      1. Remove all jobs that test Python 2 (or update them if they're not
      duplicates).
      2. Remove six compatibility code, which should simplify string
      handling significantly.
   6. More Flavor Capabilities
      1. Image Tag (to allow different amp images per flavor)
      2. Availability Zone (to allow compute AZ pinning)
      3. Management Network (to go with compute AZ)
      4. Metadata (allow passing arbitrary metadata through to compute)
   7. TLS Protocol/Cipher API Support
      1. Allow users to select specific protocols/ciphers as a whitelist.
      2. Stories:
         1. Ciphers: https://storyboard.openstack.org/#!/story/2006627
         2. Protocols: https://storyboard.openstack.org/#!/story/2006733
      8. Performance Tuning
      1. HAProxy: There are a number of knobs/dials that can be adjusted to
      make HAProxy behave more efficiently. Some of these that we could look at
      more are around TLS options, and around multiprocessing/threading. The
      latter will probably need to wait for us to switch to HAProxy 2.0.
      2. Image Metadata: There are flags that could be added to our amphora
      image's metadata that might improve performance. To be further researched.
   9. Testing
      1. Team to evaluate existing non-voting jobs for promotion to voting.
         1. Agreement was made with the Barbican team to promote both
         side's co-gating jobs to voting.
      2. Team to evaluate merging or pruning some jobs to reduce the
      overall set that run on each change.
      3. Grenade needs a few changes:
         1. Switch to python3.
         2. Upgrade to Zuul v3.
         3. Test additional operations on existing LBs (old amp image), not
         just traffic.
      4. Test more than just the most recent amphora image against the
      current control-plane code. Use periodic jobs for this.
      5. Fix the Zuul grafana dashboard for Octavia test history.
   10. Jobboard
      1. This continues to be a priority for Ussuri.
      2. Put together a priority list of patches specifically for jobboard.
   11. HAProxy 2.0
      1. A number of features are gated behind the new version, including
      multi-process and HTTP/2 support.
      2. Need to reach out to distributions to push for backports (to
      cloudarchive for Ubuntu,  and whatever similar thing for CentOS).
      3. Possibly add an element to allow building new versions from source.
      4. Perform version-based validation of options on the API-side of the
      amphora driver.
         1. Inspect and cache Glance metadata for the LB's amphora image to
         get version data.
         2. Provide the metadata string for the operator from our
         disk-image-create script.


The full etherpad from the PTG including the notes I've summarized here is
available at https://etherpad.openstack.org/p/octavia-shanghai-U-ptg if
further review is desired.
Thanks to everyone who participated, and best of luck on this (hopefully)
productive new cycle!

    --Adam Harwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191111/3efcc8e8/attachment.html>