Open Stack

On Fri, Mar 16, 2018 at 5:01 AM, Joe Topjian <joe at topjian.net> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180316/13fa57a7/attachment.html>