Open Stack

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/
>>> 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.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.openstack.org?subject:unsubscrib
>> e
>> 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.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

*梁嘉豪/Jiahao LIANG (Frankie)     *
Email: gzliangjiahao at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170127/a1510119/attachment.html>