Open Stack

Yeah, I believe it was because we intended to leave it up to the specific
certificate manager to determine what needs to be done -- we are treating
it as a delete, and if the cert manager wants to do a true delete, they
can. I'll agree the verb is not perfectly clear, but the driver author
should make sure the correct action is taken regardless of the function
name.

It's possible we should just rename the function to something like
"unget_cert", which sounds a bit nonsensical but is possibly still clearer.
I remember at the time I wrote this being frustrated with trying to name
the function and wanting to just move on. T_T

   --Adam (rm_work)

PS: Did we remove the local cert manager yet? Now I need to check... I hope
so, because it's not actually usable, nor can it be without API
modifications (which we discussed but never actually implemented or even
fully agreed on).

On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <gzliangjiahao at gmail.com>
wrote:

> 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
>
> __________________________________________________________________________
> 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/20170127/1c6fdee4/attachment.html>