Octavia API needs a tenant facing API interface

[Michael Johnson]

As part of the "OpenStack LBaaS" (aka Neutron-LBaaS / Octavia merge) project we need to enable a tenant facing API interface in addition to the current "Operator API".

This would include setting up a tenant facing endpoint.

[alex kang (akang)]

Doe "Tenant facing API interface" mean tenant can create load-balancer?
In my devstack with multiple compute nodes, I can not use tenant to create load-balancer.

As the Octavia amphora VM is attached to lb-mgmt-net which is belong to admin.

[Michael Johnson (johnsom)]

Hi Alex,

This bug is an RFE to enhance the Octavia API to be ready to be a customer facing endpoint. Currently we are using the neutron API with the neutron-lbaas extension to allow tenants to create and use load balancers.

Also, please note, the lb-mgmt-net is purely for control plane communications between the Octavia controller the amphora. Tenant networks are connected in a network namespace inside the amphora as the customer configures their load balancer.

[Adam Harwell (adam-harwell)]

Adding this bug to my list of things to track for the final commits of the api merge.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459032
Committed: https://git.openstack.org/cgit/openstack/octavia/commit/?id=fb0da76c27735a965340e02cebff8be46271f579
Submitter: Jenkins
Branch: master

commit fb0da76c27735a965340e02cebff8be46271f579
Author: Adam Harwell <email address hidden>
Date: Sat Apr 22 11:12:11 2017 +0900

    Add support for single-create for APIv2

    Still need to fix the entry-points for each individual type, but that
    wasn't even in the original spec. Not sure if we even want that.

    I think this may not do things EXACTLY how the old one did it, we'll
    need to look into whether it matters, as we never published docs for it
    and I don't think it ever actually worked properly in neutron-lbaas.

    Also closing a few bugs that are only peripherally related, because we
    (possibly me) forgot to tag them on the individual CRs, but I'm
    considering them closed as of this patch. See below for my reasoning on
    each individual bug, and feel free to post counter-arguments.

    For #1673546 (single-call create): This is the obvious one!
    For #1673499 (lb return pool object): Rolled into this patch as a matter
    of course, abandoned the original fix as it is no longer relevant.
    For #1544214 (root tags): All existing resources now have root tags. Any
    new ones will also need root tags, but I would consider this bug closed.
    For #1596636 (tenant facing API): Every object is now creatable via the
    v2 API, so I would consider this to be complete. Quotas and some
    additional work is being finished, but it's not necessary for this IMO.
    For #1665446 (hm id): This was resolved in the HM patch, I just forgot
    to close it, and including it here will ensure it is release-tracked.
    For #1685789 (listener quota): Just shoving it in here as I do the
    single-create quotas.
    For #1685827 (hm quota): Same as listener quota.

    Closes-Bug: #1673546
    Closes-Bug: #1673499
    Closes-Bug: #1544214
    Closes-Bug: #1596636
    Closes-Bug: #1665446
    Closes-Bug: #1685789
    Closes-Bug: #1685827

    Depends-On: I3d86482a2999197a60a81d42afc5ef7a6e71e313

    Change-Id: I4ff03593e1cfd8dca00a13c0550d6cf95b93d746

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/octavia 1.0.0.0b2 development milestone.