[openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found
Bharath M
bharath.stacker at gmail.com
Tue Mar 1 00:37:13 UTC 2016
As Adam stated, it could be any of those reasons. Mainly look for the
credentials defined under [service_auth] section of lbaas conf file. Most
importantly the credentials, tenant (or project) name should be the same as
the user that created the container. This is assuming you aren't using
ACLs'.
On Mon, Feb 29, 2016 at 2:07 PM, Phillip Toohill <
phillip.toohill at 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 <madhusudhan.openstack at gmail.com>
> *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 (most
> recent call last):
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 104, in
> handler
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 90, in
> enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 146, in
> content_types_enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 143, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> controllers.containers.container_not_found()
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/containers.py", line 36, in
> container_not_found
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> pecan.abort(404, u._('Not Found. Sorry but your container is in '
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 141, in abort
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers exec('raise
> webob_exception, None, traceback')
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 141, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> external_project_id)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/model/repositories.py", line 360, in get
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> _raise_entity_not_found(self._do_entity_name(), entity_id)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers File
> "/opt/stack/barbican/barbican/model/repositories.py", line 2173, in
> _raise_entity_not_found
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers id=entity_id))
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers HTTPNotFound: Not
> Found. Sorry but your container is in another castle.
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> 2016-02-29 13:43:17.403 INFO barbican.api.middleware.context
> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b 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: 76/76] 192.168.109.129 () {34 vars in
> 598 bytes} [Mon Feb 29 13:43:17 2016] POST
> /v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
> 111 bytes in 63 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on
> core 0)
>
>
>
>
> On Mon, Feb 29, 2016 at 1:40 PM, Phillip Toohill <
> phillip.toohill at rackspace.com> wrote:
>
>> To further my thoughts, as Adam mentioned, it could be a user issue,
>> which to me is what it sounds like. So being able to view the config and
>> have other information is pertinent to solving the issue.
>>
>>
>> Phillip V. Toohill III
>> Software Developer
>> phone: 210-312-4366
>> mobile: 210-440-8374
>>
>>
>>
>> ------------------------------
>> *From:* Phillip Toohill <phillip.toohill at RACKSPACE.COM>
>> *Sent:* Monday, February 29, 2016 3:33 PM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container
>> could not be found
>>
>>
>> We could use some more information.
>>
>>
>> Phillip V. Toohill III
>> Software Developer
>> phone: 210-312-4366
>> mobile: 210-440-8374
>>
>>
>>
>> ------------------------------
>> *From:* Madhusudhan Kandadai <madhusudhan.openstack at gmail.com>
>> *Sent:* Monday, February 29, 2016 3:21 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container
>> could not be found
>>
>> Wondering, have you guys figured out this issue? I am seeing the same
>> problem that Jiahao is getting.
>>
>> On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell <adam.harwell at rackspace.com>
>> wrote:
>>
>>> Could you provide your neutron-lbaas.conf? Depending on what version
>>> you're using, barbican may not be the default secret backend (I believe
>>> this has been fixed). Alternatively, it depends on what user accounts are
>>> involved -- this should definitely work if you are using only the single
>>> admin account, but we haven't done a lot of testing around the ACLs yet to
>>> make sure they are working (and I believe there is still an outstanding bug
>>> in Barbican that would cause the ACLs to not function properly in our
>>> use-case).
>>>
>>>
>>> --Adam
>>>
>>>
>>> ------------------------------
>>> *From:* Jiahao Liang <jiahao.liang at oneconvergence.com>
>>> *Sent:* Thursday, January 28, 2016 12:18 AM
>>> *To:* openstack-dev at lists.openstack.org
>>> *Subject:* [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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160229/09c0a8a0/attachment.html>
More information about the OpenStack-dev
mailing list