On Fri, Mar 16, 2018 at 5:01 AM, Joe Topjian <[email protected]> wrote:
> Hi Chris, > > I wear a number of hats related to this discussion, so I'll add a few > points of view :) > > It turns out that with >> Terraform, it's possible to tear down resources in a way that causes >> Neutron to >> leak administrator-privileged resources that can not be deleted by a >> non-privileged users. In discussions with the Neutron and Octavia teams, >> it was >> strongly recommended that I move away from the Neutron LBaaSv2 API and >> instead >> adopt Octavia. Vexxhost graciously installed Octavia and my request and I >> was >> able to move past this issue. >> > > Terraform hat! I want to slightly nit-pick this one since the words "leak" > and "admin-priv" can sound scary: Terraform technically wasn't doing > anything wrong. The problem was that Octavia was creating resources but not > setting ownership to the tenant. When it came time to delete the resources, > Octavia was correctly refusing, though it incorrectly created said > resources. > > From reviewing the discussion, other parties were discovering this issue > and patching in parallel to your discovery. Both xgerman and Vexxhost > jumped in to confirm the behavior seen by Terraform. Vexxhost quickly > applied the patch. It was a really awesome collaboration between yourself, > dims, xgerman, and Vexxhost. > > >> This highlights the first call to action for our public and private cloud >> community: encouraging the rapid migration from older, unsupported APIs to >> Octavia. >> > > Operator hat! The clouds my team and I run are more compute-based. Our > users would be more excited if we increased our GPU pool than enhanced the > networking services. With that in mind, when I hear it said that "Octavia > is backwards-compatible with Neutron LBaaS v2", I think "well, cool, that > means we can keep running Neutron LBaaS v2 for now" and focus our efforts > elsewhere. > > I totally get why Octavia is advertised this way and it's very much > appreciated. When I learned about Octavia, my knee-jerk reaction was "oh > no, not another load balancer" but that was remedied when I learned it's > more like LBaaSv2++. I'm sure we'll deploy Octavia some day, but it's not > our primary focus and we can still squeak by with Neutron's LBaaS v2. > > If you *really* wanted us to deploy Octavia ASAP, then a migration guide > would be wonderful. I read over the "Developer / Operator Quick Start > Guide" and found it very well written! I groaned over having to build an > image but I also really appreciate the image builder script. If there can't > be pre-built images available for testing, the second-best option is that > script. > Periodic builds of Ubuntu and CentOS pre-built test images coming soon: https://review.openstack.org/#/c/549259/ Periodic builds by the RDO project: https://images.rdoproject.org/octavia/master/ ( https://review.rdoproject.org/r/#/c/11805/) > >> This highlights a second call to action for the SDK and provider >> developers: >> recognizing the end of life of the Neutron LBaaSv2 API[4][5] and adding >> support for more advanced Octavia features. >> > > Gophercloud hat! We've supported Octavia for a few months now, but purely > by having the load-balancer client piggyback off of the Neutron LBaaS v2 > API. We made the decision this morning, coincidentally enough, to have > Octavia be a first-class service peered with Neutron rather than think of > Octavia as a Neutron/network child. This will allow Octavia to fully > flourish without worry of affecting the existing LBaaS v2 API (which we'll > still keep around separately). > > Thanks, > Joe > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
