Open Stack

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) <
gzliangjiahao at gmail.com> 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) <
> gzliangjiahao at gmail.com> 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 <
>> agrebennikov at mirantis.com> 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 <flux.adam at gmail.com>
>>> 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) <
>>>> 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/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: gzliangjiahao at gmail.com
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>>> enstack.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.op
>>>>> enstack.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.op
>>>>> enstack.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.op
>>>> 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: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>
>> *梁嘉豪/Jiahao LIANG (Frankie)     *
>> Email: gzliangjiahao at gmail.com
>>
>>
>
>
> --
>
> *梁嘉豪/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
>
>


-- 
Andrey Grebennikov
Principal Deployment Engineer
Mirantis Inc, Austin TX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170127/4b8118a1/attachment.html>