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.a...@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) < > gzliangjia...@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: gzliangjia...@gmail.com > > __________________________________________________________________________ > 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 > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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