Ask Your Question
3

Keypair is created with Heat stack but sometimes not deleted

asked 2014-08-15 13:59:25 -0500

aavang gravatar image

updated 2014-08-18 09:51:31 -0500

smaffulli gravatar image

I am running icehouse openstack and using a heat stack to create resources, including a keypair. I have seen several times now where the nova keypair still exists after the heat stack is deleted. If I repeatedly create/delete the stack, the keypair is deleted most of the time, but occasionally I find that the keypair does not get deleted. When this happens, I see the messages I have included below.

I am wondering if anyone has encountered this behavior as well? Is there an existing bug report for this or should I create a new bug report.

I have looked in the nova-api.log file and see the following from my attempt to delete the keypair named 'isc01_InternalKey'...and below that segment is another where I tried to recreate the heat stack and it shows a failure to create a keypair with the same name ('isc01_InternalKey') with the error that the same key already exists:

2014-08-15 07:35:46.559 3115 DEBUG routes.middleware [-] Matched **DELETE /e2fa6ebdad824e839421e9cfb4089bff/os-keypairs/isc01_InternalKey** __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100
2014-08-15 07:35:46.559 3115 DEBUG routes.middleware [-] Route path: '/{project_id}/os-keypairs/:(id)', defaults: {'action': u'delete', 'controller': <nova.api.openstack.wsgi.Resource object at 0x7f45d7f67790>} __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:102
2014-08-15 07:35:46.559 3115 DEBUG routes.middleware [-] Match dict: {'action': u'delete', 'controller': <nova.api.openstack.wsgi.Resource object at 0x7f45d7f67790>, 'project_id': u'e2fa6ebdad824e839421e9cfb4089bff', 'id': u'isc01_InternalKey'} __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:103
2014-08-15 07:35:46.559 3115 DEBUG nova.api.openstack.wsgi [req-d7eaab6b-0e7d-41d1-9dbe-e68849129ac6 53162a8bc5fe481d9aa5d2a40c1a6ed2 e2fa6ebdad824e839421e9cfb4089bff] Calling method '<bound method KeypairController.delete of <nova.api.openstack.compute.contrib.keypairs.KeypairController object at 0x7f45d80e6250>>' 
(Content-type='None', Accept='application/json') _process_stack /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:945
2014-08-15 07:35:46.563 3115 INFO nova.api.openstack.wsgi [req-d7eaab6b-0e7d-41d1-9dbe-e68849129ac6 53162a8bc5fe481d9aa5d2a40c1a6ed2 e2fa6ebdad824e839421e9cfb4089bff] ****HTTP exception thrown: The resource could not be found.****
2014-08-15 07:35:46.564 3115 DEBUG nova.api.openstack.wsgi [req-d7eaab6b-0e7d-41d1-9dbe-e68849129ac6 53162a8bc5fe481d9aa5d2a40c1a6ed2 e2fa6ebdad824e839421e9cfb4089bff] Returning 404 to user: The resource could not be found. __call__ /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:1215
2014-08-15 07:35:46.564 3115 INFO nova.osapi_compute.wsgi.server [req-d7eaab6b-0e7d-41d1-9dbe-e68849129ac6 53162a8bc5fe481d9aa5d2a40c1a6ed2 e2fa6ebdad824e839421e9cfb4089bff] 135.1.194.1 "DELETE /v2/e2fa6ebdad824e839421e9cfb4089bff/os-keypairs/isc01_InternalKey HTTP/1.1" status: 404 len: 272 time: 0.0090990
2014-08-15 07:35:49.657 3103 DEBUG keystoneclient.middleware.auth_token [-] Authenticating user token __call__ /usr/lib/python2.7/dist-packages/keystoneclient/middleware/auth_token.py:569

yet...when I turn around and try to create the same keypair, it fails..

2014-08-15 07:41:57.781 3115 DEBUG routes.middleware [-] Route path: '/{project_id}/os-keypairs', defaults: {'action': u'create', 'controller': <nova.api.openstack.wsgi.Resource object at 0x7f45d7f67790>} __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:102
2014-08-15 07:41:57.782 3115 DEBUG routes.middleware [-] Match dict: {'action': u'create', 'controller': <nova.api.openstack.wsgi.Resource object at 0x7f45d7f67790>, 'project_id': u'e2fa6ebdad824e839421e9cfb4089bff'} __call__ /usr/lib/python2 ...
(more)
edit retag flag offensive close merge delete

Comments

I'm not sure if your question is about searching for bugs or it's about how to properly delete the keypair. Can you edit your question and make it more specific?

smaffulli gravatar imagesmaffulli ( 2014-08-15 16:46:59 -0500 )edit

I have edited the question to hopefully make it more clear. In summary, The problem I see is that a keypair created by a heat stack is not always being deleted when the stack is deleted. Log entries show the deletion attempt is not succeeding because it is not finding the keypair to delete.

aavang gravatar imageaavang ( 2014-08-18 07:48:54 -0500 )edit

I have the same problem. i name my keypair in the Heat template by the stack-name, so i get a conflict when this happens. It is rare, but happens. I have not started to debug it. I can reproduce it if a different user (in the same project) deletes the stack.

don gravatar imagedon ( 2014-09-04 19:41:11 -0500 )edit

3 answers

Sort by ยป oldest newest most voted
1

answered 2014-08-18 09:55:41 -0500

smaffulli gravatar image

A simple search for 'keypair' on Heat's bug tracker doesn't return any significant hit. The fact that this behavior is random makes me think that this is indeed a bug and should be investigated further. If you can, try running the same stack against an installation from trunk (devstack, maybe). In any case, I would suggest to file a new bug report, if you don't get a more comprehensive answer here.

edit flag offensive delete link more
0

answered 2015-01-29 10:29:07 -0500

David Hill gravatar image

I created a bug report as I'm hitting this bug as well.

edit flag offensive delete link more

Comments

0

answered 2015-01-29 10:58:48 -0500

dale-aavang gravatar image

updated 2015-01-29 13:57:03 -0500

I have also run into a somewhat related scenario that I thought might be useful to mention here. If user-1 of tenant-a runs a heat stack that creates a keypair, it cannot be deleted by another user of the same tenant due to issues revolving around the management/ownership of security keypair. There is a bug report for this issue: https://bugs.launchpad.net/heat/+bug/1308834 (https://bugs.launchpad.net/heat/+bug/...)

The change made by this bug report seems to be part of Juno 2014.2. I have tested this in Juno 2014.2.1, and the deletion of the stack created by user-1 now works for user-2, but it seems the keypair that was originally created by user-1 from with-in the heat stack does not get deleted and remains associated with user-1. This may cause problems down the road if user-1 tries to rerun the heat stack since it will fail to create the keypair, since it already exists.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2014-08-15 13:59:25 -0500

Seen: 953 times

Last updated: Jan 29 '15