Ah, I see the point... So basically it is just updating one of the values of the cert object in Barbican. In this case yes, fully agree it should be marked as a bug and fixed asap.
Sorry for misunderstanding! On Fri, Jan 27, 2017 at 1:44 PM, Jiahao Liang (Frankie) < [email protected]> wrote: > Hi German, > > Once again, we are not talking about a real delete of a cert in whatever > cert storage. > > The problem we are trying to resolve is, even the lbaas is deleted, users > still see the lbaas is using the cert in Barbican. > We didn't call the deregister logic during lbaas deletion. > > Best, > > On Fri, Jan 27, 2017 at 11:37 AM, Jiahao Liang (Frankie) < > [email protected]> wrote: > >> Hi Andrey, >> >> The reason Barbican cert container has a property called consumer. The >> definition is as following: >> >>> What is a Consumer? >>> >>> >>>> A consumer is a way to register as an interested party for a container. >>>> All of the registered consumers can be viewed by performing a GET on the >>>> {container_ref}/consumers. The idea being that before a container is >>>> deleted all consumers should be notified of the delete. >>> >>> >> When we create a Terminated_HTTPS listener in lbaas, we register the >> lbaas as one of the consumers of corresponding cert container. >> >> But when we delete the listener/lb, we didn't deregister/revert the >> consumer registration. >> This deregister/revert is actually what delete_cert() do for Barbican >> cert_manager in neutron_lbaas, NOT a real delete. >> >> My suggestion was we need to add this deregister/revert procedure. >> >> Hope this helps. >> >> Best, >> >> On Fri, Jan 27, 2017 at 9:07 AM, Andrey Grebennikov < >> [email protected]> wrote: >> >>> Frankie, >>> >>> What is the reason why the cert has to be deleted on the balancer >>> deletion? >>> The entire workflow, if I'm not mistaken, is to first work with Barbican >>> API in order to create the cert bundle. And technically it is not yet >>> connected to anything else. >>> After that you create the balancer, specifying the link to where the >>> cert bundle is. >>> From this perspective, why one should expect the cert bundle to be >>> deleted? >>> >>> For me personally it is the same as deletion of the image automatically >>> once the instance got deleted :/ >>> >>> Sorry if I'm missing the context. >>> >>> On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell <[email protected]> >>> wrote: >>> >>>> 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) < >>>> [email protected]> 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 <[email protected]> >>>>> 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) < >>>>> [email protected]> 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/c >>>>> ontainers/453e8905-d42b-43bd-9947-50e3acf499f4 >>>>> +----------------+------------------------------------------ >>>>> -----------------------------------------------------------+ >>>>> | Field | Value >>>>> | >>>>> +----------------+------------------------------------------ >>>>> -----------------------------------------------------------+ >>>>> | Container href | http://192.168.20.24:9311/v1/c >>>>> ontainers/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/s >>>>> ecrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb >>>>> | >>>>> | Intermediates | None >>>>> | >>>>> | Private Key | http://192.168.20.24:9311/v1/s >>>>> ecrets/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/mit >>>>> aka/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_m >>>>> anager/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: [email protected] >>>>> >>>>> ____________________________________________________________ >>>>> ______________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: [email protected] >>>>> enstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> ____________________________________________________________ >>>>> ______________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: [email protected] >>>>> enstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> ____________________________________________________________ >>>>> ______________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: [email protected] >>>>> enstack.org?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: [email protected] >>>> enstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Andrey Grebennikov >>> Principal Deployment Engineer >>> Mirantis Inc, Austin TX >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected] >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> >> *梁嘉豪/Jiahao LIANG (Frankie) * >> Email: [email protected] >> >> > > > -- > > *梁嘉豪/Jiahao LIANG (Frankie) * > Email: [email protected] > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Andrey Grebennikov Principal Deployment Engineer Mirantis Inc, Austin TX
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
