<div dir="ltr"><div>Fellow Octavians,</div><div><br></div>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.<br><ol><li>Metrics</li><ol><li>It would be nice to expose metrics for pools/members, though we would like to get a better understanding of the requirements / use-cases.</li><li>We should publish metrics using some mechanism (plugin/driver).</li><ol><li>The default would be "database" and would handle the existing API-exposed metrics.</li><li>Additional drivers would be loaded in parallel, and might include Monasca/Ceilometer/Prometheus drivers.</li></ol><li>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.</li></ol><li>Notifications</li><ol><li>We will need to create a spec and gather community feedback.</li><li>Initial observation indicates the need for two general paths, which will most likely have their own driver systems:</li><ol><li>provisioning_status changes (including all create/update/delete events)</li><li>operating_status changes (member up/down, etc)</li></ol><li>We would provide the entire object in the notification, similar to what other services do.</li><li>Most likely the default driver(s) would use oslo.notify.</li></ol><li>Availability Zone Support (Multi-Zone Fault Tolerance)</li><ol><li>Make at least a story for tracking this, if it doesn't already exist.</li><li>Allow a single LB to have amphorae in multiple zones.</li><li>Existing patch: <a href="https://review.opendev.org/#/c/558962/">https://review.opendev.org/#/c/558962/</a></li></ol><li>Availability Zone Support (Compute AZ Awareness)</li><ol><li>Make at least a story for tracking this, if it doesn't already exist.</li><li>Allow placing LBs in specific zones:</li><ol><li>When zones are geographically separated, LBs should exist in the same zone as the members they support</li><li>When zones are logically separated (like PCI compliance zones, etc), users may need to place them specifically.</li></ol><li>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.</li><li>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.</li><li>Update clients to support this, including further polluting the `openstack availability zone list` command to include `--loadbalancers` zones.</li></ol><li>Python 2 EOL</li><ol><li>Remove all jobs that test Python 2 (or update them if they're not duplicates).</li><li>Remove six compatibility code, which should simplify string handling significantly.</li></ol><li>More Flavor Capabilities</li><ol><li>Image Tag (to allow different amp images per flavor)</li><li>Availability Zone (to allow compute AZ pinning)</li><li>Management Network (to go with compute AZ)</li><li>Metadata (allow passing arbitrary metadata through to compute)</li></ol><li>TLS Protocol/Cipher API Support</li><ol><li>Allow users to select specific protocols/ciphers as a whitelist.</li><li>Stories:</li><ol><li>Ciphers: <a href="https://storyboard.openstack.org/#!/story/2006627">https://storyboard.openstack.org/#!/story/2006627</a></li><li>Protocols: <a href="https://storyboard.openstack.org/#!/story/2006733">https://storyboard.openstack.org/#!/story/2006733</a></li></ol></ol><li>Performance Tuning</li><ol><li>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.</li><li>Image Metadata: There are flags that could be added to our amphora image's metadata that might improve performance. To be further researched.</li></ol><li>Testing</li><ol><li>Team to evaluate existing non-voting jobs for promotion to voting.</li><ol><li>Agreement was made with the Barbican team to promote both side's co-gating jobs to voting.</li></ol><li>Team to evaluate merging or pruning some jobs to reduce the overall set that run on each change.</li><li>Grenade needs a few changes:</li><ol><li>Switch to python3.</li><li>Upgrade to Zuul v3.</li><li>Test additional operations on existing LBs (old amp image), not just traffic.</li></ol><li>Test more than just the most recent amphora image against the current control-plane code. Use periodic jobs for this.</li><li>Fix the Zuul grafana dashboard for Octavia test history.</li></ol><li>Jobboard</li><ol><li>This continues to be a priority for Ussuri.</li><li>Put together a priority list of patches specifically for jobboard.</li></ol><li>HAProxy 2.0</li><ol><li>A number of features are gated behind the new version, including multi-process and HTTP/2 support.</li><li>Need to reach out to distributions to push for backports (to cloudarchive for Ubuntu,  and whatever similar thing for CentOS).</li><li>Possibly add an element to allow building new versions from source.</li><li>Perform version-based validation of options on the API-side of the amphora driver.</li><ol><li>Inspect and cache Glance metadata for the LB's amphora image to get version data.</li><li>Provide the metadata string for the operator from our disk-image-create script.</li></ol></ol></ol><br>The full etherpad from the PTG including the notes I've summarized here is available at <a href="https://etherpad.openstack.org/p/octavia-shanghai-U-ptg">https://etherpad.openstack.org/p/octavia-shanghai-U-ptg</a> if further review is desired.<br>Thanks to everyone who participated, and best of luck on this (hopefully) productive new cycle!<br><div><br></div><div>    --Adam Harwell</div></div>