Open Stack

Just FYI, l7 policy/rule support for Neutron LBaaS V2 and Octavia is on its
way[1], because we will have both octavia and magnum deployed on our
openstack based public cloud this year, an ingress controller for
openstack(octavia) is also on our TODO list, any kind of collaboration are
welcomed :-)

[1]: https://github.com/gophercloud/gophercloud/pull/833


Cheers,
Lingxian Kong (Larry)

On Fri, Mar 16, 2018 at 5:01 PM, 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.
>
>
>> 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/20180317/3497a913/attachment.html>