What about the other way around? An Octavia plugin that simply manages k8s Ingress objects on a k8s cluster? Depending on how operators are deploying openstack, this might be a much easier way to deploy Octavia.
Thanks, Kevin ________________________________ From: Lingxian Kong [anlin.k...@gmail.com] Sent: Friday, March 16, 2018 5:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [k8s][octavia][lbaas] Experiences on using the LB APIs with K8s 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 <j...@topjian.net<mailto:j...@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-requ...@lists.openstack.org?subject:unsubscribe<http://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
