Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete
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
Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete
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-
Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete
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
[openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete
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
Re: [openstack-dev] [neutron][lbaas][heat][octavia] Heat engine doesn't detect lbaas listener failures
But in the lbaas db, all lbaas resources have the provisioning_status and operating_status fields[1]. [1] http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/db/loadbalancer/models.py#n352 Also there are apis which allows drivers to maintain them[2]. [2] http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/agent/agent_manager.py#n255 __ 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][heat][octavia] Heat engine doesn't detect lbaas listener failures
On Tue, Sep 27, 2016 at 5:35 PM, Rabi Mishra wrote: > On Wed, Sep 28, 2016 at 1:01 AM, Zane Bitter wrote: > >> On 27/09/16 15:11, Jiahao Liang wrote: >> >>> Hello all, >>> >>> I am trying to use heat to launch lb resources with Octavia as backend. >>> The template I used is >>> from https://github.com/openstack/heat-templates/blob/master/hot/ >>> lbaasv2/lb_group.yaml. >>> >>> Following are a few observations: >>> >>> 1. Even though Listener was created with ERROR status, heat will still >>> go ahead and mark it Creation Complete. As in the heat code, it only >>> check whether root Loadbalancer status is change from PENDING_UPDATE to >>> ACTIVE. And Loadbalancer status will be changed to ACTIVE anyway no >>> matter Listener's status. >>> >> >> That sounds like a clear bug. >> > > It seems we're checking for any exceptions from the client[1], before > checking for the > loadbalancer status. I could not see any other way to check the listener > status afterwards. > Probably a lbaas bug with octavia driver? > > Could you please raise a bug with the heat/lbaas logs? > > [1] https://git.openstack.org/cgit/openstack/heat/tree/heat/ > engine/resources/openstack/neutron/lbaas/listener.py#n183 > In Octavia, creating resources (listeners, pools, etc.) is an async operation which it wouldn't raise any exception. A normal workflow is: 1. heat/neutron client send a create api to Octavia 2. Octavia return a response to client and set the resource to PENDING_CREATE (no exception will throw to client if the api goes through.) 3. It creation succeeds, Octavia set that resource to ACTIVE; otherwise, set it to ERROR. Please correct me if I am wrong. I will go ahead to raise a bug later if both of you think it necessary. Thanks, Jiahao Liang > >> 2. As heat engine wouldn't know the Listener's creation failure, it will >>> continue to create Pool\Member\Heatthmonitor on top of an Listener which >>> actually doesn't exist. It causes a few undefined behaviors. As a >>> result, those LBaaS resources in ERROR state are unable to be cleaned up >>> with either normal neutron or heat api. >>> >>> >>> Is this a bug regarding LBaaS V2 for heat, or is it designed that way on >>> purpose? In my opinion, it would be more natural if heat reports >>> CREATION_FAILURE if any of the LBaaS resources fails. >>> >>> Thanks, >>> Jiahao Liang >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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
[openstack-dev] [neutron][lbaas][heat][octavia] Heat engine doesn't detect lbaas listener failures
Hello all, I am trying to use heat to launch lb resources with Octavia as backend. The template I used is from https://github.com/openstack/heat-templates/blob/master/hot/lbaasv2/lb_group.yaml . Following are a few observations: 1. Even though Listener was created with ERROR status, heat will still go ahead and mark it Creation Complete. As in the heat code, it only check whether root Loadbalancer status is change from PENDING_UPDATE to ACTIVE. And Loadbalancer status will be changed to ACTIVE anyway no matter Listener's status. 2. As heat engine wouldn't know the Listener's creation failure, it will continue to create Pool\Member\Heatthmonitor on top of an Listener which actually doesn't exist. It causes a few undefined behaviors. As a result, those LBaaS resources in ERROR state are unable to be cleaned up with either normal neutron or heat api. Is this a bug regarding LBaaS V2 for heat, or is it designed that way on purpose? In my opinion, it would be more natural if heat reports CREATION_FAILURE if any of the LBaaS resources fails. Thanks, Jiahao Liang __ 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][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?
Thank you the info Lubosz. On Fri, Jun 17, 2016 at 5:01 PM, Kosnik, Lubosz wrote: > Here is a bug for that - https://bugs.launchpad.net/octavia/+bug/1585804 > You’re more than welcome to fix this issue. > > Lubosz Kosnik > Cloud Software Engineer OSIC > lubosz.kos...@intel.com > > On Jun 17, 2016, at 6:37 PM, Jiahao Liang > wrote: > > Added more related topics to the original email. > > -- Forwarded message -- > From: Jiahao Liang (Frankie) > Date: Fri, Jun 17, 2016 at 4:30 PM > Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and > gateway are required but not used? > To: openstack-dev@lists.openstack.org > > > Hi community, > > I am going over the Octavia amphora backend code. There is one thing > really confused me. In > https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/plug.py#L45, > plug_vip() method doesn't use the cidr and gateway from the REST request. > But in the haproxy amphora api, those two fields are required values (an > assert > <https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/server.py#L117> > will > perform on the server). > > What is the design considerations for this api? Could we safely remove > these two values to avoid ambiguity? > > Thank you, > Jiahao Liang > __ > 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
[openstack-dev] [Neutron][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?
Added more related topics to the original email. -- Forwarded message -- From: Jiahao Liang (Frankie) Date: Fri, Jun 17, 2016 at 4:30 PM Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used? To: openstack-dev@lists.openstack.org Hi community, I am going over the Octavia amphora backend code. There is one thing really confused me. In https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/plug.py#L45, plug_vip() method doesn't use the cidr and gateway from the REST request. But in the haproxy amphora api, those two fields are required values (an assert <https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/server.py#L117> will perform on the server). What is the design considerations for this api? Could we safely remove these two values to avoid ambiguity? Thank you, Jiahao Liang __ 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]TLS container could not be found
84 TRACE barbican.api.controllers pecan.abort(404,
u._('Not Found. Sorry but your container is in '
2016-06-10 12:25:28.184 TRACE barbican.api.controllers File
"/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 141, in abort
2016-06-10 12:25:28.184 TRACE barbican.api.controllers exec('raise
webob_exception, None, traceback')
2016-06-10 12:25:28.184 TRACE barbican.api.controllers File
"/opt/stack/barbican/barbican/api/controllers/consumers.py", line 141, in
on_post
2016-06-10 12:25:28.184 TRACE barbican.api.controllers
external_project_id)
2016-06-10 12:25:28.184 TRACE barbican.api.controllers File
"/opt/stack/barbican/barbican/model/repositories.py", line 364, in get
2016-06-10 12:25:28.184 TRACE barbican.api.controllers
_raise_entity_not_found(self._do_entity_name(), entity_id)
2016-06-10 12:25:28.184 TRACE barbican.api.controllers File
"/opt/stack/barbican/barbican/model/repositories.py", line 2250, in
_raise_entity_not_found
2016-06-10 12:25:28.184 TRACE barbican.api.controllers id=entity_id))
2016-06-10 12:25:28.184 TRACE barbican.api.controllers HTTPNotFound: Not
Found. Sorry but your container is in another castle.
2016-06-10 12:25:28.184 TRACE barbican.api.controllers
2016-06-10 12:25:28.187 INFO barbican.api.middleware.context
[req-4aebc499-b92d-4ab1-8b0e-52f12ddabdd2 d2d0cb2842eb450ebe032d70bcaeeb3b
d24f00aff0b24f4ea7f37d193129d532] Processed request: 404 Not Found - POST
http://192.168.100.149:9311/v1/containers/8daec3a0-1582-4d59-ba04-be11d0c2d036/consumers/
Thank you,
Jiahao Liang
On Mon, Feb 29, 2016 at 5:07 PM, Madhusudhan Kandadai <
madhusudhan.openst...@gmail.com> wrote:
> Okay, Figured out the issue.When debugging, I was trying to create lb and
> barbican clients with different users. Thanks guys!
>
> On Mon, Feb 29, 2016 at 2:07 PM, Phillip Toohill <
> phillip.tooh...@rackspace.com> wrote:
>
>> Is the create LB happening on a different user than the one that created
>> the barbican container? Maybe im not looking at it right, but cant tell
>> from this.
>>
>>
>> Phillip V. Toohill III
>> Software Developer
>> phone: 210-312-4366
>> mobile: 210-440-8374
>>
>>
>>
>> --
>> *From:* Madhusudhan Kandadai
>> *Sent:* Monday, February 29, 2016 3:47 PM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container
>> could not be found
>>
>> Is what I can see the error logs in barbican svc screen while I create
>> TLS listener like this:
>> http://paste.openstack.org/show/xVl9iuJtGW03fCGetDm3/
>>
>> 2016-02-29 13:42:55.222 INFO barbican.api.middleware.context
>> [req-65fd0f08-4c1e-4b2f-9cbd-64f186365077 afaa5d797f3543369d05e370a543ef9d
>> c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST
>> http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
>> {address space usage: 220770304 bytes/210MB} {rss usage: 101371904
>> bytes/96MB} [pid: 52558|app: 0|req: 75/75] 192.168.109.129 () {34 vars in
>> 598 bytes} [Mon Feb 29 13:42:55 2016] POST
>> /v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
>> 111 bytes in 214 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on
>> core 0)
>> 2016-02-29 13:43:17.397 ERROR barbican.model.repositories
>> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
>> c141e106a7424d1a8316cf03a8c91e40] Not found for
>> d96dccd5-0d39-4f67-ba3a-366a84cfd371
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories Traceback (most
>> recent call last):
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories File
>> "/opt/stack/barbican/barbican/model/repositories.py", line 354, in get
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories entity =
>> query.one()
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line
>> 2699, in one
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories raise
>> orm_exc.NoResultFound("No row was found for one()")
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories NoResultFound:
>> No row was found for one()
>> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories
>> 2016-02-29 13:43:17.398 ERROR barbican.api.controllers
>> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
>> c141e106a7424d1a8316cf03a8c91e40] Webob error seen
>> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers Traceback
[openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found
Hi community,
I was going through
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
with
devstack. I was stuck at a point when I tried to create a listener within a
loadbalancer with this command:
neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443
--protocol TERMINATED_HTTPS --name listener1
--default-tls-container=$(barbican secret container list | awk '/
tls_container / {print $2}')
But the command failed with output:
TLS container
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34
could not be found
When I run:
barbican secret container list
I was able to see the corresponding container in the list and the status is
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
| Name | Created | Status | Type|
Secrets
| Consumers |
+++---++-+-+---+
|
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34
|
tls_container | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate |
private_key=
http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd |
None |
|
|| || |
certificate=
http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe |
|
|
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee
|
tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate |
private_key=
http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10 |
None |
|
|| || |
certificate=
http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698 |
|
+++---++-+-+---+
Also, if I did a GET method from a RESTful client with correct X-Auth-Token
to the url:
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e3,
I was able to receive the JSON information of the TLS container.
Anybody could give some advice on how to fix this problem?
Thank you in advance!
Best,
Jiahao Liang
__
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
