Open Stack

Thanks rm_work.

I also notice something need to be handled properly.

For barbican, the delete_cert() only deregisters the cert without actually
delete it. That's safe for us to call during
delete_listener()/delete_loadbalancer().

But if the user uses other cert_manager by any chance, say the
local_cert_manager, the same delete_cert() method will do a real delete of
the cert.

Probably we need to implement register_consumer()/remove_consumer() method
for cert_manager and call them in neutron_lbaas as well.


On Wed, Jan 25, 2017 at 10:48 Adam Harwell <flux.adam at gmail.com> wrote:

> I've got this on my list of things to look at -- I don't know if it was
> you I was talking with on IRC the other day about this issue, but I'm
> definitely aware of it. As soon as we are past the Ocata feature freeze
> crunch, I'll take a closer look.
>
> My gut says that we should be calling the delete (which is not a real
> delete) when the LB is deleted, and not doing so is a bug, but I'll need to
> double check the logic as it has been a while since I touched this.
>
>     --Adam (rm_work)
>
> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
> gzliangjiahao at gmail.com> wrote:
>
> Hi community,
>
> I created a loadbalancer with a listener with protocol as
> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
> secret container from Barbican.
> However, after I deleted the listener, the lbaas wasn't removed from
> barbican container consumer list.
>
> $openstack secret container get http://192.168.20.24:9311/v1/
> containers/453e8905-d42b-43bd-9947-50e3acf499f4
> +----------------+------------------------------------------
> -----------------------------------------------------------+
> | Field          | Value
>                                             |
> +----------------+------------------------------------------
> -----------------------------------------------------------+
> | Container href | http://192.168.20.24:9311/v1/
> containers/453e8905-d42b-43bd-9947-50e3acf499f4                        |
> | Name           | tls_container2
>                                              |
> | Created        | 2017-01-19 12:44:07+00:00
>                                             |
> | Status         | ACTIVE
>                                              |
> | Type           | certificate
>                                             |
> | Certificate    | http://192.168.20.24:9311/v1/
> secrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb                           |
> | Intermediates  | None
>                                              |
> | Private Key    | http://192.168.20.24:9311/v1/
> secrets/c85d150e-ec84-42e0-a65f-9c9ec19767e1                           |
> | PK Passphrase  | None
>                                              |
> | *Consumers      | {u'URL':
> u'lbaas://RegionOne/loadbalancer/5e7768b9-7aa9-4146-8a71-6291353b447e',
> u'name': u'lbaas'}*
>
>
> I went through the neutron-lbaas code base. We did register consumer
> during the creation of "TERMINATED_HTTPS" listener in [1]. But we somehow
> doesn't deregister it during the deletion in [1]: https://github.com/
> openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/
> services/loadbalancer/plugin.py#L642
> get_cert() register lbaas as a consumer for barbican cert_manager.  (
> https://github.com/openstack/neutron-lbaas/blob/
> stable/mitaka/neutron_lbaas/common/cert_manager/barbican_
> cert_manager.py#L177)
> [2]: https://github.com/openstack/neutron-lbaas/blob/
> stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L805
> we probably need to call delete_cert from barbican cert_manager to remove
> the consumer. (https://github.com/openstack/neutron-lbaas/blob/stable/
> mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L187)
>
>
> My questions are:
> 1. is that a bug?
> 2. or is it a intentional design letting the vendor driver to handle it?
>
> It looks more like a bug to me.
>
> Any thoughts?
>
>
> Best,
> Jiahao
> --
>
> *梁嘉豪/Jiahao LIANG (Frankie)     *
> Email: gzliangjiahao at gmail.com
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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/20170125/cea2fc16/attachment-0001.html>