Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Andrey Grebennikov]

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) <
gzliangjia...@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) <
> gzliangjia...@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 <
>> agrebenni...@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 
>>> 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) <
 gzliangjia...@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 
> 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 

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

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) <
gzliangjia...@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 <
> agrebenni...@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 
>> 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) <
>>> gzliangjia...@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  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/c
 ontainers/453e8905-d42b-43bd-9947-50e3acf499f4
 ++--
 

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

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 <
agrebenni...@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  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) <
>> gzliangjia...@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  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/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
>>> 

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[German Eichberger]

Hi,

The idea was that we would like to let the user know in Barbican when the 
certificate is being used with LBaaS. Therefore, we added the register and 
de-register logic. I don’t know of any use case where a certificate needs to be 
deleted in Barbican when LBaaS doesn’t need it any longer.

So I agree with Andrey – it’s the same semantic as images.

German

From: Andrey Grebennikov <agrebenni...@mirantis.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Friday, January 27, 2017 at 12:07 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: Subrahmanyam Ongole <song...@oneconvergence.com>
Subject: Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get 
deregistered in barbican after lbaas listener delete

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

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Andrey Grebennikov]

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  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) <
> gzliangjia...@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  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
>> 

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Adam Harwell]

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) 
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  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 

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

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  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

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Adam Harwell]

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) 
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-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

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