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.) 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
