> On Mar 16, 2018, at 7:40 AM, Simon Leinen <simon.lei...@switch.ch> wrote: > > Joe Topjian writes: >> 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. > > I dunno... if Octavia created those lower-layer resources on behalf of > the user, then Octavia shouldn't refuse to remove those resources when > the same user later asks it to - independent of what ownership Octavia > chose to apply to those resources. (It would be different it Neutron or > Nova were asked by the user directly to remove the resources created by > Octavia.) > >> 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. > > Speaking as another operator: Does anyone seriously expect us to deploy > a service (Octavia) in production at a stage where it exhibits this kind > of behavior? Having to clean up leftover resources because the users who > created them cannot remove them is not my idea of fun. (And note that > like most operators, we're a few releases behind, so we might not even > get access to backports IF this gets fixed.)
Simon and Joe, one thing that I was not clear on (again, goes back to the statement that mistakes I make are my own), is that this is behavior, admin-scoped resources being created then not released, was seen in the Neutron LBaaSv2 service. The fix _was_ to deploy Octavia and not use the Neutron API. As such, I'm reluctant to use Terraform (or really, any other SDK) to deploy load balancers against the Neutron API. I don't want to be leaking a bunch of resources I can't delete. It's not good for the apps I’m trying to run and it’s definitely not good for the cloud provider. I have much more confidence developing against the Octavia service. We figured this out as a group effort between Vexxhost, Joe, and the Octavia team, and I'm exceptionally grateful to all of them for helping me to sort those issues out. Now, I ultimately dropped it in my own code because I can't rely on the existence of Octavia across all clouds. It had nothing to do with the either the reliability of the GopherCloud/Terraform SDKs or Octavia itself. So, to repeat, leaking admin-scoped resources is a Neutron LBaaSv2 bug, not an Octavia bug. > In our case we're not a compute-oriented cloud provider, and some of our > customers would really like to have a good LBaaS as part of our IaaS > offering. But our experience with this was so-so in the past - for > example, we had to help customers migrate from LBaaSv1 to LBaaSv2. Our > resources (people, tolerance to user-affecting bugs and forced upgrades > etc.) are limited, so we've become careful. > > For users who want to use Kubernetes on our OpenStack service, we rather > point them to Kubernetes's Ingress controller, which performs the LB > function without requiring much from the underlying cloud. Seems like a > fine solution. > -- > Simon. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev